NVIDIA Mission Control 2.5 为
来自 NVIDIA Developer · 期号 2026-10-26
摘要
AI 工厂里跑着几百个 GPU 的分布式训练，一次硬件故障就可能让几天的计算白费。传统靠人工介入和静态检查点的做法，在这种规模下撑不住。 NVIDIA Mission Control 2.5 把自主恢复引擎扩展到了 Kubernetes 工作负载（由 Run:ai 管理）。引擎分三层：Kubernetes 调度器负责放任务，自主任务恢复服务根据失败上下文判断该重启还是重试，自主硬件恢复服务隔离故障节点并跑诊断。 硬件故障时，任务恢复和硬件修复并行跑——任务被重新调度到健康节点，故障节点同时被隔离诊断。软件瞬态错误则只重试，不触发硬件修复。硬件恢复服务还能在故障发生前就检测到退化信号，把有风险的节点提前移出调度池。 对平台团队来说，这套模型在 Kubernetes 和 Slurm 两套调度器上保持一致。故障节点被隔离、标注、诊断，修好了才放回池子。 原文是技术详解，附了架构图和故障场景的完整流程。
深读
导读 AI 工厂中跨数百节点、数千 GPU 的分布式训练一旦遭遇硬件故障，传统依赖人工介入和静态检查点的恢复方式会浪费大量算力。NVIDIA Mission Control 2.5 将其自主恢复引擎从 Slurm 扩展到 Kubernetes 工作负载（由 Run:ai 管理），通过三层控制回路实现故障的自动检测、分类与并行恢复。读完可以理解这套引擎如何区分硬件故障与软件瞬态错误、如何在故障发生前提前隔离退化节点，以及它对平台团队和业务的实际价值。 关键信息 - Mission Control 2.5 的自主恢复引擎由三个组件构成：Kubernetes 调度器（Run:ai）、自主任务恢复服务、自主硬件恢复服务，三者形成控制回路。 - 硬件故障时，任务恢复与硬件修复并行执行：任务被重新调度到健康节点，故障节点同时被隔离并启动诊断。 - 软件瞬态错误（如训练进程退出、可恢复超时）只触发任务重试，不触发硬件修复，避免不必要的节点隔离。 - 自主硬件恢复服务可在故障发生前检测到退化信号（如 GPU 健康警告、连接问题），将风险节点提前移出调度池。 - Mission Control 2.5 在 Kubernetes 和 Slurm 两套调度器上提供一致的恢复模型：故障节点被隔离、标注、诊断，修好后才能重新加入调度池。 逐节讲解 自主恢复引擎的架构设计 Mission Control 的自主恢复引擎由两个服务组成：自主任务恢复服务和自主硬件恢复服务。它们与工作负载调度器（Kubernetes 或 Slurm）配合，构成一个三层控制回路。在 Kubernetes 场景下，Run:ai 作为默认调度器负责放置工作负载；自主任务恢复服务监控运行中的任务，利用失败历史和任务拓扑判断恢复路径（重启、重试、重新排队或重新放置）；自主硬件恢复服务监控节点和 GPU，必要时将异常节点移出调度并运行诊断。职责分离使得模型可移植：任务恢复服务不需要修复硬件，硬件恢复服务不需要理解训练框架，调度器可以直接将工作负载导向就绪容量。 三种故障场景的恢复路径 场景一：训练中的硬件故障。 当 GPU 出现 ECC 错误、工作进程挂起或通信超时时，恢复分为两条并行路径。任务恢复服务捕获任务上下文并识别故障节点，通过 Kubernetes 调度器将任务重启或重新调度到健康节点。同时，硬件恢复服务隔离故障节点、记录原因并启动诊断。工作负载不必等待根因分析即可恢复，故障节点也不会被错误地分配给下一个任务。 场景二：软件瞬态错误。 如果任务失败历史显示为瞬态错误（如进程退出、可恢复超时），系统只根据调度策略重试，不隔离硬件。硬件恢复服务继续在后台监控，但不介入恢复路径，除非出现新的硬件证据。这避免了不必要的节点隔离和运维噪音。 场景三：硬件退化提前检测。 当节点出现重复的 GPU 健康警告或连接问题时，硬…