Collective Communication

Alibaba High Performance Network (HPN) HPN介绍了一种两层的双平面网络，可以在一个Pod中接入1.5w个GPU，通常需要3层Clos架构的网络才能容纳这么多GPU HPN 提出了一种新的双 ToR 设计，以取代传统数据中心网络中的单 ToR 1. 贡献与挑战 挑战 流量模式 传统网络无法应对LLM的低熵、周期性、突发的网络特点，传统的数据中心网络一般是高熵的（传统网络中会存在百万条流，但是每条流的利用率特别低，一半小于20%） ECMP在传统的数据中心的高熵、低利用率的网络中性能表现较好，但是在LLM训练中并不是最佳的 单点故障的敏感性高 LLM训练是一个同步过程，所有GPU合作完成一系列迭代，任何一个GPU发生故障都有可能导致整个训练过程出现问题 对LLM训练影响最大的是与机架顶部（ToR）相关的单点故障，这种故障可能会影响到各种GPU 生产统计数据显示，LLM训练中出现的故障造成的损失是一般云计算故障的 20 倍 贡献 非堆叠的双层ToR网络，可以在两个交换机之间直接同步，很好的改善了大规模部署的可信度 适配最新的51.2Tbps的交换机芯片，可以将1K个GPU部署在Tier 1网络中，使96.3%的训练任务获得高性能的网络 我们的实验表明，使用HPN的LLM训练吞吐量比传统数据中心网络高14.9倍 2. 背景知识 LLM的并行策略 DP：每次迭代使用All Reduce同步计算梯度数据 PP：每次使用Send/Recv传递中间结果 TP：每次迭代使用All Reduce/All Gather同步输出和对应的梯度 LLM的流量特征 带宽利用率周期性突发 流的数量少 传统的数据中心网络不适用于LLM流量模式 LLM对单点故障的敏感性 LLM每次的Checkpoint间隔大概在2-4小时，按照一个3k张GPU的集群计算，每次失败导致的回滚都将导致大约3w美元的损失 常见的监控工具和异常分析工具并不能避免网络产生故障，根据实验表明，在NIC到ToR之间每个月大概有0.057%的Link故障率，在ToR交换机每个月的故障率大约是0.051%，即一个LLM训练集群每个月可能会产生1-2次的Crash，5k-60k次的Link故障 LLM网络架构的建设目标 规模化：达到15K个GPU的规模，未来可以扩展到100K个GPU的规模 高性能：尽可能小的网络跳数，尽可能使用GPU-GPU直达的连接 单点故障容错率：在网络拓扑层尽可能改善单点故障的容错率 3. HPN架构 分为前端网络和后端网络，前端网络主要负责例如管理、接口、存储等网络流量，后端网络负责LLM的训练时的流量 每个Host包含8个GPU，使用NVLink互联，双向带宽达到400GBps-900GBps 每个Host包含9个2x200Gbps的网卡，其中一个连接到前端网络，其余的8个与GPU直连，接入后端网络 每个网卡的2个端口分别连接至不同的ToR网络，这种双ToR设计可以避免单点故障 4. 双ToR网络 传统数据中心的NIC的两个光缆接入一个交换机成为单ToR设计 双ToR设计将NIC的两个光缆接口分别接入不同的ToR交换机中 两个接口配置相同的IP和MAC地址，即使其中一个ToR故障，另外一个依旧可以正常工作 基于以上，同一个NIC的两个网卡共享相同的Queue Pair Context ...

we survey the current state-of-the-art collective communication libraries (namely xCCL, including NCCL, oneCCL, RCCL, MSCCL, ACCL, and Gloo), with a focus on the industry-led ones for deep learning workloads. 常见的MPI库：MPICH、MVAPICH、OpenMPI 其他的非MPI库：OpenSHMEM（Open-source Symmetric Hierarchical MEMory）、UCX（Unified Communication X）、UCC（Unified Collective Communication） 常见的xCCL库：NVIDIA Collective Communications Library (NCCL)、AMD’s ROCm Collective Communication Library (RCCL)、Gloo 1. 贡献与挑战 挑战 什么让同时代的xCCL比MPI更具有吸引力？ 每种集合通信库的性能特性如何？ 这些xCCL库是如何设计的？是否存在某种共享的设计模式？ 贡献 总结和研究集合通信原语、网络拓扑、算法，为同时代的深度学习训练奠定基础 讨论这些研究的工业集合通信解决方案以及其细节测试 对比当前的集合通信库的性能情况 2. 集合通信原语 Broadcast：常用于将训练数据发送到各个设备上 All Reduce：广泛应用于分布式神经网络训练的后向传播阶段 All Gather、Scatter、All-to-All、Reduce、Reduce Scatter 3. 网络拓扑架构 3.1 HyperCube 优点：高度的连接性，不容易发生故障 ...

