摘要
在运行大规模机器学习（ML）基础设施时，可靠性是一个关键挑战，尤其随着ML模型和训练集群规模的不断扩大，这一问题愈发突出。尽管已有数十年的基础设施故障研究，但不同规模下作业失败的影响仍不明确。本文分享了管理两个大型多租户ML集群的经验，提供了量化分析、运营经验以及我们在理解和解决大规模可靠性问题方面的视角。我们的分析显示，尽管大型作业最容易受到故障影响，但小型作业在集群中占多数，因此应被纳入优化目标中。我们还识别了关键的工作负载特性，并在不同集群中进行比较，展示了大规模ML训练所需的核心可靠性要求。我们提出了一套故障分类体系及关键可靠性指标，分析了两个最先进ML环境中11个月的运行数据，这些环境总共涵盖了超过1.5亿小时的A100 GPU使用时间和400万个作业。基于这些数据，我们构建了故障模型，预测了不同GPU规模下的平均故障间隔时间（MTTF）。
此外，我们还提出了一种方法来估算相关指标——有效训练时间比率，并用该模型来评估在大规模环境下潜在的软件缓解措施的效果。我们的研究为提升AI超级计算集群的可靠性提供了宝贵的洞见，并指明了未来的研究方向，强调了灵活、与工作负载无关且具备可靠性意识的基础设施、系统软件和算法的必要性。本节将深入探讨我们为提升集群可靠性所采取的改进措施。健康检查只是这些措施中的一项，它在检测随机节点故障方面表现尤为出色。然而，故障可能与某些特定节点紧密相关，我们称之为“柠檬节点”，这可能是由于配置错误、部件老化或硬件缺陷造成的。因此，我们可以将健康检查机制进行扩展，以便发现频繁出现问题的节点（参见第IV-A节）。
此外，我们还将在服务器范围之外实施改进措施，纳入网络层面的缓解策略，以应对网络路由不稳定的情况（参见第IV-B节）。最后，我们将阐述集群设计以及工作负载本身是如何对集群性能指标产生影响的。
尽管健康检查为防范同一故障导致多个作业失败提供了初步保障，但在实际运用中，我们发现某些节点的作业失败率高于平均水平。由于这些失败率与特定节点相关联，我们推测可能是硬件退化或节点运行了配置错误的软件。遗憾的是，要快速找到这类节点并不容易，因为需要长时间观察它们的失败行为以获得具有统计意义的结果。更糟糕的是，这些节点在失败后仍会继续吸引新的作业，最终导致作业失败并降低整体有效训练时间比（ETTR）。本节将概述我们如何建立这一检测流程。在训练集群中，由于不同硬件组件的瞬时或永久故障，研究人员通常会根据以往经验手动排除导致作业失败的节点。然而，这种做法既不可扩展，又可能导致容量不足。若过度排除节点，还可能引发容量饥荒。为提高有效训练时间比率，我们设计了问题节点检测机制，以便主动识别、隔离并从机器学习作业调度器（如Slurm）中替换柠檬节点。柠檬节点是指导致作业反复失败但无法通过现有机制（如健康检查和修复流程）识别的服务器。如前文第三节所述，导致训练作业失败的最重要因素之一是NODE_FAIL，这凸显了主动处理问题节点的重要性。柠檬节点检测信号：在每个节点上可用的数十个检测信号中，以下信号与柠檬节点的相关性最高：1. excl_jobid_count：排除节点的不同作业数量；2. xid_cnt：节点遇到的唯一XID错误数量；3. tickets：为节点创建的修复工单数量；4. out_count：节点从调度器中移出不可用的次数；5. multi_node_node_fails：由节点导致的多节点作业失败数量；6. single_node_node_fails：由节点导致的单节点作业失败数量；7. single_node_node_failure_rate：节点上单节点作业失败的比率。我们可以将这些信号视为二元分类模型的潜在特征，尽管我们报告的结果是基于预测问题节点的准确性和误报率手动调整的。
图11展示了基于RSC-1的28天数据快照的信号分布，我们使用该数据来设置检测标准的阈值。x轴表示每个GPU节点上信号的出现次数，从0到1进行归一化处理。y轴表示经历每个信号的GPU节点的累积和归一化数量。我们发现，用户报告的excl_jobid_count信号与节点失败的相关性不强，但仍有大量节点被至少一个作业排除。这促使我们主动检测问题节点，而不是将检测负担留给机器学习开发人员。在识别出的问题节点中，超过85%的节点在测试中失败。这些失败在表II中进行了分类。我们设计、实现并评估了问题节点检测机制，成功识别出RSC-1（24个节点）和RSC-2（16个节点）中的40个故障节点，准确率超过85%。识别出的问题节点占RSC-1足迹的1.2%、日常作业的13%和RSC-2足迹的1.7%。我们的问题节点检测机制使大型作业（512个及以上GPU）的失败率降低了10%，从14%降至4%。观察11：历史数据对于发现故障节点至关重要。实施柠檬节点（即故障节点）检测可以提高大型作业完成率30%以上。
故障特征分析揭示了Infiniband链路错误引发的故障的重要性。正如服务器可能在不同阶段发生故障，对于短暂或永久性能下降的组件，网络链路也可能因物理或电气特性的变化而表现出类似的行为。大规模高度并行模型训练不可避免地会遇到故障网络链路。这些链路可能具有高错误率、在上下状态之间波动的行为、永久断开状态或在多租户环境中高度拥塞。所有这些都会导致网络架构中的通信性能下降。大规模物理链路更换十分繁琐。因此，Infiniband网络架构配备了交换机级别的技术来容忍链路问题。其中一种称为SHIELD[11]的自愈功能允许交换机围绕故障链路进行协调。然而，即使启用了此功能，将链路视为断开的阈值也可能过于保守，导致协议层面的重传以及可能的网络性能下降。特别是在RSC-1的启动阶段，我们观察到带宽损失高达50%-75%。另一种更高级的功能是自适应路由（AR），它根据实时网络条件动态调整路由决策。AR在所有网络链路之间平衡流量，并提高链路总体利用率。通过允许数据包避开拥塞区域和不健康链路，自适应路由提高了网络资源的利用率和效率。因此，由网络问题引起的训练作业性能差异得以减少。我们在集群中启用了AR，以提高性能的可预测性。
为了展示AR在我们集群中的重要性，我们进行了两个实验。在第一个实验中，我们使用mlxreg工具修改网络架构中的端口寄存器，从而在架构中引入了位错误率（BER）。然后，我们在512个GPU上运行了NCCL-Tests[6]中的All-Reduce基准测试，比较了启用和未启用AR时的性能。图12a的结果显示，在链路错误的情况下，AR能够维持更高的带宽。在第二个实验中，我们在64个节点上同时运行了多轮NCCL-Tests中的All-Reduce测试，每组两个节点（16个GPU），以展示AR在争用情况下的表现。图12b显示，当网络架构中充斥着多个NCCL环时，使用AR时的性能差异更小，且AR能够实现更高的性能。这是因为AR可以使GPU免受拥塞链路的瓶颈影响。通过启用交换机根据端口负载选择输出端口，故障链路对网络架构的影响被分散到各个作业中，而不是仅惩罚那些恰好被映射到故障链路上的训练作业。观察12：网络必须移除并绕过故障。如果没有韧性机制，可能会损失超过50%的带宽。5. 关键教训与研究机遇
在分享了我们运营和优化集群的经验后，我们看到了提升可靠性、管理日益复杂的基础设施以及与框架和算法共同设计解决方案的多个机遇。训练可靠性：我们展示了如何通过运行健康检查和历史分析来发现影响可靠计算的瞬时故障，以及柠檬节点（即故障节点），其移除可提升大型作业完成率30%以上。展望未来，我们认为向调度器和分布式算法进一步暴露可靠性信息具有重大机遇，以便对工作进行划分，从而最大化可靠性或吞吐量。此外，我们还注意到，网络架构本身在韧性方面存在潜在改进空间，例如，能够重新配置其拓扑结构以绕过故障，这与我们在自适应路由（第IV-B节）中所述的精神相似。因此，我们设想未来的基础设施系统将致力于让不可靠性变得不那么明显，而不是试图完全消除它。当未来的GPU系统（如NVIDIA GB200[8]）将修复单位从服务器变为机架时，我们认为可能需要重新思考整个系统，以通过应对故障来避免停机时间。更接近应用层面的是，训练作业的有效训练时间比（ETTR）是故障相关延迟开销的函数。提高ETTR的有效方法是除了降低重启概率本身外，还要最小化重启延迟成本。如先前工作[25]所观察，某些操作（如NCCL初始化）在GPU节点数量增加时扩展性较差。因此，展望未来，未来软件系统支持快速且可靠的例程以优化重启延迟成本至关重要。我们预计，完全替换类似MPI的集体操作以及提高飞行前硬件测试效率将成为未来关键途径。调试工具：一旦通过健康检查消除了许多重大故障，剩余的故障通常表现为近端故障，这些故障不会立即表明根本原因。NCCL超时是故障最常见的症状之一，其根本原因可能是网络基础设施、存在错误的模型代码或其他卡死的组件。定期检查硬件基础设施健康（第II-C节）可通过在NCCL内核卡死之前主动发现故障网络或硬件问题，从而降低NCCL超时的频率，但确定剩余超时的根本原因将导致新的健康检查或错误修复。我们可以通过跨参与集体操作的不同等级比较日志数据，追溯确定NCCL超时的根本原因，从而提高训练运行的成功率。例如，通过记录哪个等级启动了每个集体操作以及集体操作之间的依赖关系，我们可以找到某些等级启动了集体操作而其他等级未启动的第一个集体操作，并进一步调查缺失的等级。如果所有等级都进入了集体操作但未退出，我们可以检查集体操作内的网络流量，以确定哪个组件未发送或未接收预期消息。从未来的运行中移除有问题的等级或网络组件将降低这些运行遇到相同问题的可能性。高效且可靠的大规模分布式训练需要更好的诊断和调试工具。可以想象扩展现有的管理工具，如IPMI[23]，以在带外网络中提供机器调试信息，并缩小归因差距。编程模型：诊断NCCL超时的另一个混淆因素是PyTorch中实现的单程序多数据（SPMD）编程模型。如果不同的等级意外地以错误顺序发出集体操作（如all-reduce），作业将陷入死锁，从而导致NCCL超时。因此，调试NCCL超时首先应从确定训练脚本是否存在错误开始，这为追踪基础设施不稳定性增加了混淆因素。动态检测错误程序并引发异常而不是陷入死锁将提高稳定性。或者，可以旨在完全消除不匹配集体操作的可能性。例如，Pathways[14]引入了一个单点来调度通信，确保每台机器一致地调度通信。6. 相关工作
机器学习基础设施：随着对机器学习（ML）兴趣的不断增长，人们开始研究ML集群的基础设施故障以及调度器效应[24]、[31]。这包括从作业规模到故障特性等方面的分析，主要关注最大作业规模，其规模可达数十个GPU。IBM的AI基础设施和故障分类法在[18]中有所介绍——我们提供了一个类似动机的分类法，并详细量化了故障情况。Meta的生产调度器MAST的设计与运行也于近期得到了研究[15]，该研究证明了数据中心级负载均衡的必要性。大型语言模型（LLM）的兴起最近推动了一系列专门关注ML训练可靠性的研究工作[17]、[25]、[33]，这些研究假设的规模比以往通用ML实验中的规模要大几个数量级。我们的工作独具特色，因为我们的集群在规模和模型架构多样性方面既服务于小型作业也服务于大型作业，并且是在集群级研究环境中进行的。
模型-系统协同设计：已经开发出了针对LLM的并行化技术，如Megatron-LM[39]，这些技术自然地将数据和模型并行性映射到常见的网络拓扑结构中[44]。在Megascale[25]中研究了字节跳动LLM的故障及其缓解措施。在Unicron[21]中对阿里巴巴的训练系统进行了类似的研究，并提出了一种专用的HPN网络来缓解与网络相关的故障[36]。Llama 3也展示了软硬件协同设计在提高韧性方面的益处[33]。此外，对于其他大型深度学习模型的开发，也探索了容错和韧性训练[32]、[46]。虽然我们的工作同样关注模型训练韧性和通用集群可靠性，但我们的经验是独一无二的，因为我们同时在规模的两端运作，这促使我们提出了既实用又能以黑盒方式部署的解决方案，同时这些方案在四千个GPU的规模上经过了实战检验。最后，我们的工作负载是多样化的[16]、[28]、[34]、[38]、[41]、[43]，涵盖了视觉、语言和混合模态模型，且处于快速发展的研究环境中。7. 结论
我们分享了在运营两个大规模ML研究集群方面的经验。我们的分析表明，最先进的研究集群的运行规模比以往展示的要大几个数量级，这促使我们更加关注大规模性能和可靠性。本文采用数据驱动的方法来量化和缓解从硬件到系统软件再到框架级韧性改进等方面的故障影响。
粤ICP备17114055号
支持私有云部署
