一、引言

最近 imbue 發(fā)布了其自研的 Imbue 70B 模型，各項(xiàng)能力與 LLaMA-3 70B 相當(dāng)，在推理相關(guān)的任務(wù)上表現(xiàn)優(yōu)于 zero-shot 的 GPT-4o。更難能可貴的是，Imbue 也進(jìn)一步分享了他們從 0 到 1 構(gòu)建一個(gè)大規(guī)模 GPU 集群的端到端指南（From bare metal to a 70B model: infrastructure set-up and scripts - imbue）：包括網(wǎng)絡(luò)拓?fù)?，系統(tǒng)安裝，模型訓(xùn)練遇到的各種異常，以及各種解決方案。除此之外，作者還開源了相關(guān)的工具和腳本：GitHub - imbue-ai/cluster-health。本文中我們對其進(jìn)行介紹，并根據(jù)我們的經(jīng)驗(yàn)進(jìn)行注解和完善。

其實(shí)最近很多公司都公布了相關(guān)的 AI Infrastructure 以及工作，比如：

• 字節(jié)跳動(dòng) MegaScale：[2402.15627] MegaScale: Scaling Large Language Model Training to More Than 10,000 GPUs
• 上海 AI Lab 等 Acme：[2403.07648] Characterization of Large Language Model Development in the Datacenter
• 阿里 C4：[2406.04594] Boosting Large-scale Parallel Training Efficiency with C4: A Communication-Driven Approach
• 阿里 HPN：Alibaba HPN: A Data Center Network for Large Language Model Training
• 騰訊星脈網(wǎng)絡(luò) 2.0：大模型訓(xùn)練再提速20%！騰訊星脈網(wǎng)絡(luò)2.0來了
• 百度 HPN - AI Pod：徹底解決網(wǎng)絡(luò)哈希沖突，百度百舸的高性能網(wǎng)絡(luò)HPN 落地實(shí)踐
• 螞蟻金服 DLRover：DLRover: An Automatic Distributed Deep Learning System

我們也介紹過一系列相關(guān)工作，比如：

• ??阿里 HPN：針對大規(guī)模 LLM 訓(xùn)練的萬卡集群??
• ??萬卡 GPU 集群互聯(lián)：硬件配置和網(wǎng)絡(luò)設(shè)計(jì)??
• ??萬卡 GPU 集群實(shí)戰(zhàn)：探索 LLM 預(yù)訓(xùn)練的挑戰(zhàn)??
• ??阿里 C4：通信驅(qū)動(dòng)加速大規(guī)模并行訓(xùn)練效率??
• ??剖析大規(guī)模 GPU 集群：針對 LLM 場景的挑戰(zhàn)和優(yōu)化??
• ??HPN 7.0：阿里云新一代萬卡集群網(wǎng)絡(luò)架構(gòu)??

二、4088 H100 集群搭建

2.1 概覽

如下圖所示為 Imbue 從 0 開始搭建的大規(guī)模 GPU 集群?？偣舶?511 個(gè) 8*H100 GPU 節(jié)點(diǎn)，共 4088 個(gè) H100 GPU（PS：后文會(huì)介紹為什么不是 512 臺(tái) 4096 GPU）。通過 3-Tier IB 網(wǎng)絡(luò)實(shí)現(xiàn)無收斂（fully non-blocking）拓?fù)洌?/p>

2.2 8*H100 Server

如下圖所示為單個(gè) 8*H100 節(jié)點(diǎn)的配置：

• GPU：包含 8 個(gè) H100 SXM GPU，并且 8 個(gè) GPU 使用 NVLink 互聯(lián)，而沒有使用 NVSwitch。（PS：這里提到了未使用 NVSwitch，如紅框所示 “Avoid the term NVSwitch”，不理解為何不用 NVSwitch 實(shí)現(xiàn)全互聯(lián)）
• 后向網(wǎng)絡(luò)：包含 8 個(gè) ConnectX-7 的 InfiniBand NIC，帶寬為 400 Gbps，其中每個(gè) GPU 對應(yīng)一個(gè) NIC，并與 Leaf Switch 連接。
• 前向網(wǎng)絡(luò)：包含 2 個(gè) Ethernet NIC，每個(gè) 100 Gbps。

一個(gè)構(gòu)建前向的數(shù)據(jù)傳輸網(wǎng)絡(luò)，主要用于傳輸數(shù)據(jù)集、Checkpoint 以及其他數(shù)據(jù)。

另一個(gè)用于組成輔助管理網(wǎng)絡(luò)，純粹用于配置和管理，允許訪問 BIOS、電源等其他 low level 控制接口。如果沒有這個(gè)網(wǎng)絡(luò)，將不得不使用 USB 驅(qū)動(dòng)器等方式手動(dòng)配置節(jié)點(diǎn)，對于大規(guī)模集群來說不太現(xiàn)實(shí)。

• 存儲(chǔ)：一個(gè) 512GB 的硬盤用于安裝 OS；還有一組 5 個(gè) Raid2 NVME，總共 14TB 空間。
• 管理：通過 iDRAC（戴爾的基板管理控制器）可以安裝 OS；BMC（Baseboard Management Controller） 就是用于上述的輔助管理網(wǎng)絡(luò)。?

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

