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

缓存命中强相关你的任务场景和输入，如果你的输入每次都有巨大增幅，且新增内容不同，缓存命中自然就低呀
缓存命中更多是服务端的 harness ，比如 ds 缓存过期时间长，那命中率自然高
缓存命中在多轮对话中数学角度一定是不断增长的，且你每次请求 prompt 中固定部分（一些全局/工具描述等）越大，缓存命中越高

就这么一个和多个环节相关的参数，被很多人拿来评价用户侧 agent, 不禁感叹智商的分布，很长时间不理解。

你的缓存命中高，很可能只是你的任务简单，迭代次数多罢了

t6gfx4ddv3

8 月 14 日

赞同。如果上游 API 和工具不乱搞，工具调用效率更重要。

Agent 乱读不相关的文件、一个文件分三四次读、一个提交执行六七次 git 命令堆起来的缓存命中率反而更费钱。

xAI

8 月 14 日

因为成本，好多人去追求缓存命中，可以降低支出成本，和性能没有关系，如果什么任务缓存命中都非常高，那并不是好事。

Lanyangzhi

8 月 14 日

缓存命中率高意味着特定情况下（现在为普遍）的低成本，高 prompt 复用，高工具工作流优化
如果你觉得缓存不好，那你怎么看 claude code 和其他 agent 明显不同的缓存行为？
https://v2ex.com/t/1233222
我在使用其他工具，如 dsh/hermes/codex/opencode 都没有观察到这种异常的出缓
在工具本身没有拉开性能差距的情况下产生了成本浪费，那我只能认为你不论是主观恶意还是客观优化不足，都存在问题

zizon

8 月 14 日

举个例子,
agent/harness 每次都是完全不同的独立上下文协同工作.
和每次会共享一部分 context 避免重复劳动.

这两种方式都能达到目的.
但机制上来说,1 消耗的算力通常会比 2 高.

一个东西从能用就行发展到需要精细工程化的时候就需要有指标去评价实现方式好和不好.

ndxxx

8 月 14 日

缓存命中率高说明该请求读取了足够多的上下文的情况下帮你省钱了啊。

benchmark 长程任务时，缓存命中越高说明这家服务商给你的缓存时间也长。

针对一个 agent 的性能衡量有很多细节，确实不是一句缓存命中率高能概括的，但是它确实概括某一方面的某些综合能力表征。

qianmoumou

8 月 14 日

我觉得这是在刚开始使用一个新的 agent 或者新的 model 时一个粗浅的评判方式吧，确实不精准。但是如果 kv cache 异常低，那么说明 model 的在 gpu 上的部署 api 转发或者 harness 不适配。
在使用过程中，如果是短任务，那么最多理解为你的提问不够好，不够精准

KorenKrita

8 月 14 日

同样的效果看价格和速度
同样的价格看效果和速度
同样的速度看价格和效果
这才是比较 harness 的标准，只看缓存命中率完全无意义
缓存命中率 99.9%既不代表效果好，也不代表花钱少，也不代表速度快，可能就是大量类似原地打转的调用，或者每次就吃一点信息但是大量的调用次数，或者一开始就巨大的提示词

liKeYunKeji

8 月 15 日

缓存命中率，意味着这个模型多人用，同类问题容易被重复提问，省掉重新计算的成本，那么也就直接可以输出，无需复杂计算，这虽然不能作为性能的表现。只反应 2 个角度，一个是快，另一个是不消耗大量的 token ，性能的表现其实是一个感觉上，而不是真正的性能。

这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://v2ex.ih06.com/t/1234259

V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.