透過多節點 DeepSeek 部署實現更低延遲與更高吞吐量

在大多數系統中，延遲與吞吐量通常是互相衝突的目標，在設計和部署過程中需要權衡。例如，在龐大的大型語言模型中，增加批次大小可以提高吞吐量，但同時也會增加延遲；在單一機器內增加張量平行度可以減少延遲，但會減少副本數量，進而導致吞吐量降低。

像 DeepSeek-V3/R1 這樣的高效混合專家（MoE）模型最近展現出優秀的模型能力和營運效率。例如，DeepSeek-V3/R1 模型總共有 671B 參數，但在推論期間每個 Token 僅使用 37B 參數。這種模型架構為推論系統帶來了挑戰與機遇。

本文表明，與傳統系統相反，像 DeepSeek-V3/R1 這樣的 MoE 模型在大多數情況下，透過在多節點部署中使用更多 GPU，可以同時實現更高的吞吐量和更低的延遲。

由於模型擁有大量的小型專家，部署必須分散到多個裝置上。我們同時考慮了在配備 8xH200 GPU 的單一節點上進行單一節點部署，以及在配備 8xH100 GPU 的多節點部署。

兩種部署架構均利用資料平行處理，並透過我們的內部請求排程器進行協調。資料平行處理的實作涉及啟動多個推論引擎實例，每個實例獨立運作以服務和維護請求。透過 GRPC 與引擎互動的請求排程器負責盡可能平均地分發請求，同時促進 KV 快取重複使用，將具有部分匹配字首的請求傳送至包含快取的伺服器。引擎實例不會跨越多個節點。它們可以選擇性地使用張量平行度跨多個裝置進行注意力分片。這些實例在單一節點的情況下透過 NVLink 互連，或在多節點的情況下透過 InfiniBand 互連，以分發和收集專家。

單一節點部署組態在小批次大小下提供優異的延遲；然而，在負載增加的情況下，效能會迅速下降。

為了部署服務引擎，我們為每個託管多個引擎實例的節點啟動一個 Pod。PyTorch 負責設定分散式通訊並協商 NVSHMEM 初始化。在通訊方面，我們依賴先前部落格文章中所述的自訂 CUDA 核心。這兩種部署的實作幾乎完全相同，模型會根據實作專家平行度的 Fabric 選擇要使用的正確核心。

在深入探討我們的效能比較之前，必須先了解使部署如 DeepSeek-V3/R1 這類龐大 MoE 模型成為可能的關鍵平行化策略。

在 LLM 推論中，張量平行度（TP）通常用於減少每個 GPU 的記憶體使用量和運算量，從而降低延遲。通常，我們可以沿著列或欄維度對注意力層和 MLP 層中的 Linear 投影進行分片，並沿著注意力頭維度對注意力運作進行分片。

透過 TP，Llama-3 架構在各個 GPU 之間對 Linear 投影和注意力運作沒有重複的運算，這是一種理想的分片方法。然而，在 DeepSeek-V3/R1 模型中，TP 無法實現這一點。

DeepSeek-V3/R1 模型使用多頭潛伏注意力（MLA）。MLA 層首先使用 Linear 投影 kv_a_proj 來計算潛在向量，然後使用另一個 Linear 投影 kv_b_proj 將其轉換到每個注意力頭的空間中。由於所有注意力頭共用相同的潛在向量，TP 無法對潛在向量進行分片，因此所有 TP Rank 都需要複製 kv_a_proj 和 kv_b_proj 的參數和運算。同樣地，由於 MLA 將潛在向量儲存在 KV 快取中，每個 TP Rank 都會儲存一份相同的 KV 快取複本。

儘管 MLA 中存在一些重複，張量平行度仍可部分減少運算需求，使其對於需要高輸出速度的場景至關重要。

