UniPool：共享 MoE 專家池

UniPool 把 MoE 的分層專家改成全域共享池，讓不同層共用同一批 experts，降低重複參數。

傳統 MoE Transformer 的做法很直覺：每一層都配自己的專家組。這種設計好理解，也好實作，但代價是專家容量會跟著層數一路線性增加。UniPool: A Globally Shared Expert Pool for Mixture-of-Experts 認為，這個預設其實可能太死板了，尤其當某些層的專家容量並沒有真的被充分用滿時。

這篇摘要想處理的痛點很明確。若大量專家參數只是依照層數重複複製，那 MoE 雖然名義上更有容量，實際上卻可能在付出不必要的參數成本。作者提到的 routing probe 顯示，把較深層的 learned top-k router 換成 uniform random routing，在多個 production MoE 模型上只讓下游準確率下降 1.0 到 1.6 個百分點。這不代表 routing 不重要，但至少說明：有些層的專家配置，可能沒有標準架構想像中那麼不可替代。

這篇論文想解什麼問題

在常見的 MoE 架構裡，每一層都擁有自己的 experts。這樣的好處是邏輯清楚，層與層之間的容量切分也容易管理；但壞處是，專家參數會隨深度線性膨脹。對要做更大模型的團隊來說，這是一個很硬的成本結構：每多一層，通常就得再多養一批專家權重。

UniPool 的出發點，就是打破這種「每層自帶一組專家」的綁定關係。它把專家容量視為一個全域共享資源，而不是每層私有的固定配額。模型仍然保留每層自己的 router，但 router 不再只指向本層專屬的 experts，而是去同一個共享池裡挑選。

這個想法的價值，在於它重新定義了 MoE 的容量分配方式。MoE 本來就是為了用稀疏路由換取更高容量，同時避免推論成本暴增；如果架構本身因為層層重複而浪費了專家參數，那整個效率論述就會被削弱。UniPool 想做的，就是在不放棄 sparse expert routing 的前提下，讓容量配置更彈性。

UniPool 的方法怎麼運作

UniPool 的核心改動其實很簡單：把原本屬於各層的 experts，改成一個全域共享的 expert pool。每一層還是有自己的 router，負責決定哪些 token 要送去哪些 experts；差別在於，這些 router 指向的是同一批 experts，而不是各自獨立的一套。

這樣做的結果，是不同層可以重複使用同一份專家容量。對模型來說，expert parameter 不再需要隨層數重複堆疊。對工程上來說，這等於把 expert capacity 從「每層固定配額」改成「全模型共用預算」。

不過，共享也會帶來新問題。當所有層都能打到同一個 pool 時，某些 experts 可能會被過度使用，另一些則幾乎閒置。為了避免訓練失衡，論文加入了 pool-level auxiliary loss，目的是在整個共享池內平衡 expert utilization。作者也使用 NormRouter，並把它描述為能在共享 expert pool 中提供 sparse 且 scale-stable 的 routing。

所以這不是單純把 experts 合併就結束了，而是「架構共享」加上「訓練控制」一起上。對想實作這個方法的人來說，重點不只是共享本身，還要注意共享之後怎麼避免少數 experts 吃掉大部分流量。

論文實際證明了什麼

摘要中的實驗範圍是五個 LLaMA 架構規模：182M、469M、650M、830M、978M 參數。這些模型都在 The Pile 的 30B tokens 上訓練。作者表示，UniPool 在這些規模上都能穩定優於對應的 vanilla MoE baseline，指標包含 validation loss 與 perplexity。

摘要裡最具體的數字，是 UniPool 相較於 vanilla MoE，validation loss 最多可下降 0.0386。另一個重點是 reduced-pool 版本：它們只用了 vanilla expert-parameter budget 的 41.6% 到 66.7%，卻仍能在測試規模上達到與 layer-wise MoE 相當或更好的表現。這是這篇最值得注意的地方，因為它直接回應了 MoE 最常被質疑的問題之一：是不是一定要堆那麼多分層專家，效果才會好。

作者也把這個結果延伸成一個 scaling 觀點。對 UniPool 來說，pool size 變成一個可以直接調整的 depth-scaling hyperparameter。換句話說，專家容量不必再預設跟深度線性成長；在這些實驗裡，sublinear 的成長方式也能維持，甚至超過原本的 layer-wise 設計。

摘要還提到，UniPool 的好處可以和更細粒度的 expert decomposition 一起使用。雖然摘要沒有進一步展開細節，但至少可以看出這個共享池不是只能在單一設定下才有效的特殊技巧。

對開發者有什麼影響

如果你在做或調 MoE 系統，這篇的訊息很直接：expert placement 可能比傳統的分層專屬設計更有彈性。UniPool 提供了一種把 expert capacity 視為共享資源的方式，理論上可以減少參數重複，也讓深度擴展的成本不必那麼快上升。

對實務上的工程團隊來說，這個方向至少有幾個可想像的好處：

• 在相同模型規模下，可能需要更少的 expert 參數。
• pool size 變成明確可調的容量旋鈕，不必被層數綁死。
• 某些 MoE 層可能不需要完全獨立的 expert set，也能維持效果。
• 訓練時可以用 pool-level 的機制去平衡共享 experts 的使用率。

不過，這篇摘要沒有提供推論 latency、throughput、記憶體拆分或部署成本的數字，所以不能直接推論它在系統層面一定更快或更省。它目前最強的證據，還是來自訓練後的 validation loss 與 perplexity 改善，以及更低 expert budget 下仍能維持表現。

還有哪些限制要注意

從摘要能看到的資訊來說，這篇確實給了很清楚的方向，但還不是 production-ready 的完整答案。首先，摘要沒有公開完整 benchmark 細節，所以我們看不到更細的訓練設定、路由失衡情況，或不同 pool size 下的敏感度分析。

其次，實驗範圍雖然涵蓋五個 LLaMA 規模，但仍然是特定架構、特定資料集、特定訓練條件下的結果。是否能直接推到其他模型家族、其他資料分布，或更大規模的線上服務情境，摘要沒有給出答案。

最後，這篇的核心主張是「分層專屬 experts 可能太保守」。UniPool 用全域共享池證明，MoE 的 capacity allocation 不一定要照傳統方式切得那麼死。在它展示的實驗裡，這種做法不只沒有傷害表現，還能在較少 expert 參數下維持甚至改善驗證指標。對開發者來說，這是一個值得認真看的架構替代方案。