?一、背景

幻方 AI 團隊發(fā)布了一系列 DeepSeek 大模型，比如 DeepSeek-V2、DeepSeek-Math、DeepSeek-Coder 等。在 DeepSeek V2 中提出的 MLA（Multi-head Latent Attention）也廣受好評。此外，DeepSeek V2 在強大性能的情況下還將 API 定價降低到 GPT-4 的百分之一，被稱為“價格屠夫”，也由此引發(fā)大模型 API 的價格戰(zhàn)。

本文中我們介紹一下幻方 AI 訓(xùn)練 DeepSeek 系列模型使用的大規(guī)模 GPU 集群以及相應(yīng)的各種優(yōu)化手段。

對應(yīng)的論文為：[2408.14158] Fire-Flyer AI-HPC: A Cost-Effective Software-Hardware Co-Design for Deep Learning

二、摘要

深度學(xué)習(xí) （DL） 和大型語言模型 （LLM） 的快速發(fā)展對計算能力和帶寬的需求呈指數(shù)增長。此外，更快的計算芯片和互聯(lián)的成本也往往很高，這大大增加了高性能計算（HPC）的構(gòu)建成本。為了應(yīng)對這些挑戰(zhàn)，作者提出了 Fire-Flyer AI-HPC 架構(gòu)、軟硬件協(xié)同設(shè)計框架及其最佳實踐。對于深度學(xué)習(xí)訓(xùn)練，作者部署了配備 10000 個 PCIe A100 GPU 的 Fire-Flyer2，實現(xiàn)了接近 DGX-A100 的性能，同時將成本降低一半，能耗降低 40%。作者還專門設(shè)計了 HFReduce 來加速 AllReduce 通信，并采用許多措施來保證計算-存儲網(wǎng)絡(luò)無阻塞。其軟件棧包括 HaiScale、3FS 和 HAI-Platform，作者通過重疊計算和通信實現(xiàn)了更好的可擴展性。

本文中涉及的關(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)度，容錯等能力，以便增加利用率，降低成本。

PS：

• 本文中提到的 10000 卡 A100 集群最開始應(yīng)該不是為了大規(guī)模 LLM 訓(xùn)練搭建，可能沒有太大的網(wǎng)絡(luò)通信需求；而隨著大模型的發(fā)展，向這個方向轉(zhuǎn)換時為了解決網(wǎng)絡(luò)問題進而提供了一系列的解決方案，比如增加 NVLink Bridge。實際上針對大規(guī)模 LLM 推理場景，采用 PCIe GPU + NVLink Bridge 也是個不錯的方案。
• 本文中的各種實驗都是針對 PCIe 架構(gòu)展開，也并沒有提供業(yè)內(nèi)比較常見的 MFU 指標(biāo)，雖然其相比 Baseline 確實提升很多，但依然沒有一個明確的對比。比如當(dāng)前在 DGX A100 上的大規(guī)模訓(xùn)練通常能達到 50%-60% 的 MFU。

三、Fire-Flyer 2：網(wǎng)絡(luò)架構(gòu)

3.1 PCIe A100 GPU 架構(gòu)

在 NVIDIA 官方 DGX 方案中，通常會采用 SXM GPU，有 NVLink 和 NVSwitch 實現(xiàn)高速互聯(lián)，而且通常也會為每個 GPU 配備一個高速 IB 網(wǎng)卡（A100 通常是 200 Gbps）。而本文中作者采用的是 A100 PCIe GPU，無法使用 NVLink 和 NVSwitch 高速互聯(lián)。此外 PCIe A100 和 SXM A100 在性能上也會略有差異，如下圖 Table 2 所示。當(dāng)然，PCIe GPU 服務(wù)器的成本和功耗也會更低一些。

實際上 A100 的各個版本中（甚至 A800 系列），理論算力都是相同的，比如 FP16 Tensor Core 算力都是 312 TFLOPS。作者上圖中 A100 PCIe 是 A100 SXM 的 83% 應(yīng)該是實測性能：