DeepSeek-V3/R1 模型將 MLP 層替換為 MoE 層。一個 MoE 層有 256 個路由專家和 1 個共用專家。每個 Token 會被分發給 8 個不同的路由專家進行運算，並對結果進行加權求和。每個 Token 也會在共用專家中進行運算，其結果會與來自路由專家的結果相加。

專家平行度（EP）作為 MoE 層的典型分片方法，每個 GPU 管理 256 / EP 個路由專家，同時保留共用專家的複本。與 TP 相比，EP 的優勢在於它可以將運算分發到更多 GPU 上，從而減少每個 GPU 的運算和記憶體使用量。

在執行專家運算之前，所有 GPU 都需要執行 AllToAll 通訊，以將 Token 分發到相應專家所在的 GPU；在專家運算之後，需要另一次 AllToAll 通訊來收集來自各個 GPU 的運算結果並執行加權求和。我們使用 NVSHMEM 實作了這兩個 AllToAll 通訊核心（Dispatch 和 Combine）的最佳化版本。在我們先前的部落格文章中，我們詳細介紹了其實作，且我們的核心已在 GitHub 上開源。

透過 EP，我們可以將 MoE 運算分發到 128 個甚至更多 GPU 上。然而，MLA 運算無法透過 EP 進行分割。此時，我們可以引入資料平行處理（DP）。每個 DP 群組都擁有 MLA 層的完整複本。每個 DP 群組接受不同的輸入並獨立執行 MLA 層運算。

MLA 層的 DP 和 TP 可以結合，一個 DP 群組可以被分割成多個 TP Rank。MoE 層的 EP 可以與 MLA 層的 DP/TP 結合。EP = DP * TP。例如，在 16 部機器上，EP128 DP32 TP4 意味著將路由專家分發到 128 個 GPU 上，每 4 個 GPU 形成一個 DP 群組，總共有 32 個獨立的 DP 群組。

DeepSeek 的 671B 參數超過了單台 8-GPU H100 機器（80 GB * 8）的記憶體容量，但單台 8-GPU H200 機器可以完全容納整個模型（141 GB * 8）。使用 EP8 DP8 TP1 組態時，模型每個 GPU 使用約 100 GB 記憶體，大約留下 40 GB 給 KV 快取和其他中間結果。一個 Token 佔用 70,272 位元組的 KV 快取。假設每個請求有 5,000 個 Token，每個 GPU 大約可以容納 100 個請求。

我們希望了解在不同組態下，單一節點與多節點部署之間的效能差異。我們使用了一台 H200 機器進行單一節點部署，以及最多 16 台 H100 機器進行多節點部署。對於每個部署環境，我們使用了 TP 1、2、4、8 的組合，以及每個 GPU 批次大小為 1、2、4、8、16、32、64、128 的組合。我們假設每個請求的 KV 快取長度為 5,000 個 Token。我們還假設多 Token 預測（MTP）預測額外 1 個 Token（即每個請求的查詢長度為 2），並保守假設接受率为 60%。下圖顯示了不同組態的吞吐量和輸出速度。

水平軸表示每個請求以 tokens/s 為單位的輸出速度。垂直軸使用對數刻度來顯示每台機器以 tokens/s 為單位的吞吐量。我們用不同顏色的線條標記了每個 EP 組態的柏拉圖邊界（Pareto Frontier）。

在對輸出速度要求極高的場景中，使用批次大小為 1 的單一節點 EP8 DP1 TP8 可以達到超過 100 tokens/s 的輸出速度，但吞吐量極低，相當於輸出速度。在此場景中，整個批次只有 2 個 Token，最多只能分發到 2*8=16 個專家，最多啟動總共 57B 參數。

在 80-40 tokens/s 的輸出速度範圍內，隨著吞吐量增加，輸出速度會顯著下降。相比之下，在相同的輸出速度下，EP128 的吞吐量比單一節點部署高出約 5 倍。

