你的 AI 工作负载也有“夜晚”：批处理折扣是对架构的考验

每一个主流模型提供商都在以半价向你出售同样的 Token。OpenAI、Anthropic 和 Google 都提供 Batch API，其收费仅为同步请求费率的 50% —— 模型相同、提示词相同、输出也相同 —— 唯一需要你做出的让步是：接受 24 小时的完成窗口，而不是在几秒钟内获得答案。对于一个每月在推理上花费 50,000 美元的团队来说，这意味着有 25,000 美元摆在桌面上，无需更改任何一行提示词即可领取。

大多数团队从未领取过这笔钱。并不是因为折扣被隐藏了 —— 它就在每一个定价页面上 —— 而是因为领取它需要回答一个组织内从未有人问过的问题：我们的推理调用中，哪些真正需要立即得到答案？ 事实证明，这是一个架构问题，而大多数公司的诚实回答是：“我们从未对它们进行过分类，所以默认情况下所有任务都运行在交互式通道中。” Batch 折扣并不是一个定价脚注。它是一场测试，考验你的系统是否了解自身的延迟需求 —— 而大多数系统都未能通过测试。

大型机时代的“昼夜分割”又回来了

计算领域以前也经历过这种情况。在大型机时代，机器时间是稀缺资源，因此机房将工作分为两种模式：白天的交互式作业（操作员和用户需要实时响应），以及夜间的批处理任务 —— 发工资、生成报表、账目对账 —— 这些任务排队等候以消化闲置时间。昼夜分割并不是一种风格选择。它是对昂贵且容量受限的计算资源的经济理性反应。

随后计算变得廉价，这种纪律性也随之瓦解。在过去的二十年里，Web 请求的边际成本接近于零，以至于没有人费心按紧迫程度对请求进行排序。一切都变成了“实时”，因为实时是免费的。

LLM 推理打破了这一假设。单个智能体工作流（Agentic Workflow）可能消耗数百万个 Token；GPU 容量确实稀缺；且单次请求的成本高到足以成为首席财务官（CFO）询问的会计科目。因此，古老的分割悄然回归，并换上了新装：同步 API 是白天，Batch API 是深夜，两者之间 2 倍的价格差距，与五十年前大型机操作员所响应的信号如出一辙。不同之处在于，这一次大多数工程团队还没注意到这个信号 —— 他们从“紧迫性是免费的”那个时代继承了“一切都是 API 调用”的心理模型。

将每一个调用分配到不同的延迟通道

开启这个可能性的关键在于分类练习，而非技术迁移。系统中的每一个推理调用都属于以下三个通道之一：

• 交互式（Interactive）：人类或智能体正被阻塞以等待答案。聊天轮次、自动补全、或者智能体在任务中途决定其下一个工具调用。延迟预算以秒计。这个通道支付全价，理应如此。
• 可推迟（Deferrable）：工作必须完成，但无人等待。架构变更后的嵌入（Embedding）回填、为明天的仪表盘进行文档分类、针对新模型版本的评估套件、对昨天支持工单的总结、对历史数据的内容审核。延迟预算以小时计。这就是 Batch 通道。
• 周期性（Periodic）：按计划循环发生的工作，其截止日期是 下一次运行，而非“现在”。每日报表生成、每周推荐语料库的重新排序、每月的数据质量审计。这个通道在构建之初就是批处理模式 —— 它已经具有 Cron 形状的节奏；团队只是习惯性地通过同步 API 运行它，因为那是他们手头现成的客户端库。

针对真实的流量日志运行此审计，结果通常令人惊讶。团队假设他们的工作负载以交互式聊天为主，因为那是他们关注的产品界面。但当他们查看 Token 统计时，会发现嵌入生成、评估（Evals）、富化流水线（Enrichment Pipelines）和离线分类占总支出的 40–70% —— 这一切都是可推迟的，且都在为没人使用的延迟保证支付 2 倍的溢价。在大多数公司中，交互式通道只占 Token 消耗的少数；它只是占据了注意力的绝大部分。

这里有一个值得明确指出的推论：如果你无法将你的调用分类到这些通道中，这本身就是一个发现。这意味着延迟需求存在于工程师的头脑中，而不是系统里，你距离通过惨痛教训发现它们仅有一场事故之遥。

Batch 并非“只是变慢的同步” —— 它要求架构重构

折扣未被领取的理由并不是懒惰。而是 Batch API 确实要求不同的程序形态，而将这种形态改造到基于“请求/响应”构建的代码库中需要实实在在的工作。其中三项要求影响最大：

任务必须是幂等的（Idempotent）。 一批 10,000 个请求不会整齐划一地完成。某些项会因为频率限制（Rate Limits）或服务器错误而失败；偶尔整个批处理会在 24 小时标记处过期并只返回部分结果。你的流水线必须能够重新提交失败的部分 —— 且仅针对失败部分 —— 而不重复处理成功的部分。这意味着需要稳定的请求 ID、内容哈希处理过的输入，以及可以安全回放的结果写入。如果你目前的流水线在每次响应时都向表中追加数据，那么你拥有的不是一个就绪的 Batch 流水线，而是一个重复数据生成器。

