新上线9天前0 投票
KVFetch：为KV缓存压缩缺失的另一半，补上时间维度预取
一个被忽视的结构性盲区
随着大模型上下文窗口从几千扩展到十万甚至百万 token，KV 缓存压缩已经成为高效推理的刚需技术。目前主流方案可以归为三大流派：基于分数的淘汰（score-based eviction）、摘要补偿（summary compensation）以及卸载-召回（offload-and-recall）。
但 arXiv 新论文 KVFetch 指出了一个共同缺陷：这三类方法在决定"保留什么、召回什么"时，全部依赖内容与当前 query 的相关性。作者认为，这种设计在结构上是不完整的。
缓存有两种访问模式，现有方法只实现了一种
论文的核心洞察是：缓存天然支持两种访问方式——
- 按内容进行关联查找（associative lookup）
- 按位置进行顺序遍历（sequential traversal）
现有的 KV 压缩器几乎只实现了第一种。
这个缺口在真实场景中代价很高：检索增强生成（RAG）、代码补全、结构化数据抽取等任务，都要求模型从上下文中逐字复现标识符、字段值或代码 token。而基于内容的淘汰策略会保留这类序列的"开头"，却丢弃其"续写部分"，导致逐字复制在中途不可逆地断裂。作者将这种失败命名为 sequential forgetting（顺序遗忘）。
关键在于，这种失败无法通过更好的打分函数、更大的预算、摘要补偿或动态重打分来修复——它是压缩后剩余质量损失的主要来源。
KVFetch 怎么做
论文提出的 KVFetch 是一个免训练、即插即用的框架，为任意基于分数的压缩器打开一条时间召回通道：
- 将被淘汰的候选降级到量化冷层；
- 通过一个单调读指针检测模型是否正在主动复制；
- 将位置上的后继 token 预取到固定大小的热层槽位中，且不增加注意力计算开销。
实验结果
- 在 RULER-16K 的等预算对照下，KVFetch 将逐字复制能力从 0.8 恢复到 78.4，13 项任务平均提升 +8.4，增益集中在需要顺序访问的任务上。
- 在 LongBench 上，由于没有任务需要顺序访问，该通道保持休眠，不带来任何额外成本。
论文共 21 页、7 张图，已投稿至 ICLR 2027。
为什么值得关注
KVFetch 的价值不只是一项工程优化，而是提醒社区：KV 缓存压缩的评测与设计长期偏向了"相关性"这一单一维度。当应用越来越依赖长上下文中的精确复制（代码、ID、结构化字段）时，补齐"位置/顺序"这条通道，可能比继续堆叠打分策略更有效。
