搭建100000 个 H100 的集群，需要哪些芯片？

5月前

👆如果您希望可以时常见面，欢迎标星🌟收藏哦~

来源：内容由半导体行业观察（ID：icbank）编译自semianalysis，谢谢。

有一部分人认为，自 GPT-4 发布以来，AI 能力一直停滞不前。这通常是正确的，但这只是因为没有人能够大幅增加专用于单个模型的计算量。已发布的每个模型都大致达到 GPT-4 级别（训练计算约 2e25 FLOP）。这是因为专用于这些模型的训练计算也大致处于同一水平。以 Google 的 Gemini Ultra、Nvidia Nemotron 340B 和 Meta LLAMA 3 405B 为例，与 GPT-4 相比，专用的 FLOPS 数量级相似甚至更高，但使用了较差的架构，导致这些模型无法解锁新功能。

尽管 OpenAI 获得了越来越多的计算资源，但他们主要致力于推出更小、训练过度、更便宜的推理模型，例如 GPT-4 Turbo 和 GPT-4o。OpenAI 承认他们最近才刚刚开始训练下一层模型。

人工智能的下一步显然是使用大量视频、图像、音频和文本来训练一个具有数万亿参数的多模态转换器。目前还没有人完成过这项任务，但人们正在争先恐后地开展活动。

多个大型人工智能实验室（包括但不限于 OpenAI/Microsoft、xAI 和 Meta）正在竞相构建拥有超过 100,000 个 GPU 的 GPU 集群。这些单独的训练集群仅服务器资本支出就超过 40 亿美元，但它们也受到数据中心容量和功率不足的严重限制，因为 GPU 通常需要共置才能实现高速芯片到芯片联网。一个 100,000 个 GPU 集群将需要 >150MW 的数据中心容量，一年内消耗 1.59 太瓦时，按 0.078 美元/千瓦时的标准费率计算，成本为 1.239 亿美元。

今天，我们将深入研究大型 AI 训练集群及其周围的基础设施。构建这些集群比仅仅投入资金要复杂得多。由于各种组件（尤其是网络）的故障率很高，因此实现高利用率更加困难。我们还将介绍这些系统的电源挑战、可靠性、检查点、网络拓扑选项、并行方案、机架布局和总物料清单。在之前，我们介绍了 Nvidia 的 InfiniBand 问题，导致一些公司选择 Spectrum-X 以太网而不是 InfiniBand。我们还将介绍 Spectrum-X 的主要缺陷，超大规模企业选择 Broadcom 的 Tomahawk 5。

为了说明 100,000 GPU 集群可以提供多少计算量，OpenAI 为 GPT-4 训练的 BF16 FLOPS 约为 2.15e25 FLOP（2150 万 ExaFLOP），在约 20,000 个 A100 上训练了 90 到 100 天。该集群的峰值吞吐量仅为 6.28 BF16 ExaFLOP/秒。在 100k H100 集群上，这个数字将飙升至 198/99 FP8/FP16 ExaFLOP/秒。与 20k A100 集群相比，峰值理论 AI 训练 FLOP 增加了 31.5 倍。

在 H100 上，AI 实验室在万亿参数训练运行中实现了高达 35% 的 FP8 模型 FLOP 利用率 (MFU)，40% 的 FP16 MFU。总结一下，MFU 是在考虑开销和各种瓶颈（例如功率限制、通信不稳定、重新计算、落后者和低效内核）后，衡量峰值潜在 FLOPS 的有效吞吐量和利用率的指标。一个 100,000 个 H100 集群使用 FP8 训练 GPT-4 只需四天时间。在 100k H100 集群训练运行 100 天后，您可以实现约 6e26（6 亿 ExaFLOP）的有效 FP8 模型 FLOP。请注意，硬件可靠性差会显著降低 MFU。

电力挑战

100k H100 集群所需的关键 IT 功率约为 150MW。虽然 GPU 本身只有 700W，但在每个 H100 服务器中，CPU、网络接口卡 (NIC)、电源单元 (PSU) 为每个 GPU 额外占用约 575W。除了 H100 服务器之外，AI 集群还需要存储服务器、网络交换机、CPU 节点、光收发器和许多其他项目的集合，这些项目加起来占 IT 功率的另外约 10%。考虑到约 150MW 的功率，最大的国家实验室超级计算 El Capitan仅需要 30MW 的关键 IT 功率。与工业相比，政府超级计算机相形见绌。

