用 OpenAI API 跑批量任务的团队早晚会算这笔账：几千条文本要翻译、几万个商品标题要打标签、一整天的客服日志要出摘要——这些活不着急，账单却着急。AI 服务的批处理通道正是为这类需求准备的：Batch API 把任务打包提交，平台在后台慢慢跑，账单按对折计。不过它最常被误解的恰好是那个「24 小时窗口」：很多人以为要干等一天，结果该用的没用，不该等的反倒把急件塞了进去。这篇按入门篇的惯例把链路讲全：窗口的真实语义、半价的来由、哪些任务适合丢进批、哪些不适合，以及从准备文件到取结果的完整流程。
先说清窗口：24 小时是上限，不是等待时长
官方对 Batch API 的承诺表述是：批任务会在 24 小时窗口内完成。很多人把它读成「要等满 24 小时」，这一读偏差就把不少人挡在了门外。实际机制是：24 小时是完成时限的天花板，多数批次远远早于此返回，量小、单条短的批次常常几十分钟就跑完，量大、模型重的批次才需要按小时计。所以适用判断的正确姿势是问自己一句：这个任务最晚多久能等？deadline 在三天后，批处理随便用；十分钟后就要拿结果，老老实实走同步调用。还有一点随版本在调整：超时的批次如何处理、已完成的部分怎么返回，截至发稿版本，以官方更新日志为准，写代码前先把这条款读一遍。
半价从哪来：把低谷算力卖给不着急的活
折扣不是慈善，是算力的供需匹配。实时请求有高峰有低谷，低谷期的机器闲着也是闲着；批处理任务不挑时间，正好拿来填谷。平台用一半的价格换你让出「随时响应」的权利，双方各取所需，对折就是这个机制的定价表达。理解了来由，两条使用纪律就顺理成章：其一，别把急件塞进批处理——平台承诺的是 24 小时内，没承诺分钟级，急件走实时通道才是正路；其二，批处理的费率、配额上限属于平台的定价策略，随时可能调整，具体以官方定价页为准，做成本测算时直接查官方页面，别依赖二手数字。
适用任务：能等、量大、条条独立
判断一个任务能不能进批，三条标准过一遍。能等：deadline 按「最晚多久」估，不按「希望多久」估。量大：量太小省不了几个钱，反而搭进去准备 JSONL、上传、轮询的时间成本，几十条的任务直接调实时接口更划算。条条独立：批里的每条请求互不依赖、没有执行顺序保证，第一条的输出喂不进第二条。对上三条的典型场景不少：语料翻译与本地化、内容打标与分类、历史对话批量摘要、数据清洗与脱敏、评测集批量打分。还有一类间接用法值得记住：白天实时跑的业务，夜里把当天日志、超时失败的请求原样重跑一遍——批处理当夜间保洁用，成本对折，睡一觉起来结果已经在文件里。
不适用任务：交互、串行、超时敏感
反过来，三类别硬往批里塞。交互式任务：用户正在等答案的聊天、搜索联想、实时客服，批处理的对象是「人不在线」的活。串行依赖任务：第二条请求要等第一条的输出，批内条目各跑各的，没有先后，硬要做只能拆成多个批次接力，那等于自建队列，不如直接写实时调用循环。超时敏感任务：监控告警、风控拦截、分钟级报表，这类任务的价值随延迟衰减，对折的价格换不回迟到的价值。另外提一句体量边界：单批任务数与文件大小都有上限，超了要拆分多个批次文件，具体数值以官方文档为准；拆批本身不复杂，但要记得把批次 id 与业务对应关系记下来，否则回收结果时对不上号。
| 任务类型 | 典型形态 | 硬塞进批的后果 |
|---|---|---|
| 交互式 | 用户正在等答案的聊天、搜索联想、实时客服 | 批处理的对象是「人不在线」的活，人在等就等不起 |
| 串行依赖 | 第二条请求要等第一条的输出 | 批内条目各跑各的、没有先后，硬做等于自建队列 |
| 超时敏感 | 监控告警、风控拦截、分钟级报表 | 价值随延迟衰减，对折的价格换不回迟到的价值 |
完整链路：从 JSONL 到对账取数
提交流程四步走。第一步，把请求写成 JSONL 文件：一行一条请求，每行包含自定义 id、目标模型、接口方法与请求体，id 自己起名，回头用来把结果对回原任务。第二步，上传文件并创建批处理任务，拿到批次 id，这一步之后任务就交出去了，不影响你继续干别的。第三步，轮询批次状态：状态变为 completed 后下载结果文件，里面按你给的 id 逐条对应；部分条目失败不影响整批，逐条看返回里的 error 字段定位原因，错误字段的结构与常见类型怎么读，见API 错误结构一篇。第四步，对账：批处理的用量在用量面板里单列，成本核算与用量核对走这一列，用量的计量口径见用量计量一篇。整个链路的原理，与推理服务里批量处理的通用机制一脉相承，见批量推理一篇；批处理与实时通道的整体取舍，见批处理与实时取舍一篇。动手前可以让 DeepSeek 按你的任务量粗估两条通道的成本差，再用豆包把手头的任务清单按「能等、不能等」过一遍，分类做完，哪些该进批就清楚了。
Batch API 速查
- 24 小时是完成上限不是排队时长，多数批次早于此返回
- 半价的代价是让出时效：急件走实时，慢件进批
- 三条适用标准：能等、量大、条条独立
- 交互式、串行依赖、超时敏感三类任务别进批
- JSONL 一行一条、轮询状态、按自定义 id 回收结果
- 费率与配额以官方定价页与文档为准
关于 Batch API 的常见疑问
- 批次里有条目失败了，整批作废吗？：不作废。批处理按条目计费、按条目返回结果，失败的那几条在结果文件里带 error 信息，单独拿出来排查后重提即可；整批不会因为个别失败而报废，已完成的条目照常可用。
- 提交之后还能取消吗？：任务还在进行中时可以发起取消，取消前已执行完的条目按规则计费；已经进入完成状态的批次没有「取消」一说，只能按失败条目的方式处理。取消接口的参数与细节以官方文档为准。
- 批处理的输出质量和实时接口有差别吗？：没有。跑的是同一批模型，采样机制、参数语义完全一致，随机性也一致；差别只在返回时间与价格。如果你实测出明显差异，先检查两边请求参数是否一致，再考虑反馈给官方。
批处理通道解决的是成本侧的问题；成本之外，跑批量任务同样要盯用量与账单，账单突然飙升的排查思路见账单异常排查一篇，与本文正好凑成一明一暗两道闸。