其網(wǎng)絡(luò)拓?fù)鋺?yīng)該是參考了 NVIDIA H100 的標(biāo)準(zhǔn)方案，IB 網(wǎng)絡(luò)采用的是 QM97xx 交換機(jī)，每個(gè)有 64 個(gè) 400Gbps 的 Port，在 Leaf 和 Spine 中都是 32 個(gè)下行 Port，32 個(gè) 上行 Port：

如下圖所示為其對應(yīng)的網(wǎng)絡(luò)拓?fù)?，?NVIDIA 的 SuperPod 基本一致，總共 320 個(gè) Switch（PS：詳細(xì)介紹可以參考我們之前的文章）：

• 128 個(gè) Leaf Switch（T2）：共 16 組，每組 8 個(gè) Switch，連接 32 個(gè) Node。每組中的 0 號(hào) Switch 連接 32 個(gè) Node 中的 0 號(hào) NIC（GPU），7 號(hào) Switch 連接 32 個(gè) Node 中的 7 號(hào) NIC（GPU）。
• 128 個(gè) Spine Switch（T3）：共 8 組，每組 16 個(gè) Switch，連接 16 個(gè) Leaf Switch。每一組 Spine Switch 都會(huì)與 Leaf Switch 中的對應(yīng)位置互聯(lián)。比如，第 5 個(gè) Spine Switch Group 會(huì)把 16 組 Leaf Switch 中的第 5 號(hào) Switch 連接起來。（PS：這樣的好處是，集群中同卡號(hào) GPU 通信，最多只用經(jīng)過 Spine Switch，而不用經(jīng)過 Super Spine Switch）
• 64 個(gè) Super Spine Switch（T4）：每一個(gè) Super Spine Switch 都會(huì)連接 64 個(gè) Spine Switch，也就是可以分 2 組，每組 32 個(gè)，連接 64 個(gè) Spine Switch。?

2.4 NVIDIA DGX H100 SuperPod 

如下圖 Figure 5 所示為一個(gè) 127 Node 的 NVIDIA DGX SuperPod。理論上應(yīng)該可以連接 128 個(gè) Node，但是 Leaf Switch 有一部分連接了 UFM（Unified Fabric Manager），所以實(shí)際上只有 127 個(gè) Node。

如下圖 Table 3 所示，使用 QM9700 Switch，2 級 Fat-Tree 最多可以實(shí)現(xiàn) 64*64/2=2048 GPU 的無阻塞網(wǎng)絡(luò)；3 級 Fat-Tree 最多可實(shí)現(xiàn) 64*64*64/4=65536 GPU 的無阻塞網(wǎng)絡(luò)。不過 Imbue 采用的是 16 SU 方案，最多可以連接 4096 GPU（PS：實(shí)際上還有 UFM，所以是 4088 GPU）：

2.5 4096 GPU or UFM？

 為什么要引入 UFM 而不是構(gòu)成 512 Node 的完全對稱結(jié)構(gòu)呢？可能是兩個(gè)方面的考慮：

• 通過引入 UFM，可以實(shí)現(xiàn)更高效、更可靠的網(wǎng)絡(luò)管理，從而提升整體系統(tǒng)性能和穩(wěn)定性。
• GPU Node 故障率很高，很難保證長時(shí)間無異常，Node 異常后通常需要屏蔽，此時(shí)也就無法實(shí)現(xiàn)完全對稱。如果想依舊保持對稱，就需要增加冗余節(jié)點(diǎn)，像阿里的 HPN：Alibaba HPN: A Data Center Network for Large Language Model Training，但是這又會(huì)導(dǎo)致無法實(shí)現(xiàn)完全的無收斂網(wǎng)絡(luò)。?

三、集群初始化

3.1 Node 初始化

通過輔助管理網(wǎng)絡(luò)和 BMC（Baseboard Management Controller，即使 OS 未啟動(dòng)或 Node 宕機(jī)，BMC 依然可以工作，提供對系統(tǒng)的訪問和控制），可以與每臺(tái)機(jī)器進(jìn)行交互，實(shí)現(xiàn)對硬件的監(jiān)控和管理。

3.1.1 安裝一個(gè) Node

首先使用 iDRAC（戴爾的基板管理控制器）在單個(gè) Node 上安裝 Ubuntu 22.04，該 Node 將用于設(shè)置其他所有內(nèi)容。IDRAC 允許從本地計(jì)算機(jī)掛載和啟動(dòng) ISO image，并在瀏覽器中提供一個(gè)虛擬控制臺(tái)。理想情況下，這個(gè)是唯一的手動(dòng)安裝過程。

3.1.2 安裝其它 Node

安裝完第一個(gè) Node 之后，可以繼續(xù)安裝 Ubuntu 的 Metal-as-a-Service (MAAS) 軟件來幫助配置剩余的服務(wù)器。借助 PXE（Preboot eXecution Environment）和 iDRAC 工具，可以指示每個(gè) Node 從網(wǎng)絡(luò)啟動(dòng)，并配置 MAAS 以響應(yīng) PXE 啟動(dòng)請求，然后就可以執(zhí)行相應(yīng)的安裝工作。當(dāng)然，安裝并非一帆風(fēng)順，作者也遇到了一系列問題，比如時(shí)鐘相差太大，導(dǎo)致 HTTPS 證書驗(yàn)證有問題，進(jìn)而導(dǎo)致 apt 無法安裝其他包。

3.1.3 診斷異常 Node