一个主要的电力挑战是，目前没有一座数据中心建筑能够容纳新的约 150MW 部署。当人们提到 10 万个 GPU 集群时，他们通常指的是一个校园，而不是建筑。电力需求如此迫切，由于没有其他选择，X.AI 甚至将田纳西州孟菲斯的一家旧工厂改造成数据中心。

这些集群通过光收发器联网，而光收发器的价格与覆盖范围成正比。范围更广的“单模”DR 和 FR 收发器可以可靠地传输信号约 500 米到约 2 公里，但成本是“多模”SR 和 AOC 收发器的 2.5 倍，后者仅支持最多约 50 米的覆盖范围。此外，校园级“相干”800G 收发器也存在，覆盖范围超过 2 公里，但价格要高出 10 倍以上。

小型 H100 集群通常仅通过一层或两层交换机，以 400G 的速度将每个 GPU 连接到其他每个 GPU，仅使用多模收发器。对于大型 GPU 集群，必须添加更多交换层，并且光学器件变得非常昂贵。此类集群的网络拓扑将根据首选供应商、当前和未来的工作负载以及资本支出而有很大差异。

每个设计通常包含一个或多个计算单元，这些单元通过更便宜的铜缆或多模收发器连接。然后，它们将使用更长距离的收发器在“岛屿”之间进行互连。在单一地点交付 155MW 是一项挑战，但我们正在跟踪超过 15 个 Microsoft、Meta、Google、Amazon、Bytedance、X.AI、Oracle 等数据中心的建设，这些数据中心将为 AI 服务器和网络提供如此大的空间。

不同的客户会根据数据传输基础设施、成本、可维护性、功率、当前和未来的工作负载等多种因素选择不同的网络拓扑。因此，一些客户选择基于 Broadcom Tomahawk 5 的交换机，其他客户则坚持使用 Infiniband ，而其他客户则选择 NVIDIA Spectrum-X 。我们将在下面深入探讨原因。

并行性复习

为了理解网络设计、拓扑、可靠性问题和检查点策略，我们首先快速回顾一下万亿参数训练中使用的 3 种不同类型的并行性：数据并行性（Data Parallelism）、张量并行性（Tensor Parallelism）和管道并行性（Pipeline Parallelism）。我们在这里对并行性进行了全面的解释。

数据并行是最简单的并行形式，其中每个 GPU 都保存模型权重的完整副本，每个 GPU（等级）接收不同的数据子集。这种类型的并行具有最低级别的通信，因为每个 GPU 之间只需要对梯度进行求和（全部减少）。不幸的是，只有当每个 GPU 都有足够的内存来存储整个模型权重、激活、优化器状态时，数据并行才有效。对于像 GPT-4 这样的 1.8 万亿参数模型，仅模型权重和优化器状态就需要多达 10.8 TB 的内存进行训练。

为了克服这些内存限制，我们使用了张量并行。在张量并行中，每个层的工作和模型权重通常分布在隐藏维度上的多个 GPU 上。中间工作通过全缩减在设备之间多次交换，涉及自注意力、前馈网络和每个层的层规范化。这需要高带宽，尤其是需要非常低的延迟。实际上，域中的每个 GPU 都与其他每个 GPU 在每一层上协同工作，就好像它们是一个巨大的 GPU 一样。张量并行将每个 GPU 使用的总内存减少了张量并行等级的数量。例如，目前在 NVLink 上使用 8 个张量并行等级是很常见的，因此这将使每个 GPU 使用的内存减少 8。

另一种克服每个 GPU 没有足够的内存来容纳模型权重和优化器状态的挑战的技术是使用流水线并行。使用流水线并行，每个 GPU 仅具有层的一个子集，并且仅对该层进行计算并将输出传递给下一个 GPU。此技术通过流水线并行等级数减少了所需的内存量。流水线并行对通信量的要求很高，但不像张量并行那么高。

