批次层推理之问：当 50% 的折扣重塑你的架构时

你账单中最便宜的推理费用，是那些你付了两次的钱。几乎所有主流模型提供商现在都提供批处理层（batch tier），价格大约只有同步推理的一半，代价是接受以小时而非毫秒计的完成窗口。大多数工程团队要么完全忽视这一选项，要么只是随手扔进一个深夜定时任务（cron），然后宣称省下了钱。这两种做法都白白浪费了 30%–50% 的推理总支出——并非因为折扣不够大，而是因为批处理并不是一种代金券。它是一个全新的产品层面，拥有自己的 SLA、重试语义和失败模式。那些仅将其视为计费优化的团队，最终要么使用率低下，要么上线了需要数周才能排查出来的细微回归问题。

技术核心不在于“我们是否应该使用批处理？”，而在于：你系统中的哪些动作在用户感知层面确实是同步的，哪些是工程团队为了开发体验方便而“误当成”同步的，以及哪些可以在下游消费者不预设结果实时性的前提下重新塑造为任务（jobs）。回答这个问题需要进行工作负载审计、从“请求型（request-shaped）”到“任务型（job-shaped）”契约的架构转变，以及根据用户预期而非开发便利性，对每个智能体动作进行延迟层级的诚实映射。

价格标签是最简单的部分

各大提供商给出的头条数据是真实且一致的。OpenAI 的 Batch API 为所有模型（GPT-5 系列、mini 和 nano 变体、o 系列推理模型以及 embeddings）提供统一的 50% 折扣，换取 24 小时的完成窗口。Anthropic 的 Message Batches API 同样在输入和输出 token 上提供 50% 的优惠，每批次可处理多达一万个查询，且均在 24 小时内完成。两家提供商都指出，大多数批处理任务实际上在 1 到 6 小时内就能完成，24 小时只是作为最坏情况的上限，而非预期时长。

将批处理折扣与 Prompt 缓存（prompt caching）叠加，省钱效果会成倍增长。如果一个工作负载已经受益于系统提示词 90% 的缓存命中率，那么在缓存折扣的基础上，已缓存的输入还将按批处理层级计费。对于大规模的数据增强流水线，相对于直接调用同款模型的同步接口，实际输入成本可能会降低一个数量级。这是大多数生产团队能用到的最大成本杠杆，且不需要更换模型，不会出现质量下降，也无需开发新功能——只需要一点耐心。

难点在于，这种“等待的意愿”不是团队的属性，而是工作负载的属性，而大多数团队还没学会区分二者。

没人做的负载审计

梳理一个典型智能体（Agent）产品的推理调用图，询问每一个 LLM 调用：如果结果晚到四小时会发生什么？大多数工程师会下意识地回答“用户在等着呢”——对于智能体的主循环来说，这确实没错。但一个成熟产品的调用图中，大部分路径其实并不是用户急需的：

• 预计算摘要（Pre-computed summaries）：用户打开应用时看到的每日或每周摘要，而不是在生成的瞬间就要读的。
• 分类回填（Classification backfills）：分类体系变更后的存量数据重标记、根据新政策对历史内容打分、对夜间到达的支持工单进行标注。
• 评估评分运行（Eval scoring runs）：根据质量标准对生产追踪（traces）打分的判别模型、针对候选提示词运行的回归测试套件、生成本周置信度阈值的离线校准任务。
• 向量刷新（Embedding refreshes）：模型升级后的知识库重新向量化、新摄入文档集的向量化、针对基准向量进行的定期漂移检查。
• 内容审核队列（Content moderation queues）：标记用户生成内容供审核，其 SLA 是“在人工介入之前”，而非“在用户看到自己的帖子之前”。
• 回顾性增强（Retrospective enrichment）：从历史自由文本记录中提取结构化字段、为已发布的图像生成替代文本（alt-text）、为下游分析归一化日志行。

在典型的智能体产品中，这些负载加起来占到了总推理支出的一大部分，令人惊讶的是，其中绝大多数最初都是作为同步调用实现的，因为开发该功能的程序员只是顺手使用了处处都在用的 SDK 模式。审计的目的不是为了寻找显而易见的深夜任务，而是寻找那些在代码中看起来是同步的、但实际上并没有人在另一端苦等结果的调用。

从“请求型”到“任务型”契约

一旦确定了负载，将其迁移到批处理层绝不仅仅是将 messages.create 换成 batches.create 那么简单。调用者与被调用者之间的契约形式发生了变化，一些在请求模式下可选的工程原则，在任务模式下变成了强制性的。

任务级幂等，而非调用级幂等。同步请求失败可以在线重试，调用者假设只会执行一次，因为响应要么到达，要么不达。而批处理任务可能部分完成、超时，或者在调用者崩溃重启时静默成功。每个任务都需要一个能在调用者重启后存活的幂等键，每次结果写入在重复交付下必须是安全的，每个消费者都要能从任务账本中重新推导状态而不重复计算。跳过这一步的团队，会发送重复的通知、产生双倍计费的增强运行，并在分析表中留下幽灵数据。

加载中…