在数千块GPU上训练大规模AI模型是一项高风险的工作，监控与自动化机制必须内置其中，才能在大规模场景下优化集群的弹性与正常运行时间。这一理念对数据中心运营者而言并不陌生，早在AI工厂出现之前，他们就已经在衡量平均修复时间（MTTR）和平均故障间隔时间（MTBF）。
如今，风险赌注更高了。现代AI工厂需要在数百个节点上连续运行数天甚至数周的分布式训练任务，在这种规模下，运维模式也随之改变：硬件异常、软件错误、网络超时和资源争用都必须被主动管理，才能确保工作负载按计划推进。当企业在共享基础设施上同时运行数十个这类并发的多节点工作负载时，依赖人工介入、静态检查点以及被动监控的传统方法根本无法满足规模化需求。
正因如此，像NVIDIA Mission Control中提供的自主恢复引擎这类软件服务，对于规模化生产AI至关重要。此前，这一能够在整个技术栈中检测、诊断并从异常中恢复的自主恢复引擎，仅适用于基于Slurm的高性能计算（HPC）工作负载。而在Mission Control 2.5中，该服务现已扩展至使用NVIDIA Run:ai管理的基于Kubernetes的工作负载。
本文将介绍Mission Control最新版本如何将其集成式弹性恢复框架带入Kubernetes工作负载，帮助AI工厂运营从被动式运维转向主动的自我修复型基础设施。
内置弹性服务
Mission Control自主恢复引擎背后的理念很简单：AI工厂应当是能够自我修复的系统——故障能够被即时检测，恢复决策能够基于工作负载的上下文和故障类型智能做出，任务能够自动恢复运行，同时将中断和计算资源浪费降到最低。
其目标是了解故障发生的原因，隔离异常并标记待维护，并以尽可能少的时间损耗让工作负载重新投入生产性计算。
自主恢复引擎由两项服务组成：
自主任务恢复
自主硬件恢复
由于真正的自主弹性恢复机制更应被理解为一个控制回路，而非单一的恢复功能，因此自主恢复引擎会与工作负载调度器（无论是HPC还是Kubernetes）协同工作，形成一个集成的三层框架，其中每个组件扮演着各自独立但又相互协调的角色。
本文将重点介绍基于Kubernetes的工作负载调度。
控制回路中的三个角色
首先来看Kubernetes工作负载调度层。在Mission Control中，NVIDIA Run:ai是Kubernetes的默认调度器，并作为软件的一部分内置其中。它负责管理基于Kubernetes的AI工作负载、队列、策略，并将任务调度到可用的计算资源上。
自主任务恢复服务提供工作负载上下文层。它会监控正在运行的任务，追踪每个任务的执行位置，并利用故障历史和任务拓扑结构来判断哪种恢复路径最为合理。资源管理器的集成则决定这种判断如何转化为重启、重试、重新排队或重新调度的具体动作。
自主硬件恢复服务则是基础设施健康层。它负责监控节点和GPU，在必要时将异常资源从调度中剔除，并运行诊断或修复程序，以防止硬件问题持续蔓延到新的任务中。
保持这些职责的分离正是该模型具备可移植性的关键所在。自主任务恢复服务不需要修复硬件，硬件恢复服务也不需要理解每一种训练框架。最终，调度器可以将工作负载引导至已就绪的计算资源，而无需等待根本原因诊断完成。
故障处理路径实例
以下场景展示了Mission Control的控制回路如何根据其自主恢复引擎检测到的不同故障信号作出相应的处理。
场景一：训练过程中的硬件故障
一个分布式训练任务正在一组GPU上运行，此时其中一块GPU开始出现故障。这种症状可能首先表现为ECC错误、工作进程挂起，或任务中出现通信超时。
关键在于接下来发生的事情：恢复过程会分为两条并行路径。自主任务恢复服务捕获任务上下文并识别出可疑的节点或GPU。随后，Kubernetes调度器集成模块会通过重启或重新调度任务来推进工作负载的恢复。
与此同时，自主硬件恢复服务会隔离存在问题的节点，记录故障原因，并启动诊断流程。即便工作负载已经重新运行，硬件层面的处理路径仍可继续进行。
这一路径的价值在于减少停机时间。工作负载的恢复不必等待根本原因分析完成，而故障节点也不会被意外分配给下一个任务。
场景二：瞬时性软件故障
并非每一次任务失败都应触发硬件修复流程。即使底层节点本身是健康的，训练工作进程也可能因意外退出、遇到可恢复的超时，或短暂失去协调而出现故障。
在这种情况下，自主任务恢复服务会利用任务上下文信息，避免过度反应。如果故障历史显示问题是瞬时性的，系统会根据调度器策略进行重试，而不会对无需维修的硬件进行隔离处理。
尽管NVIDIA Run:ai在表现这种恢复行为时的方式可能与Slurm有所不同，但其核心目的是一致的：在不进行不必要的硬件修复的情况下，让工作负载恢复到正常运行状态。自主硬件恢复服务会持续在后台进行监控，但除非有新的证据指向硬件问题，否则它不会介入恢复流程。
这一路径的价值在于克制。系统能够在不产生不必要的运维干扰或缩减可调度资源池的情况下，恢复工作负载的运行。
场景三：提前捕获硬件退化问题
Mission Control中的自主硬件恢复服务还能够在基础设施退化演变为任务故障之前就将其检测出来。某个节点可能开始出现反复的GPU健康警告、连接问题，或其他表明该节点在未来调度中存在风险的信号。
在这种路径下，自主硬件恢复服务可以主动将该节点从调度器的可用资源中剔除，并在AI训练任务被分配到该节点之前启动诊断流程。由于故障资源在造成工作负载中断之前就已被从资源池中移除，自主任务恢复服务可能根本无需介入响应。
在这种情况下，Mission Control基于Kubernetes的调度器能够从更干净的可用资源池中获益。它可以避免将Kubernetes工作负载分配到存在疑似问题的资源上，这与Mission Control让Slurm在故障节点重新通过验证之前将其排除在资源分配之外的方式类似。
这一路径的价值在于预防。系统降低了已知风险节点在未来演变为AI训练故障的可能性。
运维层面的影响
将Mission Control的自主恢复引擎扩展至NVIDIA Run:ai，标志着向实现自我修复型AI工厂迈出了又一步。这一架构将弹性恢复从针对特定调度器的事件处理流程，转变为一种具备调度器感知能力的运营模式。
对于平台团队而言，Mission Control 2.5在其Kubernetes和Slurm环境中提供了一致的恢复模型。故障节点会被隔离、标注或记录、诊断，并仅在准备就绪后才重新投入使用。
对于AI从业者而言，如今无论是Slurm用户还是Kubernetes用户，都能从更简化的恢复流程中获益。任务可以根据用户已在使用的调度器进行重启、重试或重新排队，同时自主恢复引擎会提供必要的上下文信息，以避免在需要维护的基础设施上反复出现故障。
对于企业而言，其价值体现在对宝贵加速计算资源的更高效利用上。系统将更少的时间耗费在模糊不清的状态中，而将更多时间用于保持训练工作负载的持续产出。
视频1：NVIDIA Mission Control基于Kubernetes工作负载自主弹性恢复功能演示
开始使用Mission Control 2.5
Mission Control 2.5现已正式发布。现有NVIDIA Mission Control用户可访问文档中心，了解如何升级到最新版本。除将自主恢复引擎扩展至基于Kubernetes的工作负载外，此次版本更新的其他亮点还包括：
新增AI驱动的网络异常检测服务（目前为测试版）
通过中央Keycloak改进各服务间身份验证的用户体验
新增安全性与Kubernetes加固更新
NVIDIA Vera Rubin NVL72早期访问支持
欲了解完整版本说明，请点击此处查阅，或阅读解决方案概览，进一步了解NVIDIA Mission Control如何通过覆盖工作负载编排、端到端监控以及自主恢复的企业级软件，简化AI工厂的运营管理。