與其他大規(guī)模 GPU 集群初始化一樣，Imbue 發(fā)現(xiàn)大約 10% 的機(jī)器無法啟動(dòng)，主要是硬件問題，比如：以太網(wǎng)網(wǎng)線未連接或者接錯(cuò)、iDRAC 中的硬件問題、電源損壞、NVME 驅(qū)動(dòng)器損壞、網(wǎng)卡或 GPU 無法連接。部分機(jī)器甚至返回戴爾進(jìn)行進(jìn)一步的測試。

3.1.4 軟件安裝

繼續(xù)在每個(gè) node 上安裝以下軟件：

• GPU Driver（PS：集群正常運(yùn)行中想要升級 GPU Driver 通常比較困難，代價(jià)很高，因此通常會(huì)安裝較新的 GPU Driver，以便降低后續(xù)升級的代價(jià)）
• Docker
• Prometheus node exporter（PS：主要是暴露 OS 和硬件的各種指標(biāo)，可以參考GitHub - prometheus/node_exporter: Exporter for machine metrics）
• DCGM exporter（PS：主要是暴露各種 GPU 相關(guān)監(jiān)控指標(biāo)，可以參考GitHub - NVIDIA/dcgm-exporter: NVIDIA GPU metrics exporter for Prometheus leveraging DCGM）
• RaidZ ZFS pool

Imbue 在并行安裝軟件包時(shí)甚至遇到了帶寬瓶頸（PS：需要訪問集群外，帶寬相對集群內(nèi)要小得多），并第一次收到了各種組件的高溫報(bào)警，這一問題通過固件更新進(jìn)行修復(fù)。

3.1.5 單 Node 驗(yàn)證

在安裝完基礎(chǔ)的可運(yùn)行環(huán)境之后，通常還要確保每個(gè) Node 都能獨(dú)立處理真正的 GPU Workload。在這個(gè)過程中作者也發(fā)現(xiàn)了一系列的問題：

• GPU 相關(guān)錯(cuò)誤：主要是通過重新插拔 GPU 解決，需要將 Node 從機(jī)柜中取出，并重新插拔對應(yīng) GPU。
• 固件問題：作者通過 Ubuntu 日志發(fā)現(xiàn) GPU 或網(wǎng)卡等設(shè)備有許多 “l(fā)imited width:x4 <x16” 的錯(cuò)誤，通過更新 PCIe Switch 固件后解決。（PS：我們也遇到了 NIC 固件需要升級的情況??）
• 線纜問題：作者也發(fā)現(xiàn)集群中大約 1/4 的 PCIe 線纜需要重新調(diào)整，這可能是脆弱的線纜位于外殼和 GPU 之間，每當(dāng)有人對 GPU 維護(hù)的時(shí)候它們都可能被擠壓或拔掉。
• 雜項(xiàng)問題：這些問題通常只影響個(gè)別 Node，通常需要硬件廠商協(xié)助。

NVMe Driver 未顯示故障，但 touch 時(shí)會(huì)死機(jī)。

硬盤在 Linux 下隨機(jī)順序顯示，導(dǎo)致 OS 安裝在錯(cuò)誤的盤上。（PS：我們遇到過 OS 被安裝在數(shù)據(jù)盤的情況?? ）

錯(cuò)誤的溫度計(jì)數(shù)，導(dǎo)致風(fēng)扇一直 100% 轉(zhuǎn)速工作。作者發(fā)現(xiàn)部分是 NVIDIA Driver 導(dǎo)致，通過降級解決。

CPU 的睿頻異常，被限制在 2GHz。

Direct GPU-GPU 通信（GDR 或 GPUDirect RDMA Peer Memory Client）無法使用。

PS：在這些軟件安裝完之后就可以正常使用。不過通常還會(huì)進(jìn)行一系列的 Benchmark 測試，比如使用 NVIDIA 的 GitHub - NVIDIA/nvbandwidth: A tool for bandwidth measurements on NVIDIA GPUs. 測試 GPU 的各種通信帶寬，例如 CPU 和 GPU 之間以及 GPU 和 GPU 之間。此外，也經(jīng)常會(huì)使用 GitHub - NVIDIA/cuda-samples: Samples for CUDA Developers which demonstrates features in CUDA Toolkit 和 NVIDIA/nccl-tests。

• 有些時(shí)候一些初始化的配置不符合預(yù)期也可能導(dǎo)致性能不符合預(yù)期，通過 benchmark 可以發(fā)現(xiàn)部分問題，比如說Troubleshooting — NCCL 2.22.3 documentation中提到打開 IO 虛擬化（VT-d or IOMMU）有可能導(dǎo)致性能下降。
• 如下圖所示，我們曾經(jīng)在這個(gè)階段發(fā)現(xiàn) Device to Host 的帶寬明顯低于 Host to Device，不符合預(yù)期，最終定位發(fā)現(xiàn)在初始化時(shí)不小心打開了 Intel 的 Sub NUMA Clustering（SNC），關(guān)閉之后再測試就一切正常，但是為什么 SNC 會(huì)導(dǎo)致 dtoh 和 htod 通信帶寬不一致我們沒有找到答案。
  ?

PS：通常也可以在單 Node 上執(zhí)行一些真正的訓(xùn)練任務(wù)（比如 Resnet，Bert），并與 Benchmark MLPerf Training | MLCommons Version 2.0 Results 中的結(jié)果對比，以便驗(yàn)證單 Node 是否有性能瓶頸：

