不明白为什么很多人用「缓存命中率」作为 agent 的性能评估参数

发布于

1. 缓存命中率与任务场景和输入有很强的相关性。如果你的输入每次都有巨大的增幅，并且新增内容不同，那么缓存命中率自然会很低。

2. 缓存命中率更多是与服务端的设置有关，比如说 ds 的缓存过期时间很长，那么命中率自然会比较高。

3. 在多轮对话中，从数学角度看，缓存命中率一定是不断增长的。而且你每次请求中的固定部分（如全局/工具描述等）越大，缓存命中率也会越高。

就这么一个与多个环节相关的参数，被很多人用来评价用户端的 agent，不禁让我感叹智商的分布，长期以来我对此非常不解。

你的缓存命中率高，很可能只是因为你的任务较简单，且迭代次数多而已。

---

原文链接：[点击查看](https://www.v2ex.com/t/1234259)

评论（14）

dpsk 应该是把 system prompt 直接放到每次请求的开头了，这样每次增长的计算实际上只有用户新发的请求，剩下全部可以 prefix cache hit，导致最后命中率 99%。其实没那么多魔法，不过 dpsk 应该这次在训练 sft 的阶段就对这种 prompt 方式进行优化了。

· 0 个赞

回复

回复 @ReinXD：ds 主要的不同是缓存失效时间长。假设第 i 次 prompt 的输入等于 A_i，存在关系 A_(i+1) = A_i + delta_i，极限情况当交互次数趋向∞，那么缓存命中必然趋向 100%。连这个都要拿来说事，似乎高中数学遗忘的人很多。

· 0 个赞

我不在乎这个，但用户对价格敏感是什么很难猜的东西吗？你有研究过 ds4f 之类的热门模型的缓存占比对价格的影响可以分享一下。另外这你都能上升到别人智商有问题，其实也看不出来你有多聪明...

· 0 个赞

回复

我只是发现这个现象，并对这个现象进行质疑和讨论。我都是面向现象说的，不能等同于“别人”，我没有对具体人的评价和质疑，谢谢。

· 0 个赞

不能当作一个评价维度么？你是免费不花钱用的么？做的不好的，也能“必然趋向 100%”，高中数学还挺天真的。

· 0 个赞

回复

agent 要怎么做呢？就是把动态内容尽量滞后，这还需要怎么做，这是最基本正常的开发思维么。

· 0 个赞

确实，除非故意使坏，不然这缓存命中率就低不了。但是还是有一些优化技巧的，省一点也是真金白银。这不 deepseek 都涨价了么。

· 0 个赞

回复

这可是有记录的，A 社曾经给非 anthropic 的 api 的请求在头部增加了一个动态码。

· 0 个赞

其实 system prompt 算小头，agent 场景里的大头是 history，每一轮相比上一轮的历史都是重复的。而且缓存命中率直接决定结算单价，最终影响的是完成一件事的成本，大家会用脚投票，所以当然会特别在意。

· 0 个赞

正确的，本身缓存率就是个和实际工作负载类型强相关的东西，服务端的影响也很大。Harness 只要做好稳定前缀就行，千万别像之前某个框架在系统提示词开头插当前精确到分钟的时间，这就很离谱了（虽然现在有些模型的 template 把系统提示词放在最后了）。

· 0 个赞

其实楼主已经说到部分原因了。很多时候我们不理解，是因为我们没走到那一步，鞋子合不合脚穿过才懂。

· 0 个赞

这有啥难理解的，好比游泳，人的水平当然是核心因素，但是同一个人，穿 A 牌的泳衣就是游的比 B 牌的快。agent 缓存命中优化是同一个道理，同样的任务和模型，用 opencode 和 claude code 缓存命中率就是不一样，换你你用哪一个？

· 0 个赞

因为没什么可吹的了，大差不差的，只能强行说点啥。刚刚还看到一个帖子，说把 agent 装进你的电脑，然后强行拉踩。我寻思着现在开源本地的工具那么多，哪个不能在本地跑？

· 0 个赞

赞同，99% 命中的那能是什么好任务……正常用 95% 是合理的，当然模型后端必须尽可能保持 stable prefix 才是合理的

· 0 个赞

0.057443s