【LLM】提升大规模并行训练效率的方法

一、结论写在前面

论文来自阿里巴巴。

论文标题：Boosting Large-scale Parallel Training Efficiency with C4: A Communication-Driven Approach

论文链接：​​https://arxiv.org/pdf/2406.04594​​

LLMs的出现促使了并行训练技术的采用，涉及部署数千个GPU来训练单一模型。不幸的是，论文发现当前的并行训练效率往往不理想，主要原因有两点。首先，硬件故障不可避免，导致训练任务中断。无法快速识别故障组件导致大量GPU资源的浪费。其次，由于GPU必须在参数同步完成后才能进入下一轮计算，网络拥堵会大大增加GPU的等待时间。

为应对这些挑战，本文引入了一种通信驱动的解决方案，即C4。C4的关键洞察有两方面。首先，在并行训练中，集体通信表现出周期性和同质性，因此任何异常肯定是由某种硬件故障引起的。利用这一特性，C4能快速识别故障组件，迅速隔离异常并重启任务，从而避免由于异常检测延迟造成的资源浪费。其次，集体通信的可预测通信模型，涉及少量大流量，使C4能有效执行流量规划，大幅减少网络拥堵。

C4已广泛应用于论文的生产系统中，将错误导致的开销减少了约30%，并对某些通信成本适中的应用提升了约15%的运行时性能。    

C4已在论文的AI训练集群中部署了六个月，现在为超过20个客户提供LLM训练服务。利用其自动错误检测和恢复系统，C4有效地消除了大多数错误引起的开销，通常占总时间的约30%。此外，C4减轻了与不平衡流量相关的通信成本。对于测试的应用程序，其通信成本适中，作业的吞吐量可以提高约15%。总体而言，这些改进使得集群计算效率从30%提升到45%。

二、论文的简单介绍

2.1 论文的背景

在生产AI集群中训练LLMs的一个关键挑战是GPU的有效利用率相对较低，这主要是由于以下两个原因。首先，由于最先进的CPU产品的高故障率[32, 34]，在整个训练生命周期中诊断系统错误消耗了大量时间。长时间的训练会话需要一个稳定的过程；然而，最新一代的GPU往往表现出高错误率，这可能是由于其快速发展、匆忙交付和增加的功耗所致。当在批量同步并行（BSP）模式下运行时，任何节点的错误都可能导致整个任务失败。这需要在重新启动任务之前花费大量时间进行系统诊断和节点隔离。

此外，调整这些模型的训练过程以达到最高效率是一项复杂的任务，其中通信成本是可扩展性的一个重要障碍。也就是说，GPU在等待集体操作结果时可能会在同步点经历延迟。目前的艺术状态建议管理网络流量以提高通信性能。然而，在共享物理集群上，多个租户同时运行并发训练作业增加了这些模式的复杂性，加剧了有效管理的困难。此外，下行的出现，这在大型系统中越来越常见，也削弱了先前流量工程策略的有效性。

本文提出了C4（Calibrating Collective Communication over Converged Ethernet，在融合以太网上校准集体通信），这是一个创新的系统，旨在释放大规模AI集群中大量协作GPU的计算能力。C4由两个子系统组成，包括C4D（C4诊断）和C4P（C4性能）。

•C4D旨在通过减少由不可纠正错误引起的停滞来提高训练稳定性。C4D通过实时自动检测系统错误、隔离故障节点并促进从上次检查点重新启动应用程序来实现这一点。    

•C4P旨在减少大规模训练集群内的集体通信成本。它通过将网络连接均匀分布在所有可用路径上，并根据实时网络条件动态调整每条路径上的负载来实现这一点。它解决的关键挑战包括管理并发作业和处理链路错误。

              图1. AI训练应用在其生命周期中可能出现的问题

2.2 论文的方法

这里将详细阐述论文的AI基础设施如何应对前面识别的两个基本挑战：确保稳定性和优化并行训练的性能。论文将解释系统架构选择背后的理由，论文所接受的折中方案，并深入分析论文遇到的具体技术难题。

2.2.1 并行训练的稳定性

