智能体 AI / 生成式 AI 通过自动化工作负载恢复保持分布式训练持续运行 2026年11月02日 作者： Ripple Patel, Ian Gibbs, Rick Izzo, Ashwin Poojary 和 Dong Ahn 讨论 (0)

AI 生成的摘要

  • NVIDIA Recovery 可全天候自动完成集群内各训练作业的工作负载级恢复，通过应用日志、GPU 指标和调度器信号检测中断。
  • 该服务协调一个四阶段恢复循环：检测异常、归因故障、隔离相关节点，并根据配置的策略重启或停止工作负载。
  • 与 Slurm 的集成使用可通过 Helm chart 以集群内或 SSH 模式部署的参考 Advisor Controller，使恢复服务独立于调度器内部实现。
  • 新部署默认以监控模式启动，仅发布恢复建议而不执行调度器操作，以便运维人员在启用自主恢复前验证信号质量。
  • 持久化审计记录会记录每种检测模式、所采取的操作、时间戳、工作负载标识符和归因判定结果，Recovery Console 则提供跨调度器类型的实时运维仪表盘。
  • 7 月 9 日至 10 月 9 日期间，在一个训练集群上进行的生产监控每天覆盖近 200 个作业，记录了约 8,550 次异常检测，平均检测延迟和恢复操作延迟分别为 69 秒和 94 秒。

后续步骤

  • 克隆 dsx-ai-factory/NVIDIA-Recovery 仓库以访问源代码和问题跟踪器。
  • 运行快速入门指南，在无物理 GPU 的情况下本地部署 NVIDIA Recovery。
  • 查看运维人员部署指南，了解集群内和基于 SSH 的 Slurm 部署说明。
由 NVIDIA Nemotron 提供支持。AI 生成的内容可能不完整地概括信息。请核实重要信息。 了解更多

随着分布式 AI 训练规模扩大，硬件和软件依赖方面的故障日益干扰训练进度，因此快速、可靠的恢复至关重要。一个停滞的训练 rank 可能触发 NVIDIA 集合通信库（NCCL）超时，一个 GPU 节点可能停止响应调度器，或者一个掉队者可能拖慢整个作业。每种中断单独来看都是可控的，但累积影响和恢复开销决定了系统将实际耗时转化为有效训练进度或 有效吞吐量.

当手动恢复必须覆盖集群中的每个训练作业、全天候、大规模地进行时，它就变得不可持续。每次中断都需要日志分析、故障隔离以及从保存的检查点重启，而受影响的 GPU 在恢复期间保持空闲。随着训练作业数量和规模的增长，重叠的故障会增加工程负担并浪费 GPU 小时。如果没有持续覆盖，这些损失会不断累积，增加整体计算成本并延长训练时间。

NVIDIA Recovery 是 NVIDIA DSX OS 的一部分，后者是包含 NVIDIA DSX AI Factory Platform 的模块化软件产品组合。NVIDIA Recovery 是一项开源的工作负载级服务，可全天候自动恢复集群中各个训练作业。它利用应用日志、GPU 指标和调度器信号检测中断，通过故障归因识别相关资源，并协调隔离以及在健康容量上从检查点重启。通过在工作负载之间自动执行这一恢复循环，它，是 NVIDIA DSX OS，即包含 NVIDIA DSX AI Factory Platform 的模块化软件产品组合， NVIDIA DSX AI Factory Platform，是一项开源的工作负载级服务，可全天候自动恢复集群中各个训练作业。它利用应用日志、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 健康指标并 事件，并自动封锁和排空故障节点。 事件，并自动封锁和排空故障节点。许多 Slurm 站点使用自定义的 prolog 和 epilog 脚本检查节点健康状况。来自 Slinky 项目原生支持并在 Kubernetes 上运行 Slurm 时注入这些相同的脚本。在单个训练作业中，NVRx 提供用于作业内恢复和挂起检测的库。NVIDIA Recovery 协调恢复 在集群层面的各工作负载之间，并与这些能力集成，以管理作业重启、放置和节点排除。