3.2 安裝 IB

3.2.1 安裝 UFM

InfiniBand 的一個(gè)優(yōu)點(diǎn)是其中心化設(shè)計(jì)，因?yàn)樗幸粋€(gè)用于整個(gè)網(wǎng)絡(luò)的大腦，因此只用處理 320 個(gè) IB Switch 中的一個(gè)實(shí)體。首要任務(wù)是弄清哪些 Switch 連接哪些 Node，然后將其與接線圖相關(guān)聯(lián)，并重新命名 Switch。

3.2.2 重新布線

起初，UFM 無法檢測到 320 臺(tái) IB Switch，更不用說相應(yīng)的 Node，最后發(fā)現(xiàn)其結(jié)構(gòu)設(shè)計(jì)有問題：不是一個(gè)單一的統(tǒng)一結(jié)構(gòu)，而是 8 個(gè)獨(dú)立的網(wǎng)絡(luò)。重新布線后，再次檢查并驗(yàn)證所有物理連接與新的設(shè)計(jì)對齊。

3.2.3 上萬個(gè)溫度報(bào)警

在解決了物理布線后，UFM 與所有 Switch 建立連接。然而，此時(shí)還沒有傳輸數(shù)據(jù)，但幾乎每個(gè) Switch Port 都開始報(bào)警溫度過高，有些甚至超過 70 攝氏度。最終發(fā)現(xiàn)是網(wǎng)絡(luò) Rack 中 Switch 之間的空間問題，導(dǎo)致熱空氣重新循環(huán)會(huì)前部，經(jīng)重新調(diào)整后解決了這個(gè)問題。

3.2.4 1800 個(gè)報(bào)警

許多 Port 依然表現(xiàn)出很高的錯(cuò)誤率，或者在工作狀態(tài)和損壞狀態(tài)之間波動(dòng)，也就是 flapping。這類問題只有 port 被使用時(shí)才出現(xiàn)，因此很難預(yù)先識(shí)別。此時(shí)需要數(shù)據(jù)中心合作伙伴協(xié)助清理或重新插拔，也可能需要更換光模塊。雖然 IB 對硬件故障具有很強(qiáng)的容錯(cuò)能力，但一旦有 10% 的結(jié)構(gòu)開始出現(xiàn)問題，自適應(yīng)路由功能就可能無法可靠的運(yùn)行。

在此期間，Imbue 嘗試使用 100 到 200 個(gè) Node 進(jìn)行多 Node 訓(xùn)練。并盡可能的在一組隨機(jī) Node 啟動(dòng)，然后觀察它們的性能，試圖找到 IB 網(wǎng)絡(luò)中的可靠子集。但事實(shí)證明這很難辦到，每次改變訓(xùn)練的 Node 子集時(shí)，默認(rèn)的 IB 連接子集也在變化。

3.2.5 IB 壓測

為了診斷 IB 問題，Imbue 專門設(shè)計(jì)了一個(gè)針對整個(gè)集群的 Workload，該 Workload 側(cè)重于同時(shí)盡可能地在每個(gè) Port 發(fā)送盡量多的數(shù)據(jù)。這與大型的 AllReduce 不同，AllReduce 可以充分利用節(jié)點(diǎn)內(nèi)的 NVLink。當(dāng)大多數(shù) Port 發(fā)送的數(shù)據(jù)量超過理論容量 97% 時(shí)，UFM 開始報(bào)警，一些 Switch 也可能崩潰。經(jīng)過一天的壓測，那些依舊正常的 Port 被認(rèn)為足夠穩(wěn)定，可以繼續(xù)使用，剩余的將被禁用并進(jìn)行維修。相關(guān)代碼可以查看：??https://github.com/imbue-ai/cluster-health/tree/master/ib_burn??

3.2.6 啟用 GPUDirect RDMA

為了使 GPU 通信時(shí)不占用 CPU，作者打開了 GPUDirect RDMA，允許直接通過 IB NIC 通信。這涉及兩個(gè)關(guān)鍵步驟：

• 啟用額外的內(nèi)核模塊：Chapter 42. GPUDirect RDMA Peer Memory Client。
• 確保 PCIe ACS（Access Control Service） 被關(guān)閉，以避免出現(xiàn) Hang 的問題：Troubleshooting — NCCL 2.11.4 documentation。

3.2.7 構(gòu)建穩(wěn)定機(jī)器組合

使用最新硬件的 GPU 集群的經(jīng)驗(yàn)法則：預(yù)計(jì)每周約有 3% 的機(jī)器會(huì)故障。然而，有一個(gè)關(guān)鍵的差別可能被遺忘：并不是每臺(tái)機(jī)器都有 3% 的故障率；相反，少數(shù)機(jī)器可能反復(fù)故障，直到被徹底修復(fù)。這凸顯了在同一 Fabric 上擁有大量機(jī)器的優(yōu)勢，與其在使用隨機(jī)機(jī)器的大型訓(xùn)練中“打地鼠”，不如專注于構(gòu)建一組已知穩(wěn)定的機(jī)器。

3.2.8 維護(hù)

IB 的維護(hù)主要涉及響應(yīng) UFM 報(bào)警，更換故障線纜和收發(fā)器，以及偶爾診斷更困難的錯(cuò)誤，例如故障的交換機(jī)。大規(guī)模問題通常有兩個(gè)因素引起：

