[从零训练一个200B大语言模型] 2/25：到底需要多少张GPU？

选好GPU以后，供应商会问一个很实际的问题：你要多少台？

一千张，两千张，还是四千张？这些数字听上去都像一个大模型项目的规模，也都能很快变成一张很贵的报价单。我们要把这个问题往前追一步：机器要完成多少工作，我们希望多久拿到结果？

第一篇拿B200作为测算参照。这一篇就沿着它往下算，最后给这家假想公司定一套首轮训练配置，也把服务器的钱算出来。

200B的模型，为什么先安排4T训练量

200B表示2,000亿个参数。可以把参数理解为模型在学习过程中不断调整的数字。这篇采用稠密模型，也就是处理输入时，主要参数都会参与计算。我们先固定这一种结构，把第一套训练计划算清楚。

模型有多大确定了，还得决定给它多少材料。

训练系统会把文字切成一个个小片段，叫作token。它可能是一个字、一个词，也可能只是词的一部分。这里的1T token，就是一万亿个这样的片段。模型读过的token越多，需要做的计算通常也越多。

那200B究竟应该读多少？实践中有一个常见的起步比例：训练token数约为参数量的20倍。这个比例来自早期对计算投入怎样分配的研究：在一定训练算力下，模型规模和学习材料之间存在一个相对有效的搭配。

2026年5月的一项扩展规律研究回顾了这个约20倍的经验，也指出，把固定比例直接外推到不同规模和训练条件会有偏差。因此，我们把它用作第一轮设计的起点，后续再用自己的数据和实验调整。

这家假想公司的首轮目标，是训练出一个可以完整评估的200B基础模型，建立质量和工程基线。按照这个目标，先采用20倍起步比例，数据量就有了来由：

200B × 20 = 4,000B token = 4T token

也就是：2,000亿个参数，安排4万亿token的累计训练量。这里的20倍是一种经验配比，不能理解为每个参数各自阅读20个token。整个模型会共同处理这些材料。

采用4T以后，我们仍然可以继续训练。若模型在目标任务上的表现还有稳定提升，就评估增加到8T或更多是否值得。另一种项目目标是用更小的模型读更多材料，换取日后更低的使用成本。那会得到另一套模型大小和数据量组合。这一轮先围绕200B和首轮完整预训练来做决定。

数据团队还要把4T拆成具体来源：有多少独立内容，哪些需要重复，重复多少次。同一份材料读两遍，会记两遍训练量，但不一定带来两倍进步。Meta在2026年介绍Muse Spark时，也描述了通过一系列较小模型实验建立扩展规律的做法。我们的实验同样要回答：增加这些材料，究竟能带来多少提升。

至此，首轮工作量的两个输入都确定了：200B稠密模型，4T token。接下来才轮到机器。

一步一步算，2,048张卡要跑多少天

层：接收上一层的结果、再做一轮处理的计算单元。

训练步骤（step）：一轮学习过程，包括读入一批材料、计算预测与误差，再更新参数。

先把公式里的两个量认清楚。N是模型的参数量，这里是2,000亿；D是整个训练过程中累计处理的token数，这里是4万亿。我们要估算的是，模型处理完这些材料，一共需要做多少次浮点运算。

模型有很多层，每一层当然都要计算。这里的N已经把全模型所有层的参数加在一起。举一个简化例子：假设100层，每层20亿个参数，合计就是 100 × 20亿 = 2,000亿 = 200B。这只是帮助理解的示意，并不是本篇已经确定的模型架构，实际各层的参数量也可以不同。

后面会解释，普通稠密模型处理一个token时，主要训练计算量可以近似按每层参数量的6倍估算。把第1层、第2层一直加到最后一层，就是 6 × 第1层参数量 + 6 × 第2层参数量 + … = 6 × 全模型参数量 = 6N。所以每一层的工作都在账里；N已经包含层数，再乘一次100层就会重复计算。

一次浮点加法或者乘法，计作1 FLOP。比如把两个数相乘，再把结果加到已有的总数里，就计作2 FLOPs。GPU可以把乘和加合成一条指令执行，计算工作量时仍然记2次。一个训练步骤会包含大量这样的运算。

先看模型怎样算出一个结果。把输入分别乘上权重，再加在一起，是神经网络里最常见的计算之一。假设三个输入是2、4、6，对应权重是0.2、0.3、0.5，那么结果就是：

2 × 0.2 + 4 × 0.3 + 6 × 0.5 = 0.4 + 1.2 + 3 = 4.6