成本低的另一個原因是服務(wù)器中只配備一個 200Gbps 的 Mellanox CX6 IB 網(wǎng)卡，并且直連到 CPU，沒有經(jīng)過 PCIe Switch，類似于下圖紅框 NIC 和綠框 NIC 的區(qū)別。當(dāng)然，這里其實還會引入一個問題，不同 NUMA（CPU）下的 GPU 通信，或者 CPU1 下的 GPU 要通過 NIC 通信則都需要通過 UPI，這也額外增加了一些開銷。

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

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

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

• 共包含兩個 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：

• 20 個 Port連接 Spine Switch。
• 1 個 Port連接中間的 Zone Switch。
• 15 或 16 個 Port連接 GPU Node，也就是每個 Zone 有 [40*15=600, 40*16=640] 個 GPU Node。（PS：論文中只說總共大約 1250 GPU Node，每個 Zone 大約 600 GPU Node，因此這里只能推測）
• 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）?

3.3 成本

作者對比了本文的方案與其他方案需要的 Switch 數(shù)量以及成本，具體如下圖 Table 3 所示：

• 本文：122 個 Switch：(40+20)*2+2。
• PCIe 架構(gòu) + 3 層 Fat-Tree：每個 Node 1 個 NIC，則共需要 1600/20=80 Leaf Switch，80 Spine Switch 和 40 Core Switch，共 200 Switch。
• DGX-A100 GPU + 3 層 Fat-Tree：每個 Node 包含 8 個 GPU，有 8 個后向網(wǎng)絡(luò) NIC，因此 10000 個 GPU(NIC) 至少需要 10000/(40/2)=500 個 40-Port 的 Leaf Switch，500 個 40-Port 的 Spine Switch 和 320 個 Core Switch（PS：考慮 Full Mesh，這里不是 250），所以總共需要 1320 個 Switch。?

從上也可以看出，作者方案可以以 11600/23000=50.4% 的成本獲得 83% 的 GPU性能。

3.4 下一代網(wǎng)絡(luò)拓?fù)?/h3>

作者也在準(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。

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

4.1 HFReduce 算法

在大規(guī)模分布式訓(xùn)練中，AllReduce 是一種非常常見的集合通信操作，比如不同 Data Parallelism 之間的梯度聚合操作。而 NCCL 通常是針對節(jié)點內(nèi)有 NVLink 高速互聯(lián)或者都通過 NIC 方式通信的范式進行優(yōu)化的。針對本文這種網(wǎng)絡(luò)拓?fù)洳灰欢馨l(fā)揮最優(yōu)的性能。如下圖 Figure 6 所示為作者優(yōu)化之后的 HFReduce 概覽，其包含幾步：

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

節(jié)點內(nèi)的 Reduce 操作算法如下圖 Algorithm 1 所示：

• 將數(shù)據(jù)分成多個 Chunk 分別處理，這樣可以將 IO 和 Compute 充分 Overlap。
• 每個 Chunk 的數(shù)據(jù)都通過異步的方式傳輸?shù)?CPU 內(nèi)存，拷貝操作也可以使用 GPUDirect 來拷貝小數(shù)據(jù)（可以參考 NVIDIA 的GitHub - NVIDIA/gdrcopy: A fast GPU memory copy library based on NVIDIA GPUDirect RDMA technology），或者使用 cudaMemcpyAsync 來拷貝大數(shù)據(jù)。
• 已經(jīng)拷貝到CPU 內(nèi)存上的 Chunk 可以執(zhí)行 Reduce 操作，最終的結(jié)果也都是在 CPU 內(nèi)存中。?

節(jié)點間的 Reduce 操作算法如下圖 Algorithm 2 所示：

• 使用 Double Binary Tree Algorithm 算法實現(xiàn)節(jié)點間的 AllReduce 操作，節(jié)點間傳輸通過 RDMA 實現(xiàn)。
• 最后將計算完的數(shù)據(jù)通過 PCIe 傳輸?shù)?GPU 顯存中。此處的 Host to Device 操作也可以通過 GPUDirect 操作來同時寫到同一個 NUMA 下的 4 個 GPU，而減少對 Host Memory 的讀?。ɡ?CPU Cache）。?

