批处理请求
Batch API
中级通用批处理请求（Batch API）是把多条独立任务集中提交给服务处理，并在稍后领取各条结果的接口方式。它适合不必立即返回的大量工作，帮你减少逐条调度的开销；例如夜间给商品评论批量生成摘要。
你可能会说：「我有几万条评论要让模型逐条总结，不急着看到结果，能不能一次提交、之后再取？」
动手看看夜间批量生成评论摘要
1
夜间，应用把多条商品评论的摘要任务打成一批提交。每条评论独立处理，但只需发起一次批量请求。
要点批处理请求是怎么运作的？
- 1
先把独立任务组织成一批
你可以把每条评论的总结请求作为一项任务，附上自己的记录 ID，再集中提交。这样服务处理完后，我们才能把结果准确写回对应评论，而不是依赖返回顺序猜测。
- 2
提交成功不等于处理完成
批处理通常先返回一个批次标识，任务随后在后台处理。你的程序要查询批次状态，或按服务支持的方式接收完成通知，再读取结果；它不适合让用户一直盯着加载动画等回答。
- 3
逐条核对结果与失败项
同一批里的任务可能有成功也有失败。拿到结果后，你要按任务 ID 对账，只重试失败项，并留意服务的批次大小、处理时限和计费规则；这些细节会因服务而异。
容易混淆的地方
批处理请求和并发请求都能处理许多任务，但并发请求仍是逐条发出、逐条等待，适合需要较快拿到结果的场景；批处理更偏向集中提交、稍后取回。它也不等于消息队列：队列负责缓冲和分发任务，批处理 API 则提供提交一批请求并取得结果的接口。成本是否更低，要看具体服务的定价。
什么时候用
适合用
- 电商后台夜间为几万条新商品评论生成摘要，运营第二天查看结果。
- 给已有文章批量生成标签，用文章 ID 对应结果，并单独重试失败项。
- 定期对历史客服对话做分类统计，任务量大，但不影响用户当前操作。
不适合用
- 用户在聊天框发问后等着即时回复，用普通请求或流式响应更合适。
- 用户提交订单后需要立刻知道支付是否成功，改用实时接口处理并返回状态。
- 几项操作必须严格按顺序共享中间结果，先设计工作流或后台任务，而不是当作独立请求打包。
练一练选一个答案，看看解释
你在做评论管理后台，要给五万条旧评论生成摘要。管理员不需要实时看结果，但要知道哪些评论失败了。你会怎么设计？
让 AI 帮你做复制给 AI Agent 直接用
请为评论摘要任务设计批处理请求流程：每条评论带唯一 ID，集中提交后记录批次状态，完成时按 ID 写回结果，并单独记录和重试失败项。先说明当前模型提供方是否支持批处理、处理时限与计费规则，再给出实现方案。