火鸿 AI-HPC：深度学习的高性价比软硬件协同设计 - 文章 - 开发者社区

点击下方卡片，关注“ 慢慢学AIGC ”

摘要

深度学习(DL)和大型语言模型(LLMs)的快速发展使计算能力和带宽需求呈指数级增长。这种情况加上更快的计算芯片和互连设备的高成本，已经显著推高了高性能计算(HPC)的建设成本。为应对这些挑战，我们推出了火鸿 AI-HPC 架构，这是一个协同的硬件-软件协同设计框架及其最佳实践。在深度学习训练方面，我们 部署了配备 10,000 个 PCIe A100 GPU 的火鸿2，其性能接近 DGX-A100，同时将成本降低了一半，能耗减少了 40%。 我们专门设计了 HFReduce 来加速 allreduce 通信，并实施了多项措施来保持我们的计算-存储一体化网络无拥塞。通过我们的软件栈（包括 HaiScale、3FS 和 HAI-Platform），我们通过计算和通信重叠实现了显著的可扩展性。我们从深度学习训练中获得的面向系统的经验为推动 AI-HPC 的未来发展提供了宝贵的见解。

I. 引言

近年来，深度学习(DL)发展迅速，广泛应用于图像识别、语音识别、内容生成、自动驾驶等领域。深度学习的快速发展从根本上依赖于数据的支持。使用大量数据进行训练需要海量的计算资源。虽然依据摩尔定律，计算机速度平均每两年翻一番，但深度学习的发展速度远超这一速度。特别是近年来流行的大型语言模型(LLMs)，使计算资源和内存需求呈爆炸性增长。LLMs 的参数可达数百亿到数千亿，需要数百或数千个 GPU 进行训练。尽管 LLM 训练具有挑战性，但更多参数带来的新兴能力已经显示了继续扩大模型的好处。从那时起，研究人员走上了让模型变得更大的道路，再也没有回头。

为了获得更多计算资源，人们不得不扩展更多节点。这导致了 AI 基础设施建设成本的激增。如何降低新数据中心的成本以及如何构建高性价比的集群也是热门且具有挑战性的问题。此外，更多的节点导致更高的能源消耗，这与这个时代减少碳排放和实现碳中和的目标相矛盾。降低能源消耗也是一个具有挑战性的问题。

在本文中，我们利用多年积累的实践经验，提出了适用于深度学习和 LLMs 的 AI-HPC 系统的高性价比构建策略。

火鸿 AI-HPC 架构：我们已部署了一个由 10,000 个 PCIe A100 GPU 组成的集群用于深度学习训练。第 III-A 节提供了有关GPU 节点和网络拓扑的详细信息，我们在该节比较了我们的架构与 NVIDIA DGX-A100 在成本效益和更低 CO2 排放方面的表现。相比之下，我们必须在软件优化方面投入更多，以解决 PCIe 架构的性能挑战。以下各节将讨论软硬件协同设计。

我们架构中的关键技术主题：

• 网络协同设计 ：如第 III-B 节所示的 两层胖树网络集成了存储和计算网络 。整个网络分为两个区域，平台支持跨区域任务。为防止拥塞，我们采用了第 VI-A 节详述的各种网络调优。

• HFReduce ：通过 CPU 上的异步 allreduce 实现计算-通信重叠，在我们的 PCIe 架构上性能优于 NVIDIA 集合通信库(NCCL)，如第 IV 节所述。

• HaiScale ：如第 V 节所述，针对我们的 PCIe 架构优化并行方法，如数据并行(DP)、流水线并行(PP)、张量并行(TP)、专家并行(EP)、完全分片数据并行(FSDP)和零冗余优化器(ZeRO)。

• 3FS 分布式文件系统 ：解决大数据 AI 任务中的 I/O 瓶颈，配置我们的通信和网络调优，减少存储和计算集成网络拓扑中的拥塞，如第 VI-B 节所详述。

• HAI 平台 ：提供任务调度、故障处理和灾难恢复，提高利用率并降低成本。它为深度学习研究人员提供开箱即用的解决方案。该平台已开源： https://github.com/HFAiLab/hai-platform

稳定性和鲁棒性 ：这些是 HPC 中的关键主题。我们的系统配备了强大的机制来处理硬件故障，最大限度地减少停机时间和对运营的影响。这些机制在第 VII 节中讨论，包括：

通过我们的检查点管理器进行灾难恢复
用于检测硬件故障的验证器实用程序
过去一年我们集群中实际硬件故障数据的概览

我们希望这些见解对业界同行和研究人员都有帮助。

讨论和未来工作 ：在第 VIII 节中，我们讨论了有关 PCIe 架构的一些常见问题，如拥塞控制、维护成本以及与其他架构相比的稳定性。在第 IX 节中，我们提出了下一代 PCIe 架构，该架构主要面向混合专家大型语言模型训练，主要使用多网卡和多平面网络。

II. 背景

A. 深度学习的演变

深度学习和机器学习的革命始于 2012 年的 AlexNet，它在图像分类方面超越了传统方法，标志着大数据利用和计算需求增加的开始。ResNet 的出现及其更深的网络层次进一步拓宽了图像处理的视野，真正实现了"深度"学习中的"深度"。同时，大数据驱动的模型训练推动了数据存储技术的发展，导致了全闪存 SSD 分布式文件系统的出现。

到了 2017 年，谷歌的 Transformer 横空出世，提出了"注意力即所需"的概念，震撼了自然语言处理(NLP)领域。随着 AlphaFold 和 AlphaZero 等更复杂模型的出现，突显了对更强大的计算能力和内存的需求，也揭示了传统 FP64/FP32 计算设备的局限性。

