NVIDIA开源集群级训练恢复服务：单集群日均近200个作业，检测与恢复动作平均69秒和94秒
核心概要
分布式训练规模扩大后，单卡故障会随集群规模累积，而逐作业手工排查日志、隔离故障、从检查点重启已难以覆盖整个集群。NVIDIA 以 Apache 2.0 开源 NVIDIA Recovery，这一工作负载级服务结合应用日志、GPU 指标与调度器信号，完成检测、归因、隔离和重启或停止四个阶段，并通过 Advisor API 与 Slurm 对接。在一个训练集群上，7月9日至10月9日的监控覆盖日均近200个作业，记录约8550次异常检测，检测与恢复动作的平均延迟分别为69秒和94秒。
深度剖析
集群级训练恢复从工程师逐作业手工处理，变成一个持续运行、跨作业协调的自动化控制回路。 此前每次中断都需要分析日志、隔离故障并从保存的检查点重启，受影响的 GPU 在恢复期间保持空闲；作业数量和规模增长后，重叠故障会加重工程负担并浪费 GPU 小时。 在一个训练集群上，7月9日至10月9日的监控覆盖日均近200个作业，记录约8550次异常检测，检测与恢复动作的平均延迟分别为69秒和94秒。
恢复回路按检测、归因、隔离、重启或停止四个阶段推进，每一步的动作由中断类型和配置策略决定。 异常检测器把应用日志与调度器信号合在一起，识别崩溃、挂起和掉队者，可辨认 PyTorch 与 NCCL 失败、CUDA 错误和互连故障模式；进度信号缺失或已知通信挂起模式提示挂起，吞吐相对近期基线持续下降提示掉队者。 该服务以控制面形式运行，通过 HTTP 或 gRPC 接口与集群调度器集成，当前支持 Slurm，Kubernetes 支持列在路线图上；恢复建议遵循统一 API 契约，由集群侧控制器翻译成工作负载管理器的动作，因此不需要改动应用代码。
隔离阶段把被判定有问题的节点排除在后续重启尝试之外，必要时直接停止工作负载，并用看门狗兜底。 归因环节用检测阶段收集的调度器信号和应用日志对中断分类，可选接入 NVIDIA Attribution 进一步区分硬件故障、系统软件问题和应用缺陷，这些证据用于节点排除并写入审计记录。 异常修复器跨多次尝试跟踪涉事节点以避免重复失败；若恢复决策耗时过长或直接失败，看门狗服务允许正常调度继续，防止工作负载无限等待。
启示与展望
已演示的范围是 Slurm 作业的恢复，包括通过 slurm-operator 在 Kubernetes 上运行的 Slurm；服务以控制面形式部署，通过 HTTP 或 gRPC 与调度器集成，新部署默认处于只观察模式，只发布建议而不采取调度动作。IBM Research 在其 Slurm 集群上先运行只观察模式，把建议与自身手工恢复决策比对后再启用自主动作；Verda 在 VictoriaLogs 而非 Loki 上部署，并贡献了 VictoriaLogs 连接器。
恢复动作延迟止于自动动作本身，调度和检查点恢复才决定有效训练何时真正恢复。当前版本恢复 Slurm 作业，Slurm 作业数组和原生 Kubernetes 恢复（从 JobSet 与 Kubeflow PyTorchJob 开始）列在后续计划中；更细的故障分类、把每次恢复决策更完整地暴露到仪表盘和 API，以及走向稳定版本同样在路线图上。