跑 70B 模型的显存账本：权重、KV cache 与量化
「我这台机器能不能跑 70B」这个问题，网上的答案通常是一个孤零零的数字。但显存占用由四项构成，其中只有一项跟参数量直接相关。
四项开销
总显存 ≈ 权重 + KV cache + 激活峰值 + 框架开销
权重 = 参数量 × 每参数字节数（量化等级决定）
KV cache = 2 × 层数 × 头数 × 头维度 × 序列长度 × 批大小 × 精度
激活峰值 ≈ 与批大小、序列长度相关，推理时通常 < 2 GB
框架开销 ≈ 0.5–1.5 GB（CUDA context、分配器碎片）第一项：权重
每参数字节数是量化等级的直接结果：
| 量化 | 每参数字节 | 70B 权重 | 备注 |
|---|---|---|---|
| FP16 / BF16 | 2.0 | 约 140 GB | 基准精度 |
| INT8 / FP8 | 1.0 | 约 70 GB | 多数场景质量损失很小 |
| Q6_K | 约 0.82 | 约 57 GB | |
| Q5_K_M | 约 0.70 | 约 49 GB | |
| Q4_K_M | 约 0.58 | 约 41 GB | 性价比常用的拐点 |
| Q3_K_M | 约 0.48 | 约 34 GB | 长文推理开始出现明显退化 |
注意：上表是「纯权重」。实际加载还要加上 embedding、输出层以及对齐填充，通常再高 3%–8%。
第二项：KV cache，最容易被低估
KV cache 与参数量无关，只跟结构、序列长度、并发数有关。对常见的 70B 级模型（80 层、64 头、头维度 128）：
每 token 每序列的 KV ≈ 2 × 80 × 64 × 128 × 2 字节 ≈ 2.6 MB（FP16）
8K 上下文、单并发 ≈ 21 GB
32K 上下文、单并发 ≈ 84 GB
8K 上下文、8 并发 ≈ 168 GB这就是为什么「权重塞得下」不等于「跑得起来」：长上下文场景里，KV cache 往往比权重还大。
两个常见的压缩手段：
- KV 量化：FP16 → FP8，直接减半，质量损失通常可接受。
- 分组查询注意力（GQA）：把 64 个头压到 8 个 KV 头，KV cache 直接降到 1/8。
第三、四项：激活与框架
推理时激活峰值相对固定，批大小 1、8K 上下文通常在 1–2 GB。框架开销则是固定税：CUDA context 约 300–500 MB，加上分配器碎片，实际预留 1 GB 比较稳。
把它们加起来：三档配置
| 目标 | 配置 | 显存估算 | 可行性 |
|---|---|---|---|
| 70B Q4，短上下文 | 2 × 24 GB | 41 + 8 + 1.5 + 1 ≈ 52 GB | 刚好，需要张量并行 |
| 70B Q4，8K 上下文 | 2 × 48 GB | 41 + 21 + 1.5 + 1 ≈ 65 GB | 宽松 |
| 70B FP16，32K 上下文 | 4 × 80 GB | 140 + 84 + 2 + 1 ≈ 227 GB | 需要 4 卡 |
一句话总结
先算权重，再算 KV cache，最后加 2–3 GB 固定开销。绝大多数「跑不动」的案例，问题都出在第二步被忽略了。