Batch 批处理还是实时调用：“半价”两个字后面还有三个条件
OpenAI 与 Anthropic 的批处理接口，文档里都写明相比同步调用有 50% 的成本折扣。对预算压力大的团队，这是最容易一眼看到的省钱机会，但“半价”是有条件的：结果不是立刻返回，请求存在过期的可能，提示词缓存的命中也不再稳定。要把这笔账算明白，就要同时看三件事：任务能等多久、失败或过期后如何补救、缓存节省是否还成立。本文对照 OpenAI、Anthropic 的官方文档（核验日期 2026-10-01，价格与限额以官方页面为准），整理什么任务该走 Batch、什么任务必须实时，以及综合成本怎么算。
两家 Batch 的硬性条件
OpenAI：24 小时窗口，独立额度池
OpenAI Batch 文档说明，批处理有 50% 的成本折扣，完成窗口固定为 24 小时，支持 Chat Completions、Embeddings、Responses 等多个端点。单个批次文件最多 50,000 个请求、200 MB，每小时最多创建 2,000 个批次。一个容易被忽略的好处是：使用 Batch 不会消耗标准的按模型速率限制，它有单独的额度池，给同步调用留出了空间。
Anthropic：大多数一小时内完成，但不保证
Anthropic 的 Message Batches 文档说明，单个批次最多 100,000 个请求或 256 MB，以先到者为准；系统尽快处理，大多数批次一小时内完成，但 24 小时内未完成的请求会过期；处理速度还可能随当前需求和你的请求量而变慢，过期的请求会变多。结果在批次创建后 29 天内可下载，之后只能看到批次本身。文档还说明批处理需要在服务端保存输入和输出直到完成，最多 29 天，处理完后可以手动删除。如果数据较敏感，需要把这个保留限期纳入评估。
Flex 模式：介于实时与批处理之间
OpenAI 还提供 Flex 处理，价格按 Batch 费率计算，仍然是标准的请求形式，代价是响应更慢，且在容量不足时可能返回 429 Resource Unavailable，文档说明这种情况不计费。官方建议把客户端超时从默认的 10 分钟上调到至少 15 分钟，并对可以接受延迟的任务用指数退避重试，或在需要确保完成时改用标准处理。该模式目前仍在测试阶段，支持的模型需要查看官方定价页。它适合模型评测、数据补全这类非生产任务。
| 方式 | 响应时间 | 成本 | 主要风险 | 适合的任务 |
|---|---|---|---|---|
| 实时调用 | 秒级 | 标准价格 | 受速率限制 | 用户在等待的对话与交互 |
| Flex 模式 | 分钟级、不确定 | 按 Batch 费率 | 可能返回 429 不可用 | 内部评测、数据补全 |
| Batch 接口 | 小时级，最长 24 小时 | 标注半价 | 过期、缓存命中不稳定 | 大批量分类、摘要、离线评测 |
缓存与 Batch 能不能叠加
折扣可叠加，但命中是尽力而为
Anthropic 文档说明，Message Batches 支持提示词缓存，两者的折扣可以叠加；但因为批次里的请求是异步、并发且顺序不定处理的，缓存命中只是尽力而为，官方给出的用户经验命中率区间为 30% 到 98%，取决于流量模式。所以不能把“半价”和“缓存命中”直接相乘当作确定的省钱比例，预算里要保留余量。
把缓存命中率抬起来的三件事
- 每个请求都带相同的 cache_control 块，让公共前缀完全一致。
- 保持稳定的请求流，避免缓存因超时过期；文档建议批处理可考虑 1 小时的缓存时长。
- 把共享的上下文放在每条请求的前面，尽可能多地复用。
命中条件与命中率的算法，可以对照提示词缓存怎么省钱：命中条件、命中率算法与账单变化。
一张综合成本表：把过期与回落算进去
公式：相对成本 = 0.5×(1−e) + 1×e
设批处理中有比例 e 的请求最终要回落到实时调用（过期、失败或临近截止时手动补跑），那么综合相对成本近似为 0.5×(1−e)+1×e。e 为 10% 时约为原价的 55%，e 为 30% 时约 65%，这仅是一个简化的示例计算，没有计入缓存折扣和工程成本，实际以账单为准。它说明一件事：即使有一定比例回落，只要任务确实能等，Batch 仍然划算；但如果业务对截止时间很敏感，回落比例不可控，这张表就要重新算。
截止时间感知的混合策略
比较稳妥的写法是“先 Batch，临截止前补实时”：把任务的截止时间倒推，在距截止还有一个缓冲窗口时，查询批次状态，把未完成的部分抽出来，用实时调用补跑。这样正常情况下享受半价，异常情况下不会错过交付。补跑时要注意限流，避免一次性把实时额度打满，相关处理见API 报 429、529 或超时的三类错误区分。
哪些任务该走 Batch，哪些必须实时
适合 Batch 的任务
- 大批量的分类、标签、摘要，结果第二天使用即可。
- 定期的离线评测与回归测试，尤其是换模型前的对照。
- 数据分析与文档批量整理，允许夜间跑完。
必须实时的任务
- 用户正在对话或操作的场景，等待不能超过数秒。
- 需要多轮依赖前一次结果的智能体流程，每一步都要等上一步。
- 客服、风控、告警等对时效有硬要求的环节。
批处理有可观测性要求
批量任务往往是一次性的大额消费，建议在用量看板里给每个批次打标签，记录请求量、完成率、过期率和总成本，并与预算告警联动，可以参考团队 AI 预算治理：用量看板、告警阈值与部门分摊。
总结：先问能等多久，再问省多少
选 Batch 还是实时，第一个问题不是“能省多少”，而是“这个结果最晚什么时候需要”。能等的任务走 Batch，并用截止时间倒推的回落策略兜底；不能等的任务保持实时，并用缓存和路由降低单价。如果你的团队同时有实时与批量两类负载，可以在 Tonbo AI 的内置 AI Chat 面板里先用实时调用验证提示词效果，再把稳定的批量部分迁到批处理，结合多模型路由与 Token 套餐比较单位成本，价格比较可以查看2026 主流大模型 API 定价对比。
