万卡AI集群故障治理：从ETTR量化到柠檬节点检测与自适应路由实战

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 故障分类与根因画像

我们将导致训练作业失败的中断事件分为几个大类：

1. 节点级硬件故障：这是最经典的故障类型。包括GPU的XID错误（通常与显存、电源或温度相关）、CPU/内存故障、电源单元问题、硬盘故障等。这类故障通常会导致整个服务器节点不可用，其上运行的所有作业任务都会失败。
2. 网络基础设施故障：在万卡集群中，InfiniBand或RoCE网络是训练的“大动脉”。链路的物理损坏、光模块故障、交换机端口异常、乃至固件bug都可能导致网络性能骤降或完全中断。由于分布式训练严重依赖All-Reduce等集合通信操作，网络抖动会直接导致NCCL超时，进而引发作业失败。
3. 软件与配置问题：驱动版本不匹配、内核崩溃、容器环境冲突、调度器配置错误等。这类问题有时具有隐蔽性，可能只在特定作业负载或版本组合下触发。
4. 资源竞争与干扰：在共享集群中，不同作业可能竞争同一节点的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个关键特征信号：

1. excl_jobid_count：有多少个不同的作业在提交时主动排除了该节点。这反映了用户的“民间智慧”，是强烈的负面信号。
2. xid_cnt：节点上报的GPU XID错误数量。这是GPU硬件故障的直接指示。
3. tickets：针对该节点创建的维修工单数量。
4. out_count：节点被管理员或自动化系统从调度池中移出的次数。
5. multi_node_node_fails：由该节点导致的多节点作业（跨多台服务器）失败次数。危害性最大。
6. single_node_node_fails：由该节点导致的单节点作业失败次数。
7. 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曲线分析来确定，平衡了检出率和误报率。一旦节点被标记为“柠檬节点”，自动化系统会执行以下操作：

1. 自动隔离：将该节点从Slurm等调度器的可用节点列表中drain，阻止新作业调度上去。
2. 触发深度诊断：启动一系列更耗时、侵入性的硬件诊断测试（如GPU显存压力测试、PCIe链路完整性测试、网络带宽压力测试）。
3. 生成维修工单：将诊断结果和节点标签推送给硬件运维团队，进行部件更换或下线维修。

实施效果：这套系统在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网络本身具备一些容错机制，例如SHIELD（Self-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并非没有代价，它需要交换机芯片支持更复杂的路由计算，并可能轻微增加延迟。我们的部署经验是：

1. 渐进式启用：先在非核心业务集群或单个Pod中启用，监控性能指标和稳定性，再逐步推广。
2. 监控关键指标：除了带宽，更要关注报文重传率、交换芯片缓存丢弃计数和链路误码率。AR应该能显著降低前两者。
3. 与上层协同：告知框架和算法团队网络具备了AR能力。在某些对延迟极度敏感的场景（如参数服务器架构中频繁的小规模All-Reduce），可以评估是否需做特定优化，但对我们主流的Transformer同步训练，收益是纯正向的。
4. 硬件兼容性：确保所有交换机、网卡的固件版本支持并优化了AR功能。

核心收获：网络层面的韧性（Resilience）与性能（Performance）同等重要。自适应路由这类技术，是将网络从“静态基础设施”转变为“动态可调资源”的关键一步。它不能防止硬件故障，但能极大程度地掩盖故障影响，为训练任务提供一个更稳定、可预测的网络平面。

5. 故障排查体系化：从NCCL超时到根因定位

即使拥有了健康检查和柠檬节点检测，复杂的分布式训练中依然会出现难以诊断的故障。其中，NCCL超时是最常见也最令人头疼的症状之一。它就像一个“发烧”，病因可能是网络硬件问题、GPU驱动僵死、甚至用户程序死锁。

5.1 构建分层诊断工具箱

我们建立了一套分层递进的诊断流程：

