Batch API 批量对话
Batch API 适合离线评测、内容分类、数据清洗等无需实时返回结果的批量任务。调用方通过一个prompts 数组提交多条对话请求,平台异步处理整个批次。
本接口采用内联请求格式,无需预先生成或上传批次文件。请求体包含模型、
prompts 及可选的批次配置。接口概览
完整示例
示例中的<API-KEY> 表示实际 API Key,<MODEL-NAME> 表示已开通 Batch API 的模型名称。
接口返回格式
创建、查询和取消接口成功时都返回 Batch 对象。不同状态下,部分字段可能为null 或不出现。所有时间字段均为 Unix 秒级时间戳。
对外响应不会返回平台内部使用的
input_file_id 和 output_file_id。
创建批次
POST /v1/batches 创建成功返回 HTTP 202。任务通常从 validating 开始,此时还没有 usage 和 output_url:
查询批次详情
GET /v1/batches/{batch_id} 成功返回 HTTP 200 和最新 Batch 对象。建议直接保存并处理完整响应,不要依赖 JSON 字段顺序。
状态为 completed 且结果文件已经生成时,详情会额外返回 usage、output_url 和 output_url_expires_at。状态为 failed 或 cancelled 时,通常会返回 errors.data;每个错误项包含 code 和 message。
状态与可选字段
通用错误响应
鉴权失败、参数错误、批次不存在或依赖服务异常时返回非2xx 状态码,响应格式为:
details 可能为空或不出现。排查问题时应提供 trace_id,不要只依赖 message 文本判断错误类型。
下载批次结果
批次状态变为completed 后,详情响应会返回可下载的 output_url:
output_url 是 3 天内有效的临时签名地址,下载时无需再次携带 API Key。地址过期后,重新查询批次详情即可获取新的签名地址。请勿记录或转发完整地址。
custom_id 与创建批次时的输入关联,并从该行的 response.body 读取模型结果。只有创建批次的 API Key 能查询批次详情并获取签名地址。
任务尚未生成结果,或终态下没有可下载结果时,详情响应不会包含 output_url。
结果文件格式
结果文件不是 JSON 数组,而是 JSONL:每一行都是一条完整、非流式的 Chat Completions 结果。结果行顺序不保证与输入顺序一致,应使用custom_id 关联输入。
普通文本成功结果示例:
- 结果正文:
response.body.choices[0].message.content - Token 用量:
response.body.usage - 单条请求状态:
response.status_code
response 为 null,错误信息位于 error:
response != null 和 error != null。响应中的 choices[].message 是完整的非流式结果;Batch API 不返回需要拼接的 SSE choices[].delta 事件。
创建参数
prompts 中除 custom_id 外的字段会作为单条 Chat Completions 请求参数处理,例如 messages、temperature、max_tokens、tools 和 tool_choice。顶层 model 会统一应用到批次中的所有请求。
工具调用
需要模型选择工具时,在对应 prompt 中传入tools 和 tool_choice:
response.body.choices[].message.tool_calls。其中 function.arguments 是 JSON 字符串,调用方应按工具参数定义解析和校验。
工具调用结果示例:
messages 示例:
tool_choice,取决于所选模型的能力。
状态与计费
任务完成后,
request_counts 给出总请求数、成功数和失败数:
usage 返回批次汇总 Token 用量:
usage 通常在批次完成后返回。平台根据成功结果的实际 Token 用量完成一次后扣费,客户端重复查询批次不会重复扣费。
查询批次列表
200:
列表项不会返回临时签名
output_url。需要下载结果时,使用对应 id 查询批次详情以获取新的签名地址。
继续读取下一页时,将上一页的 last_id 作为 after:
取消批次
cancelling,此时可继续查询详情,直到状态变为 cancelled。
取消请求成功时返回最新 Batch 对象。任务进入 cancelled 后,常见响应为:
completed、failed、cancelled 或 expired 的任务不能再次取消。
使用建议
- 轮询间隔建议设置为 30 秒,避免高频查询。
custom_id建议使用业务侧稳定且唯一的标识,便于关联每条结果。- 业务逻辑应分别处理
failed、cancelled和expired状态。

