在如今的人工智能浪潮中，大规模语言模型（上百亿乃至千亿参数）正迅速改变着我们的工作和生活。然而，训练这些庞大的模型往往面临“算力不足、显存不够用、通信太慢”等诸多挑战。为了让大模型的训练过程更顺畅、更高效，沐曦MXMACA软件平台（简称 MXMACA）具有无缝兼容CUDA的能力，科学兼容Megatron-LM^[1]的绝大多数特性。此外，MXMACA进行多方面的优化，帮助科研人员和工程师能够快速在沐曦硬件环境中完成各类前沿模型的训练。下面，我们将从几个关键角度介绍MXMACA在大模型训练方面的改进思路和优化效果，让更多的读者轻松了解“大模型训练背后的那些事”。

1、为什么要优化大模型训练？

通常，大模型采用「张量并行（Tensor Parallel, TP）+ 流水线并行（Pipeline Parallel, PP）+ 数据并行（Data Parallel, DP）+ 序列并行（Sequence Parallel, SP + 专家并行（Expert Parallel，EP）+ 上下文并行（Context Parallel, CP））」的多维并行策略，让成百上千张 GPU 同时参与训练。然而，随着模型参数量飙升（DeepSeek V3为6710亿参数），单靠原版 Megatron-LM 往往会遇到以下几个难题：

MoE模型负载均衡训练困境

MoE 模型训练会出现「热门专家」被过度调用而导致计算和显存极不均匀，拖慢训练速度且易导致显存溢出。此外，跨节点的 AlltoAll 通信占据了较多的训练时间。

计算与通信资源竞争

在分布式训练中，过细的模型切分虽然可以提升计算并行度，但往往会大幅增加跨节点通信开销。特别是在计算与通信需要共享硬件资源的原生并行架构中，计算操作和通信操作会相互竞争有限的带宽和计算单元，这种资源争用问题常常导致实际并行效率低于理论预期。

显存（GPU内存）吃紧

大模型需要存储很多“中间计算结果”（比如激活值、梯度、优化器状态）和大量参数，当模型规模上升时，很容易出现“显存不够用”的状况，导致训练中断，进而影响效率。

集群训练挑战

当你用成百上千块 GPU 训练一个模型时，如何把每一种并行方式合理组合，才能既不爆显存又能让计算满载？靠人工一遍遍尝试，不但耗时，还容易错过更优的组合。集群训练如何减少因故障导致的中断和资源浪费，如何快速定位慢节点，都是集群训练常遇的挑战。

低效算子瓶颈

大模型训练常受限于某些关键算子的低效实现，这些显存访问密集型算子是拉低模型MFU的一个重要因素。

为了解决这些痛点，我们结合沐曦曦云C系列GPU的硬件特点，做了多方面的“落地优化”。既保留了框架的灵活性，也在常见疑难场景中提供了“一键开关”式的配置。下面我们将从 MoE 优化、计算通信并行、显存优化、自动调优与集群训练、算子融合等几个重点模块，逐一展开。

2、MoE优化：让混合专家训练更从容

Mixture-of-Experts（MoE）是日益流行的混合专家模型，通过路由让tokens选择相应的专家计算，能够显著提升模型容量与表达能力。然而，同时也带来了专家之间负载不均、显存爆炸等挑战。MXMACA 针对 MoE 提供了多种优化策略，帮助你在显存和吞吐之间找到更好的平衡。

2.1 “冷热专家”优化：削峰填谷式通信减负

问题背景

在MoE 模型训练初期，某些专家会被大量 token 路由（“热门”），而其他专家几乎闲置。这导致频繁且不均匀的 AlltoAll 通信：热门专家所在的显卡要不断从多台显卡拉数据，通信开销巨大。

优化方法

• 本地备份热门专家：在模型刚开始训练时，把被访问最频繁的几位“热门专家”在本地多复制一份，这样热门专家的计算就可以留在本地完成，减少跨节点通信。
• 在训练后期，当各个专家访问次数趋于均衡时，再把本地备份关闭，恢复普通通信模式。

通俗比喻

