1. AI训练稳定性的演进历程
2012年ImageNet竞赛中AlexNet的横空出世，开启了现代AI发展的新纪元。彼时我们不会想到，十年后支撑AI训练的GPU集群会从研究室里的几台服务器，发展成需要专门供电系统的万卡级计算矩阵。在这个算力爆发式增长的过程中，训练系统的稳定性管理正经历着从「简单运维」到「精密工程」的深刻变革。
1.1.早期的小模型时代：手动运维的黄金年代
2022年之前的AI训练，更像是手工作坊式的精雕细琢。大多数训练任务只需十几块GPU，利用PyTorch或TensorFlow的数据并行功能就能轻松应对。记得那时算法工程师们有个共识：如果训练遇到问题，重启往往比排查更高效。
当时我们构建的监控系统就像汽车仪表盘，只能显示最基本的任务状态。当训练意外中断时，工程师们会像侦探一样翻查日志——如果发现是GPU报错，就联系运维同事。运维人员则带着「NVIDIA三件套」（nvidia-smi、dcgm、nsys）到机房巡检，像老中医把脉般通过温度、功耗等指标判断硬件状态。这种工作模式虽简单，但应对数十卡规模的集群还算游刃有余。
1.2.大模型风暴：从量变到质变的冲击
ChatGPT的登场如同打开潘多拉魔盒，将AI训练带入新的纪元。当我们开始部署千卡/万卡集群时，才发现原有的运维体系就像用小渔网捕鲸鱼——完全无法匹配新需求。
让我们通过百度百舸经历过的一个真实案例来深入理解这个问题：
2024年初，百度百舸帮助一家AIGC创业公司迅速将其训练规模从百卡扩展到千卡级别。然而在训练数天后的某个周末凌晨，训练进程意外发生了hang死。由于当时缺乏有效的故障感知和容错机制，直到第二天算法工程师发现任务超时退出时，已经耽误了数小时宝贵的训练时间。更糟糕的是，任务日志中除了简单的timeout报错外毫无线索，平台监控也显示所有训练节点状态正常。
着急恢复训练的算法工程师没有立即上报问题，而是选择直接重新提交任务。但不幸的是，新任务运行数小时后再次出现相同的超时退出。这时他们才不得不寻求技术支持，但值班工程师面对这种任务hang死的问题也缺乏诊断经验，只能通过二分法慢慢定位。最终发现是某个节点的静默故障（SDC）导致了训练进程假死。等问题得到解决时，距离首次故障已经过去将近30小时，这意味着损失了价值巨大的千卡算力资源。
2.百度百舸集群训练稳定性全景图
站在现在的时间点回望，AI训练稳定性已从辅助功能演变为核心基础设施。就像现代建筑中的抗震结构，它虽不直接参与空间构成，却是万丈高楼得以屹立的关键。当行业向着数万卡集群迈进时，这套隐形护甲的质量，将直接决定AI进化的速度与边界。
在2024年百度百舸对训练过程的生命周期进行了更细致的拆分，提出了「无效训练时间」这一关键指标，并致力于将其最小化。具体来说：
任务无效训练时间=故障中断次数×任务故障恢复时长+任务常态写Ckpt总时长
其中，任务故障恢复时长=故障感知召回耗时（自动/人工定位）+任务调度耗时+任务初始化耗时+任务重算时长。
通过这个公式可以看出，要降低无效训练时间，需要「围绕基础设施稳定性」、「任务容错」两个维度来系统展开，重点解决三个方面的问题：
- 提高基础设施的交付质量。
- 提高任务故障容错的召回率、准确率和时效性。
- 优化checkpoint机制，减少保存时间和恢复时的重算时间。
经过容错架构的整体变革，百度百舸形成了从「任务负载—框架—通信—基础架构」全链路的自动异常感知、诊断、恢复能力，可覆盖90%+的训练异常场景，时效性最快可以实现秒级异常感知、分钟级定位，以及平均3分钟的故障自愈能力。
3.基础设施交付质量保障
基础设施的交付质量保障是稳定性的基础。
CPU时代，机器的交付前可能仅会跑一些常规的CPU计算、网络的压力测试，并不会从业务视角去评估基础架构，机器交付后硬件异常的故障频率相对较少。有硬件故障时，通常走工单系统人工换机用户相对是可接受的。
而GPU时代，AI Infra的交付则需要考虑CPU、GPU、RDMA网络、存储，甚至机房的功率、温度等各方面因素，遗漏任何一个环节都会成为后续稳定性的隐患。在交付给客户后，机器也可能会由于长时间的高负载运行频繁出现硬件故障，而GPU机器的高昂成本，使客户对节点故障感知、换机的时效性提出了非常高的要求。
因此百度百舸对GPU机器交付前及交付后的稳定性质量进行了系统性管理：
- 交付前，百度百舸会对机器进行200多项指标检测，然后进行48小时烤机，以及NCCL-Test的机内、机间的大环、同号卡通信性能基准测试，端到端的大模型训练、推理性能基准测试。
- 交付后，需要能够实时的感知节点故障及定期巡检，并具备分级处理的自愈能力，例如Error级别的故障实现自动排水、重启，Fault级别故障实现自动换机。
4.任务容错的准召率保障
任务层面稳定性最核心的就是做好容错，能够让业务在无论遇到何种故障时都能快速恢复。
那么，首要的工作就是我们能够准确的识别出异常，然后对故障进行诊断定位，最后能够自动化的从异常中恢复。
因此，任务容错需要能够从端侧（即每个训练worker）探测到进程与环境的各类异常，同时有个中心服务（Master）从任务全局的视角去诊断、定位异常，最终做出相应的决策来使任务能够快速从异常中恢复。
任务容错最重要的就是提升故障的召回率与准确率，即如何能够尽可能的准确识别、定位所有故障。我们将故障分类两类：显式故障和隐式故障。
- 显式的故障通常比较容易召回，我们将实践积累的各种进程异常状态及各类报错pattern形成专家知识库，再结合硬件感知服务（HAS Agent）的硬件全链路10秒级监控能力，可以实现显式故障的召回率达到95%+。
- 隐式的异常则往往很难轻易的识别，例如训练进程hang、慢节点就是典型的隐式故障，需要丰富的经验积累才能准确的识别出异常。
下面我们就以最典型的隐式故障场景——训练进程hang死为例，来看下如何能够做好hang自动感知、诊断。
4.1.训练hang的自动感知
训练任务发生hang之后，绝大多数情况都会以timeout的方式报错并退出进程，最常见的就是在通信过程中如果发生hang，NCCL的watchdog会中断通信，并有报如下timeout报错，然后再由pytorch的torchrun进程感知并中断训练过程。
[E ProcessGroupNCCL.cpp:828] [Rank 1] Watchdog caught collective operation timeout: WorkNCCL(SeqNum=15173, OpType=ALLREDUCE, Timeout(ms)=1800000) ran for 1802710 milliseconds before timing out.
[E ProcessGroupNCCL.cpp:828] [Rank 0] Watchdog caught collective operation timeout: WorkNCCL(SeqNum=15173, OpType=ALLREDUCE, Timeout(ms)=1800000) ran for 1802713 milliseconds before timing out.Pytorch默认为10分钟NCCL通信超时，而Megatron-LM为30分钟。在万卡规模训练场景中，意味着一万张卡要至少浪费30分钟才能被发现。这个时效性是不可接受的。而且当30分钟超时后程序会立马退出，很难有机会进行下一步定位，需要一些时效性更高的感知机制，并且在程序退出前获取一些有效信息供后续诊断分析。
很多公司、实验室在面对hang的问题时，会在采用框架层插桩的方式来trace训练进程，这种方式通常是比较直接且准确的，但是有比较强的侵入性，而且可能还会有一些性能开销。对于云厂商来说，需要寻找对用户更透明、更无损的方式来感知、定位hang异常。
如何感知训练hang，以百度百舸的产品设计思路为例，我们可以从以下几个方向去思考：
- 训练进程hang的最直观表现是什么？
- 人工判断一个任务是否hang了，最直接的方式就是看是否所有worker的任务日志一段时间内都不输出日志了，所以hang自动感知的第一种方法就是采集所有worker的日志，并判断所有worker日志中最后一行日志是否为x分钟前的（x小于Pytorch的通信超时时间，例如8分钟），如果是则基本可以判定为hang。
- 任务hang时进程有什么样的表现？
- 任务hang时，可能进程的调用栈都不在发生变化，进程的调用栈可以通过py-spy/pystack等工具进行探测，所以我们可以用此类工具对所有训练任务进行一个定时采样，当采集n个样本所有进程栈都没有变化时，可以判定一次hang，这种方式通常可以将hang感知缩小至3～5分钟。
- 任务hang时监控指标有哪些变化？
- 训练进程中的CUDA算子计算、集合通信操作通常都是在毫秒，甚至微秒、纳秒内完成的，当任务在正常迭代过程中发生了hang，我们常遇到的情况是所有rank的RDMA流量会降到0，而GPU的利用率为100%、SM利用率则在很低的水位。如果持续几分钟都是这种状态时，意味着训练进程已经计算完成，在等着集合通信完成，这种情况下基本可以判定为hang。
- 是否能在通信库中更快的感知通信hang？
- 通常单次集合通信操作都是在ms级的，如果一次操作在30秒钟都没有完成，那就可以判定为通信hang死了。百度自研的BCCL集合通信库层可以对每一次集合通信操作都进行打点，来实现通信hang感知。
上述几种方法，我们可以分别实现一种探针，来抓取相应的特征到中心端master组件进行下一步诊断和容错决策。
百度集合通信库BCCL是百度智能云推出的一款面向大模型训练场景优化的集合通信库。
BCCL基于开源的NCCL进行了功能扩展和能力增强，针对大模型训练场景在可观测性、故障诊断、稳定性等方面进行优化，进一步提升集合通信库的可运维能力。相比NCCL，BCCL的关键特性如下：
* 可观测性：新增集合通信带宽实时统计能力；
* 故障诊断：新增集合通信hang时的故障诊断能力；
* 稳定性：增强网络稳定性和故障容错能力；
* 性能优化：提升大模型训练主流GPU芯片的集合通信性能。
LSK & YZ，公众号：百度智能云技术站专为大模型训练优化，百度集合通信库 BCCL 万卡集群快速定位故障
4.2.训练hang的自动诊断
有了以上感知手段，我们需要进一步的诊断、定位，来确定是否真的发生了hang，以及hang的具体位置。具体的来讲，master收集到各类agent的数据后，会做一些综合分析：
- 是否真的发生了hang？
- 感知阶段各种探针只能探测到hang的一种特征，并没有办法100%的确定是否真的hang住了，事实上不侵入用户进程是很难做到100%确定hang的。因此，为了提高hang的判定准确率，我们需要将各种特种综合起来判断，探针上报到master后，由一个hang诊断模块，按照一个时间窗口（例如5分钟），进行综合判断。如果在时间窗口内日志、监控、进程调用栈、通信库中有2条以上都处于不处于活跃状态时，我们判断任务真正发生了hang。
- hang的具体发生的位置？
- 确定任务hang了之后，我们需要找到hang所在的节点来对它进行隔离。因此诊断模块需要在探针上报的数据中进一步找寻特征，来确定hang发生的位置：
- BCCL Tracehang诊断：在感知阶段，BCCL可以在通信库层面对所有rank的通信进行打点。如果有节点一直未完成通信则是发生了hang。但是此节点可能并非真正发生hang的源头，有可能是在等待其他节点完成通信。诊断模块可以根据BCCL打印的通信组信息，进行交叉判断，如果某个节点在多个通信组中都未完成通信，那这个节点就是hang的源头。
- RDMA/GPU指标诊断：上文中我们提到，通信阶段发生hang之后，所有rank的RDMA流量都会降到0，而同时绝大部分rank的GPU利用率持续为100%，只有某一两个rank的GPU利用率为0，那这个rank很有可能是hang的源头。
- 进程调用栈诊断：进程调用栈也可以作为一个hang源头诊断的重要参考。当发生hang之后，绝大部分的rank都要么处于barrier等待状态，要么处于通信等待阶段。只有个别的rank卡在其他函数上，那么通过对比分析，可以将调用栈与其他rank不同的节点初步判定为hang的源头。
- 综合诊断：上面3种特征为我们提供了hang的诊断依据，将3者关联起来分析后，我们基本上可以比较准确的确定一个具体的hang的源头，再结合硬件故障感知的相关信息可以进一步明确根因。
4.3.基于eBPF的隐式故障感知与诊断
在复杂的大规模分布式训练场景中，传统用户态监控往往难以捕获系统内核层面的异常事件。
百度百舸基于eBPF（Extended Berkeley Packet Filter）技术的隐式故障感知体系，能够在不侵入用户代码的前提下，对训练进程的系统调用、网络通信、CPU调度等内核态行为以及训练框架关键函数运行时间建立立体观测能力。
eBPF探针部署原理通过在内核关键路径注入轻量级探针，实现低开销的系统级行为捕获。针对训练场景特点，主要聚焦4类事件跟踪：
- 训练关键函数跟踪：微秒级跟踪训练过程中，前向计算、反向计算、集合通信操作等关键函数执行耗时，记录函数间调用关系。
- 进程调度阻塞跟踪：挂钩sched_switch事件，检测进程在TASK_UNINTERRUPTIBLE状态持续时间，当单次持续超过阈值（如5秒）时捕获调用栈。
- CUDA运行时API监控：通过uprobe在libcuda.so等关键库注入探针，记录CUDA API调用耗时分布。
- RDMA Verbs级通信监控：在ibv_post_send/ibv_poll_cq等核心通信接口设置观测点，统计通信时延分布。
结合上面4类事件，完成以下2类数据分析：
- 单体异常探测基线与实时数据对比。
- 群体一致性检测。采用卡间对比算法，当某一rank的以下指标偏离集群中位数超过阈值时判定异常，包括系统调用频率、进程就绪队列等待时长、NVLink/RDMA带宽利用率等。
基于以上所述方法，百度百舸针对以下2类典型的隐式故障进行诊断：
- 训练hang根因定位。通过关联eBPF捕获的多维度数据进行如下操作：
- 当检测到某rank的GPU Kernel执行出现分钟级空跑（SM利用率>70%但无有效计算输出）。
- 同时伴随该节点RDMA QP状态停滞（ibv_poll_cq无新完成事件）。
- 内核调度器显示进程处于D状态超过阈值。
- 性能抖动溯源。基于eBPF火焰图、时序图等进行分析：
- 抓取发生性能下降时段的CPU on-cpu/off-cpu堆栈。
- 对比正常时段数据，识别出异常的锁竞争（futex调用占比上升）。
- 结合NUMA内存访问统计，定位跨NUMA内存访问导致的TLB颠簸问题。
此类技术已在百度百舸的万卡规模训练集群中验证，相比单纯依赖应用层监控的方案，将隐式故障的平均检测时间从分钟级缩短至秒级，诊断准确率提升40%以上。
通过与既有硬件故障感知服务、BCCL通信库监测体系联动，百度百舸形成了覆盖从硬件到系统内核再到应用层的立体化诊断能力。
5.任务故障恢复的时效性保障
故障恢复的时效性也是容错能力的一个重要指标，反映的是任务从故障发生到再次重新进入训练迭代的时间，恢复效率越高则算力浪费越少。影响到任务恢复效率有2个重要因素，一是任务平均中断时间，二是训练重算时间。
5.1.多级重启策略减少故障中断时间
任务发生异常后，上文中我们提到需要经过故障自动感知、诊断和自愈等3个环节，那么减少中断时间的核心思想，就是尽可能的缩短这3个环节的时间，通过多维度的感知、诊断手段可以将故障发现、定位的时效性降低至分钟级甚至秒级。自愈则需要能够根据不同的诊断结果进行分级恢复和故障屏蔽的能力：
- 单点显式故障：重调度异常节点（replace），对节点进行集群级别屏蔽。
- 单点隐式故障：重调度异常节点，对节点进行任务级别屏蔽。
- 非单点故障：原地重启尝试恢复（restart），无法恢复时重新调度所有节点（resubmit）。
通过多级重启策略，尽可能避免单点故障引发全部节点的重新调度。在万卡级别的训练场景中，百度百舸将大部分训练异常场景恢复时间从过去的30min缩短至现在的30s内，成功率到95%+。
5.2.触发式checkpoint减少训练重算时间
除了上述的多级任务重启策略外，另一个提高任务故障恢复效率的重要手段就是减少训练重算时间。在探讨具体技术方案之前，我们先来看看目前主流的checkpoint保存策略。
传统的checkpoint保存通常采用固定间隔策略，比如每隔N个step或每隔T小时保存一次，这种方式实现简单但缺乏灵活性，可能会产生大量冗余存储，同时在故障发生时可能会损失较多训练进度。
而触发式checkpoint则是一种更智能的方案，它根据特定条件或异常事件（如故障、显存不足、显式指令等）动态触发模型状态保存。其核心目标是通过灵活的控制保存时机，减少不必要的存储开销和训练中断时间，从而降低因频繁或冗余保存导致的重算时间浪费。
随着大模型训练规模的扩大，还有一种更激进的「零重复checkpoint」技术，即在每个训练step都保存一次checkpoint。这种方案的优势在于可以将重算时间降到最低，确保故障发生时能够从最近的step恢复，几乎不会损失训练进度。但其显著的缺点是存储开销巨大，即使采用增量式存储，仍然需要相当大的存储空间和I/O带宽。此外，频繁的checkpoint操作也可能影响训练性能。
相比之下，触发式checkpoint走的是一条平衡之路。我们来看下它实现的几个核心要点：
- 集成容错：训练进程集成容错的故障感知与定位机制，在进程退出前自动触发保存。这种主动感知机制能够在故障发生的第一时间保存训练状态，最大限度减少进度损失。
- 高速转储：异步checkpoint保存机制会将checkpoint暂存到共享内存中，再由外部程序转储至磁盘。当某个节点异常时，容错组件会拉起新节点，并在新节点训练进程启动前，利用RDMA技术实现checkpoint快速从故障节点转储至新节点，这大大减少了从远程存储拉取checkpoint的时间。
- 冗余备份：触发式checkpoint也并非完美无缺，例如在节点发生内核crash等严重故障时，可能无法触发自动保存。因此，需要通过定期的冗余备份机制进行兜底，确保checkpoint不会完全丢失。
实践表明，当触发式checkpoint与异步、增量式的checkpoint机制结合使用时，可以在保证数据安全性的同时，显著提高checkpoint保存效率，减少训练重算时间。
相比零重复checkpoint的重型方案，触发式checkpoint提供了一个更实用的折中方案，在合理的存储开销下实现较好的容错效果。当然，具体选择哪种方案，还需要根据实际的训练规模、硬件条件和可用资源来权衡。
随着分布式训练规模的持续增长，相信未来会出现更多创新的checkpoint方案，比如基于预测的主动保存策略、多级存储架构的智能调度等，这些都将为提高大规模训练的可靠性提供新的可能。
6.业务发展对稳定性的要求
AI训练的稳定性管理已经演变为智能时代的精密工程。从最初靠人工重启解决问题的摸索阶段，到如今能自动感知异常、快速恢复的智能系统，每一次进步都映照着算力规模的跨越式发展。
让人不禁思考，在未来十万卡集群的算力洪流中，或许会出现更精妙的动态平衡方案：既能像鹰隼般敏锐捕捉故障征兆，又能如雁群迁移般智能调度资源，在秒级恢复与PB级存储成本之间找到新的平衡支点。
目前百度百舸支持厂内千卡和万卡集群有效训练时长已经可达99.5%，为客户大模型的预训练保驾护航，比如国内第一个数学大模型——九章算术，国内第一个类Sora大模型——Vidu等。