gpu 显存和模型参数量 对应关系

想本地跑模型，第一反应通常是「我这卡能跑多大的」。但参数量只是其中一项，精度、量化档位、上下文长度、并发数都会把占用推上去，同一张卡有人说能跑、有人报显存不足，多半是这四项没对齐。这篇不给结论数字，给你一套按自己机器填一遍就能判断的算法和排查顺序。

想本地跑模型，第一反应通常是「我这卡能跑多大的」。但参数量只是其中一项，精度、量化档位、上下文长度、并发数都会把占用推上去。同一张卡有人说能跑、有人报显存不足，多半是这四项没对齐，而不是卡不一样。

这篇不给结论数字，给你一套按自己机器填一遍就能判断的算法和排查顺序。算不出来的项就去站内页面看当时的数字，别凭印象拍脑袋。

显存不是只由参数量决定：先认清四项开销

权重占用等于参数量乘以每参数字节数，字节数由精度和量化档位决定，这一项最好估。但推理还要留 KV 缓存，它跟上下文长度、并发数成正比，跟参数量关系不大，长上下文场景经常反超权重。

权重占用

参数量 × 每参数字节数，精度越高、量化越松，这一项越大

KV 缓存

随上下文长度和并发数增长，长文档、多并发时可能比权重还占地方

框架与运行时

推理框架、CUDA 运行时、显存碎片各占一块，实际可用显存永远小于标称值

安全余量

三块加总后再留一段余量，贴着上限跑早晚会 OOM

• 参数量只能回答「大概是哪个量级」，回答不了「能不能跑」；
• 四个开销里权重最好估，KV 缓存最容易低估；
• 标称显存要打个折，卡上还跑着别的东西时折得更多；
• 把四项加总再留余量，才是判断跑不跑得动的正确姿势。

一套可照着填的估算步骤

1. 拆总量列出模型参数量，把它拆成权重、KV 缓存、框架开销三块分别估，别合成一个数拍。
2. 定档位确定量化档位，FP16 到 INT8 到 INT4 每参数字节数逐级下降，具体档位取舍去 /models/deploy 的部署测算页看当时的数字。
3. 算缓存按你实际要用的上下文长度和并发数算 KV 缓存，单并发能跑不代表多并发能跑。
4. 比显存三块相加后乘一个安全系数，再跟卡的可用显存比，差一点就直接降档位或降上下文，不要硬顶。

顺序不能颠倒。很多人先看卡再选模型，结果档位和上下文都被卡死；正确做法是先定业务需要的上下文和并发，再回头选卡或选档位。

如果你手上有多个候选模型，可以把每个模型按这套填一遍，做成一张对照表，比单看参数量靠谱得多。选型逻辑本身可以对照 /models/model-select 里的维度。

几个最容易算错的地方

• 拿下载下来的权重文件体积当运行时占用，文件是压缩存盘，跑起来解压后通常更大；
• 只按单条请求算，上线后并发一上来就爆，扩容靠卡数而不是靠调参；
• 忽略输入长度，长文档场景的实际上下文远超你测试时随手敲的那几句；
• 把「参数量大」和「效果强」画等号，量级合适的小模型往往比挤在显存边缘的大模型更稳。

还有一个隐性坑：同一台机器上跑多个服务，或者浏览器、桌面环境占着显存，你测出来的可用显存和空机器不是一回事。排查顺序建议是「先看实际可用显存，再核对档位和上下文，最后才怀疑模型本身」。

什么情况下这套算法不适用

多卡张量并行时显存能摊开，但通信和调度本身也吃资源，单卡公式不能直接乘卡数。用了 CPU offload 或磁盘卸载，显存放得下不等于速度能用，这时瓶颈已经从显存换成带宽。

• 训练和微调的占用结构跟推理完全不同，优化器状态会再吃掉数倍权重显存，要走微调的显存估算；
• MoE 架构模型激活参数量小于总参数量，按总量估偏高，按激活量估又会低估权重常驻部分；
• 批处理场景里 batch size 会把 KV 缓存成倍放大，别拿单条请求的结果外推。

判断标准很简单：只要你用了并行、卸载或训练，就别拿推理的估算当答案，重新按对应场景估一遍。