4.2 HFReduce 對比 NCCL

針對本文的網(wǎng)絡(luò)拓?fù)?，作者提出的方案相?NCCL 有 2 個優(yōu)勢：

• 減少了 PCIe 帶寬開銷：假設(shè)有 n 個 GPU 參與通信，在 NCCL 的 Ring 拓?fù)渲忻總€數(shù)據(jù)單元需要 2n-1 次傳輸，對 PCIe 通信要求比較高。而 HFReduce 中，每個數(shù)據(jù)單元只需一次 D2H 和一次 H2D，這對于本文這種 PCIe 受限場景更加友好。
• 沒有 GPU Kernel 開銷：HFReduce 使用 GPU 的 Copy Engine(CE) 來執(zhí)行異步的數(shù)據(jù)傳輸，而 NCCL 的 AllReduce 操作是使用 GPU Kernel 來完成。

如下圖（a） 所示，本文的方案在執(zhí)行 186MiB 數(shù)據(jù)的 AllReduce 時相比 NCCL獲得了更高的帶寬。 

4.3 HFReduce with NVLink

我們前面提到過，作者在每兩個 GPU 上添加了 NVLink Bridge，可以達到 600 GB/s 的高速通信帶寬。而上述標(biāo)準(zhǔn) HFReduce 并沒有利用上 NVLink，因此作者也進一步探索了帶有 NVLink 的 HFReduce。具體來說，在數(shù)據(jù)傳輸?shù)?CPU Memory 之前，先在 2 個 GPU 上執(zhí)行 Reduce；然后在結(jié)果返回時再將結(jié)果切分到對應(yīng)的 2 個 GPU。

作者進一步測試了相應(yīng)的通信帶寬，如下圖（b）所示，基本可以達到上述（a）中不帶 NVLink 的 2x。其中藍色為跨 Zone 的情況，因為一個 Leaf Switch 下有 15 或16個 Node，也就是 128 GPU，因此也只考慮超過 128 GPU 的情況：

4.4 深入分析 HFReduce

