查询可见性如何改变KV-Cache压缩排名：一项匹配预算的审计

# KV-Cache压缩排名如何被查询可见性改变：一项匹配预算的审计

**来源**: https://arxiv.org/html/2607.11942

**Daming Luo**  
[email protected]  
悉尼科技大学  

**Christy Liang**  
[email protected]  
悉尼科技大学  

**Junyu Xuan**  
[email protected]  
悉尼科技大学  

###### 摘要

KV-Cache压缩方法主要在查询被附加到上下文*之后*进行压缩的协议下进行评估——即*查询可见*协议。然而，压缩KV-Cache的经济价值在于*复用*：先压缩一次文档，然后针对它回答许多未来的问题。在这种部署中，压缩必须在*查询不可见*的情况下进行——即在任何问题被看到之前。我们针对三种开放的7-9B模型（在RULER-8192上进行了144,300次配对评估，在LongBench上进行了40,800次评估，并进行了50,000次重采样配对自助法），对六种已发表的压缩方法和三个简单基线进行了匹配预算的审计。所有条件——模型、压缩比、实例、解码——都是固定的，只有评分规则不同。有三个发现：

(1) 查询可见性改变了排名：在不可见协议下，在共享相同注意力后端的五种审计方法中，只有KeyDiff始终优于最佳-of-3简单基线（31/36个单元格），而最广泛部署的方法SnapKV，平均而言*输给了*“保留开头和最近窗口”（−0.066）。

(2) 两种协议之间每种方法的性能下降*与*问题在其`score()`实现中的可见程度一致，这些信息可以从其源代码中看出：从SnapKV的Δ=+0.198（问题位于其64个token的观察窗口内）到KeyDiff的Δ=+0.011（其得分完全不包含查询项）。我们将其作为机制性假设提出——基于六种方法的序数证据，而非拟合的定律。按照这种解读，查询可见的分数部分测量的是*查询相关性*，而非缓存复用所需的*信息重要性*。

(3) 审计发现了两个可重现的方法论隐患：一个*注意力后端混淆*——将未压缩模型的sdpa切换为eager会导致RULER准确率下降−0.29，这比大多数方法与基线的差距更大，这使得我们不得不撤回对唯一需要eager后端的方法（H2O）的任何排名声明；另一个是*依赖分词器的基准长度*：RULER名义上的“8192”会超出gemma-2的位置预算最多30%，即使不进行压缩也会静默地将13个子任务中的7个归零。我们发布了审计工具、所有逐实例记录以及配对统计数据。

## 1 引言

长上下文推理受限于内存：一个8B模型在128k token时的KV缓存大小超过了模型权重本身。因此，大量文献致力于修剪缓存——对每个缓存token进行评分，移除底部分数——并报告可以丢弃50-90%的缓存而准确率损失很小。这些证据大部分是在一个安静便利的条件下收集的：在压缩运行之前，基准问题被放置在上下文中（或之后），因此压缩器的评分过程*能够看到问题*。我们称此为*查询可见*协议。它对应于一种部署场景，其中每个问题都重新读取并重新压缩文档——在这种部署中，KV缓存几乎没有任何好处，因为被分摊的主要成本（prefill）在每个问题上都要重新支付。

使得压缩缓存具有经济价值的设置恰恰相反：*一次压缩，多次查询*——一份被几十个问题审阅的合同，一个被全天查询的代码库。在那里，压缩必然是*查询不可见*的：当驱逐发生时，问题尚不存在。这个担忧本身并不新鲜。SCBench (Li et al., 2025) 在一个KV缓存生命周期基准中记录了，当查询不可用时，依赖查询的长上下文方法性能会下降，并且最近一系列方法被明确设计为查询不可见 (Kim et al., 2025; Chari and Van Durme, 2025; Devoto et al., 2025)。文献中尚未提供的是*一个测量*：每种已发表方法对查询可见性的依赖程度有多大，且独立于所有其他变量。本文提出了这个狭窄的、可审计的问题：

> *在匹配预算下，每种已发表方法报告的性能提升有多少在从查询可见压缩转向查询不可见压缩后能够保留——并且性能下降的幅度是否与该方法评分信号使用问题的方式相关？*

我们通过审计而非提出新方法来回答这个问题。将六种已发布的压缩方法（SnapKV, H2O, TOVA, ExpectedAttention, AdaKV, KeyDiff）与三个*简单*基线（随机驱逐、key-norm、StreamingLLM的“开头 + 最近窗口”）以及一个全缓存锚点进行对比，其中模型、压缩比、实例和解码完全相同；仅压缩方法不同。两种协议都在整个网格上运行，因此从不可见到可见的delta是一个*模型内、实例内*的配对对比——这是该问题所能允许的最干净的对比。

