一、引言

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

• 語言模型：DeepSeek V1、MoE、V2、V3。
• 多模態(tài)模型：DeepSeek VL-1、VL-2、Janus。
• 數(shù)學(xué)、代碼、Reasoning 模型：DeepSeek Math、Coder、Coder-V2、R1。

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

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

• 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 集群建設(shè)，總共包含 10000 個 PCIe A100 GPU（PS：推測該集群最初不是為了大規(guī)模 LLM 訓(xùn)練而設(shè)計，不然不會采用 PCIe A100）。其涉及以下關(guān)鍵技術(shù)：

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

2.2 服務(wù)器

上面提到，DeepSeek 采用的 PCIe A100，節(jié)點內(nèi)沒有使用 NVLink + NVSwitch 全互聯(lián)。為了緩解 GPU 間數(shù)據(jù)傳輸?shù)钠款i，DeepSeek 采用折衷方案，每兩個 GPU 通過 NVLink Bridge 實現(xiàn)高速互聯(lián)。如下圖所示，8 個 GPU 共分為 4 組，每組 2 個 GPU 通過 NVLink Bridge 連接。（PS：需要說明的是，DeepSeek 早期服務(wù)器沒有 NVLink Bridge，而是后期為了適應(yīng) LLM 的需求新增加的）

此外，單個節(jié)點內(nèi)只配備一個 200Gbps 的 Mellanox CX6 IB 網(wǎng)卡，并且直連到 CPU，沒有經(jīng)過 PCIe Switch。

2.3 集群網(wǎng)絡(luò)拓撲

如下圖所示為其提出的兩層 Fat-Tree 網(wǎng)絡(luò)拓撲：

• 共包含兩個 Zone。兩個 Zone 的 Leaf Switch 直接通過 2 個 40-Port 的 Switch 互聯(lián)（我們這里稱作 Zone Switch），而不用經(jīng)過 Zone 內(nèi)的 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：軟硬協(xié)同網(wǎng)絡(luò)設(shè)計

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

•  第一步：節(jié)點內(nèi) Reduce 操作。
• 第二步：節(jié)點間在 CPU 上進行 Reduce 操作。
• 第三步：將 CPU 上 Reduce 后的數(shù)據(jù)傳輸回 GPU。

其中涉及的關(guān)鍵技術(shù)包括：

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

2.5 HaiScale：針對 DL 訓(xùn)練優(yōu)化

DeepSeek 也針對上述架構(gòu)對分布式策略進行了相應(yīng)優(yōu)化，比如：

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

2.6 聯(lián)合優(yōu)化

為了避免流量相互干擾并造成網(wǎng)絡(luò)擁塞等問題，DeepSeek 也實施了一系列的優(yōu)化措施：

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

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

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

對于 DeepEP，可以設(shè)置 NVSHMEM_IB_SL 環(huán)境變量來控制 VL 的分配。NVSHMEM_IB_SL 是 NVSHMEM 的環(huán)境變量，更多可以參考：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 代碼庫中的配置能對應(yīng)上：

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

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

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

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

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

PS：上述 Paper 中的介紹與 3FS 代碼庫中的設(shè)計相關(guān)介紹能對應(yīng)，具體可以參考 3FS/docs/design_notes.md at main [9]：

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

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

2.8 HAI Platform

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

三、H800 集群

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

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

PS：然而，根據(jù)后續(xù) DeepSeek V3 等技術(shù)報告，DeepSeek 在構(gòu)建上述集群時有些變動：

• 沒有采用 PCIe GPU，而是采用了 H800 SXM GPU（相比 H100 SXM GPU 主要區(qū)別是 NVLink 帶寬從 900 GB/s 降低到 400 GB/s）。單節(jié)點內(nèi) 8 個 H800 通過 NVLink + NVSwitch 實現(xiàn)全互聯(lián)。
• 沒有采用 RoCE 網(wǎng)絡(luò)，依然采用 IB 網(wǎng)絡(luò)。并且根據(jù) DeepSeek V3 技術(shù)報告和 DeepEP 代碼庫的測試可以看出，其配備了 8 個 400 Gbps 的 IB NIC。
• 根據(jù) 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 上預(yù)訓(xùn)練，然后經(jīng)過 SFT + DPO 獲得 Chat 模型。

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

