Summary

  • OpenAI 的 Batch API 提供相对同步接口 50% 的价格折扣和 24 小时处理窗口。批次过期时，已完成请求消耗的 token 仍会计费。
  • 未完成请求被取消，并在错误文件里标为 batch_expired。输入、输出、错误三份记录要用 custom_id 对齐，才能知道买到了什么、还缺什么。

采购单上有“半价”，交付清单上却可能有空格。这正是 Batch API 自己写明的过期规则。

OpenAI 允许客户把多条请求装进 JSONL 文件，交给异步队列处理。它在官方说明中给出两个卖点：成本比同步 API 低 50%，另有独立的速率额度池。处理窗口为 24 小时。对批量评测、文档分类、知识库向量化来说，折扣足以改变排队方式。问题出现在买方把“便宜的请求”当成“完整的项目”采购时。

过期的批次不会替客户补齐最后几行。OpenAI 规定，未按时完成的批次进入 expired 状态；已做完的响应保存在输出文件，未完成的请求被取消，相关记录进入错误文件并带有 batch_expired 代码。已完成请求消耗的 token 照常收费。窗口把任务截成了两段，账单只认已经执行的那一段。

这条规则对供应商和客户的意义不同。供应商交付了若干响应，有明确的用量。客户可能需要整个数据集才能交差：评测缺几个样本，结果就不能当完整评测；分类缺一批文件，业务流程仍要等待。折扣降低了已完成部分的单价，却没有替买方完成剩下的工作。两种“完成”被同一个 Batch 状态混在一起，最容易在预算会上被一句“任务结束了”带过去。

核账的钥匙不是输出文件的行号。每条输入请求必须带唯一的 custom_id，而 OpenAI 明确提醒：输出顺序可能与输入顺序不同。按第几行去贴结果，会把答案放到错误的原始记录上。保存输入 ID 清单，再分别同输出文件和错误文件匹配，才会得到三张准确的表：已成功、已报错、仍需处理。过期后重新提交时，最后一张表决定第二次队列应装哪些请求。

批次对象本身提供总体证据：状态、expires_at 与 expired_at、输出文件和错误文件 ID，以及 request_counts 中总数、已完成数和失败数。符合条件的批次还会给出 token 用量。计数适合发现缺口，custom_id 才能指出缺口的名字。一个“完成了九成”的数字，无法告诉团队剩下的一成是不是最重要的客户记录。

如果运营人员把原始文件整包再投一次，已经有答案的行也会重新执行。只把未解决的 ID 组成新批次，第二轮才真正瞄准缺口。OpenAI 的公开资料没有某家客户的过期输出和发票；具体损失金额要看该客户的两份结果文件、模型价格和账单记录。

所以，Batch 的经济问题不是折扣真假。50% 是清楚的价格规则；交付完整率是买方自己必须证明的结果。企业要买的是前者，还是必须在内部期限前得到后者？这个问题在提交文件之前就该有负责人。

Sources