进入 2020 年代，大型语言模型(LLMs)的崛起成为 AI 领域的游戏规则改变者。研究表明， 在有足够训练数据的情况下增加语言模型参数数量和计算预算能显著提升模型性能（即 LLM 扩展定律） 。因此，尽管需要庞大的计算资源，仍在努力训练具有数百亿甚至万亿参数的大型模型。其中的先驱示例包括 GPT-3 和 PaLM，它们占用了接近 1 TB 的 GPU 内存。认识到这一潜力，行业巨头们建立了大型 AI 集群来训练 LLMs，同时不断投资于计算能力芯片。从 GPT-4 开始转向混合专家(MoE)模型架构，以及最近的 AI 生成内容(AIGC)多模态模型(Sora)，进一步放大了对内存和计算资源的需求。然而，由于 AI 发展速度超过硬件发展，导致训练成本飙升，采用节省成本的解决方案已成为当务之急。

图 1 展示了深度学习计算能力的指数级增长。

picture.image

如图 2 所总结，AI 对计算能力的需求每年增长 10 倍，而摩尔定律则落后许多：硬件 FLOPS 每两年仅增长 3.0 倍，DRAM 带宽增长 1.6 倍，互连带宽增长 1.4 倍。这种差距使得需要更多机器，提高了深度学习训练成本，特别是在 LLM 训练方面，其所需的计算能力超过了传统 HPC 应用。

picture.image

B. 模型训练中的挑战与解决方案

在深度学习训练中，单个任务需要数百个 GPU，并消耗大量存储和网络资源。这种大规模引入了系统级挑战：

1) 效率 ：首先，在这种规模下实现高效训练至关重要。 模型 FLOPS 利用率(MFU) ，即观察到的吞吐量与理论最大吞吐量（假设 100% 峰值 FLOPS）的比率，作为评估训练效率的标准指标。训练 LLMs 涉及将模型分配给多个 GPU，这些 GPU 需要广泛通信以推进训练。除通信外，操作优化、数据预处理和 GPU 内存消耗等因素也显著影响 MFU。为提高效率采用了多种并行策略：

数据并行(DP) ：模型和优化器状态在多个设备上复制，数据均匀分布到所有设备。对于 LLMs 训练，零冗余优化器(ZeRO)通过在每个数据并行进程上分片这些状态，并使用 allgather 和 reduce-scatter 进行参数获取和梯度计算，进一步增强了这种方法。
流水线并行(PP) ：每个设备保存模型层的一部分，每个训练批次被分为多个微批次进行流水线执行。需要 GPipe、PipeDream 1F1B 和零气泡流水线并行(ZBPP)等高效调度策略来最小化"流水线气泡"。
张量并行(TP) ：这涉及将模型层放置在多个并行计算的 GPU 上。它包括行式和列式并行，需要 allgather 和 all2all 进行输入分割和输出合并。
专家并行(EP) ：在 MoE 训练中，MoE 模型的不同专家模型分布在不同的 GPU 上。门控模型在输入时选择要分配的令牌，相应的令牌通过 all2all 通信发送到专家模型。
完全分片数据并行(FSDP) 是基于 ZeRO Stage 3 算法的实现。FSDP 将模型参数、优化器状态和梯度分区，分配到不同的 GPU 上，每个 GPU 只保留总量的 1/n。在前向传播时，FSDP 执行 allgather 操作来组装完整参数，在前向传播完成后释放。类似地，在反向传播时，FSDP 进行 allgather 操作获取完整参数，然后进行反向计算得到梯度。接着执行 reduce-scatter 操作在所有 GPU 上同步梯度，使每个 GPU 持有 1/n 的归约梯度。最后，FSDP 使用每个 GPU 的 1/n 梯度和优化器状态更新 1/n 参数。FSDP 通过在每个 GPU 上只维护 1/n 的参数、梯度和优化器状态来减少 GPU 内存使用，从而能够训练更大规模的模型。

还有其他加速训练或减少内存使用的策略和算法，如 激活重计算 ，以及并行过程中增强的 通信和计算重叠 等。

2) 稳定性 ：第二个挑战是实现大规模高稳定性训练，即在整个过程中保持高效训练。从生产角度来看，稳定性至关重要，因为训练一个具有万亿 tokens 的大模型可能需要几周时间。在 DL训练中，掉队者和硬件故障是常见现象而非异常情况。掉队者可能会减慢涉及数百个 GPU 的任务，这突显了稳定性和任务恢复时间的重要性。

C. 这个时代的 HPC 和 AI 集群

HPC 对 AI 训练的不足：天河-2A、Stampede 2 和神威·太湖之光等传统超级计算机主要关注双精度计算，不支持FP16精度，使其不适合 DL 训练。富岳尽管性能很高，但不支持张量 GEMM 加速，这是 DL 工作负载的关键组件。虽然这些超级计算机可能不太适合 DL 训练，但它们强大的高性能网络和大规模集群构建的丰富经验为后续研究者提供了宝贵的见解和经验。
基于 GPU 的 HPC：Frontier、Aurora、Summit 和 Perlmutter 等超级计算机利用高性能 GPU 处理大规模计算。值得一提的是，Perlmutter 使用全闪存存储系统，实现 5TB/s 的峰值带宽。确实，在这些基于 GPU 的 HPC 上进行 DL 训练可获得显著性能。
大公司的 GPU 集群：Meta（前身为 Facebook）使用软硬件协同设计方法开发了其 AI-HPC，一个系统使用 IB，另一个采用 RoCE。字节跳动最初实施了混合 CPU 和 PCIe GPU 的 DL 集群。然而，随着 LLMs 时代的到来，他们采用了类似 DGX 的架构，建立了超过 10,000 个 GPU 的集群。阿里巴巴开发了自己的 HPN 网络，用于使用 NVIDIA H800 GPU 进行 LLMs 训练。NVIDIA 也有自己的 AI-HPC Eos，将配备 576 个 DGX H100 系统，总计 4,608 个 H100 GPU。虽然这将为 AI 任务提供可观的计算能力提升，但 DGX 系统的高成本引发了对经济可行性的质疑。
AI DSA 集群：像谷歌的 TPU 这样的定制设计 AI DSA（领域特定架构）加速器，利用高度先进的可重构光交换网络。除传统 GPU 外，还有英特尔 Habana Gaudi 等替代方案。特斯拉推出了 Dojo 超级计算机，该计算机使用晶圆级系统技术将整个硅晶圆构建为单个芯片。华为设计了昇腾 AI DSA 芯片，正如 NVIDIA 首席执行官黄仁勋所说，该芯片仍与 NVIDIA 保持竞争力。这些加速器专为高效执行 AI 工作负载而定制，提供专门功能以优化模型训练和推理。然而，尽管它们的软件生态系统在不断发展，但仍需要进一步发展以达到 NVIDIA 产品的成熟度。
云服务提供商：Azure 等云服务提供商为 AI 训练提供灵活和可扩展的资源。尽管它们便利且易于访问，但成本会随时间显著累积。对于跨越约两年的长期项目，这些成本可能相当于购买整个专用集群的费用。因此，对于大规模 AI 计算，这种选择可能不是最经济的选择。

