真·MoE？路由LLM最全面探索：一種筆記本也能玩的大模型Scaling Up研究

事關路由LLM（Routing LLM），一項截至目前最全面的研究，來了——

共計收集和整理了涉及8500+個LLM，在12個Benchmark上的共2億條性能記錄！

先來簡單科普一下路由LLM。

這種方法主要是把像ChatGPT、Qwen、DeepSeek這些成型的LLM當作 “專家” ，當給一個輸入的時候，有分類能力的Router（路由器）就會把這個輸入分配給合適的LLM處理。

如此一來，就能實現高性能、低計算消耗、低幻覺等目標。

而來自中山大學和普渡大學的研究人員在基於上述海量的記錄做了一番探索之後，發現了一個現象，叫做Model-level Scaling Up。

一言蔽之，就是一個好的Router，可以讓路由LLM範式的性能隨著LLM候選數量的增加迅速變強。

隨後，他們通過這些資料建構了針對Router設計的評測RouterEval。

值得注意的是，其他研究人員，也可以通過RouterEval在很少的計算資源下（如筆記本、單卡GPU上）就能參與到該路由LLM的研究當中。

2億條記錄中發現的新現象

當大多數研究人員和開發者第一次聽到Mixture-of-Expert (MoE) 的時候，可能第一反應不是現在常見的對結構中的FFN層進行擴展，以FFN層作為”expert”。

而是直接將每一個成型的LLM，比如ChatGPT、Qwen、DeepSeek等直接看做是”expert”。

實際上，這種範式也稱為路由LLM（Routing LLMs）。

簡單地說，就是給定一個輸入input，一個具有一定分類能力的Router (路由器)會將input分配給指定的LLM進行處理，以達到高性能、低計算消耗或者是低幻覺等各種各樣的目標，或組合目標。

這類問題可以被認為是分類問題、推薦系統問題、Agent規劃甚至是檢索問題（注意，不是檢索資料for LLM，而是檢索LLM for 資料）。

一些典型的例子有：

1. 人機客服切換：機器人客服無法解決問題的時候自動切換到更高級的客服，比如更智能的機器人，甚至人類；
2. 強弱LLM切換：比如困難問題給GPT4解決（費用貴），簡單問題給GPT3解決（費用低）

路由LLM具有很高的應用潛力和相容性，不同LLM都可以被加入到LLM候選Pool中參與routing（包括異構LLM，各種tuning/pretraining方法下得到的LLM，等等），而且可以發揮很強的性能。

比如最近UCB提出的Prompt-to-Leaderboard以很低的訓練成本，以路由LLM的範式下實現和需要數十萬個GPU訓練得到的Grok3相當的性能，並登上Arena排行榜第一。

然而當前路由LLM領域仍然存在一些挑戰影響了Router的發展：

1. 缺乏統一的benchmark。各個研究都在小範圍的建構各種的benchmark進行研究；
2. 當前benchmark不夠全面：當前的工作一般只涉及少量的LLM、evaluations，而且大多數是閉源不公開。

於是，研究團隊收集並整理且開源了涉及8567個不同LLMs在12個evaluations下2億條性能記錄，並通過這些記錄發現：

1. Model-level Scaling Up現象：有一定能力的Router，可以使得routing llm範式下的性能隨著llm pool的擴大而迅速上升。過去的研究由於涉及的不同LLM較少，不容易觀察到這個現象。
2. 通過這些資料，我們建構了全面的針對Router設計的評測RouterEval。其全面性可以大大幫助Router設計的探索。鑑於該測評已經整理良好且很簡潔，可以被看做是傳統的分類問題，所有研究者都可以以很少的計算消耗（甚至單卡或筆記型電腦）參與該大模型的研究當中。

利用2億條性能記錄，可以建構完美Router，即oracle Router ro：

接著，根據上式可以建構不同性能的Router ro(p)，其中wm為隨機Router，當p→1時，Router ro(p)越解決上界分類性能，當p→0時，ro(p)越接近隨機Router。

從上圖結果來看，隨著LLM候選的數量增加，不同的evaluation在具有一定能力的Router下呈現了Scaling Up現象。

而性能一般的Router，比如隨機Router則幾乎沒有Scaling Up現象。

且快速超過參考模型Ref. LLM的性能（參考模型一般是GPT4）。

另外團隊還可以發現兩個有趣的現象：

RouterEval涉及的LLM的參數分佈

1. 弱LLM也能組合出非常強的性能。上圖給出了RouterEval中涉及的LLM的參數分佈，LLM的參數為7B或以下的情況佔優。文章發現，即使較弱的LLM也可以組合出不錯的性能，比如5個性能在少於0.3的情況下，ro可以讓他們互補優勢在MMLU上達到0.95（超越GPT4）的性能。
2. 少量的LLM候選已經足夠。從Model-level Scaling Up現象示意圖可以看到3-10個LLM候選的時候已經可以達到非常不錯的性能。而且此時的部署成本並不高，具有很高的性價比。

當前Router的結果

通過測試當前的已有的Routers的性能，可以發現現在Router仍然有很大的提升空間。

不過幸運的是，RouterEval進行的Router設計的實驗不需要大量的計算資源，且可以融入不同的已有技術，包括few-show learning，資料增強、推薦系統、正則化方法、預訓練模型、額外資料等等.

因此Router將有希望快速得到實質性改進。

以及，和當前一些其他範式的區別和關係如下：

1. 推薦系統：Routing LLM其實是特殊的推薦系統，LLM的input是推薦系統中的user資訊，LLM候選是推薦系統中的商品item，而性能記錄則是推薦系統中的歷史使用者書記記錄；
2. LLM整合：一般LLM整合是post-decision，即讓多個LLM完成推理後再合併。而Routing LLM是pre-decision，即在LLM推理前就要決定是那個LLM來處理；
3. LLM Fusion：LLM融合主要針對是同質的LLM的“合作”，而Routing LLM可以讓“異質”（包括不開源）的LLM進行“合作”
4. Mixture-of-Experts (MoE): Routing LLM是model-level的MoE

當然，研究團隊也提出一些未來的挑戰。

首先就是缺乏資料。

要獲得足夠好的Router，當然的資料仍然遠遠不夠，因為這些性能記錄的資料一般不開源，且掌握在大公司手中，這需要全社區的共同努力。目前也可以通過演算法一定程度緩解資料缺乏的問題。

其次是如何保持在多LLM候選情況下的Router性能的問題。

當LLM候選越多的時候，意味著Router要進行更多類的分類，這對於Router的訓練來說具有很高的挑戰性；

除此之外，還包括RouterEval目前只關注在性能。

儘管routing llm可以考慮計算消耗、幻覺等其他目標。但是目前性能的水平還遠遠不夠，如果現在就過度關注其他目標的話，可能言辭尚早。另外，計算消耗和幻覺等目標的資料不容易蒐集，可能採集不到足夠多的LLM的記錄資料，仍然需要全社區的努力。

最後，就是部署的難度。

即使足夠強的Router可以獲得，但是此時LLM候選的部署可能是新的瓶頸，這在電腦系統等領域中也有很多的研究角度，如計算負載，高效分配、動態模型啟動等。幸運的是，從論文的觀察來看，3-10個LLM已經能得到出色的結果。

GitHub和論文等地址放下面了，感興趣的小夥伴可以深入研究一下哦~

程式碼地址：
https://github.com/MilkThink-Lab/RouterEval

論文地址:
https://arxiv.org/abs/2503.10657

論文合集：
https://github.com/MilkThink-Lab/Awesome-Routing-LLMs (量子位)