1. 深度學(xué)習(xí)的算力饑渴與 HPC 的成本困境

深度學(xué)習(xí)的浪潮，正以勢不可擋的姿態(tài)席卷而來。從圖像識別領(lǐng)域的 AlexNet 和 ResNet，到自然語言處理領(lǐng)域的 Transformer，再到如今參數(shù)規(guī)模動輒千億、萬億的大型語言模型 (LLM)，如 GPT-3 和 PaLM，以及混合專家模型 (MoE) 和多模態(tài)模型，深度學(xué)習(xí)模型的能力在不斷突破，但其背后對計算資源的需求也呈現(xiàn)出爆炸式的增長。

高性能計算 (HPC) 集群，作為支撐深度學(xué)習(xí)訓(xùn)練的基石，其重要性日益凸顯。然而，傳統(tǒng)的 HPC 集群，往往面向雙精度科學(xué)計算，對深度學(xué)習(xí)訓(xùn)練的支持并不完美。基于 GPU 的 HPC 集群雖然能夠較好地支持深度學(xué)習(xí)訓(xùn)練，但隨著模型規(guī)模的不斷擴(kuò)大，建設(shè)成本也急劇攀升。更快的計算芯片和互連技術(shù)固然性能強(qiáng)勁，但其高昂的價格卻讓許多研究機(jī)構(gòu)和企業(yè)望而卻步。此外，大規(guī)模集群的能耗問題也日益突出，不僅增加了運(yùn)營成本，也對環(huán)境可持續(xù)性構(gòu)成了挑戰(zhàn)。

如何在滿足深度學(xué)習(xí)日益增長的算力需求的同時，控制 HPC 集群的建設(shè)成本和能耗，成為了一個擺在整個行業(yè)面前的難題。這不僅僅是一個技術(shù)問題，更是一個關(guān)乎深度學(xué)習(xí)未來發(fā)展方向的關(guān)鍵問題。

2. Fire-Flyer AI-HPC：軟硬件協(xié)同設(shè)計的破局之道

DeepSeek-AI 的研究團(tuán)隊敏銳地捕捉到了這一挑戰(zhàn)，依托于實(shí)踐提出了 Fire-Flyer AI-HPC 這一創(chuàng)新性的軟硬件協(xié)同設(shè)計架構(gòu)。Fire-Flyer AI-HPC 的核心理念，并非簡單地追求硬件性能的堆砌，而是通過對硬件和軟件的深度融合與精細(xì)優(yōu)化，打造一個高性價比、高可擴(kuò)展性、高穩(wěn)定性的深度學(xué)習(xí)計算平臺。

Fire-Flyer AI-HPC 架構(gòu)的精妙之處，在于它并非孤立地看待計算、網(wǎng)絡(luò)、存儲等各個環(huán)節(jié)，而是將它們作為一個整體進(jìn)行系統(tǒng)性的設(shè)計和優(yōu)化。從計算節(jié)點(diǎn)的硬件配置，到網(wǎng)絡(luò)拓?fù)涞倪x擇，再到通信庫、訓(xùn)練框架、存儲系統(tǒng)以及資源管理平臺的開發(fā)，每一個環(huán)節(jié)都經(jīng)過了精心的考量和定制，以實(shí)現(xiàn)最佳的整體性能和成本效益。

3. Fire-Flyer 2：以 PCIe A100 為核心的務(wù)實(shí)選擇

Fire-Flyer 2 是 Fire-Flyer AI-HPC 架構(gòu)的第一個具體實(shí)現(xiàn)，它選擇了一條務(wù)實(shí)而高效的道路——以 PCIe A100 GPU 為核心，構(gòu)建一個面向深度學(xué)習(xí)和早期 LLM 訓(xùn)練的高性能計算集群。