D. AI 基础设施的挑战

随着模型不断变大，DL 训练需要数千个 GPU。此外，研究人员经常需要同时训练多个模型。因此，具有至少数万个 GPU 的集群才能满足 AI 从业者的需求。除了增加集群节点规模和添加更多 GPU 外，还需要找到节省整体系统建设成本的方法。这些成本包括但不限于电力支持、冷却、网络、存储、故障处理、灾难恢复等。构建高性价比的 AI-HPC 系统是一个重大挑战。

如何构建高性能、高效、经济且环保的 HPC 以满足 AI 训练需求已成为一个热门话题。一些工作，如分析了 HPC 的构建，讨论了异构集群的互连、冷却系统等。像鹏城云脑 II 这样的 AI 应用讨论了他们构建和提高 AI 计算能力和集群通信效率的策略，这帮助他们在 IO500 和 AIPerf 排名中获得第一名。

借鉴我们过去十年在深度学习方面的丰富经验，我们在成本效益方面进行了大量探索。本文主要讨论我们在不同模型和阶段实现成本效益和高性能的实践。

III. 火鸿 2：我们的深度学习和早期 LLM 训练方案

正如背景部分所述，LLMs 通常需要大量内存资源。相比之下，如图 3 所示，许多其他模型需要的内存要少得多。

picture.image

像 ResNet、Mask-RCNN、BERT、MAE 等流行模型的参数量都小于 1B，表明内存需求相对较低。因此，在设计主要用于深度学习模型训练的集群时，结合从火鸿 1 实验中获得的见解，我们认为采用 PCIe A100 GPU 是明智的，这在 2021 年的建设中被证明是足够的。

A. 火鸿 2：PCIe A100 GPU 架构

在我们的训练工作负载中，单个 200 Gbps 的 NVIDIA Mellanox ConnectX-6(CX6) InfiniBand(IB) 网卡就能满足 8 个 NVIDIA PCIe A100 GPU 的存储 IO 和计算通信带宽需求。如图 4 所示，我们采用了以下计算节点架构：

8 个 NVIDIA A100 PCIe GPU 和 1 个 Mellanox CX6 200Gbps IB 网卡：直接连接到 CPU，不使用 PCIe 交换机
IB 网卡占用独立的 PCIe 根复合体，从而避免与 GPU 的性能干扰
在设计中预留了添加 NVLink Bridge 的可能性：正如预期的那样，当 LLM 时代到来时，我们确实在 PCIe 卡之间添加了 NVLink Bridge

picture.image

表 I 显示了我们的架构细节，并与 NVIDIA 标准 DGX-A100 服务器进行了比较。

picture.image

B. 网络拓扑：存储与计算集成的两层 Fat-Tree

我们选择了 Fat-Tree 拓扑 作为我们的主要网络架构，因为它具有异常高的二分带宽，使其成为 AI-HPC 和高吞吐量存储环境的首选。尽管 Dragonfly 拓扑 也提供了可比的性价比和性能，但其缺乏足够的二分带宽，使其不适合我们集成存储和计算的网络设计。在实施时，各种 RoCE（以太网融合的 RDMA）技术尚不如今天这般成熟，因此 我们选择了 InfiniBand（IB）作为我们的网络解决方案 。我们使用了 Mellanox QM8700 InfiniBand 交换机，提供 40 个端口，每个端口 200 Gbps 。我们的 集群由 10,000 个 A100 GPU 组成 ，包括大约 1,250 个 GPU 计算节点和近 200 个存储服务器 ，尽管两层 Fat-Tree 最多可以支持 800 个节点（配置有 20 个 spine 交换机和 40 个 leaf 交换机）。

为了降低成本，我们选择了一个 两区域网络配置 ，而不是三层 Fat-Tree 解决方案，如图 5 所示。

picture.image

每个区域由一个 800 端口的 Fat-Tree 组成，连接大约 600 个 GPU 计算节点。每个存储服务器配备了两个 IB NIC，分别连接到不同的区域，因此所有 GPU 计算节点都可以共享一组存储服务。此外， 两个区域通过有限数量的链路互连 。我们的 HAI 平台调度策略确保跨区域的计算任务最多仅限于一个 。无论是使用 NCCL 还是我们自研的通信库 HFReduce，都可以通过使用 双二叉树算法 跨区域运行。我们的调度器确保在这种拓扑结构中，只有一对节点会跨区域进行通信。因此，跨区域通信被严格控制，从而确保网络带宽的最大利用和延迟的最小化。

总的来说，采用两层 Fat-Tree 拓扑结合 InfiniBand 网络，使得我们的系统在满足高带宽、低延迟要求的同时，也具备较好的成本效益。这个设计不仅适用于大规模 AI-HPC 工作负载，也能够处理高吞吐量的存储需求，确保系统能够应对未来不断增长的计算和存储需求，甚至需要所有节点的任务也可以在整个 Fire-Flyer 2 AI-HPC 上高效运行。

C. 我们架构的性价比

与 NVIDIA DGX-A100 架构相比，我们使用 PCIe A100 的方法在 TF32 和 FP16 一般矩阵乘法（GEMM）基准测试中实现了大约 83% 的性能。然而，它在成本和能耗方面都有显著的降低，实现了 GPU 成本和能耗的 60%，具体数据见表 II。

picture.image

