最近字节发布了一篇《万卡训练论文》，介绍了他们的MegaScale系统如何支撑万卡级的AI训练规模，堪比AI平台建设的采坑指南。其内容强调了AI-Infrastructure平台的重要性，对唐老师这种同样搞AI平台（华为云ModelArts）的人来说，非常认同。这里小结一下这篇论文讲了些什么，并反观我们自己的AI平台，有何异同。

Ps，其原文是这么描述：现有的技术报告主要集中在模型性能比较上，忽略了使这种训练成为可能的系统基础设施的具体细节。本文通过从系统的角度分享我们在超过10,000个GPU规模上进行端到端LLM预训练的经验，填补了这一空白。

一、论文讲了什么

全文讲的是关于他们如何支撑大规模的AI训练，总结起来主要2个主题：高效+稳定。（正如文章开始所述的2大挑战一样）。接着就从高效+稳定两方面，分别展开介绍，如何实现AI训练的提速，以及确保训练任务的稳定可靠。最后分享了这些努力的结果：基于Megatron-LM增强后，算力利用率达到开源的1.34倍。

其多次提到整个系统的设计理念：算法-系统共同设计来优化训练效率。这跟咱们提的IaaS4AI的思路一致。（虽然IaaS4AI在落地上存在一丢丢不足，但至少理念是一致的，后面分析异同章节会说）。

1.    各章节小结

章节1+章节2谈背景：重点介绍了大规模AI训练所需要的各种并行模式，如数据并行（DP），模型并行方式1-流水线并行（PP），模型并行方式2-张量并行（TP）。并强调了故障的常态性和故障的代价极高。

章节3谈高效，章节4谈稳定。这两块是该论文的主体价值部分，我总结到下图：

高效主要是从训练框架，或者说分布式训练的原理角度进行的。着重介绍了各种并行模式下，如何将计算与通信在时间上进行重叠。即实现一边算一边传，而不是算完再传，这样不用让GPU出现空闲等待。

而稳定性则是从平台角度来做增强，特别是故障的感知+故障的恢复，以及整个训练过程如何可视化来帮助故障的发现。

第5章谈监控+可视化的运维面能力。第6章介绍各个维度的优化的测试效果。

二、与ModelArts的异同

ModelArts作为华为云的AI平台服务，肯定与MegaScale存在一些差异。比如MA重点关注的是平台能力，而训练框架（如Pytorch，MindSpore等）层的改进（如各种并行策略的选择），则由盘古大模型配合完成。

所以广义上的ModelArts平台范围如下：

同时，由于在云服务中，基础设置也是一个云服务。服务都是service on service的，因此狭义上的ModelArts会不包含基础设施。但是基础设施的配置，仍然是由MA下发控制的。

总的来说，字节论文中提到的优化点，ModelArts基本都有类似的实现，那些咱就不一条一条列出来了。挑一些不一样的差异点，分别总结如下：

1.    推理+训练

这里就是ModelArts（简称MA）这个AI平台与MegaScale不太一样的地方，由于MA是一个AI平台的云服务，它不仅要支持各种AI训练任务，还得支持各种AI推理应用。因此对于训推一体的场景下，资源调度分组+隔离的能力上，要求会更高。即一个集群里面，可以支持多个「逻辑子池」来运行不同AI业务。同时对于AI推理的优化，也同样需要做增强，这一点MegaScale论文中未提及AI推理场景。

2.    多租云服务

同样的由于MA是一个云服务，所以它还需要支持云服务的基本能力。即多租户使用，以及各种按需或者包周期的商业形态。因此，当一个超大规模的集群里面，同时运行多个租户的训练作业时，其面临的挑战（如ECMP哈希冲突）会更严峻。同时，由于各个租户的使用时长不一致，对资源的分配要求更高，要求不能出现“资源空洞”，导致分布式任务资源无法满足，比如整柜下发任务这种。

3.    故障模拟

从字节论文里可以看出，其对故障的感知和发现能力有做大幅的投入，这些维度ModelArts也都有投入。毕竟日志、监控、诊断是常见的手段嘛，各家AI平台应该都不会落下。

