一、引言

DeepSeek 從 2024 年 01 月到 2025 年 01 月發布了一系列模型，其中最主要的就是語言系列模型，這個文檔中我們會對語言模型涉及的關鍵技術進行具體介紹：

• 語言模型：DeepSeek V1、MoE、V2、V3。
• 多模態模型：DeepSeek VL-1、VL-2、Janus。
• 數學、代碼、Reasoning 模型：DeepSeek Math、Coder、Coder-V2、R1。

如下圖所示，圖中我們匯集了 DeepSeek V1、MoE、V2、V3、R1 系列模型中的關鍵技術點；此外，也補充了 DeepSeek A100 和 H800 GPU 集群的關鍵配置。其中，紅色表示在對應模型中新增的關鍵技術：

DeepSeek 也從 2025.02.24 到 2025.02.28 開源了其中涉及的一系列工作，我們也會在文中進行關聯介紹，包括：

• FlashMLA: Efficient MLA Decoding Kernel for Hopper GPUs [1]
• DeepEP: an efficient expert-parallel communication library [2]
• DeepGEMM: clean and efficient FP8 GEMM kernels with fine-grained scaling [3]
• DualPipe: A bidirectional pipeline parallelism algorithm for computation-communication overlap in V3/R1 training. [4]
• EPLB: Expert Parallelism Load Balancer [5]
• 3FS: A high-performance distributed file system designed to address the challenges of AI training and inference workloads. [6]

二、A100 集群

2.1 概覽

DeepSeek 在 A100 Infra 的 Paper（[2408.14158] Fire-Flyer AI-HPC: A Cost-Effective Software-Hardware Co-Design for Deep Learning [7]）中詳細介紹了其 A100 集群建設，總共包含 10000 個 PCIe A100 GPU（PS：推測該集群最初不是為了大規模 LLM 訓練而設計，不然不會采用 PCIe A100）。其涉及以下關鍵技術：

• Network Co-Design：集成了計算-存儲網絡的兩層 Fat-Tree 網絡。
• HFReduce：為了適配器 PCIe 架構的集合通信庫。
• HaiScale：基于 PCIe 架構優化的分布式并行方案。
• 3FS Distributed File System：解決 AI 任務下大數據的 I/O 瓶頸問題。
• HAI Platform：提供任務調度，容錯等能力，以便增加利用率，降低成本。

2.2 服務器

上面提到，DeepSeek 采用的 PCIe A100，節點內沒有使用 NVLink + NVSwitch 全互聯。為了緩解 GPU 間數據傳輸的瓶頸，DeepSeek 采用折衷方案，每兩個 GPU 通過 NVLink Bridge 實現高速互聯。如下圖所示，8 個 GPU 共分為 4 組，每組 2 個 GPU 通過 NVLink Bridge 連接。（PS：需要說明的是，DeepSeek 早期服務器沒有 NVLink Bridge，而是后期為了適應 LLM 的需求新增加的）

此外，單個節點內只配備一個 200Gbps 的 Mellanox CX6 IB 網卡，并且直連到 CPU，沒有經過 PCIe Switch。

2.3 集群網絡拓撲

如下圖所示為其提出的兩層 Fat-Tree 網絡拓撲：

• 共包含兩個 Zone。兩個 Zone 的 Leaf Switch 直接通過 2 個 40-Port 的 Switch 互聯（我們這里稱作 Zone Switch），而不用經過 Zone 內的 Spine Switch。也就是 2 個 40-Port 的 Switch 共連接了 80 個 Leaf Switch。 
• 每個 Zone 大概包含：

• 20 個 Spine Switch 和 40 個 Leaf Switch，Spine 和 Leaf 之間 Full Mesh 連接。
• 800 個 Node（包含 GPU Node 和 Storage Node，還有一些管理 Node）。
• 每個 Leaf Switch 40 個 Port：

a.20 個 Port 連接 Spine Switch。

b.1 個 Port 連接中間的 Zone Switch。

c.15 或 16 個 Port 連接 GPU Node，也就是每個 Zone 有 [40*15=600, 40*16=640] 個 GPU Node。（PS：論文中只說總共大約 1250 GPU Node，每個 Zone 大約 600 GPU Node，因此這里只能推測）

d.2 或 4 個 Port 連接 Storage Node。（PS：論文中提到兩個 Zone 總共大約 200 個 Storage Node，但又介紹每個 Zone 800 個 Node。后文還提到包含 180 個 Storage Node，平均來看每個 Leaf Switch 會連接 2-3 個 Storage Node，Storage Node 包含 2 個 200 Gbps 的 NIC，不確定是否會將一個 Storage Node 連接到不同的 Leaf Switch）

2.4 HFReduce：軟硬協同網絡設計

如下圖 Figure 6 所示為針對上述集群優化之后的 HFReduce 操作概覽，其包含幾步：

•  第一步：節點內 Reduce 操作。
• 第二步：節點間在 CPU 上進行 Reduce 操作。
• 第三步：將 CPU 上 Reduce 后的數據傳輸回 GPU。

其中涉及的關鍵技術包括：

• GPUDirect：使用 GPUDirect 加速 D2H 中的小數據拷貝，同時使用 GPUDirect 減少 3 倍的 H2D 開銷。
• 節點內規約：使用 SIMD 指令完成 CPU 上的規約操作，支持 FP32、FP16、BF16 和 FP8。
• NUMA 感知：D2H 的目標內存會分配到 2 個 NUMA 對應的內存，以實現最大帶寬。CPU Reduce 和網絡傳輸的數據內存綁定在 IB NIC 對應的 NUMA，以盡量減少通過 UPI。
• 節點間規約：使用 Double Binary Tree 實現 AllReduce，避免額外的開銷。
• Overlap：將數據分為多個 Chunk 分別處理，以實現 IO 和 Compute 的 Overlap。

2.5 HaiScale：針對 DL 訓練優化

DeepSeek 也針對上述架構對分布式策略進行了相應優化，比如：

• 將 NVLink Bridge 連接的 2 個 GPU 用于 TP，實現高速互聯。（PS：通常使用 NVLink + NVSwitch 的方案可以更好的實現 8 GPU 的 TP）
• 針對 PCIe 架構優化 PP。一臺機器只有 1 個 NIC，使用 PP 時可能存在瓶頸，為此，在調度時將不同的 DP Rank 調度到同一個 Node 上，這樣可以交錯 DP 和 PP。
• 此外，也對 PyTorch DDP、FSDP 進行了適配和優化。

2.6 聯合優化

為了避免流量相互干擾并造成網絡擁塞等問題，DeepSeek 也實施了一系列的優化措施：