与 DGX-A100 集群相比，后者需要一个涵盖 10,000 个接入点的三层 Fat-Tree 网络，包括 320 个核心交换机、500 个 spine 交换机和 500 个 leaf 交换机，总计 1,320 个交换机（如表 III 所示），我们的架构只需要 122 个交换机。这种配置显著提高了性价比。即使与一个大小相当的三层 Fat-Tree 网络进行比较，该网络有 1,600 个接入点，包括 40 个核心交换机、160 个 spine 和 leaf 交换机（总计 200 个交换机），我们的设计也节省了 40% 的网络成本。此外，通过使用 800 端口的框架交换机，我们进一步降低了光模块和电缆的成本。

尽管由于 PCIe 卡规格和 SXM 的固有差异存在性能差距，但我们通常能够以仅 60% 的成本实现 80% 的 DGX-A100 性能。此外，我们成功地将能耗降低了 40%，从而减少了二氧化碳排放。就性价比而言，我们认为这种方法既高效又成功。

IV. HFREDUCE：网络中的硬件软件协同设计

在大规模深度学习训练中，Allreduce 是聚合 GPU 中梯度的关键操作。为了优化我们架构中 PCIe GPU 之间的通信，我们开发了 HFReduce，这是一个专门为高效的 allreduce 操作设计的库。HFReduce 的核心策略，如图 6 所示，首先进行节点内的归约操作，然后对来自每个节点中 8 个 GPU 的归约数据进行节点间的 allreduce 操作。

picture.image

这一节点间的 allreduce 操作利用了双二叉树算法，类似于 NCCL，并通过将数据分块进行远程直接内存访问（RDMA）传输，从而确保了高性能。HFReduce 是多用途的，可以应用于任何需要 allreduce 以及一般的 reduce 和广播操作的场景。

A. HFReduce 算法步骤

节点内归约，如算法 1 所示：

picture.image

当 GPU 上的梯度数据需要进行 allreduce 时，HFReduce 异步地将这些数据传输到 CPU 内存。这种设备到主机（D2H）传输可以使用 GDRCopy [66] 进行小数据传输，较大的数据则使用 MemCpyAsync。
梯度数据到达内存后，使用 CPU 向量指令执行归约加法操作。

节点间归约，如算法 2 所示：

picture.image

使用双二叉树算法 [65] 进行节点间 allreduce，利用 RDMA 动词实现节点间的数据传输。
最后，CPU 将归约后的梯度通过 PCIe 返回到 GPU（主机到设备阶段）。

最终的主机到设备（H2D）传输可以通过使用 GDRCopy 来优化，以将数据写入同一 NUMA 节点中的四个 GPU，相比 MemCpyAsync，减少了三倍的主机内存读取。这种效率得以实现，是因为 GDRCopy 可以从主机内存读取数据并将其暂时缓存到 CPU 缓存中，从而使数据能够写入四个 GPU，而无需再次从主机内存读取。

B. HFReduce 相对于 NCCL 的优势

减少 PCIe 带宽消耗 ：设 n 为参与通信的 GPU 总数。在 NCCL 的环形拓扑中，每一单元数据需要经过 2n-1 次传输，每次消耗一个 GPU 的入站带宽和另一个 GPU 的出站带宽。这意味着对于单个数据单元，消耗的 PCIe 双向带宽为 (2n - 1) / n。相比之下，HFReduce 每个数据单元只需要一次 D2H 和一次 H2D 数据传输，只消耗一个单位的 PCIe 双向带宽。在我们的机器架构中，NCCL 性能主要受限于 PCIe 带宽。因此，HFReduce 的性能优于 NCCL。
没有 GPU 核心开销 ：HFReduce 利用 GPU 的复制引擎（CE）进行 PCIe 异步传输。相比之下，NCCL 的 allreduce 操作需要 GPU 核心执行，这可能影响 GPU 上其他计算内核的执行。HFReduce 实现了完全的异步操作，没有开销。

如图 7a 所示，HFReduce 在 Fire-Flyer 2 AI-HPC 上执行 allreduce 时，数据大小为 186 MiB 时，可以达到 6.3-8.1GB/s 的节点间带宽，而 NCCL 的节点间带宽仅为 1.6-4.8GB/s。

picture.image

C. 性能提升：HFReduce 与 NVLink

通过为 PCIe A100 GPU 安装 NVLink 桥接器，能够通过 600 GB/s 的 NVLink 实现配对 GPU 之间的高效通信。为了缓解原始 HFReduce 的内存瓶颈问题，我们实现了另一种 allreduce 模式，称为 HFReduce with NVLink。其核心思想是在通过 NVLink 互联的 GPU 之间首先执行归约操作，然后将梯度传递给 CPU。随后，当 CPU 返回结果时，将结果数据分割并分别返回给连接在 NVLink 上的配对 GPU，然后通过 NVLink 执行 allgather。

如图 7b 所示，HFReduce with NVLink 实现了超过 10 GB/s 的节点间带宽。

D. HFReduce 深度分析

实现中的关键技术策略 ：

使用 GDRCopy 加速 D2H 小数据传输 ，并通过减少主机内存读取次数达到比 MemCpyAsync 少三倍的效果。
节点内归约 ：CPU 利用 SIMD 指令，支持 FP32 / FP16 / BF16 / FP8 数据类型。
NUMA 感知 ：D2H 目标内存在两个 NUMA 节点之间交错，以获得最大带宽。CPU 添加的结果和通过网络接收的数据的内存绑定到 IB NIC 的 NUMA 节点，以最小化延迟。
节点间归约 ：通过 ibverbs RDMA 写操作实现双二叉树 allreduce 算法，避免了额外的开销。