为了最大化模型 FLOP 利用率 (MFU)，公司通常会将三种并行形式结合起来形成 3D 并行。然后在 H100 服务器内部对 GPU 应用张量并行，然后在同一个 Island 内的节点之间使用管道并行。由于数据并行的通信量最低，而 Island 之间的联网速度较慢，因此 Island 之间使用数据并行。

FSDP 之类的整体技术在小型 GPU 世界规模下对于非常大的模型很常见，但它不起作用。它实际上也与 FSDP 不兼容。

网络设计注意事项

网络设计时考虑了并行方案。如果每个 GPU 都以最大带宽连接到胖树拓扑中的每个其他 GPU，则成本将非常高昂，因为需要 4 层交换。由于每增加一层网络都需要中间的光学元件，因此光学元件的成本将飙升。

因此，没有人会为大型 GPU 集群部署全胖树架构。相反，他们依靠制造具有全胖树（full fat tree）架构的计算岛，同时这些岛之间的带宽较少。有多种方法可以做到这一点，但大多数公司都选择“超额认购”顶层网络。例如，请参阅 Meta 的上一代 GPU 集群架构，最高可达 32,000。总共有 8 个岛，它们之间具有全胖带宽，然后顶部还有另一层交换层，其超额认购率为 7:1。与岛内的网络相比，岛之间的网络速度要慢 7 倍。

GPU 部署有多个网络、前端、后端和扩展 (NVLink)。在某些情况下，您将在每个网络上运行不同的并行方案。NVLink 网络可能是唯一一个速度足够快以满足张量并行带宽要求的网络。您的后端通常可以轻松处理大多数其他类型的并行，但如果存在超额认购，则通常只能使用数据并行。

此外，有些人甚至没有在顶层拥有超额带宽的孤岛。相反，他们利用从后端网络转移到前端网络的举措。

混合 InfiniBand 和前端以太网结构

一家大型公司使用前端以太网在多个 InfiniBand 岛上进行训练。这是因为前端网络的成本要低得多，并且可以利用建筑物和区域路由之间的现有数据中心园区网络。

不幸的是，由于 MoE 等稀疏技术的存在，模型大小增长得更快，前端网络需要处理的通信量也会增加。必须仔细优化这种权衡，否则您最终会拥有两个成本相同的网络，因为前端网络带宽最终会增长得如此之大，以至于可能与后端网络带宽相匹配。

值得注意的是，谷歌专门使用前端网络进行多 TPU pod 训练运行。他们的“计算结构”称为 ICI，最多只能扩展到 8960 个芯片，并采用昂贵的 800G 光学器件和光路交换机连接每个 64 个 TPU 水冷机架。因此，谷歌必须通过使 TPU 前端网络比大多数 GPU 前端网络更强大来弥补这一不足。

当在训练期间使用前端网络时，必须执行岛之间的网络拓扑感知全局全归约。首先，每个 pod 或岛将在 pod InfiniBand 或 ICI 网络内执行本地归约散射，这将使每个 GPU/TPU 拥有梯度子部分的总和。接下来，将使用前端以太网网络执行每个主机等级之间的跨 pod 全归约，然后最终每个 pod 将执行 pod 级全收集。

前端网络还负责加载数据。随着我们转向多模态图像和视频训练数据，前端网络需求将呈指数级增长。在这种情况下，前端网络带宽将在加载大型视频文件和执行所有归约之间争夺。此外，如果存储网络流量不规则，您的落后者问题就会增加，这会导致您的整个全归约速度变慢并且无法进行预测建模。

替代方案是使用 4 层 InfiniBand 网络，超额订阅率为 7:1，包含 4 个 pod，每个 pod 有 24,576 个 H100，并采用无阻塞 3 层系统。与使用前端网络相比，这为未来的带宽增加提供了更大的灵活性，因为从 A 栋楼的一个交换机向 B 栋楼的另一个交换机添加更多光纤收发器要容易得多，而对集群的每个机箱进行完整的前端网络 NIC 升级以将其从 100G 升级到 200G 等则要容易得多。

这样可以创建更稳定的网络模式，因为您的前端网络可以专注于加载数据和检查点，而您的后端网络可以专注于 GPU 之间的通信。这也有助于解决落后者问题。但不幸的是，由于需要所有额外的交换机和收发器，4 层 Infiniband 网络非常昂贵。