1. 第一层：基础设施健康快照。当作业失败时，自动化脚本立即收集故障时间点前后各节点的系统日志、dmesg、GPU状态、InfiniBand交换机计数器、以及Slurm作业记录。这有助于快速判断是否是集群范围的硬件或网络问题。
2. 第二层：NCCL通信矩阵分析。对于NCCL超时，我们开发了内部工具，分析作业内所有Rank（进程）在超时时刻的通信状态。理想情况下，所有Rank应处于相同的集合通信操作中。工具会找出“掉队”的Rank——那些没有进入或没有完成某个集合通信操作的进程。这些Rank所在的节点就是重点怀疑对象。
3. 第三层：深度硬件诊断与“黑匣子”。对于反复出现问题的节点或难以定位的偶发超时，我们采取了更深入的方案：
   • 增强型健康检查：在作业Prolog（开始前）和Epilog（结束后）运行更耗时的定制化测试，如GPU间P2P带宽测试、All-Reduce微基准测试，捕捉间歇性性能降级。
   • “飞行记录器”原型：借鉴了航空领域的思路，我们在PyTorch框架层面尝试了轻量级的通信事件记录。它会以极低开销持续记录每个Rank发起和完成集合通信的操作序列和时间戳。当发生超时，可以导出最后一段时间内的“飞行记录”，像看飞机黑匣子数据一样，精确还原死锁或卡顿发生前各Rank的执行轨迹，极大提升了诊断Bug（如集合通信顺序错乱）的效率。

5.2 典型故障排查案例

案例：幽灵般的间歇性NCCL超时

• 现象：某个4096卡任务每周会随机失败1-2次，报错NCCL timeout，但重提交又能成功。硬件健康检查无异常。
• 排查：
  1. 第一层快照显示，失败时刻集群无告警。
  2. 第二层通信矩阵分析发现，每次超时都有不同的少数几个Rank“掉队”，且这些Rank分布在不同的机架。
  3. 将问题缩小到网络。调取InfiniBand交换机的历史性能计数器，发现某台核心交换机的某个线卡端口，在故障时间点存在短暂的但极高的“本地拥塞丢弃”计数。
  4. 深入检查该线卡，发现是一个散热风扇间歇性降速，导致芯片温度周期性升高，触发了内部流控机制，造成微秒级的突发拥塞。这个时间窗口极短，传统监控未能捕获，但足以打乱严格的NCCL通信同步。
• 解决：更换故障风扇。同时，优化了交换机的温度监控告警阈值。

经验之谈：分布式训练的故障排查，必须建立全局的、时间同步的观测能力。单节点的日志毫无意义。你需要一个能够关联集群所有节点、网络设备、作业状态在同一毫秒级时间戳下的监控系统。此外，假设代码有Bug，但先证明基础设施没问题，是一个高效的排查心法。

6. 架构演进与未来展望

通过上述实践，我们将大规模AI集群的可靠性工程总结为三个层次的持续作战：预防（健康检查、柠檬检测）、容忍（自适应路由、快速检查点）、诊断（分层排查工具）。展望未来，我们认为可靠性优化将从“运维侧”的被动应对，更多地向“系统-算法”协同设计演进。

1. 调度器感知可靠性：当前的调度器（如Slurm）主要考虑资源约束和排队策略。未来的调度器应成为“可靠性感知”的。它需要知道节点的健康分数、网络链路的实时质量、甚至作业的容错能力（例如，某些算法对节点失效更鲁棒）。调度器可以主动将高价值、大规模的作业调度到最可靠的“岛屿”上，而将测试性、容错性强的作业调度到风险稍高的区域，实现集群整体效率和成功率的帕累托最优。

2. 框架原生容错与快速恢复：检查点和重启的开销仍然是ETTR提升的最大瓶颈。未来的训练框架需要：

   • 异步与增量检查点：将模型状态异步写入持久化存储，并与计算重叠，将开销从分钟级降至秒级。
   • 层级化恢复：不是每次故障都全集群重启。探索局部恢复（只重启故障节点）、滚动恢复等机制。
   • NCCL通信链路快速重建：优化集合通信库，使其在节点失效或网络重构后能极速重建通信组，避免漫长的初始化过程。

3. 算法与系统的协同设计：这是更前沿的方向。例如，探索异步训练算法，允许部分节点短暂落后，从而对瞬态故障更不敏感。或者，借鉴联邦学习的思想，设计能容忍跨集群网络不稳定性的训练范式。同时，新的编程模型（如Pathways）通过集中调度通信，可以从根源上避免因程序Bug导致的集合通信死锁，提升系统层面的可调试性。

运维万卡AI集群，是一场与熵增的永恒斗争。没有一劳永逸的银弹，只有通过持续的数据分析、精细的工程优化和深度的系统协同，才能在这片充满不确定性的硬件海洋中，为前沿AI研究筑起一条相对可靠的跑道。我们的经验表明，通过系统性的故障治理和韧性设计，将数千卡规模训练的ETTR提升并稳定在0.9以上是切实可行的。这场旅程的终点不是消除故障，而是构建一个即使内部故障不断，也能让训练任务“波澜不惊”地持续向前的强大系统。