如果你写过一个会反复调用大模型的 Agent——比如带工具定义、带检索文档、带系统提示词的客服机器人或代码助手——你大概率踩过这个坑:每一次调用,都把 5 万到 10 万 token 的固定前缀原封不动重新发给模型,然后按全价计费。
而模型供应商其实早就给你留了一个折扣口子:只要这段前缀一字不差,命中后读取只收一折(90% off)。这个机制叫原生提示词缓存(prompt caching / context caching),它和你可能听过的"语义缓存"是两码事——后者是应用层模糊匹配、还会返回旧答案,前者是供应商 KV 缓存层级的硬折扣、质量零损耗。
今天这轮情报,就把这套"原生折扣体系"完整拆给你:Anthropic、OpenAI、Gemini 三家的缓存机制,叠加 Batch API 的五折异步通道,再配上国内 DeepSeek/GLM 的白嫖玩法,算一笔实打实的账。
下面这段伪代码,是九成 RAG/Agent 项目的真实长相:
for msg in conversation:
response = client.messages.create(
model="claude-sonnet-4-6",
system=[{"type": "text", "text": SYSTEM_PROMPT}], # 固定,2万 token
messages=[
{"role": "user", "content": retrieved_docs}, # 固定,4万 token
{"role": "user", "content": msg} # 变化,500 token
]
)
注意到了吗?真正每次变化的只有最后那条用户消息,前面 6 万 token 的前缀(系统提示 + 工具定义 + 检索文档)每次都一模一样。但 API 照样按 6 万 token 的全价计费。
以 Claude Sonnet 4.6 输入价 $3/百万 token 算,一天 1000 次调用:
那 $178.5 的差价,就是因为你没开原生缓存。
这是国内开发者最大的误区。很多人听说过"缓存能省钱",第一反应是搭个 Redis 做语义缓存(把相似问题的答案存起来)。但这两者完全不在一个层级:
| 维度 | 原生缓存(Prompt/Context Caching) | 语义缓存(Semantic Cache) |
|---|---|---|
| 工作层级 | 供应商 KV 缓存层 | 你自己的应用层 |
| 命中条件 | 前缀逐字节完全相同 | 查询语义相似(向量距离阈值) |
| 命中后行为 | 只跳过前缀计算,照常重新生成答案 | 直接返回缓存的旧答案 |
| 质量风险 | 零(每次都是新输出) | 高(可能返回过时/错误答案) |
| 折扣力度 | 命中读取 90% off | 100% off(但命中率通常 20%-40%) |
| 搭建成本 | 加一行参数 | 自己维护向量库 + 阈值调优 |
一句话总结:语义缓存赌的是"问题相似",原生缓存赌的是"前缀相同"。前者省的是整次调用,后者省的是重复计算——而且不牺牲任何回答质量。
实战中两者可以叠加:固定前缀走原生缓存打一折,相似查询再走语义缓存。但绝大多数人连第一层都没开。
Claude 系列的缓存需要你显式声明缓存断点,但折扣力度是全场最猛的:
开启方式只需在对应内容块加一个字段:
{
"role": "user",
"content": [
{
"type": "text",
"text": "...这段固定的长文档...",
"cache_control": {"type": "ephemeral"} // 5分钟缓存
// 想要1小时:{"type": "ephemeral", "ttl": "1h"}
}
]
}
谁该用:系统提示长、工具定义多、RAG 文档固定的 Agent。Claude Code、Cursor 这类工具内部早已大量使用,所以你能感觉它们又快又省。
OpenAI 的缓存是零配置自动开启的:
缺点是折扣只有五折(不如 Claude 的一折猛),且你无法手动控制断点位置,完全交给系统。但胜在"什么都不用做就生效"。
Google 的玩法最灵活也最复杂:
适用判断:文档会在较长时间窗口内被高频复用(比如一个知识库被连续查询几小时),存储费才划算;如果只是几分钟内复用几次,存储费会吃掉折扣。
国内玩家更幸福,因为 DeepSeek 的上下文缓存是自动的、免费的、力度更狠:
GLM(智谱)同样在 API 层提供上下文缓存支持,对国内出海项目和成本敏感的本地部署极其友好。
回到第一节的例子,我们把那段 6 万 token 的固定前缀接上 Anthropic 缓存,重算一遍(假设缓存 5 分钟内持续命中,首次写入后基本不掉):
| 项目 | 无缓存 | 开缓存(5分钟TTL) |
|---|---|---|
| 前缀写入(首条) | — | 60K × $3.75/M ≈ $0.225 |
| 前缀读取(999条) | 60K×999×$3/M = $179.8 | 60K×999×$0.30/M ≈ $18.0 |
| 用户查询(变化部分) | $1.5 | $1.5 |
| 单日合计 | ≈ $181 | ≈ $19.7 |
| 单月(30天) | ≈ $5,430 | ≈ $591 |
单月省下约 $4,800,降幅 89%。 而且这条收益是纯利润——回答质量零下降,因为模型每次都重新生成,只是省了前缀的重复计算。
如果再用 1 小时 TTL(写溢价 2×)应对低频但跨度大的场景,写入成本翻倍但能撑住更长间隔,跨小时复用同样划算。
flowchart TD
A[收到一次模型请求] --> B{前缀是否超过1024 token?}
B -- 否 --> Z[直接全价调用<br/>不值得缓存]
B -- 是 --> C{前缀是否每次相同?}
C -- 否, 动态拼接 --> D[改造为固定前缀+可变后缀]
D --> C
C -- 是 --> E{5分钟内会被复用吗?}
E -- 是 --> F[开 5分钟TTL 缓存<br/>写入1.25x 读取0.1x]
E -- 否 --> G{1小时内会被复用吗?}
G -- 是 --> H[开 1小时TTL 缓存<br/>写入2x 读取0.1x]
G -- 否 --> I{需要实时响应吗?}
I -- 否, 可等数小时 --> J[改走 Batch API<br/>全单五折 50% off]
I -- 是 --> Z
F --> K[缓存命中只收一折 ✅]
H --> K
J --> L[异步批处理打五折 ✅]
如果你的任务不需要实时返回——批量打标签、文档摘要、数据集清洗、内容审核——三大供应商都提供一个被严重低估的接口:Batch API。
| 任务类型 | 实时 API 单价 | Batch API 单价 | 折扣 |
|---|---|---|---|
| Sonnet 实时调用 | $3/M 输入 | — | 基准 |
| Sonnet 批量调用 | — | $1.5/M 输入 | 50% off |
| Sonnet 批量+缓存读 | — | $0.30/M 输入(命中部分) | 90% off |
实战节奏:白天实时业务走原生缓存(用户不能等),晚上把当天积压的非紧急任务(日志分析、用户反馈分类)打包丢进 Batch API 过夜跑。同一份账单,两个折扣各管一摊。
很多人兴冲冲开了缓存,账单却没降,基本都是这几个原因:
前缀不是真·固定:你在前缀里塞了时间戳、用户 ID、随机数,导致每次前缀都变,永远 miss。正确做法:把可变部分挪到请求末尾,前缀保持纯静态。
TTL 过期:5 分钟缓存,结果你的请求间隔超过 5 分钟,缓存早被清了。低频场景换 1 小时 TTL,或干脆用 DeepSeek 这种自动长缓存。
没到最低长度:前缀不足 1024 token,缓存根本不会触发。把系统提示+工具定义+文档拼到一起才够格。
断点放错位置:Anthropic 最多 4 个断点,要放在"固定边界"上(比如系统提示结束处、文档结束处),而不是随手加。
Gemini 存储费吃掉收益:缓存对象存太久、调用太少,小时存储费反而比折扣高。算清楚"调用频率 × 折扣节省 > 存储费"再开。
以为自动缓存万事大吉:OpenAI 虽然自动缓存,但如果你用 SDK 时把固定内容放在了 messages 中间、前面还夹了可变历史,前缀匹配照样失败。
| 认知层级 | 大众认知 | 信息差认知 |
|---|---|---|
| 缓存省钱 | = 自己搭 Redis 语义缓存 | 原生缓存是供应商硬折扣,零质量风险 |
| Anthropic 缓存 | 没听说过 | 命中读取 90% off,加一行 cache_control |
| 缓存写入 | 以为免费 | 5分钟 TTL 写溢价 25%,1小时溢价 100% |
| OpenAI 缓存 | 以为要配置 | 全自动 50% off,但前缀必须真固定 |
| Batch API | 没用过 | 非实时任务一律走异步,24h 内 50% off |
| 折扣叠加 | 单独用 | 缓存读 + Batch 可叠加,理论 90% off × 50% |
| 国产方案 | 只知道便宜 | DeepSeek 缓存命中 95% off,写入零溢价且自动 |
审计前缀:把你最高频的那个 API 调用拎出来,看 system + 工具定义 + 文档占多少 token。超过 1024 token?就是省钱的肥肉。
拆分固定/可变:把请求重构成"纯静态前缀 + 动态后缀"。任何会变的东西(时间、ID、用户输入)一律放到最后。
按供应商打折扣开关:
- 用 Claude?给固定前缀加 cache_control,高频用 5 分钟 TTL,跨小时用 1 小时 TTL
- 用 OpenAI?确认前缀真固定,自动缓存自动生效
- 用 Gemini?算清存储费再创建 Cache 对象
- 用 DeepSeek/GLM?什么都不用做,确认调用集中在高峰期更容易命中磁盘缓存
回收非实时任务:把日志分析、批量标注、内容审核这类"等得起"的任务,从实时调用迁到 Batch API,单子直接打五折。
一周后回看账单,你会看到那条"固定前缀"的成本线几乎被削平——这就是原生缓存给你留的、却一直没人告诉你的折扣口子。
本文由「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 等场景全覆盖。