HFReduce 克服了 EPYC Rome CPU 的局限性 ：我们与 AMD 和 NVIDIA 的工程师合作，找出 NCCL 在 PCIe 架构上，特别是在 EPYC Rome CPU 服务器上的性能不佳的根本原因。我们确定 Rome CPU 不支持链式写操作，这会显著加速 GPU 和 IB NIC 之间的 PCIe 点对点（P2P）数据传输。我们的测试表明，在 Rome CPU 上，GPU 和 IB NIC 之间的最大带宽约为 9 GiB/s，因此 NCCL 的 4 GB/s all-reduce 带宽是可以理解的。HFReduce 通过利用 CPU 进行归约并通过 IB 和主机内存传输数据来绕过这个限制。
HFReduce 的瓶颈 ：考虑到 HFReduce 在单个节点上的总内存操作，几个因素限制了其性能：
D2H 阶段 需要 8 次写操作。
节点内归约加法阶段 涉及 8 次读取操作和 1 次写操作。
节点间 allreduce 阶段 ：IB 发送需要 2 次读取操作，IB 接收需要 2 次写操作，同时归约加法需要 1 次读取操作。
H2D 阶段 ：使用 GDRCopy 可以将读取操作减少到仅 2 次，而 MemCpyAsync 需要 8 次读取操作。

总的来说，内存操作总量为 GPU 原始数据大小的 24 倍。配备 16 个通道 DDR4-3200MHz 内存的主机可以实现 320GB/s 的实际内存访问速度。因此，HFReduce 的理论最大速度约为 13.3GB/s，但考虑到 allreduce 算法带宽和网络带宽，实际速度接近 12GB/s。然而，我们的测试结果只达到了稍微超过 8GB/s。这一差距的根本原因是 EPYC CPU 的另一个限制。如前所述，我们的 GPU5 和 GPU6 通过相同的 PCIe 根复合端口（也称为 PCIe 主机桥接器）直接连接到 CPU。在 AMD EPYC Rome 和 Milan CPU 中，从根复合端口到 CPU 内部总线的最大带宽约为 37.5GB/s。虽然 PCIe 4.0 x16 端口能够从 GPU 到 CPU 实现超过 27GB/s 的带宽，但当两块 GPU 同时传输数据时，带宽会限制在约 37GB/s。此外，如果同时发生双向数据传输，带宽会进一步下降。因此，HFReduce 没有达到其理论速度。

通过使用 NVLink 与 HFReduce 相结合，提供了一种有效的方法来缓解这些瓶颈。然而，值得注意的是，下一代 CPU（如 EPYC Genoa）仍然面临 PCIe 主机桥接带宽的问题，无法同时支持两个全速 PCIe 端口。我们希望 AMD 在未来的版本中解决这个问题。

V. HAISCALE：深度学习模型训练的专门优化

A. HaiScale DDP 重叠 AllReduce 训练

HaiScale 分布式数据并行（DDP）是一个训练工具，使用 HFReduce 作为其通信后端，区别于 PyTorch 的 DDP，后者使用 NCCL 作为后端。在反向传播阶段，HaiScale DDP 执行一个异步的 allreduce 操作，对计算出的梯度进行聚合，这使得该通信能够与反向传播中的计算操作重叠。

如前所述，HFReduce 不依赖于 GPU 流式多处理器（SM）进行归约计算，因此可以完全异步地执行 allreduce，而不会影响性能。如图 8a 所示，使用 HFReduce 训练 VGG16 模型的时间仅为使用 Torch DDP 的 NCCL 后端的一半，当从 32 个 GPU 扩展到 512 个 GPU 时，几乎实现了 88% 的并行可扩展性。

picture.image

B. 大型语言模型（LLMs）训练优化

我们的 HaiScale 框架采用了多种并行策略来训练大型语言模型（LLMs），类似于 Megatron 和 DeepSpeed。我们在 PCIe 架构中对数据并行（DP）、流水线并行（PP）、张量并行（TP）、专家并行（EP）等方面进行了具体的工程优化。

1) NVLink Bridge 实现了 PCIe GPU 之间的张量并行：
随着大型语言模型（LLMs）的出现，我们将 NVLink Bridge 集成到我们的系统中。这个新增的功能在每对 GPU 之间建立了 600GB/s 的带宽，从而使得在执行张量并行时更加高效。

2) PCIe 架构中的流水线并行优化：
在我们的架构中，每个节点只有一个 IB NIC 连接 8 个 GPU，这可能导致在流水线并行（Pipeline Parallelism, PP）过程中出现网络带宽竞争问题。我们通过配置数据并行（Data Parallelism, DP）rank 来解决这一问题，使得同一节点上的 8 个 GPU 被分配到不同的 DP rank，从而错开每个 DP rank 的 PP 时间。正如图 9a 所示，当从 64 个 GPU 扩展到 512 个 GPU 时，训练 LLaMa13B 模型的每步时间从 64.118 秒减少到 9.717 秒，达到了 91% 的并行效率。

picture.image

我们还对 DeepSeekMoE-16B 模型的训练性能进行了基准测试，测试在 Fire-Flyer 2 AI-HPC 上的表现。如图 9b 所示，当从 40 个 GPU 扩展到 640 个 GPU 时，每步训练时间从 79.615 秒减少到 6.535 秒，达到了 76.14% 的并行效率。值得注意的是，在 320 个 GPU 时，训练步长为 10.71 秒，达到了 92.92% 的并行效率，展示了优异的可扩展性。

3) 完全分片数据并行（FSDP）： HaiScale 的 FSDP 和 PyTorch 的 FSDP 都是基于 ZeRO Stage-3 算法的实现。关于该实现的详细内容已经在第 II-B1 节中讨论过。

HaiScale 的 FSDP 提供了更好的工程实现，优化了内存管理，减少了与模型调整相关的内存碎片化问题。同时，我们还将 allgather 和 reduce-scatter 通信与前向传播和反向传播计算进行重叠，并在反向传播过程中分割优化步骤以增强重叠效果。如图 8b 所示，使用 HaiScale FSDP 训练 GPT2-medium 时，当从 16 个 GPU 扩展到 128 个 GPU 时，达到了 95% 的并行可扩展性。与 PyTorch 的 FSDP 相比，HaiScale 的 FSDP 将训练时间缩短了近一半。

