批处理与异步推理

这笔交易到底是什么。

你提交一份包含大量彼此独立请求的文件，提供方按自己的排期把它们跑完，你在任务结束时取回结果。Anthropic 的 Message Batches API 与 OpenAI 的 Batch API 都把这件事定价为标准价的 50%，输入与输出皆然，并以 24 小时完成窗口作为承诺；实际上多数批次远早于此就跑完了。

• 模型是同一个。同样的权重、同样的质量、同样的上下文窗口。你没有在降级能力——这是唯一一个只花你时间、不花你别的东西的成本抓手。
• 折扣是有原因的。可排期的工作让提供方能填补实时流量高峰之间的低谷。你卖出去的是延迟上的灵活性，所以这个价格是结构性的，而不是促销性的。
• 请求彼此独立。提交的单位是一个列表，不是一段对话。每一条都自带完整提示词，并以你指定的 ID 各自取回结果。

你手上哪些活儿其实是离线的。

只用一条判据：接下来几秒内，有人被这件事卡住吗？如果没有，它就是批处理的候选。在多数系统里，这份清单比预想的长。

• 评测运行。一组固定输入按计划打分——这是最纯粹的批处理形态，而且往往是生产之外最大的令牌消耗方。参见评估智能体。
• 回填与富化。给一张已有的表做分类、摘要或打标。工作量有界，截止时间是「下一份报表之前」。
• 索引构建。喂给检索系统的文档摘要、抽取出的实体、生成的查询，都是构建一次、读取多次——参见分块与向量搜索。
• 数据生成。批量产出训练或测试样本，晚一天交付毫无影响；参见合成数据。
• 定时报表。凌晨三点跑、上午九点被人读的那份日报，有六个小时的余量，而它现在一分钟都没花掉。

批处理不适用的地方——更重要的那一半。

这些限制是结构性的，认清它们能避免你设计出一个从根上用不了这个折扣的系统。

• 循环无法批处理。智能体循环第 n+1 步的输入是第 n 步的输出，所以提交批次的那一刻，后面的请求根本还不存在。批处理适配的是扇出形态——大量彼此独立的调用——而不是串行形态。你可以批处理一千个智能体任务，但没法批处理一个任务的各个步骤。
• 它和提示词缓存相互拉扯。缓存条目的存活时间以分钟计，而一个批次要在数小时里陆续被调度，共享前缀很难一路保持热态。如果你现在的节省主要来自一个巨大的缓存前缀，请把两条路都测一遍，别默认它们可以叠加——参见提示词缓存。
• 飞行途中无法干预。没有可供检视的中间输出，提交之后也无从介入。任何需要人在中间把关的事情，都属于实时路径。
• 那个窗口是上限，不是承诺。多数批次很快就完成；你不能据此规划一个产品功能。如果截止时间是硬的，你就需要为仍未返回的部分准备同步兜底。

做两条车道，按截止时间分流。

能干净地吃到这份折扣的设计，不是在请求路径上外挂一个「批处理功能」，而是一个队列：每个工作单元都带着自己的截止时间，而分流看的是截止时间——不是模型，也不是任务类型。

• 截止时间超过一小时 → 走批处理车道。其余一律走同步。这是一条能用一句话说清的路由规则，而正因如此它才能在代码库不断变大之后依然活着。它与模型路由可以组合但彼此独立：一个决定用哪个模型，一个决定有多急。
• 长尾降级到同步。先提交批处理；若截止时间到了仍有结果未返回，只把这部分请求改用同步重发一遍。你为少数几条付全价，而不是为全部。
• 让任务可续跑。按请求 ID 记录已提交、已返回、已失败。单条请求会单独失败，而一个无法局部重试的批处理任务只能整个重跑——到那时你等于把折扣花掉了两次。
• 把这个比例放上看板。「每月令牌中经由批处理车道的百分比」是多数团队从未算过的数字。它通常从接近零开始，向上的空间大得很。

延伸阅读：智能体成本控制按回报排序讲各个抓手，成本、质量与延迟讲底下那个三角，服务与访问讲这些 API 位于何处。