缓存命中率多少是不错的

账单里明明开了缓存，省下来的钱却没多少，这时候你大概会盯着一个数字发愣：命中率到底多少才算正常？这篇不重复缓存怎么生效，只聊怎么读这个比率——什么区间算健康、哪些用法天然拉不高、以及命中率高低跟省钱是不是一回事。看完你能判断自己该继续调提示词结构，还是该换思路省钱。

账单里明明开了缓存，省下来的钱却没多少，这时候你大概会盯着一个数字发愣：命中率到底多少才算正常。先别急着找一个标准答案，因为命中率是个比值，脱离你的调用结构去比大小，基本没什么意义。这篇不重复缓存怎么生效，只聊怎么读这个比率——什么区间算健康、哪些用法天然拉不高、以及命中率高低跟省钱是不是一回事。

看完你能判断自己该继续调提示词结构，还是该换思路省钱。中间所有涉及同类调用量分布、各档价格的数据，都到站内页面核对当时的数字，别拿记忆里的旧值当基准。

先分清「不错的命中率」有两层含义

很多人问「多少算不错」，其实心里混了两个不同的指标。第一层是技术命中率：你的请求里有多少 token 真的命中了缓存；第二层是省钱命中率：命中的那部分在总花费里占多大比重。这两个数经常对不上，一个很高一个很低，原因就在下面这张表里。

命中率是比值不是绝对值。同一个百分比，放在不同调用结构里，省下的钱可能差好几倍。一个每轮拼入大量新材料的请求，就算技术命中率看着还行，命中部分占总花费的比例也可能小得可怜，所以别只盯一个数字下结论。

把自己的命中率算出来，再看落在哪一档

口径先对齐，这是最容易出错的一步。命中 token 数要除以「可缓存的总 token 数」，而不是除以全部输入 token。分母搞错，算出来的数字会凭空低一截，然后你就开始瞎优化一个根本不存在的问题。

• 长期跑同一份系统提示词、模板稳定的场景，技术命中率通常能跑到比较高的档位，这类是最值得继续优化的
• 每轮都拼新内容、上下文频繁变化的场景，命中率天然偏低，这不是配置问题，调也调不上去
• 短请求占比高的账号，分母小、波动大，单看一天的曲线没有意义，至少看一周
• 同一模板被多个渠道分发时，命中率要按渠道分开看，混在一起容易被平均值骗

算完落在哪一档，接下来是排查顺序。顺序反了容易白折腾，下面这三步按先后走。

1. 先看提示词前缀有没有固定把最近几次请求的开头部分拉出来对比，确认前缀是不是一字不差。有任何变动都算新前缀。
2. 再看两次调用之间有没有插入变动内容时间戳、随机 ID、用户名这类东西只要出现在前缀里，缓存就别指望了。把它们挪到末尾或单独放。
3. 最后才怀疑平台侧缓存策略前面两步都干净了，命中率还是上不去，再去 /tools/speed-test 之类的工具页看当时的缓存行为说明，别一上来就怪平台。

把命中率拉低的常见原因，逐个对号

命中率低很少是单一原因，通常是几个因素叠在一起。与其一个个试，不如拿下面这份对照表逐条排查，找到真正拉低你数字的那一两个。

这里要专门说一句不可复用的情况。一次性问答、每次材料都不同的任务，本来就没有可命中对象。这种场景里优化命中率是白费力气，你该做的是砍输出长度或者换更便宜的档位，而不是继续折腾前缀。

命中率是结果，不是目标。盯着一个拉不上去的数字优化，往往不如承认这个任务本来就不适合缓存。

命中率高不等于省钱，用三步确认值不值得继续调

最容易被忽略的一点：命中率高跟省钱不是一回事。命中率上去了，账单却没怎么变，说明你省的那部分本来就不是花费大头。用下面三步确认一下，再决定要不要继续投入时间优化。

1. 把命中部分和未命中部分的花费分开记格式参考 /usage 里的字段口径，只看总账单看不出结构，分不开就永远不知道钱花在哪。
2. 算多花的钱来自哪是未命中的输入太贵，还是输出太长？两者的解法完全不同，前者调缓存，后者砍输出。
3. 判断上限如果可缓存部分本来只占花费的一小块，命中率再高也就省那么点，不如去砍输出长度或换便宜档模型。

有一种情况这套判断不适用：按次计费、订阅制、或者缓存读写本身就单独计价时，命中率高低跟账单关系很小，别拿它当成本指标。这时该看的是调用次数和档位选择，而不是命中率曲线。

给自己一个判断标准：如果可缓存部分占花费大头、前缀又能固定下来，那继续调命中率是划算的；如果可缓存部分本来就只占一小块，把时间花在输出长度和档位选择上，回报通常更高。