摩尔线程王华：万卡训练中，最危险的往往是「不报错」丨GAIR 2025

来源：市场资讯

（来源：雷峰网）

“相比会引起训练报错甚至中断的数据，静默数据错误会对训练产生更严重的影响。”

作者丨包永刚

编辑丨林觉民

2025年12月12-13日，第八届GAIR全球人工智能与机器人大会在深圳·博林天瑞喜来登酒店正式启幕。

作为AI 产学研投界的标杆盛会，GAIR自2016年创办以来，始终坚守“传承+创新”内核，始终致力于连接技术前沿与产业实践。

在人工智能逐步成为国家竞争核心变量的当下，算力正以前所未有的速度重塑技术路径与产业结构。13日举办的「AI 算力新十年」专场聚焦智能体系的底层核心——算力，从架构演进、生态构建到产业化落地展开系统讨论，试图为未来十年的中国AI产业，厘清关键变量与发展方向。

王华在「AI算力新十年」论坛发表了主题为《基于国产GPU集群的大规模训练实践》的演讲。

当海外头部公司已经建设十万卡、甚至二十万卡规模的 GPU 集群，万卡训练正在从“前沿探索”转变为大模型研发的基础设施能力。模型参数规模进入万亿级之后，真正拉开差距的，已不再只是单卡性能，而是训练周期能否被压缩、系统是否长期稳定、工程效率能否支撑高频迭代。

在这样的背景下，万卡训练所面临的挑战也发生了根本变化。节点故障、性能抖动、通信与存储瓶颈，在集群规模被放大之后都会成为常态问题，很多在千卡规模下可以容忍的风险，在万卡场景中都会被大幅放大。

王华在演讲中将结合摩尔线程在国产 GPU 万卡级真实集群上的训练实践，系统拆解这一过程中遇到的关键难题，以及相应的工程解法。从并行策略选择、训练前的模拟与起飞检查，到异步 Checkpoint、慢节点治理，再到静默数据错误、Hang 以及 Inf/NaN 等稳定性问题的应对，他重点分享如何通过软件栈、自动化与可观测体系，把万卡训练从“能跑”推进到“可持续稳定地跑”。

这些经验并非实验室结论，而是来自真实生产环境中反复验证后的工程积累，他希望摩尔线程的经验能够给想要做万卡训练的公司和机构一些借鉴。

以下是王华演讲的精彩内容，雷峰网作了不改变原意的整理与编辑：

我是王华，负责摩尔线程的AI与云计算相关业务。今天主要和大家分享，我们在大规模训练实践中遇到的一些问题，以及对应的解决方案。

万卡训练我们已经讨论和推进了一段时间。从去年开始到今年，我们陆续在真实集群上推进相关工作，中间确实遇到了大量问题。客观来看，大规模训练的技术挑战很大，但在这个过程中，我们也逐步把问题解决，并积累了很多经验，今天与大家分享。

01

万卡训练为何成为大模型的必要条件？

首先需要回答的是，为什么万卡，甚至更大规模的集群已经成为必要条件？

从模型算力需求趋势来看，主流模型，像DeepSeek或国产的万亿模型，基本都到了10的24次幂的量级。而国外一些大的模型，虽然没有公开资料明确给出规格，但根据市面上流传的消息，像比较大的Grok4、GPT-5或者比较新的Gemini3，基本都会达到10的25~26次幂的算力需求，这是非常巨大的算力需求。

在国内，当前已经开源的两个万亿参数模型，一个是 Kimi K2，另一个是蚂蚁的百灵，它们的总计算量主要由两个因素决定：一是模型参数规模，对于 MoE 模型来说，核心是激活参数；二是训练数据量。

Kimi K2 的计算量大约是3×10的24次幂FLOPs，激活参数规模是 32B，训练数据是15T；百灵的计算量大约是6×10的24次幂FLOPs，激活参数规模是50B，训练数据是20T。

