「缓存命中率」是个伪指标,应该看未命中的缓存

heimoshuiyu 2026-06-27 16:51 1



命中率的问题很简单:它是一个百分比,分母是你的总 token 数。上下文越短、新输入越多、子 agent 开得越多,命中率自然就越低——但这跟 provider 的缓存质量没关系,是你自己用得多。一个百分比把「你怎么用」和「 provider 缓存好不好」混在一起,根本看不出问题出在哪。

换成绝对值就清晰了:

未命中 = 上一条的总 token 数 − 这一条从缓存读回的 token 数

就是这一轮有多少 token 被白白重新处理了。理想情况是 0 ,值越大浪费越多,用户在为这些 token 付钱。要是这个值突然飙上去,说明缓存挂了——可能是有问题的插件打断了缓存,或者 provider 的缓存过期了。

跑了下自己 16 万条消息,发现不同模型差异巨大:DeepSeek-v4 有 85% 的对话连上一轮的输出都能缓存住,GLM-4.7 有 63%,但 GPT-5.5 只有 0.3%。vLLM 和 SGLang 本来就支持输出侧 KV 复用,那些不支持的模型纯粹是没开这个能力,用户的钱就这么烧了。

把这个指标做成了可视化看板,点击某天还能下钻到具体会话,看每条消息的缓存命中细节:



直接读 OpenCode 的 SQLite ,本地一个二进制就能跑。

GitHub: https://github.com/heimoshuiyu/opencode-token-dashboard

如果你也在用 OpenCode ,可以看看自己的缓存未命中是多少。
最新回复 (8)
  • bbbblue 06-27 17:00
    1
    虽然和使用场景相关
    但是和不同的 provider 也还是有关系的吧 一些三方中转号池轮训导致的失效就不提了 毕竟他们是三方中转

    一些提供开源模型算力厂本身的缓存策略也不一样(触发阈值 缓存时间 过期机制) 导致他们的缓存命中率就差的多 or 上同样 glm5.2 有些就是 80+ 一些连 10%都不到(还有 0%的压根没缓存 😂
  • winnerczwx 06-27 17:07
    2
    这是 cc switch 统计的, codex 下 gpt5.5 缓存命中率有 92.7%, 你这个 0.3% 也太离谱了, 难道是 opencode 对 gpt 支持的不好?

  • codehz 06-27 17:16
    3
    gpt-5.5 只有 0.3 应该是你供应商的问题吧。。。这个比例怎么看都不对,我这用起来不说 90%,那起码 80%还是有的,就算子代理开爆也不至于<1%
  • heimoshuiyu 楼主 06-27 17:18
    4
    @winnerczwx 我指 gpt5.5 0.3% 是输出侧 token 存在缓存的概率。一次 API 调用包括输入 + 输出两个部分,调用完成后,deepseek 会将输入 + 输出缓存起来,而 gpt 只缓存到输入。因此用户实际上为输出 token 多付了一份输入未命中的钱。

    92.7% 这个数值很难说明什么。平时使用的平均会话上下文偏长,这个数值很容易就能刷高。这也是我建议不要使用「缓存命中率」的原因。另外,ccswitch 存在消息重排序破坏缓存的草台 bug github.com/farion1231/cc-switch/issues/3934
  • GeruzoniAnsasu 06-27 18:10
    5
    缓存命中率是给 agent 开发者看的…… honestly
  • utodea 06-27 18:28
    6
    cache hit 并不特别代表什么, 会话拉长、prompt token 适当多费点,很容易拉高。 比如我这个: https://github.com/usewhale/whale 。 优化的时候 agent 开发者可以参考它, 但过低多少有点猫腻。

    115 turns · $0.0841 · 98.8% cache · last prompt 94.7K · $2.8607 cache saved
  • JackalZhao 06-28 14:39
    7
    本应缓存命中的部分,给你按照未命中算的话,你的账单不炸了?

    我们关注缓存命中率,实质上是关注价格虚标,有没有把命中的部分按照未命中计费。
  • heimoshuiyu 楼主 06-28 16:19
    8
    @JackalZhao 我认为 “输出侧 tokens” 属于本应缓存命中的部分,而多数 provider 没缓存。关注缓存命中率的话你看不出这个问题,看未命中 tokens 就能发现这个问题,如我图所示,每一次请求的未命中 tokens 都大于上一次请求的输出 tokens 。

    另外,假如某个 provider 缓存临时故障,缓存命中率只会下降几个点,被使用习惯的噪声淹没。而未命中缓存指标会有一个非常显眼的凸起
* 帖子来源V2EX
返回