KV Cache 压缩：量化剪枝分页三合一方案

可视化演示

动态演示KV Cache压缩的核心机制，通过概览/流程/对比/趋势四种模式展示关键概念与交互流程。

缓存起源：为什么书桌总是被笔记占满

想象一位图书管理员在写读后感。每读完一个新词，他就在笔记本上添一行：左边贴索引标签（Key），右边写内容摘要（Value）。写下一个词之前，他必须先翻看所有旧笔记，才能决定接下来写什么——于是笔记本越厚，写起来越慢，书桌（显存）也越挤。这本不断变厚的笔记本，就是大模型的 KV Cache。

KV Cache 不是模型参数，而是每次请求运行时现场生成的「临时笔记」。Transformer 的每一层注意力都有自己的笔记副本；序列每多一个 token，就多一行 Key 和 Value；同时服务端每多一个并发用户，就会多一本这样的笔记。于是 KV Cache 的显存占用，几乎完全由「序列长度 × 网络层数 × 向量维度」决定。这也是上万 token 的长对话经常「爆显存」的根本原因。

书桌就那么大，所以人们开始想：能不能把笔记写得更密（量化），把不再重要的页面撕掉（剪枝），把暂时不看的页面收进抽屉（分页管理）？三招合起来，就是为了让这本笔记在有限书桌上能写得更长。

量化压缩：把字写小，同页塞下更多内容

如果把笔记本上的字从「两厘米见方」缩小到「四分之一大小」，一页纸就能装下四倍内容。KV 量化就是这个思路：把默认用 16 位浮点（FP16）存储的 Key/Value，换成 8 位整数（INT8）甚至 4 位整数（INT4）。数值精度变了，但注意力计算照样能跑，因为计算矩阵乘时会先把量化值通过缩放系数「反量化」回近似浮点，再参与运算。

只降位宽还不够——如果不做控制，很小的整数范围会把原本差异很大的数值压进同一个格子。于是常用分组量化：把一小段相邻 token 或通道分成一组，每组单独估计一个缩放系数（scale）和零点偏移（zero-point），让量化误差被约束在每组内部。这样比整层共用一个缩放系数精细得多，INT4 也能维持不错的生成质量。

缩印虽然省纸，但字变小了难免会「看错行」，这就是量化误差。好在分组量化、缩放补偿与少量浮点保留通道，能让误差控制在可接受范围。这也是 KV 压缩里最省事、收益最稳的一招。

剪枝策略：撕掉再也不翻的旧页

图书管理员发现某些页笔记从写完起一次都没被翻过，果断撕掉也不影响阅读。KV 剪枝就是这种「断舍离」：根据注意力机制给出的分数，判断哪些历史 token 的缓存是「长久冷门」，然后把它们的 K/V 从缓存中移除。

生成新词时，attention 得分越高，说明该历史 token 对当前预测越重要；反之，长期得分很低的 token 通常可以安全丢弃。H2O（Heavy Hitter Oracle）一类方法就是动态维护「高频重要 token + 最近窗口」，把重要性全局排名后只保留 Top 比例。这样既能留下「主角笔记」，又丢掉大量「背景噪音」。

撕掉的页再也找不回来，所以剪枝要留缓冲：保留最近窗口、必要时重计算被丢弃的高层信息，确保关键 token 能重新出现。牺牲一小部分精度，换取显存与速度的显著提升，在长上下文场景非常划算。

分页管理：活页夹按需取用

管理员不再把整本笔记摊开在桌面，而是用活页夹分装成若干页，手边只放当前要用的那页。PagedAttention 等方案恰好借鉴了操作系统的虚拟内存分页：把逻辑上连续的 KV 序列切分为固定大小的块，通过「逻辑块号 → 物理块号」的映射，在显存中按需装载。

这样做有两个好处：块之间不要求物理连续，显存碎片被大幅削减；不活跃的块可以换出（GPU 到 CPU 甚至磁盘），需要时再预取回来。分页的代价是多了地址映射和调度开销。块太小则页数过多、映射开销大，块太大则内部碎片多，工程上通常选 16 或 32 或 64 个 token 作为一块。

活页夹让「物理书桌」永远只需放少量页面，序列再长也不会瞬间爆桌；配合合理的预取策略，大部分翻页延迟可以被掩盖。这是三合一的第三只轮子。

三合一组合：缩字、撕页、活页一起上

三招各管一个维度：量化管「每行笔记的字有多密」，剪枝管「多少行笔记可以删」，分页管「哪些笔记可以暂时不摆在桌面」。它们作用于不同层面，因此显存收益不是相加，而是相乘。