Five-layer stack diagram showing where NVIDIA Recovery sits in the health and resilience architecture. From the base up: infrastructure, compute node, cluster, workload (where NVIDIA Recovery and NVIDIA Attribution sit), and framework (NVIDIA Resiliency Extension, or NVRx).
图 1. NVIDIA Recovery 在健康与韧性集成中的作用

这些层独立运行，没有硬性依赖，因此你可以采用每个模块化组件，或接入你自己的平台组件进行集成。例如，如果你的集群已经依赖 NVSentinel 或 NVIDIA Health Validation，那么你几乎无需或完全无需改动现有的健康工作流，即可集成 NVIDIA Recovery。

对于已经在运行 NVRx 的环境，NVIDIA Recovery 通过管理跨工作负载的生命周期和节点排除，填补了作业内重启无法触及的空白。当与 NVIDIA Attribution 配合使用时，它会接收丰富的跨层诊断结论，从而充实持久审计轨迹。

差距的代价

在集群规模下，单个GPU的罕见故障会不断累积。即使每块GPU在某一天无故障运行的概率为99.9%，一个跨越10,000块GPU的作业当天不中断完成的概率也只有 0.99910,000 ≈ 0.005%。这解释了为什么，在 Meta 对 24,000 块 A100 GPU 进行的为期 11 个月的研究硬件故障中断的任务不足1%，但这些任务却占用了19%的GPU运行时间：规模最大、运行时间最长的任务面临的风险最高。

NVIDIA Recovery 可自动完成集群内各训练工作负载的恢复，无论小型还是大型分布式运行都适用。在许多较小的作业中，中断会不断累积，加重运维负担。在大型作业中，每次中断影响的 GPU 更多，放大了恢复的计算成本。自动恢复可同时应对这两项挑战。

我们的生产环境观察结果凸显了对这种高效、自动化恢复的需求，它需要能够扩展到集群中的各类工作负载：从7月9日到10月9日，在一个训练集群上运行的NVIDIA Recovery监控每天覆盖近200个作业，并记录了约8,550次异常检测，平均检测延迟和恢复动作延迟分别为69秒和94秒。这种无人值守、覆盖整个集群的响应减少了对个别工程师和按用户安排恢复的依赖，尤其是在中断不断累积的情况下。恢复动作延迟止于自动化动作；调度和检查点恢复决定生产性训练何时恢复。

自动化恢复循环

NVIDIA Recovery 协调整个集群训练工作负载的恢复。四个阶段组织这一循环，具体动作由中断情况和配置的策略决定：

  1. 检测异常检测器结合应用日志和调度器信号来识别崩溃、挂起和掉队者。它能识别 PyTorch 和 NCCL 故障、CUDA 错误以及互连故障模式。缺失进度信号或识别到已知的通信挂起模式表明可能存在挂起；相对于近期基线的持续吞吐量下降表明可能存在掉队者。
  2. 归因：NVIDIA Recovery 利用检测期间收集的调度器信号和应用日志对中断进行分类，并指导恢复动作。可选集成 NVIDIA Attribution 可增加更深入的诊断，以区分硬件故障、系统软件问题和应用缺陷。这些证据为节点排除提供依据，并丰富审计轨迹。运维人员也可以集成自己的归因服务，并独立采用 NVIDIA Recovery。隔离：异常修复器应用：NVIDIA Recovery 利用检测期间收集的调度器信号和应用日志对中断进行分类，并指导恢复动作。可选集成 NVIDIA Attribution 可增加更深入的诊断，以区分硬件故障、系统软件问题和应用缺陷。这些证据为节点排除提供依据，并丰富审计轨迹。运维人员也可以集成自己的归因服务，并独立采用 NVIDIA Recovery。
  3. 隔离： 异常修复器会应用恢复建议，在后续重启尝试中排除相关节点，或在进一步重试无望时停止工作负载。它会跨多次尝试跟踪相关节点，以避免反复失败。此外，安全网（看门狗服务）允许在恢复决策耗时过长或彻底失败时正常调度继续进行，防止工作负载无限期等待。
  4. 重启或停止：调度器集成通过 Advisor API 执行 NVIDIA Recovery 的建议，以重启工作负载或停止无成效的重试。重启时，应用利用其现有的重启逻辑从最后保存的检查点恢复。如果作业在可配置的尝试次数内未能保存新的检查点，则可以停止进一步的重试。审计轨迹记录重启和停止决策，并将分配重启、恢复的训练进度和训练完成作为不同事件进行跟踪。
