一、背景

DeepSeek 是一個備受贊譽的開源大型語言模型 (LLM)，以其強大的性能而聞名。然而，其龐大的規模和獨特的架構給高效部署帶來了挑戰。本文詳細介紹了 LMSYS 團隊如何通過創新的并行策略和優化技術，在 96 個 NVIDIA H100 GPU 上成功部署 DeepSeek 模型，實現了每節點每秒 52.3k 輸入詞元和 22.3k 輸出詞元的高吞吐量。

"SGLang 現已支持預填充 - 解碼 (PD) 分解和大規模專家并行，包括 DeepEP、DeepGEMM 和 EPLB 的全部功能。"

DeepSeek-V3 模型采用了混合專家 (MoE) 架構，這種設計雖然能夠提高模型能力，但也帶來了工作負載不平衡和內存使用效率等問題，尤其是在大規模部署環境中。本研究通過一系列創新技術解決了這些挑戰。

二、方法 2.1 并行設計策略

DeepSeek 的高效部署需要精心設計的并行策略來管理計算復雜性和內存需求。研究團隊針對模型的四個關鍵組件采用了不同的并行方法：

注意力層

DeepSeek 使用多頭潛在注意力 (MLA) 來有效建模輸入序列中的復雜依賴關系。為優化這一機制，團隊實現了 DP 注意力，這是一種數據并行策略，能夠消除設備間 KV 緩存的重復，顯著減少內存開銷。

"DP 注意力是一種數據并行策略，能夠消除設備間 KV 緩存的重復，顯著減少內存開銷。"

盡管 DeepSeek-V3 僅使用三個密集 FFN 層，但其計算量仍可能顯著增加峰值內存使用，如果不小心管理，可能導致系統崩潰。為解決這一問題，團隊采用了數據并行 (DP) 而非張量并行 (TP)，主要基于以下優勢：

• 增強可擴展性：DeepSeek-V3 的中間維度為 18,432，高 TP 度數（如 TP32）會導致低效的小單元分段，不利于現代 GPU 的內存對齊。

• 優化內存效率：在 DP 注意力下，較低的 TP 度數可以最小化每個設備的內存使用。

• 最小化通信開銷：純 TP 中，每個 FFN 需要兩次全歸約操作，而 DP 可以將通信成本降低 50%。

在 DeepSeek-V3 的混合專家 (MoE) 架構中，稀疏 FFN 需要大量專家權重，造成顯著的內存瓶頸。為此，團隊實現了專家并行 (EP)，將專家權重分布在多個設備上，有效擴展內存容量同時保持高性能。

圖 1: 并行設計示意圖

并行設計示意圖：左側顯示 DP 注意力和 DP 密集 FFN 的集成，右側展示了基于 DeepEP 框架的 EP 實現

語言模型頭 (LM Head)

LM 頭計算大型詞匯表上的輸出概率，這是一個資源密集型操作。團隊采用了數據并行 (DP) 策略，與密集 FFN 策略相似，減少了內存開銷并簡化了設備間通信。

2.2 預填充和解碼分解 (PD Disaggregation)

LLM 推理包含兩個截然不同的階段：預填充 (Prefill) 和解碼 (Decode)。預填充階段計算密集，處理整個輸入序列；而解碼階段內存密集，管理詞元生成的 KV 緩存。傳統上，這兩個階段在統一引擎中處理，但這種方法存在三個主要問題：

1. 預填充中斷：傳入的預填充批次經常中斷正在進行的解碼批次，導致詞元生成顯著延遲。

2. DP 注意力不平衡：在 DP 注意力中，一個 DP 工作器可能同時處理預填充批次，而另一個處理解碼批次，導致解碼延遲增加。

3. 與 DeepEP 不兼容：DeepEP 為預填充和解碼執行不同的調度模式，使統一調度與 DeepEP 不兼容。

PD 分解設計圖：展示了預填充服務器和解碼服務器之間的交互流程

為解決這些問題，團隊引入了 PD 分解，將兩個階段分離，實現針對每個階段的定制優化。實現細節包括：

• 非阻塞傳輸：數據發送和接收操作在后臺線程中運行，保持調度器的事件循環不中斷。

• 基于 RDMA 的傳輸：遠程直接內存訪問 (RDMA) 利用隊列對進行連接，使用分散 - 聚集元素 (SGE) 高效傳輸非連續內存塊。

• 靈活的 API 集成：SGLang 提供適應性 API，集成高性能 RDMA 庫如 Mooncake 和 NIXL，簡化數據傳輸。