想象一个在线商店，某款商品突然在一两个城市爆火，下单量激增。如果所有订单都要从远在总部的仓库发货，就会出现“配送中心爆仓、快递车来回奔波”导致迟迟配送不到顾客手中。优化方式就好比在每个城市中心先存放几箱这款热销商品，顾客下单之后直接从本地仓库发货，大大缩短配送路径。等到热度消退、全国范围内需求趋于均衡时，再把多余的本地库存退回到总部或取消本地备货。一句话：把“最畅销的那几件”临时放到客户附近供他们随时取，就能避免每次都从很远的仓库拉货。

优化效果

• 减少跨节点通信：热门专家不用每次都“喊话”远端节点；
• 性能提升：训练吞吐量提高约 8%；
• 显存可控：因为只给几个热门专家多留一份，所以额外显存开销有限。

2.2 MoE自适应重计算：“分工不均”与节点溢出

问题背景

在 MoE 前向（Forward）/反向（Backward）时，Batch 内的某些 token 会被路由到热门专家（Expert），导致该专家对应的 GPU 需要处理大量激活，占用显存陡增，容易 OOM（Out-Of-Memory）。尤其是在训练早期，token 分配波动较大，很难预先调好“重计算参数”。

优化方法

1. 动态侦测：在每个训练 Step 之前，先统计当前各个“专家并行 Rank”所分配到的 token 总数量；

2. 阈值触发：若某个 Rank 分配到的 token 数量超过预设阈值，则自动开启重计算逻辑；否则保持常规计算；

3. 智能开关：对不同的moe dispatcher采用不同的重计算方式。

通俗比喻

当你和同事们分摊搬东西时，如果A同事拿了特大箱子，其他人手都空着。这时，你会让A暂时把一些东西放地上（重新计算），等到他搬完一部分再回来挑起；等到大家分工均匀了，就恢复正常搬运。这样既能让大家都忙起来，也避免了某个人因超负荷工作而累倒。

优化效果

• 提升性能：只有在必要情况下才启动重计算，大部分时间都能用最快的方式跑；
• 更稳定：即使训练初期数据分配不均，也不会因OOM而中断训练。

2.3 DualPipeV：“双向流水线”

问题背景

DeepSeek提出的DualPipe^[2] 方案需要在流水线并行（Pipeline Parallel）中为模型参数保留两份拷贝，这对显存要求极高，且在 Bubble 较大的场景下并行效率有限。

优化方法

DualPipeV将模型在 PP 维度拆分为前半段（PP0 - PPN/2-1）与后半段（PPN/2 - PPN-1）：

1. 前半段按照PP顺序（PP0 - PPN/2-1），看做一个完整模型布置到所有节点上；

2. 后半段按照PP逆序（PPN-1 - PPN/2），看做一个完整模型布置到所有节点上。

   
   

两组之间交替发送激活与梯度，充分减少空闲等待时间。这样，只需在每张显卡上保留一份参数拷贝，同时保持较高的流水线并行度。

图1 DualPipeV示例图

来源：https://github.com/deepseek-ai/DualPipe

通俗比喻

就像工厂生产线：如果把生产过程切成两半，整个流水线是一个V字型，每组工人在处理前半个流水线的一道工序的同时，负责后半个流水线的一道工序。当其中一道工序需要等待时，可以处理另一道工序，甚至可以双管齐下，两侧工序同时进行。

优化效果

• 显存降低：相比传统Dualpipe，仅需保存一份参数拷贝，显存降低约 20%；
• 吞吐提升：减少流水线阶段之间的空闲（气泡），整体训练速度提升可达 10% 以上。

2.4 MoE多级内存优化：“分层卸载”

问题背景

除了前面提到的“某些专家突然超载”情况，整个专家（MoE）网络里还有很多“子环节”、各种小运算（例如：激活函数、向量重排、共享专家算子等），在显存吃紧的时候，也需要“分级”来处理。

优化方法

• 把专家里最“耗显存”的几个步骤，分成几个层级：

a. 轻量级重计算：只对激活函数、向量重排、router路由这些小环节做重计算；

b. 中度重计算：在上面基础上，选择专家内部的某些全连接层和共享专家（Shared Expert）做重计算。

c. 全量重计算：MoE模型部分全量做重计算。

• 多层级重计算，可以将显存浪费降到最低，同时尽可能保持训练速度。

