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

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

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

我不在乎这个，但用户对价格敏感是什么很难猜的东西吗。
你有研究过 ds4f 之类的热门模型的缓存占比对价格的影响可以分享一下。

另外这你都能上升到别人智商有问题，其实也看不出来你有多聪明...

工具的使用单价你不在乎？

那你很有钱咯

@ReinXD 我记得主流 harness 都是这么干的？

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

确实,除非故意使坏,不然这缓存命中率就低不了.

但是还是有一些优化技巧的,省一点也是真金白银.

这不 deepseek 都涨价了么.

@0xnycth 主楼一点不看么？ 说了和任务场景有关系

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

省钱带来的冲击力是很直接的

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

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

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

黑人问号？

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

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

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

因为没什么可吹的了，大差不差的，只能强行说点啥，刚刚还看到一个帖子，说把 agent 装进你的电脑，然后有个唐式对比：

其他 AI 助手工具 XiaoyaoClaw
数据上传到云端，归别人管 本地优先，配置、聊天记录、API 密钥都在你电脑里

我寻思着 hermes openclaw pi 哪个不是本地？

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

因为大部分人的任务简单 且 价格敏感度高

我感觉评估 agent 主要还是看 模型能力 推理能力 任务执行正确率, 至于是 99%缓存还是 95%缓存确实不在意, 只要能把活干好 多花点 token 就多花点吧

一个任务 10 亿 token, 8 小时多跑完 5x 周额度, 但能解决问题啊不是吗?

@winnerczwx 从最近的 agent 看，loop 能力/任务编排/长时间任务执行 是 agent 的核心

主贴描述的现象是事实，但不应表示“Agent 缓存命中率”这个指标无效。原因应该是语义含糊问题，Agent 缓存命中率应该是一个受多场景多变量影响的指标，自媒体良莠不齐，含糊的描述，导致了传播层面的困惑。
稍微严肃一点的定义，对比多个 Agent 在相同的 codebase 、环境、链路、模型、提示语等因素，处理同一个相对复杂的业务场景，来比对缓存明中率，这样的指标应该是有意义的。因为 Agent 实现上的确有影响这个指标的因素，所以用于评估 Agent 是有效的。只是要严肃对比可能要有较为严格的测试设计。
那么 Agent 间的横向对比，和个人实际使用的纵向推进场景，有什么参考价值吗？除了来回拉扯的场景，其它可能差那么一点命中率没有太大关系，但的确是可以省钱的。

@xyooyx
列个公式其实就很清晰了

总命中率 = (System Cache Hit + History Cache Hit) / Total

= [ C × hit_rate_system + ΣΔ(k) × hit_rate_history ] / [ C + ΣΔ(k) + d ]

代入场景数据：
系统提示（含工具）：1500–3000 tokens
历史对话（ 10 轮）：4000–8000 tokens
当前输入：20–100 tokens
则：
命中率 = (3000 + 8000) / (3000 + 8000 + 50) ≈ 99.5%

所以得出推论：
- Agent 只要跑起来，轮次必然长，高缓存命中是“必然结果”
- 这不是某个特定任务的福利，而是 Agent 场景的“通用属性”

那问题就变成了：
既然所有 Agent 都必须面对“长文本 + 高重复”这个通用问题，
那一个模型如果能做到：
- 长上下文不崩（ 128K 甚至 1M 依然能 recall ）
- Cache 策略高效（不重复计算）
- 长文本推理速度不线性下降

我们就认为这个模型在 Agent 这个赛道里“做得好”。因为它在解决的是这个场景下的“通用瓶颈”

如果是公司承包我的 token 我根本不在乎所谓的缓存命中量。

如果是我自己，又是成本>收益的情况，价格肯定是个人开发者的敏感点。

@Retas 这里有个关键问题是如果模型 sft 的训练数据没有针对性优化，这样的操作是会下降模型性能的

有点像不同饭店的两盘菜的单价，不考虑原材料成本，不考虑两份菜的分量大小，就硬比。

@Tiande 赞同, 不同的用户有不同的需求侧重, 强行以自己的标准来判断还上升到智商问题是真的难评🤣

缓存命中高不仅影响价格，还影响速度

我早就想说你同样的观点了，不敢说，每次看到什么 99%的缓存率然后怎样怎样，莫名觉得好笑

大家不都是比的相似的任务么，反正我用的时候会大概看一下。正常使用过程中某些模型就是命中率低，某些工具就是命中率低，这还不能说么。又不是专门为了让某些工具刻意的高刻意的低。

因为这玩意儿影响价格啊，如果 cache read 的价格和普通 input 价格一样那这个 hit rate 0 人在意，
各家动辄 cache read 1/10 的价格，甚至大部分都没有 cache create 价格，那当然是命中率越高越省钱，这很难理解么

还有一个问题是上下文越高，AI 智商也会相应的变低。

说白了就和显示器比参数一样的逻辑。
参数有意义吗，有意义，也没有意义

难道我来用 AI 不是来赚钱，是为了花钱的？

因为 KV cache 在 llm 里面是非常正经的概念

Transformer 做自回归生成时，每生成一个 token ，都要做 Attention ，要是没 KV Cache ，那每一个 token 都要重新算，那个计算量我觉得没有模型可用吧。

另外 agent 的 Prompt Cache ，要是没有缓存，每一次都要做 prefill ，也是非常离谱的计算量

LLM 自身能成功命中缓存，很大程度上决定了这模型的速度和计算量，虽然可以输出上帮助不多，但是 prefill 提升巨大

typo：可以-可能

喷楼主的人，应该都没有理解缓存机制

建议阅读一下： https://platform.claude.com/docs/en/build-with-claude/prompt-caching

因为 Agent 的一次任务通常不是一次模型调用，而是多轮循环：
读取上下文 → 思考 → 调工具 → 把结果加入上下文 → 再次调用模型
后续每一轮都会重复携带大量相同内容，例如系统提示词、工具定义、项目说明和历史对话。模型供应商可以缓存这些不变的前缀，下一轮直接复用。
举个例子：每轮输入 100,000 Token ，其中 90,000 Token 是不变的上下文。如果缓存命中率为 90%，每轮真正需要重新处理的可能只有新增的 10,000 Token 。对需要循环几十次的 Agent 来说，差距很大。

缓存命中率更准确地说是一个“运行效率指标”，不是“能力或效果指标”。评估 Agent 应同时看：
1 、任务成功率和结果正确性；
2 、完成任务的总时间；
3 、总 Token 与总成本；
4 、模型调用和工具调用次数；
5 、是否需要人工介入；
6 、缓存命中率。
我更倾向使用 每个成功任务的成本和耗时 作为核心指标。缓存命中率适合用于解释成本和延迟为什么变化，但不应该单独拿来判断 Agent 好不好。

大概因为，不知道缓存怎么算，以为缓存高是 Agent 甚至 LLM 的功劳。
下面对话，都是 3 轮，输入 token 都是 40K，（其中 A、B、C、D 都代表 10K token，用｜分割轮次）：

缓存率 44%： 按照 A|BC|D ，缓存率就是(AA+B+C)/(AAA+BB+CC+D)=40K/80K=50%
缓存率 55%： 按照 AB|C|D ，缓存率就是(AA+BB+C)/(AAA+BBB+CC+D)=50K/90K=55%

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

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

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

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

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

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

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

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

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

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

又一个极端， 从来没人说过评估 llm 只使用缓存命中率， 这只是 llm 系统的一个侧面

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

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