Flow diagram showing NVIDIA Recovery’s four-stage loop triggered by a training interruption: Detect (application logs and scheduler signals), Attribute (classify state, optional NVIDIA Attribution verdict), Isolate (terminate workload, exclude implicated nodes), and Restart (on healthy capacity), after which the application loads from its last checkpoint and training resumes.
图 2. NVIDIA Recovery 的自动恢复循环

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

NVIDIA Recovery 作为控制平面服务运行，并通过 HTTP 或 gRPC API 与集群的调度器集成进行通信。它支持 Slurm，Kubernetes 支持已在路线图中。恢复建议遵循通用的 API 契约，由集群侧控制器将其转换为针对工作负载管理器的操作。这使 NVIDIA Recovery 与调度器内部实现保持独立，并避免修改应用代码。

对于 Slurm，参考 Advisor Controller 以 Helm chart 形式提供，便于部署。它支持两种模式：1）集群内模式，控制器在集群内运行；2）SSH 模式，控制平面远程连接 Slurm，无需添加集群内服务。当部署新的集群组件需要变更窗口或安全审查时，这提供了一种选择。

NVIDIA Recovery 会在控制器执行操作之前记录每一条恢复建议，从而形成一份预期操作的审计轨迹。如果控制器在恢复过程中重启，它会在继续之前检查当前的调度器状态，以此作为防止重复执行已完成操作的保障措施。

运行方式：监控模式与审计轨迹

新部署默认以监控模式启动。在此模式下，NVIDIA Recovery 会发布建议并记录它本应采取的操作，但不会执行任何调度器动作。请审阅这些建议，将决策与您自己的工程师会做出的决策进行对比，并在对信噪比感到满意后，按集群切换到执行模式。

controller:
  environment: prod
  acknowledgeSchedulerActions: false

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

IBM Research 在其 Slurm 集群上采用了这一方案。他们先以监控模式运行，将建议与自身的人工恢复决策进行对比，并在验证信号后启用了自主操作。Neocloud 提供商 Verda 选择部署在 Victoria Logs 而非 Loki 上，并为该仓库合作开发了 VictoriaLogs 连接器，从而快速启动了 OSS 合作伙伴计划。

NVIDIA Recovery 会将每个操作写入持久、可查询的审计轨迹。每条记录都会捕获匹配到的检测模式、所采取的操作（终止、重新排队、释放或节点排除）、时间戳、工作负载标识符，以及 NVIDIA Attribution 返回的判定结果（若有）。策略引擎操作和看门狗操作会记录在同一条轨迹中，因此记录没有缺口。

Recovery Console 是运维人员仪表板。它显示跨调度器类型的实时工作负载状态，内联呈现异常标记，并为你提供每个工作负载的检测事件和恢复操作时间线。

视频 1：演示在 Kubernetes 上使用 Slurm 的 NVIDIA Recovery 全流程，从环境搭建和作业配置，到作业失败、自动恢复与归因