4.2 預(yù)訓(xùn)練

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

其他技術(shù)點包括：

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

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

4.3 后訓(xùn)練

采用標(biāo)準(zhǔn)的 SFT + DPO 標(biāo)準(zhǔn)流程。DeepSeek 也在緊接著的 DeepSeek-Math Paper 中提出了 DPO 優(yōu)化版本： GRPO 算法。

4.4 DeepSeek V1 MFU

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

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

則對應(yīng)的 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]）的技術(shù)報告中提出了關(guān)鍵的細粒度專家+共享專家方案，并且在后續(xù)模型中一直延續(xù)。該系列共包含 2B、16B（16.4B，激活 2.8B） 和 145B（144.6B，激活 22.2B） 3 個模型，2B 和 16B 使用 2T Token 預(yù)訓(xùn)練，但最大的 145B 模型并沒有訓(xùn)練完，只訓(xùn)練了 245B Token。

5.2 MoE

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

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

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

5.3 預(yù)訓(xùn)練

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

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

其他技術(shù)點包括：

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

六、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 的主要優(yōu)勢是 Inference 階段可以大幅降低 KV Cache 存儲。此外，模型規(guī)模、數(shù)據(jù)規(guī)模也進一步擴大。包含：

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

6.2 MLA

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

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

與此同時，常用的位置編碼 RoPE 也需要相應(yīng)的調(diào)整，以便能與 MLA 兼容。

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

6.3 預(yù)訓(xùn)練

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

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

輔助負載均衡損失：

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

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

其他技術(shù)點包括：

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

6.4 后訓(xùn)練

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

為了優(yōu)化 RL 的訓(xùn)練效率，采用了一系列工程優(yōu)化：

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

6.5 DeepSeek V2 MFU

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

根據(jù)公式可以大概推出 DeepSeek V2 預(yù)訓(xùn)練的 MFU：

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

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

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

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

七、DeepSeek V3

7.1 概覽

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

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

7.2 模型結(jié)構(gòu)

7.2.1 MTP

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

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

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

7.2.2 MoE

DeepSeek V3 中的 MoE 部分的模型結(jié)構(gòu)沒有調(diào)整，更多的是訓(xùn)練策略上的優(yōu)化，包括如下幾個方面。

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

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

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

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

7.3 訓(xùn)練框架優(yōu)化

7.3.1 概覽

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

為了高效訓(xùn)練，DeepSeek V3 實施了精細的工程優(yōu)化：

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

7.3.2 DualPipe 算法

對于 DeepSeek V3 而言，跨節(jié)點 EP 引入的通信開銷導(dǎo)致計算與通信比約為 1:1，效率很低。為了應(yīng)對這一挑戰(zhàn)，作者設(shè)計了一種創(chuàng)新的流水線并行算法 DualPipe。

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

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

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

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

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

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

而 DeepSeek V3 的雙向 PP 調(diào)度中，還是 8 PP 為例：

• Stage 0 上有 Layer 0, 1 以及 Layer 14, 15 的權(quán)重
• Stage 1 上有 Layer 2, 3 以及 Layer 12, 13 的權(quán)重
• Stage 7 上有 Layer 14, 15 以及 Layer 0, 1 的權(quán)重
• 相當(dāng)于有 2 份相同的模型副本，F(xiàn)orward 的順序可以從 Stage 0 到 7，也可以從 Stage 7 到 0。

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

7.3.3 高效跨節(jié)點 All2All 通信

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

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

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

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

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

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

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

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

7.3.4 降低內(nèi)存開銷

