KV Cache 显存账与长上下文
KV Cache 的显存 = 2 × 层数 × KV 头数 × 头维度 × 序列长度 × 精度字节 × 并发，序列长度与并发都是线性项，长上下文推理显存爆炸就爆在这里。压它的四条路按成熟度排序： GQA / MLA 减头数、FP8 量化减字节、分页管理减碎片、卸载到主存换带宽。
也叫：KV Cache 显存 · GQA · MLA · FP8 量化 · 内存带宽 · 长上下文显存
一、KV Cache 到底占多少显存出自 T6-1
标准公式（这一行必须背对）：
KV_bytes = 2 × L × H_kv × D_head × S × B × P 2 ：K 和 V 各存一份 L ：层数 num_hidden_layers H_kv ：KV 头数 num_key_value_heads ← 不是注意力头数！ D_head ：头维度 head_dim S ：序列长度（prompt + 已生成） B ：并发请求数 P ：精度字节数 bf16=2, fp8=1, int4=0.5
H_kv 是最容易写错的地方。 不少资料写的是注意力头数，因为它们举的例子是 Llama 2 7B——MHA 模型，两个数恰好相等。换成现代 GQA 模型就会错得离谱：Llama-3.1-8B 是 32 个注意力头但只有 8 个 KV 头，写错就是 4 倍；70B 是 64 比 8，写错就是 8 倍。
代入具体数字（bf16，参数取自官方 config）：
| 模型 | L | H_kv | D_head | 每 token KV |
|---|---|---|---|---|
| Llama-3.1-8B | 32 | 8 | 128 | 128 KB |
| Llama-3.1-70B | 80 | 8 | 128 | 320 KB |
| DeepSeek-V3（MLA） | 61 | — | — | 68.6 KB |
一个值得记住的对照：Llama-3.1-8B 的权重是 16.1 GiB，而它在 128K 上下文下，batch=1 的 KV Cache 就是 16.0 GiB——一条长请求的 KV，顶得上一整份模型权重。
再看显存怎么分（H100 80GB 跑 8B，vLLM 的 gpu_memory_utilization 默认 0.9，截至 2026-08 主线已调到 0.92）：
┌──────────────── H100 80 GB ──────────────────────────┐ │ 预算 = 79.6 × 0.92 = 73.2 GiB │ │ ├── 模型权重 16.1 GiB ████ │ │ ├── 激活+CUDA图 ~3 GiB █ │ │ └── KV Cache 拿走 ~54 GiB ████████████████ │ ← 剩余法分配 │ │ │ 54 GiB ÷ 128 KB = 约 44 万 token 的缓存容量 │ │ 8K 上下文 → 可并发 ~54 条 │ │ 128K 上下文 → 可并发 ~3 条 ← 开头那个故障 │ └────────────────────────────────────────────────────────┘
讲"吞吐塌陷"要用并发数讲，不要用显存 GB 讲。「同一张卡，上下文长 16 倍，并发从 54 掉到 3」这一句比任何显存曲线都有说服力。
以上节选自T6-1 推理服务：自建还是调 API，以及 KV Cache 这本账，读全文能看到前后语境。