随着任务扩展的趋势持续，论文必须通过两种策略来应对硬件故障：1) 降低硬件故障率；2) 系统性地容忍这些故障。第一种策略至关重要，但超出了本文的范围，论文简要提及温度控制是关键（要点1）。诸如动态电压和频率调整（DVFS）等方法有助于防止GPU过热，但可能会影响性能的一致性。论文通过更快的风扇和更好的空调改善了冷却系统，实现了成本影响最小的温度调节。

关于第二种策略，论文与相关团队合作尝试了多种解决方案。一般来说，传统的云应用采用在线容错解决方案。例如，它们通过使用冗余计算来容忍计算故障，通过纠删码（EC）和/或三副本技术提供高度可靠的存储，并通过多路径（双上行链路）策略忍受网络异常。

然而，对于高性能计算应用，目前主流的方法是使用离线容错技术。例如，应用程序定期保存检查点，当系统发生故障时，任务从上一个检查点重新启动。当然，在最后一个检查点和故障时间之间的所有计算将被丢弃。对于论文的大规模并行训练任务，论文采用了一种相对务实且混合的技术策略。

总体上，论文利用经过验证的云存储技术来确保可靠的数据存储，同时充分认识到计算和网络可能带来的单独挑战。论文与客户进行了深入讨论，并得到了一个关键信息，即底层系统不应在模型训练过程中引入任何不确定性（要点2）。因此，论文对于容错计算只有两种选择：要么执行在线冗余计算，要么准备备用资源以替换故障节点。考虑到GPU的高成本，使用备用资源进行容错比在线冗余更经济。因此，论文为每128台服务器上的1024个GPU分配了64个备用GPU，分布在8台服务器上，确保从这136台服务器池中任意128台服务器进行并行训练时具有相同的通信和性能。    

论文的方法：C4D。总之，论文系统的容错架构包括通过纠删码实现可靠的数据存储，通过双上行链路和多路径通信确保网络可靠性，以及通过检查点和冗余处理计算故障。该系统的核心是C4D（C4诊断）子系统，旨在快速检测硬件故障以实现及时的任务重启，如图3所示。

C4D利用了两个关键观察结果（要点-4：(1) 并行训练任务表现出规律且可预测的运行节奏，使论文能够精确识别异常行为；(2) 并行训练中的批量同步并行（BSP）执行模型需要定期同步点。这些同步点被用作测量异常的锚点。

基于上述观察，论文开发了C4D以促进在线故障检测。图4展示了C4D的关键要素，包括一个增强的集体通信库（CCL），一个中央C4D主节点，以及作为中介的C4a（C4代理）。论文选择使用增强的CCL，因为当前最先进的CCL，如NCCL [20]，缺乏对集体通信操作进行在线监控的能力。

                图3. 容错系统概览    

                图4. C4D的架构

C4D监控。图5展示了论文增强的四层CCL，类似于当代的CCL。论文对底部三层进行了扩展，以实现监控功能。通信层跟踪通信器ID、等级计数和等级分配。操作层监控集体操作类型、算法、数据类型、元素计数以及操作持续时间和计数。传输层收集连接的具体信息，如RDMA IP和QP号，以及消息统计数据，包括传输的计数、大小和持续时间。在运行时以低成本和高精度收集上述信息并非易事。为了精确监控通信内核的执行模式，论文改进了所有相关的CDUA内核，直接记录它们的开始和完成时间，因为CPU时间戳和CUDA事件对此目的无效或不准确。

C4D分析。基于上述收集的信息，论文可以检测到在论文的集群中频繁发生的四种常见类型的错误，即通信挂起、非通信挂起、通信缓慢和非通信缓慢。检测前两种错误类型相对容易，此处不作深入讨论，论文将重点放在识别缓慢综合症实例的更复杂任务上。

                图5. 增强型CCL    

图6展示了一个说明性的例子。工作者之间的通信延迟被映射到一个二维矩阵中，其中每个元素代表一对工作者之间的延迟，由其y坐标（源）和x坐标（目的地）标识。矩阵中的高值有助于识别慢速连接：单个高值点表示特定的连接瓶颈，一行高值表明源端存在问题，一列高值则指向目的地的问题。               

                图6. 通信缓慢的症状

