關于deepseek R1模型分布式推理效率分析

1、引言

? ? ? ?DeepSeek R1 采用了混合專家（Mixture of Experts，MoE）架構，包含多個專家子網絡，并通過一個門控機制動態地激活最相關的專家來處理特定的任務。DeepSeek R1 總共有 6710 億個參數，但在每個前向傳播過程中僅激活 370 億個參數。模型的每一層都包含 256 個專家，并且每個 token 會并行路由到其中 8 個不同的專家("num_experts_per_tok": 8)進行評估。

2、DeepSeek R1 的混合專家架構

? ? ? DeepSeek R1 由 61 個 Transformer 層組成。MoE 架構主要在 Transformer 模塊的前饋網絡（Feed-Forward Network，FFN）層中實現。每個 FFN 層都包含 256 個專家。理解 MoE 位于 Transformer 層的 FFN 中，有助于理解計算的結構以及如何應用分布式。Transformer 層是像 DeepSeek R1 這樣的模型的基本構建模塊。DeepSeek R1模型的671B總參數中，并不是所有參數都在專家層中。MoE模型的參數可以分為兩類：

稀疏參數：只在特定token激活的專家層參數
密集參數：每個token都會使用的共享參數

在DeepSeek R1中每次激活的37B參數具體如下：
1個共享專家（所有token都激活同一個共享專家）
門控網絡選擇的8個普通專家（從255個普通專家中選擇）
所以總共是9個專家

參數計算：

共享專家的參數量與普通專家相當（約2.6B參數）
總共激活的參數 = 1個共享專家(~2.6B) + 8個普通專家(~21B) + 稠密層參數(~13.4B) ≈ 37B

DeepSeek R1專家分布分析

從配置文件中可以看到關鍵參數：

MoE層的分布：
- "moe_layer_freq": 1 - 這表明每一層都是MoE層，而不是我之前猜測的隔層分布
- "num_hidden_layers": 61 - 總共有61層Transformer塊
- 所有61層都包含MoE結構
專家配置：
- "n_routed_experts": 256 - 256個常規路由專家
- "n_shared_experts": 1 - 1個共享專家
- "num_experts_per_tok": 8 - 每個token激活8個路由專家(不包括共享專家)
專家參數量:
- "hidden_size": 7168 - 隱藏層維度
- "intermediate_size": 18432 - 稠密前饋網絡的中間層大小
- "moe_intermediate_size": 2048 - MoE專家內部的中間層大小

MoE計算細節

根據配置：

專家參數主要集中在FFN部分，計算每個專家大小約為：
- 7168 × 2048 × 2 ≈ 29.4M參數（輸入和輸出矩陣）
257個專家(256常規+1共享)×61層 ≈ 約462B參數僅在專家部分

MoE層結構:
[共享專家(1個)] + [普通專家(255個)]
? ? ↑ ? ? ? ? ? ? ? ? ?↑
? 總是激活 ? ? ? ? 選擇8個激活
? ? ↓ ? ? ? ? ? ? ? ? ?↓
? ?每個token激活9個專家(1+8)?

共享專家能接觸到所有數據，學習通用模式，而普通專家則專注于特定類型的輸入，兩者結合提高了模型的整體能力和效率。共享專家相當于是一個"通用底層處理器"，確保即使路由決策不理想，每個token也能得到基本處理。

3. 推理過程的分解：理解預填充和解碼階段

特征	預填充階段	解碼階段
計算強度	高	中等
并行化程度	高	低
內存需求	高內存帶寬	中等（KV 緩存訪問）
關鍵指標	吞吐量	延遲
典型硬件優化	多 GPU，高計算能力	快速內存訪問，低延遲互連

預填充階段在計算上受限且受內存帶寬限制，特別是對于長輸入序列。它需要大量的并行處理能力和內存帶寬來處理整個輸入。解碼階段通常受內存限制，因為它主要涉及訪問 KV 緩存并一次執行單個 token 的計算。延遲是此階段的關鍵問題。在預填充期間，模型一次性處理整個輸入序列。這允許跨輸入的不同部分以及跨模型的不同層進行并行計算。在分布式環境中，不同的節點可以并行處理輸入的不同片段或不同的層，從而可能顯著提高速度。

