從Transformer誕生起前饋網(wǎng)絡(luò)FFN就是又笨重又繞不開的角色它占了模型近三分之二的參數(shù)量但每個token都得老老實實把所有參數(shù)過一遍。你擴大模型容量推理成本就跟著線性往上漲這讓很多想做大規(guī)模模型的人非常頭疼。MoE混合專家模型或者說稀疏前饋網(wǎng)絡(luò)正是沖著這個矛盾來的——它把單個FFN拆成一組并行專家再加一道輕量門控路由讓每個token只激活其中一小部分專家。參數(shù)總量可以擴展數(shù)倍到數(shù)十倍但單token的計算量基本維持原樣容量和成本終于被解耦了。這篇文章我會從設(shè)計動機一路講到訓(xùn)練和推理階段的工程坑包括門控網(wǎng)絡(luò)怎么工作、負載均衡為什么難搞、專家并行怎么通信以及一批可以直接上手的調(diào)參經(jīng)驗。不管你是想改造自己的Transformer還是想理解最近一系列MoE大模型的結(jié)構(gòu)這篇都值得認真看完。1. 從 FFN 到 MoE改寫前饋網(wǎng)絡(luò)的真實動機1.1 一個容易被忽視的事實Transformer 的容量主要藏在 FFN 里很多人一提到Transformer下意識關(guān)注的是自注意力Self-Attention——tokens之間的交互全靠它。這話沒錯但你要是統(tǒng)計一下參數(shù)量注意力層其實只占很小一部分。一個標準Transformer Block里FFN通常包含兩個線性變換先把隱藏維度比如4096升到中間維度比如11008再降回來。這兩個矩陣相加參數(shù)量輕輕松松占總模型的2/3甚至更多。為什么設(shè)計成這個樣子因為FFN負責(zé)的是逐位置的記憶與抽象每個token獨立經(jīng)過同樣的非線性變換把注意力層已經(jīng)匯集的上下文信息進一步加工成更高層的特征。可以這樣理解注意力層負責(zé)商量FFN負責(zé)各自做事。商量只需要一個桌子做事卻需要大量工具工具多了參數(shù)量自然就上去了。問題在于推理時即使工具再多每個token也得把這些工具全部用一遍。參數(shù)量翻倍單個前向的計算量就翻倍延遲也跟著上來。于是你面臨一個非此即彼的選擇要么保持計算量不變放棄擴展容量要么接受昂貴的推理成本。這個矛盾在模型規(guī)模做大之后尤其尖銳我當時在一個文本模型項目里試著把FFN中間維度從4倍擴到8倍效果確實有提升但顯存和推理延遲的代價直接讓我放棄了。1.2 稀疏激活的直覺讓參數(shù)多、計算少變成現(xiàn)實MoE的思路一句話就能講清楚既然每個token用不上所有工具那就把FFN拆成若干個可以獨立工作的專家然后裝一個分診臺門控網(wǎng)絡(luò)讓每個token只去它需要的幾個專家那里其余專家本輪直接跳過。這就是稀疏激活的含義。傳統(tǒng)FFN是稠密計算——所有參數(shù)對所有輸入都參與計算MoE則是稀疏的——參數(shù)總量很大但單個token實際觸發(fā)的參數(shù)很少。用專業(yè)一點的術(shù)語描述假設(shè)總共有E個專家每個token從路由分布里挑出K個專家K遠小于E通常K取1或2那么這token的FFN計算量大約是原來單個FFN的K/E而不是E倍。直覺上可以類比全科醫(yī)生和?？崎T診的區(qū)別。普通FFN像一個能力全面的全科醫(yī)生每個病人都由他一個人看診所請不動更多醫(yī)生病人再多也是他一個人忙。MoE則是一個開了很多?？圃\室的醫(yī)院每個專家只擅長某一類病分診臺根據(jù)病人癥狀快速分配科室每個病人只看一兩個專家其他科室完全不打擾。醫(yī)院規(guī)模可以很大但單個病人的看病時間并沒有增加多少。模型容量來自有很多?？漆t(yī)生計算效率來自每個病人只看很少的醫(yī)生。1.3 為什么改造的是 FFN而不是注意力層這里有個值得深思的問題為什么大家做MoE都動FFN而不直接把注意力層也拆成混合專家原因在于兩種結(jié)構(gòu)的Nature完全不同。注意力層在每層同時處理所有token通過Q、K、V矩陣建立跨token的交互每個token的結(jié)果都與其他token相關(guān)FFN則對每個token獨立操作token之間沒有任何信息交換。正因為FFN的逐token獨立性我們才可以放心地把不同token送到不同專家專家之間不通信各自處理完再把結(jié)果放回原來的位置。如果對注意力層做路由比如讓每個token只和一部分token交互那被誰注意到會因為不同token選了不同專家而變得極度碎片化上下文信息容易出現(xiàn)斷裂訓(xùn)練難度也會直線上升。這不是說注意力MoE完全不可行而是在標準Transformer架構(gòu)里FFN是成本收益最劃算的改造點改動局部、邏輯清晰、收益最大。還有一點很實際FFN的權(quán)重是逐token獨立存儲的天然適合做參數(shù)并行——把不同專家放到不同GPU上互不干擾。注意力層則必須做完整的矩陣乘法和跨卡同步通信開銷大得多。所以從工程角度FFN也遠比注意力層更適合做稀疏化改造。2. 稀疏路由的完整工作鏈路門控網(wǎng)絡(luò)、Top-K 選擇與專家容量2.1 門控網(wǎng)絡(luò)token 怎么決定自己去哪個專家門控網(wǎng)絡(luò)Router也叫Gating Network是整個MoE最核心的組件。別看它決定著一大群專家的調(diào)用方式它本身的結(jié)構(gòu)卻非常簡單通常就是一個線性層輸入是token的隱藏表示h輸出維度等于專家總數(shù)E。然后過一個Softmax得到該token對各專家的選擇概率分布。用公式表示就是router_logits W_r hrouter_probs softmax(router_logits)這里的W_r是一個非常小的矩陣假設(shè)隱藏維度是4096專家數(shù)是8那W_r的參數(shù)量只有4096 × 8占整個模型的比重可以忽略不計。所以門控網(wǎng)絡(luò)被稱為輕量——它算得快、參數(shù)少卻直接影響模型的容量利用率。一個關(guān)鍵的設(shè)計細節(jié)是Router的輸入到底用哪一層表示。如果是用當前層的FFN輸入那路由決策反映的是這一層之前的特征如果是用上一層的輸出或者與attention輸出拼接后的向量則可能包含更多上下文。不同實現(xiàn)各有取舍我個人的粗淺經(jīng)驗是在層數(shù)較深的地方用本層的輸入就夠如果訓(xùn)練不穩(wěn)定可以嘗試把上一層Router的logits也拼接喂進來給當前層更多先驗。2.2 Top-K 選擇與專家容量從分診到預(yù)約掛號拿到全量專家概率后不能真的所有專家都參與計算那樣又退回稠密了。做法是取概率最高的K個專家K通常取1或2。取到具體哪K個專家后對應(yīng)專家計算得到輸出再按路由概率或歸一化后的權(quán)重加權(quán)求和得到當前token的FFN輸出。當K1時每個token只走一個專家計算效率最高但每個token的感受域非常受限專家之間也完全沒有冗余協(xié)作。K2是當前很多工作的經(jīng)驗?zāi)J值既保證了稀疏性又給了token一點選擇的余地。我感覺K2相當于讓分診臺不僅選最合適的科室還允許備選科室兜底對訓(xùn)練初期路由還不成熟時特別友好。接下來是專家容量Expert Capacity的問題。一個專家在某一層最多能處理多少個token如果不設(shè)上限某幾個熱門專家可能被分配大量token其他專家空轉(zhuǎn)計算負載嚴重不均。于是實現(xiàn)時會為每個專家設(shè)置一個容量上限capacity capacity_factor * (T / E)。這個公式的含義是理論平均分配下每個專家應(yīng)該處理T/E個tokencapacity_factor則允許一定的彈性冗余。舉個例子假設(shè)T256個tokenE8個專家理論平均是每個專家32個tokencapacity_factor取1.25則容量為40。一旦某個專家被分配的token數(shù)超過了容量超出的token就只能被丟棄或者走一條殘差連接直接跳過FFN的通路。很多人第一次看到丟棄token會嚇一跳訓(xùn)練時丟信息模型還能學(xué)好嗎實際上這是工程上的妥協(xié)——如果強行保留所有token計算圖和同步邏輯會變得非常復(fù)雜還會導(dǎo)致不同專家之間的執(zhí)行時間出現(xiàn)長尾。后續(xù)有人提出無丟棄drop-free的負載均衡方法核心是調(diào)整路由分配而不是限制容量效果也確實更好。但從工程復(fù)雜度考慮帶容量的實現(xiàn)依然是目前最穩(wěn)妥的基線方案。2.3 一個完整的 token 走向示例為了把上面這些概念串起來我走一遍一個token在MoE層的完整流程token輸入為形狀[B, H]的向量先復(fù)制一份作為殘差為后續(xù)相加做準備。門控網(wǎng)絡(luò)根據(jù)當前token的表示算出每個專家的概率得到形狀[E]的分布。挑選概率最高的K2個專家記為專家3和專家7。token被送往專家3和專家7所在的設(shè)備如果是單卡就是同一設(shè)備上的不同矩陣。專家3和專家7分別對token做自己的FFN前向計算得到兩個輸出。兩個輸出按路由權(quán)重加權(quán)求和。加權(quán)結(jié)果與第一步的殘差相加得到當前層的輸出。這個流程里其他6個專家完全沒有參與計算對應(yīng)的參數(shù)也處于空閑狀態(tài)。這就是稀疏兩個字的真正含義——不是少設(shè)計了參數(shù)是每次只用到其中一小撮。3. 負載均衡與路由離散性訓(xùn)練階段最頭疼的兩個工程問題3.1 離散路由不可微梯度怎么回到 RouterMoE聽著完美但訓(xùn)練時第一個坑就擺在面前Top-K取的是索引是一個離散操作不可導(dǎo)。你沒法把我選了專家3這個行為直接變成梯度信號來更新門控網(wǎng)絡(luò)。怎么辦經(jīng)典解法是雖然選擇是離散的但最終輸出是對所選專家的輸出按概率加權(quán)求和而概率本身是router logits經(jīng)softmax得到的是連續(xù)可導(dǎo)的。于是梯度可以沿著概率權(quán)重這條路回傳到路由網(wǎng)絡(luò)。換句話說真正參與加權(quán)求和的權(quán)重是router_probs里選中那個位置的值而不是一個one-hot向量即使如此這仍然會產(chǎn)生一個什么問題呢問題在于概率權(quán)重在反向傳播時數(shù)值通常比較小門控網(wǎng)絡(luò)拿到的梯度信號偏弱。你可以理解為后端專家們學(xué)得很快但分診臺學(xué)得有點滯后。這帶來一系列連鎖問題后面會詳細講。還有一個細節(jié)容易被忽略訓(xùn)練時如果想用hard gradient估計算法類似Gumbel-Softmax的Straight-Through情況會稍有不同——forward時用one-hotbackward時用連續(xù)概率的近似梯度。但標準實現(xiàn)里大多數(shù)框架仍然采用加權(quán)求和式的軟路由簡單且穩(wěn)定。我之前在某次實驗里試過hard路由收斂速度明顯變慢后來果斷退回soft加權(quán)。3.2 負載坍縮少數(shù)專家過熱、多數(shù)專家空轉(zhuǎn)MoE最著名的訓(xùn)練困境就是負載坍縮load collapse。開始訓(xùn)練時Router的參數(shù)幾乎隨機各專家的分配還算均勻。但很快某些專家因為初始化稍好、梯度更新方向略微有利就會被分配更多的token形成正反饋熱門專家學(xué)得更快、表現(xiàn)更好Router越來越傾向于選它其他專家則長期閑置梯度信號近乎為零逐漸變成死專家。最終整個模型退化成其實只用了兩三個專家參數(shù)總量虛增容量優(yōu)勢形同虛設(shè)。解決負載坍縮的主要手段是加輔助負載均衡損失Auxiliary Load Balancing Loss讓Router在每個batch里盡量把token均勻分配給專家。經(jīng)典的實現(xiàn)大概長這樣aux_loss E * sum(prob_per_expert * fraction_of_tokens_per_expert)其中prob_per_expert是所有token對本專家的平均選擇概率fraction_of_tokens_per_expert是實際被分配到本專家的token占比。二者相乘再求和如果分配完全均勻這個值會趨近于1越不均勻值越大相當于對Router施加一個均勻化的懲罰。E作為縮放因子使得損失數(shù)值與專家數(shù)無關(guān)方便統(tǒng)一調(diào)系數(shù)。但這又引入新矛盾輔助損失權(quán)重設(shè)太大模型會傾向于為了均勻而均勻犧牲真正的專業(yè)分化整體表現(xiàn)下降設(shè)太小負載坍縮壓不住。我在實際調(diào)參時觀察到的情況是由于每個batch的分布都在變固定權(quán)重很難同時照顧訓(xùn)練前期和后期的需求。比較務(wù)實的方法是訓(xùn)練前幾百步用小權(quán)重等專家分化初步形成后再逐漸加大或者觀察負載的variance指標——如果某專家占比長期超過2倍平均值就臨時加大權(quán)重拉一把。3.3 初始化與 Router 輸入尺度的穩(wěn)定性除了負載均衡Router訓(xùn)練的另一個隱性障礙是logits的數(shù)值波動。如果Router的輸出一直非常大softmax出來的分布就會非常尖銳幾乎等于固定選Top-1專家別的專家?guī)缀鯖]有機會。反過來如果logits太小分布太平滑Top-K的選中結(jié)果和未選中結(jié)果差異不大路由失去了區(qū)分能力。一個常用技巧是給Router加一個可學(xué)習(xí)的temperature項初始值設(shè)小一點讓logits先溫和一些。入口處做LayerNorm也是常見做法把不同token的表示尺度拉到同一水平避免某些高范數(shù)token支配Router的決策。我還用過一種更樸素的方法直接從已有Dense模型做熱啟動warm start。比如把稠密FFN拆成E個專家時克隆同一份參數(shù)作為每個專家的初始化這樣所有專家在訓(xùn)練初期能力一致Router沒有偏心的理由。這在多任務(wù)遷移場景下特別有效畢竟從零訓(xùn)練一個大規(guī)模MoE冷啟動穩(wěn)定性的難度是很多人低估的。4. 訓(xùn)練態(tài)與推理態(tài)的差異顯存預(yù)分配、專家并行與通信開銷4.1 訓(xùn)練時怎么擺放專家專家并行與 All-to-All 通信討論完訓(xùn)練穩(wěn)定性還得解決一個現(xiàn)實問題MoE參數(shù)總量大一張卡根本放不下。傳統(tǒng)模型并行是切分每一層的矩陣MoE則有天然更優(yōu)的方案——專家并行Expert Parallelism把不同專家分布在不同GPU上每張卡只保存一部分專家的權(quán)重Router所在位置則根據(jù)token的分布動態(tài)將token散播到對應(yīng)專家所在的卡。這里有兩個關(guān)鍵通信階段。第一個階段叫Dispatch某個token被路由到專家3而專家3在另一張卡上就必須把token的隱藏向量通過通信送到那張卡。第二個階段叫Combine專家3算完輸出后結(jié)果還要送回原來的卡供后續(xù)的殘差相加和下一層使用。如果K2token實際上要做兩次dispatch/combine通信量也隨之倍增。這兩個通信階段使用的通常是All-to-All模式也就是每個節(jié)點都要向其他所有節(jié)點發(fā)送數(shù)據(jù)。這和傳統(tǒng)All-Reduce所有節(jié)點只匯總一個結(jié)果完全不同。通信量大約正比于被路由的token數(shù)、隱藏維度和專家跨卡跳數(shù)。所以一個非常重要的工程教訓(xùn)是MoE的稀疏收益到一定規(guī)模后可能被通信開銷吃掉。如果網(wǎng)絡(luò)帶寬不夠你會發(fā)現(xiàn)訓(xùn)練速度不升反降加專家還不如加計算密度來得劃算。我實際測試過一個典型配置8卡環(huán)境、每層8個專家、K2。在單機NVLink互聯(lián)下通信損耗還能接受但一旦跨機走以太網(wǎng)訓(xùn)練step時間立刻漲了30%收益大打折扣。所以設(shè)計MoE規(guī)模時一定要先盤清楚自己的通信拓撲。4.2 推理態(tài)顯存的真正瓶頸參數(shù)常駐而不是計算量很多人第一次接觸MoE推理時都會有個錯覺既然每個token只激活一小部分專家那顯存占用是不是也按比例減小不是。稀疏只減少了計算量FLOPs參數(shù)依然全部常駐顯存。無非是一個token實際只用到了門控網(wǎng)絡(luò)和少數(shù)專家的權(quán)重但所有專家的參數(shù)都必須在內(nèi)存里待命因為你不知道下一個token會訪問哪個專家。這在推理側(cè)會造成一個非常有趣的局面MoE模型的推理延遲可以接近同計算量的Dense模型但顯存占用接近同參數(shù)量的Dense模型。換句話說你省的是算力省不了容量。正因如此大規(guī)模MoE推理基本都是多卡分布式方案每張卡放一部分專家。當請求到來時token先經(jīng)過路由再通過通信調(diào)用其他卡的專家。這實際上把訓(xùn)練時的專家并行復(fù)用了只是batch更小、通信更多在卡間進行。顯存優(yōu)化通常還有兩個方向一是對專家權(quán)重做更激進的低比特量化因為專家本身是逐token獨立使用的量化誤差不容易像attention參數(shù)那樣跨token擴散二是預(yù)先把所有專家的參數(shù)做統(tǒng)一內(nèi)存池管理配合顯存碎片整理。后一種技巧偏工程化但收益很直觀尤其在長期多請求服務(wù)的場景里。4.3 padding token 帶來的路由損耗一個容易踩的隱藏成本訓(xùn)練時為了batch對齊我們會給短句做padding。在普通Transformer里padding位置雖然參與計算但因為注意力mask的存在它們對有效位置的影響基本可以被忽略于是人們很少專門去處理padding token的成本。但在MoE里情況變了每個padding token也要走Router、也要被dispatch到某個專家、也要占用專家容量。這帶來兩個直接后果。第一padding token占用專家容量可能導(dǎo)致有效token被擠掉超過capacity被丟棄。第二即使padding token沒有實際信息它們依然占據(jù)通信通道白白消耗All-to-All帶寬。好在我們找到的解決辦法并不復(fù)雜在padding位置的路由概率上直接加一個非常大的負偏置讓Router幾乎不可能選中任何專家或者把padding token在進入MoE層之前直接從batch里摘除等所有專家計算完再放回原位。前者改動小后者更徹底但需要處理動態(tài)batch工程復(fù)雜度會增加一些。類似的浪費也出現(xiàn)在推理場景現(xiàn)在主流的推理框架普遍采用連續(xù)批處理continuous batching不同請求的長度不對齊時也會出現(xiàn)大量虛位token。所以做MoE推理服務(wù)時請求調(diào)度策略對性能的影響往往比模型結(jié)構(gòu)本身還大。5. 實測調(diào)參清單與擴展思路從復(fù)現(xiàn)一個簡單 MoE 層開始5.1 一個可直接改寫的 MoE 層偽代碼結(jié)構(gòu)看完前面的原理你已經(jīng)可以把一個標準的MoE層搭出來了。下面用離實現(xiàn)很接近的偽代碼展示核心邏輯框架無關(guān)方便你對照著改寫自己的代碼。def moe_ffn(x, experts, router, K2, capacity_factor1.25): # x: [batch, hidden] B x.shape[0] E len(experts) T B # 這里假設(shè)每個token獨立路由實際實現(xiàn)會考慮padding mask # 1. 計算路由概率 logits router(x) # [B, E] probs softmax(logits, dim-1) # [B, E] # 2. 取Top-K專家 top_probs, top_idx probs.topk(K, dim-1) # 各[B, K] top_probs top_probs / top_probs.sum(dim-1, keepdimTrue) # 歸一化 # 3. 按專家容量篩選 capacity int(capacity_factor * B / E) dispatch_mask build_dispatch_mask(top_idx, E, capacity) # [B, E, K] 或管理token分配 # 4. 對每個選中的專家執(zhí)行 FFN并按權(quán)重聚合 output zeros_like(x) for e in range(E): selected dispatch_mask[:, e] # 哪些token被分到專家e if selected.any(): expert_out experts[e](x[selected]) # [num_selected, hidden] output[selected] (top_probs[selected, e] * expert_out) # 5. 殘差連接 return output residual_x當然真實工程里不會用for循環(huán)逐專家算而是通過矩陣乘法一次性完成所有專家的前向但核心邏輯就是上面的流程。為了效率專家計算通常會合并成一個大的張量運算把專家參數(shù)沿著一個軸堆疊起來然后用grouped GEMM一次算出所有選中專家的輸出。這也是很多訓(xùn)練框架在MoE部分做的主要優(yōu)化。5.2 調(diào)參順序先穩(wěn)定路由再追容量調(diào)MoE和調(diào)普通模型一個很大的區(qū)別是超參數(shù)之間存在明顯的先后依賴關(guān)系。一上來就亂試專家數(shù)、路由權(quán)重很容易出現(xiàn)忘記調(diào)了什么的局面因為每個超參數(shù)都會間接影響Router的負載分布。我建議按下面的順序做超參數(shù)常用范圍影響效果調(diào)整優(yōu)先級專家數(shù) E8~64視參數(shù)量預(yù)算決定容量上限和并行度先定預(yù)算再選Top-K1~2計算量、冗余度、通信量建議固定為2capacity_factor1.0~1.5丟棄率、負載余量、性能優(yōu)先調(diào)aux loss 系數(shù)0.001~0.1負載均衡強度次優(yōu)先Router溫度0.5~1.0可學(xué)習(xí)路由分布尖銳度小步微調(diào)專家Dropout0.0~0.1緩解過擬合、增強魯棒性最后調(diào)具體來說先固定E和K把capacity_factor從1.25開始試觀察訓(xùn)練時被丟棄token的比例。如果丟棄太多說明Router的選擇太集中或容量太小可以適當調(diào)大capacity_factor如果幾乎為零則逐步減小壓出更多計算密度。然后才去調(diào)整aux loss系數(shù)從0.01起步每幾百步看一眼各專家的token占比分布。占比的方差如果持續(xù)縮小到接近均勻說明權(quán)重偏大可以降如果某個專家占比持續(xù)超過2倍平均則要加大權(quán)重。一個反直覺的經(jīng)驗是對于中小規(guī)模的模型參數(shù)量在億級以下MoE的優(yōu)勢并不明顯。Router自身也需要數(shù)據(jù)爬坡假設(shè)總數(shù)據(jù)量沒法讓每個專家都充分訓(xùn)練那稀疏結(jié)構(gòu)的收益就會打折扣。所以不要只盯著MoE大模型專利這個說法也要理解它依賴的規(guī)模前提。5.3 什么時候不應(yīng)該用 MoE以及幾個值得關(guān)注的擴展方向MoE不是銀彈。如果你的使用場景是單機單卡、推理延遲極敏感、或者模型規(guī)模本來就很小那么MoE帶來的通信開銷和顯存負擔(dān)通常不值得。尤其是邊緣端或者移動端場景參數(shù)量常駐和動態(tài)路由的不確定性會讓部署變得非常不友好。寧可把精力花在蒸餾、量化或者知識蒸餾這類壓縮手段上。反過來MoE真正發(fā)光的地方是訓(xùn)練語料極其豐富而單卡顯存成為瓶頸、需要在不顯著增加推理計算量的前提下擴展容量、以及多種異構(gòu)任務(wù)希望共用一套底座但各任務(wù)又有自己的特性。多模態(tài)方向也可以大膽嘗試——不同模態(tài)的信息處理模式差異大正好適合交由不同專家專人負責(zé)門控網(wǎng)絡(luò)學(xué)到的模態(tài)路由有時會帶來意想不到的可解釋性。我在一次改造中把MoE從語言模型搬到了推薦系統(tǒng)的打分模型里不同用戶群體走不同專家冷啟動階段用戶走Generalist專家活躍用戶則能訪問專屬專家后的組合結(jié)果效果提升比純粹加深網(wǎng)絡(luò)更明顯。這說明MoE的分診思想完全值得跨場景復(fù)用關(guān)鍵還是找到那些不同樣本需要不同能力的問題。最后分享兩個小技巧。如果你已經(jīng)用上了MoE建議把Router的決策分布做成可視化日志每訓(xùn)練幾千步看一眼比任何損失曲線都能更快發(fā)現(xiàn)問題另一個是在測試階段記錄專家熱力分布如果模型收斂后大部分token的Top-1專家高度集中往往說明模型只學(xué)到了表面規(guī)律需要回頭檢查訓(xùn)練數(shù)據(jù)本身的多樣性。MoE這條路技術(shù)在往前走但工程的坑說到底還是那幾類通信、負載、穩(wěn)定性。理解了底層邏輯剩下的就是耐心調(diào)參和踩坑。希望這些經(jīng)驗?zāi)軒湍闵僮邘撞綇澛贰? MoE混合專家模型：稀疏激活如何破解大模型容量與成本困局
從Transformer誕生起前饋網(wǎng)絡(luò)FFN就是又笨重又繞不開的角色它占了模型近三分之二的參數(shù)量但每個token都得老老實實把所有參數(shù)過一遍。你擴大模型容量推理成本就跟著線性往上漲這讓很多想做大規(guī)模模型的人非常頭疼。MoE混合專家模型或者說稀疏前饋網(wǎng)絡(luò)正是沖著這個矛盾來的——它把單個FFN拆成一組并行專家再加一道輕量門控路由讓每個token只激活其中一小部分專家。參數(shù)總量可以擴展數(shù)倍到數(shù)十倍但單token的計算量基本維持原樣容量和成本終于被解耦了。這篇文章我會從設(shè)計動機一路講到訓(xùn)練和推理階段的工程坑包括門控網(wǎng)絡(luò)怎么工作、負載均衡為什么難搞、專家并行怎么通信以及一批可以直接上手的調(diào)參經(jīng)驗。不管你是想改造自己的Transformer還是想理解最近一系列MoE大模型的結(jié)構(gòu)這篇都值得認真看完。1. 從 FFN 到 MoE改寫前饋網(wǎng)絡(luò)的真實動機1.1 一個容易被忽視的事實Transformer 的容量主要藏在 FFN 里很多人一提到Transformer下意識關(guān)注的是自注意力Self-Attention——tokens之間的交互全靠它。這話沒錯但你要是統(tǒng)計一下參數(shù)量注意力層其實只占很小一部分。一個標準Transformer Block里FFN通常包含兩個線性變換先把隱藏維度比如4096升到中間維度比如11008再降回來。這兩個矩陣相加參數(shù)量輕輕松松占總模型的2/3甚至更多。為什么設(shè)計成這個樣子因為FFN負責(zé)的是逐位置的記憶與抽象每個token獨立經(jīng)過同樣的非線性變換把注意力層已經(jīng)匯集的上下文信息進一步加工成更高層的特征。可以這樣理解注意力層負責(zé)商量FFN負責(zé)各自做事。商量只需要一個桌子做事卻需要大量工具工具多了參數(shù)量自然就上去了。問題在于推理時即使工具再多每個token也得把這些工具全部用一遍。參數(shù)量翻倍單個前向的計算量就翻倍延遲也跟著上來。于是你面臨一個非此即彼的選擇要么保持計算量不變放棄擴展容量要么接受昂貴的推理成本。這個矛盾在模型規(guī)模做大之后尤其尖銳我當時在一個文本模型項目里試著把FFN中間維度從4倍擴到8倍效果確實有提升但顯存和推理延遲的代價直接讓我放棄了。1.2 稀疏激活的直覺讓參數(shù)多、計算少變成現(xiàn)實MoE的思路一句話就能講清楚既然每個token用不上所有工具那就把FFN拆成若干個可以獨立工作的專家然后裝一個分診臺門控網(wǎng)絡(luò)讓每個token只去它需要的幾個專家那里其余專家本輪直接跳過。這就是稀疏激活的含義。傳統(tǒng)FFN是稠密計算——所有參數(shù)對所有輸入都參與計算MoE則是稀疏的——參數(shù)總量很大但單個token實際觸發(fā)的參數(shù)很少。用專業(yè)一點的術(shù)語描述假設(shè)總共有E個專家每個token從路由分布里挑出K個專家K遠小于E通常K取1或2那么這token的FFN計算量大約是原來單個FFN的K/E而不是E倍。直覺上可以類比全科醫(yī)生和?？崎T診的區(qū)別。普通FFN像一個能力全面的全科醫(yī)生每個病人都由他一個人看診所請不動更多醫(yī)生病人再多也是他一個人忙。MoE則是一個開了很多?？圃\室的醫(yī)院每個專家只擅長某一類病分診臺根據(jù)病人癥狀快速分配科室每個病人只看一兩個專家其他科室完全不打擾。醫(yī)院規(guī)模可以很大但單個病人的看病時間并沒有增加多少。模型容量來自有很多?？漆t(yī)生計算效率來自每個病人只看很少的醫(yī)生。1.3 為什么改造的是 FFN而不是注意力層這里有個值得深思的問題為什么大家做MoE都動FFN而不直接把注意力層也拆成混合專家原因在于兩種結(jié)構(gòu)的Nature完全不同。注意力層在每層同時處理所有token通過Q、K、V矩陣建立跨token的交互每個token的結(jié)果都與其他token相關(guān)FFN則對每個token獨立操作token之間沒有任何信息交換。正因為FFN的逐token獨立性我們才可以放心地把不同token送到不同專家專家之間不通信各自處理完再把結(jié)果放回原來的位置。如果對注意力層做路由比如讓每個token只和一部分token交互那被誰注意到會因為不同token選了不同專家而變得極度碎片化上下文信息容易出現(xiàn)斷裂訓(xùn)練難度也會直線上升。這不是說注意力MoE完全不可行而是在標準Transformer架構(gòu)里FFN是成本收益最劃算的改造點改動局部、邏輯清晰、收益最大。還有一點很實際FFN的權(quán)重是逐token獨立存儲的天然適合做參數(shù)并行——把不同專家放到不同GPU上互不干擾。注意力層則必須做完整的矩陣乘法和跨卡同步通信開銷大得多。所以從工程角度FFN也遠比注意力層更適合做稀疏化改造。2. 稀疏路由的完整工作鏈路門控網(wǎng)絡(luò)、Top-K 選擇與專家容量2.1 門控網(wǎng)絡(luò)token 怎么決定自己去哪個專家門控網(wǎng)絡(luò)Router也叫Gating Network是整個MoE最核心的組件。別看它決定著一大群專家的調(diào)用方式它本身的結(jié)構(gòu)卻非常簡單通常就是一個線性層輸入是token的隱藏表示h輸出維度等于專家總數(shù)E。然后過一個Softmax得到該token對各專家的選擇概率分布。用公式表示就是router_logits W_r hrouter_probs softmax(router_logits)這里的W_r是一個非常小的矩陣假設(shè)隱藏維度是4096專家數(shù)是8那W_r的參數(shù)量只有4096 × 8占整個模型的比重可以忽略不計。所以門控網(wǎng)絡(luò)被稱為輕量——它算得快、參數(shù)少卻直接影響模型的容量利用率。一個關(guān)鍵的設(shè)計細節(jié)是Router的輸入到底用哪一層表示。如果是用當前層的FFN輸入那路由決策反映的是這一層之前的特征如果是用上一層的輸出或者與attention輸出拼接后的向量則可能包含更多上下文。不同實現(xiàn)各有取舍我個人的粗淺經(jīng)驗是在層數(shù)較深的地方用本層的輸入就夠如果訓(xùn)練不穩(wěn)定可以嘗試把上一層Router的logits也拼接喂進來給當前層更多先驗。2.2 Top-K 選擇與專家容量從分診到預(yù)約掛號拿到全量專家概率后不能真的所有專家都參與計算那樣又退回稠密了。做法是取概率最高的K個專家K通常取1或2。取到具體哪K個專家后對應(yīng)專家計算得到輸出再按路由概率或歸一化后的權(quán)重加權(quán)求和得到當前token的FFN輸出。當K1時每個token只走一個專家計算效率最高但每個token的感受域非常受限專家之間也完全沒有冗余協(xié)作。K2是當前很多工作的經(jīng)驗?zāi)J值既保證了稀疏性又給了token一點選擇的余地。我感覺K2相當于讓分診臺不僅選最合適的科室還允許備選科室兜底對訓(xùn)練初期路由還不成熟時特別友好。接下來是專家容量Expert Capacity的問題。一個專家在某一層最多能處理多少個token如果不設(shè)上限某幾個熱門專家可能被分配大量token其他專家空轉(zhuǎn)計算負載嚴重不均。于是實現(xiàn)時會為每個專家設(shè)置一個容量上限capacity capacity_factor * (T / E)。這個公式的含義是理論平均分配下每個專家應(yīng)該處理T/E個tokencapacity_factor則允許一定的彈性冗余。舉個例子假設(shè)T256個tokenE8個專家理論平均是每個專家32個tokencapacity_factor取1.25則容量為40。一旦某個專家被分配的token數(shù)超過了容量超出的token就只能被丟棄或者走一條殘差連接直接跳過FFN的通路。很多人第一次看到丟棄token會嚇一跳訓(xùn)練時丟信息模型還能學(xué)好嗎實際上這是工程上的妥協(xié)——如果強行保留所有token計算圖和同步邏輯會變得非常復(fù)雜還會導(dǎo)致不同專家之間的執(zhí)行時間出現(xiàn)長尾。后續(xù)有人提出無丟棄drop-free的負載均衡方法核心是調(diào)整路由分配而不是限制容量效果也確實更好。但從工程復(fù)雜度考慮帶容量的實現(xiàn)依然是目前最穩(wěn)妥的基線方案。2.3 一個完整的 token 走向示例為了把上面這些概念串起來我走一遍一個token在MoE層的完整流程token輸入為形狀[B, H]的向量先復(fù)制一份作為殘差為后續(xù)相加做準備。門控網(wǎng)絡(luò)根據(jù)當前token的表示算出每個專家的概率得到形狀[E]的分布。挑選概率最高的K2個專家記為專家3和專家7。token被送往專家3和專家7所在的設(shè)備如果是單卡就是同一設(shè)備上的不同矩陣。專家3和專家7分別對token做自己的FFN前向計算得到兩個輸出。兩個輸出按路由權(quán)重加權(quán)求和。加權(quán)結(jié)果與第一步的殘差相加得到當前層的輸出。這個流程里其他6個專家完全沒有參與計算對應(yīng)的參數(shù)也處于空閑狀態(tài)。這就是稀疏兩個字的真正含義——不是少設(shè)計了參數(shù)是每次只用到其中一小撮。3. 負載均衡與路由離散性訓(xùn)練階段最頭疼的兩個工程問題3.1 離散路由不可微梯度怎么回到 RouterMoE聽著完美但訓(xùn)練時第一個坑就擺在面前Top-K取的是索引是一個離散操作不可導(dǎo)。你沒法把我選了專家3這個行為直接變成梯度信號來更新門控網(wǎng)絡(luò)。怎么辦經(jīng)典解法是雖然選擇是離散的但最終輸出是對所選專家的輸出按概率加權(quán)求和而概率本身是router logits經(jīng)softmax得到的是連續(xù)可導(dǎo)的。于是梯度可以沿著概率權(quán)重這條路回傳到路由網(wǎng)絡(luò)。換句話說真正參與加權(quán)求和的權(quán)重是router_probs里選中那個位置的值而不是一個one-hot向量即使如此這仍然會產(chǎn)生一個什么問題呢問題在于概率權(quán)重在反向傳播時數(shù)值通常比較小門控網(wǎng)絡(luò)拿到的梯度信號偏弱。你可以理解為后端專家們學(xué)得很快但分診臺學(xué)得有點滯后。這帶來一系列連鎖問題后面會詳細講。還有一個細節(jié)容易被忽略訓(xùn)練時如果想用hard gradient估計算法類似Gumbel-Softmax的Straight-Through情況會稍有不同——forward時用one-hotbackward時用連續(xù)概率的近似梯度。但標準實現(xiàn)里大多數(shù)框架仍然采用加權(quán)求和式的軟路由簡單且穩(wěn)定。我之前在某次實驗里試過hard路由收斂速度明顯變慢后來果斷退回soft加權(quán)。3.2 負載坍縮少數(shù)專家過熱、多數(shù)專家空轉(zhuǎn)MoE最著名的訓(xùn)練困境就是負載坍縮load collapse。開始訓(xùn)練時Router的參數(shù)幾乎隨機各專家的分配還算均勻。但很快某些專家因為初始化稍好、梯度更新方向略微有利就會被分配更多的token形成正反饋熱門專家學(xué)得更快、表現(xiàn)更好Router越來越傾向于選它其他專家則長期閑置梯度信號近乎為零逐漸變成死專家。最終整個模型退化成其實只用了兩三個專家參數(shù)總量虛增容量優(yōu)勢形同虛設(shè)。解決負載坍縮的主要手段是加輔助負載均衡損失Auxiliary Load Balancing Loss讓Router在每個batch里盡量把token均勻分配給專家。經(jīng)典的實現(xiàn)大概長這樣aux_loss E * sum(prob_per_expert * fraction_of_tokens_per_expert)其中prob_per_expert是所有token對本專家的平均選擇概率fraction_of_tokens_per_expert是實際被分配到本專家的token占比。二者相乘再求和如果分配完全均勻這個值會趨近于1越不均勻值越大相當于對Router施加一個均勻化的懲罰。E作為縮放因子使得損失數(shù)值與專家數(shù)無關(guān)方便統(tǒng)一調(diào)系數(shù)。但這又引入新矛盾輔助損失權(quán)重設(shè)太大模型會傾向于為了均勻而均勻犧牲真正的專業(yè)分化整體表現(xiàn)下降設(shè)太小負載坍縮壓不住。我在實際調(diào)參時觀察到的情況是由于每個batch的分布都在變固定權(quán)重很難同時照顧訓(xùn)練前期和后期的需求。比較務(wù)實的方法是訓(xùn)練前幾百步用小權(quán)重等專家分化初步形成后再逐漸加大或者觀察負載的variance指標——如果某專家占比長期超過2倍平均值就臨時加大權(quán)重拉一把。3.3 初始化與 Router 輸入尺度的穩(wěn)定性除了負載均衡Router訓(xùn)練的另一個隱性障礙是logits的數(shù)值波動。如果Router的輸出一直非常大softmax出來的分布就會非常尖銳幾乎等于固定選Top-1專家別的專家?guī)缀鯖]有機會。反過來如果logits太小分布太平滑Top-K的選中結(jié)果和未選中結(jié)果差異不大路由失去了區(qū)分能力。一個常用技巧是給Router加一個可學(xué)習(xí)的temperature項初始值設(shè)小一點讓logits先溫和一些。入口處做LayerNorm也是常見做法把不同token的表示尺度拉到同一水平避免某些高范數(shù)token支配Router的決策。我還用過一種更樸素的方法直接從已有Dense模型做熱啟動warm start。比如把稠密FFN拆成E個專家時克隆同一份參數(shù)作為每個專家的初始化這樣所有專家在訓(xùn)練初期能力一致Router沒有偏心的理由。這在多任務(wù)遷移場景下特別有效畢竟從零訓(xùn)練一個大規(guī)模MoE冷啟動穩(wěn)定性的難度是很多人低估的。4. 訓(xùn)練態(tài)與推理態(tài)的差異顯存預(yù)分配、專家并行與通信開銷4.1 訓(xùn)練時怎么擺放專家專家并行與 All-to-All 通信討論完訓(xùn)練穩(wěn)定性還得解決一個現(xiàn)實問題MoE參數(shù)總量大一張卡根本放不下。傳統(tǒng)模型并行是切分每一層的矩陣MoE則有天然更優(yōu)的方案——專家并行Expert Parallelism把不同專家分布在不同GPU上每張卡只保存一部分專家的權(quán)重Router所在位置則根據(jù)token的分布動態(tài)將token散播到對應(yīng)專家所在的卡。這里有兩個關(guān)鍵通信階段。第一個階段叫Dispatch某個token被路由到專家3而專家3在另一張卡上就必須把token的隱藏向量通過通信送到那張卡。第二個階段叫Combine專家3算完輸出后結(jié)果還要送回原來的卡供后續(xù)的殘差相加和下一層使用。如果K2token實際上要做兩次dispatch/combine通信量也隨之倍增。這兩個通信階段使用的通常是All-to-All模式也就是每個節(jié)點都要向其他所有節(jié)點發(fā)送數(shù)據(jù)。這和傳統(tǒng)All-Reduce所有節(jié)點只匯總一個結(jié)果完全不同。通信量大約正比于被路由的token數(shù)、隱藏維度和專家跨卡跳數(shù)。所以一個非常重要的工程教訓(xùn)是MoE的稀疏收益到一定規(guī)模后可能被通信開銷吃掉。如果網(wǎng)絡(luò)帶寬不夠你會發(fā)現(xiàn)訓(xùn)練速度不升反降加專家還不如加計算密度來得劃算。我實際測試過一個典型配置8卡環(huán)境、每層8個專家、K2。在單機NVLink互聯(lián)下通信損耗還能接受但一旦跨機走以太網(wǎng)訓(xùn)練step時間立刻漲了30%收益大打折扣。所以設(shè)計MoE規(guī)模時一定要先盤清楚自己的通信拓撲。4.2 推理態(tài)顯存的真正瓶頸參數(shù)常駐而不是計算量很多人第一次接觸MoE推理時都會有個錯覺既然每個token只激活一小部分專家那顯存占用是不是也按比例減小不是。稀疏只減少了計算量FLOPs參數(shù)依然全部常駐顯存。無非是一個token實際只用到了門控網(wǎng)絡(luò)和少數(shù)專家的權(quán)重但所有專家的參數(shù)都必須在內(nèi)存里待命因為你不知道下一個token會訪問哪個專家。這在推理側(cè)會造成一個非常有趣的局面MoE模型的推理延遲可以接近同計算量的Dense模型但顯存占用接近同參數(shù)量的Dense模型。換句話說你省的是算力省不了容量。正因如此大規(guī)模MoE推理基本都是多卡分布式方案每張卡放一部分專家。當請求到來時token先經(jīng)過路由再通過通信調(diào)用其他卡的專家。這實際上把訓(xùn)練時的專家并行復(fù)用了只是batch更小、通信更多在卡間進行。顯存優(yōu)化通常還有兩個方向一是對專家權(quán)重做更激進的低比特量化因為專家本身是逐token獨立使用的量化誤差不容易像attention參數(shù)那樣跨token擴散二是預(yù)先把所有專家的參數(shù)做統(tǒng)一內(nèi)存池管理配合顯存碎片整理。后一種技巧偏工程化但收益很直觀尤其在長期多請求服務(wù)的場景里。4.3 padding token 帶來的路由損耗一個容易踩的隱藏成本訓(xùn)練時為了batch對齊我們會給短句做padding。在普通Transformer里padding位置雖然參與計算但因為注意力mask的存在它們對有效位置的影響基本可以被忽略于是人們很少專門去處理padding token的成本。但在MoE里情況變了每個padding token也要走Router、也要被dispatch到某個專家、也要占用專家容量。這帶來兩個直接后果。第一padding token占用專家容量可能導(dǎo)致有效token被擠掉超過capacity被丟棄。第二即使padding token沒有實際信息它們依然占據(jù)通信通道白白消耗All-to-All帶寬。好在我們找到的解決辦法并不復(fù)雜在padding位置的路由概率上直接加一個非常大的負偏置讓Router幾乎不可能選中任何專家或者把padding token在進入MoE層之前直接從batch里摘除等所有專家計算完再放回原位。前者改動小后者更徹底但需要處理動態(tài)batch工程復(fù)雜度會增加一些。類似的浪費也出現(xiàn)在推理場景現(xiàn)在主流的推理框架普遍采用連續(xù)批處理continuous batching不同請求的長度不對齊時也會出現(xiàn)大量虛位token。所以做MoE推理服務(wù)時請求調(diào)度策略對性能的影響往往比模型結(jié)構(gòu)本身還大。5. 實測調(diào)參清單與擴展思路從復(fù)現(xiàn)一個簡單 MoE 層開始5.1 一個可直接改寫的 MoE 層偽代碼結(jié)構(gòu)看完前面的原理你已經(jīng)可以把一個標準的MoE層搭出來了。下面用離實現(xiàn)很接近的偽代碼展示核心邏輯框架無關(guān)方便你對照著改寫自己的代碼。def moe_ffn(x, experts, router, K2, capacity_factor1.25): # x: [batch, hidden] B x.shape[0] E len(experts) T B # 這里假設(shè)每個token獨立路由實際實現(xiàn)會考慮padding mask # 1. 計算路由概率 logits router(x) # [B, E] probs softmax(logits, dim-1) # [B, E] # 2. 取Top-K專家 top_probs, top_idx probs.topk(K, dim-1) # 各[B, K] top_probs top_probs / top_probs.sum(dim-1, keepdimTrue) # 歸一化 # 3. 按專家容量篩選 capacity int(capacity_factor * B / E) dispatch_mask build_dispatch_mask(top_idx, E, capacity) # [B, E, K] 或管理token分配 # 4. 對每個選中的專家執(zhí)行 FFN并按權(quán)重聚合 output zeros_like(x) for e in range(E): selected dispatch_mask[:, e] # 哪些token被分到專家e if selected.any(): expert_out experts[e](x[selected]) # [num_selected, hidden] output[selected] (top_probs[selected, e] * expert_out) # 5. 殘差連接 return output residual_x當然真實工程里不會用for循環(huán)逐專家算而是通過矩陣乘法一次性完成所有專家的前向但核心邏輯就是上面的流程。為了效率專家計算通常會合并成一個大的張量運算把專家參數(shù)沿著一個軸堆疊起來然后用grouped GEMM一次算出所有選中專家的輸出。這也是很多訓(xùn)練框架在MoE部分做的主要優(yōu)化。5.2 調(diào)參順序先穩(wěn)定路由再追容量調(diào)MoE和調(diào)普通模型一個很大的區(qū)別是超參數(shù)之間存在明顯的先后依賴關(guān)系。一上來就亂試專家數(shù)、路由權(quán)重很容易出現(xiàn)忘記調(diào)了什么的局面因為每個超參數(shù)都會間接影響Router的負載分布。我建議按下面的順序做超參數(shù)常用范圍影響效果調(diào)整優(yōu)先級專家數(shù) E8~64視參數(shù)量預(yù)算決定容量上限和并行度先定預(yù)算再選Top-K1~2計算量、冗余度、通信量建議固定為2capacity_factor1.0~1.5丟棄率、負載余量、性能優(yōu)先調(diào)aux loss 系數(shù)0.001~0.1負載均衡強度次優(yōu)先Router溫度0.5~1.0可學(xué)習(xí)路由分布尖銳度小步微調(diào)專家Dropout0.0~0.1緩解過擬合、增強魯棒性最后調(diào)具體來說先固定E和K把capacity_factor從1.25開始試觀察訓(xùn)練時被丟棄token的比例。如果丟棄太多說明Router的選擇太集中或容量太小可以適當調(diào)大capacity_factor如果幾乎為零則逐步減小壓出更多計算密度。然后才去調(diào)整aux loss系數(shù)從0.01起步每幾百步看一眼各專家的token占比分布。占比的方差如果持續(xù)縮小到接近均勻說明權(quán)重偏大可以降如果某個專家占比持續(xù)超過2倍平均則要加大權(quán)重。一個反直覺的經(jīng)驗是對于中小規(guī)模的模型參數(shù)量在億級以下MoE的優(yōu)勢并不明顯。Router自身也需要數(shù)據(jù)爬坡假設(shè)總數(shù)據(jù)量沒法讓每個專家都充分訓(xùn)練那稀疏結(jié)構(gòu)的收益就會打折扣。所以不要只盯著MoE大模型專利這個說法也要理解它依賴的規(guī)模前提。5.3 什么時候不應(yīng)該用 MoE以及幾個值得關(guān)注的擴展方向MoE不是銀彈。如果你的使用場景是單機單卡、推理延遲極敏感、或者模型規(guī)模本來就很小那么MoE帶來的通信開銷和顯存負擔(dān)通常不值得。尤其是邊緣端或者移動端場景參數(shù)量常駐和動態(tài)路由的不確定性會讓部署變得非常不友好。寧可把精力花在蒸餾、量化或者知識蒸餾這類壓縮手段上。反過來MoE真正發(fā)光的地方是訓(xùn)練語料極其豐富而單卡顯存成為瓶頸、需要在不顯著增加推理計算量的前提下擴展容量、以及多種異構(gòu)任務(wù)希望共用一套底座但各任務(wù)又有自己的特性。多模態(tài)方向也可以大膽嘗試——不同模態(tài)的信息處理模式差異大正好適合交由不同專家專人負責(zé)門控網(wǎng)絡(luò)學(xué)到的模態(tài)路由有時會帶來意想不到的可解釋性。我在一次改造中把MoE從語言模型搬到了推薦系統(tǒng)的打分模型里不同用戶群體走不同專家冷啟動階段用戶走Generalist專家活躍用戶則能訪問專屬專家后的組合結(jié)果效果提升比純粹加深網(wǎng)絡(luò)更明顯。這說明MoE的分診思想完全值得跨場景復(fù)用關(guān)鍵還是找到那些不同樣本需要不同能力的問題。最后分享兩個小技巧。如果你已經(jīng)用上了MoE建議把Router的決策分布做成可視化日志每訓(xùn)練幾千步看一眼比任何損失曲線都能更快發(fā)現(xiàn)問題另一個是在測試階段記錄專家熱力分布如果模型收斂后大部分token的Top-1專家高度集中往往說明模型只學(xué)到了表面規(guī)律需要回頭檢查訓(xùn)練數(shù)據(jù)本身的多樣性。MoE這條路技術(shù)在往前走但工程的坑說到底還是那幾類通信、負載、穩(wěn)定性。理解了底層邏輯剩下的就是耐心調(diào)參和踩坑。希望這些經(jīng)驗?zāi)軒湍闵僮邘撞綇澛贰?