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

“与可能导致训练错误甚至延迟的数据相比，无声的数据错误会对训练产生更严重的影响。”作者丨包永刚 编辑丨林觉民 2025年12月12-13日，第八届GAIR全球人工智能与机器人大会在深圳博林天瑞喜来登酒店正式开幕。作为AI产学研投界的标杆盛会，GAIR自2016年创办以来始终遵循“传承+创新”的核心，始终注重连接技术前沿与行业实践。在人工智能逐渐成为国家竞争的关键变量之际，算力正在以前所未有的速度重塑技术路径和产业结构。 13日召开的“B·AI算力十年”专场聚焦智能系统的底层核心算力，从计算能力的演进进行了系统探讨。从架构、构建生态到产业化，试图厘清中国人工智能产业未来十年的关键变量和发展方向。王华在“AI算力新十年”论坛上发表题为“基于国产GPU集群的大规模训练实践”的演讲。当其他国家领先企业搭建10万甚至20万卡的GPU集群时，万卡训练从“前沿探索”转变为大规模研发的基础设施能力。当模型参数达到万亿级后，真正拉大的差距不再是单卡的性能，而是训练周期能否压缩、系统能否长期稳定、工程效率能否支持高频迭代。在此背景下，万卡实践面临的挑战也发生了根本性的变化。节点故障、性能抖动、通信和存储瓶颈将成为n增加集群规模后的正常问题。很多1000张卡规模可以承受的风险，到了10000张卡场景就会被大大放大。王华在演讲中将结合摩尔线程在国产GPU万卡实集群中的实践、拆解系统过程中遇到的主要问题以及相应的工程解决方案。从并行策略选择、预训练模拟和起飞检查，到异步检查点、慢速节点管理，以及解决静默数据错误、Hang和Inf/NaN等稳定性问题，他重点分享了如何通过软件堆栈、自动化和可观测系统将万卡训练从“能够运行”推进到“可持续稳定运行”。这些经验不是实验室结论，而是来自实际生产环境反复验证后的工程积累。他希望摩尔线程的经验能为企业提供一些参考想要练习Wanka的s和机构。以下是王华演讲精华，雷锋网在不改变原意的情况下整理编辑： 我是王华，负责摩尔线程的人工智能和云计算相关业务。现在，首先我将与大家分享我们经验丰富的培训技巧中遇到的一些问题以及相应的解决方案。我们已经讨论了很长时间，并在万卡培训方面取得进展。去年到今年，我们陆续推进了实体集群的相关工作，过程中遇到了很多问题。客观来说，大规模训练的技术挑战是巨大的，但在这个过程中，我们也逐渐解决了问题，积累了很多经验，今天跟大家分享。 01 为什么一万卡训练是大模特的必要条件？首先需要回答的是，为什么万卡甚至更大的星团成为必要条件？从特雷来看算力需求模型中，主要模型，如DeepSeek或国内万亿模型，通常达到10到24次方的水平。虽然没有pampublic信息明确说明国外一些大型型号的规格，但根据市场上流传的消息，比如更大的Grok4、GPT-5或者更新的Gemini3，它们通常会达到10到25到26的算力要求，这是一个非常大的算力要求。在中国，目前开源的万亿参数模型有两个，一个是Kimi K2，另一个是蚂蚁百灵。它们的总计算成本主要由两个因素决定：一是模型参数的规模，对于MoE模型来说，核心是激活参数；二是模型参数的规模。另一个是训练数据量。 Kimi K2计算成本约为3×10的24 FLOPs次方，激活参数大小为32B，训练数据为15T；白灵计算成本约为6×10的24 FLOP次方，激活参数大小为50B，训练数据为20T。如果按照我们当前一代的训练卡来估算，3×10 FLOPs 24次方的算力需求大约需要半年时间；如果扩容到5000张卡，需要40天；如果达到10000张卡，只需要23天。对于百灵来说，随着算力加倍，相应的时间也加倍。对于大型模型，训练时间非常重要。现在模型竞争非常激烈，我们经常会对新的模型算法进行一些实验，希望能够快速看到结果，所以训练时间越短越好。最好不要超过一个月。在国外，领先企业已经建设了10万甚至20万张卡的集群，更大的集群也在规划之中。这个方向就是k预测未来的某种趋势。 02如何“跑”万卡训练集群？致力于大规模实践，Moore Threads 自下而上系统地构建了一个软件堆栈。最底层，除了硬件之外，主要是集群调度组件；上面是MUSA平台，它兼容CUDA，可以让我们快速迁移和运行模型；楼上是培训室。针对摩尔线程平台，我们对MegatronLM、DeepSpeed、PyTorch、TransformerEngine等关键框架进行了适配和优化，并且它们都是开源的，可以在GitHub上找到；更高一层是Model Studio和一系列自动化训练和部署工具。在整个培训过程中，我们的主要重点是卓越培训。从流程上看，往往涉及到大量的训练：出发检查、拉起训练（建立通讯组、数据加载等）、正式训练、故障定位与处理、故障处理后进入下一个周期。以前，在千卡规模上，集群可以继续运行r半个月甚至几个月都没有问题。但在万卡集群中，单个节点出现问题的概率会大幅增加。早期，就连 NVIDIA 的 Wanka 集群每隔几个小时就会出现一次错误。我们在训练中也经历了这个阶段。因此，在万卡训练中，为了提高整体效率，一方面要提高正常训练阶段的表现，另一方面要尽可能压缩所有非训练环节的时间，包括出发检查、检查点、故障定位等，只要简单地缩短这些环节的时间，就可以显着提高训练效率。在性能优化层面，在进行训练之前，需要确定并行策略和超参数。一种方法是通过实际的引体向上练习来反复尝试不同的配置，但在万卡规模上，每次引体向上测试的成本非常高。哎呀。为了降低成本，我们使用模拟。我们开发并开源的SimuMax软件（可以在GitHub上找到）用于估计不同模型和不同集群大小的训练性能，帮助判断策略的合理性，并估计总训练时间。该模拟基于一系列理论计算，有助于确定当前实践是否已达到速度极限。如果达到了这一点，说明表现基本到位；否则，说明还有优化的空间。围绕这个目标，我们在SimuMax中开发了很多功能支持，包括各种模型结构、并行方法、优化技术等。在Wanka集群中，起飞检查是一个非常有用的功能。当训练开始时，调度系统将分配资源。但节点故障、亚健康状态、系统级网络或存储异常都会导致训练无法启动。因而首先，在开始训练之前，我们会首先运行一组特定的基准测试，对计算节点、网络、存储和调度节点进行全面检查。最重要的是，当检测到问题时，自动剔除检查将异常节点剔除，不再依赖人工干预，实现真正的无人值守训练启动。 Checkpoint是另一个对效率影响较大的环节。如果采用并发写入，检查点往往需要几分钟的时间，期间无法进行训练，整个集群处于空闲状态。为此，我们实现了异步检查点：首先将检查点写入本地内存，然后异步写入存储系统，将检查点时间压缩到秒级。这样，对于千亿参数的模型，写一个检查点只需要几秒钟，训练就可以立即继续。在 DP 并行方法的情况下，each节点不需要写检查点。我们打通了检查点，不同的节点负责不同的分片，避免重复写入和资源浪费。如果负责分片的节点出现故障，则会分配其他节点来完成写入任务。在读取阶段，如果某个节点挂掉了，从后端存储的全量读取会非常慢。我们使用P2P机制直接从其他节点的内存中加载检查点，将加载时间压缩到半分钟以内。通过这些优化，我们可以以非常高的频率进行检查点，例如每十分钟一次。 03 千卡训练挑战：稳定性与可控性 慢节点检测在大规模训练中也非常重要，因为慢节点会拖慢整个集群的训练速度。发现慢节点通常有两个来源：一是节点或卡本身处于亚健康状态，可以在起飞阶段发现e 检查；另一种是运行过程中出现亚健康状态，需要运行时检查。我们的解决方案是在培训过程中引入整体监控机制。训练包括前向传播和反向传播，包括多个通信和计算步骤。我们将监测这些措施的实施时间。计算和通信步骤的执行时间一般遵循统计分布规律，但不能用绝对值来判断每一步的速度。不同型号有不同时间。我们通过聚类分析识别出一些异常缓慢的节点并自动删除它们。整个过程完全自动化。无声数据错误也是一个难题。与导致训练错误甚至延迟的问题不同，静默数据错误不会触发异常或中断训练。这些值看起来“正常”，但实际上发生了错误。有几个原因对于无声号码错误。一是计算硬件有一定的故障率，在一定概率下可能会出现误算，导致数据无声。另外，内存或显存中的ECC功能对性能影响较大，训练过程中可能不开启。在传输过程中，纠错码也可能失败，导??致错误未被检测到。对于微小的误差，通常会在万亿参数规模内用其他值求平均，效果不会很明显，所以可以继续练习。一类是严重错误，会导致Loss或者梯度的值出现较大偏差。 Loss曲线会出现异常尖峰，如果出现过于频繁，就会影响模型的准确性。如果这个问题频繁出现，就会导致训练精度下降。还有一个致命的缺陷。数值转移异常，最终导致Na的出现N或Inf，这会导致训练延迟，返回到前一个检查点的唯一方法是执行回训练。因为评估起来非常困难，所以整个行业还在探索之中。一方面，我们在硬件验收阶段和训练起飞检查阶段进行压力测试，尽快找出“较弱”的卡；另一方面，压力测试需要多个运营商来覆盖。除了GEMM和Attention之外，一些实现较少的运营商也会使用，因为不同的运营商会使用不同部分的卡来达到全面压测的目的。同时，我们重点监控温度、电压等关键硬件指标。这些异常往往与故障高度相关。挂题也是玩卡练习题中比较难的一类。一旦发生挂掉，整个集群往往都会挂掉。如果所有节点都挂了，那就很难了找到源头。通过分布式分析，我们结合信任数据库日志记录，对比所有参与节点的Hof原因，找到异常节点。正常情况下，重启即可恢复Hang。但如果某个节点频繁挂掉，就会导致训练变得非常不稳定。在这种情况下，需要删除该节点。解决Hang问题后，整体训练的稳定性将会得到很大的提升。 Inf（无穷大）和 NaN（非数字）问题是工业界常见的问题。困难在于传播。在 Inf 中添加或减去任何正常值都会“吃掉”正常值。因此，我们关注Inf/NaN最早出现的位置和时间点，寻找最常触发异常的算子或阶段。在集群洞察方面，我们会继续监控前向传播和反向传播中的计算和通信时间，慢节点检测就是基于此分析数据。同时，我们引入了更全面的profiling能力，可以在不中断训练的情况下一键启动或停止性能分析器，按需收集训练数据，并进行火焰图等操作员级别的分析。它甚至可以聚合多个节点的数据进行联合分析。最后，有一个统一的可视化系统。我们的可视化平台涵盖了大量的系统指标和练习。即使之前的机制漏掉了问题，这里也可以通过检测指标的异常情况并结合分析来抓住。过去我们也曾利用该平台快速发现个别节点过热导致的异常问题，并进一步将原因追溯到散热层面。以上是我们所做工作的一部分。在过去的时间里，我们积累了很多经验，其中很多已经融入到我们的产品中。现在我们也在做一些万卡级别集群的训练。我们把我们的经验和积累的内容分享给大家，希望能够为以后想要进行大规模培训的公司和机构提供参考。谢谢大家。 特别声明：以上内容（如有，包括照片或视频）由自媒体平台“网易号”用户上传发布。本平台仅提供信息存储服务。 注：以上内容（包括图片、视频，如有）由网易号用户上传发布，网易号为社交媒体平台，仅提供信息存储服务。