但是对于故障模拟这个功能并未提及，这一点MA是可以提供NPU卡的全量故障模拟能力的，这一点可以帮助测试&开发人员分析整个AI训练的鲁棒性，以及故障恢复对整体影响如何改进。

4.    训练任务管理框架

可以看到字节管理训练任务的框架如下：

我提炼一下，字节的训练任务管理框架：

就是把管理逻辑，和训练逻辑明显的分开。但是ModelArts由于是个云服务，一般出于安全考虑，会不让数据面可以这么自由的连通管理面。因此管理训练任务的模式稍有微调：

MA的一个分布式训练任务，会让参与训练的所有“选手”，先选出一个“老大”（通常是1号），然后其他选手都把信息发给这个老大。后面的管理决策逻辑，就跟字节大差不差的了。可以看出整体“管理训练任务”的思路其实差别不大，无非这个「Driver」程序放哪里执行有一点点不同。

5.    故障恢复

在分布式训练中，有一个成员发生故障，如何恢复的问题上。字节的论文中只提及：替换故障节点后，重新恢复任务，并利用checkpoint恢复训练。这里并没有提及参与训练的其他worker的详细过程。

MA这故障恢复的时候，提供了多种恢复策略：原地恢复、Pod级恢复、Job级恢复。

• 原地恢复：

根据故障的来源，判断出只需要进行一些reset动作，即可恢复的（如ECC错误、磁盘满等等）故障。那么只需要对本地进行reset行为后，重启该进程就行。

• Pod级恢复：

这个GPU坏了，那么所有其他的worker不用退出。只需要单独等这个坏卡的Pod重新调度后，即可恢复训练。

• Job级恢复：

隔离坏卡后，重新投递本次训练任务。因为它会自动从checkpoint处恢复继续训练。

6.    CKPT的加速

先将训练状态（checkpoint）保存到内存，然后异步将内存数据，保存到外部存储。这个思路确实可以大幅提升CKPT的保存&恢复。当前MA也正在进行这条路径的优化实现，虽然稍有落后，但是也会在今年年中提供该能力。

在CKPT的加载上，思路也差不多。MA会先让部分worker（比如前面提到的1号选手）先加载CKPT，然后通过高速RDMA网络，同步至其他选手。同时做分布式的加载，即多个worker分别加载CKPT的一部分来合成。这样有一个明显的好处是：不会大家同时去读外部存储，导致存储带宽成为瓶颈。

7.    日志聚合&分析

字节论文中提到，所有参与训练的worker日志，会被聚合后进行实时分析过滤。这一点MA稍有不同，训练worker的日志，会在采集时就进行过滤分析。如果有异常就会第一时间发现。同时也会对其他信息进行聚合由参与训练的“老大”执行分析。

相对字节的由外部聚合后再过滤分析，虽然MA直接在采集处就进行过滤分析，会增加一点点性能损耗，但是与训练时间相比，开销微不足道，并且与阿里云的PAI里面的AI-Master思路也是一致的。

所以各家的思路方向仍然是大同小异。

8.    CUDA采集

这块因为要修改用户CUDA调用入口进行埋点，MA作为云服务有时候无法主动提供该能力（需要用户的训练任务配合）。不过在昇腾NPU场景下可以考虑提供该能力。

可以提供训练任务全局角度的CUDA时长视图，并从中观察到多个worker之间的依赖关系+处理时长，是一个非常好的特性。

三、小结

感谢字节这种Open的精神，与大家分享其万卡训练的经验，一起推动大规模AI训练的进展。ModelArts作为华为云的AI平台服务，也提供了其论文中提及的大部分的能力，虽然实现细节上不完全一样，但是目的是一致的：即追求训练的“高效+稳定”。特别是对故障的管理，如故障感知、故障恢复、故障排查等，亦是作为一个重要特性进行开发的。

有些字节提到的优秀的思路，后续ModelArts也会借鉴。同时，ModelArts也有一些自己特有的场景和能力来帮助训练出更好的AI模型。希望同领域的人一起多多交流，共同进步J

Ps，鉴于AI的火热，ModelArts今年有不少招人指标哦。对AI平台有兴趣的人，可以联系我们。过来和唐老师一起冲这一波AI的浪潮吧~