我的知識庫

AI · 2026-07-10

閱讀時間約 12 分鐘

📖 學（核心）

稀疏激活：為什麼「參數多」不等於「算得慢」

混合專家模型（Mixture of Experts, MoE）的核心想法,是把原本一個巨大的前饋層（FFN）拆成好幾組獨立的「專家」網路,每組專家各自學會處理不同型態的輸入。關鍵在於,每個 token 通過這一層時,並不會同時通過所有專家運算,而是只被送去其中一小部分(例如 8 選 2、甚至 256 選 8),其餘專家完全不參與這次計算。這種「只啟動一部分參數」的做法就是稀疏激活(sparse activation),對比之下,傳統的密集模型(dense model)每個 token 都要經過全部參數運算,計算量隨參數量線性增加。

稀疏激活帶來的直接效果,是模型的「總參數量」和「實際運算量」被解耦。以 Mixtral 8x7B 為例,模型總共擁有約 470 億參數,但每個 token 實際上只會用到約 130 億參數在運算,因為路由器每層只挑選 2 個專家出來處理。這代表在相同的運算預算(FLOPs)之下,MoE 架構可以把模型容量做得遠比密集模型大,讓不同專家去記憶、專精不同的知識和模式,而不必為此多花運算成本。這也是為什麼近年的旗艦級模型,從 Mixtral 到 DeepSeek-V3,再到 GPT-4 等傳聞中的架構,幾乎都選擇了 MoE 路線 —— 用同樣的訓練和推理算力,換到更大的有效模型容量。

DeepSeek-V3 把這個概念推得更極致,採用「細粒度專家」設計,總共 256 個路由專家,每個 token 只啟動其中 8 個,再加上固定啟動的共享專家。專家數量變多、每個專家變小,可以讓路由器做更精細的分工,不同專家能學到更窄、更專一的模式,理論上提升了模型在同樣運算量下的表達能力。這也說明了 MoE 設計不是「一種固定架構」,而是一個可以在專家數量、每層啟動數、專家大小之間反覆調校的設計空間。

路由器與負載平衡:MoE 真正難的地方

如果說「多專家、稀疏啟動」是 MoE 的骨架,那路由器(router)就是決定這個架構能不能真正發揮效益的靈魂。路由器本質上是一個小型的門控網路(gating network),輸入是當前 token 的隱藏狀態,輸出是每個專家的分數,再依分數挑出前 k 名專家(即 top-k routing)。這個選擇是「離散」的,而離散選擇本身難以像一般神經網路一樣直接用梯度下降做端到端最佳化,這也是為什麼早期 MoE 論文要大費周章設計輔助技巧,讓路由決策依然可以被訓練調整。

路由器的訓練最容易踩到的坑,是「專家崩潰」(expert collapse):如果不做任何限制,路由器很可能發現只要把大部分 token 都送去某幾個表現不錯的專家,loss 就能快速下降,結果導致這幾個熱門專家被過度使用、其餘專家幾乎收不到訓練訊號,形成惡性循環,模型也失去了「多專家分工」原本該有的多樣性。Mixtral 的實測資料顯示,即使有訓練技巧介入,專家之間的負載仍可能出現高達 25% 的不平衡,顯示這是一個持續存在、而非一次解決就沒事的問題。

因應這個問題,業界發展出兩條主要路線。第一條是「輔助損失」(auxiliary loss)路線,在主要訓練目標之外,額外加一個懲罰項,鼓勵路由器把 token 均勻分配給所有專家,Mixtral 等早期 MoE 模型多半採用這個做法,但額外的 loss 項也會干擾主任務的最佳化方向,兩者要拉扯出平衡點。第二條是 DeepSeek-V3 採用的「免輔助損失」路線,做法是替每個專家維護一個動態調整的偏置項(bias),當某個專家最近被啟動得太頻繁,系統就調低它的偏置、讓它在下一輪路由競爭中分數變低,反之則調高偏置,藉此在不動用額外 loss 的前提下,持續把負載動態地拉回平衡,實測在小規模模型上可以把每層的負載不平衡壓到 8% 以內,顯著優於傳統輔助損失做法。

專家並行:把巨大的 MoE 模型真正跑起來

