给五万条商品补分类，给一批客服记录做摘要，或者让候选模型跑完同一套评测题，这些任务很少要求用户盯着屏幕等答案，逐条调用在线接口当然能做，程序却要自己处理并发、限流和失败重试。批量推理把整批请求交给模型服务异步处理，适合用等待时间换费用和调度空间。
我查了 Gemini 与 OpenAI 当前的 Batch API 文档。Gemini 把数据预处理和评测列为典型用途，批量请求按同模型标准交互费用的一半计价，目标周转时间是二十四小时。OpenAI 的批任务也使用二十四小时完成窗口。这个时限说明了使用边界，用户正在等的客服回答和付款确认不该走这条路。
每条请求都要带回自己的身份
小批任务可以直接提交请求列表，大批任务通常写进 JSONL 文件，一行放一个完整请求。Gemini 的内联请求总量需小于 20MB，文件输入上限为 2GB。OpenAI 当前允许单个输入文件放最多五万个请求，文件不超过 200MB。各家限制会变，提交前应以目标平台文档为准。
文件里的请求需要带稳定的业务编号。批任务完成顺序未必与输入顺序相同，只靠第几行去认结果，很容易把摘要写回错误记录。编号还可以帮助重试时去重，区分首次结果与补跑结果。
创建任务本身也要防重复。Gemini 文档明确说明，创建批任务不具备幂等性，同一请求发两次会生成两个独立任务。客户端超时以后若直接再发一遍，可能得到两份账单和两套结果。程序应先保存任务标识，再按状态查询，确实没有创建成功才补交。
整批完成不等于每条都成功
批任务通常会经历校验、排队、运行和完成等状态。输入文件格式错误可能让任务在校验阶段失败，单条内容超限或参数不对，也可能只影响其中几条。Gemini 建议完成后查看失败请求数量，并逐行判断拿到的是模型响应还是错误状态。OpenAI 的批对象同样分别记录完成和失败的请求数，并提供错误文件。
因此，接收程序要准备三张清单。成功结果进入下一步，能修正的错误单独重试，过期或取消的任务保留原因。这里的清单可以是数据库状态，不必真的做成表格。关键在于每条输入都能对上结果，每次重试都有记录。
我会先拿一百条任务试跑，故意放入几条格式错误和超长输入，看系统能否认出局部失败。确认编号、状态和重试都能对上以后，再扩大批量。批量推理省下的费用很实在，前提是业务能等，接收端也接得住一份不完全整齐的结果。