2.2.2 并行训练的可扩展性

并行训练性能取决于单节点计算、数据访问和集体通信的效率。虽然单节点效率可以通过混合精度[35]和变换器引擎等优化提高，数据访问效率可以通过Alluxio等缓存机制提高，但本文重点关注集体通信效率，这是训练可扩展性的关键因素。

如果论文把网络带宽视为一种资源，优化集体通信性能相当于找到一种最佳的资源分配方法。实际上，集体通信可以看作是工作者之间一系列一对一通信的集合，如果包含归约操作，还可能涉及计算。因此，寻找最佳资源分配的问题可以分解为两个问题。首先，论文需要最小化每个一对一通信的资源需求。其次，论文需要以最小化总通信时间的方式将每个一对一通信映射到网络资源。

第一个问题并非本文关注的焦点，因此为了完整性，论文在此简要介绍。论文的网络实际上是一种分层拓扑，NVLINK构成第一层，不同服务器间的RDMA网络构成第二层。此外，论文利用了双上行链路技术，这不仅提高了网络可靠性，还允许增加交换机芯片的基数。显然，对于给定数量的端点和指定的网络拓扑，交换机基数越大，网络直径越小。其次，论文采用网络拓扑感知的调度技术，确保需要通信的两个等级在网络中尽可能接近。

论文的方法：C4P。为应对这一挑战，论文引入了C4P（C4性能）系统，该系统旨在减少不必要的通信成本。C4P通过以下方式优化并发作业和链路故障的通信：(1) 在任务启动时识别并避免故障链路，(2) 平衡RDMA QPs（即连接）跨路径以实现负载分配，以及(3) 动态适应QP工作负载以响应网络变化和流量冲突。本质上，C4P是一种流量工程技术，旨在通过调节网络内每个数据流的传输路径来最小化网络拥塞。    

C4P遵循C4D的软件架构，但存在关键差异，如图7所示。首先，C4P主节点作为多个作业或租户的控制中心，与专注于单一作业的C4D主节点不同。此外，C4P的CCL可以为通信中的工作者请求路径分配，而C4D的CCL收集监控数据。最后，C4P的主节点分配通信路径，而C4D的主节点处理故障检测和诊断。

论文采用路径探测进行精细化的流量工程。C4P首先隔离并丢弃叶节点与脊节点交换机之间的故障链路，构建一个健康链路网络。C4P主控通过每个叶节点交换机上随机选择的服务器执行全网状路径探测，识别并记录可靠路径。在连接建立时，CCL向C4P主控发起路径请求，主控通过指定RDMA连接的源端口来响应所选路径。主控确保来自同一NIC的流量在左右端口间平衡，禁止左端口到右端口的路径，反之亦然。               

                图7 展示了C4P的工作流程

C4P的部署方式与C4D相似，两者都被嵌入用户镜像中，以便与Kubernetes（K8s）集成。然而，一个显著的区别是，C4P主节点在系统全局层面运行，提供全局访问，而C4D主节点则扮演更局部化的角色，仅限于单个作业范围。为避免冗余，此处不再重复详细信息。    

2.3 论文的效果

2.3.1 设置

如表2所示，论文概述了操作集群的系统配置，从中收集了C4D的评估数据。另一方面，与C4P相关的评估是在该集群的一个子集上进行的。为了防止集群中其他正在进行的工作的干扰，并确保论文评估结果的完整性，论文分配了集群的一个特定部分作为受控测试环境。该测试床包括16个节点，配备总共128个GPU。所有节点都直接连接到8个专用叶交换机，确保论文的测试活动有一个专用的环境。

该高性能集群内的节点配备有8个NVIDIA H800 GPU和8个BlueField-3 NICs 。每个NIC提供两个物理200Gbps端口，这些端口被绑定以创建一个单一逻辑400Gbps端口。这些NIC集成到一个3级Clos网络[7]中，配置为Fat-Tree拓扑，超订率1:1，确保最佳性能和带宽分配。利用Broadcom的Trident4作为叶交换机和Tomahawk4作为脊交换机，集群能够支持超过10,000个GPU。在单个pod中，构成两级子网，它可以容纳512个GPU，展示了其广泛的扩展性。

