要点
- NVIDIA 技术博客（2026-11-02）介绍开源 NVIDIA Recovery（DSX OS）：跨集群训练作业的工作负载级自动恢复，默认 monitor 模式先出建议再动手。
- 四段闭环：Detect（日志/GPU 指标/调度信号）→ Attribute（可接 NVIDIA Attribution）→ Isolate（排除节点/停止无意义重试）→ Restart or Stop（经 Advisor API 作用到调度器）。
- 生产观测（文称单一训练集群，2026-07-09 至 10-09）：约每天 200 个作业、约 8550 次异常检测；平均检测时延 69 秒、恢复动作时延 94 秒。
- Slurm 参考 Advisor Controller 可用 Helm（in-cluster 或 SSH）；IBM Research、Verda 等被写作早期部署/合作路径；K8s JobSet/Kubeflow 在路线图。
训练规模一大，单卡「很少坏」也会变成集群「几乎天天花」。博文用一个算术钉住直觉：若单卡日无故障概率 99.9%，一万卡作业当天不中断的概率约为 0.999^10000 ≈ 0.005%。Meta 对 2.4 万 A100、11 个月的研究被引来说明：硬件故障打断的作业不到 1%，却占 GPU 运行时间的 19%——最长、最大的作业最暴露。
NVIDIA Recovery 把答案放在工作负载层控制环：不是只修节点，也不是只让每个用户自己配 NVRx，而是跨作业、全天候地检测中断、归因、隔离并按策略从检查点重启。可证伪主张是：集群 goodput 的瓶颈，越来越是恢复编排的覆盖面与时延，而不是再多一篇「如何手动重跑」的 runbook。
[1]发生了什么
Recovery 定位为 DSX OS 里独立的工作负载恢复层，与 NVSentinel/健康校验、作业内 NVRx、以及 Slurm/K8s 调度并行，无硬依赖。控制面经 HTTP/gRPC 与集群侧 Advisor Controller 说话，推荐遵循统一 API，由控制器翻译成调度动作——从而不改应用代码、也不绑死调度内部。
新部署默认 monitor：只发布「会做什么」并写入审计，不碰调度；对照人工决策后再按集群打开 action。审计记录检测模式、动作（kill/requeue/release/节点排除）、时间戳、工作负载 ID，以及若有的 Attribution 裁决。Watchdog 防止恢复决策过慢卡住正常调度。
[1]证据有多硬
机制叙述完整：Detect 识别 PyTorch/NCCL/CUDA/互连模式、挂起与相对基线的吞吐掉队；Attribute 可用调度信号与日志，并可接 Attribution；Isolate 跟踪多次尝试中的嫌疑节点；Restart/Stop 走现有检查点逻辑，连续无法写出新检查点可停掉重试。
量化证据来自「一个训练集群」三个月窗口：约每天 200 作业、约 8550 次异常检测，检测/动作均值 69/94 秒——动作时延止于自动动作，调度与检查点恢复另计。这是厂商自测运营数据，不是多站点对照试验。外部路径写到 IBM Research（先 monitor 再自主）与 Verda（VictoriaLogs 连接器），细节仍偏叙事。
[1]钢人与缺口
钢人：3 a.m. 人工读日志不可扩展；只做破损节点下线，工作负载仍可能在坏容量上重试；只做作业内库，覆盖取决于每个团队是否正确接入。Monitor-first 与审计轨迹是负责任的产品姿态。
缺口：时延与检测量未拆失败类型/成功率；「恢复成功」与「训练真正恢复」被文中区分但未给后者分布；当前以 Slurm 为主，JobSet/Kubeflow 与 job array 仍在路线图；与 Attribution 强耦合叙述可能让读者低估无 Attribution 时的能力边界。
[1]谁付钱、下一步看什么
付钱的是空转 GPU 小时与时间-到-收敛。对许多小作业，中断累积成运维负担；对大作业，单次中断乘上卡数。自动化恢复同时打这两种账单。
六个月看点：K8s 原生恢复是否按期落地；外部贡献的失败模式是否进入同一审查；以及更多站点公开 monitor→action 的误报/漏报曲线。
[1]收束
节点修复与作业内库仍然必要，但它们不是集群 goodput 的完整答案。NVIDIA Recovery 把问题写成控制环：先在工作负载边界上自动完成检测与隔离建议，再谈是否信任它动手——否则规模化训练会把稀有硬件故障放大成日常的墙钟税。
[1]