AutoCCL: Automated Collective Communication Tuning for Accelerating Distributed and Parallel DNN Training

文章标题：AutoCCL: 自动化集合通信调优以加速分布式并行DNN训练
作者/机构：Guanbin Xu, Zhihao Le, Yinhe Chen, Zhiqi Lin, and Zewen Jin (中国科学技术大学); Youshan Miao (微软研究院); Cheng Li (中国科学技术大学; 安徽省生物医学成像与智能处理重点实验室; 人工智能研究院，合肥综合性国家科学中心)

A1 主要贡献

本文针对分布式并行深度神经网络（DNN）训练中通信瓶颈问题，提出了一种名为AutoCCL的自动化集合通信调优方法。现有网络优化研究通常假设底层通信库（如NCCL）已充分调优，但忽略了其低级参数选择的重要性。本文研究发现，通过调优这些低级参数，可以显著提升通信性能，例如带宽可提升高达35%。然而，自动化调优面临两大挑战：一是参数组合导致的状态空间爆炸问题，二是训练过程中计算与通信并发执行带来的干扰。

为了应对这些挑战，AutoCCL做出了以下核心创新：
1. 全面的参数分析与解耦: 深入分析了NCCL的性能敏感参数，识别出6个关键低级参数，并将其分为两类：实现相关参数（决定通信原语的实现方法）和资源分配参数。前者取值范围小，后者取值范围大，且前者是后者的先决条件。通过实验和理论建模，发现资源参数的组合对通信带宽的影响呈现单峰函数特性。
2. 高效的“分而治之”调优算法: 基于参数解耦，设计了一种避免暴力搜索的高效算法。该算法首先将实现相关参数划分为多个子空间，然后在每个子空间内，利用资源参数的单峰特性，采用坐标下降法搜索最优的资源参数组合。这种方法显著减少了搜索空间，降低了调优开销。
3. 考虑计算干扰的在线调优方法: 为了精确捕捉真实训练环境中计算与通信的并发干扰，提出了在线调优方法。该方法利用DNN训练的迭代特性，将调优过程融入训练的初始迭代中。这样不仅可以直接在受干扰的环境下评估通信性能，从而获得更准确的最优配置，还能将调优开销隐藏在训练早期，对端到端训练时间影响极小。

本文的主要贡献总结如下：
* 对领先的通信库NCCL中的集合通信原语的低级性能参数进行了全面研究，揭示了其调优指南。
* 提出了一种在线调优方法，该方法实现了参数子空间划分和子空间内坐标下降搜索算法，并利用训练的迭代性来精确建模计算干扰下参数分配的影响。
* 实现了AutoCCL调优器，该工具集成了上述调优方法，并能透明地支持训练任务。
* 通过在通信微基准测试和代表性训练任务上将AutoCCL与NCCL及另一款最先进的调优器进行深入评估，验证了其有效性。

A3 背景知识/关键Observation/设计原则

2.1 分布式与并行DNN训练

分布式并行训练的普遍性与通信瓶颈。为了加速模型参数更新，将DNN训练任务分布并并行化到GPU集群上已成为普遍做法【17, 20, 24, 25, 30, 37–39, 44, 45, 48, 49, 51, 55,58,66】。如表1所示，当模型大小不超过单个GPU内存时，通常采用数据并行，让GPU处理不同数据分区，这需要频繁同步梯度，传输量与模型参数大小相当。当模型内存消耗超过GPU容量时，除了数据并行，还会采用张量并行或流水线并行来划分模型，这导致了更复杂的通信模式，这些通信往往位于训练流水线的关键路径上。已有研究证明，通信是限制分布式并行DNN训练可扩展性的主要瓶颈【14, 26, 27, 33, 34, 36】。

现有通信优化方法的局限性。现有优化方法包括调度【13, 19, 22, 23, 31, 46, 50, 59, 60, 67】、数据压缩【8, 9, 53, 56, 62, 63】、稀疏性探索【10, 28】和基于拓扑的算法设计【12,15,16,27,29,32,35,42,42,47,57】。这些方法大多假设底层通信库已得到良好调优，能有效发挥其优化效果。然而，本文在第3节通过实验验证，通信调优本身对带宽有显著的提升作用。

2.2 集合通信

NCCL在DNN训练中的核心作用。分布式并行DNN训练引入了集合通信模式，即数据在多个GPU之间进行聚合或分发。NVIDIA集合通信库（NCCL）【5】专为优化NVIDIA GPU和网络系统上的多GPU、多节点通信而设计，提供了如ReduceScatter、AllGather、AllReduce等高性能原语。这些API在单节点内通过PCIe和NVLink以及跨节点通过网络提供高带宽低延迟通信。AMD的RCCL（ROCm Collective Communication Library）【1】是其对应产品。本文聚焦于NCCL，因其应用最广且其设计理念影响了后续者。