轨道优化与机架中部优化

为了提高可维护性并增加铜网络（<3 米）和多模网络（<50 米）的使用，一些客户选择放弃 NVIDIA 推荐的导轨优化设计，而是选择采用机架中间设计。

轨道优化是一种让每台 H100 服务器连接到 8 个不同的叶交换机（而不是全部连接到同一个机架交换机中间）的技术，这样每个 GPU 只需 1 个交换机跳转即可与更远的 GPU 通信。这可以提高现实世界中所有集体的性能。所有集体通信在混合专家 (MoE) 专家并行性中被大量使用。

导轨优化设计的缺点是，您必须连接到距离不同的不同叶交换机，而不是连接到靠近服务器中所有 8 个 GPU 的机架中间交换机。当交换机可以放在同一个机架中时，可以使用无源直连电缆 (DAC) 和有源电缆 (AEC)，但在导轨优化设计中，交换机不一定位于同一个机架中，必须使用光纤。此外，叶到主干的距离可能大于 50 米，因此必须使用单模光纤收发器。

通过使用非轨道优化设计，您可以用廉价的直接连接铜线替换连接 GPU 和叶交换机的 98,304 个光收发器，从而使您的 GPU 结构中有 25-33% 为铜线。从下面的机架图可以看出，现在叶交换机位于机架中间，允许每个 GPU 使用 DAC 铜线，而不是每个 GPU 到叶交换机的连接都向上连接到电缆托盘，然后横向穿过 9 个机架连接到专用的轨道优化叶交换机机架。

与光纤相比，DAC 铜缆运行温度更低、耗电更少且更便宜。由于 DAC 电缆运行温度更低、耗电更少且更可靠，因此可以减少抖动（网络链路间歇性中断）和故障，这是所有使用光纤的高速互连的主要问题。使用 DAC 铜缆时，Quantum-2 IB 主干交换机的功耗为 747 瓦。使用多模光纤收发器时，功耗会增加到 1,500 瓦。

此外，对于数据中心技术人员来说，轨道优化设计的初始布线极其耗时，因为每条链路的末端距离可达 50 米，而且不在同一机架上。相比之下，机架中间设计中，您的叶交换机与连接到叶交换机的所有 GPU 位于同一机架中。在机架中间设计中，您甚至可以在集成工厂测试计算节点到叶交换机的链路，因为它们都在同一个机架内。

可靠性和恢复

由于当前前沿训练技术的同步特性，可靠性是这些巨型集群最重要的运营问题之一。最常见的可靠性问题是 GPU HBM ECC 错误、GPU 驱动程序卡住、光收发器故障、NIC 过热等。节点不断出现故障或出现错误。

为了将故障恢复的平均时间保持在较低水平并继续进行训练，数据中心必须在现场保留热备用节点和冷备用组件。发生故障时，最好不要停止整个训练运行，而是换上已经运行的备用节点并继续训练。这些服务器的大部分停机时间只是对节点进行电源循环/重新启动，并解决出现的任何问题。

不过，简单的重启并不能解决所有问题，在许多情况下，它需要数据中心技术人员进行物理诊断和更换设备。在最好的情况下，数据中心技术人员需要几个小时才能修复损坏的 GPU 服务器，但在许多情况下，可能需要几天时间才能将损坏的节点重新投入训练运行。损坏的节点和备用热节点是 GPU，它们没有积极地为模型做出贡献，尽管理论上可以提供 FLOPS。

在训练模型时，需要频繁将模型检查点设置到 CPU 内存或 NAND SSD 上，以防发生 HBM ECC 等错误。发生错误时，您必须从较慢的内存层重新加载模型和优化器的权重并重新开始训练。可以使用容错训练技术（例如Oobleck ）来提供用户级应用程序驱动方法来处理 GPU 和网络故障。

不幸的是，频繁的检查点和容错训练技术会损害系统的整体 MFU。集群需要不断暂停以将其当前权重保存到持久内存或 CPU 内存中。此外，当您从检查点重新加载时，通常每 100 次迭代只保存一次。这意味着您最多只能损失 99 步有用的工作。在 100k 集群上，如果每次迭代花费 2 秒，则第 99 次迭代失败会让您损失最多 229 个 GPU 天的工作量。

