显存计算实战：模型规模 × 量化 → 显存需求，KV cache 怎么估
显存计算实战：模型规模 × 量化 → 显存需求，KV cache 怎么估
上一篇文章讲了「按显存选卡」，这篇把数学部分拆开：为什么同一个模型、不同上下文长度需要的显存差好几 GB？「27B 跑不动」到底差在权重上还是 KV cache 上？GPU 卸载层数怎么定？把公式和实测方法讲清楚，你就能在买卡之前算准、部署之后调准。
30 秒版本
显存 = 权重 + KV cache + 运行开销。权重 = 参数量 × 量化字节系数（Q4_K_M 约 0.6 字节/参数）；KV cache 随上下文线性增长，是长上下文的大头；运行开销再留 1-2GB。跑起来后用 nvidia-smi 和 llama.cpp 启动日志校准，比任何公式都准。
公式一：权重体积
权重体积 = 参数量 × 每参数字节数。各量化档位的经验系数：
| 量化档位 | 字节/参数（约） | 7B | 27B | 70B |
|---|---|---|---|---|
| Q8_0 | 1.05 | 7.4GB | 28GB | 74GB |
| Q6_K | 0.85 | 6.0GB | 23GB | 60GB |
| Q5_K_M | 0.72 | 5.0GB | 19GB | 50GB |
| Q4_K_M | 0.60 | 4.2GB | 16GB | 42GB |
| Q3_K_M | 0.48 | 3.4GB | 13GB | 34GB |
| Q2_K | 0.35 | 2.5GB | 9.5GB | 25GB |
为什么是「约」
不同模型的嵌入层、输出层大小不同，同样参数量下实际 GGUF 文件大小有 5%-10% 的偏差。买卡前用「模型卡上的实际文件大小」核对一次，比套用系数更稳。
公式二：KV cache
KV cache 保存历史 token 的 K/V 矩阵，是长上下文部署的隐性大头。单请求的体积估算：
KV cache ≈ 2（K 和 V）× 层数 × KV 头维度总和 × 上下文长度 × 2 字节（fp16）
不用记精确公式，记住两条规律：
- 随上下文长度线性增长——8K 到 32K，KV cache 约涨 4 倍
- 随批量线性增长——同时处理 4 个请求，KV cache 约涨 4 倍
实战经验值（fp16，单请求，供估算参考）：
| 模型规模 | 8K 上下文 | 32K 上下文 |
|---|---|---|
| 7B 级 | 约 0.5-1GB | 约 2-4GB |
| 27B 级 | 约 1-2GB | 约 4-8GB |
| 70B 级 | 约 2-4GB | 约 8-16GB |
长上下文场景 KV cache 可能超过权重的一半
27B 模型 Q4 权重 16GB，32K 上下文的 KV cache 可能到 4-8GB——四分之一到一半的显存给了「记住历史」。这就是为什么「同样 27B，短对话很流畅、喂长文档就 OOM」。规划长上下文部署时，KV cache 必须单独算。
公式三：运行开销
框架本身的开销：CUDA 上下文约 0.3-0.5GB、推理引擎缓存、显存碎片，通常再留 1-2GB。多卡时每张卡都有独立开销。
完整算例：三个真实场景
场景 1：Qwen3.8-27B，Q4_K_M，8K 上下文，单用户
- 权重 16GB + KV cache 约 1.5GB + 开销 2GB ≈ 19.5GB → 24GB 卡可跑
场景 2：同上，但 32K 上下文
- 权重 16GB + KV cache 约 6GB + 开销 2GB ≈ 24GB → 24GB 卡卡在边缘，建议 32GB 或降档
场景 3：混元 4B（hy4），Q4_K_M，8K 上下文
- 权重 约 2.5GB + KV cache 约 0.5GB + 开销 2GB ≈ 5GB → 8GB 卡轻松跑，甚至纯 CPU 可接受
MoE 模型的算法不一样
35B-A3B 这类 MoE：权重按总参数 35B 算（Q4 约 21GB），KV cache 按实际架构的层数/KV 头算，推理速度按激活的 3B 感受。所以 MoE 的显存需求接近 35B 稠密模型，但速度接近 3B 模型——这正是它适合本地部署的原因。
GPU 卸载层数怎么定
llama.cpp 的 -ngl（n_gpu_layers）决定多少层放显存、多少层留内存。确定方法：
- 先全上：
-ngl设成等于总层数（启动日志会打印层数），看是否 OOM - OOM 就降：每次减 4-8 层，直到能加载
- 看速度权衡：留在内存的层越多，生成越慢——用同样的 prompt 测 token/s，找「能加载 + 速度可接受」的平衡点
卸载不是免费的
部分层卸载到内存后，每生成一个 token 都要跨 PCIe 搬运数据，速度可能掉到原来的几分之一。如果必须卸载一半以上的层，不如换更小的模型或更低量化档位——体验会好得多。
实测校准：比公式更准
公式用来「买卡前估算」，实测用来「部署后调优」：
看显存占用：另开终端跑 nvidia-smi，观察推理时的显存占用峰值。
看 KV cache 分配：llama.cpp 启动日志会打印 KV cache 的实际分配大小（类似 llama_kv_cache: ... MiB），用它校准你的估算系数。
看碎片化：如果峰值占用比公式算的高出 2GB 以上，检查是否开了过大的 -c（上下文）或批量参数。
# 启动 llama-server 时观察日志中的 KV cache 分配
./llama-server \
-m ./models/Qwen3.8-27B-Q4_K_M.gguf \
-ngl 40 \
-c 8192 \
--host 127.0.0.1 --port 8080
批量推理的显存倍增
本地部署如果要多用户并发，注意：KV cache 按并发数倍增。单用户 8K 上下文占 1.5GB，4 并发就是约 6GB——加上权重和开销，24GB 卡跑 27B + 4 并发就紧张了。
策略：要么限制并发数（llama-server 的并行参数），要么为并发预留显存，要么把高并发场景交给云端 API。
FAQ
为什么我的显存占用比公式算的高？
KV cache 能压缩吗？
27B 用 Q4_K_M 还是 Q3_K_M？
-ngl 设多少合适？
MoE 模型显存怎么算？
公式算出来刚好等于卡的显存，能跑吗？
相关阅读
- 本地算力硬件选购指南 — 按显存选卡
- 本地部署完整手册 — 从硬件检查到接入
- Qwen KV cache 与长上下文 — KV cache 原理详解
- Qwen GGUF 本地部署入门 — 部署通识
- 本地算力成本模型 — 买卡 vs 租卡 vs API