Prompt caching 不是开了就能省钱。它的 ROI 取决于缓存 TTL、请求密度、前缀稳定程度和重复输入的真实频率。5 分钟窗口和 1 小时窗口之间的差异，可能决定缓存是省钱了还是增加了复杂度。
什么决定 Prompt Caching 的 ROI
Prompt caching ROI 回答一个问题：缓存折扣是否大于缓存未命中的成本？
两个供应商即使给同样的缓存折扣，因为 TTL、请求量和复用模式不同，ROI 也可能完全不同。主要变量包括：
- 缓存 TTL：缓存前缀在多长时间内有效（5 分钟、1 小时或更长）
- 前缀稳定性：可缓存部分的内容在不同请求之间是否变化
- 请求密度：在 TTL 窗口内，有多少请求命中同一前缀
- 缓存折扣：缓存输入和正常输入的价格差异
如果 TTL 很短且请求分散，大部分输入都会错过缓存。折扣只对命中有效，如果没有命中，就没有省钱。
5 分钟缓存窗口
5 分钟 TTL 要求请求以短时间内密集到达的方式出现。如果流量在全天均匀分布，5 分钟窗口能捕获的命中可能很少。
5 分钟窗口适合的场景：
- 批处理任务几分钟内跑完大量请求
- 并发用户会话共享相同系统提示词
- Agent 工作流中多次工具调用复用相同指令
- 评测或测试任务反复命中同一 prompt 模式
5 分钟窗口的盈亏平衡需要更高的请求密度。如果你不能在 5 分钟内用同一前缀发出多次请求，缓存可能不划算。
1 小时缓存窗口
1 小时 TTL 给复用留了更多空间。即使请求在一天内均匀分布，仍然有机会命中缓存。
1 小时窗口适合的场景：
- 稳定生产的用户流量
- API 集成中请求间隔不均匀
- 系统提示词和工具定义变化缓慢的工作流
- 跨多次会话复用相同政策上下文的客服机器人
1 小时窗口更宽容，不需要流量突发也能看到省钱效果。
盈亏平衡命中率计算
盈亏平衡命中率是让缓存比不缓存成本更低的临界命中率。
有效输入成本 = (1 - 命中率) × 正常价格 + 命中率 × 缓存价格和不缓存的情况对比：
不缓存成本 = 正常价格
盈亏平衡命中率 = (正常价格 - 目标有效成本) / (正常价格 - 缓存价格)如果盈亏平衡命中率高于你的流量结构能够实际达到的水平，缓存可能不值得投入实现成本。
缓存什么时候增加复杂度多于价值
缓存是有成本的。实现工作包括：
- 把稳定的前缀和可变用户输入分开
- 测试缓存失效是否正确
- 在生产中监控缓存命中率
- 处理长 prompt 的部分缓存未命中
如果盈亏平衡命中率高于 50%，而你的流量达不到，缓存节省的 token 可能不足以覆盖工程成本。
可以用 文本模型计算器 对比缓存和不缓存的场景。价格表 列出了每个模型当前的缓存折扣。如果你想先了解基本概念，可以从 Prompt Caching 能省多少钱 和 缓存命中率成本规划 开始看。
缓存预算表
在 Token 预算模板 里单独加两行：
| 输入类型 | 价格假设 | 说明 |
|---|---|---|
| 未命中输入 | 正常输入价格 | 用于突发或可变输入请求 |
| 缓存命中输入 | 缓存价格 | 用于稳定前缀、高复用请求 |
在生产命中率数据出来之前，不要把两者合并成一个平均价格。
什么时候缓存 TTL 不重要
有些工作负载请求量太大，即使 1 分钟 TTL 也能命中。在这些情况下，TTL 选择的影响远小于缓存折扣本身。高并发批处理任务、持续 CI 流水线和带有重复任务模式的实时 Agent 系统，即使短 TTL 也很容易命中。
TTL 讨论对中等流量或突发流量场景最有意义。流量非常大时，不管 TTL 长短，缓存基本都划算。
FAQ
Prompt Caching ROI 多高才算值得？
如果盈亏平衡命中率超过 60%，除非你的流量非常大，否则缓存可能不值得投入工程成本。
缓存 TTL 会影响供应商的标价吗？
TTL 通常是技术限制，不是定价杠杆。供应商决定提供多长的缓存窗口，你在这个窗口内做规划。
缓存未命中会不会比不用缓存更贵？
有些供应商会在未命中时收取缓存写入的费用。请确认你的供应商是否对缓存写入也按正常输入价格收费。
怎么开始测量 Caching ROI？
把输入 token、缓存命中输入 token 和输出 token 分开统计。比较开启缓存前后每完成一次行动的成本。