• 固件升級，可能會(huì)導(dǎo)致 UFM 狀態(tài)異常，通常需要重啟 UFM。
• 同時(shí)大規(guī)模啟動(dòng) GPU，可能同時(shí)觸發(fā) UFM 狀態(tài)更新，導(dǎo)致問題，同樣也需要重啟 UFM。

四、全面的健康檢查

在使用的過程中，作者發(fā)現(xiàn)許多因素都會(huì)導(dǎo)致訓(xùn)練失敗或者速度變慢，并且許多都不會(huì)立刻展現(xiàn)。因此作者編寫了一系列運(yùn)行狀態(tài)檢查工具，以確保 Node 足夠健康，可以用于訓(xùn)練。相關(guān)的腳本已經(jīng)開源在 Github：??https://github.com/imbue-ai/cluster-health/tree/master/health_checks??。

具體的檢查包含以下幾種：

• GPU：檢查 Node 上 GPU 數(shù)量是否正確，ECC 是否打開，是否存在 ECC Error，以及 NVLink 的拓?fù)涞取?/li>
• 硬盤：

檢查硬盤使用是否超過 95%。

檢查 zpool 已經(jīng)掛載。

• Docker：檢查 Docker 能正確運(yùn)行 GPU 容器，以及監(jiān)控、剖析相關(guān)容器能被賦予正確權(quán)限。
• Dmesg：檢查 dmesg 中是否有 Xids 或 SXid 錯(cuò)誤（GPU 或 NVSwitch 相關(guān)故障）。（PS：我們通常也用來檢測 OOM相關(guān)問題，有些時(shí)候平臺(tái)化的方式無法很好捕獲 OOM 相關(guān)錯(cuò)誤，比如 OOM 后被 kill，或者監(jiān)控采樣周期問題導(dǎo)致沒有監(jiān)測到突發(fā)的 OOM）
• iDRAC：Imbue 采用的戴爾服務(wù)器，因此也會(huì)檢查戴爾特有的 iDRAC 錯(cuò)誤，但會(huì)忽略非致命錯(cuò)誤。
• IB：檢查是否存在 IB 錯(cuò)誤率增加，或者驅(qū)動(dòng)進(jìn)程固件過時(shí)。
• NVLink：檢查機(jī)器上的 NVLink 錯(cuò)誤，通常不會(huì)導(dǎo)致訓(xùn)練失敗，但可能導(dǎo)致訓(xùn)練降速。
• GDR：檢查是否已經(jīng)啟動(dòng) GDR。
• VBIOS：檢查 GPU 的 VBIOS 以及 H100 的 baseboard 是否為最新版本。
• Flint：作者使用 flint 和 hca_self_test 來檢查 Mellanox OFED 驅(qū)動(dòng)、固件以及收發(fā)器固件是否是正確版本，以及它們是否適配 NVIDIA 驅(qū)動(dòng)。

除此之外，還會(huì)進(jìn)行一系列的測試，檢查 PSB（PCIe Switch Bus）是否健康，具體來說，檢查 GPU 和網(wǎng)卡相關(guān)的連接速度和帶寬是否符合預(yù)期。也會(huì)有一系列復(fù)雜的健康檢查：

• 使用 Pytorch 初始化矩陣計(jì)算，并測量其 NVLink 帶寬，GPU 計(jì)算速度以及內(nèi)存。也會(huì)通過設(shè)置 GDR flag 來測試 IB 和 NVLink。
• 使用帶有–use_cuda的ib_write_bw來通過 IB NIC 發(fā)送數(shù)據(jù)并測量 PCIe 和 IB 帶寬。會(huì)運(yùn)行 15 分鐘，以捕獲不穩(wěn)定的 IB 連接。
• 運(yùn)行多節(jié)點(diǎn)診斷程序，以檢查 NCCL 初始化能力以及是否會(huì)隨機(jī)失敗。作者也 fork 了 NCCL 代碼來添加更多的日志記錄。通常需要運(yùn)行 12-24 小時(shí)才能發(fā)現(xiàn)問題，因此通常只對新 Node 或者懷疑有問題的 node 運(yùn)行。（PS：其實(shí)各個(gè)大廠也都有基于 NCCL 改造的 CCL，比如百度 BCCL，阿里 ACCL，騰訊 TCCL 等）
• 檢查 DCGM 導(dǎo)出的各種指標(biāo)中是否有任何不符合預(yù)期的現(xiàn)象。比如 GPU clock 受限等。

五、診斷訓(xùn)練問題

硬件準(zhǔn)備好之后即可啟動(dòng)正式的訓(xùn)練，這里作者進(jìn)一步梳理了訓(xùn)練中的問題。

5.1 啟動(dòng)崩潰

從某種程度上來說，這是最好的錯(cuò)誤，因?yàn)樗鼈兺ǔ：苋菀讖?fù)現(xiàn)并修復(fù)。首先會(huì)檢查代碼是否正確、配置和環(huán)境變量是否準(zhǔn)確，雖然很基礎(chǔ)，但也是常見的問題。然后會(huì)進(jìn)一步檢查機(jī)器是否都正常運(yùn)行，可以通過堆棧、日志聚合平臺(tái)來追蹤，比如使用 Loki、Prometheus 和 Grafana。最后，作者也構(gòu)建了一個(gè)失敗時(shí)自動(dòng)重啟的系統(tǒng)，此時(shí)日志和錯(cuò)誤聚合也就更加重要，避免不同任務(wù)出現(xiàn)混淆。

