MoE 是什麼:把大模型變便宜的關鍵設計

DeepSeek-V3 的技術報告裡有一組很容易被誤讀的數字：

671B total parameters,37B activated per token。

白話說，它不是每次回答都把 671B 參數全開。每個 token 只啟動其中一部分。Mixtral 8x7B 也有類似設計：Mistral 說它有 46.7B total parameters，但每個 token 只使用 12.9B parameters。

這就是 Mixture of Experts。

Mixture of Experts(MoE，專家混合)是一種條件式計算架構。模型裡有多組 expert parameters，每個輸入或 token 進來時，router / gating network 只選少數 expert 來處理。它的核心不是「很多專家比較聰明」，而是把「模型總容量」和「單次計算量」拆開。

理解 MoE，就能看懂 2024-2026 年很多「大模型變便宜」的敘事：哪些是真的架構效率，哪些只是把成本藏到部署工程裡。

先看 dense model:每次都全員上工

一般 Transformer LLM 多半是 dense model。Dense 的意思是：每個 token 通過模型時，會使用同一套主要參數路徑。

可以把它想成一間公司只有一個巨大部門。每份文件進來，都送進同一個部門處理。部門越大，能力可能越強，但每次處理文件都要動用整個部門的計算量。

這有一個直接問題：

想要的事	Dense model 的代價
讓模型知道更多	增加參數
增加參數	每次推論也更重
每次推論更重	延遲、GPU 記憶體、成本上升

Dense scaling 很乾淨，也很貴。

MoE 想解的是這件事：能不能讓模型有很大的參數倉庫，但每次只拿出其中幾格來算？

MoE 怎麼運作：router 先分派，expert 再計算

MoE 會把模型的一部分層，通常是 Transformer 裡的 feed-forward network，換成多個 expert。

一個簡化流程如下：

token
  ↓
router / gating network
  ↓
選出 top-k experts
  ↓
只有被選中的 experts 計算
  ↓
合併結果,送回模型主幹

這裡的 expert 不要想成人類專家。它不是「法律專家」「寫程式專家」「中文專家」這種可直接命名的角色。更精確地說，expert 是一組參數。Router 學會對不同 token 分派不同參數路徑。

2017 年的 Sparsely-Gated MoE 論文把這個想法放進語言模型和機器翻譯：用 gating network 為每個例子選擇稀疏的 expert 組合。後來 GShard、Switch Transformer 把這個方向推到更大的 Transformer 與多語言翻譯模型。

關鍵詞是 sparse activation(稀疏啟動)。模型總參數很多，但每個 token 只啟動一小部分。

為什麼這會讓模型「大而不一定貴」

MoE 的好處，可以用三個數字拆開：

指標	意思	讀法
Total parameters	模型總共有多少參數	代表容量，但不等於每次都全用
Active parameters	每個 token 實際啟動多少參數	更接近每次推論的計算量
Number of experts / top-k	有幾組 expert，每次選幾組	影響容量、路由與部署複雜度

以 Mixtral 8x7B 為例。Mistral 說它每層有 8 組 expert，每個 token 由 router 選 2 組 expert 處理。它的 total parameters 是 46.7B，但每個 token 使用 12.9B parameters。

所以「8x7B」不能直覺讀成「等於 56B dense model 每次全開」。比較準確的讀法是：它有多組 7B 級 expert 組成的稀疏架構，但每個 token 只走其中一部分路徑。

DeepSeek-V3 的數字更大。技術報告表示它是 671B total parameters，每個 token 啟動 37B parameters。這類規格要用同一個框架讀：

模型	Total parameters	Active per token	應該怎麼理解
Mixtral 8x7B	46.7B	12.9B	大容量 open-weight SMoE，每 token 只啟動少數 expert
DeepSeek-V3	671B	37B	很大的 MoE 參數倉庫，但單 token 計算量遠小於 total parameters

這就是 MoE 的吸引力：它讓模型的「容量」可以比單次推論的「計算量」長得更快。

Switch Transformer 做了什麼

MoE 不是 2024 才出現。它長期卡在一個現實問題：想法漂亮，工程麻煩。

Switch Transformer 的重要性，在於把 MoE routing 簡化。傳統 top-k MoE 可能為每個 token 選多個 expert；Switch Transformer 讓每個 token 只選一個 expert，降低 routing 和通訊複雜度。

論文裡有兩個值得記的訊號：

• MoE 可以讓模型稀疏啟動，總參數很大，但計算量不按同等比例上升。
• 這條路的障礙一直是 complexity、communication cost、training instability。

第二點很重要。MoE 不是「把模型切成很多塊」就結束。Router 如果分派不均，有些 expert 過載，有些 expert 閒置；跨 GPU / TPU 傳 token，會帶來通訊成本；訓練時還要讓各 expert 都學到有用東西，而不是某幾個 expert 壟斷流量。

