如果你每天要喂给模型成千上万条非实时的请求——客服邮件分类、商品描述生成、数据集标注、文档摘要——你大概率正在用同步 API 实时调用，按原价一分不少地付钱。但 OpenAI、Anthropic、Google 三家从 2024 年起就内置了一个「五折开关」：Batch API（批量异步接口）。你只要把请求打包、接受「24 小时内出结果」（通常几十分钟到几小时就跑完），账单直接对半砍。今天这篇拆的是这条确定性最强、却最少人用的省钱暗线：什么是 Batch API、哪些任务该上、怎么从同步无痛迁移、有哪些隐藏坑，以及如何叠加 prompt caching 把账单从五折再压到接近一折。读完你能立刻在自己的后端加一个 async=true 的开关，下个月账单先降一半。

一、核心认知：你在为「实时」付一笔不该付的税

同步 API 的定价里，隐含着一项「即时算力调度税」。provider 必须在毫秒级把 GPU 算力预留给你，高峰期还要抢占别人的资源，所以原价本质上是在卖「实时算力的优先级」。

但你手头 80% 的批量活儿根本不需要实时：昨晚积压的 5 万条评论情感分析、今早要跑的评测集、每周一次的报告批量摘要——这些任务晚出 10 分钟还是晚出 10 小时，业务完全不care。Batch API 的本质就是把「延迟容忍」当货币花出去：provider 把这些请求塞进低峰期的空闲算力慢慢跑，作为交换，给你 50% 折扣。三家定价惊人地一致——都是直接半价，不是阶梯、不是优惠券，是写在定价页上的常规价。

信息差就在这：绝大多数中国团队的后端代码里，chat.completions.create 一把梭，从早到晚同步打，一个月烧掉几万块，其中至少一半本可以白捡回来。

二、三家 Batch API 横向对比

三家逻辑完全同构，会一个就会另两个。区别只在文件格式和上传姿势，下面统一讲。

三、决策树：你的任务到底该不该上 Batch

不是所有请求都该异步。判断标准只有一个词——延迟容忍度。

flowchart TD
    A[新到一批模型请求] --> B{用户在等结果吗?}
    B -- 是, 秒级返回 --> C[必须同步 API<br/>聊天框/Agent 交互/实时翻译]
    B -- 否, 可等 --> D{批次规模 ≥ 50?}
    D -- 否, 零散几条 --> E[同步即可<br/>Batch 接入成本不划算]
    D -- 是, 成批 --> F{可接受 24h 内返回?}
    F -- 否, 需要 1 分钟内 --> G[同步 API<br/>或流式]
    F -- 是 --> H[✅ 上 Batch API<br/>立刻省 50%]

    H --> I{有固定 system prompt / 长文档?}
    I -- 是 --> J[再叠加 prompt caching<br/>命中部分压到 1/10]
    I -- 否 --> K[纯 Batch 5折已最优]

适合 Batch 的典型场景（中国开发者高频踩中）： - 客服/工单批量分类与摘要：夜间把当天工单打包，次日早上看结果 - 电商商品多语言描述生成：新一批 SKU 上架前批量产出 - 评测集跑分：SWE-bench、MMLU、自家业务 benchmark - 日志/评论情感分析：T+1 的 BI 看板数据 - 数据集标注与蒸馏：用大模型给小模型造训练数据 - 文档库问答预处理：对一批 PDF 先做摘要/分块

绝对不能上 Batch 的：聊天回复、Agent 工具调用的实时循环、实时翻译字幕、任何用户盯着 loading 图标等的那条请求。

四、实战迁移：从同步到 Batch 的三步

以 Anthropic 为例（OpenAI/Google 几乎一样的套路）。原来你的同步代码长这样：

# 同步：每条实时调用，原价
for item in items:
    resp = client.messages.create(
        model="claude-sonnet-4-5",
        max_tokens=512,
        messages=[{"role":"user","content": item["text"]}],
    )

迁到 Batch，三步：

第 1 步：把请求写成 JSONL，每行一个独立请求

{"custom_id":"job-001","params":{"model":"claude-sonnet-4-5","max_tokens":512,"messages":[{"role":"user","content":"第一条内容..."}]}}
{"custom_id":"job-002","params":{"model":"claude-sonnet-4-5","max_tokens":512,"messages":[{"role":"user","content":"第二条内容..."}]}}

注意每个请求带一个 custom_id——这是你后续对账、定位失败请求的唯一锚点。

第 2 步：提交批次，拿到 batch_id

batch = client.messages.batches.create(requests=requests_list)
print(batch.id)   # 存下来，轮询用

第 3 步：轮询状态，完成后下载结果

