一个模型实际需要多少显存。
两个数字决定了一切：固定不变的权重，以及随您所服务的上下文量增长的 KV 缓存。几乎所有的错误答案，都是因为用第一个数字去推算第二个数字。
简短的答案
- Weights
- 参数量（十亿）× 每参数字节数。70B 在 4-bit 下是 35 GB。
- KV 缓存
- 2 × 层数 × KV 头数 × 头维度 × 字节数，每 token 计算。与参数量无关。
- Overhead
- 为激活值、CUDA 上下文和分配器碎片再加上约 15%。
- 陷阱
- 把权重量化到 4-bit，并不会量化缓存。在所有常见的技术栈中，它都保持 FP16。
公式
这里没有哪条经验法则能经受住第二个模型的检验。整个计算只有三行，亲自算一遍是值得的，不要指望一个简单的倍数。
# 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 是一个独立的数字，这种独立性正是错误答案最常见的来源——见下文。
权重
简单的一半。它与参数量完全成线性关系，唯一需要决定的是精度。
| 模型 | BF16 / FP16 | FP8 | 4-bit (AWQ, GPTQ) |
|---|---|---|---|
| Llama 3.1 8B | 16.0 GB | 8.0 GB | 4.0 GB |
| Qwen 3 32B | 64.0 GB | 32.0 GB | 16.0 GB |
| Llama 3.3 70B | 140.0 GB | 70.0 GB | 35.0 GB |
| Llama 3.1 405B | 810.0 GB | 405.0 GB | 202.5 GB |
4-bit 量化会牺牲一定质量，具体牺牲多少，取决于模型本身，远胜于取决于量化方法。当它决定的是一张显卡还是四张显卡的差别时，这笔交易是划算的；如果您本来就已经绰绰有余，这笔交易就不划算。
KV 缓存
困难的一半，也是决定一台机器在 4k 时是否够用、在 128k 时是否毫无胜算的那一半。它取决于层数和 KV 头数——而不是模型有多大。
| 模型 | 每个 token | 4k 上下文 | 8k 上下文 | 32k 上下文 | 128k 上下文 |
|---|---|---|---|---|---|
| Llama 3.1 8B | 128 KB | 0.5 GB | 1.0 GB | 4.0 GB | 16.0 GB |
| Gemma 3 27B | 496 KB | 1.9 GB | 3.9 GB | 15.5 GB | 62.0 GB |
| Llama 3.3 70B | 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 | 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 倍的缓存——见下文。
忽略了开销。激活值、CUDA 上下文和分配器碎片都是实实在在存在的。15% 是刻意留出的保守余量；完全忽略它，就是一个“放得下”的模型最终加载失败的原因。
把多张显卡的显存加总计算。四张 24 GB 显卡不等于一张 96 GB 显卡。张量并行可以把模型拆分到它们上面，但每一层都要通过链路同步——见NVLink 指南。
按激活参数量来估算 MoE 的显存需求。DeepSeek V3 每个 token 只激活 37B，但您必须在显存中容纳全部 671B。激活参数决定的是速度；总参数量决定的是它到底能不能加载。
实例演算
所需的总显存，即权重加缓存加开销，按 8k 上下文、单个请求计算。这与配置器针对产品目录中每种配置所运行的计算相同。
| 模型 | BF16 / FP16 | FP8 | 4-bit (AWQ, GPTQ) | 能放得下的最小节点 |
|---|---|---|---|---|
| Llama 3.1 8B | 20 GB | 10 GB | 6 GB | NVIDIA L4 |
| Mistral Small 24B | 57 GB | 28 GB | 15 GB | NVIDIA L4 |
| Gemma 3 27B | 67 GB | 33 GB | 20 GB | NVIDIA L4 |
| Qwen 3 32B | 76 GB | 38 GB | 21 GB | NVIDIA L4 |
| Llama 3.3 70B | 164 GB | 82 GB | 43 GB | 2 × NVIDIA L4 |
| Mixtral 8×22B (MoE) | 326 GB | 163 GB | 83 GB | 4 × NVIDIA L4 |
| Qwen 3 235B-A22B (MoE) | 542 GB | 271 GB | 137 GB | 8 × NVIDIA L4 |
| DeepSeek V3 671B-A37B (MoE) | 1,544 GB | 772 GB | 386 GB | 8 × NVIDIA A100 PCIe |
| Llama 3.1 405B | 936 GB | 468 GB | 237 GB | 10 × NVIDIA L4 |
最后一列是我们产品目录中，能在 4-bit、8k 上下文下容纳该模型的最便宜节点，以及显存带宽所能达到的单流生成速率。吞吐量数字刻意取保守值，并参照已发表的测量数据进行了校准——请把它们当作下限，而不是承诺。
同时服务多个请求
这就是一台为演示而配置的服务器，变成一台撑不起产品的服务器的地方。权重只需付出一次；缓存则要按每个并发序列付出代价。
| 并发请求 | 4k 上下文 | 8k 上下文 | 32k 上下文 |
|---|---|---|---|
| 1 个请求 | 42 GB | 43 GB | 52 GB |
| 4 个请求 | 46 GB | 52 GB | 86 GB |
| 16 个请求 | 63 GB | 86 GB | 224 GB |
| 64 个请求 | 132 GB | 224 GB | 776 GB |
无论怎么做，Llama 3.3 70B 在 4-bit 下的权重都是 35 GB。表格中超出 35 GB 的部分都是缓存。这就是为什么“在我笔记本上跑得好好的”和“在生产环境里崩了”，说的其实是同一个模型、同一张显卡。
--max-model-len 限制在您实际使用的上下文长度：vLLM 会按声明的最大值预留缓存，声明 128k 而实际只用 8k，就会白白浪费 16 倍于所需的显存。
换算成哪台服务器
由以上内容得出的三条实用规则，按重要性排序。
- 只要可能，一张显卡总是优于多张。无需拆分，层与层之间无需同步，也不用考虑互联。如果您的模型在您的上下文长度下能放进一张显卡，就买那张显卡。
- 按您实际的上下文长度和实际并发数来估算，而不是按模型宣称的最大值。宣称的最大值是一种能力上限，不是要求。
- 必须拆分时，优先选择 NVLink。拆分到四张 PCIe 显卡上可行；拆分到四张 NVLink 显卡上同样可行，而且明显更快。下一篇指南正是讨论这种差异何时值得为之付费。
配置器会针对全部 41 种配置实时运行这一计算：选择一个模型、一种精度和一个上下文长度，它就会告诉您哪些节点能容纳它、哪些能在单张显卡上容纳它，以及每种配置每月的价格。它使用的就是本页上的这套公式，所以如果您不认同我们的算法，现在可以准确指出问题出在哪里。