「参数量除以二就是显存」错在哪？

「参数量除以二就是显存」是大模型部署圈流传最广的口诀，意思是七十亿参数的模型用十六比特精度约占十四G显存。作为权重的粗算它没错，坏就坏在很多人把它当成了总账。错在哪？这个公式只算了权重一层，而权重通常只占推理总开销的一半左右。正确说法是：权重先按参数量估算，再把上下文缓存、框架开销、并发余量逐项加上去，才是显存总账。

错在哪：公式只算了一层

权重像图书馆的书架，买书架的钱只是开始；读者来了要座位，书摊开了要桌子，节假日还要留走道。推理时的「读者」就是上下文缓存——模型在生成每个词时，都要保存之前所有内容的中间状态，长度越长占用越大。这部分和参数量无关，和请求长度、并发数直接挂钩，公式里却完全没有它。算键值缓存时别用平均值，按长度上限算才有意义，缓存占用是峰值决定生死的。

权重之外还有三大项

第一项，键值缓存：长度上限设到几万字的对话场景，并发一上来占用轻松超过权重本身。第二项，框架开销：推理引擎要放计算中间量、通信缓冲，通常按一两个G预留。第三项，碎片与突发：显存分配器留白、请求忽大忽小，都需要安全余量。把这三项加进去，一个「十四G」的模型，实际部署往往要按二十四G以上的卡来配。监控这些占用的实际水位，靠部署后的持续观察，方法见自建监控和托管监控。

上下文越长吃得越多

同样一个模型，短对话模式和长文档模式对显存的需求能差出一倍。很多人按默认配置算好账，用户一传长文档就崩。所以估算前必须先定两件事：单请求长度上限设多少、同时服务几个人。上限砍半，缓存占用几乎跟着砍半，这比换大卡便宜得多。用智谱清言或 DeepSeek 做对照测试时也可以观察到，长上下文请求的耗时和资源占用明显更高，直觉上就能体会这条规律。

能落地的分步估算法

• 第一步：权重占用，按参数量乘精度字节数粗算；
• 第二步：键值缓存，按长度上限和并发数查所用框架的系数；
• 第三步：框架开销，按一至两G预留；
• 第四步：安全余量，前三项之和再乘一点二；
• 第五步：用真实长文档按目标并发实测一次，校准数字。

一张16G显卡的例子

拿七十亿参数模型部署：权重约十四G，第一步就把16G的卡排除了。降到三十亿参数，权重约六G，加上长上下文并发后的缓存四G、框架开销一点五G、余量两G多，总计逼近十四G，16G的卡勉强可行但很紧。若把长度上限减半、并发限制到四，缓存降到两G，总占用十一G左右，就稳了。可见同一张卡上，能跑什么不只由参数量决定，更由使用策略决定。这套算法不必手工做，让智谱清言按步骤生成一张估算表，填入参数就能出结果，再实测校准。

同一张卡，三种策略算出来的账差得很远。

速查表

• 权重：参数量乘精度字节数
• 缓存：随长度上限与并发线性涨
• 开销：固定预留一至两G
• 余量：总和再乘一点二

记一句：公式只买书架，读者座位要另算。

关于显存估算再多问三句

• 量化之后公式还适用吗？：权重部分按新精度重算，但缓存和开销降得很少，很多人算完以为省一半，实际总占用远没有降那么多，详见量化部署零损失的误区。混合精度部署能再省一截，但要确认框架支持。
• 多张小卡凑总显存行不行？：显存能拼，算力和通信开销是另一本账，别指望简单相加，见多卡一定比单卡快的误区。
• 和直接调API比，自己估显存值不值？：用量小且波动大时，调API反而省心省钱，分界分析见API 一定比本地贵的误区。

口诀是捷径，也可能是最贵的弯路。把权重、缓存、开销、余量四项列成表格再下单，估算就从玄学变成了算术。