1024 张 GPU 96% 扩展,Monarch 上 AMD 的真实信号？

PyTorch 把它的分布式训练框架 Monarch 从 CUDA 环境搬到了 AMD ROCm 上，配套的性能数据来自此前在 1024 张 AMD MI325 GPU 上跑 DeepSeekV3-671B，FP8 训练拿到了 96.16% 的扩展效率。这个数字单独看是一个漂亮的 benchmark，但放在大模型训练当前的瓶颈上更有意思——扩展效率本身不是最难的事，难的是节点故障时不停摆。

传统容错做法是周期 checkpoint：每隔一段时间把整个模型状态写到持久存储，节点挂了就从上一个 checkpoint 重启。这种做法在大集群里越来越不 work——千亿参数模型一次 checkpoint 要写几百 GB 数据，期间整个集群空转，节点越多单次 checkpoint 周期内发生故障的概率越高。Monarch 想做的事是在节点故障时不重启整个训练任务，让健康节点继续往前跑、坏节点恢复后重新加入。

这套机制落到工程上有几层设计。Python 层只有一个程序入口，开发者在 Python 里直接编排整张 GPU 集群；Rust 运行时（Tokio）负责高并发和内存安全；底层基础设施接 RDMA、RCCL/NCCL 通信库、SLURM、Kubernetes 和 SkyPilot。故障被隔离在 actor 内部，崩溃不会扩散到整个任务，处理层级尽量下放，本地重启只要几秒钟，升级到上层调度才需要几分钟。这种分层让训练任务可以在不中断的情况下动态扩缩容。

对 AMD 来说，Monarch 跑通 ROCm 的意义在于：AMD Instinct GPU 不再只是 CUDA 兼容层的二等公民，可以承接和 CUDA 平台同等水平的分布式训练工作负载。对开发者来说，多一个硬件选择意味着大模型训练的基础设施定价权开始分化。对最终用户来说，下一波开源大模型训练的成本曲线有可能被进一步压低。

未来 12 个月看得到的指标有这么几条：一个是 Monarch 在 AMD 集群上的故障恢复实测曲线是否真能达到官方说的几秒到分钟级；二是能不能被主要的大模型训练项目（比如 Hugging Face、DeepSeek、Mistral 这类）直接采用；三是 AMD 是否能在 RDMA、RCCL 这类底层通信库上追上 NCCL 的成熟度。这几点决定 ROCm + Monarch 能不能从「能跑」走到「大家愿意跑」。

创业找资源，上乌鸦部落。