本地部署一个 7B 大模型，到底需要多大显存？
"我的 8G 显卡能不能跑 7B？"
这个问题在群里出现的频率，大概仅次于"Python 和 Java 学哪个"。而答案通常是两种：一种是拍脑袋（"7B 嘛，4 位量化 4 个 G，够"），另一种是"看情况"。
其实显存账是可以精确算的，而且只需要三个公式。算完你会发现：决定你能不能跑长上文的，不是权重，是 KV Cache。
一、三个公式
权重要多少：
权重占用 = 参数量 × 每参数字节数FP16 是 2 字节/参数，INT8 是 1 字节，4 位量化是 0.5 字节。
KV Cache 要多少：
ini
KV Cache = 2(K和V) × 层数 × KV头数 × head_dim × 上下文长度 × batch × 每元素字节注意第二项是 KV头数，不是注意力头数------这是 GQA（分组查询注意力）的全部意义所在。
再留一点余量： CUDA context、激活值、框架预留，工程上取 10%~20%。
二、把公式写成 20 行代码
python
def gb(n: float) -> float:
return n / 1024 ** 3
def weights_gb(params_b: float, bits: int) -> float:
"""bits=4 时约等于 Q4_K_M 的实际权重占用（含少量量化元数据，误差 <5%）。"""
return gb(params_b * 1e9 * bits / 8)
def kv_cache_gb(layers: int, kv_heads: int, head_dim: int, ctx: int,
batch: int = 1, dtype_bytes: int = 2) -> float:
return gb(2 * layers * kv_heads * head_dim * ctx * batch * dtype_bytes)
def total_gb(params_b, bits, layers, kv_heads, head_dim, ctx,
batch=1, overhead=0.15):
return weights_gb(params_b, bits) * (1 + overhead) + kv_cache_gb(
layers, kv_heads, head_dim, ctx, batch)跑一遍（以 Qwen2.5-7B 系结结构为例：28 层、GQA 4 个 KV 头、head_dim 128）：
yaml
量化 上下文 权重 KV Cache 合计
FP16 4096 13.04G 0.22G 15.21G
FP16 32768 13.04G 1.75G 16.74G
FP16 131072 13.04G 7.00G 21.99G
INT8 4096 6.52G 0.22G 7.72G
INT8 32768 6.52G 1.75G 9.25G
INT8 131072 6.52G 7.00G 14.50G
Q4_K_M 4096 3.26G 0.22G 3.97G
Q4_K_M 32768 3.26G 1.75G 5.50G
Q4_K_M 131072 3.26G 7.00G 10.75G（完整脚本：code/01_vram_estimate.py，零第三方依赖）
三、这张表告诉你的四件事
1. 4 位量化不是"省一半"，是省 75%。 FP16 的 7B 权重 13 GB，Q4_K_M 只要 3.26 GB。8 GB 显卡跑 4 位 7B 完全够------如果上下文只有 4K 的话。
2. 下下文长度是显存的第二个价格标签。 同一份 4 位权重：4K 上下文总共 3.97 GB，32K 变 5.50 GB，128K 直接 10.75 GB。KV Cache 从 0.22 GB 涨到 7 GB，涨了 31 倍。很多人"能跑起来"但"一开长文档就 OOM"，就是这个原因。
3. GQA 是长下下文的真正功臣。 同样 4096 上下文，传统 MHA（28 个 KV 头）要 1.53 GB，GQA（4 个 KV 头）只要 0.22 GB，相差 7 倍。如果按 128K 上下文算，MHA 光 KV Cache 就要 49 GB------这也是为什么现在的开源模型基本都用 GQA/MQA。
4. "显存不够"最常见的三种真实死因，都不是权重：
- 上下文设太大（KV Cache 爆了）；
- 并发请求没限制（每个并发请求一份 KV Cache）；
- 加载时用了 FP16 或 BF16 权重，然后指望它自己变 4 位。
四、对着显卡买模型的速查表
| 显存 | 现实可行的配置 |
|---|---|
| 6 GB | 4 位 3B，上下文 ≤ 8K；7B 会 OOM |
| 8 GB | 4 位 7B，上下文 8K~16K；32K 需降 batch 到 1 |
| 12 GB | 4 位 7B + 32K 上下文；或 4 位 13B 短上下文 |
| 16 GB | 4 位 13B + 16K；或 8 位 7B + 32K |
| 24 GB | 4 位 32B 短上下文；或 4 位 13B + 64K |
| 48 GB+ | 可以考虑 FP16 的 7B/13B，或量化后的 70B（勉强） |
（表格里的数字都能用上面那段脚本自己复算，把 params_b / layers / kv_heads / head_dim 换成目标模型的配置即可，配置文件里都有。）
五、两个容易踩的坑
坑一：只算权重，不算 CUDA context。 CUDA context 本身要占几百 MB 到 1 GB 以上。用 nvidia-smi 看到的"空闶显存"往往比标称少 1 GB 左右。所以 8 GB 卡实际可用大约 7 GB------我上面的 overhead=0.15 就是给这个留的。
坑二：把 batch 忘了。 公式里 batch=1 是单人使用。服务端 4 个并发请求，KV Cache 直接乘 4。这也是为什么 vLLM 的 PagedAttention 值得单独学------它把 KV Cache 按页管理，显著降低碎片，让同样的显存塞下更多并发。
小结
- 权重看量化位数，KV Cache 看上下文和 KV 头数，两者相加再留 15% 余量；
- 想跑长上下文，选 GQA 模型比换更大的显卡有效；
- 显存不够先查上下文长度和并发数，别急着换卡。
文末回站引导
上面这段脚本和完整的推理部署笔记（量化格式对比、vLLM 参数、API 服务化）整理在 道满PythonAI 的《大模型推理部署：量化、与数据并行历）： www.daomanpy.com/llm/llm-dep...
Windows/Linux 从零与环境的那套不步开始吧： www.daomanpy.com/llm/window_...
我平时看到这份问题时，想出了一个能自己算清楚，满足后否，我想我能把它记录下来，以能帮助到更多人。