DeepEP[1]是 DeepSeek 團隊實現的通信庫，旨在簡化 MoE 模型中的 EP。它提供兩種專門的調度模式：

• 普通調度：針對處理長輸入序列（如預填充階段）優化，優先考慮最大計算吞吐量。

• 低延遲調度：為解碼階段生成輸出詞元定制，優先考慮最小延遲以確保實時性能。

DeepGEMM[2]是另一個高效庫，專為優化 MoE 模型中的計算而設計，提供兩種專門函數：

• 分組 GEMM（連續布局）：為動態輸入形狀設計，適用于 MoE 推理的預填充階段。

• 分組 GEMM（掩碼布局）：假設固定輸入形狀，使用掩碼張量僅計算輸入的有效部分，兼容 CUDA Graph。

在多節點環境中，有限的通信帶寬可能顯著增加整體延遲。為解決這一挑戰，團隊實現了兩批次重疊 (TBO)，將單個批次分為兩個微批次，允許計算和通信重疊，同時通過將有效批次大小減半來降低峰值內存使用。

圖 3: 預填充階段的 TBO 實現

預填充階段的 TBO 實現：通過優化啟動順序避免 CPU 阻塞

實現 TBO 面臨兩個主要挑戰：

1. 代碼復雜性：直接編碼 TBO 可能導致管理多個微批次的邏輯重復。

2. 預填充階段的同步問題：DeepEP 中的普通調度會阻塞 CPU，可能使 GPU 閑置。

為創建更易維護和可重用的代碼庫，團隊使用了由操作和產出點組成的抽象層，簡化了開發過程。

專家并行負載均衡器 (EPLB)

在 MoE 模型中，EP 經常導致 GPU 間工作負載分布不均。這種不平衡迫使系統等待最慢的 GPU 計算或通信，浪費計算周期并增加內存使用。隨著 GPU 數量（EP 大小）增加，不平衡問題變得更加嚴重。

圖 4: EPLB 模擬結果

模擬顯示了規模和 EPLB 算法對不平衡問題的影響

為解決這一問題，DeepSeek 開發了專家并行負載均衡器 (EPLB)[3]。EPLB 接收專家分布統計作為輸入，計算專家的最佳排列以最小化不平衡。用戶可以分配冗余專家，這些專家與原始專家一起創建一個專家池，允許 EPLB 戰略性地放置或復制專家。

三、實驗與結果 3.1 端到端性能

團隊在由 12 個節點組成的集群上評估了 SGLang 使用 DeepSeek-V3 的端到端性能，每個節點配備 8 個 H100 GPU，通過 InfiniBand 連接。評估比較了四種設置：

1. SGLang 與 TP16 x 6

2. SGLang 與 PD 分解

3. SGLang 與 PD 分解和模擬 MTP

4. DeepSeek 官方配置文件結果

預填充和解碼階段的端到端性能：左圖顯示預填充階段在 4 個節點上的性能，右圖顯示解碼階段在 9 個節點上的性能

圖 6: 預填充階段內核執行時間

預填充階段的內核執行時間細分：包括默認 EPLB、模擬完美 EPLB 和單元測試結果的比較

3.2 詳細性能分析

團隊將 SGLang 的性能與 DeepSeek 的推理系統進行了比較，盡可能使實驗設置與 DeepSeek 的生產環境保持一致。

圖 7: 解碼階段內核執行時間

解碼階段的內核執行時間細分：顯示了 SGLang 與 DeepSeek 在解碼階段的內核性能比較

圖 8: TBO 總體性能

TBO 在不同場景下的性能影響：左圖顯示預填充階段，右圖顯示解碼階段

關鍵觀察包括：

• 默認 EPLB：通信內核相比 DeepSeek 的配置文件表現出更長的執行時間和更高的方差，可能是由于更大的專家不平衡。

• 模擬完美 EPLB：這種設置與 DeepSeek 的配置文件更為接近，盡管仍存在差異，表明潛在的優化領域。

• 與單元測試的比較：DeepSeek 和 SGLang 的通信時間都比單元測試結果慢，而后者在禁用 TBO 時可實現，揭示了通信是瓶頸時的潛在優化方向。

TBO 在預填充階段提供兩個顯著優勢：

1. 支持更大的批次大小：在普通配置中，每個設備最多處理 8,192 個詞元，而 TBO 通過優化內存使用，使推理批次大小高達 16,384 個詞元。