不同模型训练中的集合通信模式。表1总结了四种DNN模型训练所使用的并行策略和集合通信原语。VGG19模型较小，仅使用32路数据并行，每次迭代通过AllReduce在32个GPU间交换6个大小为15-392MB的梯度桶。其他三个大语言模型则使用复杂的混合并行，如8路张量并行与4路数据并行/流水线并行结合。例如，Yi-1.5-34B在单次训练迭代中，执行61,440次AllGather（在8个GPU内传输56MB激活数据）和93,184次ReduceScatter（同样在8个GPU内传输56MB激活数据）。Phi-2-2B和Llama-3.1-8B由于采用4路数据并行，每次迭代传输的数据量更大（高达1710MB），需要在4个GPU服务器间通过AllGather、ReduceScatter和AllReduce传输模型梯度。

Table 1: 4个DNN模型在32个GPU（4台机器）集群上训练时使用的并行方式和集合通信原语。B代表十亿模型参数。TP、DP和PP分别代表张量并行【48】、数据并行【32】和流水线并行【20】。括号中的数字代表相应并行方式的GPU参与数量。对于每个集合通信原语，其(x_y_z)值表示每次训练迭代中，在y大小的通信组中交换x大小的消息z次。

集合通信任务的多样性与优化需求。总结来说，分布式DNN训练频繁使用多种集合通信原语，消息大小从几十MB到几GB不等，通信组大小和硬件设置也各不相同。因此，尽管任务复杂多样，高效执行通信至关重要。

2.3 底层原语配置

NCCL性能敏感参数的识别与分类。我们对NCCL的参数空间进行了系统全面的研究，分析了所有158个参数（包括93个未文档化的），发现其中有28个性能敏感参数。这些参数可分为6类：1个算法（A）、3个协议（P）、3个传输（T）、11个nchannel（NC）、3个nthread（NT）和7个块大小（C）。当用户调用通信原语时，NCCL运行时会创建一个对应的集合通信任务，并为其分配一个< A, P, T, NC, NT, C >形式的配置。

各项参数的具体含义。如表2所示，参数A（算法）决定数据如何在GPU间分发、组合或聚合，可选值为ring或tree等。P（协议）定义数据如何在GPU内存层级间移动和管理，如LL（低延迟协议）专为小消息优化。T（传输）指GPU间物理传输数据的机制，如P2P（点对点，通过NVLink或PCIe直连）或SHM（共享内存）。其余三个参数NC、NT、C与资源分配或并行度相关。NCCL将大消息分解为NC个分区，每个分区绑定一个线程块独立传输处理。每个线程块由NT个线程组成。每个数据分区可进一步分解为多个块，大小由C定义。因此，NC个线程块并发传输数据块，每个线程块顺序处理其数据块。

Table 2: NCCL的原语配置参数

3.1 独立通信

PCIe环境下的配置性能差异。我们首先考虑无干扰的独立通信任务。以Phi-2-2B模型中的任务为例，即在单机8个A40 GPU上聚合80MB数据。表3列出了四种测试配置，图1展示了其通信带宽。最佳配置CP3的带宽是最差配置CP1的2.69倍。CP3将消息拆分为更多数据分区（更大的NC）和更小的块（更小的C），并调整线程数（NT）以匹配传输粒度。与CP3相比，CP1使用的并发数NC较小，导致性能严重下降。CP2虽然增加了线程数，但性能仍低于CP3。值得注意的是，NCCL的默认配置CP0并非最优，其带宽仅为CP3的81.2%。

Table 3: 在具有节点内PCIe的8-GPU节点上，针对不同NCCL配置的AllGather（80MB）的各种配置。CP0指默认的NCCL配置。



Figure 1: 使用不同NCCL配置的的带宽比较

NVLink环境下的配置性能差异。我们将上述AllGather任务迁移到GPU间通过NVLink互连的新硬件环境。如表4所示，我们测试了CN0到CN3四种配置。图1显示，最佳配置CN3的带宽是最差配置CN0的1.28倍。对比CN0（NCCL默认配置）和CN3，我们发现传输参数T起着重要作用，CN3使用的共享内存（SHM）通信性能更优。对比CN3和次优的CN2，使用更多通道能带来更好的并行性能，这与PCIe实验中的观察一致。同时，对比CN1、CN0和CN3，我们发现当传输参数T设为P2P时，增加NC起到了完全相反的作用。