• 不同流量區分：在典型的訓練任務中，有 4 種不同類型的流量：HFReduce 通信，NCCL 通信，3FS 存儲流量和其他流量。DeepSeek 利用 IB 的 Service Level（SL）技術，在節點之間建立連接時為其分配不同的 SL 值，并將 SL 映射到 IB 物理隊列虛擬通道（VL），使用虛擬通道可以確保不同通道中的流量不會相互干擾。最終，通過配置它們的比例實現流量隔離，從而防止 Head-of-Line（HOL）阻塞和不同的流量沖突引起的網絡阻塞。
• 拓撲調整和路由優化：在高吞吐存儲場景中，存在許多 incast 通信模式，導致擁塞。針對這種情況，采用靜態路由策略，將存儲流量均勻分散在不同 Leaf -> Spine 連接，并將各種節點（存儲、計算、管理）均勻分配到 Leaf -> Spine 連接。
• NCCL 優化：調整了 NCCL 拓撲，以便調整同一個 Node 內的 IB NIC 和 GPU 的路由。可以減少 CPU chiplet 互聯導致的 PCIe 擁塞。此外，通過使用 PCIe Relaxed Ording 進一步減少擁塞并增加帶寬。
• 3FS 網絡調優：3FS 實現了一個請求到發送的控制機制來緩解擁塞。

PS：DeepSeek 在 DeepEP 代碼庫中也提到了流量隔離（Traffic isolation）。具體來說，IB 通過虛擬信道（Virtual Lanes，VL）支持流量隔離，為防止不同類型流量間的相關干擾，作者建議按照以下方式將工作負載分配到不同的 VL：

• 使用高吞吐 Kernel 的 Workload
• 使用低時延 Kernel 的 Workload
• 其他的 Workload

對于 DeepEP，可以設置 NVSHMEM_IB_SL 環境變量來控制 VL 的分配。NVSHMEM_IB_SL 是 NVSHMEM 的環境變量，更多可以參考：Environment Variables — NVSHMEM 3.2.5 documentation [8]。

2.7 3FS

如下圖 Table IV 為 Paper 中提到的 Storage Node 配置，可以看出，其包含 1 個 CPU，2 個 200 Gbps NIC 和 16 個 15.36TB 的 SSD。

• 總共 2880 NVMe SSD，可以提供 20 PiB 的存儲（有1個額外的存儲副本）。
• 總共可以提供 180*2*200 Gbps = 72 Gbps = 9 TB/s 的理論帶寬，實測可以達到 8 TB/s。

PS：該配置與 3FS 代碼庫中的配置能對應上：

在該配置下，最終的聚合讀吞吐可以達到 6.6TB/s：

PS：然而，其在 3FS 代碼庫中進行 GraySort 評估的配置又與上述配置不同：

• 25 個 Storage 節點配備了 2 個 400 Gbps 的 IB NIC，網絡帶寬是上述配置的 2x，應該是 CX7，估計對應 H100 集群。
• 其中 50 個計算節點，每個計算節點包含 2.2T RAM 和一個 200 Gbps 的 IB NIC，上述 A100 集群的 RAM 是 512 GB，這個也許是 H800 Server，不過其已經包含了 8 個 400 Gbps 的 IB NIC，可能是有一個額外的 200 Gbps NIC 專用于數據 IO。

3FS 系統包含 4 個角色：Cluster Manager、Meta Service、Storage Service 和 Client。其中 Storage Service 會部署在每個 Storage Node 上，每個 Storage Service 都能提供等分的帶寬。根據這個設計，每個 Client 都可以訪問每個 Storage Service。峰值負載時，作者在 Client 觀察到 Incast 擁塞，為了緩解這個擁塞，作者在 Storage Service 和 Client 之間實現了一種請求發送控制機制（request-to-send），這種機制會增加端到端 IO 延遲，但又是實現可持續高吞吐的必要手段。

除此之外，還基于 3FS 實現了 3FS-KV，是 DeepSeek LLM Inference 中實現分布式 Context Caching 的關鍵所在。

PS：上述 Paper 中的介紹與 3FS 代碼庫中的設計相關介紹能對應，具體可以參考 3FS/docs/design_notes.md at main [9]：

• Meta Service 和 Storage Service 向 Cluster Manager 發送心跳信號。
• Cluster Manager 負責處理成員變更并將集群配置分發給其他 Service 和 Client。系統中部署了多個 Cluster Manager，其中一個被選舉為主管理器（primary）。當 primary 發生故障時，另一個 Manager 會被提升為 primary。集群配置通常存儲在可靠的分布式協調服務中，例如 ZooKeeper 或 etcd。在作者的生產環境中，為了減少依賴，使用與文件元數據相同的鍵值存儲來保存集群配置。
• 文件 metadata 操作（例如打開或創建文件/目錄）被發送到 Meta Service，Meta Service 負責實現文件系統語義。Meta Service 是無狀態的，因為文件 metadata 存儲在事務性鍵值存儲（如 FoundationDB）中。Client 可以連接到任意 Meta Service。
• 每個 Storage Service 管理幾個本地 SSD，并提供塊存儲接口。Storage Service 實現了帶有分攤查詢的鏈式復制（CRAQ）協議以確保強一致性。CRAQ 的 “write-all-read-any” 方法有助于充分發揮 SSD 和 RDMA 網絡的吞吐量。3FS 文件被分割成等大小的塊，這些塊在多個 SSD 上存儲多個副本。
• 為應用程序開發了兩種 Client：FUSE client 和 native client。大多數應用程序使用 FUSE client，因為其采用門檻較低。而對性能要求較高的應用程序則集成了 native client。

DeepSeek 在 3FS 代碼庫中也提供了對針對 Inference 場景的 3FS-KV，如下圖所示，上圖展示了所有 KV Cache Client 的讀取吞吐量，其峰值吞吐可達 40 GiB/s。下圖則展示了同一時間段內垃圾回收（GC）過程中刪除操作的操作次數（IOPS）：

2.8 HAI Platform

DeepSeek 很早就開源了其對應的分布式訓練平臺，具體可以參考源碼（GitHub - HFAiLab/hai-platform: 一種任務級GPU算力分時調度的高性能深度學習訓練平臺 [10]）和文檔（歡迎來到HAI Platform 官方文檔 [11]）。不過開源了將近兩年都沒有再更新。

三、H800 集群

DeepSeek 并沒有詳細的報告來介紹 H800 集群，只是在幾個報告中有所提及。

在上述 A100 集群的 Paper 中提到，也在準備構建下一代的 PCIe 架構集群來支持 MoE LLM 的訓練，其包含大量的 All2All 通信，因此下一代架構中 GPU 和 NIC 會采用 1:1 配比，也就是每個 GPU 都有一個對應的 NIC，也考慮采用多平面網絡。此外，會使用 RoCE 替代 IB Switch 以降低成本。使用 128 Port 的 400 Gbps RoCE Switch，4 平面的 2 層 Fat-Tree 網絡可以支持 32,768 個 GPU。

PS：然而，根據后續 DeepSeek V3 等技術報告，DeepSeek 在構建上述集群時有些變動：

• 沒有采用 PCIe GPU，而是采用了 H800 SXM GPU（相比 H100 SXM GPU 主要區別是 NVLink 帶寬從 900 GB/s 降低到 400 GB/s）。單節點內 8 個 H800 通過 NVLink + NVSwitch 實現全互聯。
• 沒有采用 RoCE 網絡，依然采用 IB 網絡。并且根據 DeepSeek V3 技術報告和 DeepEP 代碼庫的測試可以看出，其配備了 8 個 400 Gbps 的 IB NIC。
• 根據 3FS 代碼庫推測，每個 H800 SXM 配備 2.2 TB RAM 和至少一個額外的 200 Gbps IB NIC。

