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

@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%