##### 贡献。

1.  一个带有简单基线锚定、精确逐实例配对、强制覆盖检查和最佳-of-选择去偏的匹配预算审计协议——以及我们在进行此类审计时必须控制的两个隐患：注意力后端混合（§6.2）和忽略了后端的去重键（§3.4）。
2.  查询依赖性的定量测量：在一个统一协议下（§4.2），三种模型上每种方法从不可见到可见的delta，以及一个机制性解读——这些delta与每种方法`score()`实现中问题的可见程度顺序一致——我们将其作为基于六种方法序数证据的假设提出，而非拟合的定律（§5）。
3.  部署协议图景：在RULER上的查询不可见压缩下，在五个后端可比的方法中，只有查询独立的方法（KeyDiff）优于最佳-of-3简单基线（31/36个单元格，+0.171），而SnapKV的平均值低于它（13/36，−0.066）；LongBench检查显示，这个图景在自然文本上的*有效性*得以保留，但不在*排他性*上——其他方法会追上或超越（§4–6.1）。
4.  两个可重现的评估隐患：一个注意力后端混淆（eager vs. sdpa 会使合并后的RULER准确率变化−0.221，这比大多数方法与基线的差距更大；这使我们无法将H2O纳入排名结论）以及依赖分词器的基准长度（RULER名义上的8192会超出gemma-2的位置预算多达30%，即使完全不进行压缩也会静默地将13个子任务中的7个归零）（§6.2–6.3）。

我们强调这篇论文不是什么。它不是一种新的压缩方法，不是对KeyDiff的背书，也不是声称查询可见的论文在其自身条件下是错误的——我们*复现*了SnapKV在查询可见下的性能提升（+0.132）。它也不是首次观察到查询可见性很重要：Li et al. (2025) 已经定性地指出了这一点。它是对该效应的受控的、逐方法的量化，以及记录了此类审计必须保持哪些条件固定才能有效。

## 2 背景与相关工作

##### KV缓存驱逐。

H2O (Zhang et al., 2023) 通过累积注意力分数保留“重击者”；SnapKV (Li et al., 2024) 通过最后64个位置（“观察窗口”）的注意力对token进行评分；TOVA (Oren et al., 2024) 使用最后一个token的注意力；AdaKV (Feng et al., 2025) 按头重新分配类似SnapKV的预算；ExpectedAttention (Devoto et al., 2025) 通过对未来查询注意力的解析估计进行评分；KeyDiff (Park et al., 2025) 完全脱离注意力，保留其*键向量*与平均键方向呈角度离群的token。StreamingLLM (Xiao et al., 2024)——保留sink + 最近窗口——在此被降级为*简单基线*，与随机驱逐和 Devoto et al. (2024) 的key-norm启发式方法并列，后者保留了*低范数*键（低键范数与高注意力相关）。所有压缩方法均按 NVIDIA kvpress 0.5.4 (NVIDIA, 2025) 中的实现执行。

##### 共享上下文评估与SCBench。

最接近的先前工作是SCBench (Li et al., 2025)，它在完整的KV缓存生命周期（多轮和多请求模式）中评估长上下文方法，并定性地报告依赖查询的压缩——尤其是SnapKV——在压缩时查询不可见时表现不佳。我们的审计更窄，并且在那一点上更锐利：我们固定模型、预算、实例和解码，配对每个记录，以简单基线为锚定，并通过自助法置信区间测量每种方法从不可见到可见的delta——将定性警告转化为可归因于每个评分规则的数量。这两项工作是互补的：SCBench变化工作负载；我们隔离协议变量。

##### 查询不可见压缩方法。

最近一系列工作直接针对复用场景设计：KVzip (Kim et al., 2025) 通过KV对重构上下文的贡献进行评分，Compactor (Chari and Van Durme, 2025) 使用查询不可见的近似杠杆分数，ExpectedAttention (Devoto et al., 2025) 对建模的未来查询分布进行积分。其中，ExpectedAttention 在我们的审计中；KVzip的多遍压缩过程不适合单遍的匹配预算框架，而Compactor未在审计的kvpress发布中实现（两者都是自然的扩展，§7）。我们的结果支持这一系列工作的动机，同时增加了一个它继承的警示：在网格上，分析上查询不可见的ExpectedAttention仍然输给了保留开头加最近的基线（§4.2），因此查询不可见的*设计*本身并不能保证在不可见协议下*获胜*——这正是审计的目的所在。

## 3 审计

### 3.1 设计原则：一个变量

