大模型部署需要多大显存？参数规模、量化与GPU选型分析

部署大模型时被问得最多的一句话是"我这台机器够不够"。答案不能靠拍脑袋，也不能只看模型的参数规模。显存需求由几部分组成：模型权重、KV Cache、激活和框架开销。这篇文章给出一套可以自己动手算的估算方法，讲清楚参数量、精度、量化如何影响显存，配几个常见的规模例子，最后给 GPU 选型的方向。要提前说明：以下所有数字都是估算和量级参考，实际占用会随模型架构、序列长度、并发数、推理框架实现而不同，上线前务必以实测为准，并留出足够余量。

一、显存被谁吃掉了

推理时显存主要被四部分占用。

第一是模型权重（Weights）。这是模型的参数本身，大小由参数量和精度决定，是最容易估算的部分。

第二是 KV Cache（键值缓存）。Transformer 在生成每个新 token 时，要复用前面所有 token 的 Key 和 Value，缓存下来避免重复计算。它的大小随序列长度、并发数、模型层数和隐藏维度增长，是长上下文和高并发场景下的显存大头。

第三是激活（Activation）和中间张量。前向计算过程中的临时数据，通常比权重小很多，但和批大小相关。

第四是框架开销。推理引擎、CUDA 上下文、内存池等占用的固定部分，通常是几百 MB 到数 GB 量级。

很多人只算了权重，忽略了 KV Cache 和开销，结果模型加载进去后一上并发就 OOM。所以正确的做法是四部分都算，再留余量。

二、模型权重：参数量 × 精度字节数

这是最核心的公式，先记住每个参数的字节数。

FP32（单精度）：4 字节/参数。精度最高，显存最费，推理很少用。
FP16 / BF16（半精度）：2 字节/参数。推理和训练的常用默认。
INT8（8 位量化）：1 字节/参数。显存约减半，精度损失通常较小。
INT4（4 位量化）：0.5 字节/参数。显存约降到四分之一，需要考虑精度影响。

权重显存 ≈ 参数量 × 每参数字节数。以 70 亿参数（7B）模型为例：FP16 约 7 × 2 = 14 GB；INT8 约 7 GB；INT4 约 3.5 GB。再以 700 亿参数（70B）为例：FP16 约 140 GB；INT8 约 70 GB；INT4 约 35 GB。

把这些整理成一张表，方便对照。

这张表只是权重的"理论下界"。实际还要加上 KV Cache、激活和框架开销，并且量化后的模型可能因为反量化、分组缩放等额外数据略高于理论值。

三、KV Cache：长上下文和高并发的隐形开销

KV Cache 的估算稍微复杂。一个常用的经验公式是：

KV Cache ≈ 2 × 层数 × 隐藏维度 × 序列长度 × 并发数 × 精度字节数

那个 2 是因为 Key 和 Value 各一份。层数和隐藏维度取决于模型架构（比如常见的 7B 模型层数在 30 层上下，隐藏维度在 4000 左右，具体以模型为准）。序列长度是你允许的最大上下文（比如 4096、8192、32768），并发数是你希望同时服务的请求数。

举例估算：假设一个 7B 模型，层数 32，KV 输出维度合计约 4096，FP16（2 字节）。对单个序列长度 4096、并发 1 的情况，KV Cache ≈ 2 × 32 × 4096 × 4096 × 1 × 2 字节 ≈ 2 GB 量级。如果上下文加到 32768，或并发开到 8，这个数字会成倍甚至成十倍增长。

这就是为什么"同样的模型，短对话能跑，长文档和多人并发就 OOM"。降低 KV Cache 的手段有：用小一些的上下文长度、用 GQA/MQA 这类减少 KV 头的架构、用分页式 KV Cache 管理（如连续批处理框架）、用 KV 量化。

# 观察模型加载后与并发压测中的显存变化，反推 KV Cache 占用
nvidia-smi --query-gpu=memory.used,memory.total --format=csv -l 1
# 用 PyTorch 查看峰值显存（在服务进程内调用）
# python -c "import torch; print(torch.cuda.max_memory_allocated()/1024**3, 'GB')"

四、激活与框架开销

激活显存和批大小、序列长度相关，在推理时通常比权重小，但如果序列很长、批量很大也会明显增长。一般情况下，估算时可以按权重的百分之几到十几来预留，具体看框架实现和批大小。

框架开销是一个相对固定的量：CUDA 运行时、通信缓冲区、内存池碎片等，通常需要预留 1 到 3 GB。如果用了多卡并行，通信缓冲区会更大。

一个实用的经验是：在权重估算的基础上，再额外预留 10% 到 30% 的总显存作为激活和开销的缓冲，长上下文或高并发场景按上限甚至更多预留。

五、完整估算公式与示例

把上面几部分合起来，给出一个可以自己套用的估算流程：

总显存 ≈ 权重（参数量 × 字节数） + KV Cache + 激活（权重 × 5%~15%） + 框架开销（1~3 GB）

然后在这个结果上再留 20% 到 30% 的余量，作为峰值和碎片化的缓冲。

用几个典型例子走一遍（全部为估算量级，实际以实测为准）。