為降低訓(xùn)練過程中的內(nèi)存占用，作者采用了以下技術(shù)手段。

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

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

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

7.4 FP8 訓(xùn)練

7.4.1 混合精度框架

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

盡管 FP8 格式具有效率優(yōu)勢，但某些算子因?qū)Φ途扔嬎惚容^敏感仍需更高精度。同時，一些低成本算子也可采用更高精度，對整體訓(xùn)練性能的影響微乎其微。因此，對以下組件保持原始精度（如 BF16 或 FP32）：Embedding Module、輸出 Head、MoE 門控模塊、歸一化算子及 Attention 算子，確保 DeepSeek-V3 的訓(xùn)練動態(tài)穩(wěn)定性。為進一步保證數(shù)值穩(wěn)定性，將主權(quán)重、權(quán)重梯度和優(yōu)化器狀態(tài)以更高精度存儲。

7.4.2 提升精度

作者還引入了若干策略以提升低精度訓(xùn)練的準(zhǔn)確性，重點在于量化方法與乘法過程的優(yōu)化。

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

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

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

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

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

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

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

7.4.3 低精度存儲和通信

還通過將緩存的激活值和優(yōu)化器狀態(tài)壓縮為低精度格式，進一步減少內(nèi)存消耗和通信開銷。

低精度優(yōu)化器狀態(tài)。采用 BF16 而非 FP32 來存儲 AdamW 優(yōu)化器中的一階矩和二階矩，而不會引起可觀察到的性能下降。然而，主權(quán)重（由優(yōu)化器存儲）和梯度仍使用 FP32 存儲，以確保整個訓(xùn)練過程中的數(shù)值穩(wěn)定性。

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

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

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

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

7.4.4 DeepGEMM 高效 FP8 GEMM 實現(xiàn)

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

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

• Dense GEMM：

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

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

• Grouped GEMM：基本實現(xiàn)了 1.2x 的加速。

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

7.5 推理部署

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

7.5.1 Prefill

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

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

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

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

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

7.5.2 Decoding

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

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

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

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

7.5.3 專家并行負載均衡器

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

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

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

b.然后，在每個節(jié)點內(nèi)復(fù)制專家實例；

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

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

7.5.4 MTP 投機采樣

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

針對上述問題，可以充分利用 MTP 機制實現(xiàn)投機采樣，如下所示，vLLM 在 https://github.com/vllm-project/vllm/pull/12755 [18] 中進行了簡單評估，一個投機 Token（k=1）時，不同并發(fā)下可以實現(xiàn) 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 模型實現(xiàn)了 3x 左右的加速（PS：這一般是序列比較長或者并發(fā)比較小的情況下實現(xiàn)的）。

7.6 DeepSeek V3 MFU

DeepSeek V3 和 V2 的結(jié)構(gòu)基本一致，可以采用類似的 MFU 估算方式。

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

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

同樣，考慮 MLA 無參數(shù) Attention 計算等，假設(shè)占比 10%，則對應(yīng)的 MFU 為 34.7% * 1.1 = 38.2%。

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

八、DeepSeek R1

8.1 概覽

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

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

8.2 DeepSeek R1-Zero

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

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

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

3.3 DeepSeek R1

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

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

3.4 DeepSeek R1-Distill-xx

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

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

3.5 蒸餾（Distill）與強化學(xué)習(xí)（RL）

僅通過蒸餾 DeepSeek-R1 或者 RL 都可以使模型取得不錯的 Reasoning 能力。如下圖 Table 6 所示，作者基于 Qwen-32B-Base 進行實驗，可以看出，僅通過 RL 使得 Qwen-32B-Base 獲得了與 QwQ-32B-Preview 相當(dāng)?shù)?Reasoning 能力，但依舊遠差于蒸餾的方案。可以得出兩點結(jié)論：

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

九、相關(guān)鏈接

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??

本文轉(zhuǎn)載自??AI閑談??，作者：AI閑談