跑一个模型要多少显存：先回答四个问题，再决定买哪张卡
有人在群里问「跑一个模型要多少显存」，然后收到十几个互相矛盾的数字，这事我见得太多了。问题不在回答的人不专业，在于这个问题本身缺条件——它不是一个常数，是一个四元函数：精度、上下文长度上限、并发数、框架余量。这四个数不给全，任何一个具体的 GB 数字都是猜的。
同一个模型，两种用法差近五倍
先看一个反例，让这件事有个直观的量级。下面所有数字都是假设参数，只用来演示算术关系，不代表任何真实模型的实际需求：
- 假设模型参数量 10B，精度 FP16（每参数 2 字节）→ 权重占 10 × 2 = 20 GB
- 假设单路请求每 1K token 的 KV cache 占 0.1 GB（这个系数取决于层数、头数、head_dim，每个模型都不同）
- 余量按 15% 估
用法一：内部工具，一个人用，上下文 2K。 KV cache = 0.1 × 2 × 1 = 0.2 GB，权重加 KV = 20.2 GB，乘 1.15 的余量系数 ≈ 23.23 GB。
用法二：对外服务，并发 100 路，上下文 8K。 KV cache = 0.1 × 8 × 100 = 80 GB，权重加 KV = 100 GB，乘 1.15 ≈ 115 GB。
115 ÷ 23.23 ≈ 4.95 倍。同一份权重，同一个精度，只因为上下文和并发变了，显存需求差了快五倍——一个能塞进单卡，一个得上整机多卡。所以下次再有人问你这个问题，先反问他这四个条件，而不是报数字。
三块构成，一段话讲完
显存拆成三块：权重是固定的，等于参数量乘以每参数字节数，一旦模型和精度定了它就不动了；KV cache 是变量，随上下文长度和并发数线性增长，是所有意外 OOM 的主因；余量必须留，推理框架的运行时、CUDA 上下文、中间激活值、显存池预分配和碎片，这些加起来不是可以忽略的零头。公式的推导过程我在模型需要多少显存：权重、KV cache 与余量的三块估算法里写过，这篇不重复。
这里给个更省事的做法：把你的参数量、精度、上下文、并发直接填进显存估算器，一秒出三块的拆分结果，比在纸上推快得多，也不容易把字节数乘错。本文剩下的部分不讲怎么算，只讲算出来之后该怎么决策。
场景 A：我有一张卡，想知道能跑多大的模型
这种情况要倒着算——从卡的可用显存开始扣，最后剩下的才是权重预算。步骤是固定的四步（下面仍用假设值演示，你把 48 换成自己那张卡的可用显存即可，具体容量请对照你手上卡的规格）：
- 先扣余量。 假设可用显存 48 GB，按 15% 余量倒推，能给权重和 KV 的部分是 48 ÷ 1.15 ≈ 41.74 GB。
- 再扣目标并发的 KV cache。 假设目标并发 8 路、上下文上限 4K，按前面 0.1 GB/1K/路 的假设系数，KV = 0.1 × 4 × 8 = 3.2 GB。
- 剩下的就是权重预算。 41.74 − 3.2 ≈ 38.54 GB。
- 除以每参数字节数得到参数量上限。 FP16 是 38.54 ÷ 2 ≈ 19.3B；如果接受 INT4（0.5 字节），38.54 ÷ 0.5 ≈ 77B。
第 4 步的两个结果放在一起就是这套算法最有价值的地方：同一张卡，精度选择直接决定了你的模型档位上限差四倍。要不要为了上更大的模型去换精度，是个质量取舍问题，判断标准我写在模型量化怎么选：不看别人的跑分，用自己的验收标准决定上不上里，核心是别信别人的跑分、用自己的验收集测。
注意第 2 步用的是目标并发不是当前并发。倒着算的时候人最容易犯的错，是拿”我现在就一个人测”去扣 KV，算出一个虚高的参数量上限，然后选了个上线就跑不动的模型。
场景 B：我有一个模型，想知道该买/租什么卡
这种情况正着算，但必须加一道预留。还是假设 10B、FP16、权重 20 GB：
按今天的量算： 并发 4 路、上下文 8K → KV = 0.1 × 8 × 4 = 3.2 GB，合计 23.2 GB，乘 1.15 ≈ 26.68 GB。
按三个月后翻两番算： 并发 16 路、上下文不变 → KV = 0.1 × 8 × 16 = 12.8 GB，合计 32.8 GB，乘 1.15 ≈ 37.72 GB。
两者相差 11.04 GB。这 11 GB 的意义在于：显存容量是离散档位，不是连续的。26.68 和 37.72 很可能落在两个不同的档位上，也可能一个够一个不够。按今天的并发选卡，等于赌业务不涨——而只要业务真的起来了，你就得在最忙的时候做迁移，那是最难受的时机。
我的做法是按目标并发的 2 到 4 倍做预留，然后再看卡。至于消费卡和专业卡在 ECC、多卡互联、租用可得性上的区别，推理 GPU 选型：RTX 4090、A100、H100 怎么选那篇讲了维度，选之前值得过一遍。
场景 C：算出来装不下怎么办
这一步最容易被人一步跳到量化，其实量化应该是最后一条路。按对质量的影响从小到大排，优先级是这样的：
第一条，降上下文上限。 大部分业务的真实请求长度分布，比设置的上限低得多。把 32K 的上限压到 8K，KV cache 直接降到四分之一，而如果你 99% 的请求本来就不到 8K，用户感知不到任何变化。做这个决定之前先去日志里统计一下真实的长度分布，别拍脑袋。
第二条，降并发上限。 把超出的请求排队，而不是让它们挤进显存。排队会增加尾部延迟，但延迟变长和整个服务 OOM 崩掉，严重性完全不是一个级别。框架侧一般都有并发或批大小的上限参数，具体名称以你所用推理框架的官方文档为准。
第三条，多卡切分。 用张量并行或流水线并行把权重摊到多张卡上。代价是引入卡间通信开销，且对互联方式敏感，但它不损失任何输出质量。
第四条，才是量化。 前三条都是纯工程取舍，只有量化会动模型本身的数值精度。而且要清楚一点：量化压的主要是权重那一块，如果你的瓶颈根本在 KV cache（长上下文、高并发的场景），压权重的收益会比预期小很多——先看清楚三块的拆分比例再决定压哪一块。
场景 D：算出来刚好够，能不能上
不能。这是我最想让人记住的一条。
“算得刚好”等于”一上量就 OOM”，原因有四个，每一个都足以吃掉你那点富余：
- 估算天然偏小。 公式覆盖的是权重和 KV，框架运行时、CUDA 上下文、激活值、显存碎片这些只能给个笼统系数，实际往往更高。
- KV cache 的占用是波动的。 它跟着当下在跑的请求走。平均并发 4 路不代表不会瞬间来 8 路，估算算的是均值，OOM 发生在峰值。
- 显存碎片会随运行时间累积。 启动后跑十分钟的占用和跑十小时的占用不是一回事。
- OOM 不是降级是崩溃。 内存不够可以变慢，显存不够是进程直接挂掉，正在处理的请求全丢。
所以显存这件事没有”刚好够”这个状态，只有”有富余”和”迟早出事”两种。留出可观的头寸，是这类系统唯一稳妥的做法。
KV cache 为什么是关键：双线性增长
把上面几个场景串起来看，真正的变量只有一个——KV cache 随上下文长度和并发数同时线性增长，也就是随两者的乘积增长。用前面那套假设参数（10B、FP16、权重 20 GB、0.1 GB/1K/路、15% 余量）做两张小表就很清楚：
上下文 8K 时：
| 并发 | KV cache | 相对倍数 | 含权重与余量的总量 |
|---|---|---|---|
| 1 | 0.8 GB | 1× | 23.92 GB |
| 4 | 3.2 GB | 4× | 26.68 GB |
| 16 | 12.8 GB | 16× | 37.72 GB |
上下文 32K 时：
| 并发 | KV cache | 相对倍数 | 含权重与余量的总量 |
|---|---|---|---|
| 1 | 3.2 GB | 1× | 26.68 GB |
| 4 | 12.8 GB | 4× | 37.72 GB |
| 16 | 51.2 GB | 16× | 81.88 GB |
两张表放一起有三个值得盯住的地方。
一是KV 那一列严格按并发倍数走，并发翻两番，KV 就是 16 倍，没有任何摊薄效应。
二是总量的涨幅被权重稀释了。8K 那张表里 KV 涨了 16 倍，总量只从 23.92 涨到 37.72，约 1.58 倍——因为 20 GB 的权重是不动的大头。这解释了为什么小并发时大家感觉”加并发不怎么吃显存”，然后在某个点突然撑不住：权重的稀释效应是有尽头的，越过之后每一路并发都是实打实的成本。
三是乘积相同则 KV 相同。8K × 并发 16 和 32K × 并发 4，KV 都是 12.8 GB，总量都是 37.72 GB。这条对做取舍很有用——当你要在”支持更长文档”和”支持更多人同时用”之间选，本质上是在花同一笔显存预算。
这两张表你不用抄我的假设系数，去显存估算器里填自己模型的配置，把并发数从 1 拨到 16 看总量怎么走，比看表更有感觉，也能立刻看出你的方案对流量波动到底有多敏感。
估算之后必须做的一件事：实测
估算是用来选卡的，不是用来承诺容量的。这两件事经常被混为一谈，代价是上线后的事故。卡到手之后，最小的验证流程是这样：
- 用真实的上下文长度分布，不是平均值。 从线上日志或试运行日志里抽样，保留长尾的那些长请求，因为决定峰值的就是它们。
- 压到目标并发，再往上压一档。 只压到目标值只能证明”刚好够”，而前面说过刚好够不算够。压到 1.5 到 2 倍，看它在哪一点崩，那个点才是你真正的容量。
- 跑够时间，看峰值不看启动值。 服务刚起来的显存占用意义不大，至少跑到碎片和缓存策略稳定下来。持续采样显存占用，记录峰值，用峰值对照卡容量。
- 观察并发被拒或排队的行为。 显存到顶时框架是排队还是报错，这个行为要在压测时看清楚，而不是在线上第一次遇到。
- 把这次的实测值反过来校准你的估算系数。 实测总量除以估算总量得到的比例，就是你这套模型加框架的真实余量系数，下次换模型估算时直接用它，比通用的 15% 准得多。
第 5 条是很多人漏掉的收尾动作。估算工具给的是通用系数，但你的框架、你的模型架构、你的部署方式有自己固定的偏差，测一次就能把这个偏差固化成你自己的经验值，之后所有估算的精度都会上一个台阶。
上线前自查清单
- 精度、上下文上限、目标并发、余量系数这四个数，我是不是都写下来了，而不是只记了一个总 GB 数。
- KV cache 用的是目标并发算的，不是”我现在测试时的一路”。
- 并发按未来 2 到 4 倍做了预留，而不是按今天的量刚好卡住档位。
- 估算结果不是”刚好够”——如果是，回到场景 C 的四条路，从降上下文上限开始，量化排最后。
- 上下文上限是查过真实请求长度分布之后定的，不是照抄默认值。
- 已经做过压测，记录的是跑够时间后的显存峰值，不是启动值。
- 实测值已经反过来校准了余量系数，并记在部署文档里，下次换模型直接复用。
四个变量确定之后，剩下的就是算术。把你的参数填进显存估算器，先把权重、KV、余量三块的比例看清楚，再对照本文的四个场景决定下一步动作。