作者常遇到的錯(cuò)誤包括：

• 不同Rank 間參數(shù)傳遞不匹配，比如“Forward order differs across ranks: rank 0 is all-gathering 43 parameters while rank 1228 is all-gathering 1 parameters”，這可能是 Pytorch FSDP 的問題，通過重啟可解決。
• GPU OOM，通常是代碼問題，比如部分代碼沒有指定 GPU Device，導(dǎo)致都用了 0 號(hào) GPU，通?？梢詸z查最新修改的代碼。
• CPU RAM OOM，有些時(shí)候從錯(cuò)誤日志中不太容易發(fā)現(xiàn)，通常最好通過 Docker 容器外 Node 上的 demsg 日志檢測。

5.2 訓(xùn)練中崩潰

首要任務(wù)是構(gòu)建自動(dòng)運(yùn)行系統(tǒng)，重新運(yùn)行所有診斷檢查工具，然后驅(qū)逐異常機(jī)器，并自動(dòng)重新啟動(dòng)訓(xùn)練任務(wù)。有些異常通過重啟可以解決，但也有些錯(cuò)誤需要返廠或更換，比如無法糾正的 ECC Error。

此外，作者也遇到訓(xùn)練數(shù)據(jù)導(dǎo)致的異常。比如，語料庫中一個(gè)非常大的單個(gè)文件可能導(dǎo)致 CPU 或 GPU OOM。為了防止這種問題，通常需要一個(gè)完全確定性的 DataLoader，可以指定 epoch 或 step 數(shù)，以便復(fù)現(xiàn)或跳過部分?jǐn)?shù)據(jù)。（PS：訓(xùn)練中有些時(shí)候 loss 會(huì)存在 spike，也需要跳過部分 step）。

最后，通過聚合網(wǎng)絡(luò)或 Node 的統(tǒng)計(jì)數(shù)據(jù)也很有幫助，有些短暫的問題可能不容易被發(fā)現(xiàn)，聚合后會(huì)更容易。

5.3 Hang ?。]有堆棧信息）

由于缺乏有用的信息，通常很難可靠的復(fù)現(xiàn)這類錯(cuò)誤，因此調(diào)試起來非常困難。如下所示為常見的令人頭疼的信息，因?yàn)橛?xùn)練通常是同步方式，所以可能所有節(jié)點(diǎn)都有同樣的錯(cuò)誤，不能區(qū)分具體是哪一個(gè)有問題：

Watchdog caught collective operation timeout: WorkNCCL(SeqNum=408951, OpType=_ALLGATHER_BASE, … , Timeout(ms)=600000) ran for 600351 milliseconds before timing out

為了解決這個(gè)問題，作者 Fork 了 NCCL 代碼庫，并添加了相應(yīng)的時(shí)間戳（??https://github.com/boweiliu/nccl/commit/0966031bdb5905b8ea5aef3fb2a8ce6317040234??），以便更好地顯示崩潰發(fā)生時(shí)正在執(zhí)行的消息或操作，從而確定哪個(gè) Node 或 GPU 可能阻塞了：

此外，為了識(shí)別可能存在問題的 Node，經(jīng)常會(huì)找出哪些 Node 沒有生成某些日志消息，缺少此類消息表明該 Node 的工作進(jìn)程落后或者已經(jīng)崩潰。其他沒有有用錯(cuò)誤信息的響應(yīng)實(shí)例通?？赡芘c硬件相關(guān)，為了區(qū)分 NCCL 掛起，驅(qū)動(dòng)進(jìn)程掛起或 Python 代碼中的死鎖等問題，作者使用 Py-Spy 和 GDB 等工具來實(shí)時(shí)調(diào)試 Hang 住的進(jìn)程，使用此方法能夠捕獲一些特定的問題。

5.4 訓(xùn)練變慢（MFU 下降）

這一類問題可能更加令人頭大，除了 Py-Spy、堆棧跟蹤檢查和 GDB 外，作者也會(huì)使用 NVIDIA Nsight 等 Profiling 工具，其中的一些工具在大規(guī)模分布式環(huán)境比較難使用。

速度變慢，MFU 降低可能是多種原因引起的。首先可以檢查配置、代碼和環(huán)境變量是否正確。作者遇到過使用了錯(cuò)誤的模型，Batch Size，UFM 或 NCCL 設(shè)置，以及錯(cuò)誤的 CUDA_DEVICE_MAX_CONNECTIONS，這些都可能導(dǎo)致性變差。此外，測量細(xì)粒度的 MFU 也很有幫助，可以幫助診斷一系列問題：

