Prompt缓存实战：把大模型API账单砍掉一半的工程技巧
从Anthropic、OpenAI到国产大模型，系统讲解Prompt Caching的原理、命中条件与工程化落地，附成本测算表与常见踩坑清单。
为什么你的API账单降不下来？
2026年，几乎所有主流大模型都支持了 Prompt Caching（提示缓存），但真正用好它的团队却不多。很多开发者的做法是”尽量把system prompt写短一点”，这其实是抓错了重点——真正省钱的地方在于复用，而不是压缩。
先看一组真实数据：一个典型的客服Agent，system prompt + 工具定义 + 知识库片段合计约 4000 tokens，每次对话平均 6 轮。按 Anthropic 的定价，缓存命中的输入 token 价格通常只有未命中的 10%。如果全量命中，单次对话的输入成本可以降低 70% 以上。
Prompt Caching 到底缓存了什么？
缓存的对象不是”回答”，而是前缀的 KV Cache（注意力键值对）。模型在处理输入时，会对每个 token 计算出键值矩阵。如果你两次请求的前 N 个 token 完全一致，第二次就可以直接复用第一次算好的 KV Cache，跳过这部分前向计算。
这带来两个关键结论：
- 前缀必须逐字节一致。哪怕多一个空格、换一个时间戳，缓存就失效了。
- 缓存有生命力。Anthropic 的缓存默认 TTL 为 5 分钟，可续期到 1 小时；OpenAI 的缓存是”自动的”，命中前 1024 tokens 左右的稳定前缀即生效。
一个反直觉的结论：把易变的放到后面
很多人的 prompt 结构是这样的：
[当前时间: 2026-09-26 15:03:22]
[用户ID: u_88213]
[system prompt... 2000 tokens]
[工具定义... 1500 tokens]
[对话历史...]这样写，缓存几乎永远无法命中，因为第一行的”当前时间”每次都在变，导致后面 3500 tokens 的前缀全部作废。
正确做法是把结构改成”稳定内容在前，易变内容在后”：
[system prompt... 2000 tokens] # 稳定，缓存
[工具定义... 1500 tokens] # 稳定，缓存
[知识库片段... 800 tokens] # 半稳定，按会话缓存
---
[当前时间] [用户ID] [对话历史...] # 易变，不缓存仅仅这一个结构调整，很多团队的报告显示缓存命中率从个位数提升到了 60%–80%。
成本测算：缓存值不值得做？
以输入价 $3 / 百万 token、缓存写入价 $3.75 / 百万、缓存读取价 $0.30 / 百万为例，一个每天 1 万次调用、每次输入 4000 tokens 的场景：
| 方案 | 单次输入成本 | 日均 | 月均 |
|---|---|---|---|
| 完全不缓存 | $0.0120 | $120 | $3600 |
| 缓存命中 70% | $0.0054 | $54 | $1620 |
| 缓存命中 90% | $0.0040 | $40 | $1200 |
也就是说，做好缓存，一个月能省下一台服务器的钱。而且缓存写入虽然是加价的，但只发生在前缀首次出现时。
工程化落地的五个要点
第一，建立”前缀快照”机制。 把稳定的 system prompt、工具 schema、few-shot 示例抽成一个版本化文件，带 hash。任何修改都要走版本号，避免”某天有人改了一行字”导致全省。
第二，按会话聚合缓存。 知识库片段如果是同一个用户频繁访问的主题，可以按会话维度拼进前缀，续期缓存。
第三，警惕动态 few-shot。 如果你根据用户输入动态挑选 few-shot 示例并放在前面，缓存必然失效。要么固定示例，要么把它挪到易变区。
第四，监控命中率。 主流 API 会在 response 里返回 cache_creation_input_tokens 和 cache_read_input_tokens。把这两个指标接进监控，命中率跌破阈值就告警。
第五，别忘了国产模型。 通义千问、DeepSeek、Kimi 等也已支持上下文缓存，定价策略各不相同，有的按命中次数计费，需要单独测算。
常见踩坑清单
- 时间戳/随机ID 混进前缀：最常见，也最致命。
- JSON 序列化顺序不稳定：工具定义用 dict 序列化时键顺序变了，缓存就废了。务必用固定排序。
- 多租户共享前缀：不同客户看到同一份 system prompt 缓存没问题，但一旦拼进客户专属信息就必须隔离，别把 A 客户的数据喂给 B。
- 缓存 TTL 误判：低流量场景下，两次调用间隔超过 TTL，缓存早过期了，白交写入费。此时应该主动”保活”或干脆不缓存。
小结
Prompt 缓存的本质是把”每次重算”变成”一次算好、多次复用”。它不是魔法，而是一套需要设计的工程约束：稳定在前、易变在后、逐字节一致、按版本管理。做好这四点，50% 的账单降幅不是痴人说梦。