故障恢复的另一种方法是让备用节点通过后端结构从其他 GPU 进行 RDMA 复制。由于后端 GPU 结构大约为 400Gbps，并且每个 GPU 有 80GB HBM 内存，因此复制权重大约需要约 1.6 秒。使用这种方法，您最多只会损失 1 步（因为更多 GPU HBM 将拥有最新的权重副本），因此只需要 2.3 GPU 天的计算量 + 另外 1.85 GPU 天的 RDMA 从其他 GPU HBM 内存复制权重。

大多数领先的人工智能实验室都已实施了这一技术，但许多较小的公司仍然坚持使用繁重、缓慢、低效的技术，即对所有故障从检查点重新启动，因为这种技术过于简单。通过内存重建实现故障恢复可以为大规模训练运行的 MFU 增加几个百分点。

最常见的问题之一是 Infiniband/RoCE 链路故障。即使每个 NIC 到叶交换机链路的平均故障时间为 5 年，由于收发器数量众多，在全新、正常运行的集群上，第一次作业故障只需 26.28 分钟。如果不通过内存重建进行故障恢复，由于光学故障，在 100,000 个 GPU 集群中重新启动训练运行所花费的时间将比推进模型所花费的时间更多。

由于每个 GPU 都直接连接到 ConnectX-7 NIC（通过 PCIe 交换机），因此在网络架构级别没有容错能力，因此必须在用户训练代码中处理故障，这直接增加了代码库的复杂性。这是 NVIDIA 和 AMD 当前 GPU 网络结构面临的主要挑战之一，即使一个 NIC 发生故障，该 GPU 也没有其他路径与其他 GPU 通信。由于当前 LLM 在节点内使用张量并行的方式，即使一个 NIC、一个收发器或一个 GPU 发生故障，整个服务器也会瘫痪。

我们正在开展大量工作，以使网络可重新配置，并减少节点的脆弱性。这项工作至关重要，因为现状意味着，只要有 1 个 GPU 故障或 1 个光学故障，整个 GB200 NVL72 就会瘫痪。价值数百万美元的 72 GPU 机架瘫痪比价值数十万美元的 8 GPU 服务器灾难性更大。

Nvidia 已经注意到了这个重大问题，并增加了一个专门的引擎来提高可靠性、可用性和可服务性 (RAS)。我们认为 RAS 引擎会分析芯片级数据，例如温度、恢复的 ECC 重试次数、时钟速度、电压，以预测芯片何时可能发生故障并提醒数据中心技术人员。这将使他们能够进行主动维护，例如使用更高的风扇速度配置文件来保持可靠性，在稍后的维护窗口中让服务器停止服务以进行进一步的物理检查。此外，在开始训练工作之前，每个芯片的 RAS 引擎将执行全面的自检，例如运行已知结果的矩阵乘法来检测静默数据损坏 (SDC)。

Cedar-7

一些客户（例如微软/Openai）正在进行的另一项成本优化是在每台服务器上使用 Cedar Fever-7 网络模块，而不是使用 8 个 PCIe 外形尺寸的 ConnectX-7 网卡。使用 Cedar Fever 模块的主要好处之一是，它只允许使用 4 个 OSFP 笼（cages），而不是 8 个 OSFP 笼，从而允许在计算节点端（而不仅仅是交换机端）使用双端口 2x400G 收发器。这将连接到叶交换机的收发器数量从每个 H100 节点 8 个收发器减少到 4 个收发器。将 GPU 连接到叶交换机的计算节点端收发器总数从 98,304 减少到 49,152。

由于 GPU 到叶交换机的链路被缩短了一半，这也有助于缩短首次作业故障的估计时间。我们估计，每条双端口 2x400G 链路的平均故障时间为 4 年（而单端口 400G 链路的平均故障时间为 5 年），这将使首次作业故障的估计时间缩短至 42.05 分钟，这比没有 Cedar-7 模块的 26.28 分钟要好得多。

Spectrum-X NVIDIA

目前正在部署一个使用 NVIDIA Spectrum-X 以太网的 100k H100 集群，并将于今年年底投入运营。

