训练一个万亿参数模型，你有多少分钟能用来浪费？
Meta 的 Llama 3 405B 在 16384 张 H100 上训练了 54 天，期间发生了 419 次意外中断，平均每 3.1 小时一次。其中 148 次来自 GPU 自身故障，72 次来自 HBM3 内存故障。业界据此推算，H100 在持续负载下的年化故障率约 9%——虽然这只是 54 天观测数据的数学外推，并非实测寿命数据，但它指向一个残酷事实：万卡集群的硬件在统计学意义上一定会坏。问题从不是会不会坏，而是坏了之后，你要花多久才能回来。
GPT-4 的训练用了 25000 张 A100，跑了 90 到 100 天，算力利用率 MFU 仅 32% 到 36%。它采用 MoE 架构，总参数量约 1.8T，每 token 激活约 280B 参数。业界分析指出，其中的关键损耗之一正是故障恢复过程中的高开销检查点操作。OpenAI 甚至在早期因检查点损坏损失过 72 小时的训练进度，对应数百万美元的计算资源浪费。
传统方案下，一次 GPU 故障意味着 NCCL 通信超时等待，Kubernetes CrashLoopBackOff 风暴，全量拉取镜像和检查点恢复——整个过程 4 分钟以上算快的。在 16384 卡集群上，如果每 3 小时中断一次、每次恢复 5 分钟，一天白白损失约 40 分钟训练时间。乘以 90 天训练窗口，就是 60 个小时——对于 H100 集群，等效于数十万美元的直接成本，还不算模型延迟上线带来的竞争损失。
2026 年 9 月，AWS 发布了一篇博客，展示了如何将 NVIDIA Resiliency Extension（NVRx）集成到 Amazon EKS 上的 PyTorch FSDP 训练中。这一方案用三种机制将故障恢复从分钟级压入秒级：异步检查点、进程内重启、以及 ft_launcher 作业内重启。在 2 到 8 节点 H100 GPU 集群上的基准测试显示，训练效率维持在 99% 以上，恢复时间缩短到 10 秒以内。
这组数字可能标志着一个拐点：大模型训练的故障恢复，正从不可抗力走向可管理的工程问题。
从坏了重来到坏了接着跑
要理解 NVRx 的价值，先要理解分布式训练故障恢复的底层账本。
一个大模型训练作业在成千上万张 GPU 上同步运行，通过 NCCL（NVIDIA 集体通信库）做梯度同步。任何一张 GPU 故障——无论是硬件 XID 错误、HBM 内存损坏还是 InfiniBand 链路中断——都会导致整个通信组中的其他 GPU 进入等待状态，最终超时崩溃。
传统的恢复流程像一场多米诺骨牌崩塌：单卡故障导致 NCCL 超额等待，容器被 Kubernetes 标记为 CrashLoopBackOff，存活检查反复失败，重新拉取镜像，从对象存储加载最新检查点，重新初始化分布式通信组，恢复训练。整个过程 4 分钟起步，每一次都在燃烧数千 GPU 分钟的成本。
更隐蔽的损失来自检查点本身。为了在故障时最小化训练进度损失，团队必须频繁写入检查点——通常每 1000 step 甚至更短间隔写入一次。传统同步检查点（torch.save）会阻塞训练主线程，等待 I/O 完成。当模型参数达到数百 GB 时，同步检查点的阻塞时间可能长达数分钟。AWS 和 NVIDIA 的方案从两个方向切入：让检查点不阻塞，让恢复不需要走容器生命周期。
NVRx 的三层防御
NVRx 是 NVIDIA 推出的 Python 层工具包，通过 pip install nvidia-resiliency-ext 即可接入。它不需要自定义内核，不需要 fork PyTorch 源码，不需要重新编译，以普通 import 的方式直接嵌入现有的 FSDP 训练脚本——模型代码和训练逻辑无需改动。它的三个核心能力彼此独立，团队可按需集成。
异步检查点：把 IO 藏进训练里
NVRx 的异步检查点机制将写入操作从训练主线程剥离。后台 I/O 线程在训练 step 进行的同时完成数据持久化，训练进程不需要停下来等待磁盘。
AWS 的基准测试以 LLaMA-3.1-8B 模型在 FSDP 配置下进行，对比了异步检查点（NVRx）和同步检查点（torch.save）。结果非常直接：从 2 节点（16 GPU）扩展到 8 节点（64 GPU），异步检查点的训练效率始终保持在 99% 以上。也就是说，检查点引入的额外时间开销不到 1%。
这种优势在检查点频率加大时更加突出。当同步检查点的开销随写入频率线性增加时，异步方案的边际成本几乎为零。团队因此可以采用更激进的检查点策略——每 100 step 甚至更短间隔——而不必担心训练效率的折损。
进程内重启：10 秒回到训练
很多 GPU 故障属于软故障——程序抛出 Python 异常、死锁或活锁，进程本身还在，但训练已经卡死。传统方案下，这类故障也得走完整的容器销毁重建流程。
NVRx 的进程内重启能在不重启容器、不重新初始化 PyTorch 进程组的情况下恢复训练。它通过在故障发生时直接捕获异常、清理 NCCL 通信器、从内存中的最新检查点状态重启训练来实现，省掉了容器拉起、镜像拉取、进程注册等所有层级的开销。AWS 博客的基准测试显示恢复时间约为 10 秒，与 baseline K8s 方案所需的 4 分钟以上形成两个数量级的差距。
ft_launcher：硬故障的逃生舱
硬故障——SIGKILL、GPU 从总线脱落（XID 79）、节点宕机——会导致进程彻底消失。进程内重启派不上用场。
ft_launcher 是 NVRx 配套的启动器组件。它自动检测失败的 worker，在已有节点上重新拉起替换进程，而不是等待 Kubernetes 重新调度新的 Pod。它的核心价值在于跳过了 Kubernetes 的 CrashLoopBackOff 等待和调度决策周期。虽然硬故障恢复比进程内重启稍慢，但相比默认 K8s 恢复路径仍有数量级的提升。
用 seed 控制随机故障的实验哲学
AWS 博客中的基准测试方法值得单独拎出来说。团队没有被动等待真实故障发生，而是在训练脚本中植入故障注入逻辑，用固定 seed 确保每次实验触发完全相同的故障序列。一次实验运行注入 5 次故障，分别测试 baseline K8s 恢复、ft_launcher 恢复和 NVRx 进程内重启三种方案。
检查点开销测试则独立进行，不注入故障，直接对比异步和同步检查点在相同训练量下的 wall-clock 时间差异。
这种实验设计的价值在于公正和可复现。任何一个 AWS 客户都可以在 EKS 集群上复现完全相同的测试、验证结果，而不需要等一次真正的 GPU 硬件故障来检验方案的可靠性。
99%+ 训练效率意味着什么
要理解 99%+ 训练效率的真正意义，需要把它放进行业背景来看。
据业界分析，GPT-4 训练期间的 MFU 仅 32% 到 36%。虽然 MFU 低的主因是计算与通信之间的负载不平衡以及 attention 机制的带宽需求，但故障恢复和检查点开销在其中占有相当比重。当模型参数从 8B 走向 70B、405B 乃至 1T，检查点文件从几 GB 膨胀到几百 GB 甚至 TB 级别，同步写入的阻塞效应会成倍放大。
在万卡集群上，每 1% 的效率提升对应的都是数千乃至数万 GPU-hours 的节约。99% 的训练效率意味着检查点开销几乎可以忽略不计——你花在存进度这件事上的算力，还不到总量的 1%。
NVRx 的秒级恢复更进一步改变了团队的运维策略。当一次恢复只需要 10 秒而不是 4 分钟时，你可以在同一个训练窗口中承受远多于以往的故障次数而不明显影响完成时间。这意味着团队可以在检查点开销和故障损失之间做出更激进的抉择——与其担心坏了损失多少，不如大胆地频繁存档。
为什么是 EKS
AWS 选择在 EKS 上验证 NVRx 并非偶然。
Kubernetes 的默认 Pod 恢复机制是为无状态 Web 服务设计的，对分布式训练而言存在天然缺陷。NCCL 的通信组对成员变化极度敏感——一个 Pod 崩溃，整个组都得等待超时。Kubernetes 的 CrashLoopBackOff 等待机制在 Web 服务场景下是合理的保护阀，但对训练作业来说，每一次退出-等待-重试周期都在浪费数千美元的算力。
EKS 的优势在于它提供了更细粒度的控制。AWS 团队展示了如何通过自定义 Operator 和副容器与 NVRx 配合，在 Kubernetes 框架下实现接近裸机性能的故障恢复。对那些已经在云原生生态中有大量投入、但又想获得 HPC 级别容错能力的团队来说，这是一个重要的过渡方案。
值得注意的是，NVRx 与 SageMaker HyperPod 的配合也在同步推进。SageMaker HyperPod 近期推出了托管分层检查点能力，进一步降低了团队的运维复杂度。AWS 的策略是让用户在管理 Kubernetes 和托管服务之间自由选择，而 NVRx 在两套方案中都可以发挥作用。
边界与局限
NVRx 的容错能力有明确的边界。
首先，它只解决判断作业是否应该中止以及如何从中恢复的问题。如果故障原因是节点掉电、网络分区或存储不可用，NVRx 无能为力——这些需要在基础设施层通过冗余和故障域隔离来解决。
其次，进程内重启依赖故障进程所在的环境依然可用。如果 GPU 因为硬件故障完全从 PCIe 总线脱落（如 XID 79 错误），进程内重启不会有什么帮助。此时必须依赖 ft_launcher 的作业内重启或更底层的节点级替换。
第三，NVRx 不解决 straggler（掉队者）问题。虽然 NVRx 包含 straggler 检测组件，但它的角色是检测到掉队后终止作业，而不是自动缓解。处理 straggler 的根本手段仍然是硬件层面的供电和散热管理，以及任务调度策略优化。
最后，NVIDIA 的容错方案天然绑定 NCCL 生态。对于使用其他通信库的集群——如 AMD ROCm 的 RCCL、华为昇腾的 HCCL——NVRx 的能力无法直接迁移。这对于在国内被制裁环境下运行国产 GPU 集群的团队来说是一个需要提前考虑的技术选型约束。
谁需要关注这件事
如果团队只有几十张 GPU，用它跑微调和实验，每次故障重来就是几分钟的事，NVRx 带来的秒级恢复可能不是刚需。同步检查点的简单方案已经够用。
但以下三类场景应该认真评估这套方案。
第一，百卡以上的分布式训练团队。当 GPU 规模突破 100 张，故障概率就从偶尔出现变成必然发生。此时容错方案的 ROI 由负转正。
第二，运行时长超过一周的训练作业。一周以上的训练窗口意味着几乎一定会遇到至少一次硬件故障。少一次中断就能省下数小时的恢复时间。
第三，已经或计划在 EKS 上运行训练工作负载的团队。由于 NVRx 以 Python 包形式提供，接入成本极低——pip install 加几行代码即可完成。已有的 FSDP 训练脚本不需要改动模型代码。
拐点已至
2025 年的 GTC 上，NVIDIA 首次系统介绍了 NVRx 的容错架构。2026 年 9 月，AWS 用完整的基准测试和可复现的代码证明了它在 EKS 上的实际效果。从概念到可落地的生产级方案，这个周期只有一年半。
在 Meta 的 Llama 3 训练日志里，419 次中断中的每一次都在提醒行业：当模型规模和集群规模持续膨胀时，少坏和快修必须同时推进。NVRx 在快修这个环节给出了一个工程上可验证的解——99% 的训练效率不是演示数据，而是真实负载下可重复的基准。
算力从来不便宜。让它真正被用完而不是等完，才是容错工程最朴素的目标。
快报