通俗比喻

想象训练MoE模型像在沙漠探险。 显存是珍贵的骆驼运力（负重能力）。轻量： 只背少量必需品（省运力，稍慢）。中度： 选择性背大件（平衡运力与速度）。全量： 所有装备现用现造（运力最省，行动最慢）。分层选择，用最小速度代价换最大运力空间。

优化效果

• 更灵活：根据显存紧张程度，采用不同层级的内存优化方法；
• 损失更小：做最合适的显存优化，让性能损失最低。

  
  

在显存紧张的思路下，多级内存优化相较于不优化时能节省 12% 左右的显存峰值，而整体训练速度仅损失3% 左右，为中小集群训练带来显著价值。

2.5 MoE Batch GEMM：让专家计算“汇成批”一次到位

问题背景

在 MoE模型 中，不同专家收到的输入token数量往往不同，这导致每个专家要做的矩阵乘法（GEMM）大小不一。GPU 在处理大小不一的矩阵运算时，可以采用groupgemm提升算力利用率，但相对于均匀计算，效率还是有所降低。

优化方法

• 把输入长度 “对齐”：在进入专家前，给“超量输入”专家丢弃一些数据， 给“少量输入”的专家补上一些“空白”数据，这样让所有专家的输入长度一致；
• 然后把所有专家的矩阵乘法合并到一个“批量（Batch）GEMM”操作里一次性完成，充分利用 GPU 的并行能力。

通俗比喻

想象你有好几批货，大小差异很大，不利于装入标准箱进行一次性搬运。这时让较大的货物，拿去一部分，较小的货物，添加一部分，就可以一次性把好几个标准箱同时装车，搬运效率更高。

优化效果

• 大幅提升 GPU 利用率：在实验中，可提升专家计算效率约 15%；
• 略微精度影响：因为 Batch GEMM 会做少量的tokens丢弃，对精度有少量影响。但从长期训练看，模型loss误差在1%以内，对整体模型效果几乎没有影响。

3、计算与通信并行：让“传输”更无缝

在大规模并行训练中，“算”与“传”往往会发生冲突：当 GPU 在做大矩阵计算时，却要停下来做 AllReduce/AlltoAll等通信，结果就是一边算，一边等。或者在已有的“算”与“传”并行场景中，两者发生硬件资源竞争，导致性能相互影响。MXMACA 主要通过 SDMA、通算融合算子等手段，尽量让“算”与“传”不再相互干扰。

3.1 SDMA通信并行：让设备侧“专属搬运工”来接手

问题背景

在计算通信并行场景中，由于GPU核心既承担计算任务，又承担通信任务（如AllGather、ReduceScatter），容易导致资源竞争，使得通信与计算互相拖慢。

优化方法

• 沐曦C系列 GPU 内置了 SDMA引擎，可以让显卡侧在节点内专门负责高速数据传输。

• 节点间使用CPU和网卡来实现通信传输。

通信最大程度减少对GPU的使用，可以有效减轻互相抢资源的情况。

通俗比喻

SDMA通信引擎的实现，就好像生产车间里出现了“自动小推车”，一台机器算完半成品后，直接把它放到小推车上，小推车负责自动把零件送到下一个工作台；原来那台机器不用为送货而分摊精力。

优化效果

• 减少“算”和“传”互相抢资源：其结果是训练速度能提高约 4%~8%；

• 简单易用：只需在训练时打开相应开关，SDMA 就自动接管通信。

3.2 Tensor Parallel Overlap（TP Overlap）：计算与通信融合

问题背景

在 TP（张量并行）切分场景下，计算与通信的依赖关系难以打通：

• 有依赖关系的算子（如 GEMM → ReduceScatter），无法并行；
• 无依赖关系的算子（如部分 Compute + Allgather），则会与计算抢占 GPU 资源。

优化方法

1. GEMM+ReduceScatter/AllGather 融合：

将 GEMM 计算与通信算子写入同一个 CUDA Kernel 中，直接将 GEMM 结果远写到其他 GPU，省去了显存读写与 kernel 启动开销。同时实现了通信和计算细粒度切分，使细粒度间的计算和通信任务不存在依赖关系，从而并行执行。