C4D的有效性通过论文的一项真实世界LLM训练工作负载进行评估。该工作所使用的模型包含1750亿个参数。采用2400个GPU进行分布式训练，该模型从零开始完成一个完整的训练周期通常需要超过一个月的时间。相比之下，C4P的效率通过集体通信基准测试和三个代表性的语言模型（LM）训练任务进行评估。为了确保通信基准测试的评估结果公正，论文将其配置为使用基于环的算法。测试中涉及的模型的具体配置，如并行策略和零优化器级别，将在评估结果展示时详细说明。    

2.3.2 结果

2.3.2.1 C4D有效性的评估

论文审查了来自内部客户的一项工作的历史日志，包括其开始和终止时间戳，以及工作因某些原因成功或失败的情况。论文的主要关注点放在了一个需要2400个GPU并需要超过一个月时间来完成其模型训练过程的代表性工作上。如表3所示，论文比较了该工作在部署提出的容错系统之前（2023年6月）和之后（2023年12月）因错误导致的停机时间。数据清楚地表明，C4D的部署导致停机时间显著减少，大约减少了30倍，从31.19%下降到仅1.16%。

在2023年12月，尽管系统诊断仍然占据大部分停机时间，但其贡献相比以往减少了约27倍，略低于平均效率提升水平。C4D的部署显著加快了错误检测和故障组件定位的速度，将响应时间缩短至仅几十秒。然而，转向服务仍需额外几分钟来隔离受影响的节点并重启作业，表明仍有改进空间。导致停机的第二大原因是检查点后的持续时间。但随着更频繁的检查点采用，用户现在每10分钟可以保存一次检查点，因此检查点后的停机时间大幅减少了33倍。与作业重新初始化相关的成本保持不变，由于系统中最脆弱组件的识别和增强，平均错误率下降了3.33倍，从0.6%降至0.15%。    

深入分析诊断和隔离开销后，显而易见，大多数错误源于GPU缺陷，包括GPU ECC错误、NVLink错误和CUDA错误。在2023年6月，这些GPU相关问题占到了总停机时间的12.53%，约占整体开销的2/3。值得注意的是，到2023年12月，这些GPU相关错误的频率降低了3.2倍，相关时间开销更是大幅减少了41.8倍。这一显著改善归功于C4D处理这些特定类型错误的高效性，从而大幅降低了相应的开销。对于C4D仅能部分管理的其他类型错误，仍有显著改进。这些错误的频率降低了3.4倍，处理它们所花费的时间减少了16.5倍。这些数据突显了C4D对系统整体性能和可靠性的积极影响。

                  图8. 通过绑定端口间的平衡流量实现的改进    

平衡两个绑定物理端口之间的流量。当流量从构成单一绑定端口的两个不同物理端口分发时，存在两种流量可能被路由到接收端同一物理端口的情况，导致接收端两个物理端口之间的流量不平衡。通过采用C4P，论文可以为每个物理端口的流量指定专用路径，从而防止由这种不平衡引起的性能下降。没有C4P，大多数测试案例中的有效busbw低于240 Gbps，远低于网络的理想带宽（约360 Gbps）。然而，启用C4P后，有效busbw接近峰值360 Gbps，意味着性能提升了50%，展示了C4P在优化网络性能方面的实际益处。

在多个作业间平衡流量。为了展示C4P在缓解多个并发作业间的流量冲突中的有效性，论文进行了一项评估，涉及8个同时进行的allreduce基准测试应用。数据显示，所有任务在C4P实现全局流量工程的情况下，性能水平相似，接近该测试床上单个任务可达到的最大吞吐量。具体而言，这些任务的性能指标在353.86 Gbps至360.57 Gbps之间。相比之下，当未启用C4P时，任务间存在显著的性能下降和差异。性能最差的任务仅达到171.93 Gbps，而最佳任务达到263.27 Gbps。平均而言，C4P提升了系统总吞吐量70.3%。这一比较清楚地突显了C4P在带宽利用率和一致性方面带来的显著改进。    

图 9. 全局任务特征工程的有效性

                  图10 展示了每个绑定端口接收到的拥塞通知包（CNP)计数

