并非每个 LLM 请求都需要立即响应。聊天界面需要实时响应。但数据提取、丰富化和后台工作可以等待数小时。这种时间灵活性可以解锁巨大的成本节省，尽管简单的实现会创造可靠性噩梦。

这种模式非常常见。一个团队需要处理数十万份文档，所以他们编写了一个循环，等待每个响应。然后脚本在请求 1000 次时失败，他们意识到需要检查点、重试和速率限制。不久，他们只为调用 API 就构建了一个分布式任务队列。

我最近发现了一个 551 行的 Python 文件，它最初是一个“简单”的批量处理器。它有自定义的速率限制、指数退避、分布式锁、检查点文件和用于恢复逻辑的状态机。 以下是实际代码 。这类一次性脚本非常常见，似乎是在你尝试让同步 API 执行批量工作时产生的。

这里的悲剧不在于复杂性。而是在所有这些工程之后，他们仍然没有利用批量折扣！

这并不是说这种策略是错误的——对于 10k 次请求以下的情况，它可能非常合理，因为你可以快速响应，并且可能愿意为了快速完成而牺牲成本。但到了一定规模，这种脚本就会崩溃，变得难以维护。

这就是为什么在 Inference.net 我们构建了最可扩展的批量 LLM 推理服务 。

批量与实时测试的简单方法

这里是我的决策方法：如果结果要进入数据库而不是用户界面，就使用批量处理。如果有人正在等待响应，就使用实时处理。

这涵盖了90%的使用场景。数据丰富化、分类、提取、摘要、嵌入生成、合成数据创建——所有这些都是批量处理。聊天界面、搜索建议、内容推荐——所有都是实时处理。

中间地带也在出现。不需要立即响应的单个请求，但又不适合整齐地放入批量处理。这就是异步推理大放异彩的地方，但这将是另一篇博客文章的主题。

等待的经济学

当你发起实时 API 调用时，你并不是在为计算付费。你是在为保证可用性付费。

你的提供商承诺立即响应。为了实现这一点，他们让 GPU 在远低于满负荷的状态下闲置，随时准备立即响应你的请求。你实际上是在为机器等待付费。

批量处理打破了这种模式。你不再要求立即响应，而是给提供商最多 24 小时的时间来完成你的工作。他们将你的请求打包到闲置的 GPU 时间中，在实时请求之间，在非高峰时段。同样的硬件，同样的模型，但现在你只支付实际计算的费用。

这是为什么 Inference.net 可以提供 10%的批量处理折扣（对于企业规模的工作负载，请联系我们以获取更大的折扣）。通过使用批量计算，我们可以更有效地使用我们的 GPU，并将这些节省转嫁给您。

与处理单个请求不同，使用我们的批量 API，您可以先准备数据，然后将其交给我们。我们处理所有复杂性，包括重试。

以下是完整的实现，可扩展到数百万份文档：

from openai import OpenAI
import json

client = OpenAI(base_url="https://api.inference.net/v1", api_key="inf-xxx")

# Prepare all requests upfront
with open("batch.jsonl", "w") as f:
    for i, doc in enumerate(documents):
        f.write(json.dumps({
            "custom_id": f"doc-{i}",
            "method": "POST",
            "url": "/v1/chat/completions",
            "body": {
                "model": "meta-llama/llama-3.2-1b-instruct/fp-8",
                "messages": [{"role": "user", "content": f"Classify: {doc['text']}"}],
            }
        }) + "\n")

# Submit and wait
file = client.files.create(file=open("batch.jsonl", "rb"), purpose="batch")
batch = client.batches.create(
    input_file_id=file.id,
    endpoint="/v1/chat/completions",
    completion_window="24h"
)

现在，大型工作负载不再需要重试逻辑、速率限制或检查点。平台内部处理所有事情，使用专为这种用例设计的经过实战考验的基础设施。

Webhook 驱动的批量处理的优雅之处

我见过的最好的大多数批量工作流程都使用 webhook 而不是轮询。你提交你的批量任务，并附带一个回调 URL，然后就可以放手不管了。当处理完成时，你会收到一个包含结果的 POST 请求。

批量推理的目标通常是更新数据库。使用批量+webhook 架构，如果我们愿意，我们可以完全无服务器地完成这项工作！

Example Batch Workflow

示例批量工作流程

当批量处理还不够时

在真正的互联网规模下，即使是批量定价也会累积起来。当你每月处理数千万到数十亿个请求时，是时候考虑高级优化了。

模型蒸馏是最强大的方法。在 Inference.net，我们提供端到端任务特定的模型训练 ，我们使用一个大模型为你特定的任务生成高质量的标签，然后训练一个成本只有一小部分的小模型。这种方法与批量处理特别有效，因为蒸馏模型通常具有相似的需求模式。

因为 Inference.net 通过租赁未使用的计算资源已经提供了极具竞争力的价格，我们的批量处理费用很难被超越。但对于具有重复结构的真正大规模工作负载，我们也提供具有 KV 缓存优化的专用实例。当数百万个请求共享公共前缀（如分类提示或提取指令）时，预先填充 KV 缓存可以进一步降低成本。模型蒸馏、批量处理和前缀缓存的组合可以实现与同步 API 相比高达 95%以上的成本降低。

如果您在 LLM 推理上的月支出超过 10k，请联系我们！这些优化可以改变您的经济状况。

转换过程

如果您仍然通过同步 API 运行批量工作负载，转换过程很简单。将您的数据导出为 JSONL 格式，其中每行都是一个完整请求。上传文件，开始批量处理，完成后检索结果。

在 Inference.net，我们的基础设施非常适合批量工作负载。而其他人将批量工作视为次要任务，我们将数据中心中闲置的 GPU 容量进行聚合，以实现低成本的无服务器推理，但更低的批量处理成本。我们可以在已经很低的价格上提供 10%的折扣，对于大量订单还有更大的折扣。

那么，那些介于实时和批量之间的请求怎么办？那些不需要即时响应，但也不适合批量处理的请求？

这就是我们的异步 API 和分组 API 发挥作用的地方。异步 API 允许您发送单个请求并在准备好时获取结果，而分组 API 可以将多达 50 个相关请求作为一个单元处理——非常适合处理用户上传的文档或一起分析消息线程。

对于某些工作流程，异步 API 可以比大型批量处理提供重大优势，同时提供相同的折扣。我们下一篇文章，《 最便宜的 LLM 调用是你不需要等待的那个 》，探讨了异步请求如何改善开发人员对后台任务的体验。