2026年9月13日InfrastructureResearchBenchmark

他用三种办法在真实 agent 轨迹上挑战 LRU,三次全输

有人把 393 个真实 Claude Code 会话里的 68,266 条请求、外加 23,608 条 Mooncake 请求,重放进一个前缀缓存模拟器,用三种互相独立的办法去挑战最朴素的 LRU 淘汰策略,三次全败。他把整个过程连同失败一起发出来了:https://github.com/gauravapiscean/agentic-kv-cache 。Hacker News 上 90 分,其实配得上更高,因为基于真实轨迹的负面结果,比它反驳的那些正面结果稀有得多,也有用得多。

这三次尝试都不业余:用风险函数预测一个会话是不是还活着;用物理建模算真实重算代价而不是用一个替代指标;按会话粒度做淘汰,让一个会话的缓存链条同生共死。这三样在已发表的 KV cache 文献里都是被认为该有效的。三样都让结果变差了。

真正有意思的不是策略本身,而是原因,这个原因同时解释了为什么有几篇论文在优化错的东西。文献大多假设的是 TTL 主导的场景:缓存项按计时器过期,浪费来自那些空闲一阵又回来的会话。但真实的 agent 流量是容量主导的,在他的轨迹里 TTL 根本就没触发过,因为容量早就把该淘汰的都淘汰完了。他原话是:当容量成为约束时,它会压过 TTL,而它造成的重算,跟「会话空闲」那套故事完全不是一回事。具体数字:33.1% 的重算来自距上一条请求不到 10 秒的请求,而间隔超过 5 分钟的只占 17.5%。请求间隔的中位数是 2.1 秒。把缓存冲垮的是工具调用循环,不是被人丢在一边的聊天窗口——而且在 2.1 秒这个尺度上,你也根本没有信号可以拿来预测存活性。

里面还埋着一条所有做缓存策略评测的人都该看的方法论地雷。他指出,如果你的框架不给正在使用中的缓存链条做引用计数固定,像 Belady 这种离线最优策略跑出来会比 LRU 还差,而这个偏差是悄悄发生的,会污染整组对比。他还点名了两篇已发表的论文:它们拿 Continuum 当基线,却把 Continuum 的自适应 TTL 换成固定 2 秒或 0.3 秒的钉死值,而这恰恰废掉了让 Continuum 有效的那个机制。拿一个被故意做了脑叶切除的基线去比,就是一个领域是怎么攒出一堆无法复现的结果的。

两条保留意见得留着。会话到达模式是合成的,而且作者自己明确划了范围:结论只适用于容量受限、且哈希命名空间按会话隔离的部署,不是所有 agent 场景都通用。另外 HN 那边花了不少力气讨论他的消融实验有 LLM 参与、行文有明显的 Claude 腔——注意到这一点很公道,但拿这个否定真实轨迹数据就很没道理了。把它和[那次 RTK 省 token 的打假](https://clauday.com/zh/article/4d232d72-fed4-4cb2-ba3c-497b48241d52)、[Spotify 砍掉九成 token](https://clauday.com/zh/article/400d8e6f-0fcf-407b-9b4e-589c8fd5fe98)摆一起,规律很一致:在 agent 基础设施这块,能扛住真实流量检验的说法,都是那些有人把美元数字和失败案例一起发出来的。
← 上一篇
谷歌让每条搜索结果都多花你一次请求
下一篇 →
在真实公司代码上,最强的 agent 只拿 38.8 分
← 返回所有文章

评论

加载中...
>_