工程上通常按「量化 → 剪枝 → 分页」组织管线：先对 KV 做 INT4 量化，缩小单条笔记的存储成本；再按注意力分数剪掉低价值 token，减少笔记总行数；最后把剩余 KV 块交给分页调度器，只让活跃页常驻显存。三者叠加后，单 token 的显存成本可以从 2 字节一路降到不到 0.1 字节。同时要留意精度协同：量化误差与剪枝误差可能叠加，分页虽不改变数值，却需要管理好页面命中率。

管理员终于不用换更大的书桌：字小了、页撕了、活页夹只留常看的两三页——即便二十万字的长篇小说也能在随身笔记本上写完全程。工程复杂度确实上升，但这正是从云端走向端侧的必经之路。

端侧部署：把长笔记搬进随身书桌

手机上几乎没有「大书桌」。移动 SoC 的共享内存通常只有 8 到 16GB，还要留给系统和 App，能分给模型的往往不到一半。没有 KV 压缩，手机最多只能流畅处理几千 token；三合一方案则让数万 token 的长文档问答成为可能。

llama.cpp、MLC-LLM 等端侧推理框架已内置 INT4/INT8 KV 量化与分页调度。评估时主要看三个指标：可服务的最大上下文长度、每 token 生成延迟、以及内存/电量占用。实际调参中，块大小、剪枝比例、量化分组大小互相牵制，需要针对具体模型做组合评测。

当管理员把笔记从图书馆大书桌搬到手机大小的随身书桌，三合一方案让长上下文不再是高端 GPU 的专利。量化负责缩小、剪枝负责减量、分页负责调度，三者合起来，就是端侧大模型「装得下、跑得动」的关键钥匙。

AI 应用场景

Python 演示

"""KV Cache 压缩演示：量化 + 剪枝 + 分页的显存估算。""" import math  class KVCacheCompressor:    """用模拟数据估算三合一后的 KV 缓存占用。"""     def __init__(self, token_count, layer_count, d_kv):        self.token_count = token_count          # 序列长度 L        self.layer_count = layer_count          # Transformer 层数        self.dim_kv = d_kv                      # 每个 K/V 向量的维度        self.fp16_bytes = 2                     # FP16 下每个数占 2 字节     def fp16_memory(self):        # 未压缩 KV 缓存字节数: 2 路 x 层 x token x 维度 x 字节        return 2 * self.layer_count * self.token_count * self.dim_kv * self.fp16_bytes     def quantized_memory(self, bit_width=8):        # 量化后按位宽比例缩放        return self.fp16_memory() * bit_width / 16.0     def pruned_memory(self, keep_ratio=0.5):        # 剪枝后只保留 top keep_ratio 的 token        keep = int(self.token_count * keep_ratio)        return self.fp16_memory() * keep / self.token_count     def paged_memory(self, block_size=16, active_blocks=4):        # 分页后只有活跃块常驻显存        total_blocks = max(1, math.ceil(self.token_count / block_size))        return self.fp16_memory() * active_blocks / total_blocks     def combined_memory(self, bit_width=4, keep_ratio=0.6,                        block_size=16, active_blocks=4):        # 三合一: 量化 x 剪枝 x 分页 三个比例相乘        total_blocks = max(1, math.ceil(self.token_count / block_size))        r_q = bit_width / 16.0        r_p = keep_ratio        r_b = active_blocks / total_blocks        return self.fp16_memory() * r_q * r_p * r_b  def main():    c = KVCacheCompressor(token_count=4096, layer_count=32, d_kv=128)    base = c.fp16_memory()    q = c.quantized_memory(4)    p = c.pruned_memory(0.6)    page = c.paged_memory(block_size=16, active_blocks=4)    final = c.combined_memory(bit_width=4, keep_ratio=0.6,                              block_size=16, active_blocks=4)    print("FP16 baseline: {:.1f} MB".format(base / 1024 / 1024))    print("INT4 quantize: {:.1f} MB".format(q / 1024 / 1024))    print("60% prune: {:.1f} MB".format(p / 1024 / 1024))    print("4 active pages: {:.1f} MB".format(page / 1024 / 1024))    print("combined: {:.1f} MB".format(final / 1024 / 1024))    print("compression ratio: {:.1f}x".format(base / final))  if __name__ == "__main__":    main()

1. return 2 * self.layer_count * self.token_count * self.dim_kv * self.fp16_bytes这是 KV 缓存的原始显存公式，2 表示 Key 和 Value 两路。
2. return self.fp16_memory() * bit_width / 16.0量化压缩只关心位宽比，INT4 就是原来的 25%。
3. keep = int(self.token_count * keep_ratio)剪枝先算出保留多少 token，再按比例估算显存。
4. total_blocks = max(1, math.ceil(self.token_count / block_size))分页把序列切成固定大小的块。
5. return self.fp16_memory() * r_q * r_p * r_b三合一的核心：三个压缩因子直接相乘，得到最终显存。
6. print("compression ratio: {:.1f}x".format(base / final))输出总压缩比，直观看到三合一带来的数量级收益。

常见误区

面试题