自动化故障恢复，让分布式AI训练持续运行

随着分布式AI训练规模不断扩大，硬件和软件依赖链上的故障日益频繁地打断训练进程，因此快速、可靠的恢复机制变得至关重要。一个训练节点的停滞可能触发NVIDIA集合通信库（NCCL）超时，一个GPU节点可能停止响应调度器，或者一个掉队节点可能拖慢整个任务。每种故障单独来看都可以管理，但累积的影响和恢复开销决定了系统将实际运行时间转化为有效训练进度（即有效产出）的效率。

当需要全天候覆盖集群中的每一个训练任务时，人工恢复方式变得难以为继。每次中断都需要进行日志分析、故障定位，并从保存的检查点重新启动，而受影响的GPU在恢复期间则处于闲置状态。随着训练任务数量和规模的增长，重叠发生的故障会加重工程负担并造成更多GPU算力的浪费。如果缺乏持续的覆盖能力，这些损失会不断累积，从而增加整体计算成本并延长训练所需时间。

NVIDIA Recovery是NVIDIA DSX OS的一部分，后者是NVIDIA DSX AI Factory平台下的模块化软件组合。NVIDIA Recovery是一项开源的工作负载级服务，可全天候自动化处理集群中训练任务的故障恢复。它通过应用日志、GPU指标和调度器信号检测中断，利用故障归因定位相关资源，并协调隔离操作和基于健康算力资源的检查点重启。通过在各工作负载间自动完成这一恢复闭环，该系统能够处理并发性中断、减少人工介入，并有助于维持训练的有效产出。本文将介绍该恢复闭环的运作方式、NVIDIA Recovery与Slurm的集成方法，以及如何在自己的集群上进行部署。

工作负载恢复是AI工厂运维中的独立议题

此前我们发布的NVIDIA DGX Cloud弹性文章、GTC演讲以及NVIDIA Mission Control 2.5相关文章，都介绍了保持训练高效运行的分层方法。NVIDIA Recovery在此架构基础上进一步发展，将基础设施层面的修复与工作负载层面的恢复连接了起来。

故障修复自动化负责识别故障节点、将其从服务中移除，并安排硬件维修。诸如NVRx这样的框架级库可在单个训练任务内部提供恢复、挂起检测和掉队节点缓解能力，但每位用户都必须自行配置和管理这些能力以适用于自己的工作负载。像Slurm这样的集群工作负载管理器负责资源分配、排队和容器执行。

工作负载恢复是一个独立的协调性问题：要恢复高效训练，需要将故障归因于具体原因，决定受影响的任务是否需要重启、在何处重启，并在共享基础设施的各个工作负载间采取一致的行动。要解决这个问题，需要一个集群级的控制闭环，将基础设施修复、框架级恢复与集群工作负载管理整合在一起，并配备可追踪恢复延迟、恢复成功率和恢复至有效训练所需时间等运维指标。

多层级NVIDIA健康与弹性技术栈

如下图1所示，NVIDIA Recovery在DSX OS技术栈中提供专门的工作负载恢复层。节点健康监测与隔离依赖于集群自身的编排与工作负载管理技术栈。在Kubernetes部署环境中，可使用NVSentinel监测GPU健康指标和XID事件，并自动隔离与清空故障节点。许多Slurm站点通过自定义的prolog和epilog脚本检查节点健康状况。Slinky项目中的slurm-operator在Kubernetes上运行Slurm时，原生支持并注入相同的脚本。在单个训练任务内部，NVRx提供了用于任务内恢复和挂起检测的库。NVIDIA Recovery在集群层面协调各工作负载间的恢复工作，并与这些能力集成，以管理任务重启、放置和节点排除。

这些层级各自独立运行，彼此之间没有硬性依赖，因此您可以灵活采用每个模块化组件，或接入自己的平台组件进行集成。例如，如果您的集群已经依赖NVSentinel或NVIDIA Health Validation，那么您只需极少甚至无需对现有健康检查工作流做任何改动，即可集成NVIDIA Recovery。

对于已经运行NVRx的环境，NVIDIA Recovery填补了任务内重启无法覆盖的空白，负责管理跨工作负载的生命周期和节点排除。当与NVIDIA Attribution搭配使用时，它还能获得丰富的跨层诊断结论，从而充实持久化的审计记录。

差距的代价

在集群规模下，即便是单个GPU上发生概率极小的故障，也会不断累积放大。假设每个GPU在某一天无故障运行的概率为99.9%，那么一个跨越10000个GPU的任务在当天完全不中断的概率仅为0.999的10000次方，约等于0.005%。这也解释了为什么在Meta对24000个A100 GPU长达11个月的研究中，硬件故障中断的任务数量不到1%，但这些任务却占据了19%的GPU运行时间：规模最大、运行时间最长的任务恰恰最容易受到影响。

NVIDIA Recovery可自动处理集群中各训练工作负载的恢复，对小规模和大规模分布式训练任务都同样适用。在众多较小的任务中，中断事件会不断累积，增加运维负担；而在大型任务中，每次中断都会影响更多的GPU，从而放大恢复所需的计算成本。自动化恢复能够同时应对这两类挑战。