《ASTRA-SIM: Enabling SW/HW co-design exploration for distributed DL training platforms》 1. 文章简介 1.1 摘要 现代深度学习系统主要依靠基于高性能加速器（如 TPU、GPU）的硬件平台进行分布式训练。目前的例子包括谷歌的云 TPU 和 Facebook 的 Zion。DNN 训练涉及 DNN 模型架构、并行化策略、调度策略、集体通信算法、网络拓扑和终端加速器之间复杂的相互作用。随着人工智能/ML 模型的创新不断加速发展，需要一种全面的方法来理解和驾驭未来系统中复杂的 SW/HW 设计空间，以支持未来 DNN 模型的高效训练。在这项工作中，我们做出了以下贡献：(i) 为分层扩展结构上的分布式训练建立了 SW/HW 设计空间；(ii) 开发了一个用于导航设计空间的网络模拟器；(iii) 展示了算法拓扑协同设计加速端到端训练的前景。 1.2 研究动机 对模型架构、并行策略、调度算法、集合通信、网络拓扑、终端算力的仿真 大规模并行训练成本高，在实际部署和训练之前，需要一个仿真工具进行评估 1.3 主要贡献 为分层加速器结构设计空间探索建立 SW/HW 设计空间，并确定扩展 DL 工作负载的关键瓶颈 开发名为 ASTRASIM 的端到端网络模拟器，用于评估设计空间的各个方面 使用 ASTRA-SIM 对 alltoall 和 Torus 拓扑的 all-reduce 和 all-to-all 集合的一维、二维和三维拓扑进行全面分析 2. 实现方法 3. 实验结果 实验参数 ...

1. 内容简介 1.1 摘要 聚合以太网（RoCE）上的 RDMA 协议因其与传统以太网结构的兼容性而对数据中心网络产生了巨大的吸引力。然而，RDMA 协议只有在（几乎）无损网络上才有效，这就强调了拥塞控制在 RoCE 网络中的重要作用。遗憾的是，基于优先级流量控制（PFC）的本地 RoCE 拥塞控制方案存在许多缺点，如不公平、头线阻塞和死锁。因此，近年来人们提出了许多为 RoCE 网络提供额外拥塞控制的方案，以尽量减少 PFC 的缺点。不过，这些方案都是针对一般数据中心环境提出的。与使用商品硬件构建并运行通用工作负载的普通数据中心不同，高性能分布式培训平台部署了高端加速器和网络组件，并使用集体（All-Reduce、All-To-All）通信库专门运行培训工作负载。此外，这些平台通常有一个专用网络，将其通信流量与数据中心的其他流量分开。可扩展的拓扑感知集体算法本质上就是为了避免同播模式并优化流量平衡而设计的。由于这些显著特点，我们有必要重新审视以前提出的通用数据中心环境拥塞控制方案。在本文中，我们深入分析了在分布式培训平台上运行时，一些最先进的 RoCE 拥塞控制方案（DCQCN、DCTCP、TIMELY 和 HPCC）与 PFC 的对比。我们的研究结果表明，以前提出的 RoCE 拥塞控制方案对培训工作负载的端到端性能影响甚微，因此有必要根据分布式培训平台和工作负载的特点设计一种优化的、低开销的拥塞控制方案。 1.2 研究动机 标准的RoCE协议使用FPC协议控制阻塞，但是会带来不平衡、队头阻塞和死锁的问题 传统的基于RoCE的阻塞控制算法是基于通用的数据中心构建的 之前的阻塞控制协议（DCQCN、TIMELY、HPCC等）并不适用于DNN训练的场景 1.3 主要贡献 第一个在DNN分布式训练任务上进行阻塞控制方案评估的工作 使用ASTRA-sim和NS3使用不同的阻塞控制方案进行仿真验证 对每个现成的阻塞控制方案进行详细的分析，包括集合通信和DNN训练负载等 不同的最先进 RoCE 拥塞控制方案对端到端培训性能影响甚微 我们为设计一种针对分布式训练的优化且低开销的拥塞控制方案指明了方向 2. 实现方法 使用ASTRA-sim仿真 网络拓扑 系统参数 3. 实验结果 3.1 Single-switch Incast micro-benchmark FPC only 队列快速满载，随后网络被反复暂停并重复这一过程 DCQCN在设置参数时确保没有FPC触发，且带宽率用率较高 DCTCP、TIMELY等在没有触发FPC帧的条件下 3.2 Single-switch Collectives Micro-benchmark 在8-128个GPU条件下进行All-To-All和All-Reduce集合通信 在集合通信条件下不存在阻塞，所以没有阻塞控制算法对其无效 ...

