我的知識庫

AI · 2026-07-23

閱讀時間約 10 分鐘

2026 年幾乎所有跑得又快又便宜的大模型，底層都是同一個架構祕密：混合專家（Mixture of Experts，MoE）。當一家公司說它的旗艦模型「總參數上兆、但每個 token 只用其中一小部分」，講的就是 MoE。它解決的是一個看似無解的矛盾——你想要更大的模型（參數越多、能力通常越強），又不想要等比暴增的運算成本。MoE 的答案是：把模型做得很大，但每次只喚醒一小塊。今天把這個支撐當代前沿模型的架構，從直覺到工程權衡講透。

📖 學

稠密模型的困境：參數一多，成本就等比爆炸

傳統的「稠密」（dense）Transformer，每處理一個 token，都要動用全部參數做運算。參數翻倍，每個 token 的運算量（FLOPs）也大致翻倍。這是條殘酷的縮放曲線：能力隨規模成長，但推理成本、延遲、電費也同步膨脹。你想要 GPT 等級模型的聰明，卻付不起讓每個 token 都跑過上兆參數的帳單。MoE 就是為了打破「參數量」與「每 token 運算量」之間這條死綁的等號而生。

核心概念：專家與稀疏啟用

MoE 把 Transformer 裡的前饋層（FFN）換成一組並排的「專家」（experts）——比如 8 個、64 個、甚至 256 個結構相同、參數各異的子網路。關鍵是每個 token 不會經過所有專家，只被路由到其中少數幾個（常見是 top-2）。這叫「稀疏啟用」（sparse activation）。

於是模型有兩個截然不同的參數量：**總參數（total parameters）**是所有專家加起來的龐大數字，決定模型能「記住」多少知識容量；**啟用參數（active parameters）**是每個 token 實際用到的那一小部分，決定每次推理的運算成本。一個總參數 1 兆、每 token 只啟用 370 億的模型，能力接近千億級稠密模型，運算成本卻只像幾百億級——這就是 MoE 的魔法：用啟用參數的成本，買到接近總參數的容量。

路由器 Router：MoE 的大腦與痛點

決定「這個 token 該送去哪幾個專家」的，是一個叫**閘門網路（gating network）或路由器（router）**的小型網路。它為每個 token 對每個專家算一個分數，選出分數最高的 top-k 個專家，把 token 送過去，再把各專家的輸出依權重加總。整個路由是可微分的，跟著主模型一起訓練，讓路由器逐漸學會「什麼樣的 token 交給哪種專家最好」。

但路由器也是 MoE 最脆弱的地方。最大的敵人是負載不均衡（load imbalance）：路由器可能偷懶，把大多數 token 都塞給少數幾個「明星專家」，其他專家幾乎沒被訓練到，形同浪費——嚴重時甚至「專家崩塌」。為此工程上要加**輔助損失（auxiliary/load-balancing loss）**懲罰不均，或設「專家容量上限（capacity factor）」，滿了就丟棄或改路由（token dropping）。近年像 DeepSeek 採用的「無輔助損失負載均衡」等新做法，就是在想辦法在不犧牲模型品質的前提下把 token 分得更平均。

一個常見誤解：專家不是「領域專家」

很多人以為 MoE 的專家會自然分工成「數學專家」「法律專家」「寫程式專家」。事實上經過訓練後，專家的分工往往是細碎、抽象、難以用人話解讀的——某個專家也許擅長處理標點與句法結構，另一個對某類 token 的過渡特別敏感，而不是乾淨地對應到人類的知識領域。把「專家」想成「一群各有偏好、由路由器動態調度的子網路」，比想成「一排領域顧問」更貼近真相。

工程權衡：省了算力，賠上記憶體與複雜度

MoE 不是免費午餐，它把成本從「運算」搬到了「記憶體與系統複雜度」。雖然每個 token 只啟用少數專家，但所有專家的參數都得同時載進顯示記憶體（VRAM）待命——所以 MoE 模型的記憶體佔用是按總參數算，不是啟用參數。這使得部署 MoE 往往需要跨多張 GPU 做「專家平行（expert parallelism）」，把不同專家放在不同卡上，推理時 token 要在卡與卡之間傳遞，帶來通訊開銷與工程複雜度。此外訓練 MoE 較不穩定、微調更棘手。所以 MoE 的甜蜜點是大規模、高吞吐的服務場景：省下的運算成本遠大於多付的記憶體與工程代價；而在記憶體吃緊的邊緣裝置上，稠密小模型或蒸餾模型反而更合適。這也和昨天談的量化、蒸餾是互補的壓縮思路——量化壓的是每個參數的位元、蒸餾壓的是總參數量、MoE 壓的是每次推理實際動用的參數。

🧠 記

  • MoE 打破「總參數量」與「每 token 運算量」的死綁：模型做很大，每次只喚醒一小塊。
  • 把稠密 FFN 換成一組並排「專家」，每個 token 只路由到少數（常見 top-2），即稀疏啟用。
  • 兩個參數量：總參數＝知識容量，啟用參數＝每次推理成本；用啟用成本買到接近總容量的能力。
  • 路由器（閘門網路）決定 token 送去哪些專家，可微分、隨模型一起訓練。
  • 最大痛點是負載不均衡，靠輔助損失、容量上限、token dropping 或新式無輔助損失均衡緩解。
  • 誤解澄清：專家的分工細碎抽象，並非乾淨對應「數學／法律」等人類領域。
  • 代價是記憶體：所有專家都要載進 VRAM，佔用按總參數算，常需跨 GPU 的專家平行。
  • 甜蜜點是大規模高吞吐服務；與量化（壓位元）、蒸餾（壓總量）互補。

✍️ 實踐

  1. 下次看到模型規格寫「1T total / 37B active」，先在心裡翻譯：能力接近前者、每 token 成本接近後者、記憶體需求看前者。
  2. 選型時分辨場景：雲端高吞吐服務偏好 MoE；記憶體受限的本地／邊緣裝置優先考慮稠密小模型或蒸餾模型。
  3. 若用開源 MoE（如 Mixtral、DeepSeek 系列），實測時觀察它在你任務上的品質是否隨負載變化，理解容量上限與 token dropping 可能的影響。
  4. 估算部署成本時，記得 VRAM 要按總參數準備，別被「啟用參數很小」誤導而低估硬體需求。
  5. 把 MoE、量化、蒸餾三者當成一組互補工具：分別對應壓縮「每次動用的參數／每個參數的位元／整體參數量」，依瓶頸選用。
  6. 讀一篇 MoE 論文或技術報告，特別看它如何處理負載均衡，這通常是模型品質差異的關鍵。

🔗 延伸學習

💬 問 AI

我想真正搞懂混合專家模型 MoE，而不只是背名詞，並判斷它適不適合我的使用情境。

我的情況：
- 我在做的應用／部署環境：{待填，例如雲端 API 服務／本地 GPU／邊緣裝置}
- 我在意的指標：{待填，例如吞吐量／延遲／記憶體成本}
- 我目前考慮的模型：{待填}

請幫我：
1. 用白話解釋 MoE 的「總參數 vs 啟用參數」對我的推理成本與記憶體需求分別代表什麼。
2. 針對我的環境，判斷該選 MoE 還是稠密／蒸餾模型，並說明關鍵取捨（VRAM、專家平行通訊、微調難度）。
3. 出 2 個問題考我，檢查我是否真的理解路由器與負載均衡，而不只是看過。

反向連結