最近好幾撥做模型訓練的朋友都在問同一個問題開源模型技術報告里“總參數(shù)”越報越大顯卡上卻還跑得動參數(shù)表和顯存需求對不上。答案十有八九是 MoE?；旌蠈＜夷Ｐ蚆ixture of Experts這名字聽起來很唬人實際拆開就是一句大白話模型總參數(shù)可以很大但每個輸入 token 只激活其中一小部分“專家”參數(shù)來計算。這個思路不是這兩年才冒出來的只是大模型算力緊張以后它成了擴大模型容量最實用的手段。這篇文章不準備堆一堆勸退公式主要按我自己的理解把 MoE 為什么能省計算、路由怎么給 token 分派專家、訓練和推理要注意什么以及什么情況下不如老老實實堆 Dense 模型統(tǒng)一過一遍。適合的人正在做模型選型、準備做 MoE 微調、或者想從零搭一個小規(guī)模 MoE 實驗的工程師同學。還沒接觸過 Transformer 的讀者建議先補一下基礎再來讀。1. MoE 到底是什么從“全棧員工”到“專家團隊”1.1 稀疏激活模型變“胖”計算量沒有跟著“胖”普通 Transformer 的 FFN 層對所有 token 用同一套參數(shù)這就是 Dense 模型。假設模型有 700 億參數(shù)中間那些 FFN 權重對每個 token 都得完整算一遍所以訓練和推理成本基本跟著參數(shù)線性走。MoE 的做法則是把某些 FFN 層改造成“一組專家”每個專家是一套獨立 FFN旁邊再配一個路由模塊。輸入 token 到達這一層時先看它的 hidden state挑出少數(shù)幾個專家只算這幾個專家的 FFN其他專家在這次前向計算里直接當作不存在。稀疏激活是 MoE 的核心性質。模型“總參數(shù)量”可以做到幾百 B但單次前向真正參與計算的“激活參數(shù)”可能只有十幾 B 甚至幾 B。這就好比一間公司注冊了 800 名員工但一張工單真正被調來干活的可能只有幾個人剩下的人照常坐工位、領工資占顯存但在你這張工單上不產出。這也是為什么很多模型參數(shù)表寫的是“總參數(shù) XXXB激活參數(shù) XXB”而不是一個數(shù)。為什么這種設計能裝下更多知識Dense 模型每加一批參數(shù)就要讓所有 token 把新參數(shù)都過一遍訓練成本直接爆炸MoE 加一批專家只影響被路由選中的那一部分 token訓練成本增長遠比參數(shù)增長慢。知識容量跟著總參數(shù)量走計算成本跟著激活參數(shù)走兩者解耦之后才可能在單卡算力有限的情況下把模型塞進更大的容量。我在訓練中反復體會到的就是這一條MoE 省的是算力不是內存這一點后面部署部分還會重點講。1.2 路由決策與加權輸出一次前向計算到底發(fā)生了什么一個 MoE 層的前向流程并不復雜。輸入向量 x 先經過門控網絡門控通常是一個線性層加 softmax輸出每個專家的概率分布。接著取概率最高的前 K 個專家常見 K2把 x 分別送進這些專家各自的 FFN 里做變換得到多個專家輸出。最后用路由概率作為權重對這些專家輸出做加權求和得到這一層的最終輸出。專家之間的計算完全獨立所以天然可以并行所謂 dispatch 和 combine就是把 token 按照路由決定分發(fā)到對應專家所在的設備算完再把結果收回來拼回去。訓練階段還有個容易忽略的細節(jié)gate 在計算 logits 時會加一點噪聲。這個噪聲的目的是探索避免 router 在非常早的 step 就鎖死在某幾個專家上導致其他專家永遠沒機會學。等 warmup 階段結束再逐步把噪聲撤掉路由才開始真正進入“精細化分工”的狀態(tài)。很多從零實現(xiàn) MoE 的人漏了這一步結果 router 提前固化模型后期的表現(xiàn)上限直接被鎖死。1.3 MoE 真正解決的痛點參數(shù)容量、訓練成本與推理的三角Dense 模型的痛苦在于一個三角矛盾想提升效果就加參數(shù)加參數(shù)就要更多算力、更多顯存、更大 batch。MoE 把容量和計算解耦之后總參數(shù)漲了單位 token 的計算量只漲一點但顯存需求仍然跟總參數(shù)量走所以它解決的是“更多知識”和“有限算力”這一對矛盾而不是“更小顯存”這個矛盾。對訓練集群來說稀疏激活能大幅減少每 token 的 FLOPs讓更大 batch 成為可能這又是訓練穩(wěn)定性的額外紅利。代價也藏在三個方面。第一路由機制要學會“正確分配專家”這本身需要訓練時間第二專家被切到多卡之后通信開銷不可忽略第三負載不均衡會導致部分專家“餓死”整體模型白訓練。后面幾節(jié)基本就是圍繞這三個代價展開的。2. 路由機制與專家選擇MoE 的調度中心是怎么干活的2.1 Gating Network給每個 token 打分路由模塊本質上就是一層線性層輸入是 token 的 hidden state輸出是每個專家的 logits。維度一般是 hidden_size × num_experts。得到 logits 后做 softmax變成每個專家被選中的概率。實際選擇時并不一定非要用 softmax 之后的概率來排序直接用 logits 排序結果也一樣因為順序一致但最終輸出加權時要用 softmax 后的歸一化權重這樣才能保證總權重為 1輸出尺度穩(wěn)定。訓練時加在 logits 上的噪聲常見做法是加一個標準正態(tài)分布噪聲乘以一個很小的 scalescale 可以取 0.01 到 0.1。scale 越大探索越強router 初期越“亂跳”后期逐步關掉或調小讓選擇穩(wěn)定下來。我見過一個開源實現(xiàn)里把噪聲 scale 做成 schedulewarmup 階段 0.1后續(xù)線性降到 0實測比固定噪聲更穩(wěn)。比較省事的做法是先固定 0.01等模型訓練幾千步后再手動關掉也能跑出正常效果。2.2 Top-K 選擇為什么是 K2 而不是 K全部Top-1 最簡單計算量最小但訓練穩(wěn)定性差。因為選出的單個專家會承擔非常強的梯度更新一旦選錯優(yōu)化方向就劇烈抖動。K 如果太大比如 K8等于所有專家都參與計算稀疏激活名存實亡計算量回歸 Dense 水平還多出路由和通信開銷。Top-K 還直接影響通信量選中的專家越多每個 token 需要 dispatch 和 combine 的數(shù)據(jù)就越多跨卡傳輸?shù)拇螖?shù)也成倍增加。為什么 K2 成為普遍折中兩個專家的輸出可以做一個簡單的軟組合比單獨一個專家容忍更多噪聲梯度平滑一些同時兩路并行只比一路多一份專家計算卡在可控范圍內。多個實驗和工程實踐都指向同一個結論從 K2 再往上加質量提升很有限計算成本卻明顯上漲。所以“2”更多是工程與穩(wěn)定性的妥協(xié)而不是理論最優(yōu)解。如果你在代碼里看到有人設 K4先別急著批判得看他專家的粒度是不是已經拆得非常細此時多一兩個被選專家可能是在彌補單專家容量太小的問題。2.3 輔助平衡損失防止專家“餓死”和“撐死”完全沒有約束時路由大概率會把大部分 token 送進少數(shù)幾個專家其他專家形同虛設。這是無監(jiān)督優(yōu)化里典型的“富者愈富”被選中越多的專家梯度越充分能力越好于是又被選得更多沒被選中的專家一直拿不到有效梯度停在隨機初始化附近。最后整個模型的容量被浪費了大半。為了解決這個問題業(yè)界幾乎統(tǒng)一加一個輔助平衡損失。常見設計統(tǒng)計一個 batch 內每個專家被選中的概率均值 f_i再乘上路由分配給它的平均概率 P_i求乘積和。這個值越小說明“誰被選得多誰就被分配高概率”這樣互相強化的關系越弱均衡性越好。實際代碼里會給它乘一個很小的系數(shù)典型值 0.01 左右疊加到主損失上。這個系數(shù)非常需要手工調。我一開始圖省事設過 0.1結果專家之間確實均衡了但整體 loss 明顯變差因為強約束犧牲了路由的分配性能。后來降到 0.01 附近才找到平衡點。原則很簡單路由明顯塌縮就調大模型精度下降就調小。2.4 專家容量與 Token 丟棄容易被忽略的隱性開關每個專家的處理能力是有上限的。代碼里通常用 capacity 來表示capacity ceil(batch_tokens / num_experts) × capacity_factor如果某個專家被分到的 token 數(shù)超過 capacity超出的 token 要么被丟棄要么就地排隊等待。被丟棄的 token 通常會直接走殘差旁路也就是把這一層當成沒有專家 FFN只保留 attention 之后輸入本身。capacity_factor1.0 意味著每個專家最多只能承接平均接單量這幾乎必然導致丟棄因為路由分布不可能完美均衡調到 1.25 到 1.5 能顯著減少丟棄但會占用更多顯存和計算資源。這個參數(shù)藏得很深。很多人調 MoE 調了半天 loss 不對勁最后發(fā)現(xiàn)是 capacity 設置的問題。尤其是把專家數(shù)從 8 改成 64 時batch 內每個專家平均分配到的 token 變少了很多capacity_factor 如果不調整丟棄行為會完全改變模型表現(xiàn)。我自己訓練時會在日志里單獨打印一個 token 丟棄率指標要求它穩(wěn)定在 1% 以內一旦發(fā)現(xiàn)連續(xù)出現(xiàn)大批量 token 被丟棄優(yōu)先提高 capacity_factor 或者增強輔助平衡損失的權重。3. 進階設計細粒度專家、共享專家與路由改進3.1 細粒度專家把專家拆小組合更靈活經典 MoE 把整個 FFN 當一個專家。這種設計下單個專家內部參數(shù)很多但一次只能選兩個等于把“全科醫(yī)生”派去處理所有類型的 token粒度太粗。細粒度專家則是把專家拆小比如原先專家 FFN 的中間層維度是 4096拆成 8 個小專家、每個中間層維度 512。總參數(shù)量基本不變但路由每次能在更多候選者里挑兩個。這樣不同專家可以專精更具體的模式組合起來也更靈活。細粒度帶來的收益本質上是“組合爆炸”。假設你有 N 個小專家每次選 2 個可能的組合數(shù)是 O(N2) 量級遠大于原來 4 個大專家選 2 個的組合數(shù)。語義空間被切得更細token 的分派顆粒度也更高。代價是路由計算量增加、專家之間的通信量增加。所以不是拆得越細越好一般要在實驗里觀察效果變化通常在收益曲線變平時停止繼續(xù)增大專家數(shù)量。3.2 共享專家常設的“公共知識庫”Top-2 路由的特點就是每個 token 只走極少專家這會帶來一個問題語言模型里有大量非常通用的知識比如基礎句法、因果常識、通用推理模式如果這些也要靠路由專家去處理那所有 token 都在為這些共性反復選擇專家路由容量被白白消耗。共享專家的思路是設置一個不參與路由的專家每個 token 進來都固定經過它它就像公司的公共行政部所有人都能調用。然后再額外路由幾個專家負責領域和語義差異。實現(xiàn)上共享專家可以直接放在 MoE 層里作為固定路徑也可以把它的輸出疊加在路由專家的加權和后面。效果上共享專家讓模型更穩(wěn)定因為它保證了每個 token 至少有一條基礎計算路徑不依賴路由質量同時把路由專家解放出來讓它們更專注做差異化分工?，F(xiàn)在很多開源模型里的“共享專家”變體已經快成為標配不是偶然它確實解決了 Top-2 稀疏路由在強通用任務上的短板。3.3 部分層 MoE不是每一層都需要專家化有些實現(xiàn)不會把每個 FFN 都替換成 MoE而是挑一部分層放路由專家。淺層主要負責通用特征抽取語義標簽差異不明顯專家化收益低反而增加成本和通信壓力深層特征更抽象、更接近最終任務語義路由器更容易學到有意義的分工。具體放多少層、從第幾層開始取決于任務和模型規(guī)模。我做過一個實驗12 層 Transformer 只把最后 6 層改成 MoE和全部層改成 MoE 相比效果非常接近訓練成本卻省下不少。這屬于典型的“用稀疏換通信”思路對中等規(guī)模模型很實用。3.4 從 Dense 權重升級到 MoE一種省錢的探索路徑如果手里已經有一個訓練好的 Dense 模型想嘗試 MoE 但不想從頭預訓練可以考慮“復制擴展”把 Dense 的 FFN 權重復制成好幾份作為多個專家的初始權重再給每份權重加微小噪聲打破對稱性路由器模塊隨機初始化。這樣模型在訓練初期基本等價于原來的 Dense 模型之后再通過繼續(xù)訓練讓專家逐漸分化。這個辦法省掉了從零預訓練的大部分成本路由一開始也不至于因為完全沒有先驗知識而亂選。不過要注意初始相同的專家在早期梯度完全一樣如果噪聲太小專家分化會很慢噪聲太大模型又容易被帶偏。我實測下來初始噪聲 scale 在 0.01 到 0.05 之間比較安全同時要讓 router 在前幾百步保持較高探索強度否則復制出來的專家很可能長期處在“同質化”狀態(tài)。4. 工程落地我實測下來的 MoE 訓練與部署注意點4.1 訓練階段顯存與通信為什么會猛增Dense 模型訓練時每個參數(shù)和它的優(yōu)化器狀態(tài)都留在本地梯度是局部的MoE 不同因為專家會被切到不同 GPU 上一個 token 的 hidden state 要 dispatch 到專家所在設備計算再把結果 combine 回來。這種通信在代碼里通常表現(xiàn)為 all-to-all 通信也就是說每個設備都要給其他設備發(fā)數(shù)據(jù)也都要收數(shù)據(jù)。GPU 數(shù)量越多通信圖的規(guī)模越大小 batch 時通信占比甚至能到三到四成。顯存開銷也比直觀預期高專家參數(shù)本身、優(yōu)化器狀態(tài)、梯度這些都要跟著專家分布存儲跨節(jié)點同步更麻煩。我遇到最典型的認知偏差是以為 MoE 稀疏激活能省顯存實際單卡顯存需求幾乎等于總參數(shù)量。省的是算力不是內存。所以訓練 MoE 時通信框架和顯存規(guī)劃往往比模型結構本身更影響效率。4.2 推理部署計算省了內存沒省推理階段也一樣模型總參數(shù)量決定了最低顯存門檻。一張 80GB 的卡FP16 精度下能加載的模型總參數(shù)量上限大約 40B跟它是不是 MoE 沒什么關系。每個 token 雖然只算兩個專家但加載模型時所有專家權重都已經駐留在顯存里。換句話說計算瓶頸降了內存和帶寬瓶頸原樣保留。工程結論就是MoE 適合能夠攢大批量再統(tǒng)一跑的場景比如離線批量推理、服務端高并發(fā)不適合單條短請求要求極低延遲或單卡小顯存部署的場景。KV Cache 方面因為 attention 部分通常還是共享的序列越長attention 的 KV 占比越高這一點和 Dense 模型差不多FFN 計算占比下降之后attention 計算反而可能變成相對瓶頸。所以不能說“MoE 一定更快”關鍵看具體業(yè)務請求形態(tài)。我踩過的一個坑是在短請求高并發(fā)場景硬上 MoE結果因為每次都要跨卡通信延遲反而比 Dense 高了一截。4.3 實驗期最值得盯的三個指標訓練 MoE 不要只看 loss 曲線。我建議至少在日志里記錄三樣東西專家利用率每個專家最近一個 batch 里被選中的 token 數(shù)按專家畫柱狀圖。理想情況是分布相對均勻不要出現(xiàn)某個專家是 0 或者獨占 80% 的情況。路由熵對每個 batch 的專家概率分布求熵。熵掉得太快說明路由早早固化后期很難再分化熵一直很高則說明路由沒有學到有效分工專家都在“摸魚”。丟棄率每個 batch 里因為 capacity 限制被丟掉的 token 比例。這個數(shù)字比 loss 更能直接反映 capacity_factor 設置是否合理。這三個指標最好同步記錄。我有一次就是只看 loss覺得曲線很正常后來看了眼專家利用率才發(fā)現(xiàn)四個專家里有三個已經長時間“失業(yè)”只是剩下那一個專家勉勉強強把 loss 扛住了。如果不看利用率這種模型訓練到一半時等于是花著 MoE 的錢在跑一個比 Dense 還差的效果。5. 常見問題與排查技巧實錄實際訓練 MoE 的過程中下面這幾個問題出現(xiàn)頻率非常高我把癥狀和排查思路整理成了一張速查表。癥狀可能原因排查與解法loss 不降或波動大專家利用率極度集中路由坍縮負載均衡失效調大 aux loss 系數(shù)給 router 加噪聲或 dropout檢查初始化權重是否同質某個專家利用率長期為 0capacity_factor 過小導致 token 全被丟棄或路由初始偏向其他專家先確認丟棄率再調大噪聲與 aux loss檢查專家 id 是否正確loss 出現(xiàn)周期性尖峰特定 batch 中大量 token 涌進同一專家造成單卡計算和通信尖峰減小 batch 或提高 capacity_factor打開梯度裁剪推理吞吐比 Dense 還慢batch 太小通信占比高或 attention 成了瓶頸增大 batch嘗試部分層 MoE減少專家數(shù)量微調后模型能力明顯下降全量微調導致路由分布突變破壞預訓練知識凍結非專家層只調 router、共享專家或少量低秩參數(shù)顯存 OOM把稀疏激活誤解為顯存節(jié)省優(yōu)化器狀態(tài)分片、開啟激活重計算必要時量化專家權重或減少專家數(shù)路由坍縮是最常見也是最隱蔽的問題。修它的第一步不是調模型而是先確認數(shù)據(jù)有沒有偏差比如某類 token 占比過高。第二步是看 aux loss 是不是被主 loss 淹沒了打開日志確認它是否在正常下降。第三步再調大系數(shù)。我自己的經驗是先小幅調大到 0.02 觀察 200 步如果專家利用率還是極端再繼續(xù)調一次跳太多容易把模型精度打崩。微調 MoE 導致“變笨”這件事也值得單獨講。MoE 的預訓練知識分布在專家權重里Router 的分配模式其實是這些知識的重要索引。如果全量微調時所有參數(shù)都放開路由分布很容易被新任務帶偏導致新數(shù)據(jù)進來時模型調用了一組錯誤專家。比較好的做法是在微調階段凍結非專家層只讓 router、共享專家和小部分低秩適配參數(shù)可學習。這樣新任務能調整路由偏好但不會把底層語言能力破壞掉。6. 選型思考與經驗總結什么時候才該上 MoE6.1 適合與不適合 MoE 的場景場景是否推薦原因通用多語言大模型推薦覆蓋面廣、知識容量需求大專家領域分工收益明顯代碼、數(shù)學等分科知識推薦不同語言、不同題型天然形成子任務路由容易學到有意義分工低延遲單請求在線服務不推薦通信和全量加載內存會吃掉稀疏計算的收益單卡邊緣設備部署不推薦無法容納總參稀疏激活不能減內存預算有限但想擴大參數(shù)容量推薦激活參數(shù)可控訓練成本比同等 Dense 低已訓練 Dense 模型做特定任務微調謹慎建議凍結大部分參數(shù)只微調路由和共享專家這里多說一句MoE 并不適合所有任務。如果領域數(shù)據(jù)量小、任務非常單一那路由能學到的分工空間很有限加一堆專家只會增加訓練成本和過擬合風險。更直白地說MoE 的價值前提是“數(shù)據(jù)的多樣性足夠高”。數(shù)據(jù)不夠多樣時MoE 和 Dense 效果差距不大但工程復雜度明顯更高。6.2 從零開始做 MoE 實驗的建議路徑如果你沒有跑過 MoE我建議按這條路徑走而不是直接拿一個超大模型開練先有一個小規(guī)模 Transformer 基座能正常跑通語言建模任務。挑其中幾層 FFN 替換成 MoE 層。初始配置用 num_experts8top_k2capacity_factor1.25aux_loss_coef0.01。訓練過程中持續(xù)記錄專家利用率、丟棄率和路由熵。拿同一份數(shù)據(jù)和同樣的訓練步數(shù)跟 Dense 基線做對比。你可能看到 MoE 前幾百步 loss 稍差這是路由器在探索正常如果 loss 始終追不平去查負載均衡配置。路由健康之后再逐步加專家數(shù)量、加細粒度拆分、再加共享專家。一個比較省心的初始配置可以長這樣num_experts: 8 top_k: 2 expert_intermediate_size: 1024 capacity_factor: 1.25 aux_loss_coef: 0.01 router_noise_scale: 0.01這套配置在中小規(guī)模模型上一般不會出大問題之后再根據(jù)監(jiān)控指標微調。6.3 一點真實體會我一開始做 MoE 實驗時有一個誤區(qū)以為 MoE 是一種“更聰明的神經網絡層”只要把 FFN 換成專家池效果就會自動變好。實際跑了幾輪才發(fā)現(xiàn)MoE 更像一個分布式系統(tǒng)問題——你把模型切成很多專家真正要管理的是如何讓每個專家都有活干如何讓通信不拖后腿如何讓梯度不因稀疏而劇烈抖動。路由、容量、負載均衡這三件事每調一個都會牽動另外兩個。如果你準備接觸 MoE我的建議是別急著堆參數(shù)先用小模型把這三個指標調明白再遷移到大模型上會順暢很多。