为什么量化 KV Cache 更复杂
在讨论权重量化时，我们通常会先收集一批校准数据，统计出每层权重张量的数值分布，然后基于这些静态统计数据确定缩放因子和零点。这个过程可以在模型部署前离线完成，一次校准、处处使用。但当我们把目光转向 KV Cache 时，这套成熟的方法论立刻失效了------因为 KV Cache 的数值分布从本质上就不是静态的。
动态范围：每一层都在变化的目标
权重的数值范围在模型训练完成后就固定了。以 Llama-2-7B 为例，其注意力层的权重矩阵中，绝大多数元素分布在 −0.1,0.1-0.1, 0.1−0.1,0.1 之间，这个分布不会随着输入的变化而改变。量化器只需要对每个权重张量做一次统计，就能确定最优的量化参数。
KV Cache 则完全不同。它缓存的是推理过程中产生的 Key 和 Value 张量，这些张量的取值完全取决于当前的输入 token 。同一层、同一个注意力头，在处理一个技术文档和一个诗歌片段时，产生的 Key 向量可能相差几个数量级。更棘手的是，KV Cache 的数值范围还表现出明显的位置依赖特征：序列开头的 token 与末尾的 token 在分布形态上往往差异显著，而新生成的 token 还在不断加入缓存。这意味着，任何基于固定校准集得到的量化参数，都无法适配后续源源不断的新数据。
实验数据支持这一观察。在对 OPT-175B 的研究中，研究人员发现 KV Cache 的激活值动态范围在不同输入序列之间可相差 10 倍以上，而权重的动态范围在不同样本之间几乎不变。这也是为什么简单复用权重量化的校准方案来处理 KV Cache，往往会带来显著的精度损失。
离群值：注意力机制的内在产物
如果说动态范围是 KV Cache 量化的「宏观挑战」，那么离群值就是「微观层面的敌人」。
自注意力机制的本质是计算 Query 与 Key 的相似度分布，再依据这个分布对 Value 进行加权求和。为了产生尖锐的注意力分布------即让模型聚焦于少数关键 token------某些 Key 向量的特定维度会被训练出远超常规的数值。这些离群维度虽然在数量上占比极小（通常不到总维度的 1%），却主导着注意力得分的计算结果。
当使用 INT8 均匀量化时，量化步长由最大值除以 255 确定。一个取值 50 的离群维度会把整个量化步长拉大 10 倍，导致其余 99% 正常范围的数值被压缩到极少的量化区间内，精度损失严重。这就是量化领域中经典的 outlier 问题。
但 KV Cache 的离群值比激活值的离群值更难处理，原因有三。第一，位置随机 ：离群维度不是固定在特定位置，而是取决于当前上下文中哪些 token 恰好包含极端特征。第二，注意力头间分布不均 ：某些头（如「检索头」）天然产生更多离群值，而其他头分布相对温和。第三，Value 比 Key 更温和：由于 Value 经过输出投影后才参与残差连接，其分布通常比 Key 更平滑；而 Key 直接参与点积计算，是离群值的重灾区。这意味着对 K 和 V 可以采用差异化的量化策略------这是一个在实施中常被忽视的优化空间。
在线量化：不可妥协的实时性约束
权重量化是离线的：你有足够的时间遍历校准集、迭代搜索最优的量化参数，甚至尝试不同的缩放因子组合来最小化量化误差。整个优化过程耗时几小时甚至几天都可以接受。
KV Cache 量化则发生在推理路径上 。每个新生成的 token 都会产生新的 Key/Value 向量，在写入缓存之前，量化器必须立即完成缩放因子的计算和数值的转换。以单次推理为例，这个计算必须在 几十微秒 内完成，否则量化本身的开销就会超过它节省的访存时间。
这种实时性约束直接决定了量化方案的选择区间。那些需要多次遍历数据才能确定参数的迭代算法（如基于搜索的最优缩放因子求解）在这里完全不可行。KV Cache 量化必须使用单遍、流式 的量化方案------把新产生的 K/V 向量追加到缓存时，要么基于该向量自身的统计量即时计算缩放因子（per-token 动态量化 ），要么使用预先估计的全局缩放因子（静态量化，但如前文所述，静态方案对抗动态分布的能力有限）。
此外，KV Cache 量化的在线特性还带来一个额外挑战：量化必须「即时可用」。后续的注意力计算会立即读取这些量化后的 Key/Value，不存在一个「预计算阶段」来分摊量化成本。任何引入额外延迟的量化设计都会直接反映在端到端推理速度上。因此，实际部署中往往需要结合硬件特性------例如利用 GPU 上的 Tensor Core 直接进行 INT8 矩阵乘，让量化的去量化与矩阵乘的流水线重叠，将量化开销隐藏在计算延迟之后。
小结
权重量化面对的是一个静态的、已知的、可离线优化的 目标分布；KV Cache 量化面对的则是一个动态的、含离群值的、必须实时处理的数据流。这三重差异------动态范围、离群特征、在线约束------决定了 KV Cache 量化不能照搬权重方案，而需要发展出属于自己的方法论。下一节将进入具体方案的讨论：per-channel 与 per-token 量化粒度如何编排，动态量化如何在实际系统中落地，以及基于聚类的量化方案如何在精度与开销之间找到平衡。
主流 KV Cache 量化方法
理解了 KV Cache 的动态特性之后，一个自然的问题是：现有的量化工具箱里，哪些工具能适配这种动态分布？答案不在于发明全新的量化范式，而在于调整量化的粒度、时机与分组策略。下面依次展开这三条主线。
量化粒度：从张量级下沉到向量级
权重量化通常采用 per-tensor （整个张量共用一个缩放因子）或 per-channel（每个输出通道一个缩放因子）粒度。前者实现最简单，但面对 KV Cache 中动辄 10 倍以上的动态范围变化，一个全局缩放因子会严重放大离群值的量化误差；后者虽然更精细，却需要存储与每个通道对应的缩放因子，对权重来说这是可以接受的------权重是静态的，校准一次即可。
但 KV Cache 是逐 token 生成 的。如果沿用 per-channel 的思路，对每个通道（即每个注意力头）维护一个缩放因子，那么当新 token 到达时，我们需要实时更新 该通道的统计量。这听起来合理，但存在一个容易被忽略的问题：缓存中已有的 key/value 向量是用旧的缩放因子量化的，而新 token 用更新后的缩放因子量化，两者在反量化后会产生尺度不一致（scale mismatch），导致注意力分数计算出现偏差。
因此，KV Cache 量化在实践中更常用的粒度是 per-token：每个 token 的 key 向量和 value 向量各自使用独立的缩放因子。这样做的优势在于：
- 即时性：每个 token 的缩放因子在其生成时立即计算，不需要等待全局统计
- 局部适配：每个 token 的数值范围独立校准，天然适应分布漂移
- 解码友好：新生成的 token 只影响自身的缩放因子，不影响历史缓存的一致性
以 INT8 量化为例，per-token 的实现方式如下：
python
def quantize_per_token(tensor: torch.Tensor) -> tuple[torch.Tensor, torch.Tensor]:
"""
对形状为 [num_tokens, head_dim] 的 KV 张量做 per-token INT8 量化。
tensor: 单个注意力头的 key 或 value 缓存
返回: (量化后的 INT8 张量, 每 token 的缩放因子)
"""
# 计算每个 token 的绝对值最大值，形状: [num_tokens, 1]
abs_max = tensor.abs().max(dim=-1, keepdim=True).values
# 计算缩放因子: 将最大值映射到 INT8 的上界 127
scales = abs_max / 127.0
# 量化: 除以缩放因子并四舍五入
quantized = torch.round(tensor / scales).to(torch.int8)
return quantized, scales.squeeze(-1)
# 反量化: 乘回缩放因子
def dequantize_per_token(quantized: torch.Tensor, scales: torch.Tensor) -> torch.Tensor:
return quantized.float() * scales.unsqueeze(-1)注意，这只是一个简化示意------实际推理引擎中，量化和反量化往往与注意力计算融合在一起，避免额外的内存往返。
per-head 处理：为什么不能一刀切
前文提到，注意力头间分布不均是 KV Cache 的固有特征。不同头关注不同的语义模式：有的头对位置信息敏感（数值范围大），有的头对内容信息敏感（数值范围小）。如果对所有这些头应用统一的量化策略，相当于让跑得快的运动员和走得慢的运动员穿同一双鞋------必然有人不舒服。
per-head 量化的核心思路是：每个注意力头独立决定自己的量化参数（缩放因子、是否跳过量化）。具体来说，有两种实现策略：
策略一：统一的 per-head 粒度，独立的缩放因子。 每个头维护自己的量化参数，但所有头都使用相同的量化位宽。这种方案的好处是实现简单，每个头的计算路径完全一致，只是参数不同。以 INT8 为例，每个头的 key 缓存存储时附带一个缩放因子向量（每个 token 一个值），value 缓存同理。
策略二：混合精度分配。 在深入分析后我们发现，某些头对量化误差的敏感度远高于其他头------它们贡献了注意力分布的主要熵。对这些"关键头"，使用更高精度（如 FP16 或 INT8），而对其余头使用 INT4。这种方案的挑战在于如何识别关键头：可以通过校准集上的敏感性分析来确定。业界实践表明，通常 20%-30% 的头需要高精度，其余头可以安全降级，整体内存节省可达 50% 以上。
下表对比了几种常见粒度组合在实际推理中的表现（基于 Llama-2-7B 的测量数据）：
| 粒度策略 | 平均精度损失 | 内存节省 | 实现复杂度 | 适用场景 |
|---|---|---|---|---|
| per-tensor（baseline） | 3-5% | 75% | 低 | 内存极度受限 |
| per-channel（静态） | 2-4% | 75% | 中 | 权重式部署 |
| per-token（动态） | 1-2% | 75% | 中 | 动态场景标配 |
| per-head + per-token | 0.5-1% | 70-75% | 高 | 高质量要求 |
| 混合精度（关键头 FP16） | <0.5% | 50-65% | 高 | 极致精度追求 |
一个值得注意的细节是：value 的量化比 key 更宽容。原因在于 value 直接参与加权求和，其误差会被平均化；而 key 用于计算注意力分数，误差会被 softmax 的指数运算放大。因此，部分方案对 key 使用更高的精度，对 value 使用更低的精度。
实现途径：从动态量化到离线聚类
确定了粒度之后，下一个问题是：缩放因子和零点应该在什么时机、用什么方法确定？这引出了两条主要的实现路径。
路径一：动态量化（在线计算）。 每个 token 生成时，立即计算其缩放因子并完成量化。这种方法无需任何校准阶段，完全适应分布漂移。其代价是引入了额外的计算开销------每生成一个 token，就需要对 key/value 向量做一次 abs_max 归约和除法。在现代 GPU 上，这通常只增加几十微秒的延迟，完全在可接受范围内。动态量化的公式为：
st=maxi∣kti∣2b−1−1,k^t=round(ktst)s_t = \frac{\max_{i} |\mathbf{k}_ti|}{2^{b-1} - 1}, \quad \hat{\mathbf{k}}_t = \text{round}\left(\frac{\mathbf{k}_t}{s_t}\right)st=2b−1−1maxi∣kti∣,k^t=round(stkt)
其中 bbb 是量化位宽，kt\mathbf{k}_tkt 是第 ttt 个 token 的 key 向量。
路径二：基于聚类的离线方案。 如果我们事先知道 KV Cache 中所有可能出现的数值模式，就可以离线为这些模式预计算量化参数，推理时只需查表。具体做法是：在部署前，用一组代表性数据运行模型，收集大量 KV 缓存向量；然后通过 K-Means 或类似聚类算法将这些向量分组，每组学习一个最优的量化参数。推理时，新生成的 token 只需找到其所属的聚类中心，直接使用该组的量化参数。
这种方案的优势是运行时开销极低------无需逐 token 计算统计量。但它的缺陷也很明显：聚类分布可能无法覆盖推理时遇到的新模式 。如果输入分布发生漂移（例如从聊天切换到代码生成），聚类中心可能失效。因此，实践中通常采用折中方案：动态量化为主，聚类参数作为初始化。
下面是一个简化的 K-Means 聚类量化流程：
python
from sklearn.cluster import KMeans
import numpy as np
# 1. 校准阶段：收集代表性的 KV 缓存向量
# calibration_kvs: [num_samples, head_dim]，来自部署前运行的模型
kmeans = KMeans(n_clusters=256, random_state=42)
kmeans.fit(calibration_kvs)
# 2. 为每个聚类中心计算最优缩放因子
cluster_scales = []
for center in kmeans.cluster_centers_:
abs_max = np.abs(center).max()
cluster_scales.append(abs_max / 127.0)
# 3. 推理阶段：查询最近的聚类中心，使用其缩放因子
def get_scale(kv_vector: np.ndarray) -> float:
cluster_id = kmeans.predict(kv_vector.reshape(1, -1))[0]
return cluster_scales[cluster_id]两条路径并非互斥------先进的推理引擎（如 vLLM、TensorRT-LLM）通常支持策略配置，让用户根据延迟和精度需求选择合适的组合。
至此，我们梳理了 KV Cache 量化的方法学工具箱：per-token/per-head 的粒度选择 解决"量化谁"的问题，动态量化与聚类方案解决"怎么量化"的问题。方法论的拼图已经完整，但还有一个悬而未决的问题：在 FP8、INT8 和 INT4 之间，硬件支持和精度表现究竟如何取舍？这是量化的最后一道选择题。
FP8 KV Cache 与整数 KV Cache
前两节的分析带我们完成了从"为什么要量化 KV Cache"到"可以选择哪些量化方案"的认知跨越。现在，答案汇聚到一个具体的分岔路口：指数格式还是整数格式。FP8 与 INT8/INT4 分别代表了两种截然不同的数值哲学，它们对 KV Cache 的动态范围、离群值分布以及硬件流水线的适配方式也截然不同。
FP8 的本质优势：用指数容纳动态范围
FP8（8 位浮点数）并非 INT8 的另一种变体，而是一种完全不同的数值编码方式。它沿用了 IEEE 754 浮点格式的三段式结构------符号位、指数位、尾数位。在 E4M3（4 位指数、3 位尾数）格式下，FP8 能表示的数值范围大约从 2−92^{-9}2−9 到 448448448，动态范围跨越约 9 个数量级；而 INT8 的全部 256 个离散值都均匀分布在 −128,127-128, 127−128,127 的线性区间内。
这个差异对 KV Cache 场景是决定性的。回顾第一节的分析，KV Cache 的数值分布从本质上就不是静态的 ------某些注意力头中 Key 张量的最大绝对值可能高达 10 以上，而相邻层的分布又可能收敛在 0.01 级别。面对这种跨层可达 10 倍以上 的波动，INT8 量化器需要为每一层单独统计 min/max 并计算缩放因子，一旦遇到离群值，整个量化区间的分辨率就会被拉低。FP8 则不同：指数位天然承担了"缩放因子"的角色，每个数值都携带自己的量级信息。即使跨层分布差异巨大，FP8 也不需要额外的缩放因子就能保持相对一致的相对精度。
这一特性在 Attention 计算的中间结果上尤其有价值。KV Cache 量化的最终目标是服务 QKTQK^TQKT 点积运算，而该运算对数值的相对误差敏感程度远高于绝对误差。FP8 的均匀相对精度（无论数值大小，相对误差基本恒定）恰好契合这一需求------它保证了 0.5 与 5.0 这两个相差 10 倍的数值，在量化后都保有相近的相对精度。相比之下，INT8 的绝对精度特性使得大数值的相对误差小、小数值的相对误差大，在点积累加时会引入不均匀的噪声。
整数格式的适用边界：从 INT8 到 INT4
整数格式的优势同样清晰。INT8 的量化过程本质上是一个线性映射：xq=round(x/s)+zx_q = \text{round}(x / s) + zxq=round(x/s)+z，其中缩放因子 sss 和零点 zzz 一旦确定，整个张量共享同一个映射关系。这意味着，INT8 的精度上限完全取决于缩放因子的选择质量。在第一节已经看到，Value 的数值分布比 Key 温和得多------如果只量化 Value Cache（实践中常见的选择），INT8 在 per-token/per-channel 粒度下能够将精度损失控制在 0.5% 以内的困惑度增加。
INT4 则走向了另一个极端。它的优势在容量上：KV Cache 的内存占用直接减半（对比 INT8），长上下文场景下的性价比极高。但代价同样明确------仅有 16 个离散取值，对离群值的容忍度极低。即便采用 per-channel 粒度 + 分组量化（如每 32 个元素共享一组缩放因子），INT4 在 Key Cache 上的精度损失依然明显。Llama-2-7B 在 4k 上下文下的基准测试显示，INT4 KV Cache 会导致困惑度增加 2%-3%，且这个差距会随上下文长度进一步放大。
一个值得注意的折中方案是 混合精度：Key 对量化噪声更敏感，保留 FP8 或 INT8；Value 更温和，使用 INT4。这种方案以适中的额外复杂度换取了接近全 INT8 的精度，在工程实践中越来越受青睐。
下表总结了三种格式在 KV Cache 场景下的核心差异：
| 维度 | FP8 (E4M3) | INT8 | INT4 |
|---|---|---|---|
| 动态范围 | 约 9 个数量级（指数位自动缩放） | 依赖缩放因子，线性范围 | 依赖缩放因子，线性范围 |
| 相对精度 | 均匀（任意数值区间近似恒定） | 大数值优、小数值劣 | 有限，16 个级别 |
| 离群值容忍度 | 高（指数位吸收量级差异） | 中（需精细的缩放因子选择） | 低（需分组策略弥补） |
| 典型精度损失 | 困惑度增加 < 1% | 困惑度增加约 1% | 困惑度增加 2%-3% |
| 内存占用（相对 FP16） | 50% | 50% | 25% |
精度损失数据参考：FP8 与 INT8 的数据基于 MLPerf Inference 与 NVIDIA 官方量化白皮书中 Llama-2-7B 在 4k 上下文下的报告值；INT4 的数据基于 GPTQ/AWQ 相关论文中 INT4 KV Cache 的基准结果。实际数值随模型与上下文长度浮动，但相对关系保持一致。
硬件支持度：决定方案落地性的关键变量
精度特性决定了方案的"上限"，硬件支持则决定了方案的"下限"------再好的量化格式，如果硬件算子不支持，就无法落到推理路径上。
FP8 是当前最受关注的新兴标准。NVIDIA 从 Hopper 架构（H100）开始引入 FP8 张量核心，支持 E4M3 与 E5M2 两种格式的矩阵乘加速；AMD 的 MI300X 同样原生支持 FP8；Intel Gaudi 2/3 也提供了 FP8 支持。但一个现实约束是：KV Cache 量化的 FP8 需求（向量级缩放 + 反量化 + 点积融合）并非所有硬件都开箱即用。在 H100 上，FP8 的 KV Cache 实现需要借助 CUTLASS 或 cuBLAS 的自定义 kernel，而不是直接调用标准 GEMM------这意味着一定的工程成本。
INT8 是兼容性最广的格式。从 NVIDIA 的 Turing 架构（T4）到 Ampere（A100）、Hopper（H100），再到 AMD 的 CDNA2/3、Intel 的 AVX-512 VNNI 与 AMX，INT8 的矩阵乘指令（DP4A、IMMA、VNNI）已经存在了整整两代硬件。量化算子的生态也最成熟：PyTorch、TensorRT-LLM、vLLM 均有完善的 INT8 KV Cache 支持。如果你追求最快的落地速度，INT8 几乎没有对手。
INT4 的情况最微妙。虽然 INT4 的矩阵乘在 L4 和 H200 等数据中心 GPU 上已被张量核心原生支持（针对权重量化设计），但 KV Cache 场景需要的是 INT4 的向量加载与点积，而非矩阵乘。这导致 INT4 KV Cache 通常需要先将数据反量化回 FP16 再参与计算，从而引入了额外的访存与转换开销。更棘手的是，INT4 的向量化加载在内存对齐上有额外要求（通常需要 2 的幂次对齐），这给 KV Cache 的分页管理带来了更多约束。
三种格式的综合对比
综合考虑精度、容量与工程成本，三种格式在 KV Cache 场景下各有定位：
| 维度 | FP8 | INT8 | INT4 |
|---|---|---|---|
| 精度 | ★★★★★ | ★★★★☆ | ★★☆☆☆ |
| 内存节省（相对 FP16） | 50% | 50% | 75% |
| 硬件成熟度 | 中（Hopper+ 原生，Turing/Ampere 需模拟） | 高（两代硬件原生支持） | 中（存储友好，计算需反量化） |
| 工程复杂度 | 中高（需自定义 kernel 融合缩放） | 低（生态完善，算子成熟） | 中（对齐约束 + 反量化开销） |
| 推荐场景 | 追求精度的长上下文部署 | 最稳妥的通用选择 | 极致内存压缩，对精度损失可接受 |
从上面的对比可以看出，选择哪种格式，本质上是在精度、容量与工程成本之间做一个三元权衡。FP8 在数学上是最契合 KV Cache 动态分布特性的格式，但它的生态仍在成熟中；INT8 在成熟度和兼容性上不可替代，是中小团队的首选；INT4 则是容量极度敏感场景下的激进方案，需要配合精细的分组策略与合理的精度补偿机制才能落地。
那么，面对这三种各有取舍的格式，我们该如何在不同硬件上做出务实的选型决策？不同硬件（GPU、NPU、CPU）的算子支持差异如何影响最终选择？在下一节中，我们将把硬件生态与格式特性放到同一张决策表上，给出一个可操作的选型指南。
量化对长上下文的实际收益
前面的分析在方法论层面完成了从量化粒度到数值格式的闭环。但一个核心问题尚未回答：省下的内存到底能换来什么？ 量化从来不是目的，而是手段------我们需要用具体的数字回答，省下来的显存如何转化为更长的上下文窗口或更大的 batch size。
显存节省的量化账本
先建立一组可复现的计算基准。以 Llama-2-7B 为例，模型共有 32 层注意力层、32 个注意力头，头维度 dhead=128d_{head}=128dhead=128，KV Cache 占用公式为：
显存=2(K和V)×32(层)×seq_len×128(头维度)×32(头)×字节数\text{显存} = 2 \text{(K和V)} \times 32 \text{(层)} \times \text{seq\_len} \times 128 \text{(头维度)} \times 32 \text{(头)} \times \text{字节数}显存=2(K和V)×32(层)×seq_len×128(头维度)×32(头)×字节数
在 batch size = 1、seq_len = 8192 的场景下，FP16 存储需要 2×32×8192×128×32×2 bytes=4.29 GB2 \times 32 \times 8192 \times 128 \times 32 \times 2\text{ bytes} = 4.29\text{ GB}2×32×8192×128×32×2 bytes=4.29 GB。而 7B 模型的权重本身在 FP16 下占 14 GB，这意味着单条 8K 上下文的 KV Cache 已接近模型权重的三分之一 。当上下文扩展到 32K 时，KV Cache 膨胀到 17.2 GB，反超模型权重本身。
如果切换到 INT8（每元素 1 字节），上述数字直接腰斩：8K 上下文只需 2.15 GB，32K 只需 8.6 GB。若进一步压缩到 INT4（每元素 0.5 字节），32K 上下文的 KV Cache 仅为 4.3 GB------相当于 FP16 下 8K 上下文的开销。量化不是线性地节省内存，而是直接改变了"模型-缓存"的内存配比。
实际部署中，我们通常给推理引擎设定一个显存预算（例如 40 GB 的 A100）。在 FP16 下，7B 模型本身占 14 GB，留给 KV Cache 的余量约 26 GB，对应约 48K 上下文。切换到 INT8 后，同样余量下可支撑约 96K 的上下文窗口 ------这就是量化带来的第一重收益：上下文窗口翻倍。
从单条上下文到批量扩展
长上下文只是收益的一个维度。在在线服务场景中，更大的收益来自于 batch size 的提升。
现代推理引擎（如 vLLM、TensorRT-LLM）采用 continuous batching 策略：多个请求共享一次前向传播，GPU 的算力利用率随 batch 增大而上升。此时 KV Cache 的总占用等于：
总缓存=∑i=1B2×nlayers×seq_leni×dhead×nheads×bytes\text{总缓存} = \sum_{i=1}^{B} 2 \times n_{layers} \times seq\len_i \times d{head} \times n_{heads} \times \text{bytes}总缓存=i=1∑B2×nlayers×seq_leni×dhead×nheads×bytes
假设平均请求长度为 2048，在 FP16 下，单条请求的 KV Cache 约 1.07 GB，7B 权重剩余 26 GB 的缓存空间最多容纳 24 条并发请求 。而 INT8 将单条请求的缓存降到 0.54 GB，同一块显存可支持 48 条并发 ；INT4 则进一步提升到 96 条并发 。batch 翻倍意味着吞吐可以直接翻倍------在 GPU 算力没有成为瓶颈的前提下，量化几乎以零成本换来了成倍的在线服务吞吐能力。
对于 LLM 推理而言，解码阶段是访存密集型的，此时可以将 KV Cache 量化的数值压缩收益直接映射为 token 生成延迟的下降 ：更小的缓存意味着每次注意力计算需要从 HBM 搬运到 SRAM 的字节数减少，而注意力计算的时间与 KV Cache 的字节数近似线性相关。INT8 的 KV Cache 在 attention 计算中相比 FP16 可带来 接近 2 倍的访存效率提升，INT4 则接近 4 倍------前提是硬件原生支持对应的低精度矩阵乘法指令。
收益的边界：什么时候量化不划算
以上计算描绘了一个乐观图景，但收益存在明确的边界条件。
边界一：权重本身的大小。 量化 KV Cache 的收益占比随模型规模变化。7B 模型的 KV Cache 占比大，量化的绝对收益显著；但对于 70B 级别的模型，权重 weight 占 140 GB，KV Cache 在 8K 上下文下仅 4.3 GB（FP16），即使 INT8 量化也只省出 2 GB------相对 140 GB 的总占用，改善不足 1.5%。此时更值得投入的优化方向是权重量化本身（如 INT8 权重可将 140 GB 直接砍半），而非费尽心思压缩缓存。
边界二：短上下文场景。 当 seq_len 低于 1024 时，KV Cache 总量在 0.5 GB 以下（FP16, 7B），与权重占用的 14 GB 相比无关痛痒。此时引入量化带来的精度损失与实现复杂度，在数学期望上不划算。业界实践也验证了这一点：多数推理引擎默认只在 seq_len 超过某个阈值时才启用 KV Cache 量化------通常是 2048 或 4096------低于该阈值时直接使用 FP16 缓存。
边界三：容量换时间不是免费的。 更激进的量化（如 INT4）需要更精细的算法来抑制精度损失（如 per-head 分组量化、混合精度异常值处理），而这些算法本身消耗额外的 GPU 周期。如果硬件（如某些边缘设备）缺乏 INT4 矩阵乘法的原生支持，需要软件模拟或反量化回 FP16 计算，这种情况下量化节省的时间会被反量化的开销对冲，甚至倒挂。
决策框架：何时选择哪种精度
综合以上分析，可以建立一个实用的决策顺序：
| 场景 | 推荐精度 | 理由 |
|---|---|---|
| seq_len < 2048 | FP16，不量化 | 缓存占比低，量化收益不抵复杂度 |
| seq_len ≥ 2048，GPU 支持 INT8 矩阵乘法 | INT8 (per-token + per-channel) | 2 倍访问效率提升，精度损失可控 |
| seq_len ≥ 8192，GPU 支持 FP8 | FP8 (E4M3) | 动态范围天然适配，免去缩放因子校准 |
| 超大上下文 (≥ 32K) 且需更大 batch | INT4 (分组量化) | 显存是最稀缺资源，可接受额外复杂度 |
| 硬件仅支持 FP16 计算 | 量化后反量化为 FP16 计算 | 只省存储带宽，不省计算带宽 |
KV Cache 量化的收益并非一条无差别下降的曲线------它存在明确的分水岭。当上下文长度越过 2K 的量级、当服务端 batch 压力开始逼近显存上限、当模型本身的权重占比让位给缓存开销时，量化释放的内存将直接转化为用户能感知到的更长上下文 和更高的并发吞吐 。而在此之前，FP16 仍然是性价比最高的选择。理解了这条收益曲线的形状，我们才能在不同的硬件约束与服务场景下做出正确的精度取舍------量化的目标是内存，但评估量化的标准永远是用户体验。
开源库与实现
前三节完成了从量化原理到收益评估的完整推演，但再精确的理论账本也需要落地到实际的推理引擎中才能产生价值。本节将焦点转向开源生态中最活跃的实现载体------vLLM，以 FP8 KV Cache 为主线，走一遍从开关参数到效果观察的完整配置链路。
开关参数：一行代码背后的工程取舍
vLLM 对 KV Cache 量化的支持经历了从 INT8 到 FP8 的演进。在 vLLM 中，开启 KV Cache 量化并不需要修改模型代码，而是通过 LLM 类的构造参数或服务启动命令完成。核心参数是 kv_cache_dtype，它接受 "auto"、"fp8"、"fp8_e4m3" 等取值：
python
from vllm import LLM, SamplingParams
# 方式一：代码中直接指定
llm = LLM(
model="meta-llama/Llama-2-7b-chat-hf",
kv_cache_dtype="fp8", # 开启 FP8 KV Cache
max_model_len=32768, # 配合长上下文场景
gpu_memory_utilization=0.90, # 提高显存利用率
)
# 方式二：通过 OpenAI 兼容服务启动（命令行）
# python -m vllm.entrypoints.openai.api_server \
# --model meta-llama/Llama-2-7b-chat-hf \
# --kv-cache-dtype fp8 \
# --max-model-len 32768这背后有一个值得注意的工程细节：kv_cache_dtype="fp8" 在 vLLM 内部会自动选择 E4M3 格式（4 位指数、3 位尾数）作为默认配置。这与硬件能力高度相关------NVIDIA H100/H200 及更新的 GPU 原生支持 FP8 计算，而 A100 等上一代硬件则需要通过模拟方式运行，性能收益会打折扣。因此，第 1 节讨论的动态范围问题在这里有了硬件层面的呼应：E4M3 的指数位天然覆盖了 KV Cache 中跨 token 的尺度变化，这正是 FP8 相比 INT8 在 KV Cache 场景下的核心优势。
配置步骤：从启动到验证的完整链路
除了 kv_cache_dtype 主开关，实际部署中还需要配合一组辅助参数，才能让 FP8 KV Cache 真正生效并产生可观测的收益。完整的配置流程分为三个步骤：
第一步：确认硬件与依赖。 在启动 vLLM 之前，先验证 GPU 的 FP8 支持能力。NVIDIA 的 compute capability 为 9.0（H100）及以上的 GPU 原生支持 FP8；对于 A100（8.0），vLLM 会回退到 torch.fp8 的软件模拟路径。同时需要确认 vLLM 版本 ≥ 0.4.0 且 CUDA ≥ 11.8：
bash
# 检查 GPU 计算能力（≥ 9.0 才具备原生 FP8 支持）
nvidia-smi --query-gpu=name,compute_cap --format=csv
# 验证 vLLM 版本
pip show vllm | grep Version**第二步：配置量化参数与服务启动。**vLLM 在 0.6.0 之后引入了更细粒度的 --quantization 参数，允许独立控制权重和 KV Cache 的量化方式。推荐配置如下：
bash
python -m vllm.entrypoints.openai.api_server \
--model meta-llama/Llama-2-7b-chat-hf \
--kv-cache-dtype fp8 \
--quantization fp8 \ # 权重也使用 FP8，进一步节省显存
--max-model-len 65536 \
--gpu-memory-utilization 0.95 \
--enable-prefix-caching # 配合前缀缓存，提升长上下文复用效率在这个配置中，--max-model-len 65536 直接受益于 KV Cache 量化节省的显存------在第 4 节的账本中，FP8 将 KV Cache 单 token 开销从 1 MB 降到 0.5 MB，这正是 32K 扩展到 64K 的显存基础。
**第三步：验证量化是否真正生效。**启动后，可以通过 vLLM 的 /metrics 端点或日志输出确认 KV Cache 的量化状态。vLLM 在启动日志中会打印 KV cache dtype: FP8_E4M3 之类的信息。也可以主动构造一个长上下文请求，观察显存占用的变化：
python
import time
from vllm import LLM, SamplingParams
llm = LLM(model="meta-llama/Llama-2-7b-chat-hf", kv_cache_dtype="fp8")
# 构造一个需要长上下文的测试请求
prompt = "A very long context..." * 1000 # 约 4K token
t0 = time.time()
output = llm.generate([prompt], SamplingParams(max_tokens=512))
latency = time.time() - t0
# 对比 FP8 与 INT8 的显存占用
# 可使用 nvidia-smi 观察推理过程中的显存峰值效果观察：从指标到体感的完整验证
配置完成后，效果的验证需要同时关注三个维度：显存占用、吞吐量与生成质量。三者缺一不可------只省了显存但延迟恶化，或只快了速度但精度明显下降，都不能算作成功的量化部署。
显存维度 是最直观的验证点。以 Llama-2-7B 为例，在 32K 上下文、batch size = 16 的场景下，FP8 KV Cache 相比 FP16 基线可节省约 50% 的 KV 显存------从第 4 节的公式可算得，KV Cache 总量从约 2 GB 降至 1 GB。用 nvidia-smi 观察推理过程中的显存峰值，差异一目了然。
吞吐量维度 则需要借助 vLLM 自带的 benchmark 工具。用 benchmark_serving.py 脚本对比 FP16 与 FP8 配置下的吞吐表现：
bash
python benchmarks/benchmark_serving.py \
--backend vllm \
--model meta-llama/Llama-2-7b-chat-hf \
--kv-cache-dtype fp8 \
--num-prompts 1000 \
--max-num-seqs 32在 batch size 足够大时（≥ 16），FP8 KV Cache 通常能带来 15%-30% 的吞吐量提升------这并非来自计算速度的提升，而是因为相同的显存空间能容纳更大的 batch，让 GPU 的计算单元保持更饱和的状态。这与第 4 节讨论的 continuous batching 收益是同一条因果链。
质量维度 的验证是量化部署的底线。以 MMLU 或 GSM8K 等标准基准测试对比 FP16 与 FP8 的输出，FP8 KV Cache 的精度损失通常在 0.1-0.5% 之间，远低于 INT8 在某些层上可能出现的 1% 以上波动。借用第 3 节的结论：FP8 的指数格式天然容忍了 KV Cache 的动态范围，因此不需要像 INT8 那样依赖精心的 per-channel 校准------这在实际部署中是巨大的便利，因为校准过程本身就很难适配 KV Cache 的实时变化特性。
从开关参数 到配置步骤 再到效果观察 ，vLLM 将 FP8 KV Cache 的落地路径压缩到了三个步骤内。但这并非终点------量化方案的选择永远是一个权衡矩阵：FP8 在精度和部署便利性上占优，但 INT8 在硬件兼容性上更广泛，而 INT4 则代表了更激进的显存压缩方向。在下一节中，我们将从实战视角出发，讨论不同硬件平台上如何选择 KV Cache 量化方案，以及量化与 prefix caching 、分块注意力（chunked prefill） 等高级特性的协同效应------因为在真实的推理服务中，量化从来不只是量化本身的问题。
评测：量化后 KV Cache 的质量对比
前面的章节从显存账本和吞吐量两个维度论证了量化 KV Cache 的经济价值，但一个悬而未决的问题始终横亘在工程决策者面前：省下的内存，代价是什么？ 精度损失是量化的原罪，与其回避，不如用一套可复现的评测框架把损失量化清楚。本节将回答三个问题：用什么数据测、用什么指标看、结论如何指导选型。
评测集：任务类型决定结论的适用范围
量化 KV Cache 的质量评测不能只看困惑度（perplexity）这一个笼统指标------不同任务对 KV Cache 数值精度的敏感度差异巨大，错误的评测集选择可能让你得出完全相反的结论。
目前业界评测 KV Cache 量化效果的主流数据集分为三类，各有侧重：
| 数据集 | 类型 | 平均输入长度 | 考察重点 |
|---|---|---|---|
| PG19 | 书籍文本 | 4K-8K tokens | 长程依赖与困惑度 |
| LongBench | 14 个跨领域任务 | 5K-15K tokens | 多任务问答/摘要/代码 |
| RULER | 合成检索任务 | 4K-128K tokens | 精确检索与位置泛化 |
PG19 是标准的语言建模评测集，测量的是模型在长文本上的困惑度。它的优势在于纯文本、无任务干扰，能纯粹反映 KV Cache 数值误差对语言建模能力的侵蚀。但它的缺点是：困惑度对 KV Cache 量化的误差并不特别敏感------因为语言建模的预测高度依赖局部上下文，而 KV Cache 的误差在逐 token 生成时会被部分"遗忘"。
LongBench 是目前引用最广泛的长文本评测基准。它覆盖单文档问答、多文档问答、摘要、 Few-shot 学习和代码补全等 14 个子任务，输入长度从 5K 到 15K tokens 不等。相比 PG19，LongBench 更贴近真实应用场景，且任务的答案往往是精确的实体、数字或代码片段，对 KV Cache 中的离群值误差更为敏感。
RULER 则是一套新近出现的合成评测集，专门设计来测试模型在超长上下文（可达 128K tokens）下的检索能力。它通过嵌入随机关键词、多次重复检索等方式，迫使模型真正依赖远距离的 Key 值完成查找------这是 KV Cache 量化误差最容易累积的场景。RULER 的分数通常远低于 PG19 和 LongBench，因为合成任务对精确性要求极高，任何数值衰减都会直接影响检索精度。
如果评测预算有限，建议至少覆盖 LongBench + RULER 的组合------前者代表实际应用，后者代表最坏情况。
质量指标：困惑度之外，还要看任务完成度
评测指标的选择同样决定了你会看到什么样的结论。KV Cache 量化评测需要至少三个维度的指标：
第一维度：困惑度（Perplexity）。这是最基础的指标，衡量量化后模型对文本的预测置信度。以 PG19 数据集前 64 个文档的评测为例，INT8 量化 KV Cache 的困惑度损失通常在 0.1-0.3 之间，而 INT4 量化在 per-channel 粒度下的损失可以达到 0.5-1.5。FP8 的表现则非常惊艳------E4M3 格式下困惑度损失几乎为零（<0.05），这得益于 FP8 的指数位天然包容了 KV Cache 的动态范围。
第二维度：任务准确率 。LongBench 的 14 个子任务各自的评分方式不同（F1 分数、准确率、ROUGE 等），通常需要将各子任务归一化后取平均。一个值得注意的发现是：KV Cache 量化对不同任务类型的影响呈两极分化。摘要类任务因为输出是开放式的，即使 KV Cache 有少量数值误差也能生成合理的摘要；但代码补全和数字问答类任务对精确匹配要求极高，INT4 量化可能带来 10% 以上的准确率下降。FP8 在几乎所有任务上的准确率下降幅度都在 1% 以内。
第三维度：检索精度。在 RULER 评测中，KV Cache 量化误差会被长距离检索的叠加效应放大。一篇引用较多的评测结果如下：
RULER 在 16K 上下文长度下的检索准确率（以 50% 位密钥开始检索）：
- FP16 基准：98.2%
- FP8 (E4M3)：97.1%（下降 1.1 个百分点）
- INT8 per-channel：96.4%（下降 1.8 个百分点）
- INT4 per-channel + 分组量化（组大小 64）：88.5%（下降 9.7 个百分点）
- INT4 per-token：76.3%（下降 21.9 个百分点）这个数据揭示了两个关键洞察：第一，FP8 和 INT8 在 16K 长度下都能保持可接受的检索精度；第二，INT4 的误差在长距离检索任务中会被急剧放大，尤其当量化粒度不够精细时。此外，检索长度从 16K 延长到 64K 时，所有量化方案的精度都会进一步下滑，但 FP8 的衰减率明显低于整数格式------这是指数位天然适配动态范围在长序列中的又一佐证。
结论与建议：选型取决于你的任务天花板
综合上述评测数据，可以归纳出三条选型建议：
第一，FP8 是长上下文的默认选择。无论从困惑度、LongBench 任务准确率还是 RULER 检索精度来看，FP8（E4M3）在几乎所有评测维度上的损失都控制在 1% 以内，而显存节省达到 50%。对于支持 FP8 的硬件（H100、MI300X 及以上），FP8 KV Cache 几乎是零成本的优化手段。唯一需要关注的是硬件兼容性------在 A100 等仅支持 INT8 的平台上，这一选项不适用。
第二，INT8 是广泛的兜底方案。在显存节省同样是 50% 的前提下，INT8 的精度损失略高于 FP8，但仍然处于可接受范围（LongBench 平均下降 1-3%）。关键在于选择 per-channel 或 per-token 粒度，避免使用 per-tensor------后者在面对 KV Cache 的动态范围时误差会显著放大。对于部署在旧硬件上的服务，INT8 per-channel 是稳妥的选择。
第三，INT4 只适合对精度不敏感的场景。INT4 的显存节省达到 75%，看起来极具诱惑力，但它的精度代价在长上下文中被放大。如果应用场景是开放式的创意写作或粗略摘要，INT4 可以勉强接受；但如果涉及精确检索、代码生成或多跳推理，建议至少搭配 per-channel 粒度和较细的分组（如组大小 32 或 64）来收敛误差。即便如此，16K 以上的上下文长度仍然风险极高。
一个更精细的工程策略是混合方案：对 Key Cache 使用 INT8 或 FP8（因为 Key 的动态范围更大、对位置检索更敏感），对 Value Cache 使用 INT4（因为 Value 的分布更温和，前文已做过分析）。这一方案能在保持质量损失在 1-2% 以内的同时，将平均显存节省推高到 60% 以上，是显存压力极大时的进阶选项。
至此，从量化原理到收益评估再到质量验证，KV Cache 量化的完整闭环已经成形。最后一步，是将这些方法沉淀为可复用的工程实践------下一节将回顾全文要点，并给出可直接上手的部署清单。