?一、背景

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

本文中我們介紹一下幻方 AI 訓練 DeepSeek 系列模型使用的大規模 GPU 集群以及相應的各種優化手段。

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

二、摘要

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

本文中涉及的關鍵技術點為：

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

PS：

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

三、Fire-Flyer 2：網絡架構

3.1 PCIe A100 GPU 架構

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

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

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

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

3.2 網絡拓撲

如下圖所示為本文作者提出的兩層 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：

• 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 數量以及成本，具體如下圖 Table 3 所示：

• 本文：122 個 Switch：(40+20)*2+2。
• PCIe 架構 + 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 個后向網絡 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 下一代網絡拓撲

作者也在準備構建下一代的 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。

四、HFReduce：軟硬協同網絡設計

4.1 HFReduce 算法

在大規模分布式訓練中，AllReduce 是一種非常常見的集合通信操作，比如不同 Data Parallelism 之間的梯度聚合操作。而 NCCL 通常是針對節點內有 NVLink 高速互聯或者都通過 NIC 方式通信的范式進行優化的。針對本文這種網絡拓撲不一定能發揮最優的性能。如下圖 Figure 6 所示為作者優化之后的 HFReduce 概覽，其包含幾步：

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

節點內的 Reduce 操作算法如下圖 Algorithm 1 所示：

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

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

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

4.2 HFReduce 對比 NCCL

針對本文的網絡拓撲，作者提出的方案相比 NCCL 有 2 個優勢：

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

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

4.3 HFReduce with NVLink

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

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

4.4 深入分析 HFReduce

實現中的關鍵技術決策：

• 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，避免額外的開銷。

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

HFReduce 的瓶頸：作者統計了一個 Node 上的所有內存操作：

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

整體來說，上述內存操作相比 GPU 上的數據大小涉及 24x 的放大。一個 16 Channel 的 DDR4-3200MHz 內存，理論最大內存帶寬為 320GB/s，對應理論最大 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 可以實現 27GB/s。但是當 2 個 GPU 同時傳輸數據時將受到上述 37GB/s 的限制，也就是說平均最大只能達到 19GB/s。如果考慮雙向傳輸，帶寬瓶頸會更加明顯。而作者加裝的 NVLink Bridge （GPU5 和 GPU6 通過 NVLink Bridge 互聯）可以提供一種有效的方案來緩解這個問題。此外，即使 AMD EPYC Genoa 也同樣面對這個問題。

五、HaiScale：針對 DL 訓練優化

5.1 HaiScale DDP

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

5.2 LLM 訓練優化

針對 LLM 訓練，作者同樣優化了 DP、PP、TP 和 EP。

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

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

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

六、聯合優化

6.1 計算-存儲網絡擁塞最小

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

不同流量區分：在典型的訓練任務中，有 4 種不同類型的流量：HFReduce 通信，NCCL 通信，3FS 存儲流量和其他流量。作者利用 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 實現了一個請求到發送的控制機制來緩解擁塞。

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 系統包含 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 的關鍵所在。

6.3 HAI Platform

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

七、穩定性和魯棒性

7.1 Checkpoint 管理

在超大規模訓練中，各種異常是在所難免的，為了減少異常導致的計算浪費，通常都會采用 Checkpointing 機制，定期保存 Checkpoint。本文中 Checkpoint 的保存同樣依賴上述的 3FS，每個 Node 可以提供 10 GiB 的帶寬，所以通常可以在幾秒時間完成 Checkpoint 的保存。在作者的訓練過程中，通常是每 5 分鐘保存一次，也就是每次異常最多浪費 5 分鐘的訓練。

7.2 驗證

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

• 經常檢測硬件，比如連接速度，狀態。
• CPU 壓測及內存帶寬壓測。
• GPU Memory 測試。
• GPU 運行 GEMM 測試。
• 節點內 AllReduce 測試。
• 存儲帶寬壓測。

7.2 硬件故障

最常見的硬件問題包含兩種：GPU Xid Error 和網絡抖動。

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

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

如下圖 Figure 11 所示，作者同樣頻繁受到網絡抖動的影響：

八、參考鏈接

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

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