這種現象可以透過檢視單一節點部署的行為來解釋：增加批次大小直接與啟動專家的增加相關。當批次大小為 1 時，每個 GPU 平均啟動的專家數量為 2 * 8 / 8 = 2。當批次夠大時，所有專家都會被啟動，這意味著每個 GPU 會啟動 256 / 8 = 32 個專家。啟動更多專家意味著 GPU 需要從記憶體中讀取更多參數，從而顯著增加記憶體頻寬壓力。由於大型語言模型的解碼階段已經受到記憶體頻寬而非運算效能的瓶頸限制，因此在單一節點部署中增加批次大小會顯著降低輸出速度。

比較四種多節點部署組態（EP16、EP32、EP64 和 EP128）顯示，較高的 EP 值會將柏拉圖邊界推向同時提升吞吐量和輸出速度的方向。

使用較高的 EP 數字意味著每個 GPU 被分配到較少的專家。例如，EP128 意味著每個 GPU 負責 256 / 128 = 2 個專家，因此記憶體頻寬壓力顯著降低。換句話說，透過使用較大的 EP 數字，我們有效地獲得了更多的記憶體頻寬。當每個 GPU 的批次大小小於 64 時，增加批次大小不會顯著影響專家運算速度，因為增加輸入數量不會顯著增加記憶體頻寬壓力。因此，我們觀察到當使用 EP128 時，增加批次大小不會對輸出速度產生那麼顯著的影響。

有趣的是，在較大的批次大小（每個 GPU 64 個請求）下，我們觀察到一個新現象：單一節點部署的吞吐量略高於多節點部署。部分原因是節點內的 NVLink 具有比節點間 InfiniBand 更高的頻寬。另一部分是由於我們實作中的限制。我們稍後將更詳細地分析此現象。

由於記憶體容量的限制，EP8 DP8 TP1 組態無法達到每個 GPU 128 的批次大小，因此在追求更高吞吐量的場景中，多節點部署仍然是更好的選擇。

正如上面簡要介紹的關於專家平行度，GPU 在 MoE 層通訊期間處於閒置狀態。為了減少浪費並降低延遲，我們需要尋找資料獨立的運算任務來填補這段閒置時間。

上圖的上半部分顯示了單一層的運算流程。MoE 運算依賴於 Dispatch，下一層的運算則依賴於 Combine 的結果。

我們將共用專家放置在每個 GPU 上。這樣一來，共用專家運算就不需要 AllToAll 通訊。因此，我們可以在 Dispatch Send 完成後立即執行共用專家運算，然後等待 Dispatch Recv 完成。我們將此重疊方案稱為「Dispatch Overlap」。

Dispatch Overlap 提供簡單直接的實作和廣泛的適用性。這項技術隱藏了所有 EP 大小和批次大小下的共用專家運算時間。

為了進一步提高運算與通訊的重疊度，我們使用了 DeepSeek 技術報告中提到的微批次（micro batching）來打破資料依賴性。如圖下半部分所示，我們將一個 Transformer 層的運算分為 5 個階段：

階段 1：InputNorm、QKVProj、AppendKV、BMM

階段 2：BMM、Attn、OProj、PostNorm、Gate

階段 3：Dispatch Send、共用專家

階段 4：Dispatch Recv、MoE、Combine Send

階段 5：Combine Recv

在前 3 個 Dense Transformer 層中，我們使用整個批次。在接下來的 58 個 MoE Transformer 層中，我們將批次平分為兩個微批次。這兩個微批次交替執行，相差 3 個階段。由於這兩個微批次之間沒有資料依賴性，我們可以在 Dispatch Send 之後以及 Combine Send 之後切換到另一個微批次的運算。

接下來，我們透過實驗來比較重疊的效果，並比較單一節點部署 EP8 與多節點部署 EP128 之間的效能差異。為了便於比較，我們在以下實驗中使用了 H100 GPU。我們使用了 TP1、每個 GPU 128 的批次大小、每個請求 2 的查詢長度，以及 5000 的 KV 快取長度。