Table 4: 在具有节点内NVLink的8-GPU节点上，针对不同NCCL配置的AllGather（80MB）的各种配置。CN0指默认的NCCL配置。

不同任务和硬件下的配置联合效应。我们研究了不同通信任务、硬件环境和配置参数选择的联合效应。以VGG19模型中的AllReduce-64MB和AllReduce-15MB任务为例，在一台8 A40 GPU和两台16 A40 GPU的机器上运行，节点内使用PCIe，节点间使用100Gbps InfiniBand。如表5所示，对比C0和C1，我们发现算法参数A成为性能关键因素，NCCL默认算法错误地判断Ring算法更适合当前硬件，但实际上Tree算法更优。此外，将任务的最佳配置C2应用于任务（即C3），其性能比该任务的最优配置C4低约10%，表明即使是相似任务也需要重新发现配置。对比C3和C4，我们发现Ring算法是更好的选择，增加并行度（NC）确实能提升性能，同时需要缩减传输的最小粒度C和线程数NT。

Table 5: 在具有节点内PCIe的8-GPU节点上AllReduce的各种配置。每个任务以x, y格式显示，其中x表示消息大小，y表示通信组大小。P和T被省略，因为在所有配置中它们分别设置为Simple和SHM。C0指默认的NCCL配置。

独立通信调优的结论。以上所有实验表明，NCCL确定的默认配置通常并非最优，为NCCL参数调优留下了巨大的性能潜力。即使在相同硬件上的不同任务，或相同任务在不同硬件上，也需要不同的最优配置。参数选择及其相互作用的模式尚不明确，因此需要一个自动调优功能，让上层训练任务自由地享受优化后的快速通信。

3.2 并发计算干扰

计算干扰对通信性能的影响。通信和无数据依赖的计算任务通常并发执行，通信很少独占资源。计算与通信对GPU资源（特别是SM、缓存和全局带宽）的竞争会导致各自性能下降。为了研究NCCL通信任务在计算任务资源争用下的配置调优，我们设计了带计算干扰的实验。

带干扰环境下的调优效果。我们在表4的AllGather通信任务上引入额外的计算任务，并以NCCL默认配置为基线。计算任务使用GEMM【4】，后跟一个sigmoid【7】操作，通过选择不同的矩阵维度来代表轻量和重量级计算。表6显示，即使是轻量级计算，计算干扰也会导致通信性能显著下降。例如，轻量级计算干扰使AllGather带宽下降12.8%，重量级计算则下降高达39.3%。然而，通过精细的原语配置调优，AllGather的带宽在所有设置下都提升了34-78%。值得注意的是，经过配置调优后，带计算干扰的场景甚至可以比无干扰的默认NCCL快7.8-16.8%。

Table 6: 在8-NVLink-GPU节点上AllGather（80MB）的带宽，随计算干扰水平变化

3.3 NCCL调优的挑战

调优面临的两大核心问题。NCCL原语配置调优需要解决以下两个问题：

挑战一：如何在巨大空间中快速找到高性能配置？ 对于特定的通信类型、消息大小和通信组大小，配置调优空间是巨大的。如图2所示，可能的组合数量可达数百万。遍历这样的空间并比较候选配置的延迟和带宽非常耗时。例如，在单机8个由PCIe连接的A40 GPU上测试AllGather 80MB的所有参数组合需要数小时，随着消息大小和通信组大小增加，时间开销会显著扩大。


Figure 2: 不同通信的组合数量

挑战二：如何建模计算干扰与训练运行时动态性？ 模型的并行训练任务通常有高度可变的算子、算子划分维度和算子输入，导致在GPU上执行的计算任务多种多样。建模计算任务及其对通信的影响会进一步增加NCCL配置空间。此外，训练框架会增加运行时调度优化，引入动态性，使得计算和通信任务的并发执行难以预先预测。同时探索这些因素的所有潜在组合会导致不切实际的搜索成本。

A2 方法细节

4.1 参数划分

实现相关参数的特性与挑战。首先，algorithm、protocol和transport是实现相关的参数，它们共同决定了算法执行逻辑的拓扑、数据传输的方法以及完成原语语义所需的软件栈调用。这些参数至关重要，但它们的搜索空间相对较小，例如algorithm只有两种选择，protocol有三种，transport有两种。一些先前的工作【12,16,47】为选择这些实现参数提供了有用的指导。然而，我们发现这些指导在实践中并不总是可靠。例如，一些工作假设GPU之间的带宽和延迟是固定的，从而将Tree和Ring拓扑的时间成本估计为log2N和2 × (N − 1)。但实际上，带宽受消息大小、集群拓扑、拥塞和并发等多种因素影响，导致成本模型不准确。一个直接后果是，在对应表5的实验中，NCCL错误地选择了算法。