NVIDIA Recovery 已在 dsx-ai-factory/NVIDIA-Recovery 采用 Apache 2.0 许可证的 GitHub 仓库。让首个工作负载进入恢复流程需要三个步骤：

  1. 安装该 chart。NVIDIA Recovery 通过单个 Helm umbrella chart 部署。它附带一个捆绑的 MySQL 子 chart，因此你可以在本地运行快速入门，而无需预置数据库或物理 GPU。对于生产环境，请将该 chart 指向托管 MySQL 服务。仓库中的 operator 部署指南涵盖了这两种路径，以及 Kubernetes、Helm 和 Slurm 的当前版本要求。
  2. 验证你的信号。将图表指向你现有的 Loki 或 Victoria Logs 端点以及你的 Prometheus 抓取目标，然后在首次运行工作负载之前运行日志摄取配置器。它会根据 NVIDIA Recovery 契约测试你的信号，映射与默认值不同的标签名称，并在不匹配变成静默故障之前将其暴露出来。
  3. 接入一个工作负载。在你的 sbatch 提交脚本中添加一条指令：
#SBATCH --comment='{"nvidia-recovery":{"environment":"prod","mode":"observe"}}'

随后，NVIDIA Recovery 通过应用日志和调度器信号监控工作负载。在监控模式下，它会发布恢复建议而不采取行动。在 Recovery Console 中验证这些建议后，通过在 Helm values 中将 mode 设为 action、将 acknowledgeSchedulerActions 设为 true，即可启用自主恢复。

其他资源涵盖其余内容：

  • 包含源代码和问题跟踪器的 dsx-ai-factory/nvidia-recovery GitHub 仓库。
  • 快速入门指南，无需物理 GPU 即可运行。
  • 操作员部署指南，适用于集群内和基于 SSH 的 Slurm 部署。
  • 架构参考，说明控制平面如何组合在一起。

NVIDIA 归因 是推荐的配套部署。它为 NVIDIA Recovery 提供更深入的诊断结论和更丰富的审计追踪；它是可选的，并与 NVIDIA Recovery 一同发布。

接下来是什么

此版本可恢复 Slurm 作业，包括通过 slurm-operator 在 Kubernetes 上运行的 Slurm。接下来将推出两项能力。针对 Slurm 作业数组的恢复功能，为许多团队以数组形式运行超参数扫描提供与单个作业相同的保护：每个失败的任务都会单独恢复，而当失败看起来是系统性的时候，恢复就会停止。原生 Kubernetes 恢复从 JobSet 和 Kubeflow PyTorchJob 开始，使用开源的工作负载映射 以支持每种工作负载类型。

路线图涵盖更精细的故障分类、在仪表板和 API 中更清晰地记录每一项恢复决策（以便你将其接入自己的可观测性工具），以及朝着稳定版本推进的工作。请对路线图问题投票并发表评论，以影响哪些事项优先推进。IBM Research 已为训练工作负载部署 NVIDIA Recovery，并正与该团队合作，从中提炼故障模式。Verda 是首个部署它的 NVIDIA 云合作伙伴，其运行 NVIDIA Recovery 时搭配 VictoriaLogs路线图 涵盖更精细的故障分类、在仪表板和 API 中更清晰地记录每一项恢复决策（以便你将其接入自己的可观测性工具），以及朝着稳定版本推进的工作。请对路线图问题投票并发表评论，以影响哪些事项优先推进。

IBM Research 已为训练工作负载部署 NVIDIA Recovery，并正与该团队合作，从中提炼故障模式。Verda 是首个部署它的 NVIDIA 云合作伙伴，其运行 NVIDIA Recovery 时搭配 VictoriaLogs，并已提交了首批拉取请求。随着更多采用者做出贡献，他们的更改将与 NVIDIA 自己的更改一样经过相同的审查。

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

开始使用

NVIDIA Recovery 将原本需要工程师在凌晨 3 点手动完成的恢复流程实现自动化。克隆代码仓库，针对你的遥测栈运行配置器，并将一个工作负载纳入其中。第一次中断就会让你看到这个循环从头到尾是如何运作的。

  • 这些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 对本博文亦有贡献。 

