大语言模型需要多少显存？
一套为任意模型估算显存的实用方法：从权重和 KV 缓存，到额外开销和训练状态，附 Llama 3.1 的实际计算，并把结果对应到真实的 GPU。
FullGPU 工程团队
阅读约 8 分钟
LLM 需要多少显存：计算公式
对推理而言，显存占用可以分为三部分：
VRAM ≈ weights + KV cache + overhead
weights = parameters × bytes per parameter
KV cache = 2 × layers × KV heads × head dim × bytes per value × tokens in flight
overhead = activations, CUDA context, engine buffers (plan 10-30%)每个参数的字节数：BF16 或 FP16 为 2，FP8 或 INT8 为 1，4 位格式为 0.5。公式中的“tokens in flight”（在途 token 数）指上下文长度乘以同时处理的序列数。本文中的所有容量均以十进制 GB（即 10 亿字节）为单位，并且有意只做粗略估算：实际的检查点会把部分层保留为更高精度，推理引擎也是按块分配显存的。
不同精度下的模型权重
权重是显存需求的下限。如果连权重都装不下，其他一切都无从谈起。用参数量乘以每个参数的字节数即可：
| 参数量 | BF16 / FP16 | FP8 / INT8 | 4 位 |
|---|---|---|---|
| 8B | 16 GB | 8 GB | 4 GB |
| 14B | 28 GB | 14 GB | 7 GB |
| 32B | 64 GB | 32 GB | 16 GB |
| 70B | 140 GB | 70 GB | 35 GB |
| 120B | 240 GB | 120 GB | 60 GB |
| 405B | 810 GB | 405 GB | 203 GB |
FP8 和 4 位这两列应视为下限。量化格式会在权重旁边存储缩放因子，量化检查点通常还会把嵌入层和输出层保留为 16 位。这两层在小模型中占比更大：在 Llama 3.1 8B 中，这两个矩阵约有 10.5 亿个参数，BF16 精度下约 2.1 GB，超过模型其余部分在 4 位精度下所占空间的一半。精度还会影响质量，4 位的影响比 FP8 更大；我们关于 FP8 与 FP4 精度的解读文章介绍了其中的权衡。
KV 缓存：随上下文增长的显存
在生成过程中，对于它所处理的每个序列，模型会在每一层为每个 token 保存一个键向量和一个值向量。这就是 KV 缓存。在长上下文或大量并发用户的情况下，它占用的显存可能超过权重。
KV bytes per token = 2 × layers × KV heads × head dim × bytes per value
KV cache = KV bytes per token × context length × concurrent sequences现代架构正是在 KV 头数这一项上节省显存。Llama 3.1 采用分组查询注意力：70B 模型有 64 个查询头，但只有 8 个键值头，因此它的缓存只有完整多头注意力所需的八分之一。按官方公布的架构参数、采用 16 位缓存计算：
- Llama 3.1 8B（32 层，8 个 KV 头，头维度 128）：2 × 32 × 8 × 128 × 2 字节 = 131,072 字节，即每个 token 约 0.13 MB。
- Llama 3.1 70B（80 层，8 个 KV 头，头维度 128）：2 × 80 × 8 × 128 × 2 字节 = 327,680 字节，即每个 token 约 0.33 MB。
| 上下文长度 × 并发序列数 | 在途 token 数 | Llama 3.1 8B | Llama 3.1 70B |
|---|---|---|---|
| 8,192 × 1 | 8,192 | 1.1 GB | 2.7 GB |
| 8,192 × 16 | 131,072 | 17.2 GB | 42.9 GB |
| 32,768 × 1 | 32,768 | 4.3 GB | 10.7 GB |
| 32,768 × 8 | 262,144 | 34.4 GB | 85.9 GB |
| 131,072 × 1 | 131,072 | 17.2 GB | 42.9 GB |
| 131,072 × 4 | 524,288 | 68.7 GB | 171.8 GB |
由此可以得出三点结论。第一，在 70B 模型上，单个 128K token 的对话就需要约 43 GB 缓存，超过一张 H100 显存的一半。第二，16 个用户各用 8K token，所需缓存与这一个长对话完全相同，因为真正起作用的是在途 token 的总数。第三，FP8 缓存能让表中的每个数字减半，这正是 vLLM 等推理引擎把它作为可选项提供的原因。
这张表反映的是最坏情况。采用分页 KV 缓存的引擎会随着 token 的生成逐块分配显存，因此提前结束的请求不会占满它的全部上下文。请按在途 token 数的实际峰值来规划容量，而不是假设所有用户同时用满上限；但要确保至少能装下一个最大长度的请求。
额外开销与余量
权重和缓存还不是全部开销。在模型加载之前，CUDA 上下文和各种库就已在每张 GPU 上占用显存，通常从几百 MB 到一两 GB 不等。前向传播期间，激活值需要工作空间，并在处理长提示词时达到峰值。推理引擎还会为 CUDA Graph 和采样缓冲区预留显存，多 GPU 任务则会额外占用通信缓冲区。
计算示例：部署 Llama 3.1 70B 推理服务
假设您要用 Llama 3.1 70B 为 16 个并发用户提供推理服务，每个用户最多 8,192 个 token。
- FP8 权重：约 70 GB，实际略多一些。
- BF16 KV 缓存：16 × 8,192 个 token × 0.33 MB ≈ 43 GB。
- 加上 15% 余量后的总量：(70 + 43) × 1.15 ≈ 130 GB。
这在单张 141 GB 的 H200 上装得下，在单张 80 GB 的 H100 上却装不下：权重几乎占满整张卡，只给缓存留下几 GB，同一时间只够处理一两个 8K 请求，而不是 16 个。用 FP8 把缓存减半后，总量约为 105 GB，仍然需要不止一张 H100。
在 BF16 精度下，仅权重就约有 140 GB。这实际上排除了单张 H200，因为缓存将无处容身。180 GB 的 B200 装下权重并扣除额外开销后，还剩约 20 GB，大约够 6 个用满 8K token 的请求使用，采用 FP8 缓存则约为 12 个。288 GB 的 B300 能服务全部 16 个用户，且仍有余量。
微调所需显存：全参数微调、LoRA 与 QLoRA
训练时每个参数所需的显存远多于推理，因为 GPU 还要存放梯度和优化器状态。下表数字不含激活值；激活值取决于序列长度和微批次大小，通常借助激活检查点（梯度检查点）加以控制。
| 方法 | 显存中存放的内容 | 8B 模型 | 70B 模型 |
|---|---|---|---|
| 全参数微调（AdamW，混合精度） | |||
| BF16 基座模型上的 LoRA | 冻结的 16 位权重，外加小型适配器及其优化器状态 | 约 17 GB | 约 145 GB |
| 4 位基座模型上的 QLoRA | 冻结的 4 位权重、16 位嵌入层和输出层、适配器 | 约 7 GB |
实际上，对 8B 模型做 LoRA，32 GB 的 RTX 5090 或 48 GB 的 L40S 就能装下，还能为激活值留出空间。对同一模型做全参数微调，则需要 180 GB 的 B200 或 288 GB 的 B300，或者使用多张 80 GB GPU 并对优化器状态进行分片。到了 70B，QLoRA 单张 H100 或 H200 即可装下；LoRA 需要两张 80 GB GPU，或者一张 B200 或 B300；全参数微调则需要一台 8 卡 B300 服务器、采用精简配置的 8× B200，或者把优化器状态卸载到 CPU 内存的 8× H200。我们的 70B 模型微调指南逐一分析了每种情况。
MoE 模型：所有专家都必须装入显存
混合专家（MoE）模型会把每个 token 路由到众多专家中的少数几个。这降低的是每个 token 的计算量，而不是显存：所有专家都必须常驻显存，因为下一个 token 可能用到其中任何一个。请按总参数量估算 MoE 模型的显存，激活参数量只作为计算量的参考。
- Mixtral 8x7B 总参数量为 46.7B，但每个 token 只用到约 12.9B。在 BF16 精度下，它的权重仍需约 93 GB，超过单张 H100 的容量。
Qwen3-235B-A22B DeepSeek-V3
缓存大小仍取决于注意力机制的设计。DeepSeek 的模型采用多头潜在注意力，存储的是压缩后的缓存，因此上面的公式会高估它们的缓存。关于这一系列模型，请参阅我们的 DeepSeek 硬件要求指南。
哪款 GPU 装得下您的模型
下表把这些数字对应到实际的推理硬件上，假设上下文长度和并发量都处于中等水平。“勉强装下”表示权重装得下，但留给缓存的空间很少。
| GPU | 显存 | 宽裕装下 | 勉强装下 |
|---|---|---|---|
| RTX 5090 | 32 GB | 8B（BF16）、14B（FP8）、32B（4 位） | 14B（BF16） |
| L40S | 48 GB | 14B（BF16）、32B（FP8） | 70B（4 位） |
| H100 | 80 GB | 32B（BF16）、70B（4 位） | 70B（FP8） |
| RTX PRO 6000 | 96 GB | 32B（BF16）、120B（4 位） | 70B（FP8） |
| H200 | 141 GB | 70B（FP8），可承载真实并发 | 120B（FP8） |
| B200 | 180 GB | 120B（FP8）；70B（BF16），中等并发 | 70B（BF16），长上下文 |
| B300 或 MI355X | 288 GB | 70B（BF16），大批次；120B（FP8），长上下文 | 120B（BF16）、405B（4 位） |
| 8× H100 | 640 GB | 405B（FP8）、235B MoE（BF16） | — |
| 8× RTX PRO 6000 | 768 GB | 405B（FP8），经 PCIe 互联 | |
| 8× H200 | 1,128 GB | — | |
| 8× B200 | 1,440 GB | 405B（BF16），长上下文 | — |
| 8× B300 或 8× MI355X | 2,304 GB | — |
关于多 GPU 部署，有两点需要注意。第一，用张量并行拆分模型时，KV 缓存也会随之拆分，因此缓存容量会随 GPU 数量增长。第二，互联很重要：HGX 服务器上的 GPU 通过 NVLink 互联，而 RTX PRO 6000 和 L40S 显卡之间通过 PCIe 通信，这用来运行模型的多个独立副本没有问题，但把一个模型拆分到多张卡上时就会慢一些。如需按工作负载排序的推荐，请参阅我们的大语言模型推理最佳 GPU 选型指南。
以上所有内容都假设您拿到的是整张卡。我们出租的每张 GPU 都是一整张物理 GPU，因此表中的全部显存都归您使用，无需扣除 vGPU 配置文件或 MIG 分区。如果您的目标是以 FP8 运行 70B 模型并承载真实并发，NVIDIA H200 页面列出了单卡和 8 卡两种配置。
常见问题
运行 70B 模型需要多少显存？
8B 模型需要多少显存？
上下文长度真的会影响显存占用吗？
会。KV 缓存随上下文长度和并发序列数线性增长。在 Llama 3.1 70B 上，单个 128K token 的请求在 BF16 精度下需要约 43 GB 缓存，超过一张 H100 显存的一半。
可以把多张 GPU 的显存合起来用吗？
可以。推理引擎和训练框架可以通过张量并行或流水线并行把模型拆分到多张 GPU 上，KV 缓存也会随之拆分。这在 NVLink 上效果最好，例如 8 卡 HGX 服务器；通过 PCIe 也能运行，但通信开销更大。
GPU 标称的显存都能用上吗？
不完全能：CUDA 上下文、各种库和框架缓冲区会在每张 GPU 上占用一部分显存，推理服务器还会为激活值预留工作空间。在共享或分区的 GPU 上，您可能只能拿到其中一个切片，因此请确认您租用的是整张卡。
