理解 KV Cache 压缩

自回归生成看似是计算密集型任务，但大语言模型服务往往首先是内存管理问题。每生成一个 token，Transformer 的每一层都要新增对应的 Key 与 Value。缓存避免了对完整前缀的重复计算，却会随序列长度、批量大小、层数和隐藏维度持续增长。

这种增长会改变整个服务系统的形态。请求在 Prefill 阶段可能轻松容纳，却在长时间 Decode 后变得昂贵。大批量可以提高算术单元利用率，也可能先耗尽加速器内存。只有当压缩改善了系统级权衡时，它才真正有价值。

从内存公式开始

对于常规多头注意力模型，缓存大小近似正比于：

2 × 层数 × 序列长度 × KV 头数 × 头维度 × 每个数值的字节数

系数 2 对应 Key 和 Value。GQA 与 MQA 减少 KV 头数，低精度减少单值字节数，token 淘汰或合并减少有效序列长度。这些机制作用于同一公式的不同部分。

四类压缩方法

降低精度

量化 KV Cache 可以直接减少存储，并保留原有注意力模式。工程难点不仅是精度：反量化成本、算子支持、内存对齐与混合精度边界都可能抵消理论收益。

减少保留 token

淘汰方法根据近因性、注意力统计或学习到的重要性保留部分位置。它可以大幅节省内存，但存在语义风险：某一步看似不重要的信息，稍后可能重新变得关键。

共享或压缩表示

低秩方法、token 合并与潜在缓存存储更小的表示，并在使用时恢复注意力所需内容。这会把压力从内存容量转向计算，同时增强模型与系统的耦合。

架构级缩减

GQA 等模型选择在训练阶段就降低缓存规模，通常是最干净的服务优化，但未必能无成本地应用到所有已部署模型。

衡量服务结果

压缩应使用端到端指标评估：

维度	衡量内容
容量	目标上下文下的并发序列数
延迟	首 token 时间与 token 间延迟
吞吐	真实流量下每秒 token 数
质量	不同上下文位置的任务准确率
稳定性	最差情况，而非只有平均值

缓存减少 50% 并不自动意味着吞吐提升 2 倍。注意力算子、调度策略、模型权重或主机与设备之间的数据传输可能成为新的瓶颈。

设计原则

把 KV Cache 压缩视为服务架构变化。先识别真正限制来自容量、带宽、延迟还是成本，再选择方法。最好的方法能够移动瓶颈，同时不损害真正重要的工作负载。