选型 指南 · 阅读需 9 分钟

# 一个模型实际需要多少显存。

两个数字决定了一切：固定不变的权重，以及随您所服务的上下文量增长的 KV 缓存。几乎所有的错误答案，都是因为用第一个数字去推算第二个数字。

简短的答案

- **Weights:** 参数量（十亿）× 每参数字节数。70B 在 4-bit 下是 **35 GB**。
- **KV 缓存:** 2 × 层数 × KV 头数 × 头维度 × 字节数，每 token 计算。与参数量无关。
- **Overhead:** 为激活值、CUDA 上下文和分配器碎片再加上约 **15%**。
- **陷阱:** 把权重量化到 4-bit，**并不会**量化缓存。在所有常见的技术栈中，它都保持 FP16。

## 公式

这里没有哪条经验法则能经受住第二个模型的检验。整个计算只有三行，亲自算一遍是值得的，不要指望一个简单的倍数。

总显存（GB）

```
# 1. Weights
weights_gb   = parameters_in_billions × bytes_per_parameter

# 2. KV cache, per token — then multiplied by the context you serve
bytes_per_tok = 2 × layers × kv_heads × head_dim × cache_bytes
cache_gb      = bytes_per_tok × context_tokens × batch / 1024³

# 3. Everything else
total_gb      = (weights_gb + cache_gb) × 1.15
```

