# 三个折扣能叠加：API账单砍到5%
国内技术圈聊"省 token 钱"，十有八九停在"换个便宜的模型"或者"把 prompt 写短一点"。但海外生产环境里真正在跑大流量的团队，省钱的核心根本不是抠 prompt，而是**把官方本来就给的三道折扣叠加起来用**。这三道折扣单独看每个都能砍掉一半以上，叠加之后，你的输入 token 能从原价一路砍到只剩 5%——也就是说同样一段长 prompt，别人花 100 块，你花 5 块。
这套打法在国内几乎没人系统讲过，因为大部分人连第一道折扣的开关都没打开。今天就把它拆透：**Prompt Caching（官方缓存）、Batch API（批量半价）、语义缓存+智能路由**，三道闸怎么开、怎么叠加、踩什么坑。
## 一、第一道闸：Prompt Caching——官方白送的 90% off
很多人不知道，OpenAI、Anthropic、Google 三家都给"重复 prompt"内置了缓存折扣，而且**机制完全不同**，用错等于白送钱。
**OpenAI 是"自动的，你什么都不用做"。** 只要你的 prompt 里有超过 1024 token 的重复前缀（比如固定的系统提示、文档上下文、few-shot 示例），OpenAI 后台会自动缓存，命中的那部分输入 token 直接按 **50% off** 计费。你代码一行都不用改。问题是——90% 的人因为不知道，根本没意识去把"可复用的上下文"放到 prompt 最前面，导致每次请求的前缀都不一样，缓存永远命中不了。
**Anthropic 是"手动的，你要主动打标记"。** Claude 用的是 `cache_control` 参数，你要在 API 请求里显式标出哪几段要缓存（最多 4 个断点）。它的折扣更狠：
| 操作 | 计费倍率 | 相对原价 |
|------|---------|---------|
| 基础输入 | 1.0x | 100% |
| 写入缓存（首次） | 1.25x | **+25%**（更贵） |
| 读缓存（5分钟 TTL） | 0.1x | **90% off** |
| 读缓存（1小时 TTL，扩展缓存） | 0.1x，但写入 2.0x | 90% off |
注意那个坑：**第一次写缓存是要多付 25% 的**。所以缓存不是无脑开，而是有"回本点"。算一笔账：写一次缓存花 1.25x，之后每次读只花 0.1x。如果你这段上下文会被复用 **2 次以上**，缓存就开始净赚；复用 5 次以上，省的就是几倍量级。判断标准很简单：**同一段长上下文，你的应用在一次会话里或者 5 分钟内会反复喂给模型 ≥2 次，就值得缓存。**
Google Gemini 的 Context Caching 走的是另一条路——按"小时"计 TTL，适合那种"一份超大文档喂一整天"的场景。
**国内用户最大盲区**：很多人在用 Claude/GLM 做长文档问答、RAG、Agent 多轮调用时，每次都把整个系统提示和知识库 context 重新塞一遍，从不打 `cache_control`。一个 50000 token 的知识库上下文，不缓存每次都全价，缓存后每次只付 1/10。一个高频 RAG 服务，光这一项就能砍掉 60-80% 输入成本。
## 二、第二道闸：Batch API——不急的活直接半价
这是被严重低估的一道闸。**OpenAI、Anthropic、Google 全部提供 Batch API，统一规则：异步提交、24 小时内返回、价格直接 50% off。**
适用场景非常明确：**任何不需要"秒级实时响应"的任务**。比如：
- 夜间批处理：白天攒一堆分类、抽取、打标签的请求，半夜一起跑
- 数据集处理：几万条评论做情感分析、几万份简历做结构化
- 内容生成：批量生成商品描述、SEO 文章、邮件草稿
- 评估和测试：跑 benchmark、做 LLM-as-judge 评分
操作上三家都差不多：把请求写成 JSONL 文件（每行一个请求），上传，拿一个 batch ID，几小时到 24 小时后下载结果。OpenAI 单批最多 50,000 个请求，Anthropic 单批 100,000 个。
很多人对 Batch 最大的误解是"24 小时太慢"。但实际生产里，大量后台任务本来就是 T+1 交付的——报表、标签、SEO 内容、数据清洗，用户根本不在乎你是 1 秒出还是 1 小时出。把这类任务从实时 API 迁到 Batch，**什么都不用改逻辑，直接账单砍半**。
## 三、三道闸叠加：输入 token 砍到 5%
真正的杀手锏是**这三道折扣可以叠加**。来看一笔账，以一个长上下文 RAG 任务为例，基础输入价设为 100%：
```mermaid
flowchart LR
A["基础输入价
100%"] -->|"+官方Prompt缓存
缓存读 90% off"| B["10%"]
B -->|"+Batch API
再 50% off"| C["5%"]
C -->|"+语义缓存命中
直接返回缓存答案"| D["≈ 0%"]
style A fill:#ff6b6b,color:#fff,stroke:#c92a2a
style B fill:#feca57,color:#000,stroke:#f59f00
style C fill:#4dabf7,color:#fff,stroke:#1971c2
style D fill:#51cf66,color:#fff,stroke:#2f9e44
```
**核心数学**：缓存读是 0.1x，Batch 是在此基础上再 ×0.5，所以**一段命中缓存的输入 token，放进 Batch 跑，最终费率 = 0.1 × 0.5 = 0.05x，也就是原价的 5%，砍掉 95%**。
这不是理论，是厂商明确支持的叠加方式。Anthropic 的 Message Batches 文档里写明支持 prompt caching，OpenAI 的 Batch 也支持自动 prefix caching。**也就是说，你完全可以这样设计一个离线批处理流水线**：
1. 把固定的超大上下文（系统提示 + 文档 + few-shot）用 `cache_control` 标记好
2. 把这些请求攒成 JSONL，通过 Batch API 提交
3. 每个请求里只有"变化的那个小问题"是全价，其余海量上下文既享缓存 90% off，又享 Batch 50% off
结果就是：你以为在跑"全量长上下文"的昂贵任务，实际只为那 5% 的缓存价买单。一个原本月烧 8000 美元的批量文档处理服务，迁到这套组合后往往能压到几百美元量级。
## 四、第三道闸（进阶）：语义缓存 + 智能路由
前两道是官方折扣，第三道是你在自己这边加的"中间层"。
**语义缓存（Semantic Caching）** 解决的是"prompt 文字不完全一样，但问的是同一件事"。比如"北京天气怎么样"和"今天北京天气如何"，文字不同，前缀缓存命不中，但语义一样，答案完全可以复用。做法是：把每个 query 转成 embedding，存进向量库；新 query 进来先算 embedding，找相似度高于阈值的命中，直接返回缓存的答案，**0 token 费用**。
主流工具：开源的 **GPTCache**（zilliztech 出品）、LangChain 内置的 cache、或者托管方案 **Helicone / Portkey** 自带 caching 层。语义缓存的关键风险是"假阳性"——相似度卡太高会漏掉该命中的，卡太低会返回错误答案。生产里一般把阈值设在 0.92-0.95 之间，并对"事实类、查询类"任务开缓存，对"生成类、创作类"任务关掉。
**智能路由（Model Routing / Cascade）** 解决的是"不是所有请求都需要最贵的模型"。思路是：简单请求路由给便宜小模型，只有难题才升级给大模型。一个典型级联：
```mermaid
flowchart TD
Q[请求进入] --> R{路由器判断难度}
R -->|简单: 分类/抽取/格式化| S[小模型
GLM-Flash / Haiku / 4o-mini]
R -->|中等: 总结/改写| M[中档模型]
R -->|复杂: 推理/代码/Agent| L[大模型]
S --> Cost1[成本 ~5%]
M --> Cost2[成本 ~30%]
L --> Cost3[成本 ~100%]
style S fill:#51cf66,color:#fff
style Cost1 fill:#51cf66,color:#fff
style L fill:#ff6b6b,color:#fff
style Cost3 fill:#ff6b6b,color:#fff
```
路由判断怎么做？三条路：**(1)** 基于规则——按任务类型/输入长度/token 数硬路由；**(2)** 用一个小模型当"分诊台"先判断难度（成本极低）；**(3)** 先让小模型答，用置信度或一个 judge 模型判断答得行不行，不行再升级——这就是 RouteLLM（lmsys 开源）和 LiteLLM Router 的核心思路。实测下来，配比合理的话，**省 60-80% 成本，质量损失通常 <5%**，因为 80% 的请求本来就是简单活。
## 五、信息差总结：你知道的 vs 别人在用的
| 维度 | 大多数人的做法（你在亏） | 海外在用的做法（信息差） |
|------|----------------------|----------------------|
| 长 prompt 重复 | 每次全价重发 | 打 `cache_control`，缓存读 90% off |
| 离线批处理 | 走实时 API 全价 | 丢进 Batch API，直接 50% off |
| 折扣叠加 | 至多用 1 道 | 缓存+Batch 叠加，输入砍到 5% |
| 相似问题 | 重复调用烧 token | 语义缓存，命中即 0 成本 |
| 模型选择 | 全程用最贵的大模型 | 智能路由，简单活给小模型 |
| 缓存回本 | 不知道写缓存要 +25% | 知道复用 ≥2 次才开，精确控成本 |
## 六、行动指南：今天就做这三件事
**第一步（5 分钟见效）**：审视你的应用里有没有"固定的长系统提示/知识库 context 被反复重发"。如果有，立刻给 Claude 端打 `cache_control` 标记（OpenAI 端把可复用部分移到 prompt 最前缀，自动生效）。这是 ROI 最高的一步，多数人改完当天账单就降一截。
**第二步（半天工作量）**：盘点所有"非实时"任务——分类、打标、批量生成、评估、数据清洗。凡是能容忍 24 小时延迟的，全部迁到 Batch API。逻辑几乎不用改，只是把同步调用改成攒 JSONL + 异步取结果。账单当场砍半。
**第三步（进阶，1-2 周）**：在前面两道闸之上加语义缓存层和路由层。先用开源的 GPTCache + LiteLLM 跑起来，观察命中率，把路由规则调到"80% 流量走小模型"。这一步做完，你的单位成本基本就逼近行业最低水位。
**一条避坑提醒**：别只盯单价而忽略"缓存写入溢价"。如果你的某个 prompt 永远只调用一次（比如一次性数据迁移），打缓存反而更贵（多付 25%）。缓存的本质是"用一次写入的溢价，换后续 N 次读取的暴省"，只在 N≥2 的场景才划算。
记住这个心智模型：**官方给的折扣是"默认关闭的开关"，谁主动打开谁就拿到信息差红利**。绝大多数人付的是"原价"，而少数人叠加三道闸后付的是"5% 价"——同一个模型、同样的质量，账单差 20 倍。这就是 2026 年 AI 成本战场上最朴素也最被忽视的差距。
## 参考来源
- OpenAI Batch API 官方文档（50% 折扣，24h 异步）：https://platform.openai.com/docs/guides/batch
- OpenAI Prompt Caching（自动前缀缓存，输入 50% off）：https://platform.openai.com/docs/guides/prompt-caching
- Anthropic Prompt Caching 文档（cache_control，读 90% off / 写 1.25x）：https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching
- Anthropic Message Batches（批量 50% off，支持叠加缓存）：https://docs.anthropic.com/en/docs/build-with-claude/batch-processing
- GPTCache 开源语义缓存（zilliztech）：https://github.com/zilliztech/GPTCache
- RouteLLM 开源模型路由（lmsys）：https://github.com/lm-sys/RouteLLM
---
> 本文由「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 等场景全覆盖。