我们的生产环境观测数据印证了这种高效、自动化且可在集群工作负载间扩展的恢复机制的必要性：从7月9日到10月9日，NVIDIA Recovery在一个训练集群上的监测每天覆盖近200个任务，共记录约8550次异常检测，平均检测延迟和恢复操作延迟分别为69秒和94秒。这种无需人工值守、覆盖全集群的响应机制，减少了在中断事件累积时对个别工程师及用户自行安排恢复的依赖。需要说明的是，恢复操作延迟终止于自动化操作本身；而调度和检查点恢复则决定了训练何时真正恢复至有效状态。

自动化恢复闭环

NVIDIA Recovery负责协调集群中各训练工作负载的恢复工作。整个闭环分为四个阶段，具体采取的操作由中断类型和配置策略共同决定：

检测：异常检测器结合应用日志和调度器信号来识别崩溃、挂起和掉队情况。它能够识别PyTorch和NCCL故障、CUDA错误以及互联故障模式。缺失进度信号或识别出的通信挂起模式，表明可能发生了挂起；而相对于近期基准水平出现持续的吞吐量下降，则表明可能存在掉队节点。

归因：NVIDIA Recovery利用检测阶段收集到的调度器信号和应用日志，对中断进行分类并指导恢复操作。与NVIDIA Attribution的可选集成可提供更深层次的诊断，用以区分硬件故障、系统软件问题和应用程序缺陷。这些证据将用于指导节点排除决策，并丰富审计记录内容。运维人员也可以集成自己的归因服务，独立采用NVIDIA Recovery。

隔离：异常修复器负责执行恢复建议，将相关节点排除在后续重启尝试之外，或在进一步重试无意义时直接停止该工作负载。它会跨多次尝试跟踪相关节点，以避免故障反复发生。此外，一套安全保护机制（看门狗服务）可确保在恢复决策耗时过长或彻底失败时，正常调度仍能继续进行，从而防止工作负载无限期等待。

重启或停止：调度器集成模块通过Advisor API根据NVIDIA Recovery的建议，执行重启工作负载或停止无效重试的操作。重启时，应用程序会利用其自身现有的重启逻辑，从上一次保存的检查点恢复运行。如果任务在可配置的若干次尝试中都未能保存新的检查点，则可以停止进一步的重试。审计记录会记录重启和停止的决策，并将资源分配重启、训练进度恢复和训练完成作为独立事件分别进行追踪。

NVIDIA Recovery与工作负载调度器的集成

NVIDIA Recovery作为控制平面服务运行，并通过HTTP或gRPC API与集群的调度器集成模块通信。目前支持Slurm，Kubernetes支持已列入路线图。恢复建议遵循统一的API规范，由集群侧的控制器将其转化为针对工作负载管理器的具体操作。这种设计使NVIDIA Recovery无需依赖调度器内部实现细节，也无需对应用程序代码进行任何修改。

针对Slurm，官方提供了参考实现的Advisor Controller，可通过Helm chart轻松部署。它支持两种模式：一是集群内模式，控制器在集群内部运行；二是SSH模式，控制平面通过远程方式连接到Slurm，无需在集群内新增服务。当部署新的集群组件需要经过变更窗口审批或安全审查时，这一模式提供了另一种可行选择。

NVIDIA Recovery会在控制器执行操作之前先记录每一条恢复建议，从而生成一份关于预期操作的审计记录。如果控制器在恢复过程中重启，它会先检查当前调度器状态，然后再继续执行，以此避免重复执行已完成的操作，起到保护作用。

运行机制：监控模式与审计记录

新部署默认以监控模式启动。在该模式下，NVIDIA Recovery会发布建议并记录其本应采取的操作，但不会实际对调度器执行任何操作。您可以审查这些建议，将其与您自己工程师的决策进行对比，待确认信噪比令人满意后，再按集群逐一切换到行动模式。

controller: environment: prod acknowledgeSchedulerActions: false watchdog: enabled: true mode: observe acknowledgeSchedulerActions: false environmentPattern: prod

IBM研究院在其Slurm集群上采用了这一路径。他们先以监控模式运行，将系统建议与自己的人工恢复决策进行对比，待验证信号可靠后再启用自主执行功能。新云服务商Verda则选择在Victoria Logs而非Loki上部署，并协作开发了面向该项目仓库的VictoriaLogs连接器，由此推动了开源合作伙伴计划的启动。

NVIDIA Recovery会将每一次操作写入持久化、可查询的审计记录中。每条记录都包含匹配到的检测模式、所采取的操作（终止、重新排队、释放或节点排除）、时间戳、工作负载标识符，以及在调用NVIDIA Attribution时返回的诊断结论。策略引擎执行的操作和看门狗执行的操作都会记录在同一份审计记录中，确保记录完整、不出现断档。

Recovery控制台是面向运维人员的仪表盘。它可以展示跨调度器类型的实时工作负载状态，直接标注异常标记，并为每个工作负载提供检测事件与恢复操作的完整时间线。