解碼階段以自回歸方式逐個生成輸出 token [用戶查詢。每個新 token 的預測都基于先前生成的 token 和來自預填充階段的 KV 緩存。由于 token 生成的順序性質，此階段通常比預填充階段慢且并行化程度較低。解碼階段的順序性質給并行化帶來了挑戰。

通過分布專家，仍然可以通過減少每個節點在每個 token 生成步驟中的計算負載來提高效率。與預填充不同，解碼是按順序發生的。每個生成的 token 都依賴于前一個 token。這使得跨序列長度進行并行化變得更加困難。然而，在每個 token 生成步驟中，激活專家的計算仍然可以分布在多個節點上，從而降低每個步驟的延遲。

token在transformer層中傳遞的流程

在每一層中，token首先通過自注意力機制
然后該層的門控網絡會獨立評估這個token
門控網絡動態選擇8個最相關的路由專家
token同時也會通過1個共享專家處理
9個專家(8個路由+1個共享)的輸出被加權合并
合并后的結果傳遞到下一層
在下一層，這個過程完全重復，重新選擇專家

關鍵點是：

所有層共享同一個專家池(257個專家)
每層都有獨立的門控網絡做出獨立的專家選擇
專家選擇是動態的，完全基于token在當前層的表示
不同層可能選擇完全不同的專家組合

?4、DeepSeek R1 的分布式部署策略

通過將 256 個專家分布在不同的節點上，每個節點僅存儲一部分專家的參數。在推理期間，當一個 token 被路由到一組特定的 8 個專家時，只有托管這些專家的節點才需要執行涉及其參數的大量計算。這避免了每個節點都需要訪問整個 6710 億個參數，從而顯著減少了需要本地獲取和處理的數據量。這種有針對性的參數訪問降低了內存帶寬需求以及傳輸到每個節點的數據量。

?通過將計算負載分布到多個節點上，可以并行處理更多的 token 和請求，從而實現更高的吞吐量。專家并行通過啟用更大的批處理大小，進一步提高了 GPU 矩陣計算效率并提升了吞吐量。DeepSeek 報告每個 H800 節點在預填充期間的平均輸入 token 吞吐量約為 73.7k/s，在解碼期間的平均輸出 token 吞吐量約為 14.8k/s 。處理更大的批次和并行化計算的能力直接轉化為在給定時間內服務更多用戶或處理更多數據。當工作負載分布化時，系統的總處理能力會增加。

DeepSeek R1 推理并行策略

策略	描述	DeepSeek R1 的優勢	DeepSeek R1 中的應用
專家并行 (EP)	將模型專家分布在節點上，允許每個節點處理模型參數的一個子集。	擴展批處理大小，減少每個節點的內存訪問，降低延遲。	跨節點的 EP 用于預填充和解碼，具有不同的配置。
數據并行 (DP)	將輸入數據分布在多個設備上，每個設備都持有模型的副本（或在某些情況下是分區）。	通過避免注意力層中的 KV 緩存重復來提高內存效率（在 MLA 的上下文中）。	DP 與 EP 結合使用，例如預填充期間的 MLA/共享專家 DP32。

?5、單機部署deepseek r1的局限性

主要性能影響排序

吞吐量嚴重受限（最主要影響）
- 并發請求處理能力達到硬性上限，無法超越8卡能力
- 無法通過增加節點橫向擴展處理更多并發請求
- 在高負載場景下，請求隊列迅速增長
高負載下延遲不穩定
- 隨著并發請求增加，熱門專家爭搶造成性能波動
- 無法通過分布式部署分散負載壓力
- 專家訪問不均衡導致部分GPU成為系統瓶頸
上下文長度與批量處理互斥
- 長上下文需要占用大量顯存存儲KV緩存
- 在固定顯存條件下，上下文越長，能處理的批次越少
- 這種權衡限制了同時支持長上下文和高吞吐量的能力
資源利用率不均衡
- 熱門專家所在GPU可能負載過重
- 冷門專家所在GPU可能相對閑置
- 無法通過動態調整優化全局資源利用

單機部署的資源利用情況

總顯存: 8×141GB = 1128GB
FP8模型參數: ~671GB
剩余顯存在KV緩存與批處理空間之間權衡
關鍵規律: 上下文長度增加→可處理批次減少→吞吐量下降

專家在H20 8卡上的實際分布

在H20 8卡(每卡141GB)部署時，專家分布如下：

專家分配策略：
- 256個路由專家均勻分布在8個GPU上
- 每張GPU分配32個路由專家
- 共享專家可能放在其中一張GPU上或復制到多個GPU
顯存占用計算：
- 模型總參數：671B
- 單個專家估算參數量：~2.62B (FP8精度下約2.62GB)
- 每張GPU存儲32個專家：~84GB
- 基礎模型部分(張量并行切分)：~10-20GB
- 總計每卡顯存占用：~94-104GB
- 剩余顯存(~37-47GB)：用于KV緩存、激活值等?