KV Cache 占据推理显存的 60-80%，量化 KV Cache 是提升吞吐和并发量的最有效手段之一

前置知识

• 模型量化基础 — 理解量化公式、scale、粒度概念
• KV Cache 详解 — 理解 KV Cache 结构和显存计算

核心概念（含 Mermaid 图）

为什么 KV Cache 值得量化

在 LLM 推理中，GPU 显存主要消耗在三个部分： 模型权重 、 KV Cache 、 中间激活值 。其中 KV Cache 在长上下文和大批量场景下占比最大。

关键数据 ：

KV Cache 量化的独特挑战

KV Cache 量化与权重量化有本质区别：

KV Cache 量化为什么更难：

1. KV Cache 是在推理过程中动态生成的
   → 无法用校准数据预先统计分布
   → 需要在线计算 scale（增加延迟）

2. 前几层的 KV 和后几层的 KV 分布差异大
   → 浅层 KV 变化剧烈，深层 KV 相对稳定
   → 统一量化策略对浅层不公平

3. KV Cache 中的异常值模式与权重不同
   → 某些 token 的 KV 值极大（通常是特殊 token 或标点）
   → per-tensor 量化时 scale 被 outlier 撑大

4. decode 阶段 KV Cache 读取是 memory-bound 的
   → 量化减少了带宽，但如果 dequantize 开销大则抵消收益

主流 KV Cache 量化方案

方案 1：INT8 KV Cache 量化

最简单也最实用的方案：

量化策略：
  - per-tensor 对称 INT8 量化
  - 每个 KV head 独立 scale（per-head，而非全局 per-tensor）
  - scale = max(|KV|) / 127，在线计算

精度影响：
  - MMLU 损失 < 0.3%
  - 生成质量几乎无感知差异
  - 长文本场景（> 8K）可能有轻微退化

显存收益：
  - KV Cache 减半（FP16 → INT8）
  - batch size 可以翻倍（在相同显存预算下）

性能收益：
  - decode 延迟降低 20-40%（带宽减少主导）
  - 但需要 online dequantize（INT8 → FP16 给 Attention 计算）
  - fused dequantize kernel 可以将开销降到 < 5%

方案 2：FP8 KV Cache 量化

H100 上的最佳选择：

量化策略：
  - E4M3 格式（权重用 FP8 时 KV 也用 FP8）
  - per-tensor 或 per-head scale
  - H100 Tensor Core 原生支持 FP8 Attention

精度影响：
  - MMLU 损失 < 0.2%
  - 几乎完全无损

显存收益：
  - KV Cache 减半（FP16 → FP8）
  - 与 INT8 相同的压缩比

性能收益：
  - FP8 GEMM 原生加速
  - 不需要 dequantize（FP8 直接计算）
  - decode 延迟降低 30-50%

方案 3：KIVI（Kernel-aware INT4/INT2 KV Cache）

KIVI（2024）的核心观察：
  KV Cache 中 K 和 V 的量化敏感度不同
  → K（Key）对量化更敏感（决定 token 之间的相似度）
  → V（Value）对量化相对宽容

量化策略：
  - K 用 INT4，V 用 INT2
  - per-channel + per-token 量化
  - 专门优化的 fused Attention kernel

精度影响：
  - K-INT4 + V-INT2：MMLU 损失 0.5-1.5%
  - K-INT8 + V-INT4：MMLU 损失 < 0.3%
  - 全 INT4：MMLU 损失 1-2%

显存收益：
  - 混合 INT4/INT2：KV Cache 压缩到 1/3
  - 全 INT4：KV Cache 压缩到 1/2

适用场景：
  - 超长上下文（32K+）
  - 大批量服务（batch > 64）
  - 对质量有一定容忍度的场景

方案 4：PQ（Product Quantization）KV Cache

PQ 的思路：
  将 high-dimensional KV 向量分组
  每组用 K-means 聚类出 codebook
  只存储 codebook 索引（如 8-bit 索引 = 256 个 cluster）

优势：
  - 压缩比极高（可以达到 10x+）
  - 不依赖硬件 INT8/FP8 支持

劣势：
  - 需要 online 查找 codebook → 推理延迟增加
  - codebook 需要存储在显存中
  - 实现复杂，工程化难度大

适用场景：
  - 学术研究 / 极限压缩场景
  - 目前生产环境较少使用

量化方案对比汇总

部署视角

KV Cache 量化 vs Weight 量化：先量化谁？

显存优化优先级建议：

场景 1：单请求，短序列（batch=1, seq < 4K）
  权重占显存主导 → 先量化权重（INT4/AWQ）
  KV Cache 很小，量化收益不大

场景 2：多请求，长序列（batch > 16, seq > 8K）
  KV Cache 占显存主导 → 先量化 KV Cache（INT8/FP8）
  权重量化作为第二步优化

场景 3：两者都量化
  INT4 权重 + INT8 KV Cache = 最佳性价比
  70B 模型：35GB(权重) + 32GB(KV) = 67GB → 1× A100-80G 搞定
  FP16 基线：140GB(权重) + 64GB(KV) = 204GB → 需要 3× A100

场景 4：极限压缩
  INT4 权重 + K-INT4/V-INT2 KV = 35GB + 21GB = 56GB
  但质量损失可能 > 2%，需要严格验证

