一、引言

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

• 語(yǔ)言模型：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ù)點(diǎn)；此外，也補(bǔ)充了 DeepSeek A100 和 H800 GPU 集群的關(guān)鍵配置。其中，紅色表示在對(duì)應(yīng)模型中新增的關(guān)鍵技術(shù)：

DeepSeek 也從 2025.02.24 到 2025.02.28 開(kāi)源了其中涉及的一系列工作，我們也會(huì)在文中進(jìn)行關(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]）中詳細(xì)介紹了其 A100 集群建設(shè)，總共包含 10000 個(gè) PCIe A100 GPU（PS：推測(cè)該集群最初不是為了大規(guī)模 LLM 訓(xùn)練而設(shè)計(jì)，不然不會(huì)采用 PCIe A100）。其涉及以下關(guān)鍵技術(shù)：

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

2.2 服務(wù)器

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

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

2.3 集群網(wǎng)絡(luò)拓?fù)?/h3>

如下圖所示為其提出的兩層 Fat-Tree 網(wǎng)絡(luò)拓?fù)洌?/p>

• 共包含兩個(gè) Zone。兩個(gè) Zone 的 Leaf Switch 直接通過(guò) 2 個(gè) 40-Port 的 Switch 互聯(lián)（我們這里稱(chēng)作 Zone Switch），而不用經(jīng)過(guò) Zone 內(nèi)的 Spine Switch。也就是 2 個(gè) 40-Port 的 Switch 共連接了 80 個(gè) Leaf Switch。 
• 每個(gè) Zone 大概包含：

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

a.20 個(gè) Port 連接 Spine Switch。

b.1 個(gè) Port 連接中間的 Zone Switch。

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

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

2.4 HFReduce：軟硬協(xié)同網(wǎng)絡(luò)設(shè)計(jì)

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

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

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

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

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

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

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

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

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

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

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

• 使用高吞吐 Kernel 的 Workload
• 使用低時(shí)延 Kernel 的 Workload
• 其他的 Workload

對(duì)于 DeepEP，可以設(shè)置 NVSHMEM_IB_SL 環(huán)境變量來(lái)控制 VL 的分配。NVSHMEM_IB_SL 是 NVSHMEM 的環(huán)境變量，更多可以參考：Environment Variables — NVSHMEM 3.2.5 documentation [8]。

2.7 3FS

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

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

PS：該配置與 3FS 代碼庫(kù)中的配置能對(duì)應(yīng)上：

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

PS：然而，其在 3FS 代碼庫(kù)中進(jìn)行 GraySort 評(píng)估的配置又與上述配置不同：

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

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

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

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

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

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

2.8 HAI Platform

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

三、H800 集群

DeepSeek 并沒(méi)有詳細(xì)的報(bào)告來(lái)介紹 H800 集群，只是在幾個(gè)報(bào)告中有所提及。

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

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

• 沒(méi)有采用 PCIe GPU，而是采用了 H800 SXM GPU（相比 H100 SXM GPU 主要區(qū)別是 NVLink 帶寬從 900 GB/s 降低到 400 GB/s）。單節(jié)點(diǎn)內(nèi) 8 個(gè) H800 通過(guò) NVLink + NVSwitch 實(shí)現(xiàn)全互聯(lián)。
• 沒(méi)有采用 RoCE 網(wǎng)絡(luò)，依然采用 IB 網(wǎng)絡(luò)。并且根據(jù) DeepSeek V3 技術(shù)報(bào)告和 DeepEP 代碼庫(kù)的測(cè)試可以看出，其配備了 8 個(gè) 400 Gbps 的 IB NIC。
• 根據(jù) 3FS 代碼庫(kù)推測(cè)，每個(gè) H800 SXM 配備 2.2 TB RAM 和至少一個(gè)額外的 200 Gbps IB NIC。

四、DeepSeek V1

4.1 概覽

DeepSeek V1（[2401.02954] DeepSeek LLM: Scaling Open-Source Language Models with Longtermism [12]）包含兩個(gè)模型，7B 和 13B，都是在 2 T Token 上預(yù)訓(xùn)練，然后經(jīng)過(guò) SFT + DPO 獲得 Chat 模型。

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

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

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

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

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

PS：3FS 代碼庫(kù)中提到，使用 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 的報(bào)告中有和 DeepSeek V1 67B 的預(yù)訓(xùn)練進(jìn)行對(duì)比，提到 67B 模型每 T Token 需要訓(xùn)練 300.6K GPU 小時(shí)，也可以推導(dǎo)出其使用的是 H800 GPU。通常我們可以采用如下公式計(jì)算 MFU，其中每個(gè) Token計(jì)算量 Ctoken  可以用 6N 來(lái)近似，N 表示模型參數(shù)量：

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

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

5.2 MoE

DeepSeek MoE 模型主要有兩點(diǎn)改進(jìn)，如下圖 Figure 2 所示：

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

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

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

DeepSeek MoE 中采用了 2 種負(fù)載均衡損失：

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

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

• 16B 模型分布式策略：ZeRO DP 和 PP，所有專(zhuān)家可以放在一個(gè) GPU 上，不用 EP。
• 145B 模型分布式策略：ZeRO DP + PP + 4EP。
• 訓(xùn)練數(shù)據(jù)很充足，訓(xùn)練中不使用 Dropout。
• 通過(guò) CUDA 和 Triton 實(shí)現(xiàn)自定義 GPU Kernel，以?xún)?yōu)化路由算法，融合不同專(zhuān)家中的 Linear 層等。
• 所有實(shí)驗(yàn)在 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 的最大改進(jìn)是引入 MLA（Multi-head Latent Attention），MLA 的主要優(yōu)勢(shì)是 Inference 階段可以大幅降低 KV Cache 存儲(chǔ)。此外，模型規(guī)模、數(shù)據(jù)規(guī)模也進(jìn)一步擴(kuò)大。包含：

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