每個 Fire-Flyer 2 計算節(jié)點(diǎn)的配置都體現(xiàn)了對性能、成本和能耗的精妙平衡。8 個 NVIDIA A100 PCIe GPU 提供了強(qiáng)大的計算能力，足以應(yīng)對當(dāng)前大多數(shù)深度學(xué)習(xí)模型的訓(xùn)練需求。選擇 PCIe 版本的 A100，而非 SXM 版本，是在性能和成本之間做出的權(quán)衡。雖然 SXM 版本的 A100 具有更高的 NVLink 帶寬，但其價格也更為昂貴。對于 Fire-Flyer 2 的目標(biāo)應(yīng)用場景而言，PCIe A100 的性能已經(jīng)足夠，而其更低的成本則能夠顯著降低整個集群的建設(shè)成本。

1 個 Mellanox CX6 200Gbps IB 網(wǎng)卡為計算節(jié)點(diǎn)提供了高速的網(wǎng)絡(luò)連接，確保節(jié)點(diǎn)間的數(shù)據(jù)傳輸不會成為瓶頸。2 顆 AMD 32 核 EPYC Rome/Milan CPU 則承擔(dān)了數(shù)據(jù)預(yù)處理、通信調(diào)度等輔助任務(wù)，與 GPU 形成互補(bǔ)，共同完成深度學(xué)習(xí)訓(xùn)練的各項(xiàng)任務(wù)。512GB 16 通道 DDR4-3200MHz 內(nèi)存則為大規(guī)模數(shù)據(jù)的存儲和訪問提供了充足的容量和帶寬。

Fire-Flyer 2 的計算節(jié)點(diǎn)采用了 GPU 和網(wǎng)卡直連 CPU 的設(shè)計，省去了 PCIe 交換機(jī)。這樣做的好處是最大程度地利用了 PCIe 帶寬，減少了數(shù)據(jù)傳輸?shù)难舆t和開銷。因?yàn)閿?shù)據(jù)不需要經(jīng)過 PCIe 交換機(jī)的轉(zhuǎn)發(fā)，直接在 GPU、網(wǎng)卡和 CPU 之間傳輸，從而提高了整體的通信效率。此外，F(xiàn)ire-Flyer 2 還預(yù)留了 NVLink 橋接的空間，為未來的擴(kuò)展留下了余地。如果將來需要更高的 GPU 間通信帶寬，可以通過安裝 NVLink 橋接器來實(shí)現(xiàn)。

與 NVIDIA 的 DGX-A100 系統(tǒng)相比，F(xiàn)ire-Flyer 2 在成本和能耗方面具有顯著優(yōu)勢。其節(jié)點(diǎn)成本約為 DGX-A100 的 60%，能耗也約為 DGX-A100 的 60%。雖然 PCIe A100 在某些性能測試中略低于 DGX-A100，但考慮到其顯著的成本優(yōu)勢，F(xiàn)ire-Flyer 2 無疑具有更高的性價比。

*上面術(shù)語太多，做個注釋：

SXM版本的A100，更準(zhǔn)確地說是A100 SXM4，是NVIDIA A100 Tensor Core GPU為了極致高性能計算和數(shù)據(jù)中心應(yīng)用而采用SXM4封裝和連接方式的特殊版本，它相比PCIe版本擁有更高的性能潛力、更優(yōu)的NVLink連接及更高的GPU密度，堪比F1賽車專為賽道馳騁。

而NVIDIA DGX A100系統(tǒng)正是為了充分發(fā)揮SXM版本A100的極致性能而設(shè)計的高度集成平臺，DGX A100必須且只能使用SXM接口的A100 GPU模塊，因?yàn)镾XM接口是實(shí)現(xiàn)DGX A100系統(tǒng)內(nèi)8個A100 GPU通過NVLink高速互聯(lián)、達(dá)到極致AI訓(xùn)練和推理性能的關(guān)鍵，正如高鐵列車必須搭載專門設(shè)計的高功率發(fā)動機(jī)才能高速運(yùn)行，DGX A100系統(tǒng)和SXM A100 GPU是為追求極致性能而生的完美組合，PCIe版本的A100則無法滿足DGX A100對GPU互連速度和整體系統(tǒng)性能的苛刻需求。*

4. Fat-Tree 網(wǎng)絡(luò)：高帶寬與精細(xì)調(diào)優(yōu)的結(jié)合

