作者：王順飛

沐曦PDE部門

在如今的人工智能浪潮中，大規模語言模型（上百億乃至千億參數）正迅速改變著我們的工作和生活。然而，訓練這些龐大的模型往往面臨“算力不足、顯存不夠用、通信太慢”等諸多挑戰。為了讓大模型的訓練過程更順暢、更高效，沐曦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 往往會遇到以下幾個難題：

1MoE模型負載均衡訓練困境

MoE 模型訓練會出現「熱門專家」被過度調用而導致計算和顯存極不均勻，拖慢訓練速度且易導致顯存溢出。此外，跨節點的 AlltoAll 通信占據了較多的訓練時間。

2計算與通信資源競爭

在分布式訓練中，過細的模型切分雖然可以提升計算并行度，但往往會大幅增加跨節點通信開銷。特別是在計算與通信需要共享硬件資源的原生并行架構中，計算操作和通信操作會相互競爭有限的帶寬和計算單元，這種資源爭用問題常常導致實際并行效率低于理論預期。

3顯存（GPU內存）吃緊

大模型需要存儲很多“中間計算結果”（比如激活值、梯度、優化器狀態）和大量參數，當模型規模上升時，很容易出現“顯存不夠用”的狀況，導致訓練中斷，進而影響效率。

4集群訓練挑戰

當你用成百上千塊 GPU 訓練一個模型時，如何把每一種并行方式合理組合，才能既不爆顯存又能讓計算滿載？靠人工一遍遍嘗試，不但耗時，還容易錯過更優的組合。集群訓練如何減少因故障導致的中斷和資源浪費，如何快速定位慢節點，都是集群訓練常遇的挑戰。

5低效算子瓶頸

大模型訓練常受限于某些關鍵算子的低效實現，這些顯存訪問密集型算子是拉低模型MFU的一個重要因素。

為了解決這些痛點，我們結合沐曦曦云C系列GPU的硬件特點，做了多方面的“落地優化”。既保留了框架的靈活性，也在常見疑難場景中提供了“一鍵開關”式的配置。下面我們將從 MoE 優化、計算通信并行、顯存優化、自動調優與集群訓練、算子融合等幾個重點模塊，逐一展開。

2MoE優化：讓混合專家訓練更從容

Mixture-of-Experts（MoE）是日益流行的混合專家模型，通過路由讓tokens選擇相應的專家計算，能夠顯著提升模型容量與表達能力。然而，同時也帶來了專家之間負載不均、顯存爆炸等挑戰。MXMACA 針對 MoE 提供了多種優化策略，幫助你在顯存和吞吐之間找到更好的平衡。

2.1“冷熱專家”優化：削峰填谷式通信減負

問題背景

在MoE 模型訓練初期，某些專家會被大量 token 路由（“熱門”），而其他專家幾乎閑置。這導致頻繁且不均勻的 AlltoAll 通信：熱門專家所在的顯卡要不斷從多臺顯卡拉數據，通信開銷巨大。

優化方法

本地備份熱門專家：在模型剛開始訓練時，把被訪問最頻繁的幾位“熱門專家”在本地多復制一份，這樣熱門專家的計算就可以留在本地完成，減少跨節點通信。

在訓練后期，當各個專家訪問次數趨于均衡時，再把本地備份關閉，恢復普通通信模式。

通俗比喻

想象一個在線商店，某款商品突然在一兩個城市爆火，下單量激增。如果所有訂單都要從遠在總部的倉庫發貨，就會出現“配送中心爆倉、快遞車來回奔波”導致遲遲配送不到顧客手中。優化方式就好比在每個城市中心先存放幾箱這款熱銷商品，顧客下單之后直接從本地倉庫發貨，大大縮短配送路徑。等到熱度消退、全國范圍內需求趨于均衡時，再把多余的本地庫存退回到總部或取消本地備貨。一句話：把“最暢銷的那幾件”臨時放到客戶附近供他們隨時取，就能避免每次都從很遠的倉庫拉貨。

優化效果

減少跨節點通信：熱門專家不用每次都“喊話”遠端節點；

性能提升：訓練吞吐量提高約 8%；

顯存可控：因為只給幾個熱門專家多留一份，所以額外顯存開銷有限。

