英伟达开源NVIDIA Recovery，自动处理集群训练任务中断
英伟达发布开源工作负载级恢复服务NVIDIA Recovery，通过应用日志、GPU指标和调度器信号检测训练中断，自动隔离问题节点并从检查点重启任务，目前支持Slurm，Kubernetes支持在路线图中。
AI解读：NVIDIA Recovery处理的是集群层面的恢复协调问题，而非单个任务内部的挂起检测。按照英伟达的说法，NVRx等框架级库负责单个训练任务内的恢复与挂起检测，但需要每个用户自行配置；NVIDIA Recovery则跨任务管理重启、放置和节点排除。
对使用Slurm的集群，NVIDIA Recovery以控制面服务运行，通过HTTP或gRPC与调度器集成通信，恢复建议经Advisor API由集群侧控制器执行。它可以部署在集群内，也可以用SSH模式从外部连接，后者适用于新增集群组件需要变更窗口或安全审查的场景。
新部署默认进入monitor模式：只发布建议、记录“本会执行”的动作，不操作调度器。英伟达建议先把建议与自己工程师的人工决策比对，满意后再按集群切换到action模式。IBM Research称其先在该校Slurm集群上运行monitor模式并比对人工恢复决策，验证信号后才启用自动操作。
英伟达给出的数字界线值得注意：自动恢复动作延迟的终点是执行动作本身，之后调度与检查点恢复才决定训练何时真正恢复。该公司披露，7 月 9 日至 10 月 9 日在一个训练集群上监控到日均近 200 个任务、约 8550 次异常检测，检测与恢复动作的平均延迟分别为 69 秒和 94 秒；这些是英伟达自述的生产观测，未给出恢复成功率或训练产出提升数据。
任务可通过sbatch脚本中的一条指令选择启用，传入环境名与模式。代码以Apache 2.0许可发布在dsx-ai-factory/NVIDIA-Recovery仓库，随附一个无需物理GPU的快速入门。英伟达称后续将支持Slurm任务数组，并原生支持JobSet与Kubeflow PyTorchJob等Kubernetes工作负载。
英伟达技术博客发文介绍NVIDIA Recovery：这是一个开源的工作负载级服务，用于在集群范围内自动恢复被中断的分布式训练任务。它属于英伟达DSX OS软件组合，以Apache 2.0许可发布在dsx-ai-factory/NVIDIA-Recovery GitHub仓库。
该服务通过应用日志、GPU指标和调度器信号检测中断，进行故障归因以定位相关资源，再执行节点隔离并从健康容量上的检查点重启任务。当前支持Slurm，Kubernetes支持被列为路线图内容。
与框架级恢复的分工
英伟达把集群恢复拆成多层：节点健康监控与隔离依赖集群编排栈，比如Kubernetes上用NVSentinel监控GPU健康指标和XID事件并封锁、排空故障节点，许多Slurm站点用自定义prolog/epilog脚本检查节点健康；任务内部的恢复与挂起检测由NVRx等库负责。
英伟达称，NVIDIA Recovery填补的是任务内重启够不到的缺口——跨工作负载的生命周期管理和节点排除。这些层之间没有硬依赖，可分别采用或接入自有组件；博客称已有NVSentinel或NVIDIA Health Validation的集群可以基本不改原有健康流程地集成。
可选的NVIDIA Attribution用于提供更深的诊断结论，区分硬件故障、系统软件问题和应用缺陷，并充实审计记录。英伟达称运营方也可接入自己的归因服务，单独采用NVIDIA Recovery。
- 检测：异常检测器结合应用日志与调度器信号识别崩溃、挂起和掉队任务，可识别PyTorch、NCCL失败、CUDA错误和互连故障模式
- 隔离：异常修复器将问题节点排除在后续重启尝试之外，跟踪多次尝试中的问题节点；看门狗服务在恢复决策过慢或失败时放行正常调度，避免任务无限等待
- 重启或停止：调度器集成通过Advisor API执行建议，任务用现有重启逻辑从最近检查点恢复；若连续多次未能保存新检查点，可停止无意义重试
- 审计：每条记录包含匹配的检测模式、所采取动作（kill、requeue、release或节点排除）、时间戳、工作负载标识，以及返回时的Attribution结论
部署方式与已知限制
NVIDIA Recovery以控制面服务运行，恢复建议遵循统一API约定，由集群侧控制器翻译为工作负载管理器的动作，英伟达称这样可让服务不依赖调度器内部实现，也无需改动应用代码。Slurm的参考Advisor Controller以Helm chart形式提供。
每项恢复建议在控制器执行前先被记录，形成预期动作的审计记录；若控制器在恢复过程中重启，会先检查当前调度器状态再继续，以防重复执行已完成动作。Recovery Console是运营面板，展示跨调度器类型的实时任务状态、异常标记和每个任务的事件时间线。
首次让一个任务进入恢复流程分三步：安装Helm chart（随附MySQL子chart供本地快速启动，生产环境指向托管MySQL）、用日志摄取配置器校验现有Loki或Victoria Logs与Prometheus信号、在sbatch脚本中加一条指令选择启用。
- 新部署默认monitor模式，只发布建议不操作调度器；验证信号噪声比后，在Helm配置中把模式改为action并开启acknowledgeSchedulerActions
- 英伟达给出的规模理由：若单块GPU日无故障概率为 99.9%，1 万块GPU的任务当天不中断完成的概率约为 0.005%；其引用Meta一项为期 11 个月、覆盖 2.4 万块A100的研究称，硬件故障中断的任务不足 1%，但这些任务占GPU运行时长的 19%
- 英伟达所称的后续计划：Slurm任务数组恢复、以JobSet和Kubeflow PyTorchJob起步的原生Kubernetes恢复、更细的故障分类和稳定版本
- Verda称其使用VictoriaLogs而非Loki部署，并为此贡献了VictoriaLogs连接器