总结
在本文中，我们分享了部署和维护配备 10,000 个 PCIe A100 GPU 的 Fire-Flyer 2 AIHPC 的经验和见解。我们对PCIe架构和存储计算集成网络设计的方法大幅节省了成本，有效地将建设成本减半，并展示了巨大的成本-有效性。
在软件协同设计方面，我们引入了 HFReduce 和 HaiScale 来克服硬件限制，确保 PCIe 架构的可扩展性能。我们自主研发的 3FS 分布式文件系统，结合网络协同设计，有效保证 3FS 和 HFReduce allreduce流量的隔离，有效防止拥塞。HAI 平台内的综合软件堆栈可解决从网络拥塞到硬件故障的各种系统故障，从而确保高稳定性和稳健性。
这些软件和硬件创新使我们的 PCIe A100 架构能够实现 NVIDIA DGX-A100 80% 的性能，而功耗不到其 60%。我们积累的实践知识可能对工业和学术部门都有价值。我们希望我们的工作能为其他旨在构建经济高效 AI-HPC 集群的同行提供参考。
网络相关内容
B.Network Topology: Two-Layer Fat-Tree with Storage and Computation Integrated
我们选择 Fat-Tree 拓扑作为主要网络架构，因为它具有极高的等分带宽，使其成为 AI-HPC 和高吞吐量存储环境的首选。尽管 Dragonfly 拓扑也提供了相当的成本效益和性能，但它缺乏足够的等分带宽使其不适合我们的集成存储和计算网络设计。在实施时，各种 RoCE技术还不如现今这么成熟，因此我们选择了 InfiniBand （IB） 作为我们的网络解决方案。使用了 Mellanox QM8700 InfiniBand 交换机，提供 40 个 200 Gbps 端口。虽然两层 Fat-Tree 最多可容纳 800 个节点（配置有 20 个主干交换机和 40 个叶子交换机），我们的集群由 10000 个 A100 GPU 组成，包括大约 1250 个 GPU 计算节点和近 200 个存储服务器。
为了降低成本，我们选择了两个区域的网络配置网络配置，而不是三层 Fat-Tree 解决方案。每个区域由一个 800 个端口的 Fat-Tree 组成，该 Fat-Tree 连接到大约 600 个 GPU 计算节点。每个存储服务器配备两个 IB 网卡，分别连接到不同的区域，因此所有 GPU 计算节点都可以共享一组存储服务。此外，这两个区域通过有限数量的链路互连。我们的 HAI Platform 调度策略确保跨区计算任务最多限制为一个。无论是使用 NCCL还是我们内部开发的通信库 HFReduce，它都可以使用双二叉树算法跨区域运行。我们的调度器确保在这种拓扑中，只有一对节点跨区域通信。因此即使是需要所有节点的任务也可以在整个 Fire-Flyer 2 AI-HPC 上高效运行。
A：Ensuring Minimal Congestion in Our Computation-Storage Integrated Network
如前所述，我们经济高效的网络将计算通信和存储流量集成在一起。为了实现最大带宽，必须隔离不同类型流量之间的干扰并控制网络拥塞。在实践中，我们实施了以下措施：
1） 不同流量的发散：在典型训练任务中，有四种不同类型的流量：HFReduce 通信、NCCL 通信、3FS 存储流量和其他流量。通过使用 InfiniBand 的Service Level（SL）技术，我们在节点之间建立连接时分配不同的 SL 值，并将 SL 映射到 IB 物理队列虚拟通道 （VL）。使用虚拟通道可确保不同通道中的流量不会相互干扰。最终，我们配置了它们的比例来实现流量隔离，从而防止了由线头 （HOL） 阻塞 [76] 和不同的流量冲突引起的网络拥塞。
2）拓扑调整和路由优化：在高吞吐量存储场景下，自然存在很多 Incast 通信模式，导致网络出现一定的拥塞。在这种情况下，我们观察到启用 Adaptive routing 将导致网络中出现更严重的拥塞传播。因此，我们选择了静态路由策略。基于静态路由方案，为了将存储流量均匀分散到Leaf → spine 链路中，我们将各个节点（存储、计算、管理节点）均匀分布到 leaf → spine 链路中。
3） NCCL 优化：我们调整了 NCCL 拓扑，以通过同一 NUMA 节点内的 IB NIC 和 GPU 进行路由。此调整减少了 CPU 芯片互连引起的 PCIe 拥塞。此外，通过使用 PCIe Relaxed Ordering [77]，我们进一步减少了拥塞并增加了带宽。
4） 3FS 中的网络调整：3FS 实施了 request-to-send 控制机制来缓解拥塞。
Discussion
A. RDMA网络拥塞控制的讨论
无损 RDMA 网络提供了多种流控制机制，例如用于 RoCE 网络的PFC和用于 IB 网络的基于信用的流控制。在网络路由中，IB 或 ECMP 和 AR 中的静态路由算法可以有效地处理路由问题。但是，当多个服务器向单个接收器发送数据时，仍会发生拥塞，从而可能阻止整个网络。为了缓解这种情况，IB NIC 使用 DCQCN作为其拥塞控制算法。虽然DPU如 NVIDIA BF 系列，允许用户自定义拥塞控制算法（如 HPCC和基于 TIMELY RTT 的 CC ），但它们增加了集群的成本和操作复杂性。
在实践中，我们的计算存储一体化网络中支持 HFReduce 流量和 3FS 存储流量，因为找不到类似参数所以我们选择禁用 DCQCN 以避免其缺点。相反，我们采用了第 VI-A 章节中提到的网络调优方法，确保我们的网络在没有拥塞控制的情况下保持无拥塞运行。
B. 关于NVLink技术选择的讨论
最初，为了避免额外成本并保持稳定性，我们没有使用 NVLink ，因为 当时 HFReduce 足以满足培训要求。但是，随着需求的LLM增加，我们添加了专门用于训练目的的 LLM NVLink。由于其潜在的缺点，部署 NVLink 的决定应基于实际需求
1） 建设成本：相对硬件成本见表II和III。由数十名内部开发人员贡献的软件成本只是数千台 GPU 服务器成本的一小部分。
2） 功耗：表 II 提供了 ResNet 训练期间的平均功耗比较。包括 IB 交换机和其他节点的开销在内，Fire-Flyer 2 AI-HPC 的总能耗不超过 4 MW，大约略高于 3 MW。
3） 运营成本：可以通过考虑功耗和机架租赁成本来估算运营成本。通过将该数字乘以节点数和 PUE（电力使用效率），可以计算出总运营成本。
最近的一篇论文报告称，与 NVLink 相关的故障约占总故障的 52.42%（103 个中的 54 个），原始数据显示 54 个 NVLink 错误、21 个 CUDA 错误、16 个节点故障、12 个 ECC 错误和 12 个网络错误。相比之下，我们的 NVLink 相关问题，主要是 Xid-74 错误，如第 VII-C1 节所述，约占 GPU 故障的 42.57%。
九. 今后的工作
我们的下一代 PCIe 架构专为 MoE（混合专家）LLM训练而设计，其中all-to-all的性能至关重要。因此，下一代节点具有 1：1 的 GPU 与 NIC 比率，可与 DGX-H100/B100 系统相媲美，如图 12 所示。
我们正在考虑实施多平面网络，以降低成本，同时保持性能。此外，我们正在探索使用 RoCE 交换机而不是 IB 交换机，这可以显著降低网络费用。借助 128 端口 400 Gbps RoCE 交换机，4 平面两层 Fat-Trees 网络可支持多达 32,768 个 GPU。
对 幻方论文 感兴趣的同学，点赞和在看后，在公众号后台回复“tooyum150”可以获取下载地址。
相关阅读：