结果需要陈旧度预算（Staleness Budget）。 一旦你接受了 24 小时的窗口，你就接受了输出描述的是截至一天前的世界。对于大多数可推迟的工作，这没问题 —— 支持工单的总结不会在一夜之间腐烂。但这个预算必须是明确的。典型的失败案例：一个团队将产品目录富化移至 Batch，商品策划人员在窗口期中途编辑了产品，而 Batch 结果（基于旧描述计算）在 12 小时后覆盖了新描述。每一个 Batch 消费者都需要一套规则来处理提交后输入发生变化的情况，哪怕这套规则只是“此处可以接受‘最后写入者胜’（Last-write-wins），理由如下”。

队列需要监控和泄压阀。 同步调用会立即大声报错；Batch 任务则会在明天悄无声息地失败。这种反转意味着你需要可能尚未具备的可观测性：队列深度、Batch 完成率、入队时间百分位，以及针对已在 90% 完成状态停滞了 6 小时的 Batch 发出告警。你还需要一条升级路径 —— 当一个可推迟的任务突然变得紧急时（例如副总裁正要演示的仪表盘是空的），必须有一种被认可的方法通过同步 API 重新路由这些项并支付全价，而不是让工程师在午夜手动搞一个绕过方案。

诚实的成本指标源于那个泄压阀：不是 Batch 发票金额，而是 (Batch 成本 + 同步重试成本) 除以已完成、经验证的输出。单次有用输出的成本总是高于标称折扣所暗示的价格。通常它仍然远低于同步定价 —— 但你应该了解真实的数字。

这些都不新奇。这是数据工程团队应用于任何异步流水线的相同纪律。新颖之处在于将其应用于推理，而大多数团队仍将推理视为函数调用，而非一项作业（Job）。

折扣是供应商在付钱请你平滑他们的负载曲线

值得去理解折扣为什么存在，因为背后的原因决定了它是否会持久。

推理需求具有昼夜节律且呈突发性。交互式流量在工作时间达到顶峰，而在深夜跌至谷底，但 GPU 资源是固定存在的——供应商的机群规模是根据峰值确定的，这意味着在波谷时期，大量的算力处于闲置状态。行业估计 AI 数据中心的平均 GPU 利用率在 60–70% 之间，而峰谷之间的差距正是成本最高昂的部分：无论是否有 token 在流动，电力基础设施、冷却系统以及加速器的资本成本都已支出。最近关于 AI 数据中心电力动态的研究提出了一个互补的观点——批处理加交互式的混合工作负载产生的总需求比单一模式明显更平滑，这正是因为批处理作业可以等待，而交互式需求则在到达瞬间占用算力。

批处理队列是供应商对自己波谷进行套利的方式。你可延迟的任务变成了可调度的“填料”，在凌晨 3 点吸收闲置算力，从而提高已经购买并通电的硬件的利用率。50% 的折扣是供应商在与你分享这笔套利收益：他们宁愿在一个原本颗粒无收的 GPU 小时上赚取半价。这正是电力分时计价和竞价实例（spot instances）背后的经济学逻辑——受容量限制的公用事业机构付钱给客户，以促使他们将负载从高峰期移走。

随之而来有两个实际影响。首先，“24 小时” SLA 是最坏情况，而非典型情况——由于供应商会在算力空闲时随时清空队列，批处理通常在 1 到 6 小时内就能完成，尽管你无论如何都必须针对最坏情况进行架构设计。其次，这种折扣是结构性的，而非促销性的。只要交互式需求存在昼夜差异且 GPU 产能受限，供应商就会为可调度的负载付费。如果说有什么变化的话，随着机群规模的扩大，这种激励只会更深：每一个新的按峰值设计的集群都会创造一个更大的波谷。你今天为批处理构建的架构是与业务的底层物理逻辑相契合的，而不是为了一个会过期的优惠券。

在下一份账单寄到前进行审计

批处理折扣是极少数不需要谈判、不需要迁移供应商、也不需要牺牲模型质量的成本优化手段。它需要的是自省：诚实地盘点哪些调用需要立即得到回复，而哪些只需最终得到结果。

具体的操作可以在一周内完成。调取一个月的推理日志，并标记每个调用点（call site）——不是每次调用，而是每个调用点——是交互式的、可延迟的还是周期性的。统计每个路径的 token 总量。在大多数系统中，你会发现有两位数百分比的支出分布在可延迟和周期性路径中，并且可以列出两三个只需少量代码改造即可迁移到批处理的流水线（评估和嵌入几乎总是首选）。先迁移这些，为队列安装监控，采用“单位有效产出成本”作为指标，并利用简单迁移节省下来的资金，让更复杂的迁移逐步排入路线图。

更深层次的转变在于将延迟视为每个推理调用的显式属性，而不是第一个工程师恰好引入了哪个 API 的偶然结果。能够识别自身紧急程度的系统，可以随着供应商不断扩大“立即”与“随时”之间的价格差距，顺着价格曲线下行。而无法做到这一点的系统，将继续为那些没人在清醒时阅读的任务支付白天的价格。