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