大多数团队将 LLM 调用视为要么是同步的 （现在给我答案）要么是批量的 （今晚运行整个数据集）。然而，对于某些工作负载来说，批量推理并不适用，这就是我们为什么要引入一种新的 LLM 请求类型：一个_异步的_请求。

异步请求 – 一旦空闲 GPU 可用，就会完成。

以下是关于为什么这很重要以及如何今天使用 Inference.net 来实现它的 5 分钟解释。

为什么“同步”是昂贵的

从 OpenAI/Anthropics 到 Inference.net 这样的 OS LLM 提供商，所有无服务器推理服务都面临同样的问题——有时你会看到使用量的大幅波动，而扩展现有的 GPU 来处理所有请求却很难，这可能导致一些请求失败。个人用户购买信用额度，并期望能够随时进行 LLM 推理。他们可能会以允许的速率尽可能快地发送请求，或者等待一段时间后再发送请求，并期望在他们决定进行推理时，容量是充足的。

在交互式端点中，唯一降低错误率的方法是保持 GPU 处于预热状态并等待。问题是，租用和低效使用 GPU 是昂贵的，这些成本最终转嫁给了用户。

行业调查将平均利用率放在 15%-40%的范围内，这意味着你正在为大量的闲置时间付费（DevZero，LinkedIn）。这种浪费的容量最终被纳入所有提供的 LLM 模型的价格中。

这也是为什么大多数 LLM 提供商都有极其严格的速率限制——他们根本无法在保持可靠性的同时处理推理的突然增加，而且他们的错误容忍度通常出人意料地低。那么，如果你需要成千上万甚至数百万次请求来丰富你的数据库，你该怎么办呢？

批处理作业有所帮助——但可能不是最佳选择

批处理 API 允许你上传一个巨大的文件，并获得一张单价的折扣账单。从定价角度来看，批处理对双方来说实际上都非常出色。用户可以得到折扣，而 LLM 推理提供商则可以利用整天未充分利用的容量。

批处理对于处理大型数据集，如分类或合成数据集生成等任务非常出色，但通常你只是想处理一个请求并更新你的数据库。你不需要即时响应（实际上等待即时响应可能会实际上使用宝贵的服务器资源），但你也不想担心将 LLM 请求累积成一个大批次！

对于许多不需要即时响应的产品，开发者要么：

  • 人为地等到午夜才运行批量操作（需要管理请求和构建整个工作流程，如果批量操作因某些原因失败，风险很高），要么
  • 继续通过同步调用烧钱。

遇见异步请求

一个_异步_请求只是一个普通的 API 调用，它说：

“这是我的有效载荷。我不在乎答案两分钟后还是10小时后回来——只要便宜就行。”

因为提供商可以将这些工作滑入空闲的 GPU 间隙（与批量处理相同），价格就会下降，并且基本上不需要速率限制。一天处理 10M 异步请求比 10 分钟内处理 5k 请求要容易得多，尽管后者的请求/秒数要高得多。

这些’异步’请求对开发者来说更加方便，他们可以设置一个 webhook 端点来在 inference.net 仪表板中接收响应，并等待请求到来。

使用 /v1/slow 在 Inference.net 上

from openai import OpenAI   # OpenAI SDK works out of the box

client = OpenAI(
    base_url="https://api.inference.net/v1/slow",  # only change
    api_key=os.getenv("INFERENCE_API_KEY"),
)

job = client.chat.completions.create(
    model="meta-llama/llama-3.2-1b-instruct/fp-8",
    messages=[{"role": "user", "content": "Summarize War and Peace in 10 bullets"}],
    metadata= {
      "webhook_id": "AhALzdz8S"
    }
)
print(job.id)        # store this for later

调用立即返回一个 请求 ID。当 GPU 处理能力较低（可能是立即或最多 24 小时后），获取结果：

curl https://api.inference.net/v1/generation/$ID \
  -H "Authorization: Bearer $INFERENCE_API_KEY"

或者，更有可能的是，在您的 webhook 端点接收响应！

当异步调用有意义时

  • 大规模内容生成（翻译、合成数据、SEO 内容、丰富化）
  • 异步丰富化任务（公司数据查询、文档嵌入）

一些可能从异步请求中受益的应用示例

同步（亚秒级或流式）

  • 支持小部件的实时聊天完成
  • IDE 中的代码自动补全
  • 用户发布消息前的实时策略过滤

批量（按计划的大负载）

  • 夜间将该日文章批量翻译成20种语言
  • 每周对模型进行一次重新训练，评分 10M 条评论以刷新嵌入
  • 月底合同审计，对每个新的 PDF 文件运行 LLM 以检查合规性标志

异步（一次性调用，无需等待响应）

  • 用户资料丰富化：当有人注册时，启动一个低成本的异步请求来总结他们的 LinkedIn/GitHub 资料，并存储起来以备后续个性化使用
  • 背景标签化：每个新上传的 PDF 文件都会被发送到 /v1/slow 进行关键词提取；标签在准备好后进入您的数据库
  • 异步情感/语气评分：每封客户邮件都会收到一个异步请求来标注情感，这样就不会阻塞支持代理人的工作，同时为分析仪表板提供数据

为什么异步请求可能比同步请求更好

对于同步请求，我们需要等待响应。通常，你最终会为这段等待时间付费（我个人因为等待缓慢的异步请求，已经产生了超过 10k 的 Vercel 函数持续时间费用）。异步请求不需要你等待响应，因此处理大量请求要简单得多。除此之外，你还能节省成本并提高可靠性。如果你不需要即时结果，这真的是不言而喻的。

便宜多少？

Inference.net 目前将异步推理的价格定在同步价格的 10%以下，但如果你预计会有大量工作负载，请联系我们，我们可能能够提高这个数字。

TL;DR

  1. 同步用于用户体验， 批量用于大型离线作业。
  2. 其他呢？ 异步请求。
  3. 它们是即插即用的（/v1/slow），对 webhook 友好，还能帮你削减 LLM 账单。