網(wǎng)絡(luò)架構(gòu)對于 HPC 集群的性能至關(guān)重要。Fire-Flyer 2 采用了雙層 Fat-Tree 網(wǎng)絡(luò)拓?fù)?，并將存儲和計算網(wǎng)絡(luò)整合在一起。Fat-Tree 拓?fù)湟云涓叨确謳挼奶匦远Q，能夠確保集群中任意兩個節(jié)點(diǎn)之間都能以較高的帶寬進(jìn)行通信，避免了網(wǎng)絡(luò)擁塞的發(fā)生。這種拓?fù)浣Y(jié)構(gòu)非常適合 AI-HPC 和高吞吐量存儲環(huán)境對網(wǎng)絡(luò)帶寬的嚴(yán)苛要求。

Fire-Flyer 2 的集群被劃分為兩個區(qū)域，每個區(qū)域構(gòu)成一個 800 端口的 Fat-Tree 網(wǎng)絡(luò)，連接大約 600 個 GPU 計算節(jié)點(diǎn)。這種分區(qū)設(shè)計不僅降低了網(wǎng)絡(luò)成本，還支持跨區(qū)域任務(wù)的執(zhí)行，提高了集群的靈活性和利用率。

為了防止網(wǎng)絡(luò)擁塞，F(xiàn)ire-Flyer 2 團(tuán)隊采取了一系列精細(xì)的網(wǎng)絡(luò)調(diào)優(yōu)策略。首先，利用 InfiniBand 的服務(wù)級別 (SL) 技術(shù)，將不同類型的流量（如控制流量、數(shù)據(jù)流量、存儲流量）分配到不同的虛擬通道 (VL) 中。這就像在高速公路上為不同類型的車輛劃分不同的車道，避免了相互干擾，保證了關(guān)鍵流量的優(yōu)先級。其次，采用靜態(tài)路由策略，避免了自適應(yīng)路由 (AR) 可能導(dǎo)致的網(wǎng)絡(luò)擁塞擴(kuò)散問題。自適應(yīng)路由雖然在某些情況下能夠提高網(wǎng)絡(luò)利用率，但在大規(guī)模集群中，其動態(tài)調(diào)整路由的行為可能會導(dǎo)致?lián)砣目焖俾?，反而降低整體性能。靜態(tài)路由則像預(yù)先規(guī)劃好的路線，雖然可能不是在所有情況下都是最優(yōu)的，但它能夠保證網(wǎng)絡(luò)的穩(wěn)定性和可預(yù)測性。再次，將存儲節(jié)點(diǎn)、計算節(jié)點(diǎn)和管理節(jié)點(diǎn)均勻地分布在網(wǎng)絡(luò)中，使得存儲流量能夠均勻地分散到各個鏈路，避免了局部熱點(diǎn)的產(chǎn)生。最后，針對 NCCL (NVIDIA Collective Communications Library) 進(jìn)行了深度優(yōu)化，調(diào)整 NCCL 拓?fù)洌蛊鋬?yōu)先在同一 NUMA 節(jié)點(diǎn)的 IB 網(wǎng)卡和 GPU 之間進(jìn)行通信，減少跨 NUMA 節(jié)點(diǎn)通信帶來的 PCIe 擁塞；同時，啟用了 PCIe Relaxed Ordering，進(jìn)一步降低擁塞，提高帶寬利用率。

5. HFReduce：通信庫的創(chuàng)新，突破 allreduce 瓶頸

在大規(guī)模深度學(xué)習(xí)訓(xùn)練中，allreduce 操作是一個非常頻繁且耗時的操作。它負(fù)責(zé)將所有 GPU 上計算得到的梯度進(jìn)行匯總，然后更新模型的參數(shù)。傳統(tǒng)的 allreduce 實(shí)現(xiàn)，如 NCCL，雖然已經(jīng)經(jīng)過了高度優(yōu)化，但在 PCIe 架構(gòu)下，仍然存在一定的性能瓶頸。