例子一：7B 模型，FP16，上下文 4096，并发 4。
权重约 14 GB；KV Cache 约 2 GB 乘以并发 4 的系数后约 6 到 8 GB；激活与开销约 2 到 3 GB。合计约 22 到 25 GB。所以单张 24 GB 显存的卡跑 7B FP16 会比较紧，要想多并发建议用 40 GB 以上或做量化。

例子二：7B 模型，INT4，上下文 4096，并发 8。
权重约 3.5 GB；KV Cache 约 6 到 8 GB；激活与开销约 2 GB。合计约 12 到 14 GB。一张 24 GB 卡就比较从容，还能再提并发。

例子三：70B 模型，INT4，上下文 8192，并发 4。
权重约 35 GB；KV Cache 约 10 到 16 GB 量级；激活与开销约 4 GB。合计约 50 到 55 GB。单张 80 GB 卡可容纳但并发有限；要更高并发或不用量化，需要两张卡（共 160 GB）做模型并行。

例子四：13B 模型，FP16，上下文 8192，并发 2。
权重约 26 GB；KV Cache 约 4 到 6 GB；激活与开销约 3 GB。合计约 33 到 35 GB。单张 48 GB 卡有余量，单张 24 GB 卡装不下 FP16 权重。

六、GPU 选型方向

有了估算的总显存，选卡就清晰了。核心原则是：单卡显存能装下最好，装不下就用多卡模型并行（分片），或者降精度量化。

按经验，24 GB 显存级别的卡适合 7B 到 13B 的量化模型和中小并发；40 到 48 GB 级别的卡适合 13B 到 34B 的模型；80 GB 级别的卡适合 70B 级别的量化模型和较大并发。更大规模（如 180B 以上、或 70B 的 FP16）通常需要多卡组合。

多卡方案要注意：显存总量不会自动叠加成一张大卡，需要用张量并行/流水线并行等技术把模型真正切开，且伴随通信开销。卡间互联越强，多卡效率越高（这在 095 篇讲过）。选卡时不能只看总显存之和，还要看互联能力。

七、省显存的几套组合拳

如果显存紧张，有几条思路可以组合使用，按收益从大到小排列。

第一，量化。INT8 直接减半，INT4 降到约四分之一，是最有效的手段，但要评估精度。

第二，缩短上下文。上下文长度对 KV Cache 是线性影响，把 32K 降到 8K 能省一大截，前提是业务能接受。

第三，控制并发。并发数直接乘进 KV Cache，限制最大并发是防 OOM 的简单办法。

第四，用高效的 KV Cache 管理和连续批处理框架，减少碎片和浪费。

第五，多卡模型并行，把权重分散到多张卡上。

第六，用小架构优化（GQA 等）的模型，本身 KV Cache 就更小。

# 用容器限制和观测显存分配，配合框架参数调优
# 常见框架参数（示意，不同框架参数名不同）：
# --max-model-len 8192       限制上下文长度
# --gpu-memory-utilization 0.9  限制框架使用的显存比例
# --max-num-seqs 8          限制最大并发序列数
# 观测显存与利用率
nvidia-smi --query-gpu=memory.used,memory.total,utilization.gpu --format=csv -l 1

常见问题

Q：显存估算出来的数字和实际差多少？
可能差不少，尤其在长上下文、高并发、多卡场景。本文给的是量级估算，用于快速判断方向。上线前一定要做实测，并留 20% 到 30% 余量。

Q：INT4 量化后显存真的只要四分之一吗？
理论上接近，但量化后会引入分组缩放等额外数据，实际略高于理论值，KV Cache 也不会自动减少。所以总量不是简单除四。

Q：为什么模型加载后没跑起来就占了很多显存？
框架初始化、CUDA 上下文、内存池预分配都会占显存。这部分是固定开销，和模型大小无关，通常 1 到 3 GB。

Q：一张大卡的显存等于两张小卡之和吗？
不等。两张卡做模型并行时，权重可以分片，但通信有开销，且中间激活可能需要在卡间传递。显存总量也不是无脑相加，要留出通信缓冲。

Q：能不能用主机内存或磁盘当"显存"？
有技术（如内存卸载、分层加载）能把部分权重放在主机内存或磁盘，但速度会显著下降，适合对延迟不敏感的场景，不适合高并发在线服务。

Q：同一模型，为什么别人的机器能跑我不能？
可能是上下文长度、并发上限、量化精度、推理框架、模型实现（如 KV 头数）不同。比显存需求时要在相同条件下比较。

总结

大模型推理的显存由四部分组成：模型权重、KV Cache、激活、框架开销。只算权重是新手最常见的错误，KV Cache 在长上下文和高并发下会成大头。

权重估算记住公式：参数量 × 精度字节数。FP16 是 2 字节，INT8 是 1 字节，INT4 是 0.5 字节。7B 在 FP16 约 14 GB，70B 约 140 GB，量化后相应减少。

KV Cache 随层数、隐藏维度、序列长度、并发数线性增长，是"短对话能跑、长文档和多人并发就 OOM"的根因。控制手段是缩短上下文、限制并发、用高效 KV 管理。

总显存留 20% 到 30% 余量。单卡装得下最省事，装不下就用多卡模型并行或量化。选卡要同时看显存容量和卡间互联。

本文所有数字均为估算和量级参考，实际占用受模型架构、框架实现、序列长度、并发等因素影响，请以实测为准，并参考模型和硬件的官方文档确认兼容性与规格。