專家數量一多,MoE 模型的總參數量很容易超過單張 GPU 的顯存容量,這時候需要靠「專家並行」(Expert Parallelism, EP)把不同專家分散到不同 GPU 甚至不同機器上。做法是每張 GPU 只保留一小部分專家的權重,其餘的注意力層等共用參數則在各裝置間複製。當一批 token 進入 MoE 層,系統要先透過 all-to-all 通訊,把每個 token 分派到它被路由器選中、且剛好放在其他 GPU 上的專家那裡運算,算完之後再用另一次 all-to-all 把結果送回原本的裝置,重新組合成完整的序列輸出。

這套機制聽起來單純,實際落地卻極度考驗硬體的互聯頻寬。因為 all-to-all 通訊的資料量、延遲,直接決定了大型 MoE 模型的推理吞吐上限,如果 GPU 之間只靠 PCIe 這種較慢的介面串接,通訊延遲很容易吃掉稀疏激活省下來的算力優勢。這也是為什麼 NVIDIA 近年大力推廣 NVLink、NVL72 機櫃這類高頻寬互聯方案,並搭配 Dynamo 這類專門排程框架,目標就是讓「專家分散在多張卡上」這件事情的通訊代價降到最低,讓千億甚至兆級參數的 MoE 模型也能在合理延遲下提供服務。實務上,選用或部署 MoE 模型時,除了看參數量與 benchmark 分數,GPU 拓樸、互聯頻寬、以及路由負載是否平衡,同樣是決定實際推理成本與速度的關鍵變數。

🧠 記

  • MoE 把一層 FFN 拆成多個「專家」,每個 token 只啟動其中一小部分(top-k),稱為稀疏激活。
  • 稀疏激活讓「總參數量」與「實際運算量」脫鉤,同樣算力預算下可做出容量更大的模型。
  • Mixtral 8x7B:總參數約 470 億,每 token 實際只用約 130 億(8 選 2 路由)。
  • DeepSeek-V3:256 個細粒度路由專家 + 共享專家,每 token 啟動 8 個路由專家。
  • 路由器(router / gating network)決定 token 送去哪些專家,是離散選擇,訓練上比一般層更棘手。
  • 「專家崩潰」是 MoE 最大風險:路由器偏好少數熱門專家,其餘專家訓練不足。
  • 負載平衡兩條路線:輔助損失(auxiliary loss)vs. DeepSeek 的動態偏置(免輔助損失)。
  • 專家並行(Expert Parallelism)把專家分散到多 GPU,靠 all-to-all 通訊分派與收集 token,互聯頻寬是效能瓶頸。

✍️ 實踐

  1. 挑選 API 或開源 MoE 模型前,先分清楚「總參數量」與「啟動參數量」兩個數字,後者才是真正影響推理延遲與成本的關鍵指標。
  2. 若要自架或微調 MoE 模型,訓練時務必監控每個專家的 token 分配比例,觀察是否出現少數專家佔比過高的「崩潰」現象。
  3. 部署大型 MoE 模型時,優先確認硬體的 GPU 間互聯方案(如 NVLink 等高頻寬互聯),避免 all-to-all 通訊成為推理吞吐的瓶頸。
  4. 比較不同 MoE 架構時,留意「專家數量」與「每次啟動數」的組合(如 8 選 2、256 選 8),這會影響模型專精度與路由複雜度。
  5. 針對特定任務選型時,可實測同一 prompt 在不同 MoE 模型上的回應品質與延遲,交叉比對官方揭露的啟動參數量,評估是否符合成本效益。

🔗 延伸學習

💬 問 AI

我正在評估是否要在我的應用中導入 MoE 架構的大型語言模型（例如｛請填入模型名稱｝）。
請幫我分析：
1. 這個模型的總參數量與每次推理實際啟動的參數量各是多少？
2. 以我的使用情境（｛請填入使用情境，例如：客服問答 / 程式碼生成 / 多語言翻譯｝）來說，MoE 架構相較密集模型（dense model）有什麼優劣？
3. 若要自行部署，需要考慮哪些硬體條件（GPU 數量、互聯頻寬、專家並行設定）？
4. 有沒有已知的負載平衡或路由相關限制，是我在選型前應該注意的？

反向連結