
将 PyTorch Monarch 引入 AMD GPU:实现弹性容错分布式训练,迈向稳定大规模 AI 基建
2026 年 7 月 6 日消息,AMD 的侯朝军、Liz Li、Zachary Streeter 等,以及 Meta 的 Matthias Reso、Hamid Shojanazeri、Monarch 团队,将 PyTorch Monarch 引入了搭载 ROCm 的 AMD Instinct GPU。
训练具有数十亿参数的最先进大语言模型(LLM),需要在数百或数千个 GPU 上进行分布式训练。在这种规模下,硬件故障是预料之中的事,单个 GPU 内存错误等都可能导致整个训练运行中断。此前的工作虽展示了 FP8 训练在大规模场景下的近线性扩展能力,但大规模训练的可靠性仍是关键挑战。
为应对这些挑战,研究团队将 PyTorch Monarch 引入搭载 ROCm 的 AMD Instinct GPU,把单控制器模型扩展到了 CUDA 环境之外,让这个新兴运行时适配更广泛的硬件生态系统。下面我们来扒一扒这项研究都透露了哪些重点——
挑战:大规模训练的可靠性
传统容错策略依赖定期检查点机制,即按固定间隔将完整的模型状态保存到持久存储中,故障时整个作业从上一个检查点重新启动。但这种方法有显著缺点:
| 挑战 | 影响 |
|---|---|
| 检查点开销 | 将数百 GB 的模型状态写入存储设备会消耗大量时间和 I/O 带宽。 |
| 计算资源浪费 | 故障发生时,自上一个检查点以来的所有进度都会丢失。 |
| 集群空闲时间 | 在替换故障节点并重新启动作业时,整个集群会处于空闲状态。 |
| 可扩展性限制 | 随着集群规模的增大,在任何检查点间隔内发生故障的概率也会增加。 |
真正的大规模训练,不仅要实现扩展,训练过程还得能从故障中恢复。这就需要一种更动态的方法,允许健康节点在故障节点恢复并重新加入时继续训练,以减少计算资源浪费,提高 GPU 利用率,而 PyTorch Monarch 就能发挥这样的作用。
什么是 PyTorch Monarch?
PyTorch Monarch 引入了一种新的分布式编程范式,让开发者通过单个 Python 程序协调整个 GPU 集群。借助基于 actor 的运行时、进程网格抽象和异步执行模型,Monarch 简化了大规模分布式训练,还支持在一个统一脚本中组合训练、评估和强化学习等复杂工作流程。
该架构在多个层面运行:
- Python API:一个单程序接口,开发者编写简单 Python 代码就能实现分布式 GPU 执行。
- Monarch 运行时:管理 actor、网格、监督树和张量分片。
- Rust 运行时(Tokio):确保高性能和内存安全。
- 基础设施:与 RDMA、RCCL/NCCL、SLURM、Kubernetes 和 SkyPilot 集成。

Monarch 通过将每个训练副本内使用的并行策略与副本间使用的容错机制解耦,提供了更清晰的容错模型。故障被隔离、分层处理,恢复速度快。

将 Monarch 移植到 ROCm:生态系统集成
将 Monarch 引入 AMD GPU,需要大量工程工作把 GPU 运行时和分布式通信栈移植到 ROCm。研究团队成功实现了三条主要移植路径:
- 集体通信:使用 `hipify_torch` 将 C++ 桥接代码从 CUDA 转换为 HIP,并链接到 RCCL,其 API 与 NCCL 类似。
- GPU 内存管理:扩展构建系统以自动检测平台,并通过其 HIP 等效项路由 CUDA 驱动 API 调用。
- RDMA 集成:配置 `GPU_PLATFORM=rocm` 可保持基于 `libibverbs` 的 RDMA 路径不变,同时将 GPU 端绑定从 CUDA 替换为 HIP 以实现 GPU 直接传输。