这里做了3次乘法、2次加法，一共5次浮点运算。把这个求和放大到成千上万项，乘法和加法的次数就几乎相同。因此估算大规模计算时，通常按每项“乘一次、加一次”，合计2次来计数，忽略每个求和起点少的一次加法。

权重：模型参数中的一类，决定输入对计算结果的影响有多大。

Transformer：这类语言模型常用的结构，每层先联系上下文，再加工得到的表示。层内结构会在架构篇展开。

注意力：模型根据当前内容，选择上下文中哪些信息值得参考的计算。

很多这样的加权求和排在一起，就是矩阵乘法。稠密Transformer的大量计算都发生在这些矩阵里。把主要权重矩阵的工作合起来，处理一个token的前向计算约为2N次。前向就是从输入一路算到预测结果；GPU实际会把许多token打包成矩阵一起处理。

训练还需要知道这次预测错在哪里、哪些参数应该怎样改。这个从结果往前追溯的过程，叫反向传播。对主要的线性计算，它需要再完成两类矩阵乘法。

一类计算权重的梯度，也就是每个权重变化一点，会怎样影响最后的误差；另一类计算输入的梯度，把误差信号继续传给前面的层。它们各自的主要计算量都与前向接近，约为2N。因此反向合计约4N。NVIDIA的线性层指南把这三个计算过程分别列了出来。

于是，处理一个token的主要训练计算量就是：

前向2N + 反向4N ≈ 6N

累计处理D个token，就得到 总计算量 ≈ 6ND。这是已有多年的基础估算方法，2022年Chinchilla论文的计算量附录同时给出了更细的分项计算和6ND近似。它估的是稠密Transformer中占主导的矩阵计算，不要求每个小运算都恰好遵循这个比例。

图中先把各层参数加成N，再把每个token的前向与反向计算相加，最后乘以累计token数D。100层、每层2B只是示意，各层可以大小不同；公式近似计算主要矩阵运算。

代入本篇的模型和数据量，先算一个token：

6 × 200,000,000,000 = 1,200,000,000,000次浮点运算

也就是平均每个token约1.2万亿次。再乘以累计4万亿token：

1,200,000,000,000 × 4,000,000,000,000 = 4.8 × 10²⁴ 次浮点运算

这就解释了最初的 6 × 200,000,000,000 × 4,000,000,000,000。右边用科学计数法缩短一长串零：1.2 × 10¹²乘以4 × 10¹²，前面的数相乘得到4.8，两个指数相加得到24，所以结果是4.8 × 10²⁴。

实际训练还会做更多工作。比如注意力需要计算token之间的关系，文本越长，这部分额外计算越大；为了省显存而重新计算的部分，也没有加进这个基础公式。接下来使用的“有效速度”，统一按6ND这份主要工作量除以实际训练时间来算。因此额外计算、通信和等待花掉的时间都会反映为较低的有效速度，不能再把同一份开销扣一次。

然后看每张卡能完成多少。联想2026年更新的B200规格给出，使用BF16这种16位计算方式时，稠密计算理论峰值为每秒2.25千万亿次，也就是2.25 PFLOP/s。

实际训练还要搬运数据、交换结果，有时会为了省显存重复计算。我们先按理论峰值约44%的有效模型计算速度规划，即每卡每秒1千万亿次，写作 1 × 10¹⁵，或者1 PFLOP/s。本计划先采用这个速度，B200运行目标200B模型的实测结果回来后，要替换这个值。

现在拿2,048张卡来算。为什么先看这个数量？我们希望首轮主训练大约一个月拿到结果，便于完成一轮评估后继续调整。两千张左右是需要检验的规模，2,048张又可以组成256台八卡服务器。它先是一个候选，算完才知道是否符合这个节奏。

第一步，把每张卡的速度加起来：

2,048 × 1 × 10¹⁵ = 2.048 × 10¹⁸ 次计算/秒

第二步，总工作量除以合计速度，得到需要运行的秒数：

(4.8 × 10²⁴) ÷ (2.048 × 10¹⁸) = 2,343,750秒

第三步，一天有 24 × 60 × 60 = 86,400秒，所以：

2,343,750 ÷ 86,400 = 27.1267天

这是连续推进训练所需的时间。保存进度、阶段性评估和故障恢复还会占用日历。我们再为这些停顿预留10%的主训练窗口，也就是预计90%的时间在推进训练：

27.1267 ÷ 0.90 = 30.1408天

