NVIDIA Mission Control 2.5把自动恢复扩展到Run:ai管理的Kubernetes任务

英伟达在十月二十六日发布文章，说明 Mission Control 2.5 把自动恢复引擎扩展到由 NVIDIA Run:ai 管理的 Kubernetes 工作负载。此前这套服务主要支持使用 Slurm 的高性能计算任务。十月二十八日是本期刊期，不能写成新版本的原公告日。文章介绍了产品范围和处理路径，但没有给出平均修复时间缩短多少、可用率提升多少，或与人工值守的受控比较。因此“自动恢复”应理解为厂商所描述的功能机制，不应被改写成本站已经验证的产能收益。

架构可分为三种职责。Kubernetes 调度器把任务放到有资格运行的节点；自动任务恢复服务保留失败时的作业上下文，分析故障种类，决定重启、重新调度还是升级处理；自动硬件恢复服务识别问题设备、隔离节点并运行诊断。把任务恢复和硬件修复分开，意味着作业有机会先迁往健康资源，而故障节点不会立即接到下一个任务。这是设计意图，不能由此推断任何训练框架都能从任意时刻无损续跑。具体能恢复多少工作，还要看检查点、作业配置和调度策略。

原文用硬件故障说明并行路径。一个 GPU 在分布式训练中出现错误，症状可能是纠错码错误、工作进程挂起或通信超时。任务恢复服务捕获上下文，调度器尝试在健康资源上重启或迁移作业；硬件恢复服务同时把可疑节点设为不可调度，记录原因并开始诊断。两条路径互不必等待完整根因分析。这可以避免同一故障设备继续影响后续作业，但文章没有报告这种事件的实际发生率，也没有保证在所有故障下都能不中断服务。

第二种情况是暂时的软件问题。工作进程退出或短时失去协调，并不必然意味着 GPU 坏了。任务恢复服务可依据历史信号和调度策略重试，不让硬件服务无谓地隔离健康节点；重复或不可重试的错误则需要跳出自动路径并提示处理。第三种情况是提前发现硬件退化。节点若不断出现健康警告或连接问题，硬件服务可先把它排除在可调度资源之外，再启动诊断，避免新作业落在高风险机器上。三种案例说明同一引擎须区分故障来源，而不是对所有失败一律重试或一律隔离。

对于运行者，判断自动恢复是否有效，需要在自己的集群里记录故障注入前后的作业完成率、检查点损失、空闲节点数量及恢复时延。若误把软件错误当成硬件故障，健康算力会被锁住；若误把硬件退化当作短暂超时，作业可能反复失败。原文图示的是预期控制流，并非事故样本统计。它指向版本说明与文档，其中还提及 AI 辅助网络异常检测；这也不能填补本文缺少的量化恢复效果。可核实的新事实是对 Kubernetes 加 Run:ai 的支持范围扩展及其三层协同方式。

这一发布与本站十月二十六日刊出的另一篇 Minerva 遥测和任务关联报道，关注点不同；那篇报道所依据的英伟达原文发布于十月二十二日。Minerva 侧重把设备信号与工作负载对应起来；Mission Control 2.5 本文讲故障发生后的自动任务和硬件恢复。两者同属 AI 工厂运营范畴，但不能把一篇文章中的实验数字移到另一篇。审查标题和摘要时，应明确本稿没有独立测得可用率、成本或 GPU 产出提升，以免把功能发布写成性能评测。

运行手册还需要明确自动路径的边界。若某类故障被判断为不可重试，系统应把原因和已采取的动作交给值班人员；若重新调度发生在多节点作业中，应检查其他节点是否同步重启、检查点是否一致。英伟达文章只描绘一般场景，没有列出所有框架的恢复语义。一个受控试点可以分别注入硬件错误、短暂软件失败和缓慢退化，观察节点隔离与任务迁移是否如预期发生，并保留误判案例。这样的测量属于部署方下一步工作，不能当成本次公告已有成绩。