2. 无依赖算子 SDMA 传输：

对于无依赖关系的通信算子（如BWD中部分AllGather或者ReduceScatter），使用SDMA完成，从而避免与Compute算子争夺内存带宽和算力资源。

图2 TP overlap融合算子示例图

通俗比喻

好比生产线上的半成品不再“先放到货架，再由叉车搬去下一个工序”；而是在同一个环节里边加工边传送，让“传送”像流水一样跟着“加工”一起走，省掉了中途的反复搬运。显卡就像流水线上的工人，既动手加工又顺手交接，效率显著提升。

优化效果

• GEMM+RS/AG 融合使得通信开销降低 20% 左右，显存占用更友好;
• 与 SDMA 联合使用时，在通信瓶颈明显的场景，可带来5%~10%的整体训练加速；
• 由于通信与计算冲突减少，GPU 利用率相比原生 Megatron-LM 提升 7%~10%。

3.3 MoE Comm Overlap：让 MoE 通信与专家计算并行

问题背景

在原生Megatron-LM的MoE 中，单层 Transformer 里前向会有两个 AlltoAll，反向也有两个AlltoAll。这些通信操作往往与专家（Expert）计算串行执行，导致并行度严重不足。

优化方法

通过将 MoE 层划分为多个子单元，实现 AlltoAll 通信与专家计算的高度并行：

1. 将其中两个 AlltoAll 与 Shared Expert 的前向和反向计算并行；

2. 另外的AlltoAll与D/W分离后的专家计算并行。

   
   

理论上可达 75% 的全 Overlap 率，相比原生Overlap水平大幅提升。

通俗比喻

MoE Comm Overlap，相当于原始MoE计算和通信都在一条路上，现在增加了一条路，通过计算通信分解，让AlltoAll通信单独走一条路，大大减少来回等待。

优化效果

在 DeepSeek V3中，MoE Comm Overlap 使得AlltoAll通信与计算并行度提升约 3 倍：

• 单层 AlltoAll Overlap 达到 75% 理论并行度；
• 整体 MoE 训练吞吐率提升 8%~10%；
• 训练中每个迭代的 Loss 相对误差低于 1%，没有明显精度损失。

4、显存优化：多维度“榨干”硬件潜力

训练时的显存就像钱包里的空间，装不下就会“爆卡”。 MXMACA提供了一系列显存优化策略，从 Granular Activation Offload到Granular Recompute，多管齐下帮你“花最少的钱，装最多的东西”，让有限的显存能撑起更大规模的训练任务。

4.1 细粒度激活offload：只“偷工”不“减质”

问题背景

在流水线并行中，不同阶段（Pipeline Stage）需要存储的“中间激活数据”数量并不一样。有些阶段需要保留很多激活，有些阶段只需要少量。若直接把所有激活都卸载到主机内存，势必增加大量数据传输，很难与计算相互掩盖，拖慢训练。

优化方法

• 区分阶段卸载需求：只把第一个stage的激活卸载到主机内存，让后面几个stage保留在显存里；
• 或者根据实际显存压力，对某几层激活做卸载，而其他层保留在显存中;
• 这样在需要时再把它们提前拉回来，不用每一层都卸载，占用带宽和时间最小。

通俗比喻

就像搬家时，你把最重的家具先搬到小车上存放，但把沙发、床这些需要马上用的常驻在家里。等到后面空间还紧张，再逐个决定把哪几个“没那么急”的物件先运出去。这样既不占用车的所有空间，也避免了一次性搬空再慢慢拉回来的低效。

优化效果

• 减少不必要的卸载／加载：最大限度保留训练速度，相对于普通重计算方法，在LLaMA2-70B训练上可以提升约6%的性能；
• 显存更灵活使用：即使显存并不充裕，也能让大模型跑起来。

4.2 细粒度重计算：对轻量计算分层重计算

问题背景

重计算在显存紧张时非常有效，但如果把所有计算都重算一遍（全量重计算），会让整体训练速度大幅下降。很多时候，仅把“轻量”的那部分（例如归一化层或激活函数）重算，就能腾出不少显存，又影响不大。

优化方法

