国内技术圈聊"省 token 钱"，十有八九停在"换个便宜的模型"或者"把 prompt 写短一点"。但海外生产环境里真正在跑大流量的团队，省钱的核心根本不是抠 prompt，而是把官方本来就给的三道折扣叠加起来用。这三道折扣单独看每个都能砍掉一半以上，叠加之后，你的输入 token 能从原价一路砍到只剩 5%——也就是说同样一段长 prompt，别人花 100 块，你花 5 块。
这套打法在国内几乎没人系统讲过，因为大部分人连第一道折扣的开关都没打开。今天就把它拆透：Prompt Caching（官方缓存）、Batch API（批量半价）、语义缓存+智能路由，三道闸怎么开、怎么叠加、踩什么坑。
很多人不知道，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% 输入成本。
这是被严重低估的一道闸。OpenAI、Anthropic、Google 全部提供 Batch API，统一规则：异步提交、24 小时内返回、价格直接 50% off。
适用场景非常明确：任何不需要"秒级实时响应"的任务。比如：
操作上三家都差不多：把请求写成 JSONL 文件（每行一个请求），上传，拿一个 batch ID，几小时到 24 小时后下载结果。OpenAI 单批最多 50,000 个请求，Anthropic 单批 100,000 个。
很多人对 Batch 最大的误解是"24 小时太慢"。但实际生产里，大量后台任务本来就是 T+1 交付的——报表、标签、SEO 内容、数据清洗，用户根本不在乎你是 1 秒出还是 1 小时出。把这类任务从实时 API 迁到 Batch，什么都不用改逻辑，直接账单砍半。
真正的杀手锏是这三道折扣可以叠加。来看一笔账，以一个长上下文 RAG 任务为例，基础输入价设为 100%：
flowchart LR
A["基础输入价<br/>100%"] -->|"+官方Prompt缓存<br/>缓存读 90% off"| B["10%"]
B -->|"+Batch API<br/>再 50% off"| C["5%"]
C -->|"+语义缓存命中<br/>直接返回缓存答案"| 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。也就是说，你完全可以这样设计一个离线批处理流水线：
cache_control 标记好结果就是：你以为在跑"全量长上下文"的昂贵任务，实际只为那 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） 解决的是"不是所有请求都需要最贵的模型"。思路是：简单请求路由给便宜小模型，只有难题才升级给大模型。一个典型级联：
flowchart TD
Q[请求进入] --> R{路由器判断难度}
R -->|简单: 分类/抽取/格式化| S[小模型<br/>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% 的请求本来就是简单活。
| 维度 | 大多数人的做法（你在亏） | 海外在用的做法（信息差） |
|---|---|---|
| 长 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 成本战场上最朴素也最被忽视的差距。
本文由「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 等场景全覆盖。