實現(xiàn)中的關(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，避免額外的開銷。

克服 EPYC Rome CPU 的限制：作者找 AMD 和 NVIDIA 的工程師幫忙定位了 PCIe 架構(gòu)下通信的次優(yōu)問題。最終發(fā)現(xiàn) EPYC Rome CPU 不支持 chained write 功能，這個功能可以大幅提升 GPU 和 IB 之間的 PCIe P2P 帶寬。作者測試發(fā)現(xiàn)，Rome CPU 上 IB NIC 和 GPU 的極限帶寬在 9GiB/s，這也就可以解釋上述 NCCL 的 AllReduce 帶寬不超過 4GB/s。而 HFReduce 通過在 CPU 上進行 Reduce，在 CPU 和 IB 之間傳輸數(shù)據(jù)來規(guī)避這一問題。

HFReduce 的瓶頸：作者統(tǒng)計了一個 Node 上的所有內(nèi)存操作：

• D2H 需要 8 次寫操作（8 個 GPU）。
• 節(jié)點內(nèi) Reduce 涉及 8 次讀操作和 1 次寫操作。
• 節(jié)點間 Reduce 涉及 IB send 2 次讀操作，IB receive 2 次寫操作，以及 1 次 add 操作。
• H2D 利用 GPUDirect 執(zhí)行 2 次讀操作（8 次降低到 2 次）。

整體來說，上述內(nèi)存操作相比 GPU 上的數(shù)據(jù)大小涉及 24x 的放大。一個 16 Channel 的 DDR4-3200MHz 內(nèi)存，理論最大內(nèi)存帶寬為 320GB/s，對應(yīng)理論最大 HFReduce 帶寬為 320/24=13.3GB/s，而作者實測只有 8GB/s。

上述問題的主要原因是 EPYC CPU 的另一個限制，本文中作者的 GPU5 和 GPU6 直接通過相同的 PCIe Host Bridge 連接到 CPU。而 AMD EPYC Rome 和 Milan CPU 中 PCIe Host Bridge 的最大帶寬為 37.5GB/s，即使 PCIe 4.0x16 從 GPU 到 CPU 可以實現(xiàn) 27GB/s。但是當(dāng) 2 個 GPU 同時傳輸數(shù)據(jù)時將受到上述 37GB/s 的限制，也就是說平均最大只能達到 19GB/s。如果考慮雙向傳輸，帶寬瓶頸會更加明顯。而作者加裝的 NVLink Bridge （GPU5 和 GPU6 通過 NVLink Bridge 互聯(lián)）可以提供一種有效的方案來緩解這個問題。此外，即使 AMD EPYC Genoa 也同樣面對這個問題。

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

5.1 HaiScale DDP

Pytorch DDP 會使用 NCCL 用于梯度聚合時的 AllReduce 操作，而本文中，作者使用 HFReduce 替換 NCCL。如下圖（a）所示，訓(xùn)練 VGG 模型時，基于 HFReduce 的時延幾乎是 Pytorch DDP（NCCL）的一半。同時，從 32 GPU 擴展到 512 GPU 時可以獲得 88% 的線性加速。

5.2 LLM 訓(xùn)練優(yōu)化

針對 LLM 訓(xùn)練，作者同樣優(yōu)化了 DP、PP、TP 和 EP。

將 NVLink Bridge 連接的 2 個 GPU 用于 TP，實現(xiàn)高速互聯(lián)。（PS：通常使用 NVLink + NVSwitch 的方案可以更好的是指 8 GPU 的 TP）

針對 PCIe 架構(gòu)優(yōu)化 PP。一臺機器只有 1 個 NIC，使用 PP 時可能存在瓶頸，為此，作者在調(diào)度時將不同的 DP Rank 調(diào)度到同一個 Node 上，這樣可以交錯 DP 和 PP。如下圖 Figure 9（a）所示，訓(xùn)練 LLaMA 13B 時，GPU 數(shù)從 32 擴展到 512，每一個 Step 的 Latency 從 64.118s 減少到 9.717s，獲得了理論加速 91% 的加速效果。如下圖 Figure 9（b）所示，DeepSeek-MoE 16B 訓(xùn)練時同樣獲得了理論加速的 92.92%。

HaiScale FSDP：此外，作者也對 FSDP 進行了適配和優(yōu)化，如下圖（b）所示，從 16 GPU 到 128 GPU，HaiScale 可以獲得 95% 的加速。

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

6.1 計算-存儲網(wǎng)絡(luò)擁塞最小

如前所述，作者的網(wǎng)絡(luò)方案中計算和存儲在一個網(wǎng)絡(luò)中，相較而言，之前的方案中往往是計算網(wǎng)絡(luò)是高速后向網(wǎng)絡(luò)，而存儲網(wǎng)絡(luò)是前向網(wǎng)絡(luò)。因此，為了實現(xiàn)最大帶寬，必須隔離不同類型的流量，避免相互干擾并造成網(wǎng)絡(luò)擁塞。具體來說，作者實施了以下幾個措施。

不同流量區(qū)分：在典型的訓(xùn)練任務(wù)中，有 4 種不同類型的流量：HFReduce 通信，NCCL 通信，3FS 存儲流量和其他流量。作者利用 IB 的 Service Level（SL）技術(shù)，在節(jié)點之間建立連接時為其分配不同的 SL 值，并將 SL 映射到 IB 物理隊列虛擬通道（VL），使用虛擬通道可以確保不同通道中的流量不會相互干擾。最終，通過配置它們的比例實現(xiàn)流量隔離，從而防止 Head-of-Line（HOL）阻塞和不同的流量沖突引起的網(wǎng)絡(luò)阻塞。

拓?fù)湔{(diào)整和路由優(yōu)化：在高吞吐存儲場景中，存在許多 incast 通信模式，導(dǎo)致?lián)砣ａ槍@種情況，作者采用靜態(tài)路由策略，將存儲流量均勻分散在不同 Leaf -> Spine 連接，并將各種節(jié)點（存儲、計算、管理）均勻分配到 Leaf -> Spine 連接。