状态机从 in_progress → canceling/ended，ended 后你去拉每条请求的结果（成功/失败分开标记）。OpenAI 是直接给你一个结果 JSONL 文件下载；Anthropic 是逐条 retrieve 或整体拉。

关键点：部分失败不影响全局。一批 10 万条里第 3.7 万条因为 prompt 太长报错，其余 9.9 万多条照常返回。这比你自己写多线程跑同步还要稳——provider 帮你做了重试、限流、并发控制。

五、隐藏坑：用了 Batch 才会知道的五件事

1. 不能用 stream（流式）。Batch 本质是「跑完打包」，没有逐 token 流，需要实时打字效果的场景请回同步。
2. 调试反人类。同步出错你立刻看到报文；Batch 出错你要等批次跑完、再去结果文件里找那条 error 记录。建议先用 10 条小批跑通 prompt，再上量。
3. SLA 是 24 小时上限，不是承诺。多数时候几十分钟返回，但 provider 不保证快。如果你的业务是「最迟 2 小时」，别拿 24h SLA 当 2h 用。
4. 配额仍计入速率限制的总量。Batch 帮你绕过的是「并发/TPM 瞬时限流」，不是账户总额度。月度上限该多少还是多少。
5. 改需求要趁早。批次一旦 in_progress，只能整体 cancel，不能改某一条。提交前用 custom_id 设计好幂等。

六、终极组合拳：Batch 五折 × 缓存一折 = 接近四分之一价

这是真正拉开身价的玩法。三家都支持 prompt caching（OpenAI 自动、Anthropic 显式、Gemini 隐式），缓存命中部分的输入 token 约按 0.1 倍计价，而且缓存折扣与 Batch 五折可以叠加。

典型场景：你有一段固定的 3000 token 的 system prompt（业务规则 + few-shot 示例 + 输出格式约束），跑 10 万条客服分类。

• 同步无缓存：3000 × 10 万 = 3 亿 input token，全价
• Batch 无缓存：3 亿 input token × 0.5 = 半价
• Batch + 缓存：第 1 次全价建缓存，之后 9.999 万次命中的 3000 token 按 ~0.1× 计，再乘 Batch 的 0.5 ≈ 0.05×，即原价的二十分之一

那段重复的 system prompt 从「最贵的部分」瞬间变成「最便宜的部分」。前提是：把可缓存内容放最前面、用 cache_control 标记（Anthropic）、批次尽量在缓存 5 分钟/1 小时 TTL 内连续打。

七、真金白银的账本对比

以「每天 10 万条客服摘要，每条约 500 input + 300 output token，用 Claude Sonnet 级模型（输入约 \$3/M、输出约 \$15/M，以官网实时价为准）」为例：

一句 async=true 加一段缓存标记，月省一万三千刀。中国团队这个量级的批处理任务随处可见，但账单基本都按第一行原价在烧。

八、按预算选方案

• 零预算/个人开发者：用 Gemini API 免费额度跑小批量同步即可，量上来再考虑 Batch；Anthropic 注册后有少量试用额度可验证 Batch 流程。
• 中小团队（月 API 账单 $500–$5k）：把所有 T+1 批处理任务迁移到 Batch，预计立省 50%。优先迁移的是评测、标注、摘要这三类。
• 大体量（月账单 $5k+）：Batch + prompt caching + 路由分层（简单任务下沉到便宜模型）三件套全开，目标把单位成本压到原价的 20% 以内，并给 Batch 任务写监控（成功率、单条失败告警）。

信息差总结

行动指南

1. 今晚盘点：列出后端所有非用户实时等待的模型调用，标出延迟容忍的批处理点。
2. 挑一个试点：选一个每天跑、量稳定（如夜间摘要/评测）的任务，先用 100 条小批跑通 JSONL 提交→轮询→取结果全流程。
3. 加缓存标记：把固定 system prompt 提到最前并开 cache_control，对比命中前后的成本。
4. 写监控：成功率、失败重试、单批耗时，避免「省了钱却不知道哪条丢了」。
5. 下月对账：用同一任务跑前后两个月账单对比，量化省了多少，再决定要不要推广到全部批处理。

参考来源（请以官网实时定价为准）： - OpenAI Batch API 指南：https://platform.openai.com/docs/guides/batch - Anthropic Message Batches 文档：https://docs.anthropic.com/en/docs/build-with-claude/batch-processing - Anthropic Prompt Caching 文档：https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching - Google Gemini Batch API：https://ai.google.dev/gemini-api/docs/batch-mode - Vertex AI 批量预测：https://cloud.google.com/vertex-ai/docs/batch-predictions

本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护。 聚焦5G/6G核心网、3GPP标准、AI工具实战。知识星球「51学通信」提供深度技术答疑和行业洞察。

[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。