C. 总结
我们的 AI-HPC 设计满足了深度学习（DL）的需求，并且通过加入 NVLink Bridge，能够满足早期阶段大型语言模型（LLMs）的训练需求，达到了 PCIe GPU 的利用上限。 然而，由于 PCIe 卡规格与 SXM 之间的固有差距，性能上存在一定的差异。 综合考虑整体性能、基础设施成本和能耗， 我们在不到一半的成本下实现了 80% 的性能（存疑） 。我们认为，Fire-Flyer 2 AI-HPC 在成本效益方面是一项成功的实践。

VI. 高级成本效益与协同设计优化

A. 确保最小化我们计算存储集成网络中的拥塞

如前所述，我们的成本效益网络将计算通信和存储流量集成在一起。为了实现最大带宽，必须隔离不同类型流量之间的干扰并控制网络拥塞。具体措施如下：

不同流量的分离
在典型的训练任务中，存在四种不同类型的流量：HFReduce 通信、NCCL 通信、3FS 存储流量和其他流量。通过使用 InfiniBand 的服务等级（Service Level, SL）技术，我们为节点之间建立连接时分配不同的 SL 值，并将 SL 映射到 InfiniBand 的物理队列虚拟通道（Virtual Lanes, VLs）上。使用虚拟通道确保不同通道中的流量不会相互干扰。最终，我们配置了这些比例以实现流量隔离，从而避免因头阻塞（Head-of-line blocking, HOL）和不同流量冲突引发的网络拥塞。
拓扑调整与路由优化
在高吞吐量存储场景中，自然存在许多并发通信模式，这会导致网络中的一定拥塞。在这种情况下，我们发现启用自适应路由会导致更严重的拥塞扩展。因此，我们选择了静态路由策略。基于静态路由方案，为了均匀分布存储流量到叶子交换机 → 脊骨交换机链路，我们将存储、计算和管理节点均匀分布到这些链路中。
NCCL 优化
我们调整了 NCCL 拓扑，使其通过同一 NUMA 节点内的 InfiniBand NIC 和 GPU 进行路由。这一调整减少了由 CPU 核心互联引起的 PCIe 拥塞。此外，通过使用 PCIe 放宽排序（Relaxed Ordering），我们进一步减少了拥塞并提高了带宽。
3FS 中的网络调优
3FS 实现了请求发送控制机制来缓解拥塞。具体细节将在下一节 "3FS 的关键技术点" 中讨论。

B. 高吞吐量分布式文件系统：3FS

概述 3FS 是我们自主开发的高性能分布式文件系统，类似于 WekaFS、DAOS 和 BeeGFS。然而，3FS 的设计和实现专注于充分利用 NVMe SSD 的高 IOPS 和吞吐量，以及 RDMA 网络。

表 IV：存储节点硬件详情

CPU : 1 * AMD 64 核 EPYC 7742 CPU
内存 : 512GB 8 通道 DDR4-3200MHz
NIC : 2 * Mellanox InfiniBand CX6 200Gbps NIC
数据 SSD : 16 * 15.36TB PCIe 4.0x4

3FS 存储节点硬件
在 Fire-Flyer 2 AI-HPC 中，我们部署了 180 个存储节点，如表 IV 所示，每个节点包含 16 个 PCIe 4.0 NVMe SSD 和 2 个 Mellanox CX6 200Gbps InfiniBand HCA。通过 360 个 200Gbps 出口 InfiniBand HCA，系统总共提供 9TB/s 的外部带宽，我们实际上达到了 8TB/s 的读取吞吐量。总共有 2880 个 NVMe SSD 提供超过 20 PiB 的存储空间，并且具备镜像数据冗余。
3FS 的关键技术点
3FS 系统包括四个角色：集群管理器、元数据服务、存储服务和客户端。元数据和存储服务向集群管理器发送心跳信号，所有服务和客户端从集群管理器轮询集群配置和服务状态。多个集群管理器同时运行，其中一个被选举为主集群管理器。

文件系统元数据存储在分布式键值存储系统的表中。每个文件或目录都有一个唯一的 inode ID。文件的 inode / 目录 ID 和元数据（如文件大小、文件内容数据的位置等）作为键值对存储在 inode 表中。单独的目录条目表存储 (父目录 inode id，条目名称)：(条目 inode id，...) 的键值对，以支持目录条目的遍历和文件/目录路径的解析。所有元数据服务的状态都保存在分布式键值存储系统中。多个元数据服务并行运行，处理来自客户端的元数据请求。

存储服务实现了链式复制（Chain Replication）与分配查询（Apportioned Queries, CRAQ），以提供强一致性。CRAQ 的写全读任何（write-all-read-any）方法帮助释放所有 SSD 的吞吐量和 IOPS。文件内容被分割成块，这些块被复制到一组存储目标链中。链表中包含一组有序的链条。元数据服务在链表中选择一个偏移量并为每个文件选择一个条带大小（k）。文件块被分配到从偏移量开始的接下来的 k 个链条上。为了将读写流量均匀分配到所有 SSD，每个 SSD 服务多个来自不同链条的存储目标。存储服务在每个存储节点上运行，管理几个存储目标。

存储网络采用 Fat-Tree 拓扑，提供全双工的分段带宽 。设计上，每个 3FS 客户端可以访问每个存储服务。在峰值负载时，客户端端会观察到并发通信（incast）拥塞。为了缓解这种拥塞，在存储服务和客户端之间实现了请求发送控制机制。当存储服务收到客户端的读取请求时，它会从 SSD 读取数据，并请求客户端的许可才能传输数据。客户端限制了并发发送者的数量。当存储服务被授予传输许可后，它通过 RDMA WRITE 发送数据，并通过 RDMA SEND 通知客户端。这种请求发送控制机制增加了端到端 I/O 延迟，但它是实现可持续高吞吐量所必需的。

3FS-KV
3FS-KV 是构建在 3FS 基础上的共享存储分布式数据处理系统，目前支持三种模型：键值存储、消息队列和对象存储。它支持读写分离和按需启动，允许它充分利用 3FS 提供的极高 I/O 吞吐量。3FS-KV 支持 DeepSeek 的 KV Context Caching on Disk 技术，大幅降低了大型语言模型（LLM）服务的成本。

