提示缓存实战：把 API 账单砍掉一半的工程技巧

如果你的应用每次请求都把一大段系统提示词、几十条示例、整份文档重新发一遍，那么你正在为几乎相同的内容反复付费。提示缓存（Prompt Caching）就是解决这个浪费的利器。

一、缓存能省多少

主流厂商对缓存命中的输入 token 收取大幅折扣，通常只有原价的 10%–25%，而写入缓存可能有一次小额溢价。以一家客服机器人为例：

• 系统提示词 + 知识片段约 8000 token，每天 5 万次请求。
• 不缓存：8000 × 5 万 = 4 亿 token 全价计费。
• 开缓存：绝大多数命中，输入成本直接降到原来的两三成。

把客服、文档问答、代码助手这类”固定前缀 + 变化末尾”的场景一算，账单砍半是保守估计。

二、命中原理：前缀必须严格一致

缓存按从第一个 token 开始的连续前缀匹配。只要有一段不同，后面全部失效。这带来一条铁律：

稳定内容放前面，变化内容放后面。

正确顺序：

1. 系统指令（固定）
2. 少样本示例（固定）
3. 长文档 / 知识库（半固定）
4. 用户当前问题（每次都变）

三、五个让缓存命中的写法

1. 冻结前缀：不要往里塞时间戳、随机 ID、用户昵称，这些会击穿缓存。
2. 只在末尾注入变量：把动态信息放最后一段。
3. 统一格式：JSON 键顺序、空格、标点都要一致，差一个空格就不同。
4. 凑够最小缓存长度：不同模型有最小可缓存 token 数，太短的提示词不缓存。
5. 复用同一前缀：同一业务线尽量共用系统提示词，别为每次调用现拼新串。

四、常见翻车点

• 在系统提示里插当前日期：等于每次新前缀，缓存全废。
• 对话历史直接拼接：历史越长，前缀变化越多，命中率暴跌。应只把稳定部分前置。
• 多租户各写各的提示词：可以考虑共享骨架，只把租户信息后置。

五、落地检查清单

• 统计有多少请求共享同一长前缀。
• 把动态字段全部挪到提示词末尾。
• 固定所有格式化细节，做一次哈希比对确认一致。
• 监控”缓存命中 token / 总输入 token”这个指标。
• 对比开启前后的单位请求成本。

六、什么时候不值得做

短提示词、一次性请求、每次内容都完全不同的场景，缓存意义不大，反而增加维护成本。先测量前缀复用率，再决定是否引入。

提示缓存是纯工程收益：不改模型、不改效果，只改提示词的组织顺序。这类”零风险省钱”的优化，值得每个 AI 应用优先做。