上圖顯示了在一個 MoE Transformer 層上花費的總時間以及不同類型核心的延遲比例。除了 Dispatch、Combine 和 GroupGEMM 之外，其他核心的執行時間在 EP8、EP128 NoOverlap 和 EP128 DispatchOverlap 系列中應該是相同的，因為批次大小是相同的。

讓我們先比較三種重疊方法的成效。NoOverlap 總共耗時 2667µs，DispatchOverlap 耗時 2651µs，節省了 16µs，僅佔 0.6%。MicroBatch 表現出非常顯著的改善，耗時 1896µs，速度提升了 29%。Dispatch 和 Combine 的時間都顯著減少。Dispatch 從 593µs 降至 367µs，Combine 從 1012µs 降至 237µs。

請注意，對於運算核心，將大小為 128 的批次分割為兩個大小為 64 的批次會增加總執行時間。因此，儘管通訊花費的時間減少了 1001µs，但總時間只減少了 771µs。我們將在下一節中使用 Roofline 模型來解釋原因。

因此，微批次處理並不總是能提升效能。

使用 micro-batching 時輸出速度與每節點吞吐量的變化，並按每 GPU batch size 作圖。

上圖顯示了對於批次大小 4-128，Microbatch 與 DispatchOverlap 相比的效能提升。當批次大小小於 32 時，Microbatch 會使效能降低 5%-40%。當批次大於或等於 32 時，Microbatch 可以將效能提升 10%-35%。

讓我們回到先前的圖表，比較 EP8 和 EP128 Microbatch。EP8 總共耗時 1802µs，略少於 EP128 的 1896µs。除了前面提到的 Microbatch 帶來的核心執行時間增加之外，主要的差異在於用於 MoE 運算的 GroupGEMM，以及兩個通訊核心 Dispatch 和 Combine。

EP8 的 GroupGEMM 耗時 555µs，而 EP128 的 GroupGEMM 耗時 270µs，減少了一半。這是多節點部署的核心優勢。

不幸的是，通訊花費的時間增加了 213µs，這大大抵消了 GroupGEMM 的優勢。在我方通訊核心的獨立效能測試中，我們發現它們只能達到 Infiniband 頻寬的一半。我們將繼續最佳化我們的通訊核心。

另一個明顯落後的核心是 GEMM。Microbatch 使 GEMM 增加了 95µs。我們將在下文的 Roofline 節中更深入地分析 GEMM。我們相信目前的 GEMM 實作尚未達到最佳效能。

Roofline 模型是用於分析核心效能的良好工具。它的水平軸是算術強度（Arithmetic Intensity），即 FLOP 與記憶體 I/O 位元組的比率。水平軸的值可以直接從核心的語意中計算出來。垂直軸表示達到的效能，透過將 FLOP 除以基準延遲來計算。

核心效能的理論上限直接由 GPU 的規格決定。H100 的 FP8 峰值效能為 1979 TFLOP/s，在 Roofline 模型中表示為一條水平線。H100 的記憶體頻寬為 3.35 TB/s，表示為通過原點的線條斜率。這兩條線分別給出了受限於運算（compute-bound）和受限於記憶體（memory-bound）的核心效能極限。

以下我們將探討 GroupGEMM 和 GEMM 核心的效能。

MoE 中的 GroupGEMM 核心執行以下運算：總共有 g 個群組，第 i 個群組有 m_i 個 Token，執行 [m_i, k] x [k, n] -> [m_i, n] 的矩陣乘法。在效能測試中，我們假設每個群組中的 Token 數量相同，表示為 m_i = m。那麼 GroupGEMM 的 FLOP 計數為 2 * g * m * k * n，記憶體 I/O 位元組為 g * (m * k + n * k + m * n)。