四、DeepSeek V1

4.1 概覽

DeepSeek V1（[2401.02954] DeepSeek LLM: Scaling Open-Source Language Models with Longtermism [12]）包含兩個模型，7B 和 13B，都是在 2 T Token 上預訓練，然后經過 SFT + DPO 獲得 Chat 模型。

DeepSeek V1 模型也沒有太特殊的地方，和 LLaMA 2 類似，都是 Dense 模型。并且只在 67B 的大模型采用 GQA，7B 模型依然采用 MHA。

4.2 預訓練

采用了 Multi-Step Learning Rate 調度策略（80%+10%+10%），精度與 Cosine Learning Rate Decay 相近。好處是比較容易從第一個 Stage 的 Checkpoint 進行 Continuous Training。

其他技術點包括：

• 分布式策略：ZeRO-1 DP + PP（1F1B）。
• 采用 FlashAttention V1。
• 對于 LayerNorm、GEMM 和 Adam 更新等操作采用 Layer/OP 融合，以加速訓練。
• 在 Cross-Entropy CUDA Kernel 中實時將 BF16 的 Logits 轉為 FP32，而不是提前在 HBM 中轉換。
• 每 5 分鐘異步保存一次 Checkpoint，以便浪費進度不超過 5 分鐘；并定時刪除過早 Checkpoint，以避免占據太多空間。

PS：3FS 代碼庫中提到，使用 3FS 提供高吞吐并行 Checkpointing。

4.3 后訓練

采用標準的 SFT + DPO 標準流程。DeepSeek 也在緊接著的 DeepSeek-Math Paper 中提出了 DPO 優化版本： GRPO 算法。

4.4 DeepSeek V1 MFU

DeepSeek V3 的報告中有和 DeepSeek V1 67B 的預訓練進行對比，提到 67B 模型每 T Token 需要訓練 300.6K GPU 小時，也可以推導出其使用的是 H800 GPU。通常我們可以采用如下公式計算 MFU，其中每個 Token計算量 Ctoken  可以用 6N 來近似，N 表示模型參數量：

MFU = (Token 數 * Ctoken) / (訓練 GPU 小時數 * GPU FLOPs * 3600)

則對應的 MFU 大約為：

(1T*67B*6) / (300.6K*989T*3600) = 37.56%

五、DeepSeek MoE

5.1 概覽

DeepSeek 在 DeepSeek MoE（[2401.06066] DeepSeekMoE: Towards Ultimate Expert Specialization in Mixture-of-Experts Language Models [13]）的技術報告中提出了關鍵的細粒度專家+共享專家方案，并且在后續模型中一直延續。該系列共包含 2B、16B（16.4B，激活 2.8B） 和 145B（144.6B，激活 22.2B） 3 個模型，2B 和 16B 使用 2T Token 預訓練，但最大的 145B 模型并沒有訓練完，只訓練了 245B Token。

5.2 MoE

DeepSeek MoE 模型主要有兩點改進，如下圖 Figure 2 所示：

• 細粒度專家（Routed Expert）：常見的 MoE 模型中通常是 8 或 16 個專家，而這里會將一個大專家切分為 M 個小專家。比如原來從 16 個專家中選擇 Top 2 大概有 120 中可能；而同樣計算量的 64 個專家（M=4）中選擇 8 個，對應了 4,426,165,368 中可能。
• 共享專家（Shared Expert）：額外增加了 1 個或多個共享專家，用于捕獲通用知識，每個 Token 都會經過這些專家。

3 個模型的具體配置如下所示，需要說明的是，3 個模型中都未使用 GQA，而是使用的 MHA：

5.3 預訓練

DeepSeek MoE 中采用了 2 種負載均衡損失：

• 專家級負載損失（Expert-Level Balance Loss）：讓各個專家的負載平均，盡量避免都路由到少數專家。
• 設備級負載損失（Device-Level Balance Loss）：強制讓各個專家負載平均可能影響效果。由于每個設備（GPU）包含多個專家，因此讓不同設備上的計算量盡量均衡同樣可以一定程度避免負載不均的問題。

其他技術點包括：

• 16B 模型分布式策略：ZeRO DP 和 PP，所有專家可以放在一個 GPU 上，不用 EP。
• 145B 模型分布式策略：ZeRO DP + PP + 4EP。
• 訓練數據很充足，訓練中不使用 Dropout。
• 通過 CUDA 和 Triton 實現自定義 GPU Kernel，以優化路由算法，融合不同專家中的 Linear 層等。
• 所有實驗在 A100 和 H800 集群訓練。

六、DeepSeek V2

6.1 概覽

DeepSeek V2（[2405.04434] DeepSeek-V2: A Strong, Economical, and Efficient Mixture-of-Experts Language Model [14]）模型相比 DeepSeek MoE 的最大改進是引入 MLA（Multi-head Latent Attention），MLA 的主要優勢是 Inference 階段可以大幅降低 KV Cache 存儲。此外，模型規模、數據規模也進一步擴大。包含：

• DeepSeek-V2（236B，21B 激活），8.1T Token 預訓練；包含 2 個 Shared Expert 和 160 個 Routed Expert，每個 Token 激活 2+4=6 個 Expert。
• DeepSeek-V2-Lite（15.7B，2.4B 激活），5.7T Token 預訓練。

6.2 MLA

如下圖 Figure 3 所示，MLA 的核心思路是：使用低秩分解，并共享隱空間投影矩陣來降低 KV Cache 的存儲需求。由于每個 Head 都有獨立的參數，因此可以恢復出相應的 K 和 V，進而避免對效果的影響。

如下圖 Table 1 可以看出，MLA 的 KV Cache 需求雖然依然大于 MQA，但明顯優于 MHA 和 GQA，同時效果更好：

與此同時，常用的位置編碼 RoPE 也需要相應的調整，以便能與 MLA 兼容。

PS：DeepSeek 在 FlashMLA 代碼庫中開源了高效的 MLA Kernel 實現。如下圖所示，vLLM 在初步集成 FlashMLA 后推理性能提升了 3%-17%，具體可以參考這個 PR（https://github.com/vllm-project/vllm/pull/13747 [15]）：

6.3 預訓練

DeepSeek V2 中也采用了一些列的優化手段來提升預訓練效果和速度，具體如下所示。

設備限制路由（Device-Limited Routing）：DeepSeek MoE 的細粒度專家方案中可能會激活很多專家，這會導致 EP 中 All2All 通信量的急劇增加。為了避免 All2All 通信成為瓶頸，對每個 Token 路由到的設備數（GPU）進行限制，具體來說，在 Token 路由時會選擇分數最高的 M 個設備，Token 只路由到這 M 個設備的專家。實驗表明，M >= 3 就可以取得很不錯的效果。

