指数级增长的模型算力需求，宣告了大智算集群作为训练基础设施的“刚需”时代已然来临。? 面对动辄10^26 FLOPS级的计算量和长达数十天的万卡训练周期，单纯扩充集群规模已非良策。破局的关键在于多管齐下：?深挖低精度训练（尤其是FP8）带来的巨大潜力以提升单卡效率；同时，构建高可靠、高可用的集群环境以保障大规模训练的持续稳定运行?。这不仅关乎成本，更决定着大模型研发的节奏与成败。
7月25日，在WAIC2025期间举办的摩尔线程技术分享日上，摩尔线程副总裁王华以《基于FP8的国产万卡训练》为主题，分享了在大规模集群上用FP8做训练的创新及思考。
以下为王华的演讲实录精华：
1、大智算集群成为训练的刚需
从行业模型发展的角度看，从2020年到2025年包括GPT、Llama、Grok等主流模型所需要的计算算力资源，需要的计算算力是非常大的。
整个趋势在往上涨，在2020年的时候，还有许多并不需要很多算力的模型。举例来说，2020年大模型算力TOP需求是1023flops。但是到2025年左右，现在Grok-4的算力需求更高，而Grok-3的算力需求在1026flops，差不多是1000倍的增长。驱动增长的核心点是参数加数据。由于我们追求更好的模型效果，参数量在不断增大，数据也在不断增大，这是考虑到Scaling Law这两个数值增大会带来模型效果的提升，最终带来算力需求接近指数型增长。
再从一些熟知模型的实际算力需求，以及我们用不同规模的集群训练它们所需要的时间分析。从算力角度来讲，因为考虑到横向校正，全部拿英伟达的H100集群来做计算，这里有千卡集群、五千卡集群和万卡集群。考虑到不同的计算效率，DeepSeek算力需求大概在3.4×1024flops，1024的千卡集群计算需要的时间大概是97天，五千卡集群需要22天，万卡集群是13天。
最近刚刚发布的Kimi K2是万亿参数模型，它的计算量是2.98×1024flops，计算的时间分别是85天、19天、11天。
而对巨无霸模型GPT-4，它的训练量是1025flops，又高了一个数量级，我们看到的时间也是高了一个数量级，千卡需要602天，五千卡集群需要137天，万卡集群需要80天。早期运行比较小的GPT-3等，参数并不少，但是数据量小，所以算得很快。
由上可以看到，数据和模型这两个因素推动着整个训练的算力需求在大幅度增长。
第二个是精度的变化，从开始的FP32到FP16，再到现在的FP8。精度下降带来的好处是算力提升，精度每下降一半，算力会翻一倍，因为它需要的显存、缓存速度都在下降。另外精度下降会导致模型效果下降，主要由于精度下降会导致一些数值的损失。
2、低精度训练会带来大规模训练效率提升
如何在其中找到平衡点？回到Scaling Law，这里有两个参数，模型的loss值我们希望越小越好，参数量、数据量越大，loss值就会越小。引入精度之后，我们得到一个新的Scaling Law，除了参数量、数据量还会有一个P（精度），随着精度上升L更小，但是我们需要在P和N之间取一个平衡，变成在总的计算量固定的情况下，怎么样合理配置这三个值。这一块有一些研究，做了一系列的试验去拟合这个工具，最后我们得到一个结果。我们拿FP32、FP16、FP8、FP6以及FP4来对比。我们看到FP32对应的是220M，精度下降一半这块就会变成440M，整个loss值在FP6、FP8是一个最佳的"甜点区域"，到FP4反而会上升。我们从近期研究的结果来看，引入精度这个Scaling Law之后，比较合理的值是在FP8，所以我们现在用FP16做训练，用FP8替换之后有了很大的提升空间。
但是用低精度做训练也遇到了很多的挑战。这是低精度的表达范围，当中包含我们取的最大值、最小值，另外在每一个区间上，它表达的尾数位数少，整体的数量会少。这两个限制会导致的问题，第一个是我们的取值范围小，它就容易上溢和下溢，上溢是梯度爆炸的错误，下溢会导致数据丢失，从而梯度消失。我们在整个训练过程当中会有不同的操作，不同操作对精度的需求和敏感度不同，我们可以做一个大致的分类。这里面按照精度不敏感到中度敏感到高度敏感进行排列，不敏感的部分比如说矩阵乘，矩阵乘一般两个数直接相乘，操作次数不会太多，它的精度敏感度相对比较低。像累加/归约类，会把很多数放在一起操作，精度要求是中等的，非线型函数则可能是指数级增长，对精度要求是高的。我们针对不同的精度需求，有一个比较直白的做法就是混合精度训练，在FP32、FP16的时代就已经采用这种技术了，FP8引入之后我们也可以用类似的方式，对非敏感的部分采用FP8去做计算。
FP8出现之后，FP8技术有了很大的发展，有很多技术点支持FP8的训练。比如说硬件上就是Tensor Core，新的Tensor Core都是支持FP8的，比如说英伟达的，在输入上可以用FP8输入，输出是高精度矩阵。
另外是权重Backup，我们把权重更新部分用FP32去表达。而Tensor Scaling，在缩放的时候，先把它缩放到一个合理的值。在缩放因子的选择上，包括选择的时间点上和颗粒度上都会有不同的方式方法，有很多相关的研究。
FP8走进现实很重要的一个点就是，我们使用FP8技术真的可以训出效果很好的模型。DeepSeek在训练过程当中，不同的操作对精度的要求不一样。DeepSeek在训练当中以矩阵乘操作，DeepSeek前向和反向传播的3次矩阵乘都使用了FP8去做，还有激活值的缓存和传输也使用 FP8来做。但是对于一些精度相对来说比较敏感的部分，DeepSeek里面还是继续用高精度来运算。但是从整个训练过程来讲，已经带来很大的收益，因为这里面很大一部分计算量是矩阵乘带来的。
摩尔线程对 FP8 的训练提供了软硬件全栈的完整支持。硬件方面，我们的GPU是一个全功能GPU，算力精度上支持从FP64、FP32到FP8的全精度算力。
从软件栈上讲，我们有三个开源框架，一个是Torch-MUSA，这是我们在Torch栈上构建的MUSA底层插件，可以在MUSA上把整个Torch跑起来。这里面我们已经实现了对FP8数据类型的完整支持。
二是MT-MegatronLM，这里面支持FP8混合并行训练。框架，支持Dense、多模态、MoE 模型的高效训练，支持FP8混合精度训练、高性能muDNN库和MCCL通信库。
三是MT-TransformerEngine。主要用于Transformer的高效训练和推理优化，支持FP8混合精度训练，通过算子融合、并行加速等技术，提升训练和推理的效率。
经过这些软件栈，成功复现了DeepSeek-V3整个训练过程，因为大家知道DeepSeek最开始并没有开源，即便开源只是开一部分。我们是在这个软件栈基础上，实现了它一系列的相关技术，比如说MT FlashMLA和DeepGEMM库等等。我们是行业里到率先能复现DeepSeek满血版训练的厂商，其他家都在尝试做推理的复现。
我们在FP8训练上也做了很多的探索和实验。主要做了两个探索性的工作，第一个是在scaling factor的选择上面，像我们有不同颗粒度的Per-Tensor或者是Per-Block。根据我们的观察，像AMX这个值，如果说在Per-Tensor这个维度上，它的最小值在200左右，它并不是特别小。我们最大值大概是在2000左右，所以我们做scaling factor的时候，用最大值去除的话，不会把这个值除的非常小，所以我们在Tensor这个维度上，可以Per-Tensor的一个scaling factor。但是对Per-Block，它的最小值非常小是0，除的话容易把结果除得很大，所以在这个维度上，我们就会用JIT动态的scaling factor的选择。
另外一个是outlier的影响，因为FP8取值范围比较小，所以出现一些异常值的时候，一旦数值增大，容易把FP8取值范围上限给超了，从而导致训练不稳定。一个比较有效的技术就是Smooth SwiGLU，也是在我们的框架里面复现了本身带来的问题，用Smooth SwiGLU怎么去降低这个问题，核心点我们在量化之后，先去乘一个缩放因子，第二次量化之后再把这个缩放因子再给恢复回来，去降低FP8阶段的时候，出现上溢的这种风险。
在集群训练方面的技术考虑点。首先在大规模训练上，一些数值估算的东西，我们不可能所有东西都靠实验性来做，因为资源消耗太大，很多工作都是通过模拟器方式来做的。我们有Simumax这样一个软件，这个已经开源了，大家可以在GitHub上下载到。
它解决的问题一个是理论与仿真结合去估算我们一系列感兴趣的开销，我们可以支持各种不同的并行策略，优化策略等等。在一些主流模型上都可以用理论分析以及各种策略的设置去得出它大概的资源消耗。一方面可以估算我们需要的资源，如果说我们出现一些性能偏差，我们比较容易找到这其中出现的性能问题。
做法是我们会在计算图上去根据SPEC整个计算过程，根据经验数据或者是理论分析的数据去跑一下计算图，去收集各种各样的开销，汇总起来得到最后的结果，这需要我们对整个计算图的各种模拟做到比较全的覆盖。
3、集群可靠性对大规模训练至关重要
大规模集群训练的可靠性非常重要，因为集群规模大了之后，单机故障率不会那么高。但是我们一个节点出问题，这个训练就挂掉了，数量大了之后，这将是很恐怖的故障率。我们做了很多可靠性相关的工作。
首先，我们的训练生命周期的管理，包括它的监控、故障检测，我们引入了大规模训练的起飞检查、飞行检查和落地检查。起飞检查就是训练开始之前我们它用到的硬件做全面检查，不是一个单点的检查，我们会做包括网络的，甚至会跑一些小负载看整个栈是不是有问题。另外在检查过程当中，一旦发现有异常节点我们会自动给踢掉，这样会降低人工排查带来的时间成本和人力成本。
在飞行检查过程与训练过程当中，可能会出现hang、异常退出、训练亚健康等问题，我们要检测到这些问题，然后做相应的处理。最后是落地检查，在过程中出现亚健康或者是故障的情况，我们在训练停掉的时候，能够找到故障点，以及自动抓取故障的上下文，然后做分析。
在同步训练模式下，一个节点变慢之后，整个训练会拖慢，那我们怎么抓到这些慢节点，避免我们整个训练的过程会变慢？其实慢节点是我们遇到一个比较常见的问题，通过解决慢节点，我们经常会有10%、20%的性能提升。这一块的解决包括两方面检查，第一是在起飞检察阶段，我们会做一些小工作负载的测试，我们找到它明显比其他节点慢的节点；二是在训练过程当中，如果说它的通信执行时间和其他节点不一样，我们就把这样的节点挑出来。
容错训练方面，在大规模集训上，尤其到万卡、十万卡这样的规模上，完全靠现有的方式是不可行的，到这种级别，我们的模式就是发现一个节点之后，这个节点可能是一个DP，如果说出了故障之后，我们就把这个DP从通信组上摘出去，这个通信组可以继续工作。对于大DP，我去摘一个DP成本很高，还可以在一个DP里去摘一个节点，这种情况下对这一部分参数的计算或者更新，我们会把它Skip，但对这种大规模的海量数据来说，这么一点点的数据对它整体性能影响并不大，但是我们省掉了停掉整个集群重新拉起的开销。
最后做一个总结，我的分享主要是三点：
第一，算力需求的发展趋势，使得大智算集群成为训练的刚需。
第二，低精度的训练，会带来大规模训练效率的提升。
第三，集群的可靠性对大规模训练至关重要。
大家可以关注一下今年10月摩尔线程MUSA开发者大会，我们也会在MUSA开发者大会上为大家带来更多技术上的探索。