為了解決這個問題，F(xiàn)ire-Flyer 2 團(tuán)隊自主研發(fā)了 HFReduce 通信庫，專門針對 allreduce 操作進(jìn)行了深度優(yōu)化。HFReduce 的核心思想是“先局部 reduce，再全局 allreduce”。它巧妙地利用了 CPU 和 GPU 各自的優(yōu)勢。首先，在每個節(jié)點(diǎn)內(nèi)部，利用 CPU 的向量指令（如 AVX512）對節(jié)點(diǎn)內(nèi)所有 GPU 的數(shù)據(jù)進(jìn)行快速 reduce 操作。由于 CPU 擅長執(zhí)行向量化計算，這一步能夠非常高效地完成。然后，將每個節(jié)點(diǎn) reduce 后的結(jié)果，利用雙二叉樹算法和 RDMA 傳輸，進(jìn)行節(jié)點(diǎn)間的 allreduce 操作。雙二叉樹算法能夠有效地減少通信的跳數(shù)，降低通信延遲；RDMA 傳輸則能夠直接在節(jié)點(diǎn)間進(jìn)行數(shù)據(jù)傳輸，避免了 CPU 的參與，進(jìn)一步降低了開銷。

這種分而治之的策略，使得 HFReduce 相比于 NCCL 具有顯著的優(yōu)勢。首先，它大幅降低了 PCIe 帶寬的消耗。由于節(jié)點(diǎn)內(nèi)部的 reduce 操作已經(jīng)在 CPU 上完成，節(jié)點(diǎn)間只需要傳輸 reduce 后的結(jié)果，數(shù)據(jù)量大大減少，從而降低了對 PCIe 帶寬的壓力。尤其是在大規(guī)模集群中，這一優(yōu)勢更加明顯。其次，它消除了 GPU 內(nèi)核的開銷。HFReduce 的 reduce 操作完全在 CPU 上進(jìn)行，不占用寶貴的 GPU 計算資源，避免了 NCCL 的 GPU 內(nèi)核啟動開銷，使得 GPU 能夠更專注于深度學(xué)習(xí)模型的計算。

為了進(jìn)一步提升性能，HFReduce 還支持 NVLink 加速。通過在 PCIe A100 GPU 之間安裝 NVLink 橋接器，可以利用 NVLink 的高帶寬進(jìn)行 GPU 之間的預(yù) reduce 操作，進(jìn)一步減少 PCIe 帶寬的壓力，然后再將結(jié)果傳輸?shù)?CPU 進(jìn)行最終的 allreduce。

HFReduce 的實(shí)現(xiàn)細(xì)節(jié)也體現(xiàn)了精益求精的工匠精神。對于小數(shù)據(jù)量的傳輸，利用 GDRCopy (GPU Direct RDMA) 技術(shù)，直接在 GPU 之間進(jìn)行數(shù)據(jù)拷貝，避免了 CPU 的參與，降低了延遲；利用 CPU 的 SIMD (Single Instruction, Multiple Data) 指令，如 AVX512，對 reduce 操作進(jìn)行向量化加速，充分發(fā)揮 CPU 的計算能力；優(yōu)化內(nèi)存訪問模式，減少跨 NUMA 節(jié)點(diǎn)訪問內(nèi)存帶來的延遲；利用 RDMA (Remote Direct Memory Access) 技術(shù)，實(shí)現(xiàn)高效的節(jié)點(diǎn)間數(shù)據(jù)傳輸，避免額外的 CPU 開銷。

6. HaiScale：為深度學(xué)習(xí)量身打造的訓(xùn)練框架

HaiScale 是 Fire-Flyer 2 AI-HPC 的深度學(xué)習(xí)訓(xùn)練框架，它不僅僅是一個簡單的訓(xùn)練工具，而是針對 PCIe 架構(gòu)進(jìn)行了全方位的優(yōu)化，旨在最大程度地發(fā)揮硬件性能，為深度學(xué)習(xí)訓(xùn)練提供強(qiáng)大的支持。