所以，这套假设下的结果是约30.1天。实际排期先按31个日历日安排主训练窗口。采购、安装、数据准备、前期实验和后训练，需要在项目日程中另外安排。

这笔时间账里，训练步骤内部的通信和等待已经包含在每卡1 PFLOP/s里；额外的10%只安排步骤之外的停顿。如果我们直接测了一整周实际推进多少token，就可以用整周平均速度计算，避免把同一段等待扣两遍。

BF16：用16位存一个数的格式，训练用它来节省存储和计算资源。

FLOP：一次浮点运算，用来计量计算工作量。

FLOP/s：每秒完成的浮点运算次数，用来计量计算速度。

PFLOP/s：每秒10¹⁵次浮点运算，也就是一千万亿次。

理论峰值：硬件规格中列出的最高计算速度。

有效速度：用模型的主要计算工作量除以实际训练时间，得到的平均计算速度。

一千张、两千张、四千张，差别在哪里

刚才的演算只换一个数字，就能得到其他配置。每张卡速度相同，卡数减半，合计速度就减半，完成同一份工作的时间便翻倍。2,048张需要约30.1天，1,024张就是约60.3天，再减到512张便是约120.6天。

这张表统一使用200B稠密模型、4T token、每卡有效速度1 PFLOP/s，以及90%的训练时间占比。表格展示的是这些规划条件下的计算结果。

对这家公司来说，512张意味着一次主训练要等四个月，反馈周期太长。1,024张能把它缩到两个月。2,048张进一步缩到约一个月，符合我们为首轮计划选择的节奏。增加到4,096张，理论上又能省半个月，但需要同时拿出两倍的服务器和配套资源。因此，这一轮先选2,048张。

现实里的扩容还要看机器是否配合得好。卡变多以后，交换数据和等待的负担可能增加，每张卡的有效速度就会下降。表里“多一倍卡、时间减半”的前提，需要在不同规模上实测。

这个速度对结论有多大影响，也可以直接算。仍然是2,048张卡，如果每卡只有0.6 PFLOP/s，工期就是 30.1408 ÷ 0.6 ≈ 50.2天；如果达到1.4，则为 30.1408 ÷ 1.4 ≈ 21.5天。把4T数据增加到8T，工作量翻倍，在原来的速度下就要约60.3天。

所以工程团队的验证任务很明确：先跑通软件，再用目标200B模型、预定文本长度和训练设置测量速度，同时检查显存够不够、增加机器后速度怎样变化、训练能否顺利保存和恢复。这样拿回来的测量值，才能告诉我们31天的计划是否站得住。

集群：一起工作的多台服务器。

主训练窗口：留给这次大规模学习的日历时间，包含训练及保存、评估和恢复的停顿。采购、安装和数据准备另排时间。

这轮先准备2,048张，服务器约1.01亿至1.09亿美元

卡数定到2,048张，采购单位就是 2,048 ÷ 8 = 256台 八卡B200服务器。

这里采用Exxact的两套公开整机配置。第一套使用AMD处理器、1,536GB主存，八张B200包含在整机里，页面价格为393,607.50美元。第二套使用Intel处理器、2,048GB主存，页面价格为423,857.50美元。两套机器的配套配置不同，我们用它们给服务器采购建立一个当前价格区间。

按第一套配置计算：

256 × $393,607.50 = $100,763,520

按第二套配置计算：

256 × $423,857.50 = $108,507,520

因此，这一轮的服务器采购小计约为1.01亿至1.09亿美元。它买的是256台含GPU的服务器，不需要再把2,048张GPU的价格加一次。

公开配置中的高速网卡尚未选配，集群交换机、线缆、共享存储、数据中心、电费和团队也要另外计算。税费、运输、安装和批量交付条件需要进入正式报价。备用机器和并行实验资源同样单列。这些项目会继续增加资金需求，所以这里给出的金额是服务器采购小计。

我们的首轮规划就这样落下来：2,048张B200，组成256台八卡服务器；按200B稠密模型、4T token、每卡有效速度1 PFLOP/s和90%训练时间占比，主训练约30.1天，排31天；服务器先准备约1.01亿至1.09亿美元。

这套配置给团队一个可以执行的目标。下一步的性能验证和正式报价，都围绕这2,048张卡展开。只要实测速度、数据方案或交付条件发生变化，就重新代入上面的计算，让卡数、工期和资金一起更新。

整机主存：服务器CPU使用的内存。报价中的1,536GB或2,048GB指的就是它。

显存：GPU自己的内存。这里的显存已经包含在八张B200的配置里。