资源分配参数的特性与挑战。其次，参数NC、NT和C对应于资源分配。众所周知，模型训练期间的通信任务既需要在网络上传输数据，也需要GPU核心进行累加和平均等操作。这三个参数共同决定了如何利用网络带宽和GPU计算能力。这些参数的搜索空间相对较大，例如Chunk Size有8192个选项，Nchannel有128个选项。我们进一步观察到，分析它们对性能的影响必须基于对上述三个实现参数的预先选择。换句话说，前三个参数的选择为后三个参数的建模分析提供了基础。尽管前三个参数可以进行穷举搜索，但对后三个参数的组合进行穷举搜索在实践中是不可行的。因此，我们必须为这些资源相关参数建立一个性能模型。

基于参数分类的子空间调优方法。综上所述，基于对这些参数的分类，我们提出了一种基于子空间的调优方法。首先，我们将整个搜索空间划分为不同的子空间< A, P, T >，每个子空间对应algorithm、protocol和transport的一个特定组合。然后，在每个子空间内，我们使用一个统一的性能模型来确定NC、NT和C的最优组合。最后，我们比较所有子空间的最优组合，以确定全局最优配置。这种方法缓解了资源参数的搜索空间爆炸问题，同时消除了对实现参数启发式规则的依赖。

4.2 资源参数建模

通信带宽的理论模型。给定一个子空间，我们需要对另外三个资源参数进行建模。建模所需的符号在表7中提供。我们评估资源参数选择对通信带宽的影响，记为$β(NC,NT,C)$。集合原语的执行可分为两个阶段：阶段0，传输步骤负责从其他GPU读取数据并传输到本地缓冲区；阶段1，协议将数据从缓冲区加载到SM，执行归约操作，然后存回缓冲区。这两个阶段的带宽分别表示为$β_0$和$β_1$。由于传输和协议阶段的执行存在数据依赖且是串行的，如公式1所示，$β(NC, NT,C)$等于传输和协议带宽中的较小值。

Table 7: 符号表

传输（Phase 0）与协议（Phase 1）带宽的推导。接下来，我们推导阶段0的传输带宽公式。传输性能取决于块大小C和并发消息数NC，而与NT无关，因为传输不涉及计算。我们首先计算传输大小为M的消息所需的时间$t_0$，如公式2所示。$\frac{M}{NC \times C}$表示消息将被分成多少个串行步骤，每个步骤包含NC个大小为C的并行传输任务。等式右侧括号中的项表示一个步骤的时间成本，包括初始延迟$\alpha_0$和传输大小为$NC \times C$的数据所需时间，其中$β_0 \times \gamma$是当前拥塞下的带宽。$\gamma$是拥塞系数，随NC、NT和C的增加而增加。公式3将带宽定义为消息大小除以时间。通过求解公式2和3，我们得到阶段0的带宽公式，即公式4。与阶段0的带宽推导类似，我们也可以得到阶段1的估计带宽公式，如公式5所示。协议已确定数据粒度和缓存模式，因此处理性能与NC和NT相关，而与C无关。根据该模型，当NC、NT和C中任意两个参数固定，第三个参数逐渐增加时，$β_i$将单调增加，接近其物理带宽上限$β_i$，然后稳定甚至下降，从而影响整体带宽$β(NC, NT,C)$。




模型验证与单峰特性观察。为了验证上述模型及其特性，我们设计了一组通信原语实验。通过控制变量法，我们改变不同资源参数的值，并观察< AllGather,80M,8 − A40 − NV Link >的带宽变化。如图3所示，当任意两个参数固定时，随着第三个参数的增加，带宽先增加，然后减少或稳定。此外，当固定的两个参数改变时，第三个参数对应的带宽峰值（最佳点）也会相应移动。例如，图3a显示，当C = 80KB, NT = 96时，NC的最优值为4，而当C = 20KB, NT = 96时，最优值为16，因为较大的C导致更高的拥塞因子γ，达到最优点所需的NC值减少。类似地，如图3b所示，当NC = 2, C = 120KB时，NT的最优值为320，而当NC = 4, C = 120KB时，最优值为196，因为增加NC或NT都会增加γ，在NC较大时，NT曲线更早达到最佳点。图3c也观察到类似的模式。


Figure 3: 在一个拥有8个通过NVLink连接的A40 GPU的节点上，带宽的趋势