HaiScale 實(shí)現(xiàn)了一個增強(qiáng)版的分布式數(shù)據(jù)并行 (DDP) 算法。通過異步 allreduce 和反向傳播計算的重疊，HaiScale 進(jìn)一步提高了訓(xùn)練效率。傳統(tǒng)的 DDP 算法在進(jìn)行 allreduce 操作時，需要等待所有 GPU 完成梯度計算，然后才能進(jìn)行參數(shù)更新。HaiScale 則將 allreduce 操作和反向傳播計算進(jìn)行重疊，即在 GPU 計算梯度的同時，就開始進(jìn)行部分 allreduce 操作，從而隱藏了通信延遲，提高了整體的訓(xùn)練效率。

針對 LLM 訓(xùn)練，HaiScale 提供了多種并行化策略的支持，包括張量并行 (TP)、流水線并行 (PP) 和全分片數(shù)據(jù)并行 (FSDP)。對于需要高帶寬的張量并行操作，HaiScale 支持利用 NVLink 橋接，實(shí)現(xiàn) PCIe GPU 之間的張量并行，提升 TP 效率。對于流水線并行，HaiScale 通過精細(xì)的數(shù)據(jù)并行 rank 配置，錯開不同流水線階段的執(zhí)行時間，減少網(wǎng)絡(luò)競爭，提升流水線并行的效率。對于全分片數(shù)據(jù)并行 (FSDP)，HaiScale 針對 PCIe 架構(gòu)進(jìn)行了深度優(yōu)化，包括高效的內(nèi)存管理，減少內(nèi)存碎片，提升內(nèi)存利用率；以及通信與計算重疊，將參數(shù)的通信和計算過程進(jìn)行重疊，隱藏通信延遲。

除了上述策略外，HaiScale 還支持 ZeRO (Zero Redundancy Optimizer) 等其他并行化策略。用戶可以根據(jù)不同的模型和訓(xùn)練需求，靈活選擇合適的策略，實(shí)現(xiàn)最佳的訓(xùn)練效率。HaiScale 的這種靈活性和可擴(kuò)展性，使得它能夠適應(yīng)各種不同的深度學(xué)習(xí)訓(xùn)練場景。

7. 存儲、資源管理與穩(wěn)定性：全方位的保障

Fire-Flyer 2 采用了計算-存儲一體化網(wǎng)絡(luò)設(shè)計，將計算流量和存儲流量融合在同一網(wǎng)絡(luò)中，簡化了網(wǎng)絡(luò)架構(gòu)，降低了成本。為了避免網(wǎng)絡(luò)擁塞，F(xiàn)ire-Flyer 2 采取了前面提到的多種網(wǎng)絡(luò)調(diào)優(yōu)策略。

在存儲方面，F(xiàn)ire-Flyer 2 采用了自主研發(fā)的 3FS 分布式文件系統(tǒng)。3FS 針對 NVMe SSD 和 RDMA 網(wǎng)絡(luò)進(jìn)行了專門的優(yōu)化，實(shí)現(xiàn)了高吞吐量和低延遲，滿足了深度學(xué)習(xí)訓(xùn)練對存儲系統(tǒng)的高要求。3FS 存儲節(jié)點(diǎn)的配置包括：1 顆 AMD 64 核 EPYC 7742 CPU，512GB 8 通道 DDR4-3200MHz 內(nèi)存，2 個 Mellanox CX6 200Gbps IB 網(wǎng)卡，以及 16 個 15.36TB PCIe 4.0x4 NVMe SSD。

3FS 的核心技術(shù)之一是采用了 Chain Replication with Apportioned Queries (CRAQ) 協(xié)議。CRAQ 實(shí)現(xiàn)了強(qiáng)一致性和高性能。它將讀寫操作分離，寫操作在鏈?zhǔn)綇?fù)制的尾節(jié)點(diǎn)執(zhí)行，讀操作可以在任意節(jié)點(diǎn)執(zhí)行，從而提高了讀性能。此外，3FS 還通過精細(xì)的請求發(fā)送控制機(jī)制，有效地緩解了網(wǎng)絡(luò)擁塞，實(shí)現(xiàn)了可持續(xù)的高吞吐量。