审计的一个单元格固定（模型、基准轴、压缩比、协议分支），仅变化压缩方法。在一个单元格内，每种方法都以*相同的缓存预算*（统一压缩比 r ∈ {0.25, 0.5, 0.75, 0.9}）、*相同的解码方式*（贪婪，固定 max_new_tokens）回答*相同的650个实例*。一个全缓存锚点（r=0）校准每个单元格的性能上限。

### 3.2 压缩方法与基线

**六种真实压缩方法**: SnapKV, H2O (ObservedAttention), TOVA, ExpectedAttention, AdaKV, KeyDiff。

**三种简单压缩方法**: Random, Knorm (保留最低范数键), StreamingLLM (保留前 n_{sink} 个 + 最近窗口)。

整个对比的目标是 **最佳-of-3 简单基线**: 每个单元格内三个简单分数中的最大值。这故意对真实压缩方法不利——一种方法如果连三个近乎零成本的规则中最好的都无法击败，就没有部署的理由——并且我们在 §4.4 中纠正了残余的最佳-of-选择偏差。经验上，在27/36的不可见单元格中，最好的简单基线是StreamingLLM，在8个中是Knorm，在1个中是Random：因此“击败最佳-of-3简单基线”在实践中意味着“击败保留开头加最近窗口”。

### 3.3 基准、模型、协议

**RULER-8192** (Hsieh et al., 2024): 13个子任务，650个实例，分为三个轴——检索（needle变体）、聚合（CWE/FWE）、多跳（VT/QA）。

**LongBench** (Bai et al., 2024)（16个英文任务 × 50个实例）作为自然文本鲁棒性检查（§6.1）。

**模型**: Llama-3.1-8B-Instruct (Meta)，Qwen2.5-7B-Instruct (阿里巴巴)，DeepSeek-R1-Distill-Qwen-7B（推理微调；与Qwen同源——它提供统计而非架构的多样性，我们将其视为一个局限性）。第四个模型（gemma-2-9b）因基准本身的问题被排除（§6.3）。

##### 协议分支。

*查询可见*: 问题对压缩方法的评分过程可见。
*查询不可见*: 首先压缩上下文；问题在驱逐之后附加。
两个分支共享所有其他条件，因此模型内、方法内、比率内的逐实例差异仅由协议引起。

##### 规模。

RULER网格：3个模型 × 2个分支 × (1个锚点 + 9种方法 × 4个比率) × 650个实例 = 144,300条记录，零错误，零空洞（覆盖范围通过编程强制保证；在运行期间检测并填补了331个OOM空洞）。LongBench增加了40,800条记录；后端控制实验（§6.2）增加了600条。

### 3.4 统计——以及两个陷阱

所有对比都是按实例配对的（B=50,000次自助法重采样）；跨模型的“排名翻转”概率使用联合实例对齐重采样。我们遇到的两个操作陷阱值得记录，因为它们会静默地破坏这种形状的审计。

*(i) 去重键必须包含注意力后端。* 我们的去重键是（模型，方法，比率，任务，实例）；当H2O——它需要eager注意力——被回填时，简单基线单元格被标记为“已完成”而跳过，导致零个非H2O的eager行，并引入了一个我们后来不得不显式控制的未测量混淆（§6.2）。

*(ii) 必须断言覆盖范围，而非假设*：我们的检查器会比较每个方法每个单元格的精确实例集，正是它发现了331个OOM空洞。

## 4 RULER上的结果

### 4.1 锚点

全缓存分数（不可见分支）界定了每个模型的性能上限（表1）。R1-Distill的低锚点（它将其预算用于推理而非检索）在§4.5中产生了地板效应。

表 1: 每个模型和轴的FullCache锚点分数（不可见分支，r=0）。这些界定了下面单元格中任何方法可用的性能上限。

### 4.2 头条：协议决定谁赢

表2和图1给出了在36个单元格（3个模型 × 3个轴 × 4个比率）中每种方法对比最佳-of-3简单基线的判定；“获胜” = 单元格中平均配对差距为正。

表 2: 在36个单元格中每种方法对比最佳-of-3简单基线的判定。Δ 是协议效应（可见 - 不可见平均差距）。† H2O在eager后端上运行，而其他所有行在sdpa上运行；§6.2显示仅后端变化就会使分数变化超过H2O的不足，因此我们对H2O*不作排名声明*——该行仅为完整性而报告。请参阅图注。

图 1: 协议翻转。每种方法在全部36个单元格中对比最佳-of-3简单基线的平均配对差距，在部署协议（查询不可见，蓝色）和文献中的协议（查询可见，绿色）下。点标记每个方法按模型-轴-比率的配对差距，箱线图总结了它们。注意H2O运行在eager后端上，而所有其他方法运行在sdpa上；§6.2显示后端混淆本身可以使差距变化超过H2O的赤字，因此该图不包含H2O。