6.2 MLA

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

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

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

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

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

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

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

輔助負(fù)載均衡損失：

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

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

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

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

6.4 后訓(xùn)練

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

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

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

6.5 DeepSeek V2 MFU

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

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

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

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

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

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

七、DeepSeek V3

7.1 概覽

整體來(lái)說(shuō) 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 效果的同時(shí)只用了非常低的成本。14.8 Token，在 2048 H800 上訓(xùn)練不到 2 個(gè)月，假設(shè)每個(gè) H800 每小時(shí)成本為 2 美元，則總成本為 558 萬(wàn)美元。（PS：需要說(shuō)明的是，這只是按照租賃成本 x 訓(xùn)練時(shí)間得到的單次訓(xùn)練的成本，不包含集群采購(gòu)以及實(shí)驗(yàn)和探索的成本。）

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

7.2.1 MTP

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

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

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

7.2.2 MoE

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

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

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

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

無(wú) Token Drop（No Token-Dropping）：得益于高效的負(fù)載均衡策略，DeepSeek-V3 在整個(gè)訓(xùn)練過(guò)程中保持了良好的負(fù)載平衡。因此，DeepSeek-V3 在訓(xùn)練期間未丟棄任何 Token。此外，作者還實(shí)施了特定的部署策略以確保推理過(guò)程中的負(fù)載均衡，故 DeepSeek-V3 在推理階段同樣不會(huì)丟棄 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 個(gè)節(jié)點(diǎn)上。

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

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

7.3.2 DualPipe 算法

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

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

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

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

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

PS：正常來(lái)說(shuō)是無(wú)法實(shí)現(xiàn)雙向 PP 調(diào)度的，主要是因?yàn)?Forward 執(zhí)行順序是從前往后，比如從 Layer 0,1,2,...,14,15，而 Backward 執(zhí)行順序是從后往前，比如 Layer 15,14,...,2,1,0。而常見(jiàn) PP 中的 Layer 只會(huì)在某一個(gè) 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 代碼庫(kù)中開(kāi)源了相關(guān)代碼，其實(shí)現(xiàn)了 Forward 和 Backward 階段充分的 Overlap。如下圖所示為其 Training 的 Profiling 示例，Computation 使用 112 SM，Communication 使用 20 個(gè) SM。每個(gè) Chunk 包含 4 個(gè) MoE Layer。

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

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

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

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

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

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

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

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

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

7.3.4 降低內(nèi)存開(kāi)銷(xiāo)

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

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

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

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

7.4 FP8 訓(xùn)練

7.4.1 混合精度框架

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

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

7.4.2 提升精度

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

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

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

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

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 累加的精度實(shí)際只有 FP22，對(duì)應(yīng) 1 個(gè)符號(hào)位，8 個(gè)指數(shù)位，13 的尾數(shù)位，與上述 14 位精度基本對(duì)應(yīng)。不過(guò)從其他地方幾乎沒(méi)有再看到相關(guān)資料。

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

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

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

7.4.3 低精度存儲(chǔ)和通信

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

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

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

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

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

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

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

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

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

• Dense GEMM：

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

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

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

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

7.5 推理部署

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

7.5.1 Prefill

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

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

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

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

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

7.5.2 Decoding

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

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

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

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

7.5.3 專(zhuān)家并行負(fù)載均衡器

DeepSeek 在 EPLB 代碼庫(kù)中重點(diǎn)介紹了其專(zhuān)家并行負(fù)載均衡器（Expert Parallelism Load Balancer）。其包含兩種負(fù)載均衡：

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

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

b.然后，在每個(gè)節(jié)點(diǎn)內(nèi)復(fù)制專(zhuān)家實(shí)例；

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

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

7.5.4 MTP 投機(jī)采樣

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

針對(duì)上述問(wèn)題，可以充分利用 MTP 機(jī)制實(shí)現(xiàn)投機(jī)采樣，如下所示，vLLM 在 https://github.com/vllm-project/vllm/pull/12755 [18] 中進(jìn)行了簡(jiǎn)單評(píng)估，一個(gè)投機(jī) Token（k=1）時(shí)，不同并發(fā)下可以實(shí)現(xiàn) 1.11x-1.64x 的加速：

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

7.6 DeepSeek V3 MFU

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

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

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

同樣，考慮 MLA 無(wú)參數(shù) Attention 計(jì)算等，假設(shè)占比 10%，則對(duì)應(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)練，則對(duì)應(yīng)的 MFU 在 29%-32% 之間。

八、DeepSeek R1

8.1 概覽

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

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

8.2 DeepSeek R1-Zero

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

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

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

3.3 DeepSeek R1

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

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

3.4 DeepSeek R1-Distill-xx

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

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

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

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

• 將更強(qiáng)大的模型蒸餾至較小規(guī)模能帶來(lái)卓越效果，而依賴(lài)大規(guī)模 RL 的小型模型不僅需耗費(fèi)巨大計(jì)算資源，且可能無(wú)法企及蒸餾所達(dá)到的性能水平。
• 盡管蒸餾策略兼具經(jīng)濟(jì)性與高效性，但欲突破智能邊界，仍需依賴(lài)更強(qiá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閑談