• 開始就是極低的MFU（預(yù)期 1/10），并保持穩(wěn)定：通常是 IB 網(wǎng)絡(luò)硬件問題，比如 IB 交換機(jī)故障。也可能是 GPU 和 NIC 之間的硬件問題導(dǎo)致的。
• 30% 預(yù)期 MFU，并且保持穩(wěn)定：通常是某一個(gè) Node GDR 設(shè)置不正確，或者 GDR 環(huán)境變量不正確造成的。
• 60%-80% 預(yù)期 MFU，并且保持穩(wěn)定：通常是 IB 鏈路故障導(dǎo)致，特別是某個(gè) GPU 的 NIC 故障，導(dǎo)致流量通過 NVLink 繞行。
• 單個(gè) Batch MFU 突然急劇下降（下降 10 倍），并且經(jīng)常發(fā)生：這通常與 Checkpointing 有關(guān)，可以檢查是否與 Checkpointing 同步，針對這種情況如果添加 MFU 異常報(bào)警，將會(huì)存在很多誤報(bào)。
• 單個(gè) Batch MFU 突然急劇下降（下降 10 倍），并且偶爾發(fā)生：這可能與其他繁重的 CPU 負(fù)載有關(guān)，比如 DataLoader 瓶頸，作者為數(shù)據(jù)加載、Checkpointing 以及非 NCCL 代碼添加了計(jì)時(shí)統(tǒng)計(jì)，最終證明其非常有幫助。
• MFU 曲線逐漸下降，并且在重啟后恢復(fù)：理論上這可能是 Switch 上熱量累積的結(jié)果，不過作者通過 Profiling 發(fā)現(xiàn)可能是垃圾回收機(jī)制導(dǎo)致，禁用自動(dòng)垃圾回收和計(jì)劃垃圾回收后該問題驟然消失。（PS：字節(jié)在[2402.15627] MegaScale: Scaling Large Language Model Training to More Than 10,000 GPUs中提到了類似的問題）



• 一開始良好，然后突然下降（預(yù)期 70%），并以高頻率持續(xù)（每 15s）：最終發(fā)現(xiàn)這個(gè)可能與 GPU 的自動(dòng)調(diào)頻有關(guān)，可以通過 DCGM 收集。這通常是散熱不好，溫度過高或者電源故障，電壓不穩(wěn)等原因?qū)е隆?/li>
• MFU 良好，但偶爾會(huì)有噪聲（降到預(yù)期的 90%）：這通常是網(wǎng)絡(luò)中較高的鏈路（比如 T3，T4）抖動(dòng)。遺憾的是，許多問題并不能追溯到特定的 Node，與 IB 相關(guān)的問題尤其難以排查。

作者也總結(jié)了一系列用于快速調(diào)試吞吐量下降的措施：

1. 是否之前有效果而現(xiàn)在不行？
2. 最近更改了哪些內(nèi)容（代碼，驅(qū)動(dòng)）？
3. 是否運(yùn)行在健康的機(jī)器上，依賴的服務(wù)是否正常運(yùn)行？
4. 運(yùn)行的代碼、環(huán)境、配置、版本、機(jī)器列表、Rank 順序、隨機(jī)種子是否與上次完全相同？
5. 是否可復(fù)現(xiàn)？
6. 是否與其他任何事情相關(guān)？比如，每日 crontab、機(jī)器、DCGM 或 UFM 指標(biāo)？
7. 指標(biāo)是否正確？
8. 縮減實(shí)現(xiàn)（較小的模型、偽造的數(shù)據(jù)，不保存和加載 Checkpoint）時(shí)，問題是否能夠復(fù)現(xiàn)？

六、改進(jìn) Infra 工具

經(jīng)過以上的措施通常能在訓(xùn)練時(shí)獲得良好的性能。本節(jié)中，介紹一些工具和系統(tǒng)，旨在確保訓(xùn)練繼續(xù)順利運(yùn)行，理想情況下，人為干預(yù)盡量少。

幾乎所有訓(xùn)練運(yùn)行中的問題都可以歸咎于 Node 或者網(wǎng)絡(luò)組件故障，這些故障在大型集群中經(jīng)常發(fā)生，因此必須自動(dòng)執(zhí)行故障 Node 驅(qū)逐以及請求維修過程。

6.1 故障機(jī)器

作者開發(fā)了一個(gè)系統(tǒng)，用于任務(wù)異常時(shí)自動(dòng)從最新的 Checkpoint 啟動(dòng)。重新啟動(dòng)中將在每個(gè)可用 Node 上運(yùn)行健康檢查，并根據(jù)檢查結(jié)果進(jìn)行分類，然后從最健康的 Node 上重新啟動(dòng)訓(xùn)練作業(yè)。

6.2 網(wǎng)絡(luò)組件故障

作者觀察到所有網(wǎng)絡(luò)組件故障都被 UFM 檢測到并記錄在 UFM Event 日志中，因此響應(yīng)網(wǎng)絡(luò)組件故障只需解析 UFM 日志并針對每個(gè) Event 采取適當(dāng)?shù)牟僮骷纯伞?/p>

UFM Event 系統(tǒng)相當(dāng)復(fù)雜，包含數(shù)十種類型。然而，在實(shí)踐中，作者發(fā)現(xiàn)只有極少數(shù) Event 表明存在問題，主要與鏈路斷開或高的符號(hào)錯(cuò)誤數(shù)量有關(guān)。識(shí)別到這些 Event 之后，就能夠編寫相應(yīng)的腳本來禁用與最近 Event 相關(guān)的連接或 Port。

6.3 本地文件緩存

主要是進(jìn)出集群的以太網(wǎng)帶寬比較小，如果很多人同時(shí)下載數(shù)據(jù)集或者 Checkpoint 可能存在瓶頸。因此，作者在本地構(gòu)建了 Cache 系統(tǒng)，并且為了避免機(jī)器異常導(dǎo)致數(shù)據(jù)流失，作者采用了 3 副本配置，并使用一致性哈希來均勻分配負(fù)載。集群存儲(chǔ)空間有限，因此還需要開發(fā)各種工具來跟蹤文檔的生命周期，及時(shí)清理不相關(guān)文檔。

