显存到底被谁吃掉了

自建推理这件事，绕不开的第一个问题就是「这台机器到底要几张什么卡」。很多人第一反应是拿参数量乘个数就完事， 结果真跑起来才发现，单人测试的时候好好的，一上并发就 OOM。原因在于显存不是一块铁板，它至少要拆成三部分来看， 而这三部分的增长规律完全不一样。

第一部分是权重。这是模型本身的参数，加载完就常驻在那里，不随请求数变化。它的大小很好算： 参数量乘以每个参数占的字节数。FP16 或 BF16 是每参数 2 字节，FP8 和 INT8 是 1 字节，INT4 是 0.5 字节。 所以同一个模型，量化到 INT4 权重直接缩到 FP16 的四分之一，这也是量化最直观的价值。 权重这一项是「地板」——不管你跑不跑请求，这块显存都得先交出去。

第二部分是 KV cache，这才是真正的变量。自回归生成的时候，每生成一个 token 都要回看前面所有 token 的 Key 和 Value，为了不重复计算，框架会把它们缓存下来。缓存的大小等于：2（K 和 V 各存一份）乘以层数、乘以 kv_heads、 乘以 head_dim、乘以序列长度、再乘以并发数，最后乘每个元素的字节数。注意后面那两个乘数—— 序列长度和并发数都是线性的。上下文从 4K 拉到 32K，KV cache 涨 8 倍；并发从 1 路加到 32 路，再涨 32 倍。 两个一起上，就是 256 倍。这就是为什么单人测好好的服务，一上量就崩。

第三部分是余量。推理框架自身的运行时、CUDA 上下文、中间激活值、显存碎片，这些零零碎碎加起来不小， 但很难精确建模，所以工程上通常按权重加 KV 的一个百分比粗略预留，15% 是个常见的起点， 保守一点的场景会留到 20% 甚至更多。

为什么说 KV cache 才是并发的瓶颈

把上面三部分放在一起看，结论就很清楚了：权重决定你能不能跑起来，KV cache 决定你能同时跑多少人。 一张卡装下模型权重之后剩下的显存，全部是留给 KV cache 的预算，这个预算除以「单条序列的 KV cache 大小」， 就是这张卡的并发上限。工具里专门给出了「每多一路并发要多吃多少 GB」这个数，就是为了让你能直接做这道除法。

明白了这个关系，优化方向也就明确了。想提高并发，要么压缩权重（量化）腾出预算，要么压缩单条序列的 KV （降 KV 精度、缩短上下文、选用 GQA/MQA 架构即 kv_heads 远小于注意力头数的模型）。 反过来说，如果你的业务是长文档处理，上下文动辄几万 token，那即使模型不大，KV cache 也会迅速盖过权重， 此时盯着「换个更小的模型」优化就是南辕北辙。

怎么用估算结果选卡

实际操作建议分三步。第一步，先用你业务的真实上下文长度和目标并发填进去，得到一个总量， 对照单卡显存的常见档位（24GB、48GB、80GB）看落在哪一档。第二步，把并发数上下拨动， 看总量对并发的敏感程度——如果并发加一路就涨好几 GB，说明你的方案对流量波动很脆弱，得留更厚的余量。 第三步，如果总量超过单卡，就要考虑张量并行拆多卡，注意多卡还会引入通信缓冲区的额外开销， 这部分本工具没有建模，需要额外留。

最后必须强调一句：估算是用来选卡的，不是用来承诺容量的。这个公式给出的是数量级参考， 它不知道你用的是 vLLM 还是 SGLang，不知道你开没开 PagedAttention、开没开 prefix caching、 批处理策略是连续批还是静态批，也不知道你的显存池会被碎片吃掉多少。这些因素带来的偏差可以到几个 GB。 正确的用法是：用估算圈定候选方案，然后务必用实测校准——真机压测跑满目标并发， 观察显存峰值，再回过头修正你的余量比例。把估算值当成上线承诺，迟早会在某个流量高峰上翻车。

延伸阅读

想了解显存估算的完整推导和更多实操细节，可以看 大模型推理显存估算方法； 如果你还在纠结到底该不该自建， 自建算力与调用 API 的成本对比 这篇把两条路的账算给你看，建议先算完账再决定要不要买卡。