提示缓存能省多少？一篇算清命中率和成本的账

提示缓存的宣传通常是「缓存部分只要 1/10 价格」。数字没错，但它描述的是一段特定的前缀，不是整个请求。算错账的团队不少。

一、缓存的是什么

共同规则是：只有请求开头连续一致的片段才可能命中。

[系统提示词 + 工具定义 + 长文档]  ← 可缓存
[用户这次的问题]                  ← 不可缓存

如果系统提示词里塞了时间戳、会话 ID、随机排序的工具列表，命中率就是 0。这是最常见的问题。

二、成本公式

设可缓存前缀为 P，每请求变化部分为 V，未命中 1 倍、写入约 1.25 倍、读取约 0.1 倍，同一前缀请求 N 次：

无缓存：  N × (P + V)
有缓存：  1.25P + (N-1) × 0.1P + N × V

代入 P = 10000、V = 500：

N（同前缀请求数）	节省比例
5	约 17%
20	约 37%
100	约 55%

结论：缓存收益强烈依赖复用次数。 一次性请求用不上，长驻 Agent、批量处理和固定人设的多轮对话才吃得到红利。若每个请求前缀都不同，省的钱接近零，还多付了写入溢价。

三、四个提高命中率的手法

1. 把变化的东西挪到后面。 时间、用户名、会话上下文全放用户消息，别放系统提示词。

2. 固定序列化顺序。 工具定义、schema 字段顺序必须稳定。用无序 dict 序列化，顺序随机，就永远命中不了。

3. 按稳定性分层。 极稳定的（人设、规则）在最前，次稳定的（工具定义）居中，不稳定的放后面。命中从头开始算，前面一改后面全废。

4. 多轮对话别改历史。 插入摘要、重排消息、给旧消息加标注，都会破坏前缀。历史必须严格追加。

四、别踩的坑

TTL 很短。 多数供应商缓存只存活几分钟到一小时，且每次命中刷新。低频任务别指望。

写入也收费。 只发一次的请求用缓存反而更贵。

统计要看清楚。 响应里通常有「缓存命中 token」字段，务必单独打点。很多团队以为改了提示词就省钱，实际命中率从 80% 掉到了 10%。

五、优先级

先看命中率，再精简提示词，最后才考虑换更便宜的模型。 换模型会掉质量，缓存优化是无损的。把命中率从 0 提到 70%，是成本优化里性价比最高的一步。

一句话：缓存不是折扣券，是复用奖励。没有复用的场景，别为它做设计。