此外,有两个跨领域问题影响了移植工作:
- HIP 运行时无静态链接:NVIDIA 提供 `libcudart_static.a`,CUDA 路径可直接链接 `cudart_static`,而 ROCm 没为 `libamdhip64` 提供静态等效项,所以 ROCm 构建动态链接 `amdhip64`。两个平台都会额外使用 `dlopen` 加载 GPU 驱动 API 函数,确保两侧运行时契约一致。
- 使用 Rust 兼容性垫片而非分叉绑定:`hipify_torch` 重写 C/C++ 头文件后,`bindgen` 会生成 HIP 命名的类型。为避免在每个 Rust 调用点添加 `#ifdef` 分支,研究团队在 `nccl - sys` 和 `rdmaxcel - sys` 中添加了 `rocm_compat` 模块,将 HIP 符号重新导出为 CUDA 名称,其余 Rust 代码保持平台无关性。
这些努力最终在 Rust 中引入了 HIP 类型别名,1171 个测试全部通过,确保了对 ROCm 7.0+ 的全面支持。相关贡献已提交到开源社区(详见 PR [#2393](https://github.com/meta - pytorch/monarch/pull/2393) 和 PR [#2891](https://github.com/meta - pytorch/monarch/pull/2891))。
如今,基于 ROCm 的 Monarch 提供了完整的生态系统支持,可在 SLURM、Kubernetes 和 SkyPilot 上无缝运行,为 TorchTitan 和 TorchFT 等下游引擎支持生产工作负载。
案例研究:大规模容错训练
为展示 Monarch 在 AMD GPU 上的强大功能,研究团队将其与 TorchTitan 和 TorchFT 集成,构建了一个无需检查点的弹性分布式训练架构。
架构概述
该架构由三层组成:
- Monarch:作为协调器,管理进程和集群编排。它生成 ReplicaActors 和 Lighthouse 服务,将 GPU 组织成进程网格。
- TorchFT:在步骤级别处理容错。它与 Lighthouse 联系以进行仲裁协调,执行仲裁 AllReduce 操作,并跳过故障节点。
- TorchTitan:作为训练引擎,执行前向传播、反向传播和优化器步骤,同时管理检查点和指标。

在这种设置下,Monarch 提供了一个监督树,用于细粒度的故障检测和隔离。当训练 actor 中注入故障时,Lighthouse 会检测到故障并由 TorchFT 处理。即使出现对等节点故障,健康的副本也能继续独立训练,无需全局中断。
动态故障恢复工作流程
下面通过一个包含四个副本组的具体场景,了解恢复工作流程:
- 正常训练:OrchestrationManager 生成 4 个 ReplicaActors(Monarch 监督器)和一个 Lighthouse。每个 ReplicaActor 生成一个包含 8 个 GPU 进程的副本,运行 TorchTitan 训练器。所有 4 个副本就绪(`quorum_id = 1`),每 20 步进行一次 DiLoCo 梯度同步。
- 故障检测:副本 0 中的一个 GPU 进程崩溃。Monarch 监督器在进程死亡前捕获 `report_training_error`(包含完整的回溯信息)。副本 1、2 和 3 被标记为未受影响并继续训练。
- 本地重启:ReplicaActor 0 发起原地重启(`_stop_and_restart()`),停止旧的进程网格并生成一个新的。同时,其他 3 个副本继续同步(`quorum_id = 2`)。
- 对等检查点传输:Lighthouse 选择副本 1 作为捐赠者。发起从副本 1 到恢复中的副本 0 的对等检查点传输(模型、优化器、调度器和训练器状态)。在新仲裁组形成时,所有副本在仲裁边界处短暂暂停。
- 恢复训练:副本 0 同步完成后,新的仲裁组(`quorum_id = 3`)建立,所有 4 个副本恢复 DiLoCo 同步。

整个恢复过程无需人工干预,无需完整的检查点重启,对整体训练吞吐量影响最小。
性能特征
研究团队在 SLURM 和 Kubernetes 环境中使用 AMD Instinct MI300 系列集群验证了这一方法。
SLURM 16 节点 MI300 集群(128 个 GPU)
在 16 节点的 SLURM 集群(共 128 个 MI300 GPU)上训练 Llama 3 8B 模型,每 180 秒注入一次 RCCL 故障,每 20 步进行一次仲裁同步。结果出色:
- 由于注入的故障,活跃工作节点数量在 8 到 16 之间动态波动。
- 尽管频繁出现故障,训练仍能无缝继续,没有进行完整的重启。
- 损失曲线显示出稳定的收敛,与未注入故障的基线运行结果非常接近。

Kubernetes 32 节点 MI355 集群(256 个 GPU)
实验扩展到 32 节点的 Kubernetes 集群(共 256 个 MI355 GPU)。参与节点数量在恢复事件期间在 30 到 32 之间略有波动,保持高度稳定,全局平均损失从 12 平稳下降到约 4。这表明 Monarch 容错模型在 SLURM 和 Kubernetes 大规模集群上都能可靠工作。

总结与未来方向
大规模训练大型人工智能模型,需要强大计算能力,也需要能应对硬件故障的弹性基础设施。通过将 PyTorch Monarch 引入搭载 ROCm 的 AMD Instinct GPU,研究团队展示了一种实用的容错分布式训练方法,减少了计算资源浪费,提高了 GPU 利用率。
这种集成在 AMD GPU 大规模训练方面取得多项重要成果:
- 首次在 AMD 硬件上进行大规模验证:成功在 AMD GPU 上部署 Monarch 与 TorchTitan 和 TorchFT,证明 ROCm 软件栈支持先进容错机制。
- 更清晰的容错模型:Monarch 提供强大监督树和进程网格抽象,隔离故障并实现快速本地恢复。
- 生态系统就绪:该方法可在 SLURM 和 Kubernetes 上无缝运行,适用于生产工作负载。
关键架构见解是使用 Monarch 基于 actor 的运行时和监督树隔离故障,结合 TorchFT 基于仲裁的同步机制,让健康节点继续训练。对于在 AMD GPU 上运行大规模训练工作负载的团队来说,这种集成提供了更稳定、高效和经济的模型开发之路。
展望未来,研究团队的下一步计划包括:
- 扩展 NIC 支持并提高运行时性能。
- 扩展 Monarch 以支持 ROCm 上更多的预训练和强化学习(RL)框架。
- 进一步优化容错性能,特别是减少重新加入的重新加载延迟,并使恢复过程与计算过程重叠。
- 继续与 PyTorch 社区进行开源合作。
更多资源
文档
访问 PyTorch 全面的开发者文档
教程
获取面向初学者和高级开发者的深入教程
资源
查找开发资源并获取问题解答
保持联系,获取更新、活动信息和最新消息
提交表单即同意接收 Linux 基金会(LF)及其项目关于其活动、培训、研究、发展和相关公告的营销电子邮件,可随时使用收到的电子邮件页脚中的链接取消订阅。隐私政策。

2548

被折叠的 条评论
为什么被折叠?



