NVIDIA Recovery：用四阶段控制循环自动化集群训练故障恢复

当分布式 AI 训练规模扩大，硬件和软件依赖的故障不断打断训练进度：一个卡住的训练 rank 可以触发 NCCL 超时，一个 GPU 节点可以停止响应调度器，一个慢节点可以拖慢整个任务。每次中断单独看都可以处理，但累积影响和恢复开销决定了系统将墙上时间转化为有效训练进度的效率。人工恢复在必须覆盖集群中每个训练任务、全天候、大规模时变得不可持续——每次中断都需要日志分析、故障隔离和从检查点重启，受影响 GPU 在恢复期间持续空转。

NVIDIA Recovery 的核心设计判断是：工作负载恢复是一个独立的协调问题，不能由基础设施修复或框架级库单独解决。Break-fix 自动化识别故障节点并将其移出服务；NVRx 等框架级库提供单个任务内部的恢复和挂起检测，但需要每个用户自行配置和管理；Slurm 等调度器管理资源分配、排队和容器执行。工作负载恢复需要的是跨任务的集群级控制循环——将故障归因到根因、决定受影响任务是否及在哪里重启、并在共享基础设施的任务之间保持一致行动。

该服务将恢复组织为四个阶段。检测阶段结合应用日志和调度器信号识别崩溃、挂起和慢节点，能识别 PyTorch/NCCL 故障、CUDA 错误和互连失败模式；缺失进度信号或已识别的通信挂起模式指示潜在挂起，相对近期基线的持续吞吐下降指示潜在慢节点。归因阶段利用检测收集的证据对中断分类，引导恢复决策；可选集成 NVIDIA Attribution 以区分硬件故障、系统软件问题和应用缺陷，运维也可接入自有归因服务。隔离阶段由 Anomaly Remediator 执行建议，排除涉事节点或停止进一步重试，并跟踪跨次尝试的问题节点以避免重复失败；一个看门狗服务作为安全网，在恢复决策超时或失败时允许正常调度继续，防止任务无限等待。重启或停止阶段通过 Advisor API 通知调度器执行操作，任务从最近检查点恢复，若跨可配置次数仍无法保存新检查点则停止重试。

文章在论证问题为何在集群规模下加剧时引用了 Meta 对 24000 张 A100 的 11 个月研究：硬件故障中断了不到 1% 的任务，但这些任务占了 19% 的 GPU 运行时间——最大、最长的任务暴露最严重。即使单 GPU 日无故障概率达到 99.9%，一个横跨 10000 张 GPU 的任务当天不间断完成的概率也仅约 0.005%。NVIDIA 报告了自身单一训练集群 7 月 9 日至 10 月 9 日的监控数据：覆盖近 200 个日任务，记录约 8550 次异常检测，平均检测延迟 69 秒、恢复动作延迟 94 秒。这是厂商自报数据，来自单一集群，且文章明确指出 94 秒仅到自动化动作完成为止——调度排队和检查点恢复决定实际何时恢复有效训练。未提供恢复成功率、误报率或与其他方案的对比基线。

新部署默认进入监控模式，发布恢复建议但不执行调度器操作，运维人员可对比建议与自身工程师的判断，确认信噪比后再切换至行动模式。IBM Research 在 Slurm 集群上走了这条路径：先运行监控模式、与人工恢复决策对比、验证信号后启用自主行动。集成方式为 Slurm 提供 Advisor Controller，支持集群内和 SSH 两种模式，通过 Helm chart 部署，使恢复服务独立于调度器内部实现。当前版本仅支持 Slurm（含通过 slurm-operator 运行的 Slurm on Kubernetes），原生 Kubernetes 恢复（JobSet、Kubeflow PyTorchJob）在路线图中。