如何估算训练一个大语言模型（LLM）所需的 GPU 数量

by Armin Rahimi

本文转自：DeepHub IMBA

---

AI 领域有个问题听起来简单，却难住了不少人：

需要多少 GPU，训练要花多长时间？

很多人觉得回答这个问题得靠复杂的基础设施建模，或者昂贵的集群仿真软件。其实没那么负载，只用一个基于 scaling law（缩放定律）研究的公式，几分钟就能算出一个靠谱的估算值。

虽然结果不会完全的精确，但肯定可以落在一个数量级之内。这种计算方式在早期规划阶段基本上够用了。

---

GPU 规划归结为两个数字：

（以 FLOPs 衡量，即浮点运算次数）

（FLOP/s）

知道一项工作有多大，也知道一个工人的速度，就能算出需要多少工人才能按时完成；GPU 是同样的道理：

GPUs = C / (GPU throughput × T)

其中：

= 训练总计算量（FLOPs）

= 单块 GPU 每秒的 FLOPs

= 目标训练时长（秒）

所有 LLM 训练的粗略估算，都建立在这一个公式上。后面的内容就是把每一部分拆开讲清楚。

训练是逐个 token 进行的，所以第一个问题是：单个 token 的成本有多高？

对于一个参数量为

的标准 Transformer：

约 2N FLOPs（模型读取 token 并做出预测）

约 4N FLOPs（模型从误差中学习）

加起来：

≈ 6N FLOPs per token

前向传播中，N 个参数每一个大约都会被用到一次，一次乘加运算算作 2 次运算，这就是 2N 的由来；反向传播要同时计算激活值和参数的更新，成本大约是前向传播的两倍，这就是 4N 的由来。2N + 4N =

，整个计算方法就是这样。

这个近似在实践中用得很广并且也与 Kaplan 等人（2020）、Hoffmann 等人（2022）的 scaling law 研究结果吻合。

一个 token 成本是 6N FLOPs，那么在

个 token 上训练的成本就是：

C ≈ 6 × N × D

其中：

= 模型参数量

= 训练 token 数量

= 整个训练过程所需的总 FLOPs

一个稠密 Transformer 的计算模型更大、数据更多，计算量都线性增加。

不要用规格表上营销宣传的"峰值"数字。真实训练永远达不到峰值，实际能拿到的往往只是峰值的一部分，通常是 30%–60%，原因在于内存限制、GPU 之间的通信开销，以及软件层面的损耗。

所以想要更贴近实际的持续吞吐量数字，OpenAI 关于真实训练效率的分析（Amodei & Hernandez，2018）是个经典参考：

K80 → 2.8 TFLOPS

K40 → 3.7 TFLOPS

M40 → 6.0 TFLOPS

P100 → 9.5 TFLOPS

（1 TFLOPS = 10¹² FLOP/s。）A100、H100 这类现代显卡，代入各自的持续吞吐量数字即可，方法不变。

这里有必要专门解释一下这个 P100 数字：9.5 TFLOPS，本质上引用的是 NVIDIA 规格表里 P100 的峰值 FP32 指标（PCIe 版本是 9.3 TFLOPS，SXM2 版本约 10.6）。但放到真实训练环境里，几乎不可能长期跑到这个峰值，实际能够稳定拿到的持续吞吐量，通常只有峰值的 30%–60%。所以，这里的例子更适合被理解为一种偏乐观、用于判断数量级的估算；到了实际落地时，往往需要更长时间，或者更多 GPU。这也正是后文专门提醒 MFU 问题的原因。

单块 GPU 上的耗时：

T_single = C / GPU throughput

针对多块 GPU 的核心公式，再写一遍：

GPUs = C / (GPU throughput × T)

规划一个从零训练的小型 LLM。

Model 1.5B parameters N = 1.5 × 10⁹

Dataset 100B tokens D = 10¹¹

Hardware NVIDIA P100 9.5 TFLOPS = 9.5 × 10¹² FLOP/s

总计算量（第二步）：

C = 6 × (1.5 × 10⁹) × 10¹¹ = 9 × 10²⁰ FLOPs

单块 GPU 需要多久：

T = (9 × 10²⁰) / (9.5 × 10¹²) ≈ 9.5 × 10⁷ seconds ≈ 1,097 days

用一块 P100 算下来就是大约三年。。。显然不现实，只能并行。

要在 30 天内完成，需要多少块 GPU？先把 30 天换算成秒：

T = 30 × 24 × 3600 = 2.59 × 10⁶ seconds

单 GPU 所需时间除以愿意等待的时间：

GPUs = (9.5 × 10⁷) / (2.59 × 10⁶) ≈ 37

37 块 P100，能把约 3 年的训练缩短到大约一个月。

这就是整个方法：输入三个数字，输出一份硬件方案。

这是个好用的规划工具，但终究是个简化模型，有三点要记住。

6N 法则是近似的。它抓住了主要的矩阵乘法运算，但忽略了 attention softmax、LayerNorm、embedding 等开销。对大多数模型来说，这些只占很小的比例，但不是零。

现实里的系统，几乎不可能把效率拉到 100%。任务一旦分到多块 GPU 上，通信开销（all-reduce）、内存瓶颈，以及软件栈本身的损耗，都会一点点把性能吃掉。实际最终能跑到峰值的多少，用

来衡量，通常落在 30%–60% 这个区间。更实用的估算方法是：把最终算出来的 GPU 数量，再除以预期的 MFU。比如假设利用率是 40%，那么所需规模大约就是 37 / 0.4 ≈ 93 块 GPU。

GPU 吞吐量也不是固定不变的常数。它会随精度（FP16 / BF16）、批量大小（batch size）、模型架构，以及软件栈的调优程度而变化。TFLOPS 数字，始终只是一个估算值。

不必手动完成每一步计算，有几个免费工具可以帮着算。大致分三类：计算量估算、显存检查、成本预算。

计算量估算（6ND 运算）：

一个在线网页应用，估算训练计算量，以及模型规模与数据集规模之间的 compute-optimal（计算最优）平衡点，思路和本文的 6ND 很接近。

输入模型规模、数据集规模、想用的 GPU 型号，能得到总计算量、实际耗时、成本，用的正是同一条 6 × params × tokens 法则，并应用一个现实的 MFU。

显存 / "装不装得下"检查：

输入模型名称、量化格式、上下文长度，能知道需要多少显存，以及能不能放进你的 GPU。

不是一个网页计算器而是一个训练库，内置了针对模型规模、批量大小、分布式训练的显存估算工具，适合从规划阶段转入实际实现之后使用。

C ≈ 6 × N × D

从这一个公式出发，就能估算训练成本、训练时间、所需的 GPU 数量，误差都在一个数量级以内。做系统方案初步设计时，这通常已经够用；等需要把数字算得更精确，再去用上面那些工具。

Kaplan et al. (2020). Scaling Laws for Neural Language Models

Hoffmann et al. (2022). Training Compute-Optimal Large Language Models (Chinchilla)

Amodei, D. & Hernandez, D. (2018). AI and Compute