英伟达把自愈恢复引擎接进Kubernetes：故障节点先隔离，训练任务不必等根因诊断
核心概要
英伟达 Mission Control 2.5 把原本只服务 Slurm 高性能计算负载的自主恢复引擎扩展到由 NVIDIA Run:ai 管理的 Kubernetes 工作负载。此前这类 AI 工厂依赖人工干预、静态检查点和被动监控，难以支撑数十个并发多节点训练任务。新版本把工作负载放置、作业恢复与硬件恢复分成三层协同：作业侧依据失败历史和作业拓扑决定重启、重试或重新排队，硬件侧隔离可疑节点并做诊断，使恢复不必等待根因分析。
深度剖析
大规模 AI 训练集群的故障恢复从只覆盖 Slurm 高性能计算负载，扩展到由 NVIDIA Run:ai 管理的 Kubernetes 工作负载。 此前 Mission Control 的自主恢复引擎只能用于基于 Slurm 的高性能计算工作负载，而依赖人工干预、静态检查点和被动监控的传统做法在数十个并发多节点任务共享基础设施时难以扩展。 Mission Control 2.5 已发布，现有用户可迁移到该版本；该版本同时提供仅限 beta 的 AI 网络异常检测服务、基于中央 Keycloak 的统一认证改进、额外的安全与 Kubernetes 加固更新，以及 NVIDIA Vera Rubin NVL72 的早期访问。
恢复被拆成作业恢复与硬件恢复两条并行路径，训练任务不必等根因诊断完成就能重新开始。 自主恢复引擎由自主作业恢复和自主硬件恢复两个服务组成，前者跟踪作业运行位置并依据失败历史和作业拓扑判断恢复方式，后者监控节点与 GPU、把异常节点移出调度并运行诊断或修复。 在 GPU 开始失效的场景中，症状可能先表现为 ECC 错误、工作进程挂起或通信超时，作业侧随即重启或重新调度任务，硬件侧同时隔离该节点、记录原因并启动诊断，硬件路径可在工作负载恢复后继续。
系统会区分瞬时故障与硬件故障，避免对健康节点做不必要的隔离。 当训练工作进程退出、遇到可恢复超时或短暂失去协调而节点本身健康时，作业恢复服务依据失败历史判断故障为瞬时，按调度器策略重试，而不是隔离无需维修的硬件。 硬件恢复服务在后台持续监控，除非出现指向硬件的新证据，否则不进入恢复路径；该路径的目的是在不制造多余运维噪声、不缩小调度池的前提下恢复工作负载。
硬件恢复服务还能在故障演变为作业失败之前主动把退化节点移出调度资格。 节点可能先出现反复的 GPU 健康告警或连接问题，这类信号使其不适合后续调度，硬件恢复服务可提前将其移出并启动诊断，作业恢复服务可能根本不需要响应。 该做法与 Mission Control 让 Slurm 在节点重新验证前将其排除在分配之外的方式类似，使基于 Kubernetes 的调度器面对更干净的可用资源池。
启示与展望
该恢复引擎面向在共享基础设施上运行多节点 AI 训练任务的平台团队，覆盖由 NVIDIA Run:ai 管理的 Kubernetes 工作负载以及原有的 Slurm 工作负载；来源未给出量化的停机或修复时间指标。
来源以场景叙述说明恢复行为，未报告平均修复时间、平均故障间隔或恢复成功率的实测数据；网络异常检测服务在 2.5 版本中仅处于 beta，Vera Rubin NVL72 支持为早期访问。