為了進(jìn)一步提升 LLM 服務(wù)的效率和經(jīng)濟(jì)性，F(xiàn)ire-Flyer 2 還開發(fā)了 3FS-KV 分布式數(shù)據(jù)處理系統(tǒng)，支持 KV 存儲、消息隊列和對象存儲等多種模式，并支持 DeepSeek 的 KV Context Caching on Disk 技術(shù)，可以將 LLM 服務(wù)的成本降低一個數(shù)量級。

在任務(wù)調(diào)度和資源管理方面，F(xiàn)ire-Flyer 2 采用了 HAI 平臺。HAI 平臺采用分時調(diào)度策略，根據(jù)資源需求和集群負(fù)載情況進(jìn)行任務(wù)調(diào)度，并鼓勵用戶進(jìn)行多 GPU 并行訓(xùn)練，提高資源利用率。

為了保證集群的穩(wěn)定可靠運(yùn)行，F(xiàn)ire-Flyer 2 實(shí)現(xiàn)了多種機(jī)制，包括檢查點(diǎn)管理器 (Checkpoint Manager) 和驗(yàn)證器 (Validator)。檢查點(diǎn)管理器能夠?qū)⒛Ｐ蛥?shù)和優(yōu)化器狀態(tài)分塊寫入 3FS，實(shí)現(xiàn)快速保存和加載，并采用周期性異步保存策略，減少硬件故障帶來的損失。驗(yàn)證器則定期檢查硬件的運(yùn)行狀態(tài)，及時發(fā)現(xiàn)潛在問題。

8. 總結(jié)與展望：Fire-Flyer AI-HPC 的深遠(yuǎn)意義

Fire-Flyer 2 AI-HPC 不僅僅是一個高性能計算集群，更是一個深度學(xué)習(xí)軟硬件協(xié)同設(shè)計的典范。它通過對計算節(jié)點(diǎn)、網(wǎng)絡(luò)架構(gòu)、通信庫、訓(xùn)練框架、存儲系統(tǒng)以及資源管理平臺的全面優(yōu)化，實(shí)現(xiàn)了深度學(xué)習(xí)訓(xùn)練的高性能、低成本和可持續(xù)性。Fire-Flyer 2 的成功，證明了軟硬件協(xié)同設(shè)計在構(gòu)建高性價比 AI 基礎(chǔ)設(shè)施方面的巨大潛力。

Fire-Flyer AI-HPC 的研究成果和實(shí)踐經(jīng)驗(yàn)，為 AI-HPC 集群的建設(shè)和發(fā)展提供了寶貴的參考，也為深度學(xué)習(xí)的未來發(fā)展奠定了堅實(shí)的基礎(chǔ)。隨著深度學(xué)習(xí)技術(shù)的不斷演進(jìn)，F(xiàn)ire-Flyer AI-HPC 也將持續(xù)創(chuàng)新，不斷探索 AI-HPC 架構(gòu)的未來，為人工智能的發(fā)展貢獻(xiàn)力量。

附錄

對于NVlink，DeepSeek的研究人員是邊用邊罵：

B. Discussion about NVLink Technology Choices

Initially, we did not use NVLink to avoid extra costs and maintain stability, as HFReduce was sufficient for training requirements at that time. However, as the demand for LLMs increased, we added NVLink specifically for LLM training purposes. The decision to install NVLink should be based on actual needs due to its potential drawbacks。

還在附錄里列出了關(guān)鍵的典型錯誤：

IB網(wǎng)絡(luò)也被吐槽的體無完膚，這也許是之前英偉達(dá)股票狂跌的原因之一吧

圖片

。

而且仔細(xì)想一想，結(jié)合后面DeepSeek V3的論文中專門強(qiáng)調(diào)了對于內(nèi)存讀寫和網(wǎng)絡(luò)框架及驅(qū)動的優(yōu)化內(nèi)容（甚至用了PTX），并且被誤解為要取代CUDA。就知道他們是在踩坑的同時填坑，填完了坑才有了這種軟硬件一體化設(shè)計的論文公開。

參考論文： arXiv:2408.14158v2 [cs.DC] 31 Aug 2024

本文轉(zhuǎn)載自??上堵吟??，作者：  ??上堵吟??