1. Norm 重计算：只把归一化层（LayerNorm）相关的中间结果释放显存，反向时再重算。

2. 激活函数重计算：只把激活函数（如 GELU、Swiglu 等）的中间结果释放显存，反向时再重算。

3. 不均匀细粒度：对不同的PP stage，因为显存压力不同，使用的重计算方法和重计算力度也可以不同。

我们可以根据实际显存压力和性能需求，把“Norm 重算”和“激活重算”与传统的“全量重算”灵活组合。例如：在某些阶段只做 Norm 重计算，其他阶段保持全量；或者只做激活重计算……总之，以最小代价解决显存不足问题。

通俗比喻

该比喻和细粒度激活卸载类似。

优化效果

• 显存腾得更多：相同“省显存”目标下，比起全量重计算，速度更快；
• 灵活组合：既能满足“极限省显存”场景，也能兼顾训练速度。

5、自动搜索与集群训练：迈向“零调优”时代

当训练规模从数十张GPU扩展到成百上千张GPU 时，手动在多维并行维度上逐个尝试，几乎是不可能在有限时间里搞定的工作。MXMACA 通过“Auto Search”引擎和“DLRover”^[4]两大工具，实现了自动化调优与容错加速，让你更专注于算法设计与数据准备，而非配置参数。

5.1 Auto Search：一键找到最佳并行方案

问题背景

在 Megatron-LM 里，你可能同时考虑张量并行（Tensor Parallel）、流水线并行（Pipeline Parallel）、数据并行（Data Parallel）、专家并行（MoE Parallel）等维度。不同组合下，显存占用和性能差别巨大,要人工一一尝试，既浪费时间，也容易错过更优解。

优化方法

MXMACA 引入一套基于算子、显存与通信三大模块的自动调优（Auto Search）引擎：

1. 构建性能模型：

• 对常见算子（GEMM、AllReduce、AlltoAll、Offload、Recompute 等）进行微基准测试；
• 对不同显存策略（Recompute、Offload等）下的单节点性能进行采样；
• 对常见网络拓扑（3D Mesh、MetaLink等）下通信性能进行建模。

2. 全局搜索与预测：

• 基于先验遍历TP/PP/EP等切分空间，自动枚举候选配置；
• 结合性能模型，快速估算各候选切分配置在多节点下的 TGS（Token per GPU per Second）与显存占用；
• 打分排序后，输出 Top-k 最优配置。

图3 Auto Search自动搜索图

通俗比喻

就像你要组织一次大规模搬家，有几百个箱子、几十辆卡车，各卡车载重不同、路况也不同。传统做法是“卡车 A 多装点、卡车 B 少装点、卡车C 跑好点……”人工来回摸索。Auto Search 就是提前用模型测算好哪几种装载方案最经济，给你一个“前五优选”，你只需要挑个最方便的兑现即可。

优化效果

• 省时省力：从“试错式”调参变成“一次性推荐”；
• 效果可靠：背后有数据模型支撑，不会轻易被主观偏差误导；
• 灵活可扩展：适用于不同规模的集群、不同目标（更省显存或更高吞吐）。

5.2 DLRover Flash Checkpoint（“闪电”持久化）

问题背景

大型分布式训练任务常因节点故障或网络抖动导致中断，因为故障导致的集群空闲和回滚训练，都会导致集群资源的浪费。另一方面，在训练过程中，往往需要向存储介质一次性写入数百上千 GB 数据，耗时数分钟甚至十几分钟，影响迭代效率。

优化方法

借助DLRover Flash Checkpoint 机制，将训练状态（包括模型权重、优化器状态、学习率调度状态等）先写入CPU，再异步持久化到分布式文件系统。主要优势有：

1. 异步写入：

• 前端将 Checkpoint 数据同步写入CPU即可返回，训练阻塞时间降至最短，达到秒级；
• 后端异步从CPU将模型数据写入文件系统，充分利用 CPU 与网络带宽。

2. 故障恢复：

• 若节点瞬时宕机，DLRover 可瞬间将CPU内存模型数据强制落盘，不会出现 Checkpoint 丢失；
• 对于非完整节点宕机，在模型数据落盘后，会从冗余节点中选取节点替换故障节点，并自动拉起训练。