如果以我们当前这一代训练卡做一个估算，对于3×10的24次幂FLOPs的算力需求来说，大概需要半年的时间；如果扩大到5000卡，需要40天；到了万卡，就只需要23天。对于百灵来说，因为算力翻了一倍，对应的时间也翻了一倍。对大模型来说，训练时间非常关键，现在模型的竞争非常激烈，而且我们经常会有一些新模型算法的实验，希望快速看到结果，所以训练时间越短越好，最好不要超过一个月。

在海外，头部公司已经建设了十万卡甚至二十万卡规模的集群，更大规模的集群也在规划中了，这一方向在未来基本是确定性的趋势。

02

如何把万卡训练集群「跑起来」？

围绕大规模训练，摩尔线程从底层到顶层系统性地研发了软件栈。

在最底层，除了硬件，主要是集群调度的部分；向上是MUSA平台，它与CUDA兼容性，使得我们可以快速地迁移和运行模型；再往上是训练套件，针对摩尔线程的平台，我们对 MegatronLM、DeepSpeed、PyTorch、TransformerEngine 等主流框架进行了适配和优化，并且全部开源，在GitHub上就可以找到；更高一层，是Model Studio以及一系列自动化训练和部署工具。

在整个训练过程中，我们关注的核心是训练效率。

从流程上看，大规模训练通常包括起飞检查、训练拉起（建立通信组、加载数据等）、正式训练、故障定位和处理、以及故障处理后进入下一个周期。

过去在千卡规模下，集群可能连续运行半个月甚至一个月都不出问题。但万卡集群，单个节点出问题的概率会显著上升。早期即便是英伟达的万卡集群，也曾出现几小时就出一次错误的情况，我们在实践中同样经历了这一阶段。

因此，在万卡训练中，要提升整体效率，一方面必须提升正常训练阶段的性能，另一方面则要尽可能压缩所有非训练环节的时间，包括起飞检查、checkpoint、故障定位与恢复。只有把这些环节的时间压到足够短，训练效率才有实质性提升。

在性能优化层面，在起飞训练前，需要确定并行策略和超参。一种方法是可以通过实际拉起训练反复尝试不同配置，但在万卡规模下，每一次拉起试验的成本都非常高。为了降低成本，我们采用了模拟的方式。

我们开发并开源的SimuMax软件（可以在GitHub上找到），用于对不同模型和不同集群规模下的训练性能进行估算，帮助判断策略的合理性，并预估整体训练时间。这一模拟基于一系列理论计算，可以帮助判断当前训练是否已经达到速度上限。如果达到，说明性能基本到位；如果没有达到，则意味着仍然存在优化空间。围绕这一目标，我们在SimuMax中做了很多特性的支持，包括不同模型结构、并行策略、优化技术等。

在万卡集群中，起飞检查是非常有用的特性。训练启动时，调度系统会分配资源，而节点的故障、亚健康状态，以及系统层面的网络或存储异常，都会导致训练无法启动。

因此，我们在训练启动前，会先运行一组特定的benchmark（基准测试），对计算节点、网络、存储以及调度节点进行全面检查。更重要的是，当检测出问题后，起飞检查会自动剔除异常节点，不再依赖人工介入，实现真正的无人值守训练启动。

Checkpoint 是另一个对效率影响很大的环节。如果采用同步写的方式，checkpoint 往往需要数分钟时间，这期间无法进行训练，整个集群处于闲置状态。

为此，我们实现了异步checkpoint：先将checkpoint写入本地内存，后续再异步写入存储系统，将checkpoint时间压缩到秒级。这么做对于几千亿参数规模的模型来说，checkpoint 写入只需几秒即可，训练可以立即继续执行。

在DP并行策略的情况，并不需要每个节点都写checkpoint，我们对checkpoint进行切片，由不同节点负责不同分片，避免重复写入和资源浪费。如果某个负责分片的节点发生故障，则会分配其他节点完成写入任务。在读取阶段，如果某个节点挂掉，完全从后端存储读取会非常慢，我们采用了P2P机制，直接从其他节点的内存中加载checkpoint，将加载时间压缩到半分钟以内。有了这些优化，我们可以用非常高的频率来做checkpoint，例如每十分钟做一次。

