NVIDIA Mission Control 2.5将自主恢复引擎扩展至Kubernetes工作负载

自主恢复引擎如何与Kubernetes调度配合

NVIDIA将Mission Control的自主恢复引擎描述为一个控制循环，由两个服务组成：自主作业恢复和自主硬件恢复。在Kubernetes场景下，该引擎与NVIDIA Run:ai调度器配合，形成三层分工。

Run:ai在Mission Control中是Kubernetes默认调度器并随软件提供，管理工作负载、队列和策略，把作业调度到可用容量上。自主作业恢复服务跟踪正在运行的作业及其执行位置，结合失败历史和作业拓扑判断应走哪种恢复路径。自主硬件恢复服务监控节点和GPU，在需要时将异常节点移出调度，并运行诊断或修复。

NVIDIA称，把职责分开使这套模型具备可移植性：作业恢复服务不需要修复硬件，硬件恢复服务也不需要理解每种训练框架；调度器则可以把工作负载导向就绪容量，而不必等待根因诊断完成。

• 自主作业恢复：提供作业上下文，判断重启、重试、重新排队或重新放置
• 自主硬件恢复：监控节点与GPU，隔离异常并执行诊断或修复
• Run:ai调度器：负责Kubernetes工作负载的队列、策略与放置

三种故障路径的处理差异

博客用三个场景说明控制循环如何根据故障信号做出不同反应。第一个场景是训练中的硬件故障：某块GPU开始出现ECC错误、worker挂起或通信超时。作业恢复服务捕获作业上下文并识别可疑节点或GPU，调度器集成随后重启或重新调度作业；同时硬件恢复服务隔离问题节点、记录原因并启动诊断，这条硬件路径可以在工作负载已经转移后继续。NVIDIA称这一路径的价值是减少停机，作业不必等待根因分析就开始恢复，故障节点也不会被交给下一个作业。

第二个场景是可恢复的软件故障：训练worker退出、遇到可恢复的超时或短暂失去协调，但底层节点健康。作业恢复服务根据作业上下文和失败历史判断故障是暂时性的，按调度策略重试，而不隔离不需要维修的硬件。NVIDIA称这一路径的价值是克制，避免不必要的运维噪音和调度池缩小。

第三个场景是硬件退化被提前发现：节点出现反复的GPU健康警告或连接问题。硬件恢复服务可以在训练作业落到该节点之前，主动将其移出调度器可用范围并开始诊断，作业恢复服务可能根本不需要介入。NVIDIA称这一路径的价值是预防。

• 硬件故障：作业恢复与硬件诊断并行，节点被隔离并记录
• 软件故障：按调度策略重试，不触发硬件隔离
• 硬件退化：在作业失败前将可疑节点移出调度池

版本范围与已知限制

NVIDIA称Mission Control 2.5已可用，现有用户可查阅文档了解升级。除将自主恢复引擎扩展到Kubernetes工作负载外，该版本的其他亮点包括：新的AI网络异常检测服务，但仅处于beta；通过中央Keycloak改进跨服务认证体验；额外的安全与Kubernetes加固更新；以及NVIDIA Vera Rubin NVL72的早期访问。

需要区分的是，博客对恢复效果的评价来自NVIDIA自身的产品说明和演示。来源没有给出具体客户部署数量、平均修复时间的变化、避免的停机时长或算力利用率提升比例，因此无法据此判断该版本在实际生产环境中的量化收益。

• 自主恢复引擎的Kubernetes支持面向使用NVIDIA Run:ai的工作负载
• AI网络异常检测服务为beta版本
• 博客未提供客户侧效果数据