通俗比喻

就像你在写文档时，Word 会自动把内容先存在缓存里，然后后台再慢慢写到硬盘；如果电脑突然关机，缓存里最后的内容会被紧急落盘，下次打开就能直接恢复到缓存时的状态。

优化效果

在千卡级别集群上，DLRover Flash Checkpoint 将大小1T左右的 Checkpoint 写盘时间从 10 分钟缩减到 10秒以内；节省85%因为集群故障导致的训练回滚和空闲时间。

5.3 慢节点检测：迅速找出与剖析“拖后腿”的那台

问题背景

在大集群训练中，某台机器网络带宽突然变差、某块显卡温度过高降频、或者其他硬件异常等等，都会让那台节点训练速度变慢。可一旦出现“1 台慢”，整个训练“队伍”就会被拖慢，因为大家需要等待。

优化方法

• 内置 MCTX（MXMACA Tools Extension）：在训练中，自动给“前向”“反向”“通信”“优化”等各环节加上“埋点”，记录耗时、网络延迟等细节。
• 分层级别监测：可只看最关键的“前向/反向/优化耗时”（Level 0），也可以看更细的“每个算子、每次通信操作耗时”（Level 1/Level 2），精度高到看到“某个节点的 AlltoAll 通信慢了 20%”。
• 自动告警与定位：一旦发现某个节点在某个环节耗时显著高于平均值，就会报告给用户，帮助工程师迅速定位到“哪台机器的哪一步出了问题”。

通俗比喻

就像车队比赛时，摄影机会记录每辆车的圈速、过弯情况、进站时间等。一旦发现某辆车某圈速度比别人慢，就立即发出提示，帮助车队找出“哪里出现了瓶颈”（比如轮胎不行、油压不稳、驾驶员操作问题等），及时修正，保持整体队速。

优化效果

• 极大节省排查时间：不用手动远程登录到每台机器一遍遍看日志；
• 精确定位瓶颈：从整体到算子级别都可监测，找到“问题根源”；
• 训练更稳定：及时剔除或修复“慢节点”，维持整个集群的高速运行。

6、其他辅助优化手段：从小细节中获取额外收益

除了上面提到的几个核心方向，MXMACA 还在算子融合、并行调度等细节方面做了许多打磨，让整体训练更顺滑。下面简要介绍两项常见的补充优化。

6.1 算子融合（Flash Fusion）：把“小动作”合并成“大动作

问题背景

模型里有很多很常见但“零碎”（Memory bound）的操作，比如 “加偏置再激活再 Dropout 再相加” 这一连串动作，如果每一步都拆成单独算子去执行，就会大量占用显存带宽和启动内核的开销。

优化方法

• 算子分析：分析模型中存在的高频且memory bound的小算子，提取连续小算子操作的pattern。
• 算子融合：对连续小算子操作设计融合算子，尽量减少中间内存读写与 Kernel 启动次数。
• 支持的融合模式包括：Swiglu (Bias Swiglu)、Repeat GQA、Bias-GELU、BDA (Bias+Dropout+Add)、RoPE、MoE-Permute/Unpermute/Router 等。

通俗比喻

想象你去餐厅吃套餐，原本你要点“炸鸡”“薯条”“饮料”“沙拉”四样，如果每次都是厨师分散地一个一个做，出餐就会慢很多；而“套餐”把它们组合成一个连贯流程，一次性煎炸加热、打包好，效率便会高不少。

优化效果

在DeepSeek V3 模型训练中，启用 Flash Fusion 后可带来 5%以上的性能提升，且降低了显存占用。

6.2 Zero Bubble：零气泡流水线

问题背景

在 Pipeline Parallel（PP）中，1F1B的模型调度方式，容易产生“泡沫”（Bubble），即GPU闲置等待的时间，影响资源利用率。这种现象随着PP的增大，或者Global Batch Size（GBS）的减小，愈加严重。

优化方法

借鉴 Zero-Bubble Pipeline Parallelism[3]的思想，MXMACA集成了ZBH1（Zero Bubble H1）方案：

• 将传统 PP 中的 Bubble 率降至1/3；
• 不增加第1个PP Stage的显存；
• 适用于 GBS较小、Bubble显著且显存受限的场景。

