DeepSeek-V3 / R1 等模型采用大規模細粒度混合專家模型 (MoE) 架構，大幅提升了開源模型的質量。Llama 4 和 Qwen3 等新發布的開源模型的設計原則也采用了類似的大規模細粒度 MoE 架構。但大規模 MoE 模型為推理系統帶來了新的挑戰，如高顯存需求和專家間負載失衡等。

之前，我們介紹過突破 DeepSeek R1 模型低延遲極限的 TensorRT-LLM 優化措施，多 Token 預測 (MTP) 的實現與優化以及提高 DeepSeek R1 吞吐量性能的優化措施。

DeepSeek 團隊還分享了優化此類大規模專家并行 (EP) 模型 (如 DeepEP 和 EPLB) 的寶貴經驗與實踐。此外，DeepSeek 團隊在這份[1]技術報告中詳細闡述了具體設計考慮因素。除此之外，社區中也有在其他推理引擎中實現大規模 EP 的優秀實踐，例如 SGLang 團隊的這個項目[2]。

這篇技術博客共分為上中下三篇，將介紹支持 TensorRT-LLM 中端到端大規模 EP 的詳細設計與實現，主要包含以下內容：

如何使用 NVIDIA 多節點 NVLink (MNNVL) 硬件特性來實現高性能通信內核。

如何設計和實現在線專家負載均衡器，以動態平衡專家負載分布并適應在線流量模式的變化。我們將展示：

證明此類優化措施必要性的經驗數據分析。

在線流量數據統計模塊的實現。

復制和放置策略的設計與實現。

用于平衡多個 GPU 間在線工作負載的 MoE 權重負載和重新分配器。

為適應專家負載均衡器需求而對 MoE 路由器和計算模塊進行的必要修改。

一些證明當前 TensorRT-LLM 中實現效果的初步數據。

未來的技術博客還將涵蓋以下主題：

對 TensorRT-LLM 大規模 EP 實現的性能調優和優化的介紹。

如何在不使用 MNNVL 的情況下，為 Hopper 和其他 NVIDIA GPU 實現高效的大規模 EP 支持。

使用大規模 EP 并獲得性能提升的最佳實踐。

如何將大規模 EP 與其他系統優化技術相結合。

雖然本技術博客主要討論 TensorRT-LLM，但我們相信其核心理念和實現方法也可用于其他推理引擎在 NVIDIA GPU 上的推理性能。此外，我們希望借助社區的力量，探索如何更好地將當前 TensorRT-LLM 大規模 EP 實現模塊化，使其更容易被社區復用。

最后，本博客包含針對 Grace Blackwell 機架式系統的詳細實現方式，例如使用 Grace Blackwell 機架式系統跨 GPU 連接的通信組件，以及使用 Grace CPU 與 Blackwell GPU 間高帶寬 C2C 連接的 MoE 權重加載和重新分配模塊等。但整體設計原則和軟件架構仍適用于非此 NVIDIA GPU 系統。為了便于擴展到其他非此系統，我們有意識地關注了設計和實現的通用性。這些更改應能與現有其他組件輕松組合。

引入大規模 EP 的初衷

引入大規模 EP（本文中指 EP > 8）主要基于以下系統考量：

我們希望通過提高聚合顯存帶寬來加載專家權重，從而降低執行延遲。

我們希望通過增加有效批處理大小充分利用 GPU 算力。

需注意，當端到端 (E2E) 執行時間主要由 MoE GroupGEMM 計算主導時，引入大規模 EP 可顯著提升性能。但若端到端執行時間未被 MoE GroupGEMM 計算主導，引入大規模 EP 提升的性能有限。

系統設計中不存在“免費的午餐”。當 EP 規模增大到超過 8（有時甚至不到 8）時，由于 MoE 模型的稀疏執行特性，會自動觸發 EP 級別的負載失衡問題。

以下是一些基于特定數據集的經驗觀察（所有分析均使用DeepSeek R1 模型在32 個 GPU上進行）：

對一個機器翻譯數據集的觀察結果

首先，我們將概述各層的整體失衡問題：

圖 1. 從 rank 0 發送到所有 rank（包括 rank 0）的 Token 數（對應解碼迭代 1950）及所有 MoE 層

如圖 1 所示，在第 36 層的 MoE 中，從rank 0 發送到 rank 13的 Token 數明顯更多。

如果我們放大第 36 層的 MoE 并記錄其激活專家 rank 的分布，可以清楚地看到有一個 rank 被更頻繁地激活：

圖 2. 第 36 層每個專家 rank 接收的 Token 數量

如果我們將數據展平以查看每個專家接收的 Token 數量，可以發現有一些專家比其他專家更活躍：

圖 3. 第 36 層每個專家接收的 Token 數量

值得注意的是，這種失衡問題在多次迭代中非常穩定，如下圖所示：