輔助負載均衡損失：

• 專家級負載損失（Expert-Level Balance Loss）：同 DeepSeek MoE。
• 設備級負載損失（Device-Level Balance Loss）：同 DeepSeek MoE。
• 通信負載損失（Communication Balance Loss）：設備限制路由可以保證每個設備發送的通信量是有界的，但如果某個設備接收的 Token 比其他設備多，實際的通信效率也會受到影響。為此，引入通信負載損失，正是為了緩解不同設備接收 Token 不均衡的問題。保證設備之間均衡交換信息，促進高效通信。

Token Dropping 策略：負載均衡損失可以促進均衡，但是無法嚴格保證。為了進一步減少負載不均導致的計算資源浪費，DeepSeek V2 中額外引入了設備級 Token 丟棄策略（Device Level Token Dropping Strategy）。首先計算每個設備的平均計算預算，也就意味著每個設備的容量因子等同于 1.0，然后在每個設備上丟棄親和力得分最低的 Token，直到達到計算預算需求；除此之外，確保約 10% 的訓練序列中的 Token 永遠不會被丟棄。根據效率需求，可以在 Inference 過程中靈活配置是否丟棄 Token，并始終保證 Training 和 Inference 的一致性。

其他技術點包括：

• 和 V1 類似，采用 Warmup + Multi-Step Learning Rate 調度策略，不過 Step 從 80%+10%+10% 變為 60%+30%+10%。
• 分布式策略：Zero-1 DP + 16PP（Zero-Bubble）+ 8EP。
• 部分操作重計算，以節約內存。
• 通信計算 Overlap：Overlap Shared Expert 的計算和 Routed Expert 的 All2All 通信。
• 實現自定義 GPU Kernel，以優化路由算法，融合不同專家中的 Linear 層等。
• 基于 FlashAttention V2 優化 MLA 實現。
• 在 H800 GPU 集群訓練，節點內有 NVLink + NVSwitch 全互聯，使用 IB 網絡。
• 預訓練后，上下文長度從 4K 擴展到 128K。

6.4 后訓練

對齊階段采用了 SFT + GRPO（在 DeepSeek Math 中提出）。

為了優化 RL 的訓練效率，采用了一系列工程優化：

• 混合引擎架構，針對 Training 和 Inference 采用不同的并行策略，以實現更高的 GPU 利用率。
• 采用 vLLM 作為 Inference 后端，加速大 Batch 的 Inference 速度。
• 精心設計了 CPU 與 GPU 之間的 Model Offload 調度策略，在訓練速度和內存消耗之間實現平衡。

6.5 DeepSeek V2 MFU

DeepSeek V2 模型比較特殊，包含 MLA 和 MoE，統計每個 Token 的詳細計算量也相對復雜。然而，考慮到其中最主要的計算仍是矩陣乘法，依然可以用 6N 來近似，不過這里的 N 為每個 Token 的激活參數，而不是總參數量。

根據公式可以大概推出 DeepSeek V2 預訓練的 MFU：

MFU = (Token 數 * Ctoken) / (訓練 GPU 小時數 * GPU FLOPs * 3600)

DeepSeek-V2 預訓練每 T Token 需要 172.8K H800 GPU 小時，則可以估算其 MFU 為（按 BF16 計算）：

(1T*37B*6) / (272.8K*989T*3600) = 22.86%

不過上述計算中忽略了 MLA 中的無參數 Attention 計算等，這一部分在預訓練中通常占比不會特別大，這里假設占比 10%，則對應的 MFU 為 22.86% * 1.1 = 25.15%。

七、DeepSeek V3

7.1 概覽

整體來說 DeepSeek V3（[2412.19437] DeepSeek-V3 Technical Report [16]）的模型結構與 DeepSpeed V2 一致，只是模型規模更大（671B，37B 激活），預訓練數據規模更大（14.8T Token）。除此之外更多是一些訓練策略和工程的優化，比如引入 MTP（Multi-Token Prediction）、FP8 訓練等。

其中最引人注目的地方在于：取得 Top 效果的同時只用了非常低的成本。14.8 Token，在 2048 H800 上訓練不到 2 個月，假設每個 H800 每小時成本為 2 美元，則總成本為 558 萬美元。（PS：需要說明的是，這只是按照租賃成本 x 訓練時間得到的單次訓練的成本，不包含集群采購以及實驗和探索的成本。）

7.2 模型結構

7.2.1 MTP

DeepSeek V3 模型同樣采用 MLA 以及細粒度專家+共享專家的 MoE 結構。在訓練時與 V2 的最大不同是引入 MTP（Multi-Token Prediction），這個思路在 Inference 的投機采樣中經常使用，只不過這里也可以幫助提升模型的效果。具體來說：

• 其中 Main Model 就是標準的 Next Token Prediction。
• MTP Module 1 用于預測下下一個 Token，MTP Module 2 用于預測下下下一個 Token（與 LLM 推理中常見的多頭投機采樣思路一致）。
• MTP Module 中的輸入都包含兩個部分，一個是上一個 Module 的 Output Head 的輸入，以及上一個輸入 Token，并且其中的 Embedding Layer 和 Output Head 都是共享自 Main Model，只有新增的 RMSNorm + Linear Projection 和一個 Transformer Block。由于這里有兩個輸入分別經過 RMSNorm 后 Concat 到一起，因此需要一個額外的 Linear Projection 進行降維，保持維度一致。

MTP 策略主要用于提升 Main Model 的性能，因此在推理階段，可以直接舍棄 MTP Module，Main Model 仍能獨立且正常運行。此外，還可將這些 MTP Module 用于投機解碼，以進一步降低生成延遲。

7.2.2 MoE

DeepSeek V3 中的 MoE 部分的模型結構沒有調整，更多的是訓練策略上的優化，包括如下幾個方面。

無需輔助損失的負載均衡策略（Auxiliary-Loss-Free Load Balancing Strategy）：同樣來自 DeepSeek 2024 年的論文，具體來說，其通過動態更新每個專家的偏置（b）來維持專家的負載均衡，而不會引入額外的干擾梯度。如下圖公式 16 和 Figure 1 所示：

補充的序列級輔助損失（Complementary Sequence-Wise Auxiliary Loss）：盡管 DeepSeek-V3 主要依賴于無輔助損失的策略來實現負載平衡，但為了防止在任何單一序列中出現極端的不平衡，作者采用一種補充的序列級均衡損失。這種序列級均衡損失的目的是鼓勵每個序列中的專家負載更加均衡，避免負載集中在少數專家上，從而提高模型的效率和公平性。

節點限制路由（Node-Limited Routing）：與 DeepSeek-V2 所采用的設備限制路由類似，DeepSeek-V3 同樣使用了一種約束路由機制以控制訓練過程中的通信開銷。簡而言之，確保每個 Token 最多被發送至 M 個節點，這些節點的選擇依據是分布在各節點上的專家中，其親和度得分最高的 Kr/M 項之和。在此約束下，MoE 訓練框架幾乎能夠實現計算與通信的完全重疊。