基于单峰特性的搜索方法选择。总而言之，我们发现NC、NT和C对性能的联合影响不是单调的，而是表现出具有一个最佳点的单峰函数特性。基于这一特性，我们可以自然地使用坐标下降法【3】来搜索资源参数组合空间。通过将NC、NT和C抽象为坐标下降法的三个维度，我们可以通过沿每个维度在上升方向上连续移动来找到最大值。

4.3 调优算法

算法设计概述。基于上述的参数分类、资源相关参数建模和子空间搜索方法，我们设计了一种NCCL参数调优方法，该方法由算法1和算法2组成。

算法1：子空间导向调优。算法1采用分而治之的策略，为每个通信任务w分别搜索每个子空间。具体来说，我们遍历所有子空间（第2-5行）。在第3行，我们调用坐标下降搜索（算法2）来获取该子空间内的最优配置。如果该子空间的最优配置优于当前的最佳配置，我们就更新最佳配置（第4-5行）。

算法2：坐标下降搜索。对于输入的子空间s，算法2将M设为资源参数的总数，代表该子空间内可调参数的维度（第1行），在我们的案例中M为3。接着，随机生成一个配置p，其实现参数由子空间s确定，其他资源参数的值从各自的范围内随机选择（第2行）。第4行初始化待调优的维度索引、已调优的维度数和学习率。第5-14行执行梯度下降搜索循环，直到所有维度都已调优。在第6行，执行配置p以分析其带宽。在第7行，将p的带宽与当前最优值optimum进行比较。接下来考虑两种情况：若p带宽高，则应沿当前调优维度更新配置。第8行计算p相对于当前最优值的带宽改进百分比，并将其用作学习率lr。第9行将optimum更新为p并重置已调优维度计数器tuned_dim。若p未改善带宽，则应选择新的调优维度。第11行增加tuned_dim，第12行选择下一个要调优的维度并重置学习率lr。在分析完p之后，第13和14行根据lr更新最优配置中dim维度的值。如果所有维度都已调优，第15行返回在子空间s内找到的最优配置。

Input: Subspace (s).
1 M ← Number of resource parameters.
2 Randomly generate a config p from subspace s.
3 optimum ← p
4 dim, tuned_dim, lr ← 0, 0, 0.01
5 while tuned_dim ≤ M do
6   p.ProfileBw()
7   if p.BwDelta(optimum) > 0 then
8     lr ← p.BwDelta(optimum) p.Bw()
9     optimum, tuned_dim ← p, 0
10  else
11    tuned_dim ← tuned_dim + 1
12    dim, lr ← dim + 1, 0.01
13  p ← optimum
14  p[dim] ← p[dim] + lr
15 return optimum

5.1 整体架构

AutoCCL与NCCL的架构对比。图4展示了AutoCCL的架构及其与NCCL的对比。AutoCCL虽然由NCCL演变而来，但在几个方面有显著不同。首先，AutoCCL不遵循NCCL的点对点设计。在NCCL中，执行集合通信任务的通信组内所有GPU都是对等的Peer，每个Peer基于确定性成本模型独立为同一通信任务生成默认配置。与此不同，AutoCCL中一个GPU被指定为Leader，负责运行调优算法、识别高性能配置，并将结果更新给其他称为Worker的GPU。

Leader与Worker的角色与组件。每个AutoCCL Worker的行为类似于NCCL中的Peer，维护一个配置表。对于任何任务，该表存储一个默认配置（由NCCL成本模型生成）以及一个由Leader生成的调优配置。当收到通信任务时，Worker的Executor会检查配置表，如果存在调优配置则选择它，否则使用默认配置。与Worker的简单设计相比，Leader的逻辑更复杂，引入了两个额外的系统组件：Optimizer和Coordinator。Optimizer从Executor收集性能分析数据，决定是否需要调优，并启动调优过程。它无需与其他节点协调，独立搜索高性能配置并决定是否替换当前配置。Coordinator在收到Optimizer通知后，将更新后的配置广播到通信组中的所有节点，更新它们的调优配置。成功后，所有后续相同的通信任务将使用更新后的配置。


Figure 4: NCCL和AutoCCL的架构

5.2 迭代式在线调优

利用训练迭代性进行在线调优。如图5所示，通过将通信调优过程置于预训练期的迭代中，我们可以应对工作负载的多样性并隐藏调优时间成本。我们将每个子空间的调优算法应用于跨迭代的同一通信任务。由于训练的迭代性和微批处理的使用，同一通信任务在每次迭代中会执行多次。在执行通信任务时，我们为相应的子空间运行一步坐标下降算法。完成后，如果子空间尚未达到最优，我们保存相应状态以便下次搜索。否则，我们停止并切换到下一个子空间。当找到高性能解决方案时，Coordinator会将其广播到通信组内的每个节点，这保证了更新的原子性，避免了同一通信任务使用不同版本配置的不一致状态。