这里的 `2` 是因为每个 token 有两个张量，K 和 V。`bytes_per_parameter` 在 BF16 下是 2，FP8 下是 1，4-bit 下是 0.5。`cache_bytes` 是一个*独立*的数字，这种独立性正是错误答案最常见的来源——见[下文](https://gpuserver.io/zh/guides/vram-sizing#wrong)。

## 权重

简单的一半。它与参数量完全成线性关系，唯一需要决定的是精度。

**权重显存，按精度划分，涵盖若干模型规模**

| 模型 | BF16 / FP16 | FP8 | 4-bit (AWQ, GPTQ) |
|---|---|---|---|
| Llama 3.1 8B 8B 参数 | 16.0 GB | 8.0 GB | 4.0 GB |
| Qwen 3 32B 32B 参数 | 64.0 GB | 32.0 GB | 16.0 GB |
| Llama 3.3 70B 70B 参数 | 140.0 GB | 70.0 GB | 35.0 GB |
| Llama 3.1 405B 405B 参数 | 810.0 GB | 405.0 GB | 202.5 GB |

4-bit 量化会牺牲一定质量，具体牺牲多少，取决于模型本身，远胜于取决于量化方法。当它决定的是一张显卡还是四张显卡的差别时，这笔交易是划算的；如果您本来就已经绰绰有余，这笔交易就不划算。

## KV 缓存

困难的一半，也是决定一台机器在 4k 时是否够用、在 128k 时是否毫无胜算的那一半。它取决于层数和 KV 头数——*而不是*模型有多大。

**两个体量截然不同的模型，并排对比。** Llama 3.3 70B 有 80 层、8 个 KV 头，因此 每个 token 需要 320 KB。 Gemma 3 27B——参数量只有前者的三分之一——却有 62 层、16 个 KV 头，因此 每个 token 需要 496 KB，是前者的 1.6×*还多*。 任何按参数量线性推算的估算，都会把这个关系完全弄反。

**KV 缓存大小，按模型和上下文长度划分，缓存精度为 FP16，单个请求**

| 模型 | 每个 token | 4k 上下文 | 8k 上下文 | 32k 上下文 | 128k 上下文 |
|---|---|---|---|---|---|
| Llama 3.1 8B 32 层 · 8 个 KV 头 | 128 KB | 0.5 GB | 1.0 GB | 4.0 GB | 16.0 GB |
| Gemma 3 27B 62 层 · 16 个 KV 头 | 496 KB | 1.9 GB | 3.9 GB | 15.5 GB | 62.0 GB |
| Llama 3.3 70B 80 层 · 8 个 KV 头 | 320 KB | 1.3 GB | 2.5 GB | 10.0 GB | 40.0 GB |
| DeepSeek V3 671B-A37B (MoE) 潜在注意力 | 70 KB | 0.3 GB | 0.5 GB | 2.2 GB | 8.8 GB |
| Llama 3.1 405B 126 层 · 8 个 KV 头 | 504 KB | 2.0 GB | 3.9 GB | 15.8 GB | 63.0 GB |

请先看最后一列，再看第一列。在 4k 上下文下，这里每个模型的缓存都小到可以忽略；到了 128k，缓存就会大于一个 70B 模型在 4-bit 下的权重。DeepSeek V3 是个例外，因为它的潜在注意力设计上就压缩了缓存——这也是它虽然是这份清单里最大的模型，却仍能在长上下文下可用的原因。

## 估算容易出错的地方

**根据参数量来推算缓存大小。**这是最常见的错误，也是上面示例中出现的那个。一个 27B 模型所需的缓存，可能比一个 70B 模型还要大。

**以为 4-bit 权重就意味着 4-bit 缓存。**事实并非如此。AWQ 和 GPTQ 只量化权重；除非您明确启用 FP8 KV，否则缓存始终保持 FP16。一个 70B 模型在 4-bit、128k 上下文下，权重为 35 GB，缓存为 40 GB。

**只按一个请求来估算。**缓存是按并发序列计算的。同时服务 8 个用户，需要 8 倍的缓存——见[下文](https://gpuserver.io/zh/guides/vram-sizing#batch)。

**忽略了开销。**激活值、CUDA 上下文和分配器碎片都是实实在在存在的。15% 是刻意留出的保守余量；完全忽略它，就是一个“放得下”的模型最终加载失败的原因。

**把多张显卡的显存加总计算。**四张 24 GB 显卡不等于一张 96 GB 显卡。张量并行可以把模型拆分到它们上面，但每一层都要通过链路同步——见[NVLink 指南](https://gpuserver.io/zh/guides/nvlink-vs-pcie)。

**按激活参数量来估算 MoE 的显存需求。**DeepSeek V3 每个 token 只激活 37B，但您必须在显存中容纳全部 671B。激活参数决定的是*速度*；总参数量决定的是它到底能不能加载。

## 实例演算

所需的总显存，即权重加缓存加开销，按 8k 上下文、单个请求计算。这与配置器针对产品目录中每种配置所运行的计算相同。

**8k 上下文下所需的总显存，按模型和精度划分**

| 模型 | BF16 / FP16 | FP8 | 4-bit (AWQ, GPTQ) | 能放得下的最小节点 |
|---|---|---|---|---|
| Llama 3.1 8B 8B 参数 | 20 GB | 10 GB | 6 GB | [NVIDIA L4](https://gpuserver.io/zh/gpu/nvidia-l4) $125/月 · 单张显卡 · ~34 tok/s |
| Mistral Small 24B 24B 参数 | 57 GB | 28 GB | 15 GB | [NVIDIA L4](https://gpuserver.io/zh/gpu/nvidia-l4) $125/月 · 单张显卡 · ~11 tok/s |
| Gemma 3 27B 27B 参数 | 67 GB | 33 GB | 20 GB | [NVIDIA L4](https://gpuserver.io/zh/gpu/nvidia-l4) $125/月 · 单张显卡 · ~10 tok/s |
| Qwen 3 32B 32B 参数 | 76 GB | 38 GB | 21 GB | [NVIDIA L4](https://gpuserver.io/zh/gpu/nvidia-l4) $125/月 · 单张显卡 · ~8 tok/s |
| Llama 3.3 70B 70B 参数 | 164 GB | 82 GB | 43 GB | [2 × NVIDIA L4](https://gpuserver.io/zh/gpu/nvidia-l4) $285/月 · 拆分到整个节点 · ~7 tok/s |
| Mixtral 8×22B (MoE) 141B 中激活 39B | 326 GB | 163 GB | 83 GB | [4 × NVIDIA L4](https://gpuserver.io/zh/gpu/nvidia-l4) $564/月 · 拆分到整个节点 · ~4 tok/s |
| Qwen 3 235B-A22B (MoE) 235B 中激活 22B | 542 GB | 271 GB | 137 GB | [8 × NVIDIA L4](https://gpuserver.io/zh/gpu/nvidia-l4) $1,106/月 · 拆分到整个节点 · ~10 tok/s |
| DeepSeek V3 671B-A37B (MoE) 671B 中激活 37B | 1,544 GB | 772 GB | 386 GB | [8 × NVIDIA A100 PCIe](https://gpuserver.io/zh/gpu/a100-80gb) $7,906/月 · 拆分到整个节点 · ~37 tok/s |
| Llama 3.1 405B 405B 参数 | 936 GB | 468 GB | 237 GB | [10 × NVIDIA L4](https://gpuserver.io/zh/gpu/nvidia-l4) $1,371/月 · 拆分到整个节点 · ~3 tok/s |

最后一列是我们产品目录中，能在 4-bit、8k 上下文下容纳该模型的最便宜节点，以及显存带宽所能达到的单流生成速率。吞吐量数字刻意取保守值，并参照已发表的测量数据进行了校准——请把它们当作下限，而不是承诺。

## 同时服务多个请求

这就是一台为演示而配置的服务器，变成一台撑不起产品的服务器的地方。权重只需付出一次；缓存则要按每个并发序列付出代价。

**Llama 3.3 70B 在 4-bit 下所需的总显存，按并发请求数和上下文长度划分**

| 并发请求 | 4k 上下文 | 8k 上下文 | 32k 上下文 |
|---|---|---|---|
| 1 个请求 | 42 GB 一张 80 GB 显卡 | 43 GB 一张 80 GB 显卡 | 52 GB 一张 80 GB 显卡 |
| 4 个请求 | 46 GB 一张 80 GB 显卡 | 52 GB 一张 80 GB 显卡 | 86 GB 一张 H200 |
| 16 个请求 | 63 GB 一张 80 GB 显卡 | 86 GB 一张 H200 | 224 GB 多 GPU 节点 |
| 64 个请求 | 132 GB 一张 H200 | 224 GB 多 GPU 节点 | 776 GB 多 GPU 节点 |

无论怎么做，Llama 3.3 70B 在 4-bit 下的权重都是 35 GB。表格中超出 35 GB 的部分都是缓存。这就是为什么“在我笔记本上跑得好好的”和“在生产环境里崩了”，说的其实是同一个模型、同一张显卡。

**两种找回缓存显存的方法。** 如果您的技术栈支持，就开启 FP8 KV 缓存——能让上面的数字减半，质量代价通常察觉不到。同时把 `--max-model-len` 限制在您实际使用的上下文长度：vLLM 会按声明的最大值预留缓存，声明 128k 而实际只用 8k，就会白白浪费 16 倍于所需的显存。

## 换算成哪台服务器

由以上内容得出的三条实用规则，按重要性排序。

1. **只要可能，一张显卡总是优于多张。**无需拆分，层与层之间无需同步，也不用考虑互联。如果您的模型在您的上下文长度下能放进一张显卡，就买那张显卡。
2. **按您实际的上下文长度和实际并发数来估算**，而不是按模型宣称的最大值。宣称的最大值是一种能力上限，不是要求。
3. **必须拆分时，优先选择 NVLink。**拆分到四张 PCIe 显卡上可行；拆分到四张 NVLink 显卡上同样可行，而且明显更快。[下一篇指南](https://gpuserver.io/zh/guides/nvlink-vs-pcie)正是讨论这种差异何时值得为之付费。

[配置器](https://gpuserver.io/zh/configure)会针对全部 41 种配置实时运行这一计算：选择一个模型、一种精度和一个上下文长度，它就会告诉您哪些节点能容纳它、哪些能在单张显卡上容纳它，以及每种配置每月的价格。它使用的就是本页上的这套公式，所以如果您不认同我们的算法，现在可以准确指出问题出在哪里。

## 用您自己的模型对照我们出租的每一台服务器进行核对。

配置器会在您付款之前，针对全部 41 种配置完成上面的计算。

[打开配置器](https://gpuserver.io/zh/configure) [阅读指南](https://gpuserver.io/zh/guides)

## 其他指南

- [选型 · 7 分钟 NVLink 还是 PCIe：您的任务需要哪一个 显卡之间的互联方式何时决定您的整体吞吐量、何时又毫无影响，以及如何在为错误的节点付费之前判断自己属于哪一种情况。 阅读指南](https://gpuserver.io/zh/guides/nvlink-vs-pcie)
- [选型 · 9 分钟 为图像与视频模型选择显卡 FLUX、SDXL、SD 3.5 与 Wan 2.1 各需要多少显存、我们产品目录中哪款显卡能放下，以及为何能放下的最便宜显卡很少是该租的那一款。 阅读指南](https://gpuserver.io/zh/guides/gpu-for-flux-sdxl)
- [选型 · 10 分钟 选择量化格式 AWQ、GPTQ、GGUF 与 FP8 各自在显存占用、运行速度与生成质量上分别付出的代价——以及为何参数权重最小的格式，却很少能带来体积最小的模型。 阅读指南](https://gpuserver.io/zh/guides/awq-vs-gptq-vs-fp8)

---

来源：https://gpuserver.io/zh/guides/vram-sizing/。本文件由与网站相同的数据生成；如果此处的数字与页面不一致，以页面为准，本文件视为过期——权威来源是 https://gpuserver.io/。