2. 增強吞吐量：通過重疊計算和通信，TBO 實現了 27% 至 35% 的吞吐量增加。

預填充階段 TBO 性能細分：比較了不同配置下各個內核的執行時間

圖 10: 解碼階段 TBO 性能細分

解碼階段 TBO 性能細分：分析了三種不同配置下的性能表現

3.4 消融研究：EPLB

EPLB 對系統性能的影響通過總體吞吐量分析和詳細案例研究進行了評估。

圖 11: EPLB 對吞吐量的影響

EPLB 對大規模設置吞吐量的影響：EPLB 提供了 1.49 倍 (預填充) 和 2.54 倍 (解碼) 的顯著加速

圖 12: 工作負載不平衡與吞吐量關系

工作負載不平衡與總體吞吐量的關系案例研究：顯示了平衡度與吞吐量之間的強相關性

結果顯示平衡度與吞吐量之間存在強相關性，強調維持高平衡度對最佳性能的重要性。

四、討論與應用 4.1 工具包

SGLang 還包括兩個重要工具，以支持高效的大規模部署：

一次性張量 (Disposable Tensor)

PyTorch 中的內存管理可能因持久對象引用而變得具有挑戰性，尤其是在 GPU 密集型工作流中，CUDA 內存是稀缺資源。SGLang 通過 DisposableTensor 類解決了這一問題，該類引入了 dispose() 方法來顯式且立即釋放張量的內存，繞過了 Python 的引用計數限制。

def ffn(hidden_state: torch.Tensor, linear1: nn.Linear, linear2: nn.Linear):     intermediate_state = linear1(hidden_state)     hidden_state.dispose()  # 立即釋放 CUDA 內存     return linear2(nn.ReLU(intermediate_state)) # 將張量包裝在 DisposableTensor 中 hidden_state = DisposableTensor(hidden_state) hidden_state = ffn(hidden_state, linear1, linear2)

SGLang 還包括用于分析和模擬 MoE 模型中專家工作負載分布的工具集。此功能使用戶能夠：

• 轉儲專家工作負載統計：提取累積統計數據或每批次工作負載數據。

• 模擬專家利用率：在不需要昂貴硬件或重復試驗的情況下，模擬各種配置下的專家平衡。

雖然 SGLang 在 DeepSeek-V3 推理方面取得了顯著的吞吐量改進，但仍存在幾個局限性和未來增強領域：

1. 延遲優化：當前對吞吐量的關注使首詞延遲 (TTFT) 保持在 2-5 秒，詞元間延遲 (ITL) 約為 100 毫秒，需要進一步優化以用于實時應用場景。

2. 序列長度限制：由于使用 96 個 GPU，限制了處理較短序列。擴展 GPU 資源將支持更長序列，這對特定應用至關重要。

3. 多詞元預測 (MTP) 集成：SGLang 支持 MTP 但缺乏與 DP 注意力的完全集成，降低了混合并行配置中的效率。

4. EPLB 分布：本研究中的實驗利用了分布內數據進行專家并行負載均衡，可能無法反映真實世界的變異性。

5. 靈活的張量并行 (TP) 大小：對于 DeepSeek-V3，密集 FFN 的內存最優 TP 大小較小但大于 1。目前，SGLang 僅支持純 TP 或 DP，導致次優的內存使用。

6. Blackwell 支持：目前，實現僅支持 NVIDIA Hopper 架構，團隊正積極擴展對下一代 Blackwell 架構的兼容性。

通過利用 PD 分解、EP 和精心設計的并行策略，研究團隊在 SGLang 中成功復制了 DeepSeek 的推理框架，并取得了卓越的性能。這項開源工作——實現每節點每秒 52.3k 輸入詞元和 22.3k 輸出詞元的吞吐量——展示了 SGLang 在大規模 LLM 推理方面的強大能力。

"通過利用 PD 分解、EP 和精心設計的并行策略，我們在 SGLang 中以卓越的性能復制了 DeepSeek 的推理框架。"

這些創新技術不僅提高了 DeepSeek 模型的部署效率，還為其他大型語言模型的高效部署提供了寶貴經驗。研究團隊邀請社區探索、復制和擴展這項工作，以推動高效 AI 部署的邊界。

參考資料

[0] 原文：https://lmsys.org/blog/2025-05-05-large-scale-ep/

DeepEP: https://github.com/deepseek-ai/DeepEP

DeepGEMM: https://github.com/deepseek-ai/DeepGEMM

專家并行負載均衡器 (EPLB): https://github.com/deepseek-ai/EPLB