缓存命中率怎么算

账单里缓存写和缓存读的金额差得很远，但你打开用量记录却发现根本对不上——大概率是命中率的分母算错了：有人拿缓存读除以总输入，有人拿缓存读除以缓存写加缓存读，两种算法能差出好几倍。这篇把口径先定死，再给一套从日志里算出命中率、并找出没命中的原因的排查顺序。

账单里缓存写和缓存读的单价差得很远，可你翻出用量记录一算，数字怎么都对不上——大概率不是平台算错，而是你自己的分母口径跟计费系统不是一套。有人拿缓存读除以总输入，有人拿缓存读除以缓存写加缓存读，同一批请求这两种算法能差出好几倍，再拿去估成本就完全跑偏。

所以这篇先把口径定死，再给一套从用量日志里把命中率算出来、并逐条找出「为什么没命中」的排查顺序。全文不写具体数字，凡是涉及当前费率、模型字段名、门限值的地方，都以站内页面当时显示为准。

先把分子分母定下来

命中率的分子基本没有争议，就是缓存读到的 token。麻烦全在分母。分母不同，同一个账号能算出天差地别的结果，所以先跟你要用的那个平台对齐口径，再谈优化。判断标准很简单：你算出来的数，能不能直接乘上计费单价还原出账单金额。还原不出来，说明口径错了。

还有一点常被忽略：不同厂商对「什么算缓存命中」的定义不一样，有的按前缀精确匹配，有的允许部分匹配，字段名也各不相同。到 /official-api 找到你正在用的那家，核对它的用量字段里哪一列才是缓存读、哪一列是缓存写，别照着另一家的文档硬套。

从用量日志里算出命中率

口径定完，接下来是从日志里落字段。别只记一个总数，那样后面根本没法排查。至少要把输入、输出、缓存写、缓存读分开存，缺任何一列都会让你在归因时卡住。token 与上下文的对应关系，可以先到 /ai-dict/category/basics 把基础概念过一遍，避免字段理解错位。

1. 落四个字段每条请求记录输入 token、输出 token、缓存写 token、缓存读 token；字段名以你所用平台为准，缺失的用响应体里的 usage 补齐，验证方法是随便挑一条请求，四列相加能对上总输入。
2. 按前缀聚合而非按天跨天的同一段会话会被自然日切开，命中率会虚低。先按「同一段系统提示」或同一个提示模板分组，再在组内算命中率，验证方法是同一模板在两天的结果应当接近，差得远说明分组错了。
3. 换算成金额再对比把缓存写和缓存读两组 token 分别代入单价，看命中率变化到底省了多少钱，而不是只看百分比。用 /tools/token-price-calculator 代入当时的费率核对，注意缓存写的单价通常和普通输入不同。
4. 留一份可复算的样本每次调参前后各留一批原始日志，确认命中率变化不是你改了统计脚本造成的，验证方法是用同一份脚本回算旧数据，结果应当可复现。

命中率上不去的排查顺序

命中率低有很多原因，但排查是有顺序的，从最容易踩的地方开始，别一上来就怀疑平台。下面这个顺序基本能覆盖八成情况，按顺序走一遍，一般到第二步就能定位。

• 查前缀有没有变：时间戳、随机 ID、动态插入的用户名或会话标识放在提示开头，会让整段缓存全部失效，这是最常见的元凶
• 查请求间隔：缓存有存活时间，超过窗口再发相当于重新写一次，先到 /ai-status 确认目标区域当时有没有抖动，再判断是不是自己的调用节奏问题
• 查拼接顺序：把动态内容放在静态系统提示之前是典型错误，顺序反过来命中率立刻不一样
• 最后再谈参数门槛：部分平台对可缓存的最小长度有要求，太短的提示本来就不进缓存，这种情况再怎么调前缀也没用

提升命中率的四种改法

定位完原因，改动其实就那么几类，核心思路是把「不变的」和「常变的」分开，并让不变的尽量长、尽量稳定地待在最前面。改的时候一次只动一个变量，否则你无法判断是哪一处起了作用。

最后这条尤其要提醒：缓存写通常比普通输入贵，命中率提高不等于省钱。只有当同一段前缀被反复复用时，省下来的读才盖得住多付的写。用 /tools/model-cost-calculator 按你真实的月度调用量代入当时的费率重算一遍，两个方向都算，别只看单次请求。

命中率是优化指标，不是目标；先把分母口径和自家调用模式对齐，再决定值不值得为它改架构。