2.2MoE自適應重計算：“分工不均”與節點溢出

問題背景

在 MoE 前向（Forward）/反向（Backward）時，Batch 內的某些 token 會被路由到熱門專家（Expert），導致該專家對應的 GPU 需要處理大量激活，占用顯存陡增，容易 OOM（Out-Of-Memory）。尤其是在訓練早期，token 分配波動較大，很難預先調好“重計算參數”。

優化方法

動態偵測：在每個訓練 Step 之前，先統計當前各個“專家并行 Rank”所分配到的 token 總數量；

閾值觸發：若某個 Rank 分配到的 token 數量超過預設閾值，則自動開啟重計算邏輯；否則保持常規計算；

智能開關：對不同的moe dispatcher采用不同的重計算方式。

通俗比喻

當你和同事們分攤搬東西時，如果A同事拿了特大箱子，其他人手都空著。這時，你會讓A暫時把一些東西放地上（重新計算），等到他搬完一部分再回來挑起；等到大家分工均勻了，就恢復正常搬運。這樣既能讓大家都忙起來，也避免了某個人因超負荷工作而累倒。

優化效果

提升性能：只有在必要情況下才啟動重計算，大部分時間都能用最快的方式跑；

更穩定：即使訓練初期數據分配不均，也不會因OOM而中斷訓練。

2.3DualPipeV：“雙向流水線”

問題背景

DeepSeek提出的DualPipe[2]方案需要在流水線并行（Pipeline Parallel）中為模型參數保留兩份拷貝，這對顯存要求極高，且在 Bubble 較大的場景下并行效率有限。

優化方法

DualPipeV將模型在 PP 維度拆分為前半段（PP0- PPN/2-1）與后半段（PPN/2- PPN-1）：

前半段按照PP順序（PP0- PPN/2-1），看做一個完整模型布置到所有節點上；

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

兩組之間交替發送激活與梯度，充分減少空閑等待時間。這樣，只需在每張顯卡上保留一份參數拷貝，同時保持較高的流水線并行度。

圖1 DualPipeV示例圖

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

通俗比喻

就像工廠生產線：如果把生產過程切成兩半，整個流水線是一個V字型，每組工人在處理前半個流水線的一道工序的同時，負責后半個流水線的一道工序。當其中一道工序需要等待時，可以處理另一道工序，甚至可以雙管齊下，兩側工序同時進行。

優化效果

顯存降低：相比傳統Dualpipe，僅需保存一份參數拷貝，顯存降低約 20%；

吞吐提升：減少流水線階段之間的空閑（氣泡），整體訓練速度提升可達 10% 以上。

2.4MoE多級內存優化：“分層卸載”

問題背景

除了前面提到的“某些專家突然超載”情況，整個專家（MoE）網絡里還有很多“子環節”、各種小運算（例如：激活函數、向量重排、共享專家算子等），在顯存吃緊的時候，也需要“分級”來處理。

優化方法

把專家里最“耗顯存”的幾個步驟，分成幾個層級：

輕量級重計算：只對激活函數、向量重排、router路由這些小環節做重計算；

中度重計算：在上面基礎上，選擇專家內部的某些全連接層和共享專家（Shared Expert）做重計算。

全量重計算：MoE模型部分全量做重計算。

多層級重計算，可以將顯存浪費降到最低，同時盡可能保持訓練速度。

通俗比喻

想象訓練MoE模型像在沙漠探險。 顯存是珍貴的駱駝運力（負重能力）。輕量： 只背少量必需品（省運力，稍慢）。中度： 選擇性背大件（平衡運力與速度）。全量： 所有裝備現用現造（運力最省，行動最慢）。分層選擇，用最小速度代價換最大運力空間。

優化效果

更靈活：根據顯存緊張程度，采用不同層級的內存優化方法；

損失更小：做最合適的顯存優化，讓性能損失最低。

在顯存緊張的思路下，多級內存優化相較于不優化時能節省 12% 左右的顯存峰值，而整體訓練速度僅損失3% 左右，為中小集群訓練帶來顯著價值。

2.5MoE Batch GEMM：讓專家計算“匯成批”一次到位

問題背景