在发送端，根据网络状况进行响应。如图10所示，每个绑定端口每秒大约接收15,000个拥塞通知包（CNPs），计数在12,500至17,500之间波动。CNP的到来会触发数据传输速率的限制。    

图11. 链路故障出现时的负载均衡效果

对动态链路故障的容忍度。全球流量工程的有效性依赖于底层网络条件的稳定性。一条故障的链路可能需要重新路由受影响的流，这可能导致网络内的流量分布不平衡，并否定全球流量工程的有效性。在这种情况下，负载均衡机制将发挥作用，调整每个流的负载，从而重新平衡网络流量。为了评估这一机制的有效性，论文在1:1超额订阅的网络中重复了之前的实验，并在实验期间故意停用了一条链路。为了获得任务的即时性能，而不是任务完成后平均值，论文改进了测试基准，以便在每次allreduce操作。    

评估结果如图11所示。尽管高频时间戳记录导致数据出现一些波动，论文仍能观察到启用动态负载均衡后系统吞吐量的显著提升。在未激活C4P负载均衡的测试中，给定任务的总线带宽大幅下降，数值在160 Gbps至220 Gbps之间，平均带宽为185.76 Gbps。相反，当启用C4P负载均衡时，观察到的总线带宽显著提高，范围在290 Gbps至335 Gbps之间，平均为301.46 Gbps。这一提升代表了训练过程中发生链路错误时62.3%的显著性能增益。注意，在8个上行链路中存在1个链路错误的情况下，理论理想性能将是原始性能的7/8，即315 Gbps。启用C4P所达到的性能发现与这一理想值非常接近。                 

图12. 有无负载均衡情况下交换机端口带宽的比较

为了展示C4P负载均衡如何提升系统吞吐量，论文收集了关于流量在每个端口分布的统计数据，如图12所示。在实施C4P流量工程后，所有上游端口在引入链路错误之前都显示出接近最优的带宽利用率。然而，链路错误的出现导致不同端口间的吞吐量出现显著差异。在没有C4P负载均衡的情况下，仅有三个端口的流量有所增加，表明原本指向故障链路的流量正被重新路由至这些端口。    

因此，这些拥堵端口内每个流可用的带宽减少，同一通信信道内流的性能也受到负面影响。结果，其他端口的带宽出现明显下降。相反，C4P负载均衡动态调整网络流量的分布，减轻拥堵流的负担，同时增加通过利用不足路径的流量。这一策略导致端口间的负载更加均衡，使得之前未充分利用的端口能够处理更多流量。因此，这一优化措施带来了系统吞吐量的整体提升。

实际工作中的性能提升。为了评估C4P在增强现实世界应用性能方面的效果，论文使用三个代表性的训练任务进行了测试：Jobl涉及使用Megatron框架训练一个GPT模型，结合了TP和DP策略进行分布式训练。该模型包含220亿个参数，TP和DP的大小分别设置为8和16。Job2训练一个包含70亿参数的Llama模型。对于此任务，使用了Deepspeed框架进行分布式训练，并激活了zero优化，训练仅利用了DP。Job3涉及训练一个包含1750亿参数的另一个GPT模型。该模型也是基于Megatron框架训练，使用了TP和PP策略。将TP和PP的大小都配置为8，有效地创建了2个DP组。                 

                  图13展示了实际工作中性能提升的情况

性能评估结果如图13所示。从图中可以明显看出，前两项工作在性能上有了显著提升。具体来说，Job1的吞吐量增加了15.95%，从74.82提升至86.76样本每秒。同样，Job2的性能也提升了14.1%，吞吐量从156.59增加到178.65样本每秒。相比之下，Job3的性能提升并不明显。论文的分析表明，性能提升的差异与训练步骤中通信时间的比例密切相关。对于前两项工作，通信开销占每次迭代时长的30%以上。然而，Job3设置了较高的梯度累积（GA）值16，这意味着参数更新每16步才发生一次。这种设置大大降低了相对通信成本，这也解释了Job3性能提升不明显的原因。    

本文转载自 ​​AI帝国​​，作者：无影寺