通俗比喻

就像一条生产线，原本上下游有时会错拍，有时会轮到机器没料可做。Zero Bubble 就是优化排产计划，让前后几道工序更均匀衔接，减少待料时间。不需要给第一道工序额外加机器（显存），却能让整体产量更高。

优化效果

• 提升流水线利用率：实测在一些场景下可让显卡吞吐率提升 8%~12%；
• 显存压力不增加：Zero Bubble 并不需要给第一个 Stage 多分配显存，只要合理调整微批次顺序就能降低气泡，同时不引入额外显存开销；
• 适合显存不足时使用：当显存比较紧张，无法开启更高级的虚拟流水时，Zero Bubble依然能带来效率提升。

6.3 Empty Transformer Layers：空层补齐

问题背景

在启用VPP时，若模型总层数与 PP Stage 数量不再为整除关系（如质数层），常会出现无法均匀拆分为每 VPP Stage 保持相同层数的瓶颈。例如，61 层模型切为PP = 8 时，每个 Stage 无法平均分配层数；又比如 15 层模型切为PP = 3 时，每个 Stage 均为5层，质数层无法进一步采用VPP切分。

优化方法

MXMACA 提供“空层插入”（Empty Layer） 功能：

• 虚拟将模型层数扩充至满足 VPP 阶段拆分需求的最小整数；
• 在指定位置插入“空 Transformer 层”，该层仅作占位，无实际计算，保证每个 PP Stage 拥有相同的 VPP Stage 数目；
• 额外的资源开销仅为极少量 Metadata，无显著显存/计算损耗。

优化效果

实测在 PP=8、VPP=2 场景下，经过空层补齐的 61→64 层模型，与直接使用不均匀 PP 相比，训练速度提升 6% 以上。

7、MXMACA大模型训练优化：极致算力，一触即发

通过一系列“计算通信并行”、“专家模型优化”、“显存优化”、“自动调优与集群训练工具”等手段，MXMACA 成功让 Megatron-LM 在沐曦硬件环境中实现了如下优势：

更少显存×更高性能

• 同等硬件条件下，训练时所需显存可节省 10%~30%；
• 同时，整体训练速度较原生 Megatron-LM 提升20%左右。

更低门槛×更易部署

• 对非专业研发人员也非常友好：只需在训练脚本里打开“省显存模式”“通信并行模式”“自动调优模式”等开关，无需手动调命令行参数；
• Auto Search 能在几分钟内给出最优并行配置，不必再费心一个维度一个维度去尝试。

更高稳定性×更强容错性

• DLRover Flash Checkpoint 能让训练中断后分钟级别就恢复，而不会造成集群数小时空闲；
• MCTX 监测可自动提示“哪台GPU慢了”“卡在计算还是卡在通信”，帮助团队迅速定位并解决问题。

丰富扩展性×持续迭代

• 除了刚才讲到的这些优化，MXMACA 还在持续对 DeepSpeed、PaddlePaddle、Colossal-AI 等其他主流训练框架做兼容与优化；
• 未来也会陆续增加对新算子的融合、更多底层硬件特性的深度利用，让大模型训练更“省心、更高效”。

图4 主要模型优化前后性能及提升比率

8、总结：让大模型训练也能“大众化”

希望在有限硬件条件下训练上百亿大模型

想快速配置集群并行，不想一遍遍试命令行参数

想让训练过程有更强的容错、断点续训能力

想站在“技术巨人”肩膀上，用最少的工程成本跑出最大价值

那么不妨试试 MXMACA 提供的这些优化能力(https://developer.metax-tech.com/softnova/docker)。未来，我们也会持续迭代、不断打磨各种新功能，助力更多团队、更多应用场景，让“大模型训练”真正实现“大众化”、变得“人人可跑、人人可用”。

参考资料

[1] https://github.com/NVIDIA/Megatron-LM

[2] DeepSeek-AI. (2025). DeepSeek-V3 Technical Report. arXiv:2412.19437.

Retrieved from https://arxiv.org/abs/2412.19437

[3] https://github.com/sail-sg/zero-bubble-pipeline-parallelism

[4] https://github.com/intelligent-machine-learning/dlrover