在 MoE模型 中，不同專家收到的輸入token數量往往不同，這導致每個專家要做的矩陣乘法（GEMM）大小不一。GPU 在處理大小不一的矩陣運算時，可以采用groupgemm提升算力利用率，但相對于均勻計算，效率還是有所降低。

優化方法

把輸入長度 “對齊”：在進入專家前，給“超量輸入”專家丟棄一些數據， 給“少量輸入”的專家補上一些“空白”數據，這樣讓所有專家的輸入長度一致；

然后把所有專家的矩陣乘法合并到一個“批量（Batch）GEMM”操作里一次性完成，充分利用 GPU 的并行能力。

通俗比喻

想象你有好幾批貨，大小差異很大，不利于裝入標準箱進行一次性搬運。這時讓較大的貨物，拿去一部分，較小的貨物，添加一部分，就可以一次性把好幾個標準箱同時裝車，搬運效率更高。

優化效果

大幅提升 GPU 利用率：在實驗中，可提升專家計算效率約 15%；

略微精度影響：因為 Batch GEMM 會做少量的tokens丟棄，對精度有少量影響。但從長期訓練看，模型loss誤差在1%以內，對整體模型效果幾乎沒有影響。

3計算與通信并行：讓“傳輸”更無縫

在大規模并行訓練中，“算”與“傳”往往會發生沖突：當 GPU 在做大矩陣計算時，卻要停下來做 AllReduce/AlltoAll等通信，結果就是一邊算，一邊等。或者在已有的“算”與“傳”并行場景中，兩者發生硬件資源競爭，導致性能相互影響。MXMACA 主要通過 SDMA、通算融合算子等手段，盡量讓“算”與“傳”不再相互干擾。

3.1SDMA通信并行：讓設備側“專屬搬運工”來接手

問題背景

在計算通信并行場景中，由于GPU核心既承擔計算任務，又承擔通信任務（如AllGather、ReduceScatter），容易導致資源競爭，使得通信與計算互相拖慢。

優化方法

沐曦C系列 GPU 內置了 SDMA引擎，可以讓顯卡側在節點內專門負責高速數據傳輸。

節點間使用CPU和網卡來實現通信傳輸。

通信最大程度減少對GPU的使用，可以有效減輕互相搶資源的情況。

通俗比喻

SDMA通信引擎的實現，就好像生產車間里出現了“自動小推車”，一臺機器算完半成品后，直接把它放到小推車上，小推車負責自動把零件送到下一個工作臺；原來那臺機器不用為送貨而分攤精力。

優化效果

減少“算”和“傳”互相搶資源：其結果是訓練速度能提高約 4%~8%；

簡單易用：只需在訓練時打開相應開關，SDMA 就自動接管通信。

3.2Tensor Parallel Overlap（TP Overlap）：計算與通信融合

問題背景

在 TP（張量并行）切分場景下，計算與通信的依賴關系難以打通：

有依賴關系的算子（如 GEMM → ReduceScatter），無法并行；

無依賴關系的算子（如部分 Compute + Allgather），則會與計算搶占 GPU 資源。

優化方法

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.3MoE Comm Overlap：讓 MoE 通信與專家計算并行

問題背景

在原生Megatron-LM的MoE 中，單層 Transformer 里前向會有兩個 AlltoAll，反向也有兩個AlltoAll。這些通信操作往往與專家（Expert）計算串行執行，導致并行度嚴重不足。

優化方法

通過將 MoE 層劃分為多個子單元，實現 AlltoAll 通信與專家計算的高度并行：

將其中兩個 AlltoAll 與 Shared Expert 的前向和反向計算并行；

另外的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

細粒度重計算：對輕量計算分層重計算

問題背景

重計算在顯存緊張時非常有效，但如果把所有計算都重算一遍（全量重計算），會讓整體訓練速度大幅下降。很多時候，僅把“輕量”的那部分（例如歸一化層或激活函數）重算，就能騰出不少顯存，又影響不大。

優化方法

Norm 重計算：只把歸一化層（LayerNorm）相關的中間結果釋放顯存，反向時再重算。

激活函數重計算：只把激活函數（如 GELU、Swiglu 等）的中間結果釋放顯存，反向時再重算。

不均勻細粒度：對不同的PP stage，因為顯存壓力不同，使用的重計算方法和重計算力度也可以不同。

