KV Cache 压缩的第三条路：不扔不揉，ResKV 用残差重建找回被丢掉的信息

每次跑长上下文推理，看着内存曲线往上窜，经典纠结又来了：KV Cache 到底砍还是不砍。

不砍，显存先扛不住。砍了，模型回头去关注那些被抛弃的 token 时，注意力计算结果已经缺斤短两。省内存的主流办法就两条——要么直接扔掉 token（eviction），要么把一堆 token 揉成一个（merging）。扔的坏处是丢信息，揉的坏处是扰动精确值，该准的地方不准了。

最近 arXiv 上挂了一篇论文，想走一条中间路线。ResKV，全称 Reconstructing Omitted Attention Contributions for Fixed-Budget KV Cache Compression，几位作者来自学术机构，7 月 31 号刚提交。

核心想法：给定一个固定的 KV Cache 预算，别把预算全砸在保留精确 token 上，分出一小部分来做「残差缓存」。精确的部分叫 main cache，照常算注意力；残差的部分叫 residual cache，不保留完整的 key-value，而是记录被抛弃 token 在注意力计算里本该贡献的那部分——就是它们在 softmax 分子和分母里留下的 mass。

关键区别是，残差条目跟主缓存的条目参加同一次 softmax 归一化，而不是算完主注意力再加后处理 patch。这样残差在计算流程内部就把丢失的 numerator 和 denominator mass 补回来了，不是在外部打补丁。

工程上两个设计值得留意。一是每层、每个注意力头分多少残差预算，论文用一个 construction-time 的验证代理来确定——压缩时就做一轮预评估，摸清楚哪些头对丢失信息更敏感、哪些不敏感，然后动态分配。二是 decode 阶段加了一个动态门控，能根据当前 query 自适应调整残差贡献的权重，不是所有 query 吃得一样多。

评测做了 LongBench 和 RULER 两个长上下文 benchmark，覆盖 query-aware 和 query-agnostic 两种设定，对比了多个 backbone 和多种压缩方法。结论是：在同样的保留 KV 预算下，ResKV 在效果上有普遍提升，同时没有牺牲实际部署效率——包括峰值内存和长上下文吞吐。

这还只是一篇论文，不是到手就能用的工具。construction-time 的代理评估和 decode-time 的动态门控都会引入额外计算，这个开销在真实生产环境里能不能被收益覆盖，得看后续的工程实现。另外论文页面目前没有附带代码，暂时没法在自己的模型上跑一把试试。

但方向值得跟。KV Cache 压缩走到今天，eviction 和 merging 两大路线都碰到了自己的天花板——一个丢信息，一个失真。ResKV 的「主缓存 + 残差缓存」思路把压缩这件事从暴力取舍变成了精细配账：保留精确值，同时用紧凑的统计量把丢掉的部分重建出来。如果工程上能做扎实，对长上下文推理的部署成本结构会有实在影响。

后续如果有代码放出，或者被推理框架集成，值得关注。

相关链接：
- 论文页面：https://arxiv.org/abs/2607.29591