圖 4. 第 36 層每個專家在 50 個解碼步驟內接收的 Token 總數，本地 batch size=256。

顯然，圖 4 中的熱門專家與圖 3 中僅包含單次解碼迭代數據的專家相同。我們還對本地 batch size=1（對應單次請求）進行了基于持續時間的分析，觀察到類似的模式：

圖 5. 第 36 層每個專家在 400 次解碼迭代內接收的 Token 總數，本地 batch size=1。

綜上所述，針對該機器翻譯數據集的研究結果可總結為：

某些層中存在一些熱點，部分 EP 所在 GPU 的負載可能遠高于其他 EP。

其原因可能是最熱門專家或多個熱門專家位于同一 rank。

路由 Token 的分布可能在數十至數百個迭代步驟甚至更多迭代步驟內保持一致。

在單個請求的執行中，不同迭代步之間也存在相同的熱門專家。

另一個實際問題是上述觀察結果在其他數據集上是否會發生顯著變化。因此，我們對 GSM8K 數據集進行了類似的分析。

對 GSM8K 數據集的觀察結果

圖 6. 從 rank 0 發送到所有 rank 的 Token 數（對應第 1950 個迭代步）及所有 MoE 層

如圖 6 所示，與圖 1 相比，GSM8K 數據集中的熱門層變成了第 57 層而非第 36 層。那么 GSM8K 數據集中第 36 層的具體情況如何？

圖 7. 從 EP rank 0 發送到其他 EP rank 的 Token 數（仍以迭代 1950、MoE 第 36 層為例）

從圖 7 可以清楚地看到，工作負載失衡于不同數據集（圖 2 所示）中觀察到的情況不同。在圖 8 中可以觀察到在 GSM8K 數據集上，工作負載的失衡在多次迭代中也相對穩定。這與之前的機器翻譯數據集相同。

圖 8. 從 EP rank 0 發送到所有 rank 的 Token 總數（MoE 第 57 層，50 個解碼步驟內，本地 batch size=256）

如果我們將每個 GPU EP 層面的數據展平為專家層面，可以得到下圖。

圖 9. 第 57 層的每個專家在 50 個解碼步驟內接收的 Token 總數，本地 batch size=256

單個請求中也存在類似的失衡模式。

圖 10. 單次請求下第 57 層的每個專家在 400 個解碼步驟內接收的 Token 總數

如果使用另一個請求，我們仍然可以觀察到專家失衡問題。雖然熱門專家可能不同，但有一些是共同的（在此示例中是專家 10）。

圖 11. 單次請求下第 57 層每個專家在 400 個解碼步驟內接收的 Token 總數

通過對兩個數據集的數據分析，我們得出以下結論：

EP 級別工作負載失衡問題在多個數據集的大規模 EP 推理中較為常見。且 EP 失衡的嚴重程度可能因層而異。此外，EP 失衡的問題具有數據集敏感性。

EP rank 級別失衡問題可能由某個最熱門的專家或多個熱門專家長期占據同一 EP rank 引起。

EP rank 失衡分布在數十到數百次迭代中相對穩定。

盡管 EP rank 失衡分布在時間維度上具有穩定性，但不同請求的 EP 失衡分布可能有所不同。

這些發現可指導我們對 TensorRT-LLM 大規模 EP 實現的設計考量：

設計時需考慮 EP 失衡問題以確保端到端的性能。

基于實時在線請求流量的在線 EP 負載均衡器（而非僅實現離線 EP 負載均衡器）對確保 EP 均衡器的穩健性至關重要。

可運用 EP rank 失衡分布的時間維度穩定性，以高效的方式將 MoE 權重重新分配至不同 EP rank。

在下一篇文章中，我們將深入探討 TensorRT-LLM 大規模 EP 的整體實現架構、負載均衡策略與性能優化實踐。

引用

[1]DeepSeek-V3 技術報告:

https://arxiv.org/abs/2412.19437

[2]SGLang團隊項目：

https://lmsys.org/blog/2025-05-05-large-scale-ep/

作者

楊東旭

現任職于 NVIDIA Compute Arch 部門。主要負責 LLM 推理系統的開發和性能優化。加入 NVIDIA 之前，曾從事搜索系統的 GPU 加速和開發工作。

喬顯杰

NVIDIA Compute Arch 部門高級架構師，主要負責 LLM 推理的性能評估和優化。加入 NVIDIA 之前，他曾從事推薦系統的 GPU 加速研發工作。

謝開宇

NVIDIA Compute Arch 部門高級架構師，主要負責 TensorRT-LLM 項目的開發，專注在系統性能和優化工作。

朱恩偉

NVIDIA DevTech 部門高級工程師，主要負責 TensorRT-LLM 項目的開發和性能優化。

陳曉明

NVIDIA Compute Arch 部門的首席架構師和高級經理，對深度學習模型的算法軟硬件協同設計感興趣，最近從事大語言模型推理的性能建模、分析和優化。