GVote：自适应KV Cache压缩——告别手动预算设定

ArXiv ID: 2509.03136

会议: ICLR 2026

发布日期: 2025年9月

摘要

KV Cache压缩是长上下文LLM推理中的关键技术，但现有方法普遍依赖手动设定固定的压缩预算（如保留50%的KV对）。这种”普罗克鲁斯忒斯之床”式的做法迫使所有workload适应同一个压缩比，导致简单请求浪费内存、复杂请求精度损失。本文提出GVote，一种自适应KV Cache压缩方案，通过蒙特卡洛采样和投票机制自动计算最优缓存预算，无需人工设定。GVote基于隐状态服从高斯分布的观察，通过采样合成查询并投票决定保留哪些键值对，在多个基准测试中以更少的内存实现了更高或持平的精度。

核心问题

固定预算的局限

固定预算 = 50%:
├─ 简单查询（"总结一句话"）: 只需10% KV → 浪费40%内存
├─ 中等查询（"分析段落"）: 需要50% KV → 刚好
└─ 复杂查询（"跨段推理"）: 需要80% KV → 丢失30%关键信息

GVote自适应:
├─ 简单查询: 自动保留10% → 节省内存
├─ 中等查询: 自动保留50% → 精度最优
└─ 复杂查询: 自动保留80% → 保持精度

方法设计

1. 高斯分布假设

GVote基于一个关键观察：LLM隐状态的分布近似高斯分布。这使得可以高效地采样合成查询来预测未来的注意力需求。

2. 蒙特卡洛投票

def gvote_compression(K_cache, V_cache, num_samples=64):
    """
    GVote自适应压缩算法
    """
    # Step 1: 从隐状态分布中采样合成查询
    synthetic_queries = sample_from_gaussian(
        mean=hidden_state_mean,
        cov=hidden_state_cov,
        n=num_samples
    )

    # Step 2: 每个合成查询"投票"保留哪些键
    votes = torch.zeros(K_cache.shape[1])  # (seq_len,)
    for q in synthetic_queries:
        attn_scores = torch.matmul(q, K_cache.T)
        # 选择top-k重要的键
        top_indices = torch.topk(attn_scores, k=dynamic_k).indices
        votes[top_indices] += 1

    # Step 3: 取所有采样查询投票的并集
    # 自适应确定保留阈值
    threshold = votes.max() * 0.3  # 自动阈值
    keep_mask = votes > threshold

    # 返回压缩后的KV cache
    return K_cache[:, keep_mask], V_cache[:, keep_mask]

3. 自适应预算确定

GVote不需要预设压缩比，保留的KV对数量由投票结果自然决定：

• 当多个合成查询一致需要某些键时，这些键被高票保留
• 当查询需求分散时，保留更多键以覆盖多样性
• 当查询需求集中时，自动提高压缩率

实验结果

在多个基准上的表现：

基准	SnapKV (固定)	StreamLLM (固定)	GVote (自适应)
GSM8K	基线	基线	更优
RULER	基线	基线	更优
LongBench	基线	基线	持平/更优

核心发现：GVote在使用约50%内存的情况下达到了与固定预算方法相当或更优的精度。

与现有方法对比

方法	预算设定	适应性	额外开销	会议
GVote	自动	高	蒙特卡洛采样	ICLR 2026
SnapKV	手动固定	低	最小	-
StreamLLM	手动固定	低	最小	-
ChunkKV	手动固定	中	块分析	NeurIPS 2025
DynamicKV	层级自适应	中	动态调整	-

部署建议

最佳适用场景：

• 服务多样化workload的推理系统（请求复杂度差异大）
• 内存受限但精度要求高的部署环境
• 与vLLM/SGLang等serving系统集成

注意事项：

• 蒙特卡洛采样引入少量计算开销
• 高斯分布假设在某些极端分布下可能不成立
• 需要维护隐状态的统计信息

个人评价

GVote抓住了一个长期被忽视的实际问题——KV Cache压缩的预算不应该是”一刀切”的。蒙特卡洛投票的方法虽然不复杂，但非常有效地将”预测未来查询需求”这个难题转化为了统计采样问题。ICLR 2026的接收也验证了这个方向的价值。从工程角度看，与现有框架的集成应该比较直接，因为GVote只是改变了”保留哪些KV”的决策逻辑，不需要修改模型架构。

---

评分: 4.20/5.0

论文: https://arxiv.org/abs/2509.03136