英伟达发布了 NVIDIA Mission Control 2.5，将 AI 训练作业的自动恢复范围扩展至 Kubernetes 环境。运行大规模训练的团队可在调查故障原因的同时重启作业，并隔离可疑设备，避免其被分配给后续作业。

1. 将作业恢复与硬件处置分离

此前，自愈引擎适用于使用 Slurm 处理大规模计算作业的高性能计算任务。本次则将范围扩展至由产品内置的 NVIDIA Run:ai 管理的 Kubernetes 作业。同时运营两种环境的平台团队，如今可根据作业调度方式采用同一恢复模型。

恢复流程由负责分配作业的调度器、作业恢复服务及硬件恢复服务分工承担。这就像调度人员选择运行资源，作业负责人根据失败记录和运行位置决定重试方案，设备负责人检查故障资源。

硬件自愈服务会检查节点与 GPU 状态。一旦确认异常，就将相关资源排除在调度范围之外，并开始诊断或处置。这样，作业恢复无需等待硬件修复，也能防止可疑节点再次被分配给后续作业。

2. 根据故障类型采用不同恢复路径

当 GPU 故障导致训练作业停止时，系统会利用错误信号、作业上下文、运行状态及相关信息识别可疑节点。作业恢复服务通过与调度器集成来重启或重新调度作业，硬件恢复服务则同时隔离并诊断节点。因此，作业恢复不必停下来等待原因分析完成。

反之，如果判定为临时软件错误，例如执行实际任务的工作进程退出、可恢复的超时或未在规定时间内响应，则可根据调度器策略重试作业。此时，若硬件正常，就不会进行不必要的隔离，而是继续监控硬件状态。即使尚未发生作业失败，也可依据 GPU 健康警告或连接问题将高风险节点排除在调度范围之外。

3. Run:ai 集成与安装准备

作业恢复功能已集成到 Run:ai 的 KAI 调度器中。作业提交后，系统会将日志及状态信息与失败时刻对照，判断原因来自硬件还是软件。随后更新记录运行配置与条件的作业定义，排除近期导致异常的节点，再将作业放回等待执行的队列。

自愈引擎（ARE）由作业恢复、硬件恢复和 NVIDIA Resiliency Extensions（NVRx）三部分组成。NVRx 不随 NVIDIA Mission Control 一同安装，必须单独安装，安装说明见 https://nvidia.github.io/nvidia-resiliency-ext/ 。

训练应用可另行集成 Autonomous Job Recovery Training Telemetry Client Library（自愈作业恢复训练遥测客户端库）以记录状态信息。它无需手工整理日志格式，即可自动生成由作业恢复服务监控的日志消息，涵盖吞吐量（一定时间内处理的工作量）、检查点（训练状态保存点）及停滞检测（检查作业进度是否停止），便于应用向恢复服务传递所需信息。

该训练遥测客户端可通过以下命令从 NVIDIA PyPI 安装。

pip install --extra-index-url https://pypi.nvidia.com --upgrade aidot_training_telemetry

4. 先确认适用的作业与设备

发行说明的组件表显示，DGX B200·B300 和 GB200·GB300 NVL72 系列支持作业管理及两个自愈组件。对于使用现有受支持设备的团队而言，这提供了扩展 Kubernetes 训练恢复流程的选项。

发行说明明确指出，作业恢复适用于使用 Kubeflow PyTorch 训练算子的作业。Vera Rubin NVL72 在本次发行中仅获得必要的初始启动支持，不支持 Run:ai 和自愈引擎。

5. 减少人工处置，但需做好集成准备

自动恢复的好处在于，作业重启不必推迟到设备修复完成，也能减少因临时软件错误而隔离正常设备的情况。英伟达表示，这种分离有助于缩短停机时间，减少不必要的资源浪费。

作为代价，运维团队仍需完成训练应用的日志集成、恢复组件安装等准备工作。硬件自愈已移除 Datadog、FluentBit、Elastic 集成，因此，重新审视依赖这些工具的可观测性路径，即收集和检查系统状态的方式，也成为引入成本的一部分。

Mission Control 2.5 的价值在于将作业恢复与设备诊断分离，让 Kubernetes 训练的恢复从人工处置转向相互集成的运维流程。