無 Token Drop（No Token-Dropping）：得益于高效的負載均衡策略，DeepSeek-V3 在整個訓練過程中保持了良好的負載平衡。因此，DeepSeek-V3 在訓練期間未丟棄任何 Token。此外，作者還實施了特定的部署策略以確保推理過程中的負載均衡，故 DeepSeek-V3 在推理階段同樣不會丟棄 Token。

7.3 訓練框架優化

7.3.1 概覽

DeepSeek V3 使用自研的 HAI-LLM 框架訓練，其相應的分布式策略為：16 PP，64 EP 以及 ZeRO-1 DP；此外，64 EP 分布在 8 個節點上。

為了高效訓練，DeepSeek V3 實施了精細的工程優化：

• 設計了 DualPipe 算法以實現高效的流水線并行。與現有 PP 方法相比，DualPipe 具有更少的 PP Bubble。更重要的是，它在 Forward 和 Backward 過程中 Overlap 了計算與通信，從而解決了跨節點 EP 引入的高通信開銷問題。
• 開發了高效的跨節點 All2All 通信 Kernel，以充分利用 IB 和 NVLink 帶寬，并節省專用于通信的 SM。
• 精心優化了訓練過程中的內存開銷，從而能夠在無需使用昂貴的 TP（Tensor Parallelism）的情況下訓練 DeepSeek-V3。

7.3.2 DualPipe 算法

對于 DeepSeek V3 而言，跨節點 EP 引入的通信開銷導致計算與通信比約為 1:1，效率很低。為了應對這一挑戰，作者設計了一種創新的流水線并行算法 DualPipe。

DualPipe 的核心思想是：將一對獨立的 Forward 與 Backward Chunk 內的計算與通信進行 Overlap。特別地，對于 Backward Chunk，借鑒了 ZeroBubble，將 Attention 與 MLP 的 Backward 分為兩部分：Backward for Input 及 Backward for Weight。

如下圖 Figure 4 所示，針對一對 Forward 與 Backward Chunk，重新排列這些組件，并手動調整 GPU SM 在通信與計算間的分配比例。在此 Overlap 策略下，能夠確保 All2All 和 PP 通信在執行過程中完全隱藏，其中：

• 橙色表示 Forward
• 綠色表示 Backward for Input
• 藍色表示 Backward for Weight
• 紫色表示 PP 通信
• 紅色表示 Barrier 同步

完整的 DualPipe 調度如下圖 Figure 5 所示，其采用雙向 PP 調度，同時從流水線兩端輸入 Micro Batch，使得大部分通信得以完全 Overlap（PS：8PP，雙向 20 Micro Batch，反方向 10-19 的 10 個 Micro Batch 并沒有列出來，因此我們用紅色 10-19 補充了部分 Micro Batch）。這種 Overlap 還確保了隨著模型進一步擴展，只要保持恒定的計算與通信比，仍可在跨節點部署細粒度專家的同時，實現近乎零的 All2All 通信開銷。

PS：正常來說是無法實現雙向 PP 調度的，主要是因為 Forward 執行順序是從前往后，比如從 Layer 0,1,2,...,14,15，而 Backward 執行順序是從后往前，比如 Layer 15,14,...,2,1,0。而常見 PP 中的 Layer 只會在某一個 PP Stage，比如 8 PP，那么：

• Stage 0 上有 Layer 0 和 1 的權重
• Stage 1 上有 Layer 2 和 3 權重
• Stage 7 上有 Layer 14 和 15 的權重
• Forward 的順序也只能從 Stage 0 到 Stage 7，不能從 Stage 7 到 Stage 0。

而 DeepSeek V3 的雙向 PP 調度中，還是 8 PP 為例：

• Stage 0 上有 Layer 0, 1 以及 Layer 14, 15 的權重
• Stage 1 上有 Layer 2, 3 以及 Layer 12, 13 的權重
• Stage 7 上有 Layer 14, 15 以及 Layer 0, 1 的權重
• 相當于有 2 份相同的模型副本，Forward 的順序可以從 Stage 0 到 7，也可以從 Stage 7 到 0。

PS：DeepSeek 在 DualPipe 代碼庫中開源了相關代碼，其實現了 Forward 和 Backward 階段充分的 Overlap。如下圖所示為其 Training 的 Profiling 示例，Computation 使用 112 SM，Communication 使用 20 個 SM。每個 Chunk 包含 4 個 MoE Layer。

7.3.3 高效跨節點 All2All 通信

為了確保 DualPipe 具有足夠的計算性能，作者定制了高效的跨節點 All2All 通信 Kernel（包括 Dispatching 和 Combining），以節省專用于通信的 SM 數量。Kernel 的實現與 MoE Gating 算法及集群的網絡拓撲共同設計。

具體來說，在 H800 集群中，跨節點 GPU 與 IB 完全互連，節點內通信通過 NVLink 處理。NVLink 提供 160 GB/s 帶寬，大約是 IB（50 GB/s）的 3.2x。

• 為了有效利用 IB 和 NVLink 的不同帶寬，將每個 Token 限制為最多被發送到 4 個節點，從而減少 IB 流量。
• 對于每個 Token，在做出路由決策時，首先通過 IB 傳輸到其目標節點上具有相同節點內索引的 GPU。一旦到達目標節點，將努力確保它通過 NVLink 立即轉發到承載目標專家的特定 GPU，而不會被隨后到達的 Token 阻塞。（PS：比如說，節點 A 上 GPU 0 的 Token 要發送到節點 B 上的 GPU 3，則對應的路徑為：節點 A GPU 0 -> 節點 B GPU 0 -> 節點 B GPU 3。這樣做是因為高性能 GPU 訓練集群往往會采用軌道優化，同號 GPU 在一個 Leaf Switch 下，如下圖所示，因此可以利用高速的 NVLink 來代替從 Leaf Switch 到 Spine Switch 的流量，從而降低 IB 通信時延，并且減少 Leaf Switch 和 Spine Switch 之間的流量）

通過上述方式，IB 和 NVLink 的通信也可以完全 Overlap，每個 Token 可以有效地為每個節點平均選擇 3.2 個專家，而不會產生 NVLink 的額外開銷。在這樣的通信策略下，只用 20 個 SM 足以充分利用 IB 和 NVLink 的帶寬。

還采用 warp specialization 技術，并將 20 個 SM 劃分為 10 個通信通道，分配給每項通信任務的 warp 數量會根據所有 SM 的實際工作負載進行動態調整。

此外，使用定制化的 PTX 指令，自動調整通信 Chunk 大小，從而顯著減少 L2 Cache 的使用量及對其他 SM 的干擾。

PS：DeepSeek 在 DeepEP 的代碼庫中開源了高效的 All2All 實現。其在 Dispatch 函數內部可能無法預知當前 Rank 將接收多少個 Token，因此將涉及一個隱式的 CPU 等待 GPU 接收計數信號的過程，如下圖所示：