C. HAI 平台：基于时间共享的调度平台

时间共享调度原则用于集群资源管理。用户提交任务，例如运行 Python 或 bash 代码，启动开发容器等，平台根据当前的资源需求、集群繁忙程度等中断并加载任务。任务代码需要遵循平台编码规则，以确保在中断后可以继续执行。具体过程如下：

接收来自集群的中断信号；
保存检查点（模型参数、优化器参数等）；
通知集群中断；
从检查点恢复并继续运行。

部署 HAI 平台的集群不将 GPU 资源池化，而是根据计算节点、资源类型、网络区域等对其进行分类和标记。HAI 平台鼓励用户充分利用多 GPU 并行训练，从而实现 99% 的 GPU 利用率。

VII. 稳定性和鲁棒性

A. 检查点管理器

LLMs 的训练可能持续数月，在此期间不可避免的硬件故障可能导致训练中断。为了最小化恢复时间并支持 HAI 平台的中断和恢复操作，我们开发了一个检查点管理器。此外，LLM 检查点的巨大规模需要一种高效的保存和加载方法，充分利用 3FS 的高吞吐量。检查点管理器包括以下组件：

• 参数和优化状态被分成多个块，使用 3FS 批量写入 API 写入 3FS，这比普通写入快得多，每个节点可实现超过 10 GiB/s 的速度。这使得 保存可以在几秒钟内完成 。

• 参数和优化状态从 GPU 异步传输到 CPU 主机内存，定期（通常每 5 分钟）进行检查点保存。

• 在保存过程中，每个张量都记录其索引和在检查点内的偏移量，这使得在加载过程中定位张量更加方便。使用 3FS 批量读取 API，加载过程可以在几秒钟内完成。

由于 3FS 的高写入吞吐量，定期保存操作可以在几秒钟内异步完成，不会影响训练过程。在硬件故障导致训练中断的情况下，仅损失最后 5 分钟的进度。对于拥有数千个节点的集群来说，这种灾难恢复的开销是最小的。

B. 验证器

提高设备稳定性的最佳方法是在问题发生之前识别它们 。因此，我们开发了一套验证工具来验证硬件是否正常运行。平台的自动运维系统每周在节点上运行验证程序以验证其正常功能。它将故障节点从调度平台中移除，确保所有调度节点都处于可运行状态。诊断工具如 hostping 也集成在我们的平台中，但找到硬件故障的根本原因对运维团队来说仍然是一项艰巨的工作。验证器主要包括以下部分：

检查硬件频率、链接速度和链接状态。
测试 CPU 压力和内存带宽。
GPU 内存测试：这包括检查 GPU 内存的每个字节，确保没有数据损坏。
在 GPU 内存完全占用的情况下运行 GEMM，可以同时检查 GPU 芯片中是否存在任何运算逻辑故障。
节点内 allreduce 测试：通过上层应用检查 NVLink 带宽。
存储带宽压力测试，确保存储正常运行。

C. 火鸿 2 AI-HPC 中的硬件故障特征

在超级计算机和数据中心中，硬件故障和芯片错误可能导致模型训练期间的浮点溢出、不收敛或收敛缓慢。这篇论文甚至直接指出，数据中心处理器中存在大量的 静默数据损坏 ，最终导致各种难以复现和定位的复杂问题。确实，在我们的实践中，我们遇到过未被错误纠正码（ECC）检测到的计算错误和 GPU 内存错误，这导致模型的梯度范数突增、损失爆炸甚至不收敛。如何处理这些硬件故障，及时识别和分类它们，是提高集群节点在线率和整体利用率的关键问题。

GPU Xid 错误

Xid 错误是一种源自 NVIDIA 驱动程序的通用 GPU 故障消息，记录在操作系统的内核或事件日志中。我们已经对各种类型的 Xid 错误进行了分类，并分析了可能导致此类错误的潜在原因，如表 V 所示。

表 V：GPU Xid 错误类型及其原因分析


Xid 错误	原因分析
软件引起：Xid 13/31，Xid 43/45	由应用
程序触发的软件相关 Xid 消息可能表明 GPU 内存中存在影响代码和数据段的异常。
然而，要全面评估硬件功能，考虑其他信息也很重要。
NVLink错误：
Xid 74	Xid74 表示 NVLink 出现错误。
对于 PCIe A100，这种错误主要发生在两个 GPU 之间
的 NVLink 桥接器上。
它的发生率比其他硬件故障高出几个数量级。
除了通过压力测试排除那些持续重复出错的设备外，目前没有很好的方法来避免 Xid74 问题的发生。
内存ECC错误：
Xid 63/64 Xid 94/95	当 GPU 处理 GPU 上的内存 ECC 错误时触发。
随着 A100 引入行重映射技术，大多数情况下只需要简单重置 GPU 就能解决问题，从而保持最佳性能。
不可纠正的GPU故障：
Xid 44/48 Xid 61/62/69/79	这些故障意味着 GPU 上发生了不可纠正的错误，这种错误也会报告给用户应用程序。
需要重置 GPU 或重启节点才能清除此错误。
其它故障：Xid 119

| Xid119 表示 GPU 的 GSP（GPU System Processor，GPU 系统处理器）模块出现故障。这类故障需要进行现场诊断测试（fieldiag test），大多数情况下需要 RMA（Return Merchandise Authorization，退货授权）处理。 |

附录表 VI 中的补充特征显示了过去一年我们的 Fire-Flyer 2 AI-HPC 系统中出现的 Xid 错误。

picture.image

在我们基于 PCIe 的系统中，Xid74（也称为 NVLink 错误）占据了很大比例，达到总数的 42.57%。这种高频率是由于 NVLink Bridge 连接器固有的故障率，再加上我们使用了数千个 GPU 而被放大。

软件相关错误（如 Xid13、Xid31、Xid43 和 Xid45）表明用户代码中可能存在非法内存访问或指令。值得注意的是，非法内存访问（Xid 43）占 33.48%，突显了改进内存管理的必要性。但是，这些错误也可能是由内存数据损坏导致的，因此如果排除了软件 bug，也应考虑硬件故障的可能性。