03

万卡训练的挑战：稳定性与可控性

慢节点检测在大规模训练中同样非常关键，因为慢节点会拖慢整个集群的训练速度。慢节点的发现通常有两个来源：一类是节点或卡本身处于亚健康状态，在起飞检查阶段可以发现；另一类是在运行过程中出现亚健康状态，需要运行时的检查。

我们的解决方案是在训练过程中引入了整体监控机制。训练包含前向传播和反向传播，中间包括多个通信与计算步骤，我们会监控这些步骤的执行时间。计算和通信步骤的执行时间整体上符合统计分布规律，但不能拿绝对值去看每个步骤的快慢，不同的模型时间不一样，我们通过聚类分析识别某些异常的慢节点，并自动剔除，整个过程完全自动化。

静默数据错误也是一个棘手的问题。与引起训练报错甚至中断的问题不同，静默数据错误不会触发异常，也不会中断训练，数值看起来“正常”，但实际上已经发生错误。造成静默数错误有几种原因，一种是计算硬件有一定的故障率，在一定概率下可能会算错，就会造成静默数据；另外，内存或显存上的ECC特性对性能的影响比较大，在训练的过程可能没有开启；在传输的过程中，也会出现纠错码失效的情况，导致误码没有被发现。

对于轻微的数值错误，在万亿参数规模下往往会被其他数值平均掉，影响不明显，可以继续训练。有一类是严重错误，可能导致Loss值或梯度出现一个非常大的偏差，Loss曲线会出现异常尖峰，频繁出现时会影响模型精度。如果这种问题经常发生，会导致训练精度的下降。还有一种致命错误，数值异常传递并最终导致出现NaN 或Inf，导致训练中断，只能回退到之前的checkpoint进行回训。

因为非常难检查，整个业界也还在探索，我们一方面在硬件验收阶段和训练起飞检查阶段进行压力测试，尽早识别“体质较弱”的卡；另一方面，压测要多算子覆盖，除了GEMM、Attention外，还会用一些执行较少的算子，因为不同算子会用到卡的不同部件，达到全面压力测试的目的。同时，我们重点监控温度、电压等关键硬件指标，这些异常往往与错误高度相关。

Hang 问题同样是万卡训练中较为棘手的一类问题。一旦发生Hang，往往整个集群都会被Hang住。如果所有节点都Hang住，定位源头非常困难。我们通过分布式分析的方式，结合通信库的日志，对所有参与节点的Hang原因进行记录和比对，从而定位异常节点。

一般情况下，Hang通过重启即可恢复，但如果某个节点经常Hang，会导致训练非常不稳定，此时需要将该节点剔除。解决Hang问题后，整体训练稳定性会有明显提升。

Inf（Infinity） 和 NaN（Not a Number）问题是业内普遍存在的难点，其难点在于传播性， Inf加减任何正常值，都会把正常值“吃掉”。因此，我们重点关注 Inf/NaN 最早出现的位置和时间点，定位那些频繁触发异常的算子或阶段。

在集群洞察方面，我们会持续监控前向传播和反向传播中的计算和通信时间，慢节点检测正是基于这些数据做的分析。同时，我们引入了更全面的 Profiling 能力，可以在不中断训练的情况下，一键启动或停止性能分析器，按需采集训练数据，并进行火焰图等算子级分析，甚至可以将多个节点的数据汇聚后进行联合分析。

最后，是统一的可观测系统。我们的可观测平台覆盖了大量系统与训练指标，即便前面的机制遗漏了问题，也可以在这里通过指标异常检测和联合分析被捕获。此前我们也通过这一平台，快速定位过由于个别节点超温导致的异常问题，并进一步追溯到散热层面的原因。

以上是我们做的一部分工作，在过去的时间里，我们积累了很多经验，很多都落到来我们产品里。现在我们也在万卡级别的集群上做一些训练工作，这方面的经验以及积累的内容我们分享给大家，希望对于后续想做大规模训练的公司和机构有一定的借鉴意义。

感谢大家。