知识卡片：NVIDIA Recovery——面向分布式训练的自动化工作负载恢复

一句话结论

NVIDIA Recovery 是 NVIDIA DSX OS 旗下开源的集群级工作负载恢复服务，通过“检测—归因—隔离—重启/停止”四阶段循环，自动处理跨训练作业的中断，并在生产集群上录得约 69 秒的平均检测延迟与 94 秒的平均恢复动作延迟。

事件概述或研究问题

随着分布式 AI 训练规模扩大，硬件与软件依赖故障会持续打断训练进度：单个训练 rank 卡住可触发 NCCL 超时，GPU 节点可能不再响应调度器，慢节点（straggler）会拖慢整个作业。单次中断尚可人工处理，但当需要 7×24 覆盖整个集群的所有训练作业时，人工恢复不可持续——每次中断都要做日志分析、故障隔离、从检查点重启，期间受影响的 GPU 处于空闲状态。NVIDIA Recovery 要解决的是这一“工作负载恢复”协调问题：把故障归因到具体资源、决定作业是否以及在哪里重启，并在共享基础设施的多个工作负载之间一致地执行。

方法/产品要点

• 定位：NVIDIA Recovery 属于 NVIDIA DSX OS（模块化软件组合，含 NVIDIA DSX AI Factory Platform），是开源的工作负载级服务，以控制平面服务形式运行，通过 HTTP 或 gRPC API 与集群调度器集成通信。
• 四阶段恢复循环：
  1. 检测（Detect）：Anomaly Detector 结合应用日志与调度器信号，识别崩溃、挂起和慢节点；可识别 PyTorch 与 NCCL 故障、CUDA 错误、互连故障模式；缺少进度信号或已知通信挂起模式提示潜在挂起，相对近期基线的持续吞吐下降提示潜在慢节点。
  2. 归因（Attribute）：用检测阶段收集的调度器信号与应用日志对中断分类并指导恢复动作；可选集成 NVIDIA Attribution 做更深诊断，区分硬件故障、系统软件问题和应用 bug，为节点排除提供依据并丰富审计记录；运营方也可接入自有归因服务。
  3. 隔离（Isolate）：Anomaly Remediator 执行恢复建议，将涉事节点从后续重启尝试中排除，或在继续重试无意义时停止工作负载；跨尝试跟踪涉事节点以避免重复失败；另设 watchdog 安全网，若恢复决策耗时过长或失败则允许正常调度继续，防止工作负载无限等待。
  4. 重启或停止（Restart or Stop）：调度器集成通过 Advisor API 执行建议；重启时应用按既有重启逻辑从最近保存的检查点恢复；若作业在可配置次数的尝试中都无法保存新检查点，可停止后续重试；审计记录中重启/停止决策、分配重启、训练进度恢复和训练完成被作为不同事件跟踪。
• 调度器集成：目前支持 Slurm，Kubernetes 支持在路线图中；恢复建议遵循通用 API 契约，由集群侧控制器翻译为工作负载管理器动作，从而与调度器内部实现解耦、无需改动应用代码。Slurm 的参考 Advisor Controller 以 Helm chart 部署，支持集群内模式与 SSH 远程模式（后者适用于新增集群组件需要变更窗口或安全审查的场景）。
• 监控模式与审计：新部署默认处于 monitor mode，只发布建议并记录“本会做什么”，不执行调度动作；运营方确认信噪比后再按集群切换到 action mode。每次恢复建议在控制器执行前即被记录，形成审计轨迹；控制器在恢复期间重启时会先检查当前调度器状态再继续。
• 部署入口：克隆 dsx-ai-factory/NVIDIA-Recovery 仓库获取源码与 issue tracker；quickstart 指南支持无物理 GPU 的本地部署；operator 部署指南覆盖集群内与基于 SSH 的 Slurm 部署。

主要结果或产业意义