讨论（0）

标签

智能体 AI / 生成式 AI | 数据中心 / 云 | HPC / 科学计算 | DGX Cloud | DSX | 中级技术 | 公告 | 教程 | DSX AI Factory 平台 | 基础设施 关于作者 关于 Ripple Patel Ripple Patel 是 NVIDIA 的高级技术项目经理，负责领导 NVIDIA DSX 的 AI 平台与基础设施韧性项目。她的工作涵盖面向主权 AI 的 NVIDIA 多云 AI 平台，以及企业 | HPC / 科学计算 | DGX Cloud | DSX | 中级技术 | 公告 | 教程 | DSX AI Factory 平台 | 基础设施

关于作者

Avatar photo 关于 Ripple Patel
Ripple Patel 是 NVIDIA 的高级技术项目经理，负责领导 NVIDIA DSX 的 AI 平台与基础设施韧性项目。她的工作涵盖面向主权 AI 和企业提供商的 NVIDIA 多云 AI 平台、针对 Nemotron 等前沿训练任务的自主工作负载级恢复，以及集群机队上线。此前，她曾在 Google 和 Dolby Laboratories 领导 AI 基础设施与研究技术项目。她拥有滑铁卢大学管理工程学士学位，并持有 PMP 认证。 查看 Ripple Patel 的所有文章 Avatar photo 关于 Ian Gibbs
Ian Gibbs 是 NVIDIA 的高级技术产品经理，负责领导 NVIDIA Recovery 的产品工作，致力于让大规模 AI 训练更加韧性和高效。他曾在 AWS 参与将 Amazon SageMaker HyperPod 从概念打造为用于韧性模型训练的重要服务。在加入 AWS 之前，他在 General Motors 领导产品与数据科学团队，构建了用于产品安全监控和 OnStar 的 AI 系统。 查看 Ian Gibbs 的所有文章 关于 Rick Izzo
Rick Izzo 花了十多年时间构建开源 AI 工具和科学计算基础设施。他最初是一名医学影像研究员和开源维护者，之后联合创立了 Tensor[werk]，该公司后来被 Lightning AI 收购。过往的知名项目包括 VMTK、RedisAI、Hangar 和 PyTorch Lightning。加入 NVIDIA 后，Rick 一直维护并推动 NVIDIA Recovery 项目，设计了适用于 Slurm 和 Kubernetes 的调度器中立恢复接口。 查看 Rick Izzo 的所有文章 Avatar photo 关于 Ashwin Poojary
Ashwin Poojary 是 NVIDIA 的工程总监，负责领导专注于 AI 平台与基础设施韧性的团队。在加入 NVIDIA 之前，Ashwin 曾在 Twitter 管理大规模基础设施，此前还曾在 Facebook、Google、Juniper Networks 和 Alcatel-Lucent 任职。 查看 Ashwin Poojary 的所有文章 Avatar photo 关于 Dong Ahn
Dong H. Ahn 是 NVIDIA 的 AI 基础设施架构师兼杰出工程师。他构建 AI 工厂控制平面，将智能体 AI、自动恢复以及 Slurm 和 Kubernetes 编排相结合，以提升 HPC 和云基础设施的可靠性与有效吞吐量。他设计了 NVIDIA Recovery，这是一个集成到 NVIDIA Mission Control 和 DGX Cloud 中的参考实现，已在 NVIDIA 超过 10 万块 GPU 的集群中投入使用。此前，他在劳伦斯利弗莫尔国家实验室工作了 20 多年，领导开发了 Flux 框架，该框架目前管理着 El Capitan 百亿亿次超级计算机。他的工作曾荣获 2011 年和 2021 年 R&D 100 大奖。 查看 Dong Ahn 的所有文章

评论