先搞清楚显存这个问题的形状很多人问跑某个模型要多少显存期待一个数字。但这个问题其实有三个变量藏在里面模型有多大、上下文有多长、同时有多少人在用。只报一个数字等于把后两个变量当成常量——而它们往往比模型本身更能决定你最终要买几张卡。所以更实用的做法不是背结论而是知道显存花在哪、哪部分能被压下去。显存大致花在四处推理期显存占用模型权重KV Cache激活与临时缓冲框架与驱动开销随总参数量与数值精度增长随层数、KV 头维度、上下文长度、并发数增长随批大小与序列长度增长相对固定不可压缩理解这张图后面很多困惑会自己消失。权重MoE 要看总参数不是激活参数这是最容易搞混的一点。稀疏专家MoE模型在每次前向时只激活一部分专家所以单次计算量接近一个小得多的稠密模型。但全部专家的权重都得常驻显存——不然轮到某个专家时还得现从磁盘加载延迟反而更高。也就是说MoE 省的是单 token 的计算不是权重占用。估算显存时要按总参数量算而不是按激活参数量算。把激活量当成显存需求是最常见的错。KV Cache真正吃掉显存的黑洞自回归生成要保存每个历史 token 的键和值避免重复计算。这部分缓存会随上下文长度线性增长并且每个并发请求各存一份。于是它有两个放大器上下文长度长文档、长对话、长代码库都会把缓存推高。并发数服务端同时接 N 个请求缓存就近似乘 N。所以一个能跑起来的配置很可能在真实并发下直接 OOM。评估时如果不带并发结论基本没有参考价值。量化压的是权重顺便影响缓存量化把权重用更低位宽表示权重占用因此显著下降。这也是消费级硬件能跑起中大模型的主要原因。要注意两点量化压得最直接的是权重对 KV Cache 的收益取决于是否也对缓存做量化。压缩有代价精度可能下降部分算子和硬件组合未必都支持实际吞吐也未必线性提升。一套可套用的估算思路不给结论数字给方法先按总参数量 × 位宽估权重占用再按层数 × KV 头维度 × 上下文长度 × 并发数估 KV Cache加上框架开销与临时缓冲的余量拿总和去对齐硬件再留出安全边界。哪一步不确定就先做小规模实测反推而不是拿别人的经验值硬套。显存组成主要影响因素能否压缩压缩的代价模型权重总参数量、数值精度可以量化、低精度精度损失、算子兼容性KV Cache层数、KV 头维度、上下文长度、并发数可以缓存压缩、分页、共享实现更复杂可能影响效果激活与临时缓冲批大小、序列长度、算子实现有限影响吞吐或需要重计算框架与驱动开销运行时、上下文创建等基本不能—三个常见误区误区一按激活参数量估显存。对 MoE 来说这会严重低估。误区二只算权重不算缓存。短上下文下看不出问题一上长文本或并发就崩。误区三把量化当成免费午餐。省下的是显存付出的是精度、兼容性和调试成本。收尾显存估算不是查表而是拆账把权重、缓存、缓冲、开销四笔分开算再考虑并发和上下文这两个放大器。算清楚之后你会发现要多少显存这个问题答案其实取决于你打算怎么用它。