• 故障规模的量化论证：即使单块 GPU 某日无故障概率为 99.9%，跨 10,000 块 GPU 的作业当日不中断完成的概率仅约 0.999^10000 ≈ 0.005%；Meta 对 24,000 块 A100 长达 11 个月的研究显示，硬件故障只中断了不到 1% 的作业，但这些作业占了 19% 的 GPU 运行时——规模最大、运行最久的作业暴露度最高。
• 生产监控数据：2026 年 7 月 9 日至 10 月 9 日，NVIDIA Recovery 在一个训练集群上的监控覆盖每天近 200 个作业，记录约 8,550 次异常检测，平均检测延迟与平均恢复动作延迟分别为 69 秒和 94 秒。需注意，恢复动作延迟止于自动动作本身，调度与检查点恢复才决定生产性训练何时真正恢复。
• 与既有分层架构的关系：文章将其与既有工作衔接——break-fix 自动化负责识别故障节点、移出服务并送修；框架级库 NVRx 提供单作业内的恢复、挂起检测和慢节点缓解，但需各用户自行配置管理；Slurm 等集群工作负载管理器负责资源分配、排队与容器执行。NVIDIA Recovery 补的是跨工作负载生命周期的协调层：对已运行 NVRx 的环境，它填补了作业内重启无法覆盖的跨工作负载生命周期与节点排除；节点健康监控与隔离依赖集群编排栈（Kubernetes 用 NVSentinel 监控 GPU 健康指标与 XID 事件并自动 cordon/drain，Slurm 站点多用自定义 prolog/epilog 脚本，Slinky 项目的 slurm-operator 在 Kubernetes 上运行 Slurm 时可注入同样的脚本）。各层无硬依赖，可模块化选用或接入自有组件。

为什么重要

• 决定“墙钟时间转化为有效训练进度（goodput）”的效率：中断本身可控，但累计影响与恢复开销决定系统效率；重叠故障会放大工程负担与浪费的 GPU 小时，缺乏持续覆盖时这些损失会累积，抬高算力成本、拉长训练时间。
• 把恢复从“每位用户自行安排”变为集群级 7×24 无人值守能力，降低对个别工程师的依赖；对小作业集群，中断累积增加运营负担，对大作业，单次中断影响更多 GPU、放大恢复算力成本，自动化对两者同时有效。
• 提出可运营的度量口径：恢复延迟、恢复成功率、恢复生产性训练所需时间。
• 默认 monitor mode 与持久审计轨迹构成渐进式信任路径，IBM Research 在其 Slurm 集群上即先以监控模式运行、将建议与人工恢复决策对比后再启用。（材料在此处截断，后续启用细节待核实。）

局限与不确定性

• 材料在 IBM Research 案例处被截断，其后续启用范围与效果待核实。
• Kubernetes 支持仍在路线图中，尚未可用；Slurm 之外的调度器集成情况待核实。
• 生产数据仅来自“一个训练集群”的三个月监控窗口，且处于监控模式下的检测统计，跨集群、跨规模的普适性待核实。
• 94 秒为恢复动作延迟，不含调度与检查点恢复时间，端到端恢复生产性训练的时长未给出。
• 可选组件 NVIDIA Attribution 的具体能力边界与独立使用方式，材料仅作概述，待核实。

可用于图书/PPT/简报的角度

• “0.005% 与 19%”：用大数定律式概率与 Meta A100 研究数据说明规模为何使故障恢复成为一等系统问题。
• 分层韧性架构图：break-fix 自动化 / 框架级 NVRx / 集群调度器 / 工作负载恢复层（NVIDIA Recovery）四层职责切分，强调无硬依赖、可插拔。
• 四阶段闭环作为恢复自动化的通用范式：检测—归因—隔离—重启/停止，配 watchdog 安全网与审计轨迹。
• “先观察后行动”的自动化上线方法论：monitor mode 默认、信噪比验证、按集群切换到 action mode，以及控制器重启时的状态检查幂等保护。
• 调度器解耦设计：通用 Advisor API 契约 + Helm 部署的 Advisor Controller + 集群内/SSH 双模式，说明如何在不动应用代码、不改调度器内部的前提下接入自动化。

原始材料

• 标题：Keep Distributed Training Running with Automated Workload Recovery | NVIDIA Technical Blog
• 来源：NVIDIA Technical Blog（NVIDIA Developer）
• 作者：Ripple Patel, Ian Gibbs, Rick Izzo, Ashwin Poojary, Dong Ahn
• 日期：Nov 02, 2026
• URL：https://developer.nvidia.com/blog/keep-distributed-training-running-with-automated-workload-recovery
• 关键词：NVIDIA Recovery, DSX OS, distributed training, workload recovery, Slurm, NVRx, NVSentinel, NCCL, checkpoint restart, goodput, anomaly detection, failure attribution, monitor mode, audit trail