NCCL 優(yōu)化：調(diào)整了 NCCL 拓?fù)?，以便調(diào)整同一個 Node 內(nèi)的 IB NIC 和 GPU 的路由?？梢詼p少 CPU chiplet 互聯(lián)導(dǎo)致的 PCIe 擁塞。此外，通過使用 PCIe Relaxed Ording 進一步減少擁塞并增加帶寬。

3FS 網(wǎng)絡(luò)調(diào)優(yōu)：3FS 實現(xiàn)了一個請求到發(fā)送的控制機制來緩解擁塞。

6.2 3FS 高吞吐分布式存儲

如下圖 Table IV 為本文的 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。?

3FS 系統(tǒng)包含 4 個角色：Cluster Manager、Meta Service、Storage Service 和 Client。其中 Storage Service 會部署在每個 Storage Node 上，每個 Storage Service 都能提供等分的帶寬。根據(jù)這個設(shè)計，每個 Client 都可以訪問每個 Storage Service。峰值負(fù)載時，作者在 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)鍵所在。

6.3 HAI Platform

作者很早就開源了其對應(yīng)的分布式訓(xùn)練平臺，具體可以參考源碼（GitHub - HFAiLab/hai-platform: 一種任務(wù)級GPU算力分時調(diào)度的高性能深度學(xué)習(xí)訓(xùn)練平臺）和文檔（歡迎來到HAI Platform 官方文檔）。這里不再介紹。

七、穩(wěn)定性和魯棒性

7.1 Checkpoint 管理

在超大規(guī)模訓(xùn)練中，各種異常是在所難免的，為了減少異常導(dǎo)致的計算浪費，通常都會采用 Checkpointing 機制，定期保存 Checkpoint。本文中 Checkpoint 的保存同樣依賴上述的 3FS，每個 Node 可以提供 10 GiB 的帶寬，所以通?？梢栽趲酌霑r間完成 Checkpoint 的保存。在作者的訓(xùn)練過程中，通常是每 5 分鐘保存一次，也就是每次異常最多浪費 5 分鐘的訓(xùn)練。

7.2 驗證

增強設(shè)備穩(wěn)定性最好的手段就是在發(fā)生異常之前檢測到異常。因此作者開發(fā)了一系列的驗證工具來識別是否存在硬件故障，然后平臺可以自動進行一些運維工作。比如從集群中屏蔽異常機器，不允許調(diào)度。驗證主要包括下述部分：

• 經(jīng)常檢測硬件，比如連接速度，狀態(tài)。
• CPU 壓測及內(nèi)存帶寬壓測。
• GPU Memory 測試。
• GPU 運行 GEMM 測試。
• 節(jié)點內(nèi) AllReduce 測試。
• 存儲帶寬壓測。

7.2 硬件故障

最常見的硬件問題包含兩種：GPU Xid Error 和網(wǎng)絡(luò)抖動。

如下圖 Table V 所示，作者展示了常見的 Xid Error 和對應(yīng)的原因：

如下圖 Table VI 所示，作者也展示了不同 Xid Error 的數(shù)量和比例，可以看出，NVLink Error 占比 42.57%，這可能和作者使用的 NVLink Bridge 有關(guān)。而 Xid 31 和 Xid 43 的軟件錯誤總共超過了 50%，這種情況大部分是程序問題，如果排除程序問題那也基本可以確定是硬件故障。

如下圖 Figure 11 所示，作者同樣頻繁受到網(wǎng)絡(luò)抖動的影響：

八、參考鏈接

1. ??https://www.arxiv.org/abs/2408.14158??
2. ??https://github.com/NVIDIA/gdrcopy??
3. ??https://github.com/HFAiLab/hai-platform??
4. ??https://hfailab.github.io/hai-platform/??

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