批处理层级是 AI 时代的竞价实例

打开你的 Token 仪表板，针对其中的每一个工作负载问一个问题：是否有真人在等待这个响应？对于大多数在生产环境中运行智能体（Agent）的团队来说，诚实的回答是：至少有一半以上的账单并非如此。评估套件（Eval suites）、向量回填（embedding backfills）、每日报告生成、批量分类、隔夜代码迁移、昨日工单总结——这些任务都没有用户在盯着进度条。然而，几乎所有这些任务都流经交互式端点，以全额价格支付，并与那些真正对延迟敏感的请求竞争同样的容量。

每个主流供应商都会以一半的成本运行这些可延迟的工作。OpenAI 的 Batch API、Anthropic 的 Message Batches 以及 Gemini 的 batch 模式都为异步作业提供统一的 50% 折扣，以换取 24 小时的完成窗口。这种折扣不需要谈判，不需要承诺消费，也不需要工程上的壮举。它只要求你在架构中承认，某些工作是可以等待的——而大多数团队从未做出过这种让步，因为没有人将“延迟交付”作为一个设计决策。

我们以前看过这类戏码。多年来，抢占式实例（Spot instances）为云计算提供了 60–90% 的折扣，但大多数团队仍将所有业务保留在“按需（on-demand）”模式下。这并非因为节省的费用不真实，而是因为使用它们被迫面对一个令人不安的问题：我们哪些工作负载可以容忍中断？回答了这一问题的团队构建了检查点（checkpointing），并将计算账单削减了一半以上。没回答的团队则继续支付“凡事皆紧急”税。批处理层级是同样的岔路口，只不过坐标轴从“中断容忍度”变成了“延迟容忍度”——而且智能体工作负载每项任务消耗的 Token 是聊天机器人的 5 到 30 倍，这使得不作选择的代价要昂贵得多。

按延迟容忍度分类，而非重要性

可延迟的工作之所以出现在交互式端点上，是因为一个分类错误：团队根据工作负载的“重要程度”而不是“结果可以等待多久”来进行分类。你的每日评估运行很重要——它决定了明天的发布。你的合规性总结很重要——法律团队每天早上都要阅读。重要性触发了直觉，即为这项工作提供“最佳”基础设施，而每个人都认为这意味着最快的路径。

但重要性和紧急程度是正交的。评估运行是重要的，并且可以容忍 6 小时的延迟。相比之下，自动补全请求是微不足道的，并且必须在 800 毫秒内返回。

一个更清晰的筛选问题是：谁或什么被阻塞了，直到响应到达为止？他们能被阻塞多久？ 这大致产生了四个层级。

• 交互式（Interactive，数秒）： 有人在看着。聊天对话、IDE 内补全、实时支持智能体。这是唯一一个“首 Token 延迟（TTFT）”至关重要的层级。
• 响应式（Responsive，数分钟）： 有人在附近但没盯着看。工单分拣智能体、PR 审查机器人、工作流中某人定期检查的文档处理步骤。
• 可延迟（Deferrable，数小时）： 消费者是定时计划，而不是人。评估套件、数据增强、向量刷新、作为早间 PR 提交的智能体驱动的代码迁移。
• 随时（Whenever，一天或更久）： 回填、语料库重新处理、历史数据的定期重新评分。

最后两个层级属于批处理层或其等效方案。在大多数重度使用智能体的公司中，它们占据了 Token 消耗量的 40–60%。后台推理——监控智能体、文档监听器、合规监控——是企业 LLM 支出中增长最快的部分，恰恰是因为它们在没有人工干预的情况下持续运行。这是你拥有的最可延迟的流量，而它通常在支付交互式溢价。

没人阅读的层级菜单

价格格局已悄然变成了一份真正的菜单，而“标准（standard）”现在是它的中间选项，不再是默认选项。