I. 前置内容 在了解集合通信（Collective Communication）之前要先了解点P2P对点通信（Point-to-Point）。P2P通信通常为两个不同进程间的通信，是1对1的； 在MPI规范中，既有同步阻塞的P2P接口：MPI_send和MPI_Recv接口，也定义了非阻塞的P2P接口如：MPI_Isend、MPI_Irecve。 集合通信和P2P通信是相对应的，集合通信则是1对多或是多对多的。在分布式系统中，各个节点间往往存在大量的集合通信需求，而我们可以用消息传递接口（Message Passing Interface，MPI）来定义一些比较底层的消息通信行为譬如Reduce、Allreduce、Scatter、Gather、Allgather等。 1.1 系统架构 集合通信算法的优化往往与其对应的网络拓扑和系统架构有直接关系，通常情况下，一个节点内的GPU-GPU或GPU-CPU之间的结构成为系统架构，节点之间的网络连接称为网络拓扑，一种确定的系统架构会有确定的网络拓扑架构。 在HPC领域有很多经典的系统架构和网络拓扑，例如：Summit system或者Lassen system等。本文主要由于发表于2021年，很多系统架构和指标数据与当先最新数据差异较大，但是为了方便后续的理解，本文后续还是以Summit system和Lassen system为例进行分析。 简化的Summit System和Lassen System（论文中的结构） 每个节点包含6个GPU和2个CPU，每3个GPU和1个CPU组成一个Group，使用NVLink进行连接，CPU与CPU之间使用X-Bus进行连接，同时与IB网卡使用PCIe进行连接，节点间使用IB协议进行组网。NVLink、NVSwitch、IB等硬件设备的概念将会在下一节中介绍。 1.2 相关组件 NVLink and NVSwitch NVLink和NVSwitch是一种可支持服务器内和服务器间实现高级多 GPU 通信的基础模组。第四代NVLink技术可为多 GPU 系统配置提供高于以往 1.5 倍的带宽，以及增强的可扩展性。第三代NVSwitch基于 NVLink 的高级通信能力构建，可为计算密集型工作负载提供更高带宽和更低延迟。 Mellanox InfiniBand InfiniBand（直译为“无限带宽”技术，缩写为IB）是一个用于高性能计算的计算机网络通信标准，它具有极高的吞吐量和极低的延迟，用于计算机与计算机之间的数据互连。InfiniBand也用作服务器与存储系统之间的直接或交换互连，以及存储系统之间的互连。常用的IB交换机/网卡带宽普遍为为400GB/s。 Remote Direct Memory Access (RDMA) RDMA是一种概念，在两个或者多个计算机进行通讯的时候使用DMA， 从一个主机的内存直接访问另一个主机的内存。 1.3 (Non-)Personalized All-to-All 1.3.1 Non-Personalized All-to-All Non-Personalized All-to-All（通常称为 MPI_Allgather）是一种 MPI 集体通信模式，是 MPI_Gather 和 MPI_Bcast 的结合。所有进程按等级顺序从其他进程收集数据。操作结束时，每个进程都将与所有其他进程交换数据。 1.3.2 Personalized All-to-All Personalized All-to-All称为 MPI_Alltoall，与 MPI_Allgather 类似，所有进程都相互共享数据。然而，每个进程都会向其他进程发送不同的数据，从而形成一种个性化的集体通信模式（即，每个进程都会向每个其他进程发送不同的数据块） 1.4 相关算法 1.4.1 Ring 每个进程i发送数据给(i+1) \ N并从(i-1) \ N接收数据，但是这种方法会带来过高的延迟。 ...