OpenAI Batch vs 标准 API：并排对比

一句话总结：如果工作不需要在一小时内得到答案，Batch API 以一半的价格完成相同的推理——代价是同步秒级响应与最长 24 小时的完成窗口。对于嵌入回填、夜间分类、数据集生成和批量摘要，这是 AI 工程中最简单的 50% 成本削减方式。

概览

标准 APIBatch API

延迟秒级，同步最长 24 小时窗口（通常快得多，但不保证） 价格列表价格输入和输出均享 50% 折扣（依据 OpenAI 定价页面） 接口每次调用一个 HTTPS 请求上传 JSONL 请求文件 → 轮询 → 下载结果 速率限制您所在层级的 RPM/TPM独立的、每批次更高的配额（按模型上限适用） 流式✅❌ 每次提交规模1 个请求最多 50,000 个请求 / 每个文件 200 MB

除了价格之外，还有两个不明显的优势：批次配额独立于您的交互式速率限制（回填不会挤占生产流量），并且基于文件的工作流强制实现了幂等、可恢复的任务设计，而临时脚本通常缺乏这一点。

完整流程

python
import json, time
from openai import OpenAI
client = OpenAI()
1. 构建 JSONL——每行一个请求，custom_id 是您关联结果的方式
with open('batch.jsonl', 'w') as f:
    for doc in documents:
        f.write(json.dumps({
            'custom_id': doc['id'],
            'method': 'POST',
            'url': '/v1/chat/completions',
            'body': {
                'model': 'gpt-4o-mini',
                'messages': [{'role': 'user', 'content': f'分类情感：{doc["text"]}'}],
                'max_tokens': 8,
            },
        }) + '\n')
2. 上传 + 创建批次
batch_file = client.files.create(file=open('batch.jsonl', 'rb'), purpose='batch')
batch = client.batches.create(
    input_file_id=batch_file.id,
    endpoint='/v1/chat/completions',
    completion_window='24h',
)
3. 轮询（或稍后回来检查——不提供 webhook）
while (batch := client.batches.retrieve(batch.id)).status not in ('completed', 'failed', 'expired'):
    time.sleep(60)
4. 下载并通过 custom_id 关联
results = {}
for line in client.files.content(batch.output_file_id).text.splitlines():
    r = json.loads(line)
    results[r['custom_id']] = r['response']['body']['choices'][0]['message']['content']

实践中需要注意的细节：

custom_id 是必填项，也是唯一的关联键——结果以任意顺序返回。请使用您自己的稳定 ID。

部分失败是正常的：每行错误会进入单独的 error_file_id。务必检查它，并设计任务仅重新提交失败的 custom_id。

expired 状态可能发生（在负载下）——未完成的请求会被返回（您只需为完成的请求付费）；重新提交剩余部分。

支持的端点包括聊天补全、嵌入和响应——嵌入回填可以说是杀手级应用。

各自适用的场景

标准 API：任何面向用户的内容、代理/工具循环（其中第 N+1 次调用依赖于第 N 次调用）、任何需要流式的场景。

Batch API：夜间/离线分类和标记、整个语料库的嵌入、合成数据和评估集生成、重新总结存档、定时报告生成。思维转变：如果您的代码路径是“cron 任务 → 遍历行 → 调用 API”，那么该循环几乎肯定应该改为批处理文件——而异步加信号量模式（同步 vs 异步调用）仅在您*当天*需要结果时才是正确的工具。

严肃流水线最终采用的混合方案：批量用于大规模回填，标准 API 用于无法等待下一次夜间运行的新项目涓流。

其他提供商的类似思路

这种模式现已成为行业标准：Anthropic 的 Message Batches API 提供相同的 50% 折扣，采用类似的提交并轮询流程；Gemini 的批处理模式也是如此。如果您使用多个提供商，像 LiteLLM 这样的抽象层有助于保持批处理管道的统一——参见 LiteLLM vs Portkey for LLM gateways。定价和上限会变动——在提交预算预测之前，请核实每个提供商定价页面上的当前数字。

常见问题

提示缓存（prompt caching）在批处理中仍然有效吗？ 取决于提供商；如果在 50K 个请求中共享系统提示，则很重要——无论如何，结构化提示时稳定前缀优先（与我们的 KV 缓存深度解析 中相同的原则）。

我可以取消正在运行的批次吗？ 可以——client.batches.cancel(id)；已完成的请求会被计费，其余停止。

实际速度如何？ 通常远低于 24 小时窗口——但这是一个窗口，不是 SLA。如果“通常 2 小时，偶尔 23 小时”会破坏您的流水线，那么您需要标准 API。

---

*最后更新：2026 年 6 月。请根据 OpenAI 的文档核实当前定价和限制。*