在 DeepSeek-V3/R1 模型中，有 256 個專家，每個 Token 被分發給 8 個專家進行運算。假設批次大小為 128、查詢長度為 2，並使用 EP128 DP128 組態，每個專家接收到的平均 Token 數量（即 m）為 128 * 2 * 8 * 128 / 256 = 1024。同樣地，我們可以計算其他組態和批次大小的 m。

我們使用 DeepGEMM 的 GroupGEMM 實作進行效能測試。測試點涵蓋了 EP8、EP16、EP32、EP64、EP128 組態與 TP1 以及批次大小 1-128 的組合。

上圖顯示了不同 EP 組態下 GroupGEMM 的 Roofline 模型。不同的 EP 對應不同的群組數量。圖表顯示出幾乎重疊的效能線，這表明 GroupGEMM 效能主要由總 Token 數量（表示為 g * m）決定。

星號標記了各個 EP 組態下對應每個 GPU 批次大小 128 的資料點。比較這些帶有星號的資料點，我們可以看到隨著 EP 增加（且 DP 同步增加），每個專家的 Token 數量 m 也隨之增加。在 EP8 時，m=128，而在 EP128 時，m=2048。

隨著 m 增加，算術強度也會增加。在大多數組態中，GroupGEMM 受限於記憶體頻寬，因此增加 m 可以提升效能。

GEMM 核心對應於模型中的線性投影，例如 Q/K/V/O 投影。對於矩陣乘法 [m, k] x [k, n] -> [m, n]，FLOP 數為 2 * m * k * n，而記憶體 I/O 位元組數為 m * k + n * k + m * n。我們也可以測試批次大小 1-128 的延遲。

上圖顯示了不同 EP 組態下 GEMM 的 Roofline 模型。我們可以看到 GEMM 效能受限於記憶體頻寬。隨著批次大小增加，算術強度也會增加，從而提升效能。

當使用微批次處理時，我們將批次平分為兩部分。從上面兩張圖中，我們可以當 m 變成 m/2 時，矩陣乘法的效率會下降。因此，執行兩個大小為 m/2 的矩陣乘法比執行一個大小為 m 的矩陣乘法需要更多時間。

在整篇文章中，我們都假設使用多 Token 預測（MTP）進行投機式解碼。MTP 將每個請求的查詢長度從 1 變更為 2。對於矩陣乘法而言，這相當於將 m 變更為 m * 2，從而提高矩陣乘法效率。另一方面，如果我們繪製 MLA 的 Roofline 模型，我們會發現增加查詢長度會顯著提高 MLA 核心效率。

因此，MTP 的使用在模型效率中扮演著重要的角色。

在本節中，我們將介紹我們 DeepSeek-V3/R1 模型的一些實作與最佳化細節。

DeepSeek-V3/R1 原生採用 FP8 訓練，使用區塊量化（per-block quantization）方案，權重進行靜態量化，啟用值（activations）則進行動態（on-the-fly）量化。縮放因子不是靜態地按通道或按矩陣計算，而是針對啟動值的 128 元素向量以及矩陣的 128x128 元素磚塊（tiles）計算，從而限制了因量化導致的準確度下降。

在 Perplexity，我們依賴 CUDA 和 Triton 核心的組合來支援推論，其中 CUDA 用於對效能最敏感且修改頻率最低的核心（例如注意力機制和 GEMM），而 Triton 則用於實作各種啟用、正規化和公用程式核心。Triton 讓我們能夠快速將核心適應區塊量化方案。

對於線性（linear）和 MoE 層，我們將 Deep GEMM 核心與我們自己的 Triton GEMM 核心混合使用，因為我們注意到對於特定的矩陣維度和低批次大小，Split-K 可以提供更低的延遲。如果未量化的層執行 (M, K) x (K, N) 乘法，則它需要 (M x ceil_div(K, 128)) x (ceil_div(K, 128), ceil_div(N, 128)) 的縮放因子進行區塊量化。對於區塊量化，啟動值的縮放因子是動態計算的，而不是預先校準的。由於啟動值縮放因子僅沿著 K 維度聚合，而非沿著 M 維度聚合，因此核心只需進行輕微修改即可支援該方案。

