缓存收益必须能解释，才能写进预算
提示词缓存可以降低 AI API 成本，但前提是请求结构足够稳定，固定输入能够被重复利用。如果可缓存前缀每次请求都变化，预算看起来会很便宜，真实账单却可能完全不同。更完整的节省模型可以先看 提示词缓存能省多少，再用这份清单校验预算假设。
在生产环境成本估算中依赖提示词缓存前，可以先按下面清单检查。
1. 找出可缓存前缀
先把固定内容和动态内容拆开。
通常适合缓存：
- system instructions。
- 稳定角色定义。
- 工具 schema。
- 安全策略。
- 固定示例。
- 多次复用的长参考文档。
通常不适合缓存：
- 用户消息。
- 当前时间戳。
- session id。
- 每次请求变化的检索片段。
- 最近聊天历史。
- 个性化账户数据。
如果动态值出现在固定前缀完成之前，缓存命中率可能明显下降。
2. 检查工具 schema 是否稳定
使用工具调用的 AI 应用，往往会在每次请求中发送较大的工具定义。如果这些定义稳定，就可能成为重要的缓存部分。
需要检查：
- 工具顺序是否保持一致。
- 工具名称是否稳定。
- 描述是否不会每次重新生成。
- 可选工具是否随机插入。
- feature flag 是否频繁改变 schema。
工具 schema 可能占据大量输入 token，不稳定的 schema 会抵消预期节省。
3. 保守估算缓存命中率
不要在没有证据时假设 80% 或 90% 命中率。可以先用保守场景表：
| 场景 | 缓存命中率 |
|---|---|
| 新功能，使用方式未知 | 20% 到 40% |
| 重复工作流，prompt 稳定 | 50% 到 70% |
| 高流量固定助手 | 70% 到 90% |
上线后再用日志替换假设值。
4. 同时比较缓存和不缓存成本
提示词缓存预算应该同时展示两个版本：
| 预算字段 | 作用 |
|---|---|
| 总输入 token | 体现完整请求大小 |
| 可缓存输入 token | 体现可能打折的部分 |
| 不可缓存输入 token | 仍按正常价格计算 |
| 输出 token | 通常不会因输入缓存而减少 |
| cache write cost | 创建缓存时可能产生 |
| cache read cost | 命中缓存时产生 |
可以先用 文本模型计算器 做基础输入和输出估算，再结合 缓存命中率成本规划 对比。
5. 注意缓存破坏因素
常见缓存破坏因素包括：
- system prompt 中包含时间戳。
- 固定指令里放 request id。
- 示例顺序每次变化。
- 动态检索内容放在固定工具 schema 前面。
- 多语言文本混在同一个 prompt 前缀中。
- A/B 测试变量插入到前缀里。
能后移的动态字段，应尽量放到请求后半部分。
6. 把重试算进去
如果失败请求反复创建新前缀，或者长输出因为重试重新生成，缓存价值会下降。
需要记录：
- 重试次数。
- 超时比例。
- 重试是否复用同一个可缓存前缀。
- 用户重复提交是否去重。
做上线规划时，可以配合 AI 功能上线前的成本检查清单 一起使用。
7. 记录缓存指标
至少应记录：
| 字段 | 用途 |
|---|---|
| model | 确认价格档位 |
| input tokens | 总输入成本基准 |
| cached input tokens | 确认缓存读取量 |
| cache creation tokens | 追踪缓存写入行为 |
| output tokens | 解释剩余成本 |
| feature name | 区分不同工作流 |
| cache hit or miss | 计算真实命中率 |
没有这些字段，就无法证明提示词缓存是否真的生效。
总结
当固定指令、工具 schema 或可复用文档占据大量输入时，提示词缓存最有价值。把缓存收益写进预算前，应先找出可缓存前缀，保守估算命中率，对比缓存和不缓存成本，避免缓存破坏因素，并在上线后记录真实缓存指标。