提示缓存是怎么计费的？命中价、写入价、存活时间都要看
提示缓存不是「开了就省钱」的开关。它至少有三个价格维度：命中价、写入价、存活时间。前缀复用得够频繁才赚，每次请求前缀都不一样的话，写入费反而是净亏。
这篇讲清计费结构和判断方法。想把结论代进预算，用月成本估算器分别按「有缓存」和「无缓存」算两遍对比。
缓存到底缓存了什么
模型处理一次请求时，会先把输入逐个 token 算成内部状态。提示缓存做的事是把请求前缀对应的这部分中间状态存下来，下次遇到相同前缀时直接复用，不用重算。
关键词是前缀。缓存匹配是从头开始逐段比对的，一旦某个位置对不上，从那里往后就全部失效。所以顺序至关重要：稳定的内容必须放在最前面，变化的内容放后面。
这也解释了一个高频困惑：「我开了缓存，为什么命中率是零？」十有八九是前缀里混进了每次都变的东西——时间戳、请求 ID、随机排序的检索片段、用户名。哪怕只有几个字符不同，后面几千 token 也一起作废。
三个价格维度
一、缓存命中价（读）。 命中时这部分输入按远低于标准输入价的折扣计。折扣力度各家不同，普遍是数量级级别的便宜——这是缓存的主要收益来源。
二、缓存写入价（建）。 有的厂商建缓存要收费，价格可能略高于标准输入价（因为要额外做存储）；也有厂商不单独收写入费。这一项决定了「第一次」的成本，复用次数少时它会吃掉全部收益。
三、存活时间与存储费。 缓存不是永久的，多数有一个存活窗口，超时后自动失效，下次要重新写入。有的厂商按存活时长收存储费，有的提供更长存活的档位但价格更高。
三项合起来才是真实成本，只看命中价会高估收益。
怎么判断开缓存赚不赚
用一个很朴素的判断：在缓存存活期内，同一个前缀被复用了几次？
复用次数少（比如只有一两次），写入成本摊不下来，可能不赚甚至亏。复用次数多（几十上百次），收益就非常可观了。
所以缓存最适合的场景有共同特征：固定前缀长、请求频率高、前缀稳定不变。典型的是客服问答（长 system prompt + 固定工具定义，全天高频调用）、代码助手（固定的项目上下文）、批量处理（同一套指令跑一批数据）。
不适合的场景也很明确：低频调用（缓存等不到复用就过期）、前缀高度个性化（每个用户的前缀都不同）、请求结构随机（无法保证顺序稳定）。
怎么把前缀设计得可缓存
第一，固定内容前置。 system prompt、工具/函数定义、常驻知识片段放最前面；用户输入、检索结果、对话历史放后面。
第二，从前缀里赶走动态内容。 当前时间、随机 ID、每次都变的会话标识，能挪到后面就挪，不能挪就去掉。真需要时间信息的话，考虑降低精度（精确到天而不是秒），这样一天之内前缀还是稳定的。
第三，保证顺序稳定。 如果你的工具定义或知识片段是从字典/集合里遍历出来的，不同运行可能顺序不同，前缀就废了。显式排序。
第四，控制前缀的更新频率。 每改一次 system prompt，缓存就要重建一次。改动频繁的实验期，缓存收益会打折扣。
一定要用指标验证
缓存最坑的地方是：开了没生效，你不会收到任何报错，账单也不会立刻告诉你。所以必须有指标。
最小可用的埋点是从 API 响应的 usage 字段里取缓存相关的计数（多数厂商会返回命中的 token 数），记录下来算命中率。上线后先看一周，命中率明显低于预期就去查前缀。
监控里建议至少有两个数：命中率（命中 token / 总输入 token）和缓存节省额（按标准价与命中价的差额估算）。第二个数是你向上汇报时最有说服力的东西。
算一笔账：什么时候缓存开始回本
用一个简化模型就能算清楚。设固定前缀长度为 P，标准输入价为 a，缓存命中价为 b，写入一次的额外代价为 c（有的厂商为零），存活期内复用次数为 n。
不开缓存的成本：P × a × (n+1) 开缓存的成本：P × (a + c) × 1 + P × b × n
两边相减可以看出，只要 b 远小于 a，n 稍微大一点收益就非常明显；而当 n 等于零或一时，写入代价 c 可能吃掉全部甚至造成净亏。
这个模型的实际含义是：缓存的收益几乎完全由「存活期内复用几次」决定，而不是由前缀有多长决定。前缀长只是放大器——复用次数够多时放大收益，复用次数为零时放大损失。
所以评估缓存值不值得开，第一个要估的数不是前缀长度，而是请求频率与缓存存活时间的乘积。一分钟来一次请求、缓存能活五分钟，那 n 大约是四；一小时来一次请求，那 n 基本是零，缓存对你没意义。
几个容易误解的地方
误解一：开了缓存输出也会变便宜。 不会。缓存只作用于输入侧，输出该多少钱还是多少钱。如果你的场景是短输入长输出，缓存能省的比例本来就小。
误解二：缓存会让模型「记住」上次的对话。 不会。缓存是计算层面的复用，不改变模型行为。你不发历史，模型照样不知道之前聊过什么。
误解三：命中率越高越好。 命中率高说明前缀稳定，但如果你的总输入里固定部分本来就只占一小部分，那么命中率再高，省下的绝对金额也有限。看命中率的同时要看固定部分占总输入的比例，两个数一起才有意义。
误解四：缓存是免费的性能优化。 多数场景下确实近似免费，但存储费和写入费在某些计费模型下不可忽略，低频场景尤其要算一下。
和其他手段怎么配合
缓存优化的是单价，不解决长度问题。上下文太长导致跳档、超窗口的问题，缓存救不了，那得靠裁剪和检索——见上下文长度怎么选。
正确的顺序是：先把不必要的输入砍掉（该短的短），再把剩下的稳定部分交给缓存（该便宜的便宜）。反过来做的话，你会把一堆废话高效地缓存起来，省下的只是废话的钱。
完整的降本顺序见大模型 API 降本十招。想知道各家价目表怎么读，看输入价、输出价、缓存价怎么读。
三个高频问题
问：缓存需要我改代码吗？ 多数厂商是自动生效或加一个参数，不用改调用逻辑。真正要改的是请求的拼装顺序——把固定内容放前面。这一步才是决定成败的地方。
问：缓存会影响输出质量吗？ 不会。它复用的是计算中间状态，不改变模型的输出行为。同样的输入，命中与否结果一致。
问：多个模型之间能共享缓存吗？ 不能。缓存是绑定具体模型的，换模型等于缓存全部重建。这一点在做多模型路由时要特别注意。