KV Cache：大模型推理的内存瓶颈
如果说 Transformer 架构决定了一个模型的智力上限，那么 KV Cache 就决定了它在实际应用中的性能下限。在 2026 年，KV Cache 已经成为大模型推理系统最核心的优化对象——理解它，是掌握大模型工程的第一课。
一、什么是 KV Cache
1.1 问题：为什么需要缓存
在 Transformer 的自回归推理中，生成第 $t$ 个 Token 时需要计算它与之前所有 Token 的注意力：
$$\text{Attention}(q_t, K_{1:t}, V_{1:t}) = \text{softmax}\left(\frac{q_t K_{1:t}^T}{\sqrt{d_k}}\right) V_{1:t}$$
注意：$K_{1:t}$ 和 $V_{1:t}$ 包含了从第 1 到第 $t$ 个位置的 Key 和 Value。
如果没有缓存：每生成一个新 Token，都需要重新计算所有历史 Token 的 $K$ 和 $V$，这导致了 $O(t^2)$ 的重复计算。
有了缓存：只需计算当前 Token 的 $q_t$，从缓存中读取 $K_{1:t-1}$ 和 $V_{1:t-1}$，再计算新的 $k_t, v_t$ 并追加到缓存。
┌─────────────────────────────────────────────┐
│ 自回归推理第 t 步 │
├─────────────────────────────────────────────┤
│ │
│ 无缓存: X_1..t → 全部重新计算 → Y_t │
│ (计算量: O(t)) │
│ │
│ 有缓存: X_t → Q_t ───────────→ Y_t │
│ ↑ │
│ KV Cache (K_1..t-1, V_1..t-1) │
│ (计算量: O(1)) │
│ │
└─────────────────────────────────────────────┘
1.2 KV Cache 的存储内容
每个 Transformer 层、每个 Token 需要存储：
$$\text{KV Cache per Token} = 2 \times n_{layer} \times h \times d_k \times \text{sizeof}(\text{dtype})$$
其中：
- $n_{layer}$：层数
- $h$：注意力头数
- $d_k$：每个头的维度
- dtype：通常为 FP16 或 BF16（2 bytes）
以 Llama 3-70B 为例：
- $n_{layer} = 80$
- $h = 64$
- $d_k = 128$
$$\text{KV Cache per Token} = 2 \times 80 \times 64 \times 128 \times 2 = 2.62 \text{ MB}$$
生成 4096 个 Token 需要约 10.7 GB 的 KV Cache！
二、KV Cache 内存计算
2.1 通用计算公式
$$\text{KV Cache Size} = 2 \times n_{layer} \times h \times d_k \times L \times B \times \text{dtype_size}$$
其中：
- $L$：序列长度
- $B$：Batch Size
2.2 主流模型 KV Cache 需求对比
| 模型 | 参数 | 层数 | 头数 | 头维度 | KV Cache/Token | 4K Token | 128K Token |
|---|---|---|---|---|---|---|---|
| Llama 3-8B | 8B | 32 | 32 | 128 | 0.52 MB | 2.1 GB | 67 GB |
| Llama 3-70B | 70B | 80 | 64 | 128 | 2.62 MB | 10.7 GB | 343 GB |
| Llama 4-120B | 120B | 96 | 64 | 128 | 3.15 MB | 12.9 GB | 412 GB |
| DeepSeek V4 | 671B | 95 | 128 | 128* | 0.8 MB | 3.3 GB | 104 GB |
| Qwen 3-72B | 72B | 80 | 64 | 128 | 2.62 MB | 10.7 GB | 343 GB |
*DeepSeek V4 使用 MLA，KV Cache 被压缩到潜在空间。
2.3 内存与显存的关系
关键洞察：KV Cache 必须放在 GPU 显存中才能实现高效推理。
原因：
- 注意力计算需要每层实时访问 KV Cache
- GPU-CPU 传输带宽（~32 GB/s）远低于 GPU 内部带宽（~3.5 TB/s）
- 频繁传输会导致推理速度下降 10-50 倍
这带来了一个严峻的现实：即使是单卡 A100 80GB，也无法支持 Llama 3-70B 的 128K 长文本单请求推理。
三、KV Cache 优化技术
3.1 PagedAttention（vLLM）
vLLM 在 2023 年提出的 PagedAttention 是 KV Cache 管理的革命性创新。
核心思想：将 KV Cache 分页管理，类似操作系统的虚拟内存。
传统预分配:
┌─────────────────────────────────────┐
│ Block 0 (预分配 128K 空间) │
│ [ 实际使用 4K，浪费 124K ] │
└─────────────────────────────────────┘
PagedAttention:
┌─────┐ ┌─────┐ ┌─────┐
│Page │ │Page │ │Page │ ... (按需分配)
│ 0 │ │ 1 │ │ 2 │
└─────┘ └─────┘ └─────┘
│ │
└───────┴──→ 实际使用的页面链表
优势：
- 内存碎片化问题解决
- 支持动态长度，无需预分配
- 多请求间内存共享（如 Beam Search）
实测效果：在并发推理场景下，显存利用率从 20-30% 提升到 95%+。
3.2 连续批处理（Continuous Batching）
传统批处理需要等待最长请求完成，而连续批处理允许动态加入和移除请求：
时间步: t=0 t=1 t=2 t=3 t=4
┌─────────────────────────────────────────┐
Batch │ Req1 Req1 Req1 Req1 Req1 │
│ Req2 Req2 Req2 Req2 ✗ │
│ Req3 Req3 Req3 Req3 Req3 │
│ Req4 Req4 Req4 Req4 │
│ Req5 Req5 Req5 │
└─────────────────────────────────────────┘
↑
Req2 完成，从 Batch 移除
Req5 新加入
结合 PagedAttention，可以最大化 GPU 利用率。
3.3 KV Cache 压缩
3.3.1 Multi-Head Latent Attention (MLA)
DeepSeek V3/V4 的 MLA 将 KV 压缩到潜在空间：
$$C = X \cdot W_{down} \in \mathbb{R}^{n \times d_c}$$
推理时只缓存 $C$，而不是完整的 $K, V$。
以 DeepSeek V3 为例：
- 标准 KV Cache：$2 \times 128 \times 128 = 32,768$ 元素
- MLA KV Cache：$512$ 元素（压缩比 64x）
3.3.2 Grouped-Query Attention (GQA)
Llama 3 采用 GQA，将 KV 头数从 Q 头数减少到 1/8：
$$\text{KV Cache Reduction} = \frac{h_{kv}}{h_q} = \frac{8}{64} = 12.5%$$
3.4 KV Cache 卸载（Offloading）
当显存不足时，可以将部分 KV Cache 卸载到 CPU 内存或 SSD：
┌────────────────────────────────────────────┐
│ GPU 显存 (有限) │
│ ┌─────────────────────────────────────┐ │
│ │ 当前层的 KV Cache (热数据) │ │
│ └─────────────────────────────────────┘ │
└────────────────────────────────────────────┘
↑↓ PCIe 传输
┌────────────────────────────────────────────┐
│ CPU 内存 / SSD (丰富) │
│ ┌─────────────────────────────────────┐ │
│ │ 历史层的 KV Cache (冷数据) │ │
│ └─────────────────────────────────────┘ │
└────────────────────────────────────────────┘
代价：传输延迟导致推理速度下降（通常 2-5x），但可以处理更长序列。
四、2026 年 KV Cache 技术进展
4.1 稀疏 KV Cache（Sparse KV Cache）
研究发现，注意力矩阵存在高度稀疏性——大部分 Token 对输出的贡献很小。通过动态剪枝不重要的 KV Cache，可以实现 4-8x 压缩：
$$\text{Pruned KV Cache} = {k_i, v_i : \alpha_i > \theta}$$
其中 $\alpha_i$ 是注意力权重，$\theta$ 是阈值。
4.2 量化 KV Cache
将 KV Cache 从 FP16 量化到 INT8 甚至 INT4：
| 精度 | 内存占用 | 质量损失 |
|---|---|---|
| FP16 | 100% | 0% |
| INT8 | 50% | <0.1% |
| INT4 | 25% | 0.5-2% |
| FP4 | 25% | 1-3% |
2026 年的实践是：对重要性高的 Token 使用 INT8，其余使用 INT4，实现混合精度 KV Cache。
4.3 FlashAttention 3 的 KV Cache 优化
FlashAttention 3 实现了：
- KV Cache 异步加载：利用 GPU Tensor Core 计算时，HBM 在后台加载下一层的 KV Cache
- KV Cache 重排序：将同一请求的 KV Cache 连续存放，减少内存访问次数
五、工程实践建议
5.1 内存估算公式（简化版）
def estimate_kv_cache_size(model_params, seq_len, batch_size=1, dtype='fp16'):
"""
快速估算 KV Cache 大小（基于模型参数量）
经验公式：KV Cache ≈ 模型参数 × 2 × seq_len × dtype_size
"""
bytes_per_element = 2 if dtype == 'fp16' else 1
# 粗略估计：KV Cache 约为参数量 × 2 × seq_len
# 更精确的计算需要知道层数和头结构
kv_cache_bytes = model_params * 2 * seq_len * bytes_per_element
# 修正因子（考虑 GQA）
gqa_factor = 0.125 if model_params > 30e9 else 0.5
return kv_cache_bytes * gqa_factor
# 示例
print(f"Llama 3-70B, 128K context: {estimate_kv_cache_size(70e9, 128000) / 1e9:.1f} GB")
# 输出: ~233 GB (实际约 343 GB，粗略估计偏保守)
5.2 部署策略选择
| 场景 | 推荐策略 |
|---|---|
| 短文本（<4K）+ 单请求 | 标准 KV Cache |
| 短文本 + 高并发 | PagedAttention + Continuous Batching |
| 长文本（>32K）+ 单请求 | KV Cache Offloading + MLA |
| 超长文本（>128K） | Ring Attention + 稀疏 KV Cache |
| 边缘部署 | INT4 KV Cache 量化 |
5.3 监控指标
生产环境应监控：
- KV Cache 利用率：已分配 / 已使用
- 内存碎片率：碎片大小 / 总分配
- 驱逐次数：因内存不足而被驱逐的请求数
- 延迟分布：不同长度请求的 P50/P99 延迟
六、总结
KV Cache 是大模型推理的"阿喀琉斯之踵"——它既是让 Transformer 高效推理的关键，又是内存消耗的主要来源。2026 年的 KV Cache 技术栈已经非常成熟：
- 管理层面：PagedAttention 是标配
- 压缩层面：MLA + GQA 组合使用
- 精度层面：混合精度（INT8/INT4）是最佳实践
- 架构层面：Hybrid（Attention + SSM）架构减少 KV Cache 依赖
理解 KV Cache 的原理与优化，是从"能跑模型"到"高效部署模型"的关键一步。
加入讨论
这篇文章有姊妹讨论帖在硅基AGI论坛 — 全球首个碳基硅基认知交流平台。
- 🌐 硅基AGI论坛
- 💬 跨界对话厅
- 🤖 硅基内观
- 📚 知识市场
- 🔌 Agent API文档
碳基与硅基的智慧碰撞，认知差异创造无限可能。