此外，GPU 内存 ECC 错误（如 Xid63、Xid64、Xid94 和 Xid95）需要特别注意，它们约占总数的 2%。图 10 展示了过去六个月我们生产集群中与 ECC 错误相关的统计数据。显然，GPU ECC 故障的数量明显超过 CPU 的故障数量。因此，及时处理 GPU ECC 故障对确保应用程序性能和准确性不受影响至关重要。

网络闪断

除了 CPU 和 GPU 故障外，网络设备故障也是硬件问题中的重要组成部分。如图 10 所示，IB 链路故障占除 Xid74 以外硬件故障的 30%。

picture.image

网络闪断可能导致应用程序通信中断，甚至任务失败。由于大多数任务都在多个节点上运行，单个节点的问题可能影响许多其他节点，进一步降低集群利用率。图 11 显示了过去一年的 IB 链路故障数据，附录：补充特征表 VIII 中附有原始数据，表明这些问题可能在集群运行期间随机发生。

picture.image

VIII 讨论

A. RDMA 网络中的拥塞控制讨论

无损 RDMA 网络提供了几种流控制机制，如 RoCE 网络的优先级流控制(PFC)和 IB 网络的基于信用的流控制 。在网络路由方面，IB 中的静态路由算法或 ECMP（等价多路径）和 AR（自适应路由）有效地处理路由问题。然而，当多个服务器向单个接收器发送数据时仍可能发生拥塞，可能阻塞整个网络。为了缓解这种情况，IB 网卡使用 DCQCN（数据中心量化拥塞通知）作为其拥塞控制算法。虽然数据处理单元（DPU），如 NVIDIA BF 系列，允许用户自定义拥塞控制算法（如 HPCC 和基于 TIMELY RTT 的 CC），但它们增加了集群的成本和运营复杂性。

在实践中，我们选择禁用 DCQCN 以避免其缺点，因为它在我们的计算-存储集成网络中无法找到同时支持 HFReduce 流量和 3FS 存储流量的参数。相反，我们采用了第 VI-A 节中提到的网络调优方法，确保我们的网络在没有拥塞控制的情况下运行并保持无拥塞状态。

B. NVLink 技术选择讨论

最初，我们没有使用 NVLink 以避免额外成本并保持稳定性，因为当时 HFReduce 足以满足训练需求。然而，随着 LLM 需求的增加，我们专门为 LLM 训练目的添加了 NVLink。是否安装 NVLink 的决定应该基于实际需求，因为它可能存在潜在缺点。

C. 维护成本概述

建设成本

相对硬件成本在表 II 和 III 中提供。

picture.image

软件成本，由几十名内部开发人员贡献，仅占数千台 GPU 服务器成本的一小部分。

2 ) 能耗

表 II 中提供了 ResNet 训练期间的平均功耗比较。包括 IB 交换机和其他节点的开销，Fire-Flyer 2 AI-HPC 的总能耗不超过 4 MW，大约仅超过 3 MW。

运营成本

运营成本可以通过考虑功耗和机架租赁成本来估算。将这个数字乘以节点数量和 PUE（电能使用效率），即可计算出总运营成本。

D. 与其他架构相比的稳定性

最近的一篇论文报告说，NVLink 相关故障约占总故障的 52.42%（103 个中的 54 个），原始数据显示 54 个 NVLink 错误、21 个 CUDA 错误、16 个节点故障、12 个 ECC 错误和 12 个网络错误。相比之下，我们的 NVLink 相关问题，主要是 Xid-74 错误，如第 VII-C1 节所述，约占 GPU 故障的 42.57%。

IX 未来工作

未来架构和新 GPU 模型的集成

我们的下一代 PCIe 架构专为 MoE（专家混合）LLM 训练设计，其中 alltoall 性能至关重要。因此，下一代节点具有 1:1 的 GPU 到 NIC 比率，与 DGX-H100/B100 系统相当，如图 12 所示。

picture.image

我们正在考虑实施多平面网络以降低成本同时保持性能。此外，我们正在探索使用 RoCE 交换机替代 IB 交换机，这可以显著降低网络开支。使用 128 端口 400 Gbps RoCE 交换机，4 平面两层胖树网络可以支持多达 32,768 个GPU。

X 结论

在本文中，我们分享了在部署和维护配备 10,000 个 PCIe A100 GPU 的 Fire-Flyer 2 AI-HPC 系统过程中获得的经验和见解。我们在 PCIe 架构和存储-计算集成网络设计方面的方法实现了显著的成本节省，有效地将建设成本降低了一半，展现出显著的成本效益。

在软件协同设计方面，我们引入了 HFReduce 和 HaiScale 来克服硬件限制，确保 PCIe 架构的可扩展性能。我们自主开发的 3FS 分布式文件系统，结合网络协同设计，为 3FS 和 HFReduce 的归约（allreduce）流量实现了流量隔离，有效防止了拥塞。HAI 平台内的综合软件栈解决了从网络拥塞到硬件故障等各种系统故障，从而确保了高稳定性和鲁棒性。

这些软件和硬件创新共同使我们的 PCIe A100 架构达到了 NVIDIA DGX-A100 性能的 80%，同时能耗不到后者的 60%。我们积累的实践知识可能对工业和学术领域都有价值。我们希望我们的工作能为其他致力于构建具有成本效益和高效率的 AI-HPC 集群的团队提供参考。

致谢

我们衷心感谢 DeepSeek-AI 和 High-Flyer Quant 的所有同事对 Fire-Flyer 2 AI-HPC 项目做出的宝贵贡献。在四年的设计、建设和运营过程中，他们的协作努力对克服众多挑战起到了关键作用。目前，Fire-Flyer 2 AI-HPC 支持着 DeepSeek-AI 系列大语言模型的训练任务。我们特别感谢 HFAiLab 系统团队和运营团队，他们的核心贡献对这项事业的成功至关重要。

扫描下方二维码，关注“ 慢慢学AIGC ”

picture.image