显存不够,是该换更小的模型还是降低精度?

3 个讲解板块 · 关联 2 款站内工具 · 内容最后核对 2026-10-09

先算权重,再算 KV Cache——很多时候爆的是后者,而它随上下文线性涨。

直接答案

先分清楚是「权重装不下」还是「一加并发就爆」。权重显存等于参数量乘以每参数字节数:FP16 每参数 2 字节、INT8 是 1 字节、INT4 是 0.5 字节,所以 70B 模型依次约需 140 GB、70 GB、35 GB。如果你连加载都失败,那就是权重量化或换小模型的问题。

如果可以加载、但请求一多就 OOM,问题多半在 KV Cache。它的公式是 2 乘以层数、KV 头数、头维度、序列长度、并发数与精度字节,随上下文长度和并发数线性增长。70B 模型在 32K 上下文下单并发约 10.7 GB,并发 8 时约 85.6 GB,比 INT8 的权重还大。这时候降精度或缩短上下文,比换模型更直接有效。

部署大模型时最常见的误判,是只看模型文件多大,然后拿这个数字去挑显卡。结果文件明明装得下,一跑起来就爆显存——因为运行时还要为上下文和并发预留一大块空间。

把显存拆成四本账分别算,问题立刻变得可解:权重是固定的,量化能线性压缩;KV Cache 是浮动的,跟上下文长度和并发数成正比;激活值和框架开销是零头,留出一两成余量即可。哪本账超了,就调哪个旋钮。

1第一本账:权重,按精度线性缩放

权重显存等于参数量乘以每参数字节数,这一本账最好算,也最适合用精度去换空间。

模型规模FP16(2 字节)INT8(1 字节)INT4(0.5 字节)
8B约 16 GB约 8 GB约 4 GB
14B约 28 GB约 14 GB约 7 GB
70B约 140 GB约 70 GB约 35 GB
671B(MoE)约 1342 GB约 671 GB约 336 GB

混合专家(MoE)模型有个陷阱:虽然每次只激活一部分参数,但所有专家的权重都必须常驻显存,因为下一个 token 会路由到谁无法预知,所以省不下这份空间。

2第二本账:KV Cache,随上下文和并发线性涨

公式是 2 乘以并发数、序列长度、层数、KV 头数与头维度,最后乘精度字节数;前面的 2 分别代表 K 与 V 两个张量。

场景(70B / 80 层 / 8 个 KV 头)KV Cache 占用对比
32K 上下文,单并发,FP16约 10.7 GB比 INT4 权重还大
32K 上下文,并发 8,FP16约 85.6 GB超过 INT8 的 70 GB 权重
128K 上下文,并发 16,FP16约 53.7 GB长上下文部署的主要瓶颈
权重(INT8)本身70 GB可见 KV 完全可能反超权重

要压 KV Cache,有两条正交的路:缩短上下文(线性收益),或改用更小的 KV 精度与分组注意力(成倍收益)。

3剩下两本账与估算流程

激活值和框架开销是零头,但不能不算,否则每次都会在最后几百兆上翻车。

  1. 第一步算权重:参数量乘以精度字节数,得到下限。
  2. 第二步算 KV Cache:用 2 乘并发、序列长度、层数、KV 头数、头维度和精度字节。
  3. 第三步加激活值与框架开销:推理阶段一般按权重的 5% 到 15% 预留,再加 CUDA 上下文与框架缓冲的 1 到 3 GB。
  4. 第四步留碎片余量:再按总量预留 5% 到 10%。
  5. 最后用总显存比对硬件:不够就依次考虑降 KV 精度、缩短上下文、量化权重、换更小模型。

相关疑问

为什么模型文件明明装得下,跑起来还是爆?

文件只对应权重那一本账。运行时还要为 KV Cache、激活值和框架缓冲腾空间,长上下文或多并发时,KV Cache 本身就可能超过权重。

量化到 INT4 会掉多少效果?

收益是权重显存直接减到四分之一(相对 FP16),代价是精度损失,通常在通用对话里不明显、在长链条推理和代码任务上更敏感。实际取舍建议用自己的测试集跑一轮再定,而不是听结论。

只有一张消费级卡,能跑多大的模型?

先按权重算出下限,再为 KV Cache 留出一半以上的余量。常见做法是把上下文压到 8K 以内、单并发、INT4 量化,这样 24 GB 级别的卡可以勉强带动 14B 到 32B 的模型。

MoE 模型是不是更省显存?

推理时算力确实更省,但显存不省:所有专家权重都要驻留,所以总权重按全参数量算。省的是单次推理的计算量,不是显存占用。

内容标识:本页内容由人工智能辅助生成,并经人工核对与编辑。详见 人工智能生成内容标识说明。
内容说明:本页针对具体使用问题作答,方法步骤与数值由本站自行整理与复算,事实性内容以对应官方规范与文档为准。内容最后核对日期:2026-10-09。若发现错误,欢迎通过页脚反馈入口告知。