你公司每天几千次 API 调用里，至少有一半根本不急——但它正按实时同步价、顶着抢手的额度池在跑。OpenAI 和 Anthropic 都有一条几乎没人认真用的"延迟折扣"通道：你把"立刻要结果"换成"24 小时内给我"，账单直接对折；再叠上提示词缓存，理论能把输入侧成本压到原价的 5%。这不是又一个省钱小技巧，而是 90% 团队每年白白多付的一笔"实时溢价税"。这篇拆清楚三层叠加怎么算账、哪些场景能上、哪些别碰。
## 一、第一层折扣：Batch API，官方明牌打对折
先看 OpenAI 自己的文档原话——Batch API 的卖点就三条：**比同步 API 便宜 50%、额度池独立且宽松得多、24 小时内出结果**。Anthropic 的 Message Batches API 同样是 50% off，逻辑一致。这不是促销，是常驻定价，2026 年仍在执行。
具体怎么算？据 2026 年 6 月一份第三方指南拆解，OpenAI 旗舰模型（按文中标注为 GPT-5.4 系）批处理价约为 **$1.25 / $7.50（输入/输出，每百万 token）**，正好是同步价的一半。Claude 那边同理：批处理把 Sonnet 级别的输入输出都按同步价的 50% 收。注意价格随版本波动，下单前去官方 pricing 页核一遍即可，但"对折"这个结构是稳的。
更关键的是——**批处理不是"打折的同步调用"，而是一个独立产品形态**。流程长这样：你把成千上万条请求写进一个 JSONL 文件 → 上传 → 触发 batch job → 轮询状态 → 下载结果文件。它天生就是为"我有一堆活，谁先做无所谓"设计的。OpenAI 文档明确把适用场景列为：跑 evals、大规模数据分类、给内容库批量做 embedding、排队跑离线视频渲染任务。
这里就藏着最大的认知差。
## 二、认知差核心：你的活，到底有多少"其实不急"？
大多数团队把 LLM 调用默认成"用户点一下、立刻弹结果"的实时交互模式。于是全部走同步 API，全部按实时价，全部挤同一个被限流的额度池。
但你停下来盘一下需求，会发现惊人比例的负载是**伪实时**：
- 每晚跑的评测集、回归测试——结果第二天看就行；
- 给几十万条商品/评论打标签、做情感分类——异步攒批，几小时后入库；
- 一次性给知识库切片、算 embedding——纯离线，跑一晚上没事；
- 周报、数据洞察、批量摘要生成——用户根本不是"这一秒"要；
- 客服工单的事后分类、质检打分——T+1 完全够用。
这些场景，你原本在为"24 小时内返回"这个你根本不需要的承诺，**多付 100%**。把它统称为"延迟溢价税"：你把一项本可异步的活当同步卖给自己。
一个简单的自检：**这条调用如果延迟到 6 小时后才出结果，业务会崩吗？** 如果不会，它就该进批处理通道，立刻对折。
## 三、第二层：批处理 × 提示词缓存 = 乘法效应，不是加法
真正的高手不是单独用 Batch，而是把多个折扣**乘起来**。提示词缓存的定价结构是：cache write 收基础输入价的 1.25 倍，cache read 只收 0.1 倍（即一折）。前缀缓存那条线我已经单独讲过，这里只看它与批处理怎么叠加。
假设你有一个固定的系统提示词 + 文档前缀（比如 10 万 token 的产品手册），每条 batch 请求都复用它：
- **同步 + 不缓存**：每条请求付 100% 输入价；
- **同步 + 命中缓存**：前缀部分付 10%，省约 90%（前提是前缀占比够大）；
- **批处理 + 不缓存**：付 50%；
- **批处理 + 命中缓存**：前缀部分付 50% × 10% = **5%**。
也就是说，对于"长固定前缀 + 大量重复结构化任务"这种最常见的批处理负载，理论输入侧能压到原价的 **5%**——也就是九五折的反面，砍掉 95%。上面那份第三方指南也明确点了这一点：Batch 叠 caching，整体省到 75% 起步，长前缀场景更狠。
注意：批处理请求之间能不能命中缓存，取决于时间窗口。提示词缓存默认 TTL 是 5 分钟，批处理任务如果几小时内跑完，靠同批次内的请求互相刷新缓存，命中率依然可观。如果担心窗口，Anthropic 有更长 TTL 的缓存档位可以配。这是一笔值得调参的账。
## 四、第三层：省钱只是其一，它还送你"额度自由"
容易被忽略的第二个红利——**批处理的额度池和同步 API 是分开的**。OpenAI 文档原话：批处理提供"a separate pool of significantly higher rate limits"（一个显著更宽松的独立额度池）。
这意味着什么？当你同步调用被 TPM/RPM 限流卡得只能排队、只能加钱升 tier 时，同样的活搬进 batch，限流约束几乎松一个量级。对很多"卡在额度墙"前、被迫升级订阅或买预留容量的团队，这一条省下的隐性成本可能比那 50% 还多。
所以批处理的完整价值是三段：**显性账单减半 + 叠缓存再打折 + 独立额度池让你不必为扩容付费**。很多人只看到第一段就停了。
## 五、什么时候该上，什么时候别碰
批处理不是万能药，乱套会上业务事故。用一张决策流判断：
```mermaid
flowchart TD
A["新进一条 LLM 调用"] --> B{"用户在屏幕前
等这一秒的结果吗?"}
B -- "是: 实时交互/对话" --> C["同步 API
别动,体验第一"]
B -- "否: 可异步" --> D{"结果能等 24h
且任务可成批聚合?"}
D -- "否: 秒级~分钟级延迟" --> E["同步 + 提示词缓存
吃 0.1x 读折扣"]
D -- "是: 真异步负载" --> F["进 Batch API
输入输出直接 50% off"]
F --> G{"有没有大段
固定前缀可复用?"}
G -- "有: 长系统提示/文档" --> H["叠加提示词缓存
前缀部分压到 ~5%"]
G -- "无: 每条都不同" --> I["享受 50% 即可
缓存帮不上忙"]
H --> J["理论上可省 75%~95%
下批前先 dry-run 验命中率"]
I --> J
C --> K["把高频重复 query
交语义缓存层拦截"]
```
**强烈适合**批处理的场景：跑 evals、批量打标/分类、知识库 embedding、事后质检、周报摘要、批量翻译/改写、离线视频渲染排队。这些共同特征是——量大、结构化、不面向终端用户实时等待、容错性高（个别失败可重跑）。
**千万别碰**的场景：面向 C 端用户的对话回复、实时搜索摘要、交互式代码补全、任何"用户盯着 loading 转圈"的链路。把 24 小时延迟怼到用户脸上，省下的钱补不回流失率。
**踩坑点**：批处理是"整批成功才返回结果文件"，中途某条失败会被标记 error 但不阻塞整批；要做好失败条目的重试与对账。另外 batch 不支持 `stream=true`，依赖流式输出的逻辑得改。
## 六、补一刀：路由层（RouteLLM / FrugalGPT）
如果你的负载里既有简单也有复杂的 query，再加一层"模型路由"能再省一道。思路是：用便宜小模型（Haiku / GPT mini / 本地 8B）先接所有请求，置信度不够再升级到 Sonnet / Opus。开源框架 RouteLLM（lm-sys 出品）和斯坦福的 FrugalGPT 都做过实测——在保持回答质量基本不掉的前提下，整体成本能砍 **50%~90%**。
路由是批处理正交的另一条省钱轴，两者可以叠加，但别一上来全堆上。先把"实时溢价税"这层最肥的吃掉，再考虑路由微调。这也呼应一条原则：**优化要分层、能复利，但每层都要先验证不伤质量再开下一层**。
## 七、信息差总结
| 维度 | 大多数人（你知道的） | 真正省钱的玩法（信息差） |
|---|---|---|
| 默认调用模式 | 所有请求都走同步 API | 先按"急不急"分流，异步负载进 Batch |
| 单次折扣认知 | 听说过 Batch 50% off | 知道 50% 是**基础**，能和缓存**相乘** |
| 叠加效应 | 优惠各自单独算 | Batch × Cache read = 输入侧压到 ~5% |
| 额度价值 | 只盯着省钱 | 独立额度池=不必为扩容买预留容量 |
| 前缀结构 | 长系统提示每条重算 | 固定前缀配缓存，批内互相刷新 TTL |
| 模型选择 | 全用最贵旗舰 | 加 RouteLLM 路由层，简单 query 走小模型 |
| 失败处理 | 同步报错就重试 | batch 整批返回，按 error 字段对账重跑 |
一句话信息差：**别人按"实时价 × 全量"付钱，你按"异步价 × 缓存命中"付钱，中间隔着一个数量级。**
## 八、行动指南（今晚就能做）
1. **盘负载**：把过去 7 天所有 API 调用日志导出，打一个标签——"这条如果 24h 后才出结果，业务会崩吗？"不会的全部标黄，这就是你的 Batch 候选池。多数团队标完发现占比 30%~60%。
2. **挑一个试点**：从标黄池里选**最不敏感**的场景（通常是每晚跑的 eval 或数据打标），先拿 1% 流量切到 Batch 跑一周，对比账单和质量差异。
3. **改造调用代码**：把同步 `chat.completions.create` 的循环，改成"攒批 → 上传 JSONL → 触发 job → 轮询 → 解析结果文件"。OpenAI/Anthropic SDK 都有现成 batch 封装，参考官方 quickstart，半天能上线。
4. **配提示词缓存**：试点场景若有固定大前缀，给 batch 请求加上 cache_control，dry-run 一批看 cache_read_tokens 占比，命中率低于 30% 说明前缀结构要调。
5. **建对账脚本**：批结果文件里按 status 逐条核对，error 项自动入重试队列，别让静默失败腐蚀数据质量。
6. **看账单曲线**：试点稳定后，把标黄池的剩余流量逐步迁过去，每周看成本曲线斜率。预期这部分负载账单砍掉 60%~90%。
7. **再谈路由**：实时通道剩下的负载，评估是否值得加 RouteLLM，按 query 复杂度分发——这是下一阶段的优化，别和 Batch 这步混在一起搞。
预算排序上：**先吃延迟溢价税（Batch）→ 再吃缓存乘法效应 → 再吃额度池红利 → 最后上模型路由**。每一层都先验证质量不掉，再叠下一层，避免一次改太多定位不了回归。
## 参考来源
- OpenAI Batch API 官方文档（50% 折扣、24 小时、独立额度池）：
- OpenAI 定价页（核最新批处理价）：
- Anthropic Message Batches + 提示词缓存文档： 、
- RouteLLM（lm-sys 开源模型路由框架）：
- 第三方 Batch + Caching 叠加指南（GPT-5.4 批处理价 $1.25/$7.50、75% 节省示例，2026-06）：
> ⚠️ 价格随模型版本和档位波动，本文数字来自 2026 年 6-7 月公开信息，落地前请以官方 pricing 页为准；缓存命中率强烈依赖你的前缀结构，先 dry-run 再放量。
---
> 本文由「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 等场景全覆盖。