在顶端，OpenAI 以更高的 Token 单价销售优先级处理（priority processing），以便在需求高峰期提供持续更快、更稳定的生成——这明确针对交互层级，因为 p99 延迟是一项产品特性。在底部，批处理 API（batch APIs） 提供统一的 50% 折扣和 24 小时的 SLA：你上传一个包含请求的文件（OpenAI 最多支持 50,000 个，Anthropic 每批支持数万个），供应商将其安排在空闲容量中，你在完成后收集结果。

在两者之间，OpenAI 的 flex processing 在同步 API 上提供约半价优惠，代价是响应速度较慢，且在容量紧张时偶尔会出现 429 错误——这是一个类似于“抢占式”的层级，你保留了请求/响应编程模型，但接受“尽力而为（best-effort）”的调度。DeepSeek 走了不同的路线，直接对时间定价：历史上在 UTC 非高峰时段提供 50–75% 的折扣，将“今晚运行”变成了一个字面意义上的折扣窗口。像 OpenRouter 这样的路由服务现在将供应商服务层级作为一个请求字段暴露出来。

看看这个菜单到底是什么：供应商正在进行负荷整形（load-shaping），就像电力公司和云抢占式市场所做的那样。推理容量是按交互式需求峰值配置的，这意味着深夜和非高峰期的低谷充满了闲置的加速器。50% 的折扣是供应商付钱让你把灵活的负载转移到他们的低谷期。这个框架很重要，因为它告诉你折扣是结构性的，而不是促销性的——只要交互式需求是有波峰的且 GPU 是昂贵的，就会有人付钱让你保持灵活性。灵活性现在是你架构中可变现的属性，而一个无法表达“这可以等待”的架构正在永久地把钱丢在桌子上。

经济效应还会叠加。在支持这两项功能的供应商上，批处理折扣可以与 Prompt 缓存（prompt caching）叠加，使重复性、模板密集型工作负载（这正是评估和回填的特点）的单次调用实际成本降至标价的四分之一左右。

熬过 24 小时窗口期：竞价实例的经验同样适用

团队在尝试批处理层（Batch Tier）一次失败后就选择放弃，其原因与他们当初放弃竞价实例（Spot Instances）如出一辙：他们只是迁移了工作负载，却没有针对故障模型进行重新设计。竞价实例教会了一代基础设施工程师，只有当你能优雅地处理中断时，廉价算力才是真正的便宜——这意味着要在外部记录检查点（Checkpoint）进度、处理两分钟的预警消息、实现恢复而非重启。批处理层有其特有的故障模型，它要求同样的工程纪律。

首先：批处理任务是部分失败，而非原子级失败。 一个包含 10 万行的批处理任务返回时，已完成的行、供应商报错的行、内容被过滤的行以及超时的行会混杂在一起。如果你的流水线将批处理视为一个整体单元——“任务成功了吗？”——那么 4% 的错误率要么会导致整个运行失败（浪费了那 96% 的进度），要么会被悄无声息地忽略（导致下游数据损坏）。你需要进行行级（Row-level）设计：跟踪每条请求的完成状态，并在上游决定如何处理失败行——是丢弃、在下一个批次中重试，还是通过全价的同步 API 进行恢复。衡量成本的真实指标是每条已完成行的成本（包括重试成本），而不是发票金额。

其次：在整个窗口期内设置检查点，因为窗口期是真实存在的。 结果可能在提交后几分钟到一整天内的任何时间返回，而你的提交进程不会在这段时间内一直存活。在提交的一瞬间，就将批处理 ID 和每行状态持久化到可靠存储中，以原子方式写入检查点，并使收集器（Collector）具备幂等性，这样崩溃的轮询器可以恢复运行而非重新提交。这正是竞价实例的检查点模式——将进度外部化，假设工作节点会死亡——并将其应用于一个“中断”仅仅是时间流逝的任务。