在线调优的开销与收益。值得注意的是，调优会引入轻微的开销，可能会延长每次迭代的持续时间。然而，由于调优过程高效且调优后的迭代性能显著提升，端到端的训练加速仍然是可观的。


Figure 5: 使用AutoCCL的在线调优工作流程（底部）。带数字的矩形代表训练迭代。

5.3 新工作流程

在线调优工作流程示例。这里我们通过一个示例来逐步说明上述在线调优方法，展示AutoCCL的新工作流程，如图6所示。在Leader上，一个额外的History Table记录了不同配置下各种任务的执行时间，Optimizer用它来生成新的调优配置。最初，Config Table只包含任务task_2的红色config_1 ()。a1和a2展示了为通信任务获取并执行当前最优配置的过程，而b1到b5则展示了在线调优和配置更新过程。

具体步骤分解。假设Leader和Worker都收到了一个与之前记录的task_2（一个消息大小为40MB，通信组大小为2的AllGather操作）具有相同原语、消息大小和通信组成员的新通信任务。Leader和Worker首先查询Config Table获取目标配置（步骤a1）。由于Config Table在Leader和Worker之间是完全复制的，两者都会检索到红色的config_1，并使用config_1将task_2提交给运行时执行（步骤a2）。一段时间后，task_2执行完成，Leader上的Executor将执行时间（14ms）返回给Optimizer（步骤b1）。Optimizer更新History Table中的执行时间（步骤b2），然后检索task_2的历史执行时间并发起新一轮调优（步骤b3）。Optimizer观察到将NT从16增加到32使通信时间从16ms减少到14ms。根据坐标下降法，下一次尝试也将增加NT。因此，它选择NT = 64，生成config_2，并通知Coordinator（步骤b4）。Coordinator使用带同步语义的广播操作，将config_2更新到Leader和Worker的Config Table中，替换原有的config_1（步骤b5）。后续的task_2执行将使用config_2，在线调优过程将继续，直到找到最优配置。


Figure 6: AutoCCL的在线调优工作流程。颜色区分不同的配置。

5.4 实现细节

技术实现与兼容性。AutoCCL基于NCCL 2.18.3实现，包含9,176行C++代码，支持AllGather、Allreduce和ReduceScatter等集合通信原语。我们修改了NCCL的配置生成模块和传输初始化模块，以允许更灵活地使用各种配置。对于任何通信组，AutoCCL会自动在一个节点上启动一个额外线程作为Leader来执行通信任务调优。由于CUDA核的异步执行特性，我们启动一个额外线程来测量执行时间。AutoCCL基于C++标准库实现，Coordinator基于Linux套接字实现，无需额外库。因此，用户可以通过预加载动态库无缝地从NCCL迁移到AutoCCL，无需任何代码修改。由于AutoCCL和NCCL共享相同的接口，PyTorch【41】和MegatronLM【51】等训练框架可以直接集成AutoCCL，而运行在这些框架上的训练任务对底层的切换是无感知的。我们的代码已在【2】开源。

A4 实验环境

  • 硬件配置:
    • 集群A: 2个节点，每节点8个NVIDIA A40 GPU (48GB GDDR6)，共16个GPU。节点内GPU通过400 Gbps NVLink互连（每对GPU）。节点间通过2对400 Gbps InfiniBand-PCIe 5.0网卡连接。CPU为AMD EPYC 9654。
    • 集群B: 4台机器，每台8个NVIDIA A40 GPU，共32个GPU。节点内GPU通过PCIe 4.0连接。节点间通过100 Gbps InfiniBand网络连接。CPU为Intel Xeon Gold 5320。
  • 软件配置:
    • 系统/驱动: CUDA v12.1, NVIDIA驱动 v470.63.01。
    • 框架/库: PyTorch 2.1.0, MegatronLM用于并行管理。
  • 模型与数据集:
    • 评估了4个模型：Phi-2-2B【21】、Llama-3.1-8B【54】、Yi-1.5-34B【65】（均为大语言模型）和VGG-19【52】（计算机视觉模型）。
    • 模型参数规模从20亿到340亿不等。
    • 训练时采用混合并行策略（张量、数据、流水线并行），并结合了分布式优化器（ZeRO）。
    • 微批次大小（micro-batch size）在GPU内存限制下设为最大，全局批次大小（global batch size）参考GPT系列模型的设置。
      Table 8: DNN模型统计
  • 基线系统:
    • NCCL: v2.18.3-1，开启其内部调优功能。
    • AFNFA: 一个学术界的集合通信调优系统【64】。我们使用随机森林算法对1%的离线采样数据进行训练，并通过环境变量设置为其复现结果。