DeepSeek-V3/R1 使用的 SiLU 啟動函數需要進行重大更改，以支援 CUDA 圖形（CUDA graphs）、區塊量化和動態路由的 Token 數量。區塊量化可能會帶來問題，因為它引入了水平歸約（horizontal reductions），但該核心已經將沿著其隱藏維度的啟動值切塊為 1024 個元素的區塊。在一個區塊內，要量化的張量進一步被切塊為 128 的區塊以計算最大絕對值，而 Triton 生成了高效的跨 Warp 最大值歸約，將額外開銷降至最低。

為了在 CUDA 圖形下支援 MoE 路由，核心必須能夠感知指示每個專家 Token 數量的路由資訊，而不是根據配置來容納 Token 數量上限的緩衝區大小來排程工作。我們無法根據輸入張量維度來分割問題，因此我們啟動了固定數量的持續性核心，這些核心會讀取路由資訊以決定填入多少 Token，並在它們之間動態分割處理啟動值的工作。

我們已經將我們的一些核心上游合併到 FlashInfer 專案中，未來我們將開源更多程式碼。

我們使用 FlashInfer 進行 MLA 運算。FlashInfer 支援彈性的頁面表（Page Table）設定和極高的效能。

我們將 q_a_proj 和 kv_a_proj 融合為單一個 qkv_a_proj。延遲從 15.4 µs + 14.8 µs = 30.2 µs 降低至 16.7 µs。

我們將 kv_b_proj 分解為兩個矩陣：k_b_proj 和 v_b_proj。我們為與這兩個矩陣相關的運算編寫了一個 FP8 區塊量化 BMM 核心。

Cuda 圖形可以顯著減少核心啟動開銷，這對效能至關重要。我們為每個批次大小建立一個 Cuda 圖形。

在開發我們的 AllToAll 核心之前，我們使用 torch.all_to_all_single() 進行 AllToAll 通訊。此操作要求所有 GPU 使用相同的批次大小。然而，不同的 DP 群組可能會執行不同的批次大小。

為了確保 all_to_all_single() 與使用不同批次大小的不同 DP 群組相容，我們首先在每次模型執行前使用 allreduce() 操作來取得所有 DP 群組中的最大批次大小。然後我們讓所有 DP 群組使用此批次大小來執行。

儘管此方法確保我們可以使用 Cuda 圖形，但它有三個缺點。首先，它需要額外的 allreduce() 操作。其次，批次大小較小的 DP 群組被迫進行填補（padding）。第三，它使我們的實作程式碼變複雜。

在實作我們自己的 AllToAll 核心之後，我們不再要求所有 GPU 使用相同的批次大小。因此，我們不再需要執行額外的 allreduce() 操作或填補批次大小。

MoE 路由器是用 Triton 實作的，依賴於衍生自標準庫的修改版排序，同時也會追蹤已排序元素的索引。該實作在所有 MoE 模型中共用，因為 Mixtral 路由是 DeepSeek 路由的一種特殊情況，其中 Top-K 群組與所有專家的群組相同。稀疏核心直接消耗 Top-K 索引和分數，而依賴 all-to-all 的密集分發/組合方案則需要按專家而非按 Token 基礎聚合路由資訊。

在未來的工作中，我們計劃進一步最佳化 DeepSeek 模型的效能。

最重要的下一步最佳化是預填拆分（Prefill Disaggregation）。DeepSeek-V3/R1 模型的預填（Prefill）階段和解碼（Decode）階段具有非常不同的運算特徵。兩者都可以使用不同的最佳化策略和部署方案。