第三：24 小时的 SLA 破坏了假设“同小时产出结果”的反馈循环， 这正是真正让团队头疼的失效模式。如果你的评估套件（Eval Suite）决定了是否可以部署，而你将其移至批处理层，那么这个闸口现在对比的是昨天的提示词（Prompt）与今天的模型。有效的模式是同步金丝雀（Synchronous Canary）：将 1–2% 的行通过交互式端点运行，以便现在做出决策，然后让完整的批处理在夜间运行，以获得次日的全面视图。廉价的批量覆盖和快速的决策闸口是不同的任务；将它们分开，而不是强迫一条路径兼顾两者。

第四：审计不同路径下的质量。 据从业者报告，在相同的评价标准下，通过批处理路径运行的模型快照得分有时会比同步路径低几个百分点——容量池路由和窗口期内的快照轮转是真实存在的。定期对通过两条路径的几百行数据进行成对审计，可以告诉你这种折扣是否在悄悄地牺牲质量。信任，但要抽样。

嗅探测试：一个 90% 可延迟的“紧急”队列

这里有一个值得搜索（grep）的架构异味：一个单一的请求路径，其中所有的内容都隐式地具有紧迫性。如果你的代码库中每个 LLM 调用都通过一个客户端封装器、一个端点且没有期限概念，那么紧迫性从未被决定过——它只是被默认了。队列看起来很紧急，因为紧急是它唯一能表达的状态。

修复方法既简单又枯燥：将**延迟容忍度（Latency Tolerance）**设为每个 LLM 任务的必填字段，就像竞价实例时代的作业调度器将中断容忍度设为必填项一样。当工程师将 Agent 任务入队时，他们声明一个截止日期——interactive（交互式）、1h（1 小时）、24h（24 小时）——然后路由器将该声明映射到一个层级：交互式任务使用 Priority（优先级）或 Standard（标准），1 小时窗口使用 Flex（弹性）或 Off-peak（非高峰），其余的使用 Batch（批处理）。一旦该字段存在，就会发生三件事：

• 默认值发生反转。 在没有人类等待的情况下，任务会流向廉价层而非昂贵层，因为工程师必须主动申明紧急性，而不是被动地继承它。
• 成本审查变成紧迫性审计。 财务部门询问“为什么这个工作负载在交互层运行？”是一个比“为什么 AI 账单上涨了 40%？”好得多的对话——前者有负责人和明确的答案。
• 容量规划变得诚实。 你真实的交互式 QPS——这个决定了速率限制谈判和故障切换设计的数字——最终会发现只是原始请求量的一小部分。

这里还隐藏着组织层面的回报。延迟会压力测试你的 Agent 的自主性。能等待 24 小时的任务也必须能在无人值守的情况下运行：没有人类来批准工具调用，没有人来推动卡住的循环。被迫将 Agent 任务路由到批处理层的团队，必须构建检查点机制、幂等性和自我修复能力，而这些正是完全自主的 Agent 本就需要的。折扣为这种纪律提供了资金。

截止日期是新的设计原语

交互式端点并不是什么“真正”的 API（而批处理只是个折扣噱头）——它是成熟市场中的溢价层级，这个市场对延迟的定价方式与十年前云服务对中断的定价方式如出一辙。竞价实例奖励了那些能说“我可以被中断”的工作负载；批处理层奖励了那些能说“我可以等待”的工作负载。两者都是相同的底层交易：供应商付费让你吸收他们的调度灵活性，而这笔报酬只流向那些能够接受它的架构。

因此，让延迟成为一种决策而非意外。添加延迟容忍度字段，针对这四个层级对你现有的 Agent 工作负载进行分类，并在本季度迁移两个明显的候选对象——评估（Evals）和数据回填（Backfills）；它们容量大、模板化，且没人在等待。在信任 24 小时窗口的决策闸口之前，先建立行级账本和同步金丝雀。然后再次检查仪表盘。如果你发现一半的 Token 一直以来都是可以延迟的，那么你之前支付的双倍价格，仅仅是为了换取“从不提问”的特权——而答案其实只隔了一个字段。