DeepEP 針對 Training 和 Inference Prefill 的高吞吐需求場景，提供了高吞吐的 All2All 通信方案，采用節點內 NVLink + 節點間 RDMA 通信的方式，并分配特定數量的 SM 給 Communication（24），剩余 SM 給 Computation（108），實現通信和計算盡可能的 Overlap，幾乎無 Bubble。

7.3.4 降低內存開銷

為降低訓練過程中的內存占用，作者采用了以下技術手段。

RMSNorm 與 MLA 上投影重計算。在 Backward 階段，對所有 RMSNorm 操作及 MLA 上投影進行重計算，從而無需持久化存儲其輸出激活值。此策略雖引入少量額外計算開銷，卻顯著減少了存儲激活值所需的內存空間。

CPU 中的指數移動平均（EMA）。訓練期間，為了在學習率衰減后盡早評估模型性能，保留了模型參數的 EMA。這些 EMA 參數存儲于 CPU 內存中，并在每一步訓練后異步更新。該方法使作者能在不增加額外內存或時間開銷的前提下維護 EMA 參數。

MTP 的共享 Embedding 與輸出 Head。采用 DualPipe 策略，將模型的最淺層（含 Embedding）與最深層（含輸出 Head）部署于同一 PP Stage 上。這種安排使得 MTP Module 與 Main Model 之間能夠物理共享 Embedding 與輸出 Head 的參數及梯度。這一物理共享機制進一步提升了內存使用效率（PS：也就是 Huggingface Transformers 中的 tie_word_embeddings）。

7.4 FP8 訓練

7.4.1 混合精度框架

DeepSeek V3 中引入了 FP8 混合精度訓練框架，大多數計算密集型操作以 FP8 執行，而少數關鍵操作則保留其原始數據格式，以平衡訓練效率與數值穩定性。整體框架如下圖 Figure 6 所示，與線性算子相關的三個 GEMM 操作，包括 Forward（Fprop）、激活 Backward（Dgrad）和權重 Backward（Wgrad），接受 FP8 Tensor 作為輸入，并輸出 BF16 或 FP32 格式的結果，理論上使計算速度較原 BF16 方法提升一倍。此外，FP8 Wgrad GEMM 允許激活值以 FP8 存儲，供 Backward 使用，從而顯著降低內存消耗。

盡管 FP8 格式具有效率優勢，但某些算子因對低精度計算比較敏感仍需更高精度。同時，一些低成本算子也可采用更高精度，對整體訓練性能的影響微乎其微。因此，對以下組件保持原始精度（如 BF16 或 FP32）：Embedding Module、輸出 Head、MoE 門控模塊、歸一化算子及 Attention 算子，確保 DeepSeek-V3 的訓練動態穩定性。為進一步保證數值穩定性，將主權重、權重梯度和優化器狀態以更高精度存儲。

7.4.2 提升精度

作者還引入了若干策略以提升低精度訓練的準確性，重點在于量化方法與乘法過程的優化。

細粒度量化。由于 FP8 格式動態范圍有限，上溢和下溢是常見的挑戰。標準做法是 Per Tensor 量化，會導致低精度訓練對激活異常值極為敏感，嚴重降低量化精度。為解決此問題，提出了一種細粒度量化方法。如下圖 7a 所示：

• 對于激活值，以 1x128 的 Tile 為單位（比如，每 Token 每 128 Channel）進行分組與縮放；
• 對于權重，以 128x128 的 Block 為單位（即，每 128 輸入 Channel 每 128 輸出 Channel）進行分組與縮放。
• 此方法通過更小的元素組調整縮放比例，確保量化過程能更好地適應異常值。

提升累加精度。低精度的 GEMM 操作常面臨下溢問題，其準確性很大程度上依賴于高精度的累加，通常采用 FP32 進行。然而，在 NVIDIA H800 GPU 上，FP8 GEMM 的累加精度僅能保留約 14 位，遠低于 FP32 的累加精度。當內部維度 K 較大時，這一問題更加突出，這在大規模模型訓練中尤為常見。為解決此問題，作者采用 Cutlass 中的方案，借助 CUDA Core 以獲取更高精度。具體來說，該過程如上圖 7b 所示，在 Tensor Core 上執行 MMA，中間結果以有限位寬累加。一旦達到 Nc 間隔，這些中間結果將被復制到 CUDA Core 的 FP32 寄存器中，進行全精度的 FP32 累加。然后可以結合前面的細粒度量化，沿內部維度 K 應用每組的縮放因子。這些縮放因子在 CUDA Core 上高效地作為反量化過程進行乘法運算，額外計算成本極低。

PS：有意思的是，清華大學的 [2411.10958] SageAttention2: Efficient Attention with Thorough Outlier Smoothing and Per-thread INT4 Quantization [17] 中提到，Ada 和 Hopper 架構 Tensor Core FP8 乘法中，FP32 累加的精度實際只有 FP22，對應 1 個符號位，8 個指數位，13 的尾數位，與上述 14 位精度基本對應。不過從其他地方幾乎沒有再看到相關資料。

尾數優先于指數。與先前研究采用的混合 FP8 格式不同，該格式在前向傳播中使用 E4M3（4 位指數和 3 位尾數），在數據梯度和權重梯度中使用 E5M2（5 位指數和 2 位尾數）。DeepSeek V3 中則對所有 Tensor 采用 E4M3 格式以追求更高精度。此方法可行主要是使用了細粒度的量化策略，通過對更小的元素組進行操作，可以有效地在這些分組元素間共享指數位，從而緩解了有限動態范圍的影響。

在線量化。常見的 Tensor level 量化框架中采用 Delayed Scaling，通過保留先前迭代中的 amax（最大絕對值）history 來推斷當前值。為了確保量化 Scale 準確并簡化框架，在線計算每個 1x128 激活 Tile 或 128x128 權重 Block 的 amax，基于此推導出 scaling 因子，隨后在線將激活或權重量化為 FP8 格式。

如下圖為 NVIDIA Transformer Engine 中的 Delayed Scaling 實現方案，其 amax history 最多可以存儲 1024 個 history。在進行當前 Tensor 的 Scaling 操作時，會使用當前 Tensor 之前的 amax history 來預測當前的 amax（比如之前 history 的最大值），然后進行 Scaling 操作；Scaling 操作的同時會計算當前的 amax，并更新 amax history。

7.4.3 低精度存儲和通信

還通過將緩存的激活值和優化器狀態壓縮為低精度格式，進一步減少內存消耗和通信開銷。

低精度優化器狀態。采用 BF16 而非 FP32 來存儲 AdamW 優化器中的一階矩和二階矩，而不會引起可觀察到的性能下降。然而，主權重（由優化器存儲）和梯度仍使用 FP32 存儲，以確保整個訓練過程中的數值穩定性。

低精度激活。如上圖 Figure 6 所示，Wgrad 操作使用 FP8 執行。為了減少內存消耗，將激活值以 FP8 格式緩存用于線性算子的 Backward。不過，對于低成本高精度訓練，會對幾個算子特殊處理：