所以 MoE 的工程本質是：用 routing 和分散式系統的複雜度，換更高的參數容量效率。

Expert 真的會各自學會專長嗎

這是 MoE 最容易被過度擬人化的地方。

「Mixture of Experts」這個名字會讓人想像：模型裡有一位數學專家、一位中文專家、一位程式專家。實際上不該這樣理解。

Expert 是一組神經網路參數。Router 會根據 token 的表示選擇路徑。某些 expert 可能在訓練後對特定語言、語法、任務型態或 token pattern 更常被啟動，但它不是可直接審計的職稱表。

比較安全的說法：

常見說法	更精確說法
模型找最懂的專家回答	Router 為 token 選擇少數參數路徑
每個 expert 學一個領域	Expert 可能形成偏好，但不保證可用人類領域命名
MoE 讓模型免費變強	MoE 提高容量效率，但增加 routing / serving 複雜度

如果把 expert 當成真人職能，很容易誤解模型為什麼會錯、為什麼會偏、為什麼有時 routing 不穩。

MoE 省了什麼，沒省什麼

MoE 省下的主要是 per-token compute。每個 token 不需要跑完整 total parameters。

但它沒有自動省掉所有成本。

沒有省掉記憶體。 Serving 時你仍然要放得下整個模型或設計好 expert parallelism。Total parameters 還是要存，只是每個 token 不全部計算。

沒有省掉通訊。 如果 expert 分散在多張 GPU / TPU 上，token 被 router 分派到不同 expert，就會有跨裝置資料搬運。

沒有省掉 batching 問題。 Dense model 的 batching 比較直覺；MoE 會出現不同 token 去不同 expert 的不均衡。熱門 expert 可能成為瓶頸。

沒有省掉訓練穩定性。 Router 要學會分派，expert 要避免塌縮，負載要平衡。DeepSeek-V3 技術報告特別強調 load balancing 設計，也是因為這是 MoE 的核心工程問題。

所以看到「active parameters 只有 37B」時，不要直接翻譯成「部署成本等於 37B dense model」。更精確的問題是：

1. Total parameters 要怎麼放進硬體？
2. 每個 token 啟動多少參數？
3. Router 和 expert parallelism 帶來多少通訊成本？
4. Serving stack 是否真的為 MoE 做了優化？

MoE 跟 quantization、distillation 差在哪

MoE 常和其他「降成本」技術一起出現，但它們解的不是同一件事。

技術	解的問題	直覺比喻
MoE	每次只啟動部分參數	大倉庫，每次只開需要的幾個抽屜
Quantization	每個參數用更少 bit 儲存 / 計算	把同一本書印小一點
Distillation	用大模型教小模型	老師把知識整理成學生版本
Pruning	移除不重要參數	把很少用的零件拆掉

MoE 是架構設計。Quantization 是數值壓縮。Distillation 是訓練方法。它們可以一起用，但不要混成同一種成本魔法。

例如一個 MoE 模型仍然可以被量化；量化後的 expert 佔更少記憶體。但 router、expert 分派、跨裝置通訊問題仍然存在。

對 builder 的判斷

如果你只是使用 API,MoE 多半是供應商背後的架構細節。你真正要看的是價格、延遲、上下文長度、品質和穩定性。

但如果你在評估 open-weight 模型、自架模型或 GPU 預算，MoE 就不能跳過。

第一，讀規格時分清 total 和 active。 Total parameters 是容量敘事，active parameters 更接近單 token 計算敘事。兩個都要看。

第二，不要只看模型大小，要看 serving stack。 同一個 MoE 模型，在不同 inference framework、batch size、GPU topology 下，吞吐量可能差很多。

第三，不要用 dense model 直覺估 MoE 成本。 671B MoE 不等於 671B dense 每次全跑，也不等於 37B dense 一樣簡單。它在中間：計算量下降，工程複雜度上升。

第四，對資料敏感或自架場景，MoE 是機會也是門檻。 它讓 open-weight 模型可以用更有效率的方式增加容量，但也提高部署門檻。小團隊要先確認工具鏈是否成熟，不要只被 total parameters 吸引。

收尾

MoE 不是讓模型免費變聰明。

它真正做的事，是讓模型把「知道很多」和「每次都算很多」拆成兩件事。總參數像一座大倉庫，router 每次只打開少數抽屜。

這就是為什麼 Mixtral、DeepSeek-V3 這類模型可以同時談「大容量」和「較低每 token 計算量」。

下次看到 MoE 模型，先問三件事：

1. Total parameters 是多少？
2. Active parameters per token 是多少？
3. 為 routing、load balancing、memory、serving 付出了什麼代價？

能回答這三題，你才真的看懂「大模型變便宜」這句話的邊界。

周詠晴（編輯：廖玄同），《MoE 是什麼:把大模型變便宜的關鍵設計》，矽基前沿 [Si]gnals，2026-04-26。https://signals.tw/articles/what-is-mixture-of-experts/