去年，我们介绍了 Spectrum-X 在大型网络中相对于 InfiniBand 的多种优势。除了性能和可靠性优势之外，Spectrum-X 还具有巨大的成本优势。Spectrum-X 以太网的优势在于，每个 SN5600 交换机都有 128 个 400G 端口，而 InfiniBand NDR Quantum-2 交换机只有 64 个 400G 端口。请注意，Broadcom 的 Tomahawk 5 交换机 ASIC 也支持 128 个 400G 端口，这使得当前一代 InfiniBand 处于很大的劣势。

完全互连的 100k 集群可以是 3 层，而不是 4 层。使用 4 层而不是 3 层意味着需要 1.33 倍的收发器。由于 Quantum-2 交换机的基数较低，100k 集群上完全互连的 GPU 的最大数量限制为 65,536 个 H100。下一代 InfiniBand 交换机 Quantum-X800 通过拥有 144 个 800G 端口解决了这个问题，但从数字“144”可以看出，这是为与 NVL72 和 NVL36 系统一起使用而设计的，预计在 B200 或 B100 集群中不会大量使用。尽管使用 Spectrum-X 不需要 4 个层级可以节省成本，但不幸的缺点是您仍然需要从 Nvidia LinkX 产品线购买价格昂贵的收发器，因为其他收发器可能无法工作或未经 Nvidia 验证。

Spectrum-X 相对于其他供应商的主要优势在于，Spectrum-X 得到了 NVIDIA 库（例如 NCCL 和 Jensen）的一流支持，将您推向分配队列，成为其新产品线的首批客户之一，而使用 Tomahawk 5 芯片，您需要大量的内部工程工作来使用 NCCL 优化您的网络，以实现最大吞吐量。

使用以太网而不是 InfiniBand 作为 GPU 结构的一个不幸缺点是，以太网目前不支持网络缩减中的 SHARP。网络缩减的工作原理是在网络交换机本身内拥有张量核心来执行每个 GPU 的总和。SHARP 的理论网络带宽增加是 2 倍，因为它将每个 GPU 必须执行的发送和写入次数减少了 2 倍。

Spectrum-X 的另一个缺点是，对于第一代 400G Spectrum-X，Nvidia 使用 Bluefield3 而不是 ConnectX-7 作为临时解决方案。但对于未来几代产品，我们预计 ConnectX-8 可以与 800G Spectrum-X 完美配合。对于超大规模量产，Bluefield-3 和 ConnectX-7 卡之间的价格差异约为 300 美元 ASP，另一个缺点是该卡比 ConnectX-7 多耗电 50 瓦。因此，对于每个节点，需要额外 400W 的功率，从而降低整个训练服务器的“每皮焦耳智能”。与具有完全相同网络架构的 Broadcom Tomahawk 5 部署相比，您放置 Spectrum X 的数据中心现在需要额外的 5MW 才能部署 100,000 个 GPU。

博通战斧5

为了避免支付巨额的 Nvidia 税，许多客户都在部署基于 Broadcom Tomahawk 5 的交换机。每台基于 Tomahawk 5 的交换机都具有与 Spectrum-X SN5600 交换机相同的端口数量，即 128 个 400G 端口，如果您的公司拥有优秀的网络工程师，则可以实现类似的性能。此外，您可以从世界上任何供应商处购买任何通用收发器和铜缆，然后进行混合搭配。

大多数客户都直接与 ODM 合作，例如与 Celestica 等 ODM 合作，使用基于 Broadcom 的交换机 ASIC，与 Innolight 和 Eoptolink 等公司合作，使用收发器。根据交换机成本和通用收发器成本，Tomahawk 5 比 Nvidia InfiniBand 便宜得多，与 Nvidia Spectrum-X 相比也更便宜。

不幸的缺点是，您需要拥有足够的工程能力来修补和优化 Tomahawk 5 的 NCCL 通信集合。开箱即用的 NCCL 通信集合仅针对 Nvidia Spectrum-X 和 Nvidia InfiniBand 进行了优化。好消息是，如果您有 40 亿美元用于 100k 集群，那么您就有足够的工程能力来修补 NCCL 并编写优化。当然，软件很难，而且 Nvidia 始终处于前沿，但一般来说，我们希望每个超大规模企业都能进行这些优化并放弃 InfiniBand。