• Attention 算子后的線性算子輸入。這些激活值也用于 Attention 算子的 Backward，其對精度比較敏感。作者專門為這些激活值定制了 E5M6 數據格式。此外，在 Backward 過程中，這些激活值將從 1x128 量化 Tile 轉換為 128x1 Tile。為了避免引入額外的量化誤差，所有縮放因子均為四舍五入的 2 的整數冪。
• MoE 中 SwiGLU 算子的輸入。為了進一步降低內存成本，緩存了 SwiGLU 算子的輸入，并在 Backward 時重新計算其輸出。這些激活值也以 FP8 格式存儲，采用細粒度量化方法，可以在內存效率和計算精度之間取得平衡。

低精度通信。在 MoE 模型訓練中，通信帶寬是一個關鍵瓶頸。為緩解這一挑戰，在 MoE 上投影前將激活量化為 FP8，隨后應用 Dispatching，這與 MoE 上投影中的 FP8 Forward 兼容。如同 Attention 算子后線性層的輸入，此激活的縮放因子為 2 的整數冪，類似策略也應用于 MoE 下投影前的激活梯度。對于 Forward 和 Backward 的 Combining，保持其 BF16 格式，以確保訓練流程關鍵部分的訓練精度。

PS：DeepSeek 在 DeepEP 代碼庫的 All2All 實現中支持了 FP8 的低精度通信。

7.4.4 DeepGEMM 高效 FP8 GEMM 實現

PS：DeepSeek 在 DeepGEMM 代碼庫中開源了高效的 FP8 GEMM 實現，其受到 CUTLASS 和 CuTe 的啟發，不過避免了過度依賴它們的 templates 或 algebras。其提供以下能力：

• 除了優化 Dense GEMM 外，還提供 Grouped GEMM 的優化（非常適合 MoE 中的矩陣計算）。

• Dense GEMM：

a.在小 Shape 的矩陣乘法中，實現 1.4x - 2.7x 的加速。

b.在大 Shape 時加速比較小，比如 M=4096，N=2112，K=7168 及以上，基本上沒有加速。

• Grouped GEMM：基本實現了 1.2x 的加速。

• 前面提到的細粒度量化，允許調整縮放因子，減少精度損失。
• JIT 編譯：運行時編譯，無需安裝時預編譯。
• 硬件優化：專為 Hopper 架構 Tensor Core 實現。
• 通過腳本來修改編譯后的二進制文件中的 FFMA SASS 指令，修改了 yield bit 并翻轉了 reuse bit，為 MMA 指令和 FFMA 指令的 Overlap 執行提供了更多機會，從而提升了細粒度量化的性能，在某些情況下提升超過 10%。
• 充分利用 Persistent warp-specialization 以及 Hopper TMA 特性等。

7.5 推理部署

在 H800 集群上部署 DeepSeek-V3，為了同時確保在線服務的 SLO 和高吞吐量，采用 Prefill 階段和 Decoding 階段分離部署。

7.5.1 Prefill

Prefill 階段的最小部署單元由 4 個節點組成，共 32 個 H800 GPU。

• Attention 部分采用 4 TP 結合 SP（Sequence Parallelism），并與 8 DP 相結合。其較小的 TP 規模（4）限制了 TP 通信的開銷。
• MoE 部分采用 32 EP，確保每個專家處理足夠大的 Batch Size，從而提升計算效率。

在 MoE 的 All2All 通信中，采用與訓練階段相同的方法：首先通過 IB 在節點間傳輸 Token，然后通過 NVLink 在節點內的 GPU 間轉發。特別地，對于淺層密集 MLP，采用 1TP 以節省 TP 通信開銷。

為了實現 MoE 部分不同專家間的負載均衡，需確保每個 GPU 處理大致相同數量的 Token。引入了冗余專家部署策略，即對高負載專家進行復制并冗余部署。高負載專家基于在線部署期間收集的統計數據檢測并定期調整（如每 10 分鐘一次）。確定冗余專家集合后，根據觀察到的負載情況，在節點內的 GPU 間精心重新安排專家，力求在不增加跨節點 All2All 通信開銷的前提下，盡可能平衡各 GPU 的負載。對于 DeepSeek-V3 的部署，作者為 Prefill 階段設置了 32 個冗余專家。每個 GPU 除了原本承載的 8 個專家外（256/32），還將額外承載一個冗余專家。

此外，在 Prefill 階段，為了提高吞吐量并隱藏 All2All 和 TP 通信的開銷，同時處理兩個計算工作量相近的 Micro Batch，將一個 Micro Batch 的 Attention 和 MoE 計算與另一個 Micro Batch的 Dispatching 和 Combining Overlap 執行。

7.5.2 Decoding

在 Decoding 過程中，將共享專家視為路由專家之一。由此視角出發，每個 Token 在路由時會選擇 9 個專家，其中共享專家被視為高負載專家，始終被選中。Decoding 階段的最小部署單元由 40 個節點組成，共 320 H800 GPU。

• Attention 部分采用 4 TP 結合 SP，并與 80 DP 協同工作，而 MoE 部分則采用 320 EP。
• MoE 部分，每個 GPU 僅承載一位專家，其中 64 個 GPU 負責承載冗余專家及共享專家。Dispatching 與 Combining 部分的 All2All 通信通過 IB Direct P2P 傳輸實現，以實現低延遲。此外，還利用 IBGDA 技術進一步降低延遲，提升通信效率。

與 Prefill 階段類似，基于在線服務的專家負載統計數據，在特定間隔內定期確定冗余專家集合。然而，由于每個 GPU 僅承載一位專家，因此無需重新安排專家。

DeepSeek 在 DeepEP 代碼庫中，還提供了針對 Inference Decoding 階段 Low Latency 場景的 All2All 優化方案，借助 NVIDIA 的 IBGDA 技術，可以在保證低時延的情況下獲得很高的吞吐。借助 Receiving Hook 接口，RDMA 網絡流量可以在后臺執行（低時延 Kernel 采用純 RDMA 通信，可以異步執行，不過只是為了簡化，實際也可以使用 NVLink），對應 Communication SM 個數為 0，不會占用計算部分的任何 SM。因為有兩個 Micro-Batch，因此可以把一個 Micro Batch 的異步數據傳輸藏在另一個 Micro-Batch  的計算之后。

7.5.3 專家并行負載均衡器

DeepSeek 在 EPLB 代碼庫中重點介紹了其專家并行負載均衡器（Expert Parallelism Load Balancer）。其包含兩種負載均衡：

• 分層負載均衡（Hierarchical Load Balancing）：當節點數能整除專家組數量時，采用分層負載來利用組限制專家路由（group-limited expert routing）。比較適合 Inference Prefill 階段，此時 EP 的大小比較小。

a.首先將專家均勻分配到節點上，確保不同節點負載均衡；

b.然后，在每個節點內復制專家實例；

c.最后，將復制的專家實例分配到各個 GPU 上，以確保不同 GPU 間的負載均衡。

• 全局負載均衡（Global Load Balancing）：其他情況下，采用全局負載均衡，該策略無視專家組的劃分，將專家復制至全局范圍，并將這些復制的專家分配到各個 GPU 上。此策略適用于 Inference Decoding 階段，此時 EP 規模較大。

