给 AI 加载一个几亿参数的模型,为什么十几 G 的显存可能都吃不下?因为模型权重只是显存住户之一。显存里住着三户人家:权重、激活值、缓存,搞清楚每户占多大地方,显存占用这笔账才算得明白。
显存里住着三户人家
权重是模型的「本体」,加载进来就常驻不走;激活值是每次计算过程产生的中间结果,算完一层就释放一层地皮;缓存是推理过程中为提速留下的记录,随对话变长越攒越多。三户人家的占地规律完全不同,所以显存问题不能一概而论。
权重是常驻的大头
权重的占地主要取决于两个数:参数量和每个参数用几个字节存储。同一个模型,用高位精度存储和低位精度存储,占地可能差几倍,这也是量化技术能省显存的原因,机制详见量化部署的拆解。权重一旦加载就长期驻留,跑多少请求它都占那么多,是显存里的固定支出。
激活值随批次起伏
激活值在计算过程中产生、用完即弃,它的峰值取决于一次同时处理多少数据。批量越大、序列越长,同时要「拿在手里」的中间结果越多,峰值就越高。这解释了一个常见现象:明明权重装得下,批量一大就报显存不足——撑爆的常常不是权重,而是激活值的峰值。
缓存随上下文增长
第三户是推理过程中的缓存记录,为的是避免每生成一个字都从头算一遍。对话越长、并发越多,这户人家的占地越大,长文本服务里它甚至能超过权重。这笔账怎么算,机制拆解见KV 缓存一篇。三户人家加起来,就是一次部署的显存总账:权重是固定支出,激活看批量峰值,缓存看上下文长度和并发数,估算时分别对待。
三户人家各自怎么涨、爆了怎么认:
| 显存住户 | 占地由什么决定 | 什么时候涨 | 撑爆时的表现 |
|---|---|---|---|
| 权重 | 参数量乘以每个参数的字节数 | 加载即常驻,跑多少请求都占那么多 | 没跑请求就占满 |
| 激活值 | 一次同时处理多少数据 | 批量越大、序列越长,峰值越高 | 一上批量就报错 |
| 缓存 | 上下文长度和并发数 | 对话越长、并发越多越攒 | 对话变长后逐渐吃紧 |
算账的实用口诀
给一个新手口诀:先按权重留出固定块,再按最大批量给激活峰值留出弹性块,最后按典型对话长度给缓存留出增长块,三块相加再留一成余量防碎片。像 DeepSeek 这类参数量大的模型,权重大头决定了起步配置;Kimi 这类主打长上下文的服务,缓存则是扩容的主因。机内资源怎么整体规划,可参考一体机的整机思路;免配置直接跑一个试试,走模型商店的一键部署最省事。
显存不够时的选项排序也有讲究:首选量化压缩,改动最小、见效直接;其次降并发或限上下文长度,把峰值削下来;再不行才考虑多卡切分,成本和维护复杂度都上一个台阶。判断是哪一户撑爆了显存也有土办法:没跑请求就占满,是权重的问题;一上批量就报错,看激活;对话变长后逐渐吃紧,是缓存在涨。先定位再动手,比一上来就加卡省钱得多。
显存占用速查表
- 三户人家:权重常驻、激活看峰值、缓存随长度涨
- 权重账:参数量乘以单参数字节数
- 激活账:批量越大、序列越长,峰值越高
- 缓存账:对话越长、并发越多,占地越大
记住这句:显存爆了先分清是谁撑爆的,权重、激活、缓存三者对症下药完全不同。
估算权重占地有个快速心算:参数量以十亿为单位,每个参数按两个字节算,占地在 GB 数上大致是参数量的两倍。比如七十亿参数的模型,粗估十四 G 起步,再加激活和缓存的余量。心算不精确,但足够在选卡时圈定范围,剩下的交给实测。
关于显存占用,问得最多的三个
- 为什么加载完模型还没跑请求就占了很多?:那是权重在常驻,属于固定支出,和请求量无关。
- 显存不够加内存条有用吗?:没用,显存和内存是两套体系,不够只能换更大显存、量化压缩或者多卡拆分。
- 参数量相同的模型显存占用一样吗?:不一定,存储精度、架构设计、缓存策略都会改变实际占地。