對於 MLA 層，在解碼階段，我們使用矩陣吸收（Matrix Absorption）來減少 MLA 運算的 FLOP 數量。在預填階段，先將潛在向量投影到 K/V 空間中，然後以多頭注意力（MHA）形式進行運算會有更好的表現。

如果預填和解碼在相同的 GPU 上執行，為了減少預填對解碼輸出速度的影響，我們通常使用區塊化預填（chunked prefill）將查詢劃分為多個區塊進行預填。由於 KV 快取儲存了潛在向量，將 MLA 轉換為 MHA 形式變得困難。

對於 MoE 層，在解碼階段，我們使用盡可能大的 EP 和 DP 來增加每個專家的輸入 Token 數量，從而提升 GroupGEMM 效能。在預填階段，由於 Token 數量已經足夠大，GroupGEMM 已經受限於運算。因此，對於預填，我們可以使用較小的 EP 和 DP。

如果預填和解碼在相同的 GPU 上執行，只要任何 DP 群組正在執行預填，所有 GPU 上的 MoE 層延遲就會增加，從而顯著影響解碼輸出速度。

除了預填拆分之外，我們還計劃最佳化以下幾個方面：

AllToAll 效能：我們的 AllToAll 核心目前只能達到 Infiniband 頻寬的 1/3。我们将繼續最佳化此核心。

EAGLE 風格的投機式解碼：在上面的資料中，我們假設使用投機式解碼來預測 1 個 Token。EAGLE 可以使用樹狀結構來預測多個 Token，提升接受長度，這可以顯著提高輸出速度。

GEMM 核心：在先前顯示的 Roofline 模型中，我們發現 GEMM 核心的效率距離理論極限仍有一段距離。我們將繼續最佳化此核心。

GB200 NVL72：在 NVIDIA 最新的 GB200 NVL72 解決方案中，72 個 Blackwell GPU 透過高速 NVLink 互連。對於 MoE 架構模型來說，這是一個非常大的機遇與挑戰。

DeepSeek MoE 模型的多節點部署實現了密集 LLM 通常不可能做到的事情：同時改善吞吐量和延遲。透過將專家分發到更多 GPU 上，我們減少了每個裝置的記憶體頻寬壓力，從而實現更快的處理速度和更高的系統吞吐量。我們的實驗表明，與單一節點部署相比，EP128 組態在相同的輸出速度下可實現高達 5 倍的吞吐量提升。

諸如微批次處理等運算與通訊重疊技術顯著減少了多節點通訊開銷，我們的實作顯示速度提升高達 40%。我們的自訂 AllToAll 通訊核心和最佳化核心實作使 671B 參數模型的有效部署成為可能。

隨著 MoE 架構因其強大功能而日益普及，這些部署策略為高效擴展此類模型提供了寶貴的見解。

DeepSeek-V3 技術報告

DeepSeek-V3/R1 推論系統概述

Megatron-LM: Training Multi-Billion Parameter Language Models Using Model Parallelism

EAGLE: Speculative Sampling Requires Rethinking Feature Uncertainty

BibTeX

@online{perplexity2025LowerLatencyAndHigherThroughputWithMultiNodeDeepseekDeployment,
  author = {{Perplexity} and Lequn Chen and Nandor Licker and Erin McKnight},
  title = {{Lower latency and higher throughput with multi-node DeepSeek deployment}},
  date = {2025-04-18},
  url = {https://perplexity.coolkeypoint.com/hub/blog/lower-latency-and-higher-throughput-with-multi-node-deepseek-deployment}
}

部署架構

並行化技術

張量平行度

專家平行度

資料平行處理

單一節點與多節點

運算與通訊重疊

延遲細分

重疊

EP8 與 EP128

Roofline 模型

GroupGEMM

GEMM

微批次處理

多 Token 預測

實作與優化

量化

MLA 層

Cuda 圖形

MoE 路由器

未來工作

結論

參考資料

引文