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

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

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

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

如何使用 NVIDIA 多節(jié)點 NVLink (MNNVL) 硬件特性來實現(xiàn)高性能通信內(nèi)核。

如何設(shè)計和實現(xiàn)在線專家負載均衡器，以動態(tài)平衡專家負載分布并適應(yīng)在線流量模式的變化。我們將展示：

證明此類優(yōu)化措施必要性的經(jīng)驗數(shù)據(jù)分析。

在線流量數(shù)據(jù)統(tǒng)計模塊的實現(xiàn)。

復(fù)制和放置策略的設(shè)計與實現(xiàn)。

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

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

一些證明當前 TensorRT-LLM 中實現(xiàn)效果的初步數(shù)據(jù)。

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

對 TensorRT-LLM 大規(guī)模 EP 實現(xiàn)的性能調(diào)優(yōu)和優(yōu)化的介紹。

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

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

如何將大規(guī)模 EP 與其他系統(tǒng)優(yōu)化技術(shù)相結(jié)合。

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

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

引入大規(guī)模 EP 的初衷

引入大規(guī)模 EP（本文中指 EP > 8）主要基于以下系統(tǒng)考量：

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

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

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

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

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

對一個機器翻譯數(shù)據(jù)集的觀察結(jié)果

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

圖 1. 從 rank 0 發(fā)送到所有 rank（包括 rank 0）的 Token 數(shù)（對應(yīng)解碼迭代 1950）及所有 MoE 層

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

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

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

如果我們將數(shù)據(jù)展平以查看每個專家接收的 Token 數(shù)量，可以發(fā)現(xiàn)有一些專家比其他專家更活躍：

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

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

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

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

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

綜上所述，針對該機器翻譯數(shù)據(jù)集的研究結(jié)果可總結(jié)為：

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

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

路由 Token 的分布可能在數(shù)十至數(shù)百個迭代步驟甚至更多迭代步驟內(nèi)保持一致。

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

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

對 GSM8K 數(shù)據(jù)集的觀察結(jié)果

圖 6. 從 rank 0 發(fā)送到所有 rank 的 Token 數(shù)（對應(yīng)第 1950 個迭代步）及所有 MoE 層

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

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

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

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

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

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

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

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

如果使用另一個請求，我們?nèi)匀豢梢杂^察到專家失衡問題。雖然熱門專家可能不同，但有一些是共同的（在此示例中是專家 10）。

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

通過對兩個數(shù)據(jù)集的數(shù)據(jù)分析，我們得出以下結(jié)論：

EP 級別工作負載失衡問題在多個數(shù)據(jù)集的大規(guī)模 EP 推理中較為常見。且 EP 失衡的嚴重程度可能因?qū)佣悺４送?，EP 失衡的問題具有數(shù)據(jù)集敏感性。

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

EP rank 失衡分布在數(shù)十到數(shù)百次迭代中相對穩(wěn)定。

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

這些發(fā)現(xiàn)可指導(dǎo)我們對 TensorRT-LLM 大規(guī)模 EP 實現(xiàn)的設(shè)計考量：

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

基于實時在線請求流量的在線 EP 負載均衡器（而非僅實現(xiàn)離線 EP 負載均衡器）對確保 EP 均衡器的穩(wěn)健性至關(guān)重要。

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

在下一篇文章中，我們將深入探討 TensorRT-LLM 大規(guī)模 EP 的整體實現(xiàn)架構(gòu)、負載均衡策略與性能優(yōu)化實踐。

引用

[1]DeepSeek-V3 技術(shù)報告:

https://arxiv.org/abs/2412.19437

[2]SGLang團隊項目：

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

作者

楊東旭

現(xiàn)任職于 NVIDIA Compute Arch 部門。主要負責 LLM 推理系統(tǒng)的開發(fā)和性能優(yōu)化。加入 NVIDIA 之前，曾從事搜索系統(tǒng)的 GPU 加速和開發(fā)工作。

喬顯杰

NVIDIA Compute Arch 部門高級架構(gòu)師，主要負責 LLM 推理的性能評估和優(yōu)化。加入 NVIDIA 之前，他曾從事推薦系統(tǒng)的 GPU 加速研發(fā)工作。

謝開宇

NVIDIA Compute Arch 部門高級架構(gòu)師，主要負責 TensorRT-LLM 項目的開發(fā)，專注在系統(tǒng)性能和優(yōu)化工作。

朱恩偉

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

陳曉明

NVIDIA Compute Arch 部門的首席架構(gòu)師和高級經(jīng)理，對深度學(xué)習(xí)模型的算法軟硬件協(xié)同設(shè)計感興趣，最近從事大語言模型推理的性能建模、分析和優(yōu)化。