6.4 本地鏡像倉庫

作者還使用 Kraken 來實(shí)現(xiàn) Docker 鏡像的點(diǎn)對點(diǎn)傳輸，并且使用中沒有遇到任何問題。

6.5 各種性能監(jiān)控工具

作者配置了默認(rèn)的 Torch Profiler 和 NVIDIA Nsight。后者有助于準(zhǔn)確捕獲前向/后向傳播以及 NCCL 通信時(shí)間，并有助于確定在給定模型大小和工作線程數(shù)量下，是否受到通信或計(jì)算的瓶頸。但是，Nsight 使用起來有些困難，而且需要在特權(quán)模式下運(yùn)行 Docker，并且要禁用與性能監(jiān)控事件相關(guān)的安全檢查，此外，保存相關(guān)文檔時(shí)也需要停止訓(xùn)練過程。

作者發(fā)現(xiàn)自己編寫工具來檢查緩慢的訓(xùn)練 Batch 并了解緩慢的潛在原因很有幫助，其中最有用的工具可以監(jiān)控每個(gè) Batch 花費(fèi)的時(shí)間，并在異常慢時(shí)轉(zhuǎn)存每個(gè) worker 堆棧，以便進(jìn)一步識(shí)別細(xì)微的硬件或軟件問題。

6.6 對集群進(jìn)行細(xì)分，以排查故障機(jī)器

在使用集群的最初幾個(gè)月里，經(jīng)常遇到這樣的情況：在一組特定的機(jī)器上運(yùn)行訓(xùn)練任務(wù)會(huì)失敗，但不清楚是哪臺(tái)機(jī)器有故障。為了查明故障，作者將機(jī)器劃分為更細(xì)粒度的子集，并在每個(gè)子集上啟動(dòng)較小的作業(yè)。例如，如果一組 48 臺(tái)機(jī)器的作業(yè)失敗，可以將其劃分為 6 個(gè) 8 臺(tái)機(jī)器的子集分別啟動(dòng)任務(wù)；然后可以在 8 個(gè) 6 臺(tái)集群的子集分別啟動(dòng)任務(wù)，經(jīng)過交叉比對都失敗的組即可得到異常的機(jī)器。（PS：螞蟻的 DLRover: An Automatic Distributed Deep Learning System 中也提到了類似方案）

七、經(jīng)驗(yàn)和教訓(xùn)

在構(gòu)建和維護(hù)該訓(xùn)練 Infrastructure 的過程中，作者整理了一系列有用的經(jīng)驗(yàn)教訓(xùn)：

• 提供可置換的冗余 Node 非常有幫助。對于給定的訓(xùn)練任務(wù)，提供比運(yùn)行所需 Node 多 10%-20% 的 Node 很有幫助（PS：阿里最新的 HPN 中，甚至犧牲無收斂性，為每 128 個(gè) Node 提供了 8 個(gè)物理冗余備份），這樣就可以在有 Node 故障時(shí)輕松重啟作業(yè)。因?yàn)榧菏侨ヂ?lián)的，意味著可以使用集群中的任何子集。
• 為遇到的每種硬件或軟件故障編寫測試或自動(dòng)化解決方案很有必要，因?yàn)樵谟?xùn)練中可能隨時(shí)再次發(fā)生各種問題。此外，對于每個(gè)不透明的錯(cuò)誤信息，編寫工具使錯(cuò)誤更易于理解也很有必要。
• 可復(fù)現(xiàn)性是科學(xué)解決問題的關(guān)鍵。作者堅(jiān)持的一條準(zhǔn)則是：“一次只改變一件事”，即使是最簡單的事。
• 信任，但要驗(yàn)證。每當(dāng)流程中引入外部工具或引入新人時(shí)，無論是外部或內(nèi)部，都會(huì)確保仔細(xì)檢查相關(guān)聲明，尤其是在后續(xù)步驟取決于這些結(jié)果的情況下。

八、參考鏈接

1. ??https://imbue.com/??
2. ??https://imbue.com/research/70b-infrastructure/??
3. ??https://github.com/imbue-ai/cluster-health??
4. ??https://arxiv.org/abs/2402.15627??
5. ??https://arxiv.org/abs/2403.07648??
6. ??https://arxiv.org/abs/2406.04594??
7. ??https://ennanzhai.github.io/pub/sigcomm24-hpn.pdf??
8. ??https://cloud.tencent.com/developer/article/2433459??
9. ??https://xie.infoq.cn/article/d6162c9c77001c07a7d2e722c??
10. ??https://github.com/intelligent-machine-learning/dlrover??
11. ??https://github.com/prometheus/node_exporter??
12. ??https://github.com/NVIDIA/dcgm-exporter??
13. ??https://github.com/NVIDIA/nvbandwidth??
14. ??https://github.com/NVIDIA/cuda-samples??
15. ??https://github.com/NVIDIA/nccl-tests??
16. ??https://docs.nvidia.com/deeplearning/nccl/user-guide/docs/troubleshooting.html??
17. ??https://mlcommons.org/benchmarks/training/??
18. ??https://github.com/imbue-ai/cluster-health/tree/master/ib_burn??
19. ??https://download.nvidia.com/XFree86/Linux-x86_64/535.183.01/README/nvidia-peermem.html??
20. ??https://github.com/imbue-ai/cluster-health/tree/master/health_checks??

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