LRU 竟比论文说的更难被击败
LRU is harder to beat than the KV-cache papers suggest
我复现了 68,266 个来自 393 个 Claude Code 会话的请求，试图用三种新方法击败 LRU 缓存策略，但全部失败。研究发现，在容量受限场景下，真正的浪费并非来自长时间空闲的会话，而是源于间隔仅数秒的 tool-calling 循环。由于这些循环的间隔极短，基于存活预测的优化策略几乎无法发挥作用。更有趣的是，5 分钟的 TTL 机制在压力测试中从未触发，因为 LRU 总是先于超时进行淘汰。这意味着在容量瓶颈下，优化方向应从预测会话存活转向压缩、分层和调度，而非盲目追求更复杂的淘汰算法。
当容量成为瓶颈时，它主导了 TTL，而由此产生的重计算与空闲会话的故事截然不同。
HN 评论区
56- augment_me
让我有点恼火，而且我觉得像这种由 LLM 驱动的消融实验显然无法捕捉到的，是任何对过往研究的反思，或是任何能证明“这就是你能做到的最好结果”的证据。你根本不知道，你只是拉下了拉杆得到了一个结果，但这真的是最好的吗？你能做得更好吗？约束条件是什么？
作为一名独立研究者，你并没有 2200 万美元的预算去对你的问题进行大规模暴力搜索。你受限于你那小小的订阅额度，在解决问题的可能方案之海中，你甚至只能勉强探个脚。因此，让 Claude 在你的问题上运行一个自动研究循环，然后让它为你总结，这带来的价值为零，因为你根本不知道 LRU 缓存的缺点和权衡是什么，也不知道你该如何解决这个问题。
- wongarsu
根据第 4 部分的表格，似乎有些策略在更大的 KV 缓存尺寸下会开始超越 LRU。
虽然根据开头关于 Moonshot 数据的表格，所选的缓存尺寸范围是合理的，但既然发现所有测试的 KV 缓存尺寸都小到连 5 分钟的驱逐机制都从未触发，这本身就足以让人重新评估这一选择了。
- eru
> 它行不通，而它为何行不通的原因，比该策略本身更有趣。
这话说得真像出自 Claude 之口。
抛开嘲讽不谈，我很高兴我们的 AI 代理让进行这些实验并发布此类报告的成本足够低，以至于人们终于愿意发布那些“零发现”（null findings）的结果了。非常有价值！
- chaboud
我一直都在构建对延迟敏感的 LLM 系统，并且越来越依赖诸如“预填充感知”（pre-fill-considerate）机制，比如乒乓重叠异步上下文构建。对于交互机制而言，即使最坏情况很少见，它也是个问题。
一个玩具/简化版在这里：
https://github.com/chaboud/goulash
其中考虑了突变率（一种类似香农编码/排序的时间维度概念）（带有一些对 RoPE 友好的结构）。注意：那是一个度假项目，不是本职工作，但即使对于更大的模型，类似的原理也适用。
- talolard
我在一家 neocloud 公司从事推理工作，但观点仅代表个人。
经济成本决定了你在不同规模下能投入推理的工具。
举一个“粗略”的假设性例子：在 GB300 上，GPU 通过 nvlink 通信速度极快，且卡可以将 KV 缓存卸载到 DRAM 甚至磁盘，对于这类工具密集型的代理工作负载来说，速度已经“足够快”了。
这意味着，在足够大的规模和正确的场景下，我们可以对 KV 缓存使用非常激进的 TTL，同时仍能舒适地满足 SLA 和 Tokenomics 要求。