NVIDIA Recovery已在dsx-ai-factory/NVIDIA-Recovery的GitHub仓库中以Apache 2.0许可证开放。让第一个工作负载纳入恢复管理只需三个步骤：

安装chart。NVIDIA Recovery通过单一的Helm总控chart进行部署。其中附带了一个MySQL子chart，因此您无需配置数据库或物理GPU即可在本地运行快速入门示例。在生产环境中，请将chart指向受管理的MySQL服务。仓库中的运维部署指南涵盖了这两种部署路径，以及目前对Kubernetes、Helm和Slurm版本的具体要求。

验证信号。将chart指向您现有的Loki或Victoria Logs端点以及Prometheus抓取目标，然后在首个工作负载运行前执行日志接入配置工具。该工具会依据NVIDIA Recovery的规范测试您的信号，映射与默认标签名称不同的部分，并在问题变成无声故障之前将不匹配项提前暴露出来。

将工作负载纳入管理。只需在sbatch提交脚本中添加一行指令：

#SBATCH –comment='{“nvidia-recovery”:{“environment”:”prod”,”mode”:”observe”}}’

此后，NVIDIA Recovery将通过应用日志和调度器信号对该工作负载进行监控。在监控模式下，它只会发布恢复建议而不会实际执行操作。在Recovery控制台中验证这些建议之后，您可以通过在Helm配置值中将mode设置为action，并将acknowledgeSchedulerActions设置为true，来启用自主恢复功能。

其他资源涵盖了剩余内容：

dsx-ai-factory/nvidia-recovery的GitHub仓库，提供源代码和问题跟踪。

快速入门指南，无需物理GPU即可运行。

运维部署指南，涵盖集群内部署和基于SSH的Slurm部署方式。

架构参考文档，介绍控制平面各组件如何协同工作。

NVIDIA Attribution是推荐搭配部署的组件。它能为NVIDIA Recovery提供更深入的诊断结论和更丰富的审计记录；该组件为可选项，与NVIDIA Recovery同步发布。

接下来的计划

当前版本支持恢复Slurm任务，包括通过slurm-operator在Kubernetes上运行的Slurm任务。接下来将推出两项新能力。针对Slurm任务数组的恢复功能，将为许多团队以数组形式运行的超参数搜索任务提供与单个任务同等的保护：每个失败的子任务都会单独恢复，而当故障看起来具有系统性时，恢复机制会自动停止。原生Kubernetes恢复功能将从JobSet和Kubeflow PyTorchJob开始支持，并借助开源的Workload Map项目来支持各类工作负载类型。

除此之外，路线图还包括更精准的故障分类、在仪表盘和API中更清晰地记录每一项恢复决策以便接入您自己的可观测性工具，以及推动正式稳定版本发布的相关工作。欢迎在路线图相关议题上投票和评论，共同决定优先推进的方向。

IBM研究院已在其训练工作负载中部署了NVIDIA Recovery，并正与团队合作，基于实际数据完善故障模式识别。新云服务商Verda作为首家部署该系统的NVIDIA Cloud Partner，已将NVIDIA Recovery与VictoriaLogs结合使用，并提交了首批代码贡献。随着更多采用者参与贡献，他们提交的改动将与NVIDIA自身的代码一样接受同等审查。

NVIDIA Recovery是DSX OS的一部分，后者是NVIDIA面向AI工厂运维的开源软件层，采用Apache 2.0许可证。

开始使用

NVIDIA Recovery将原本依赖凌晨三点值班工程师手动处理的恢复流程实现了自动化。克隆代码仓库，针对您的遥测技术栈运行配置工具，并将一个工作负载纳入管理，第一次中断事件就会让您完整体验整个恢复闭环的运作方式。

dsx-ai-factory/nvidia-recovery的GitHub仓库，提供源代码和问题跟踪

快速入门指南，无需物理GPU即可运行

运维部署指南，涵盖集群内部署和基于SSH的Slurm部署方式

架构参考文档，介绍控制平面各组件如何协同工作

致谢

本文由Abhishek Jha、Alex Kondratenko、Amy You、Andrew McHarg、Ashwin Poojary、Ashwini Awatiger、Bob Schatz、Collin Neale、Dave Yao、Deepak Narayanan、Dilpreet Singh、Divyansh Jain、Dong H. Ahn、Dorrin Poorkay、Evan Briones、Gargi Prasad、Haim Elisha、Hamzeh Doostie、Harmandeep Singh、Harri Lin、Himanshu Soni、Ian Gibbs、Jason Sewall、Kumar Anik、Maer Rodrigues de Melo、Megan Chao、Mike Houston、Orlando Gentil、Oscar Bejarano Ardila、Pavan Kumar Gondhi、Prateek Gera、Rajan Singh、Rakshit Sanadhya、Rajasi Purandare、Ripple Patel、Rick Izzo、Ruoxi Zhang、Satish Pasumarthi、Shelby Thomas、Stefania Alborghetti、Tony Wang、Vincent Pun和Yugal Jain共同贡献完成。