MoE 路由不是省錢開關：為什麼專家模型最怕負載不均

MoE 模型看起來像一個很直接的優化：一次請求只激活少數幾個專家，於是參數規模變大，計算量卻不按同樣比例上漲。但真正上線時，MoE 的難點通常不在「有多少專家」，而在「誰來決定每個 token 去哪裡」。

這個決定由 router 完成。它會給每個 token 計算一個分數，再把 token 分配給一個或多個專家。理想情況下，專家之間的負載接近均勻，GPU 之間的數據移動可控，延遲曲線也比較平滑。現實中，如果某幾個專家被反覆選中，系統會立刻出現排隊、跨卡通信增加、尾延遲抬高等問題。

所以 MoE 路由首先是一個系統工程問題。模型訓練時常會加入 load balancing loss，讓 router 不要把所有 token 都推向少數專家。推理服務側還要設置 capacity factor，限制單個專家最多接收多少 token。容量太緊，會丟 token 或退化到備用路徑；容量太鬆，又會浪費顯存和調度空間。

第二個問題是 batch 內部的形狀變化。普通 dense 模型裡，每層計算比較規則；MoE 層則要把 token 按專家重新分組，執行專家計算，再把結果還原到原來的順序。這個過程帶來額外的 all-to-all 通信。模型越大、專家越分散，通信開銷越容易吃掉「只激活少數專家」帶來的收益。

第三個問題是熱點輸入。不同業務流量會讓 router 呈現不同偏好。代碼請求、數學請求、閒聊請求，可能天然偏向不同專家。如果線上流量結構突然變化，原本平衡的專家分佈也會變形。因此 MoE 服務不能只看平均 tokens/s，還要看每個專家的 token 分佈、溢出率、尾延遲和跨卡通信時間。

對應用團隊來說，MoE 的正確使用方式不是把它當作「更便宜的大模型」。更穩妥的做法是把它當作一個需要觀測和容量規劃的叢集系統：先用真實請求重放測路由分佈，再決定 batch 策略、專家並行方式和降級路徑。

如果沒有這些指標，MoE 很容易出現一種誤判：離線 benchmark 很漂亮，線上到高峰就抖。不是模型突然變差，而是 router 把某些專家變成了瓶頸。

MoE 的價值是真實的。它讓大參數量模型在可接受成本下運行。但它不是免費的魔法。router、負載均衡、通信拓撲和容量控制，才是 MoE 能不能穩定落地的關鍵。