大模型训练跑到几百张GPU规模时，硬件故障不是意外，是常态——一块显存出错、一次网络抖动，都可能让跑了几天的训练任务被迫重启。AMD联合PyTorch社区把单控制器分布式训练框架Monarch搬上了ROCm 7.0+，并拉上TorchFT（故障容错）和TorchTitan（训练引擎），在最多256张MI355GPU的集群上跑通了一套局部故障隔离、自动恢复的训练方案。故障发生时，出问题的那一组GPU自己重启、找健康的同伴要一份最新状态，其余节点照常训练，不用整体停下来等。
这套局部容错的逻辑，在CUDA阵营的Monarch上已经验证过。这次的实质进展，是ROCm软件栈证明自己也扛得住同样复杂的容错编排——这对长期被质疑"训练大模型工具链不如CUDA齐整"的AMD来说，是一块具体的短板补齐，而不是又多了一个训练脚本工具。
局部隔离恢复，比"整任务重启"省在哪
传统做法靠定期存checkpoint：训练一段时间就把模型状态写盘，出故障就全部重启，从最近一次存档接着跑。集群规模越大，出故障概率越高，每次重启意味着全体GPU陪着等，浪费的算力随规模线性增长。
Monarch的设计不同：每个训练副本是独立的actor，出故障只影响自己，其余副本不受影响、不停机。故障副本本地重启后，从存活的同伴副本那里拉取一份模型、优化器和调度器状态，重新加入协同——过程里确实还是有一次"同伴状态传输"，只是省掉了全局checkpoint重载和整任务重启这两步。
具体的恢复流程分五步：Monarch负责编排进程和集群拓扑，四个副本各自跑一份TorchTitan训练任务；一旦某个GPU进程崩溃，Lighthouse服务捕获错误并通知TorchFT，健康副本继续按原有节奏做梯度同步；故障副本本地重启进程网格；系统挑一个存活副本当"donor"，把模型、优化器、调度器状态传给它；同步完成后，新的quorum成立，四个副本重新一起训练。
故障隔离能省停机时间，但省不省钱，AMD还没给出答案。
工程上，这次迁移的关键是通过hipify_torch把CUDA代码转成HIP，链接RCCL替代NCCL，并在Rust层写了一个兼容模块，让HIP类型直接映射成CUDA同名类型，避免到处加条件分支。全部1171项测试通过，官方要求ROCm 7.0+才能跑完整功能。
谁该关注，谁还不必急着换赛道
验证做了两组：一组是16节点、128张MI300GPU的SLURM集群，跑Llama 3 8B，每180秒主动注入一次RCCL故障；另一组是32节点、256张MI355GPU的Kubernetes集群，规模更大但官方没公开故障注入的具体频率。
| 项目 | SLURM／MI300实验 | Kubernetes／MI355实验 |
|---|---|---|
| GPU规模 | 128张（16节点） | 256张（32节点） |
| 训练任务 | Llama 3 8B | 未点名具体模型 |
| 故障机制 | 每180秒注入一次RCCL故障 | 未披露具体注入频率 |
| 存活参与者 | 在8-16之间波动 | 稳定在30-32之间 |
| Loss表现 | 与无故障基线基本一致 | 从12平滑收敛到约4 |
这两组实验都是主动注入故障验证系统行为，不是生产环境里的真实故障；官方没有给出恢复耗时、吞吐损失或成本节省的具体数字，"训练更稳"目前更接近工程验证，还不是可以直接拿来做成本核算的结论。
- 风险.目前的数据只证明系统能跑，没有证明它比传统checkpoint重启更省钱或更快，选型时不能直接套用官方叙述。
对已经在用AMD Instinct集群做大规模训练的平台团队，这是个值得评估接入的信号——至少多了一条局部容错的路径，不用每次故障都全局重启。但对还在CUDA和AMD之间做选型的团队，这次的验证更多说明ROCm"补上了一课"，软件成熟度、实际吞吐和运维成本上是否追平CUDA生态，还需要更多独立于官方博客的数据来验证。