我們可以根據實際顯存壓力和性能需求，把“Norm 重算”和“激活重算”與傳統的“全量重算”靈活組合。例如：在某些階段只做 Norm 重計算，其他階段保持全量；或者只做激活重計算……總之，以最小代價解決顯存不足問題。

通俗比喻

該比喻和細粒度激活卸載類似。

優化效果

顯存騰得更多：相同“省顯存”目標下，比起全量重計算，速度更快；

靈活組合：既能滿足“極限省顯存”場景，也能兼顧訓練速度。

5自動搜索與集群訓練：

邁向“零調優”時代

當訓練規模從數十張GPU擴展到成百上千張GPU 時，手動在多維并行維度上逐個嘗試，幾乎是不可能在有限時間里搞定的工作。MXMACA 通過“Auto Search”引擎和“DLRover”[4]兩大工具，實現了自動化調優與容錯加速，讓你更專注于算法設計與數據準備，而非配置參數。

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

問題背景

在 Megatron-LM 里，你可能同時考慮張量并行（Tensor Parallel）、流水線并行（Pipeline Parallel）、數據并行（Data Parallel）、專家并行（MoE Parallel）等維度。不同組合下，顯存占用和性能差別巨大,要人工一一嘗試，既浪費時間，也容易錯過更優解。

優化方法

MXMACA 引入一套基于算子、顯存與通信三大模塊的自動調優（Auto Search）引擎：

構建性能模型：

對常見算子（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.2DLRoverFlash Checkpoint（“閃電”持久化）

問題背景

大型分布式訓練任務常因節點故障或網絡抖動導致中斷，因為故障導致的集群空閑和回滾訓練，都會導致集群資源的浪費。另一方面，在訓練過程中，往往需要向存儲介質一次性寫入數百上千 GB 數據，耗時數分鐘甚至十幾分鐘，影響迭代效率。

優化方法

借助DLRover Flash Checkpoint 機制，將訓練狀態（包括模型權重、優化器狀態、學習率調度狀態等）先寫入CPU，再異步持久化到分布式文件系統。主要優勢有：

異步寫入：

前端將 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.2Zero 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.3Empty 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% 以上。

7MXMACA大模型訓練優化：

極致算力，一觸即發

通過一系列“計算通信并行”、“專家模型優化”、“顯存優化”、“自動調優與集群訓練工具”等手段，MXMACA 成功讓 Megatron-LM 在沐曦硬件環境中實現了如下優勢：

1更少顯存×更高性能

同等硬件條件下，訓練時所需顯存可節省 10%~30%；

同時，整體訓練速度較原生 Megatron-LM 提升20%左右。

2更低門檻×更易部署

對非專業研發人員也非常友好：只需在訓練腳本里打開“省顯存模式”“通信并行模式”“自動調優模式”等開關，無需手動調命令行參數；

Auto Search 能在幾分鐘內給出最優并行配置，不必再費心一個維度一個維度去嘗試。

3更高穩定性×更強容錯性

DLRover Flash Checkpoint 能讓訓練中斷后分鐘級別就恢復，而不會造成集群數小時空閑；

MCTX 監測可自動提示“哪臺GPU慢了”“卡在計算還是卡在通信”，幫助團隊迅速定位并解決問題。

4豐富擴展性×持續迭代

除了剛才講到的這些優化，MXMACA 還在持續對 DeepSpeed、PaddlePaddle、Colossal-AI 等其他主流訓練框架做兼容與優化；

未來也會陸續增加對新算子的融合、更多底層硬件特性的深度利用，讓大模型訓練更“省心、更高效”。

圖4 主要模型優化前后性能及提升比率

8總結：讓大模型訓練也能“大眾化”

希望在有限硬件條件下訓練上百億大模型

想快速配置集群并行，不想一遍遍試命令行參數

想讓訓練過程有更強的容錯、斷點續訓能力

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

那么不妨試試 MXMACA 提供的這些優化能力(https://developer.metax-tech.com/softnova/docker)。未來，我們也會持續迭代、不斷打磨各種新功能，助力更多團隊、更多應用場景，讓“大模型訓練”真正實現“大眾化”、變得“人人可跑、人人可用”。