1. 项目概述当AI集群规模突破万卡我们如何与“故障”共舞在AI模型训练领域尤其是大语言模型LLM的训练我们正经历一场前所未有的“军备竞赛”。模型的参数量从百亿、千亿向万亿迈进训练所需的算力也从数百张GPU卡迅速膨胀到数千甚至上万张卡。我所在的团队负责运营两个代号为RSC-1和RSC-2的大规模研究集群它们承载着从计算机视觉、多模态到下一代语言模型的前沿探索。当你的训练任务需要调度4096甚至12288张A100/H800这样的顶级GPU并持续运行数周乃至数月时一个朴素但至关重要的问题就浮出水面如何保证这个庞然大物能稳定、高效地跑完整个训练流程这里的核心挑战不再是单机性能而是系统可靠性。在数千张卡、数百台服务器、复杂的InfiniBand网络构成的集群中硬件故障如GPU显存错误、电源问题、网络瞬断、软件栈冲突几乎成了“日常”。每一次故障都可能导致整个分布式训练任务中断需要从最近的检查点Checkpoint重启浪费宝贵的算力资源和研究员的时间。我们引入了一个关键指标来衡量这种影响预期训练时间比。这个指标直观地反映了基础设施可靠性对训练效率的“折扣”程度。一个理想的无故障集群其ETTR为1.0而在实际中由于排队等待资源、故障重启等因素ETTR往往小于1。我们的目标就是通过各种工程手段将这个比值尽可能推向1.0。本文将深入分享我们从故障分析到系统性优化的一线实战经验。我们将拆解大规模AI集群中故障的根源展示如何通过数据驱动的方法量化其影响并详细介绍我们落地的两项核心优化实践“柠檬节点”主动检测与隔离机制以及网络层面的自适应路由。这些并非纸上谈兵的理论而是经过数千卡规模、数月生产环境验证的工程方案希望能为同行在构建和运维超大规模训练设施时提供切实的参考。2. 核心挑战与量化分析故障如何“吞噬”算力在深入技术方案之前我们必须先理解敌人——故障。在大规模集群中故障不是“是否发生”的问题而是“何时发生”以及“影响多大”的问题。我们的分析基于对RSC-1和RSC-2集群长达数月的生产数据监控。2.1 故障分类与根因画像我们将导致训练作业失败的中断事件分为几个大类节点级硬件故障这是最经典的故障类型。包括GPU的XID错误通常与显存、电源或温度相关、CPU/内存故障、电源单元问题、硬盘故障等。这类故障通常会导致整个服务器节点不可用其上运行的所有作业任务都会失败。网络基础设施故障在万卡集群中InfiniBand或RoCE网络是训练的“大动脉”。链路的物理损坏、光模块故障、交换机端口异常、乃至固件bug都可能导致网络性能骤降或完全中断。由于分布式训练严重依赖All-Reduce等集合通信操作网络抖动会直接导致NCCL超时进而引发作业失败。软件与配置问题驱动版本不匹配、内核崩溃、容器环境冲突、调度器配置错误等。这类问题有时具有隐蔽性可能只在特定作业负载或版本组合下触发。资源竞争与干扰在共享集群中不同作业可能竞争同一节点的CPU、内存或网络带宽导致性能不稳定极端情况下引发OOM或超时。通过对历史故障工单和系统日志的分析我们绘制了故障根因的分布图。一个有趣的发现是GPU相关故障包括GPU本身和其相关的PCIe、电源问题占据了硬件故障的相当大比例这与GPU作为核心计算单元承受高负载的特性相符。同时网络相关故障虽然单次影响范围可能不如节点宕机但其发生频率和对训练稳定性的“慢性”影响不容小觑。2.2 ETTR衡量可靠性的黄金指标为了量化故障对训练任务的影响我们采用了预期训练时间比这一指标。其基本思想是比较一个训练任务在理想无故障环境下的完成时间与实际在可能发生故障的环境下的期望完成时间。一个简化的模型如下假设一个任务总计算量为T我们每隔C时间保存一次检查点。每次保存检查点需要开销δ每次故障后重启任务需要开销R。如果集群的故障率如平均无故障时间MTTF已知那么存在一个理论上的最优检查点间隔C*使得任务的总期望完成时间最短。ETTR 就是T / E[总完成时间]。我们利用Daly-Young最优检查点间隔公式进行估算并结合集群实际的作业排队时间、故障率数据进行预测。图9源于我们的内部数据分析展示了预测的ETTR与实际测量到的作业运行ETTR的对比。结果显示对于大多数作业规模预测与实测值吻合较好。但有两个关键发现规模不经济性超大规模作业如1024 GPU的实际ETTR有时比基于平均统计数据的预测值更差。这是因为大作业对故障更敏感——任何单点故障都可能导致整个万卡作业重启且大作业排队获取全部资源的时间窗口本身也增加了遭遇故障的概率。集群差异RSC-1的故障率显著高于RSC-2每千节点日故障数分别为6.50 vs 2.34。这直接体现在其大规模作业的ETTR更低上。我们推测这与两个集群承载的工作负载特性不同有关RSC-1的负载可能对GPU的压力更大。实操心得不要只关注平均故障率。必须按作业规模GPU数量和优先级维度来切分查看ETTR。一个对8卡小作业影响不大的故障率可能足以让一个4096卡的大作业难以完成。监控仪表盘必须支持这样的多维下钻分析。2.3 面向未来的压力测试万卡作业需要多可靠的集群我们进一步做了前瞻性分析如果一个研究任务需要动用集群三分之二的资源约12288张GPU为了达到可接受的ETTR例如≥0.9对集群可靠性和系统软件提出了怎样的要求我们绘制了如图10所示的等高线图横轴是集群故障率纵轴是检查点写入开销等高线是ETTR值。分析结论非常直观且具有挑战性路径一提升硬件可靠性。如果保持现有的检查点技术假设写入开销为5分钟那么RSC-1的故障率需要从6.50大幅降低到接近1每千节点日故障数这意味着硬件可靠性需要提升6倍以上这在工程上极其困难。路径二优化检查点性能。如果保持现有故障率不变那么检查点写入开销必须从分钟级降低到10秒级。这指向了异步检查点、存储I/O优化、分层检查点等技术。核心洞见对于万卡规模的训练单纯依赖硬件可靠性的边际效益已很低且成本高昂。系统软件层面的优化特别是极速检查点/恢复技术将成为提升超大规模训练可行性的关键杠杆。这要求存储网络、检查点格式、框架保存/加载逻辑的全栈协同优化。3. 实战优化一主动狩猎——“柠檬节点”检测与隔离系统在运维中我们发现一个棘手现象某些节点似乎“天生倒霉”故障率显著高于集群平均水平。这些节点可能由于硬件老化、隐性缺陷如某个内存通道不稳定或难以复现的固件/驱动兼容性问题导致其上运行的作业失败概率异常高。我们称其为“柠檬节点”。依赖用户手动报告或等健康检查Health Check在作业运行时触发效率太低且会持续浪费算力资源。3.1 从被动响应到主动预测传统的健康检查是在作业调度到节点前或运行时定期执行用于发现节点的即时故障状态如网络不通、硬盘满。但“柠檬节点”可能大部分时间通过健康检查却在特定高负载下才暴露问题。因此我们需要一个基于历史故障数据的预测系统。我们设计了一个柠檬节点检测流水线其核心是构建一个特征工程体系从海量作业历史日志、节点事件日志、硬件监控数据中提取与节点“劣质”程度相关的信号。经过分析和验证我们筛选出以下7个关键特征信号excl_jobid_count有多少个不同的作业在提交时主动排除了该节点。这反映了用户的“民间智慧”是强烈的负面信号。xid_cnt节点上报的GPU XID错误数量。这是GPU硬件故障的直接指示。tickets针对该节点创建的维修工单数量。out_count节点被管理员或自动化系统从调度池中移出的次数。multi_node_node_fails由该节点导致的多节点作业跨多台服务器失败次数。危害性最大。single_node_node_fails由该节点导致的单节点作业失败次数。single_node_node_failure_rate该节点上单节点作业的失败率。我们收集了RSC-1集群28天的数据绘制了这些特征的累积分布函数图。从图11数据分析可视化结果可以清晰看到除了excl_jobid_count很多节点都被个别作业排除过区分度不高其他故障相关特征在节点间呈现明显的长尾分布——即大部分节点特征值很低少数节点特征值异常高。这正是“柠檬节点”的典型特征。3.2 检测策略与工程落地我们采用了基于阈值的规则系统作为第一版实现主要出于可解释性和快速迭代的考虑。例如规则A如果multi_node_node_fails 2且xid_cnt 5则标记为柠檬节点。规则B如果single_node_node_failure_rate 20%且最近7天内有故障则标记。这些阈值通过对历史数据的ROC曲线分析来确定平衡了检出率和误报率。一旦节点被标记为“柠檬节点”自动化系统会执行以下操作自动隔离将该节点从Slurm等调度器的可用节点列表中drain阻止新作业调度上去。触发深度诊断启动一系列更耗时、侵入性的硬件诊断测试如GPU显存压力测试、PCIe链路完整性测试、网络带宽压力测试。生成维修工单将诊断结果和节点标签推送给硬件运维团队进行部件更换或下线维修。实施效果这套系统在RSC-1和RSC-2集群中成功识别出40个问题节点占RSC-1节点数的1.2%却影响了13%的日常作业。最关键的是在部署该机制后大规模作业512 GPU的失败率从14%下降到了4%降幅超过70%对提升超大作业的完成率起到了决定性作用。踩坑记录与技巧数据时效性特征计算的时间窗口很重要。太短如1天噪声大太长如90天则响应迟钝。我们最终采用“28天滚动窗口近7天加权”的策略。避免“误杀”有些节点故障率高是因为它总被分配高负载、易出错的实验性任务。我们通过加入“作业类型”和“用户组”作为上下文特征部分缓解了这个问题。更高级的版本可以引入因果推断模型。与调度器联动简单的drain可能造成资源碎片。更好的做法是与调度器深度集成让调度器知晓节点的“风险分数”在保证高优先级大作业成功率的提前下谨慎地将低优先级或容错性强的作业调度到“亚健康”节点上提高整体利用率。4. 实战优化二动态绕行——网络自适应路由AR实践网络是分布式训练的神经系统。我们观察到InfiniBand网络的链路错误是导致NCCL超时和作业失败的另一个主要因素。这些错误可能源于物理连接松动、光模块劣化、交换机端口芯片问题等。等待硬件更换周期长且在大规模集群中频繁插拔硬件本身会引入风险。4.1 超越静态路由与基础容错InfiniBand网络本身具备一些容错机制例如SHIELDSelf-Healing Interconnect技术可以在检测到链路故障后由交换机协同计算新的路由表绕过故障链路。然而我们发现这种机制有时过于“保守”。一条链路可能没有完全中断但误码率很高导致数据包重传带宽急剧下降。在RSC-1集群上线初期我们曾观察到某些链路问题导致整体带宽损失高达50-75%而SHIELD可能并未将其标记为故障。为此我们启用了更先进的自适应路由功能。AR允许交换机根据实时网络状况如端口拥塞程度、链路误码率动态地为每个数据包选择输出端口而不是遵循静态的固定路径。4.2 AR效果实测从带宽恢复到抗干扰我们设计了两组实验来验证AR的效果实验一模拟链路错误下的恢复能力我们使用mlxreg工具在实验环境中人为地向特定InfiniBand端口注入比特错误BER模拟链路劣化。然后我们在一个512 GPU的子集上运行NCCL All-Reduce基准测试分别开启和关闭AR。结果如图12a所示在没有AR的情况下存在错误链路的路径带宽急剧下降。而开启AR后交换机感知到该链路质量差自动将流量动态分配到其他健康路径上从而维持了接近线速的高带宽。AR就像一个智能交通导航系统在发现某条道路拥堵或损坏时立即将车辆引导至其他通畅路线。实验二多任务竞争下的性能稳定性在实际集群中多个训练任务同时运行是常态它们会竞争网络带宽。我们模拟了这种场景同时启动64个独立的NCCL All-Reduce任务组每组16 GPU让它们同时运行制造网络拥塞。结果如图12b所示在没有AR的情况下不同任务组获得的带宽波动很大有些组因为“运气不好”其通信路径经过拥塞链路性能很差。而开启AR后所有任务组的带宽都更加稳定和均衡且整体平均带宽更高。这是因为AR实现了流量的动态负载均衡避免了热点链路的产生。4.3 部署注意事项与调优启用AR并非没有代价它需要交换机芯片支持更复杂的路由计算并可能轻微增加延迟。我们的部署经验是渐进式启用先在非核心业务集群或单个Pod中启用监控性能指标和稳定性再逐步推广。监控关键指标除了带宽更要关注报文重传率、交换芯片缓存丢弃计数和链路误码率。AR应该能显著降低前两者。与上层协同告知框架和算法团队网络具备了AR能力。在某些对延迟极度敏感的场景如参数服务器架构中频繁的小规模All-Reduce可以评估是否需做特定优化但对我们主流的Transformer同步训练收益是纯正向的。硬件兼容性确保所有交换机、网卡的固件版本支持并优化了AR功能。核心收获网络层面的韧性Resilience与性能Performance同等重要。自适应路由这类技术是将网络从“静态基础设施”转变为“动态可调资源”的关键一步。它不能防止硬件故障但能极大程度地掩盖故障影响为训练任务提供一个更稳定、可预测的网络平面。5. 故障排查体系化从NCCL超时到根因定位即使拥有了健康检查和柠檬节点检测复杂的分布式训练中依然会出现难以诊断的故障。其中NCCL超时是最常见也最令人头疼的症状之一。它就像一个“发烧”病因可能是网络硬件问题、GPU驱动僵死、甚至用户程序死锁。5.1 构建分层诊断工具箱我们建立了一套分层递进的诊断流程第一层基础设施健康快照。当作业失败时自动化脚本立即收集故障时间点前后各节点的系统日志、dmesg、GPU状态、InfiniBand交换机计数器、以及Slurm作业记录。这有助于快速判断是否是集群范围的硬件或网络问题。第二层NCCL通信矩阵分析。对于NCCL超时我们开发了内部工具分析作业内所有Rank进程在超时时刻的通信状态。理想情况下所有Rank应处于相同的集合通信操作中。工具会找出“掉队”的Rank——那些没有进入或没有完成某个集合通信操作的进程。这些Rank所在的节点就是重点怀疑对象。第三层深度硬件诊断与“黑匣子”。对于反复出现问题的节点或难以定位的偶发超时我们采取了更深入的方案增强型健康检查在作业Prolog开始前和Epilog结束后运行更耗时的定制化测试如GPU间P2P带宽测试、All-Reduce微基准测试捕捉间歇性性能降级。“飞行记录器”原型借鉴了航空领域的思路我们在PyTorch框架层面尝试了轻量级的通信事件记录。它会以极低开销持续记录每个Rank发起和完成集合通信的操作序列和时间戳。当发生超时可以导出最后一段时间内的“飞行记录”像看飞机黑匣子数据一样精确还原死锁或卡顿发生前各Rank的执行轨迹极大提升了诊断Bug如集合通信顺序错乱的效率。5.2 典型故障排查案例案例幽灵般的间歇性NCCL超时现象某个4096卡任务每周会随机失败1-2次报错NCCL timeout但重提交又能成功。硬件健康检查无异常。排查第一层快照显示失败时刻集群无告警。第二层通信矩阵分析发现每次超时都有不同的少数几个Rank“掉队”且这些Rank分布在不同的机架。将问题缩小到网络。调取InfiniBand交换机的历史性能计数器发现某台核心交换机的某个线卡端口在故障时间点存在短暂的但极高的“本地拥塞丢弃”计数。深入检查该线卡发现是一个散热风扇间歇性降速导致芯片温度周期性升高触发了内部流控机制造成微秒级的突发拥塞。这个时间窗口极短传统监控未能捕获但足以打乱严格的NCCL通信同步。解决更换故障风扇。同时优化了交换机的温度监控告警阈值。经验之谈分布式训练的故障排查必须建立全局的、时间同步的观测能力。单节点的日志毫无意义。你需要一个能够关联集群所有节点、网络设备、作业状态在同一毫秒级时间戳下的监控系统。此外假设代码有Bug但先证明基础设施没问题是一个高效的排查心法。6. 架构演进与未来展望通过上述实践我们将大规模AI集群的可靠性工程总结为三个层次的持续作战预防健康检查、柠檬检测、容忍自适应路由、快速检查点、诊断分层排查工具。展望未来我们认为可靠性优化将从“运维侧”的被动应对更多地向“系统-算法”协同设计演进。调度器感知可靠性当前的调度器如Slurm主要考虑资源约束和排队策略。未来的调度器应成为“可靠性感知”的。它需要知道节点的健康分数、网络链路的实时质量、甚至作业的容错能力例如某些算法对节点失效更鲁棒。调度器可以主动将高价值、大规模的作业调度到最可靠的“岛屿”上而将测试性、容错性强的作业调度到风险稍高的区域实现集群整体效率和成功率的帕累托最优。框架原生容错与快速恢复检查点和重启的开销仍然是ETTR提升的最大瓶颈。未来的训练框架需要异步与增量检查点将模型状态异步写入持久化存储并与计算重叠将开销从分钟级降至秒级。层级化恢复不是每次故障都全集群重启。探索局部恢复只重启故障节点、滚动恢复等机制。NCCL通信链路快速重建优化集合通信库使其在节点失效或网络重构后能极速重建通信组避免漫长的初始化过程。算法与系统的协同设计这是更前沿的方向。例如探索异步训练算法允许部分节点短暂落后从而对瞬态故障更不敏感。或者借鉴联邦学习的思想设计能容忍跨集群网络不稳定性的训练范式。同时新的编程模型如Pathways通过集中调度通信可以从根源上避免因程序Bug导致的集合通信死锁提升系统层面的可调试性。运维万卡AI集群是一场与熵增的永恒斗争。没有一劳永逸的银弹只有通过持续的数据分析、精细的工程优化和深度的系统协同才能在这片充满不确定性的硬件海洋中为前沿AI研究筑起一条相对可靠的跑道。我们的经验表明通过系统性的故障治理和韧性设计将数千卡规模训练的ETTR提升并稳定在0.9以上是切实可行的。这场旅程的终点不是消除故障而是构建一个即使内部故障不断也能让训练任务“波澜不惊”地持续向前的强大系统。