A4 实验结果

通信微基准测试

  • 无计算干扰:

    • AllGather/ReduceScatter (图7): 在PCIe集群上，AutoCCL相比NCCL在AllGather和ReduceScatter上分别实现了22.66%和27.52%的平均带宽提升，而AFNFA几乎无优化。在NVLink集群上，AutoCCL的优势更明显，平均带宽加速比分别达到1.38倍和1.39倍。
    • AllReduce (图8): AutoCCL相比NCCL和AFNFA平均带宽加速比分别为1.28倍和1.15倍。在32-GPU的PCIe集群上，AFNFA甚至出现负优化，而AutoCCL仍略优于NCCL。


    Figure 7: 不同A40集群上AllGather和ReduceScatter通信的带宽加速比

    Figure 8: 不同设置下A40集群AllReduce通信的带宽加速比
    * 有计算干扰:
    * 固定消息大小 (图9): 在并发GEMM计算的干扰下，所有原语的带宽都显著下降。但通过AutoCCL调优后，相比NCCL，AllGather、ReduceScatter和AllReduce的带宽分别提升了1.29倍、1.50倍和1.38倍。有趣的是，调优后带干扰的带宽接近于无干扰时的最优带宽。
    * 变化消息大小 (图10): 随着消息大小和计算干扰程度的增加，AutoCCL对大消息的优化效果显著（相比NCCL，AllGather提升1.11-1.76倍，AllReduce提升1.16-1.39倍）。而AFNFA仅在小消息下有优势，或表现不如NCCL，表明其模型无法处理复杂动态环境。


    Figure 9: 有无计算干扰下不同通信的带宽比较。消息大小为128MB。'+I'指受计算干扰的通信。图中标注了加速比。AG, RS和AR分别代表AllGather, ReduceScatter和AllReduce。

    Figure 10: 在一个8个A40通过NVLink连接的集群中，不同通信类型随消息大小和计算干扰增加的带宽加速比

端到端性能

  • 训练迭代时间 (图11): 在所有硬件设置和模型上，AutoCCL的训练迭代时间均优于NCCL和AFNFA。在PCIe集群上，由于AutoCCL对计算干扰的鲁棒性更强，性能提升比微基准测试更显著。在NVLink集群上，由于计算可能是瓶颈，通信优化的收益相对温和。在最佳情况下，AutoCCL能将训练迭代时间缩短超过32%。


    Figure 11: 不同模型在NCCL、AFNFA和AutoCCL下的训练迭代时间，并标注了加速比

迭代式在线调优效率

  • 收敛速度 (图12): AutoCCL的在线调优收敛速度非常快。对于LLM模型，由于通信操作的高度重复性，仅需几次迭代即可找到高性能配置。对于VGG-19等较小模型，虽然单次迭代通信操作较少，但迭代时间短，总调优时间也不超过10分钟。这突显了AutoCCL快速适应新环境的能力，这是离线调优策略无法比拟的。


    Figure 12: AutoCCL调优在端到端LLM训练早期迭代中的快速收敛

A7 补充细节

8.1 参数选择与可扩展性

调优参数的选择范围与依据。一旦确定了实现相关的参数T（传输），NCCL允许进一步优化特定于传输的参数。AFNFA考虑了用于以太网传输的NCCL_SOCKET_NTHREADS和用于IB传输的NCCL_NET_GDR_LEVEL。然而，我们的研究不包括这些参数，因为它们在提供有限性能增益的同时，会引入失败风险。AFNFA尝试优化的参数包括NCCL_ALGO (对应A)，NCCL_SHM_DISABLE和NCCL_P2P_LEVEL (对应T)，NCCL_MAX/MIN_NCHANNEL (对应NC)，以及NCCL_BUFFSIZE (对应C)。这些可调组合已包含在我们的搜索空间中。我们的搜索空间还包括了P（协议）和NT（线程数），它们的重要性在3.1节中得到了证明。

AutoCCL方法的可扩展性。子空间坐标下降方法具有内在的可扩展性，允许用户优化特定于传输的参数。引入特定于传输的参数只会增加实现相关参数的组合数量，实际上是将现有子空间细分为更细粒度的子空间。这种可扩展性使用户能够根据需要进一步优化特定于传输的参数。

当前参数选择的合理性。我们的研究表明，对特定于传输的参数使用默认或固定值已经能产生稳健的性能。例如，我们尝试优化IB特定参数，发现NCCL_IB_SPLIT_DATA_ON_QPS和NCCL_IB_QPS_PER_CONNECTION的默认值已经是最优的。同样，NCCL_NET_GDR_LEVEL的最优值通常取决于NIC和GPU拓扑，使其在不同通信工作负载中都有效。由于特定于传输的参数的最优值通常是硬件相关的，对其优化的进一步探索留作未来工作。

