LLM的GPU内存计算 (2026版)

# 大型语言模型的GPU显存计算（2026版） 来源：https://theahmadosman.substack.com/p/gpu-memory-math-for-llms-2026-edition [](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Ff6c23330-8fa6-4aa5-90d4-49bd4e6ff8c9_3264x1312.png) 如果你正在本地运行模型，一旦考虑到权重最初的训练和量化方式，“模型→显存”这种思维就会崩溃。 有一种更好的思考方式： > **显存（GB）≈ 参数量（十亿） x （有效每权重比特数 ÷ 8）** 仅此而已。 这个公式能解释所有情况，包括： - FP16 / BF16 - FP8 / INT8 - GPTQ / AWQ / NF4 - GGUF 的各种变体 - 基本你用的所有格式 核心直觉如下： - FP16 / BF16 → 16 位 → 约 2 GB 每 10 亿参数 - FP8 / INT8 → 8 位 → 约 1 GB 每 10 亿参数 - 4 位量化 → 约 4 位 → 约 0.5 GB 每 10 亿参数 GGUF 格式介于之间，具体取决于量化方案： - Q6\_K → 约 0.82 GB 每 10 亿参数 - Q5\_K → 约 0.69 GB 每 10 亿参数 - Q4\_K → 约 0.56 GB 每 10 亿参数 - Q3\_K → 约 0.43 GB 每 10 亿参数 - Q2\_K → 约 0.33 GB 每 10 亿参数 超激进量化甚至可以更低，但有代价。 如果其他什么都不记得，记住这一点： - FP16 = 2 倍模型大小 - FP8 = 1 倍模型大小 - 4 位 = 0.5 倍模型大小 其他都是这个主题的变体。 在你考虑 **权重** 之前，先明白这一点：模型本身只是你 **显存账单** 的一部分。真正的大头是它周围的一切。 **KV 缓存** 随上下文长度增长，在 32K、128K 或更高时，它会悄然吃掉你的内存。激活值因运行环境和优化程度而异，但在某些执行路径下可能猛增。批处理与并发会快速倍增内存使用量，尤其在 agent 风格的工作负载中。 框架开销还会根据你使用的工具（Transformers、vLLM、TensorRT-LLM 或 llama.cpp）额外加税。还有 CUDA Graphs，它用额外保留的显存换取更好的延迟和吞吐稳定性。底线是：如果你只为权重预算，那你已经内存不足了。 让我们把它翻译成真实的模型大小。 7B 模型： - FP16 → 约 14 GB - FP8 → 约 7 GB - 4 位 → 约 3.5–4 GB 13B 模型： - FP16 → 约 26 GB - FP8 → 约 13 GB - 4 位 → 约 6–7 GB 70B 模型： - FP16 → 约 140 GB - FP8 → 约 70 GB - 4 位 → 约 35–40 GB 405B 模型： - FP16 → 约 810 GB - FP8 → 约 405 GB - 4 位 → 约 200+ GB 现在你明白为什么人们要么： - 激进量化 - 跨 GPU 分片（如张量并行） - 或者直接放弃，说“用云吧” 下面是将这些转化为人们实际拥有的 GPU 的实用版。 8 GB 显存： - 约 3B 在 FP16 - 约 6–7B 在 FP8 - 约 12–13B 在 4 位 12 GB 显存： - 约 5B FP16 - 约 10B FP8 - 约 18–20B 4 位 16 GB 显存： - 约 7B FP16 - 约 13B FP8 - 约 25B 4 位 24 GB 显存： - 约 10–12B FP16 - 约 20B FP8 - 约 35–40B 4 位 48 GB 显存： - 约 20–24B FP16 - 约 40B FP8 - 约 70–80B 4 位 80 GB 显存： - 约 35–40B FP16 - 约 70B FP8 - 约 140B 级 4 位 这是“实际能装下什么”的权重版本。 正如我们之前所说，即使数学上说能装下，你还是可能内存不足。 因为权重只是故事的一部分。 你还需要内存给： - KV 缓存（长上下文时会爆炸） - 激活值（取决于运行环境） - 批处理 / 并发 - 框架开销 经验法则： 额外增加 10–30% 显存用于安全运行。 如果你在做： - 长上下文（32K、128K 等） - 高并发 - agent 工作流 ……你将需要更多。 混合专家模型会让人们困惑。 例如： - “8x7B”听起来像 56B - 但每个 token 只运行一部分专家 所以计算成本 ≠ 内存成本。 关键点： - 总参数量 → 影响内存占用 - 活跃参数量 → 影响速度 取决于模型的加载方式： - 你可能仍然需要为所有专家分配内存 - 或者你可以跨 GPU 分片它们 如果你把 MoE 当成密集模型处理，那么你不是高估就是低估得很严重。 GGUF 常被视为作弊码。 但并不是。 它是一个容器 + 量化策略，针对以下场景优化： - llama.cpp 风格的推理 - CPU + GPU 混合设置 - 超高效内存使用 但是： 那些内存数字只在该运行时中才适用。 一旦你换到其他框架： - 权重可能会被反量化 - 内存使用可能急剧增加 所以“它能在 6 GB 中运行”并非普遍真理。它是特定运行时的真理。 没有你需要记住的巨大兼容性矩阵。 只有这个： 显存 ≈ B x (bits ÷ 8) 然后根据以下项调整： - 运行时开销 - KV 缓存 - 并发 仅此而已。 一旦你内化了这个，你就不再猜测。 你开始设计系统。 更重要的是，你不再问：“我能运行这个吗？” 你开始问：“我想怎么运行这个？” 这时候事情就变得有趣了。 下次见。 #### 关于本文的讨论 ### 准备了解更多？