7.5.4 MTP 投機采樣

DeepSeek V3 和 DeepSeek R1 模型都已經開源，其 671B 參數量為部署帶來了極大的挑戰，比如 8 * H100 機器都無法部署 FP8 版本（不考慮 Offload），不過可以部署 AWQ W4A16 版本。此外，在小規模部署時為 KV Cache（Reasoning 模型 KV Cache 更多）留下的空間很小，導致無法支持很大的 Batch Size，Decoding 階段處于明顯的 Memory Bound。

針對上述問題，可以充分利用 MTP 機制實現投機采樣，如下所示，vLLM 在 https://github.com/vllm-project/vllm/pull/12755 [18] 中進行了簡單評估，一個投機 Token（k=1）時，不同并發下可以實現 1.11x-1.64x 的加速：

同樣的，NVIDIA 在 TensorRT-LLM 中也對 LLaMA 3 模型進行了投機采樣加速測試，參考 TensorRT-LLM Speculative Decoding Boosts Inference Throughput by up to 3.6x | NVIDIA Technical Blog [19]，其 LLaMA 3.1 7B 模型實現了 3x 左右的加速（PS：這一般是序列比較長或者并發比較小的情況下實現的）。

7.6 DeepSeek V3 MFU

DeepSeek V3 和 V2 的結構基本一致，可以采用類似的 MFU 估算方式。

DeepSeek-V3 預訓練 14.8T Token，在 2048 H800 GPU 訓練 2664K GPU 小時，則可以估算其 MFU 為（按 BF16 計算）：

(14.8T*37B*6) / (2664K*989T*3600) = 34.7%

同樣，考慮 MLA 無參數 Attention 計算等，假設占比 10%，則對應的 MFU 為 34.7% * 1.1 = 38.2%。

除此之外，DeepSeekV3 采用 FP8 混合精度訓練，其訓練速度通常至少是純 BF16 訓練速度的 1.2x-1.3x，可以估算，如果使用 BF16 訓練，則對應的 MFU 在 29%-32% 之間。

八、DeepSeek R1

8.1 概覽

先前的Reasoning 模型研究中，很大程度上依賴于大量監督數據來提升模型性能。DeepSeek R1（[2501.12948] DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning [20]） 表明，即便不采用 SFT 作為冷啟動，通過大規模 RL 也能顯著增強模型的 Reasoning 能力。此外，引入少量冷啟動數據可進一步優化性能。如下為 DeepSeek-R1 的相關模型：

1. DeepSeek-R1-Zero：該模型直接在 Base 模型上應用 RL，無需任何 SFT 數據。
2. DeepSeek-R1：該模型從經過數千個 long CoT 樣本微調的檢查點開始應用 RL。
3. DeepSeek-R1-Distill-xx：將 DeepSeek-R1 的 Reasoning 能力蒸餾至小型 Dense 模型。

8.2 DeepSeek R1-Zero

即便不采用 SFT 作為冷啟動，通過大規模 RL 也能顯著增強模型的 Reasoning 能力。缺陷是可能存在可讀性差和語言混雜等問題。

DeepSeek-R1-Zero 的思考時間在整個訓練過程中持續提升（生成長度逐漸變長），相應 AIME Accuracy 指標也逐漸提升。DeepSeek-R1-Zero 通過利用更長的測試時間計算，自然而然地獲得了解決日益復雜 Reasoning 任務的能力，比如反思的能力。（PS：Sea AI Lab 的文章表明基礎模型也具備一定的反思能力）

多數投票：通過應用多數投票法，DeepSeek-R1-Zero 的表現可得到進一步提升。例如，如下圖 Table 2 所示，在 AIME 基準測試中采用多數投票后，其性能從 71.0% 躍升至 86.7%，從而超越 OpenAI-o1-0912。

3.3 DeepSeek R1

DeepSeek R1 經歷了兩輪的 SFT+RL。其中第一輪主要聚焦在提升 Reasoning 能力，特別是在編程、數學、科學及邏輯推理等具有明確解決方案的問題上。此外，在 RL 訓練中引入了語言一致性獎勵，以便解決 CoT 常出現語言混雜現象（尤其是在 RL 提示涉及多種語言時）。

除了更好的 Reasoning 數據外，第二階段還整合了來自其他領域的非 Reasoning 數據，以增強模型在寫作、角色扮演及其他通用任務上的能力。此外，進一步提升模型的有益性與無害性，同時精進其 Reasoning 能力。

3.4 DeepSeek R1-Distill-xx

直接蒸餾的方法（包含大模型生成的數據進行 SFT）也可以顯著提升了小型模型的 Reasoning 能力。

如下圖 Table 5 所示，蒸餾的 Qwen-32B 在 Reasoning 能力上優于 官方的 QwQ-32B-Preview。

3.5 蒸餾（Distill）與強化學習（RL）

僅通過蒸餾 DeepSeek-R1 或者 RL 都可以使模型取得不錯的 Reasoning 能力。如下圖 Table 6 所示，作者基于 Qwen-32B-Base 進行實驗，可以看出，僅通過 RL 使得 Qwen-32B-Base 獲得了與 QwQ-32B-Preview 相當的 Reasoning 能力，但依舊遠差于蒸餾的方案?？梢缘贸鰞牲c結論：

• 將更強大的模型蒸餾至較小規模能帶來卓越效果，而依賴大規模 RL 的小型模型不僅需耗費巨大計算資源，且可能無法企及蒸餾所達到的性能水平。
• 盡管蒸餾策略兼具經濟性與高效性，但欲突破智能邊界，仍需依賴更強大的基礎模型與更大規模的 RL 訓練。

九、相關鏈接

1. ??https://github.com/deepseek-ai/FlashMLA??
2. ??https://github.com/deepseek-ai/DeepEP??
3. ??https://github.com/deepseek-ai/DeepGEMM??
4. ??https://github.com/deepseek-ai/DualPipe??
5. ??https://github.com/deepseek-ai/eplb??
6. ??https://github.com/deepseek-ai/3FS??
7. ??https://arxiv.org/abs/2408.14158??
8. ??https://docs.nvidia.com/nvshmem/api/gen/env.html??
9. ??https://github.com/deepseek-ai/3FS/blob/main/docs/design_notes.md??
10. ??https://github.com/HFAiLab/hai-platform??
11. ??https://hfailab.github.io/hai-platform/??
12. ??https://arxiv.org/abs/2401.02954??
13. ??https://arxiv.org/abs/2401.06066??
14. ??https://arxiv.org/abs/2405.04434??
15. ??https://github.com/vllm-project/vllm/pull/13747??
16. ??https://arxiv.org/abs/2412.19437??
17. ??https://arxiv.org/abs/2411.10958??
18. ??https://github.com/vllm-project/vllm/pull/12755??
19. ??https://developer.nvidia.com/blog/tensorrt-llm-speculative-decoding-boosts-inference-throughput-by-up-to-3-6x/??
20. ??https://arxiv.org/abs/2501.12948??

本文轉載自??AI閑談??，作者：AI閑談