8.2 任务失败与有效配置

调优引发任务失败的潜在风险。调优NCCL参数可能导致训练任务失败。这个问题在相关研究【40, 64】中已有报道，并被我们的实验所证实。如前所述，一旦确定了实现相关的参数（如T），集合通信将采用特定的传输机制，如P2P传输。NCCL允许对特定传输机制进行进一步优化，例如为P2P传输启用P2P_USE_CUDA_MEMCPY可以提高带宽。然而，在端到端训练任务中，此设置可能导致死锁。此外，我们观察到另一类失败：对于资源分配参数（如NC、NT和C），过大的值会导致资源饱和，最终导致程序崩溃。

AutoCCL如何规避失败风险。尽管存在风险，但调优引起的失败对我们系统的影响很小，原因有二。首先，特定于传输的优化超出了我们的范围，因此我们天生就避免了与之相关的失败。未来，我们可能会在支持故障恢复的情况下探索进一步的优化。其次，对于NC、NT和C，由于性能函数的单峰特性，过大的值不会带来性能增益。因此，我们可以在不牺牲性能的情况下对资源使用施加上限，从而有效防止失败。

失败恢复的开销分析。此外，如果发生失败，与离线调优相比，在线调优会引入额外的加载检查点的开销。然而，鉴于最近在检查点技术方面的众多优化【18, 26, 61】，这种开销已显著减少且可以忽略不计。失败恢复的主要成本仍然是容器重启，这对于离线和在线调优都是必需的。

失败处理与调优的正交性。最后，失败处理和恢复与调优是正交的。我们可以在未来的工作中探讨这个主题。

A5 结论

AutoCCL是一个自动化调优工具，旨在优化NCCL的低级参数选择。通过将实现相关参数与扩大搜索空间的参数解耦，其“分而治之”的方法减少了进行大量试验的需求。此外，其在线调优策略能有效处理通信与计算的并发干扰。在多个集群和模型上的评估表明，与NCCL及另一款最先进的调优器相比，AutoCCL显著提升了通信性能和端到端的训练性能。

方法细节中的引用汇总

  • 【3】Coordinate descent: 在4.2节末尾引用，说明基于资源参数对性能影响的单峰函数特性，可以自然地使用坐标下降法来搜索最优参数组合。
  • 【4】General Matrix Multiplication: 在3.2节引用，作为模拟计算干扰的计算任务，与集合通信任务并发执行。
  • 【5】NVIDIA Collective Communication Library (NCCL): 在1节、2.2节、7节等处多次引用，作为本文优化的核心对象，是NVIDIA提供的主流集合通信库。
  • 【7】Sigmoid Function: 在3.2节引用，作为GEMM计算任务后的一个操作，共同构成并发计算负载。
  • 【12】Synthesizing optimal collective algorithms (Cai et al., PPoPP 2021): 在1节、2.1节、4.1节、7节引用。4.1节指出，这类工作为选择实现参数提供了指导，但其假设（如固定带宽）在实践中不总是可靠。
  • 【16】Swing: Short-cutting rings for higher bandwidth allreduce (De Sensi et al., NSDI 2024): 在1节、2.1节、4.1节、7节引用。与[12]类似，在4.1节中被提及为提供了实现参数选择指导的先前工作，但其模型可能不完全适用于动态环境。
  • 【18, 26, 61】Checkpointing and Failure Recovery Papers: 在8.2节引用，用以说明现代检查点技术已经非常高效，使得在线调优因失败而引入的检查点加载开销可以忽略不计。
  • 【40】Occl: a deadlock-free library for gpu collective communication (Pan et al., arXiv 2023): 在8.2节引用，作为相关研究，证实了调优NCCL参数可能导致任务失败（如死锁）的风险。
  • 【47】Taccl: Guiding collective algorithm synthesis using communication sketches (Shah et al., NSDI 2023): 在1节、2.1节、4.1节、7节引用。与[12]和[16]类似，在4.1节中被提及为提供了实现参数选择指导的先前工作，但可能存在局限性。
  • 【64】Afnfa: An approach to automate nccl configuration exploration (Wang et al., APNet 2023): 在1节、6.1节、7节、8.1节、8.2节多次引用，作为本文比较的主要基线系统（一个SOTA NCCL调优器）。实验结果表明AutoCCL在多种场景下优于AFNFA。讨论部分也分析了AFNFA的参数选择与AutoCCL的不同。