# vLLM INT8 KV Cache 量化配置
llm = LLM(
    model="meta-llama/Llama-3-70B-Instruct-AWQ-INT4",  # 权重已量化
    quantization="awq",
    kv_cache_dtype="int8",         # KV Cache INT8 量化
    gpu_memory_utilization=0.95,   # 量化后可以用更高的比例
    max_model_len=16384,
)

# vLLM FP8 KV Cache（H100）
llm = LLM(
    model="...",
    quantization="fp8",
    kv_cache_dtype="fp8",
    gpu_memory_utilization=0.95,
)

                                            

不同场景的推荐配置

监控 KV Cache 量化效果

关键监控指标：

1. KV Cache 显存占比
   - 量化前：60-80%
   - INT8 量化后：30-50%
   - 目标：降低 30-50 个百分点

2. 有效 batch size 提升
   - 同样显存预算下，batch size 应提升 1.5-2x
   - 如果提升不明显，检查是否权重未量化

3. 生成质量
   - 用 100 条业务数据做 A/B 测试
   - 比较量化前后的输出一致性
   - 关注：是否有重复生成、乱码、逻辑错误

4. 推理延迟
   - decode 阶段 per-token 延迟应降低 20-50%
   - 如果延迟没有降低，检查 dequantize 开销

面试视角

面试官常问问题

Q1: "KV Cache 量化和权重量化有什么区别？为什么 KV Cache 量化更难？"

满分回答要点：

• 权重是静态的，可以离线校准统计分布；KV Cache 是动态生成的，需要 online scale 计算
• 权重的分布相对均匀稳定；KV Cache 的分布随生成过程变化，前期和后期差异大
• 权重量化有成熟的 AWQ/GPTQ 方案；KV Cache 量化通常只能用简单的 per-tensor 方法
• KV Cache 中的 outlier 模式与权重不同（某些特殊 token 产生极端 KV 值）
• INT4 权重可以接受，但 INT4 KV Cache 通常质量损失太大

Q2: "KV Cache 量化后，什么情况下精度损失最大？"

满分回答要点：

• 长上下文 ：序列越长，累积的量化误差越多，影响越明显
• 数学/代码任务 ：需要精确计算的任务对 KV 精度更敏感
• 浅层 Attention ：前几层的 KV 变化剧烈，量化误差对注意力模式影响更大
• 多轮对话 ：历史 KV Cache 中的误差会在后续生成中累积
• 缓解策略：浅层用 INT8/FP16，深层用 INT4/FP8（分层量化策略）

Q3: "KV Cache 量化的 trade-off 是什么？怎么决定要不要量化 KV Cache？"

满分回答要点：

• Trade-off ：显存/速度 vs 生成质量
• 决策因素 ：
  1. 如果 batch size 受限（显存不够）→ KV Cache 量化是首选优化
  2. 如果是 latency-critical（单请求低延迟）→ 权重量化优先，KV Cache 保持 FP16
  3. 如果吞吐-critical（高并发服务）→ 两者都量化，最大化 batch
  4. 质量敏感场景（数学、代码）→ KV Cache 至少用 INT8，不用 INT4
  5. H100 环境 → 直接上 FP8 KV Cache，精度几乎无损
• 经验法则 ：INT8 KV Cache 量化在 Llama 3 级别模型上几乎无损，可以放心使用

Q4: "量化 KV Cache 会影响推理速度吗？不是说量化后数据变小了应该更快吗？"

满分回答要点：

• 理论上：KV Cache 变小 → HBM 读取量减少 → 带宽压力减小 → decode 更快
• 但实际上：需要 online dequantize（INT8 → FP16）才能给 Attention 计算用
• 如果 dequantize 是单独的 kernel → 增加 kernel launch overhead → 可能更慢
• 如果 dequantize fused 到 Attention kernel 中 → 开销 < 5% → 净收益为正
• 所以关键是 kernel 实现质量 ：好的 fused kernel 能带来 20-40% 加速，差的实现可能反而更慢
• FP8 KV Cache 在 H100 上不需要 dequantize → 天然更快

最佳实践

调参建议

• 首选 INT8 KV Cache ：精度损失极小（< 0.3%），实现简单，任何 GPU 都支持
• H100 首选 FP8 KV Cache ：精度几乎无损，推理速度更快
• 谨慎使用 INT4 KV Cache ：只在显存极度紧张且对质量要求不高时使用
• 分层量化策略 （进阶）：前 1/3 层 KV 用 FP16/INT8，后 2/3 层用 INT4 → 平衡质量和显存
• 量化 KV Cache 后， gpu_memory_utilization 可以适当提高（0.9 → 0.95），因为峰值显存更可控

避坑指南

• INT8 KV Cache 量化在 7B/13B 模型上几乎无损，但 70B+ 模型在超长上下文时可能有轻微退化
• 量化后的 KV Cache 做 Prefix Caching 时，确保 cache 也是量化格式存储（不要缓存了量化后再反量化缓存）
• vLLM 的 kv_cache_dtype 设置后需要重启引擎才能生效，不支持运行时切换
• KV Cache 量化不能替代 PagedAttention（两者是正交优化，应该同时使用）
• 测试 KV Cache 量化效果时，用真实业务数据做 A/B，不要用合成数据
• MoE 模型的 KV Cache 量化和 Dense 模型类似，但注意 active expert 切换时的 KV 分布变化