模型量化体积与显存估算器

本地处理

打赏支持
分享链接
反馈建议

部署显存由三块构成：权重（参数量 × 每参数字节数）、KV Cache（随上下文长度和并发线性增长）以及框架与中间激活的开销。量化主要压缩权重，对 KV Cache 的效果取决于是否同步量化缓存。

参数量（B，十亿）

权重精度

批大小（并发数）

上下文长度（token）

层数

注意力头数

每头维度

权重体积

KV Cache

框架开销

合计显存

建议显卡

精度	每参数字节	权重体积	含 KV 与开销合计

权重体积(GiB) = 参数量 × 10^9 × 每参数字节 ÷ 1024^3；KV Cache(GiB) = 2 × 层数 × 注意力头数 × 每头维度 × 上下文长度 × 批大小 × 2 字节 ÷ 1024^3（2 表示 Key 与 Value 两份，末尾 2 字节为 FP16 缓存）；框架开销 = (权重 + KV) × 15%；合计 = 权重 + KV + 开销。

显存到底被谁吃掉了

很多人以为部署大模型只要装得下权重就行，结果一上线就爆显存。原因在于权重只是显存的三分之一：推理时还要为每个并发请求保存注意力机制的 KV Cache，另外框架本身、CUDA 上下文、中间激活也都有固定开销，通常再占 10% 到 20%。

量化省的是哪一部分

FP32（4 字节）：训练用精度，推理场景几乎没人用，7B 就要 26 GiB，纯属浪费。
FP16 / BF16（2 字节）：推理的默认精度，几乎不损失效果，7B 约 13 GiB。
INT8（1 字节）：体积减半，效果损失很小（通常在 0.5% 以内），是性价比最高的选择。
INT4（0.5 字节）：体积再减半，7B 压到约 3.3 GiB，可以塞进 8 GB 消费级显卡；但复杂推理任务上的效果损失会明显一些。

要注意量化只压缩权重。KV Cache 默认仍是 FP16，所以当上下文很长或并发很高时，KV Cache 会成为主导项，此时光靠量化权重已经救不了显存。

KV Cache 增长有多快

从公式可以看出，KV Cache 与「层数 × 上下文长度 × 批大小」成正比。以上面 32 层、4096 上下文的配置为例，单并发就要 2 GiB；上下文拉到 32K 就是 16 GiB，再加 8 路并发直接 128 GiB——这就是长上下文服务成本高企的根本原因。缓解手段有三种：把缓存也量化成 INT8（省一半）、使用分组查询注意力（GQA，把多个头共享同一份 KV，可省 4 到 8 倍）、以及限制单请求最大并发。

常见问题

参数量的 7B 是 7 × 10^9 还是 7 × 2^30

是 7 × 10^9，即 70 亿个参数，这是模型行业的惯例（所以 7B 实际是 6.5 GiB 参数对应的数量级）。本工具按 10 亿参数 = 10^9 换算，再折算成 GiB 显示，与业界公布的模型体积口径一致。

估算结果和实际差多少

估算与实际通常有 10% 到 20% 的差距，主要来自三处：不同实现的分组查询注意力结构会让 KV Cache 比公式小；推理框架会预留一部分显存做内存池；以及张量并行的通信缓冲区。建议把估算结果上浮 20% 作为选卡依据。

你可能还想问

量化位宽怎么选？

位宽越低体积与显存占用越小，但精度损失越大；常见从较高精度建立基线，再逐步尝试低位量化，用评测集确认质量下降可接受。

显存占用怎么估？

参数量乘以每参数字节数，再加上激活值、缓存与框架开销；长上下文时缓存会显著增加，不能只按权重体积估算。

量化后速度一定变快吗？

不一定。取决于硬件是否有对应低精度算子支持；缺少加速支持时可能反而更慢，需实测推理速度再定方案。