一、引言

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

其實最近很多公司都公布了相關的 AI Infrastructure 以及工作，比如：

• 字節跳動 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
• 騰訊星脈網絡 2.0：大模型訓練再提速20%！騰訊星脈網絡2.0來了
• 百度 HPN - AI Pod：徹底解決網絡哈希沖突，百度百舸的高性能網絡HPN 落地實踐
• 螞蟻金服 DLRover：DLRover: An Automatic Distributed Deep Learning System

我們也介紹過一系列相關工作，比如：

• ??阿里 HPN：針對大規模 LLM 訓練的萬卡集群??
• ??萬卡 GPU 集群互聯：硬件配置和網絡設計??
• ??萬卡 GPU 集群實戰：探索 LLM 預訓練的挑戰??
• ??阿里 C4：通信驅動加速大規模并行訓練效率??
• ??剖析大規模 GPU 集群：針對 LLM 場景的挑戰和優化??
• ??HPN 7.0：阿里云新一代萬卡集群網絡架構??

二、4088 H100 集群搭建

2.1 概覽

如下圖所示為 Imbue 從 0 開始搭建的大規模 GPU 集群?？偣舶?511 個 8*H100 GPU 節點，共 4088 個 H100 GPU（PS：后文會介紹為什么不是 512 臺 4096 GPU）。通過 3-Tier IB 網絡實現無收斂（fully non-blocking）拓撲：

2.2 8*H100 Server

如下圖所示為單個 8*H100 節點的配置：

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

一個構建前向的數據傳輸網絡，主要用于傳輸數據集、Checkpoint 以及其他數據。

另一個用于組成輔助管理網絡，純粹用于配置和管理，允許訪問 BIOS、電源等其他 low level 控制接口。如果沒有這個網絡，將不得不使用 USB 驅動器等方式手動配置節點，對于大規模集群來說不太現實。

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

2.3 網絡拓撲

其網絡拓撲應該是參考了 NVIDIA H100 的標準方案，IB 網絡采用的是 QM97xx 交換機，每個有 64 個 400Gbps 的 Port，在 Leaf 和 Spine 中都是 32 個下行 Port，32 個 上行 Port：

如下圖所示為其對應的網絡拓撲，和 NVIDIA 的 SuperPod 基本一致，總共 320 個 Switch（PS：詳細介紹可以參考我們之前的文章）：

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

2.4 NVIDIA DGX H100 SuperPod 

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

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

2.5 4096 GPU or UFM？

 為什么要引入 UFM 而不是構成 512 Node 的完全對稱結構呢？可能是兩個方面的考慮：

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

三、集群初始化

3.1 Node 初始化

通過輔助管理網絡和 BMC（Baseboard Management Controller，即使 OS 未啟動或 Node 宕機，BMC 依然可以工作，提供對系統的訪問和控制），可以與每臺機器進行交互，實現對硬件的監控和管理。

3.1.1 安裝一個 Node

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

3.1.2 安裝其它 Node

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

3.1.3 診斷異常 Node

與其他大規模 GPU 集群初始化一樣，Imbue 發現大約 10% 的機器無法啟動，主要是硬件問題，比如：以太網網線未連接或者接錯、iDRAC 中的硬件問題、電源損壞、NVME 驅動器損壞、網卡或 GPU 無法連接。部分機器甚至返回戴爾進行進一步的測試。

3.1.4 軟件安裝

繼續在每個 node 上安裝以下軟件：

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

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

3.1.5 單 Node 驗證

在安裝完基礎的可運行環境之后，通常還要確保每個 Node 都能獨立處理真正的 GPU Workload。在這個過程中作者也發現了一系列的問題：

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

NVMe Driver 未顯示故障，但 touch 時會死機。

硬盤在 Linux 下隨機順序顯示，導致 OS 安裝在錯誤的盤上。（PS：我們遇到過 OS 被安裝在數據盤的情況?? ）

錯誤的溫度計數，導致風扇一直 100% 轉速工作。作者發現部分是 NVIDIA Driver 導致，通過降級解決。

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

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

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

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

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

3.2 安裝 IB

3.2.1 安裝 UFM

InfiniBand 的一個優點是其中心化設計，因為它有一個用于整個網絡的大腦，因此只用處理 320 個 IB Switch 中的一個實體。首要任務是弄清哪些 Switch 連接哪些 Node，然后將其與接線圖相關聯，并重新命名 Switch。

3.2.2 重新布線

起初，UFM 無法檢測到 320 臺 IB Switch，更不用說相應的 Node，最后發現其結構設計有問題：不是一個單一的統一結構，而是 8 個獨立的網絡。重新布線后，再次檢查并驗證所有物理連接與新的設計對齊。

3.2.3 上萬個溫度報警

在解決了物理布線后，UFM 與所有 Switch 建立連接。然而，此時還沒有傳輸數據，但幾乎每個 Switch Port 都開始報警溫度過高，有些甚至超過 70 攝氏度。最終發現是網絡 Rack 中 Switch 之間的空間問題，導致熱空氣重新循環會前部，經重新調整后解決了這個問題。

3.2.4 1800 個報警

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

在此期間，Imbue 嘗試使用 100 到 200 個 Node 進行多 Node 訓練。并盡可能的在一組隨機 Node 啟動，然后觀察它們的性能，試圖找到 IB 網絡中的可靠子集。但事實證明這很難辦到，每次改變訓練的 Node 子集時，默認的 IB 連接子集也在變化。

3.2.5 IB 壓測

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

3.2.6 啟用 GPUDirect RDMA

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

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

3.2.7 構建穩定機器組合

使用最新硬件的 GPU 集群的經驗法則：預計每周約有 3% 的機器會故障。然而，有一個關鍵的差別可能被遺忘：并不是每臺機器都有 3% 的故障率；相反，少數機器可能反復故障，直到被徹底修復。這凸顯了在同一 Fabric 上擁有大量機器的優勢，與其在使用隨機機器的大型訓練中“打地鼠”，不如專注于構建一組已知穩定的機器。

3.2.8 維護

IB 的維護主要涉及響應 UFM 報警，更換故障線纜和收發器，以及偶爾診斷更困難的錯誤，例如故障的交換機。大規模問題通常有兩個因素引起：

• 固件升級，可能會導致 UFM 狀態異常，通常需要重啟 UFM。
• 同時大規模啟動 GPU，可能同時觸發 UFM 狀態更新，導致問題，同樣也需要重啟 UFM。

四、全面的健康檢查

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

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

• GPU：檢查 Node 上 GPU 數量是否正確，ECC 是否打開，是否存在 ECC Error，以及 NVLink 的拓撲等。
• 硬盤：

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

檢查 zpool 已經掛載。

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

除此之外，還會進行一系列的測試，檢查 PSB（PCIe Switch Bus）是否健康，具體來說，檢查 GPU 和網卡相關的連接速度和帶寬是否符合預期。也會有一系列復雜的健康檢查：

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

五、診斷訓練問題

硬件準備好之后即可啟動正式的訓練，這里作者進一步梳理了訓練中的問題。

5.1 啟動崩潰

從某種程度上來說，這是最好的錯誤，因為它們通常很容易復現并修復。首先會檢查代碼是否正確、配置和環境變量是否準確，雖然很基礎，但也是常見的問題。然后會進一步檢查機器是否都正常運行，可以通過堆棧、日志聚合平臺來追蹤，比如使用 Loki、Prometheus 和 Grafana。最后，作者也構建了一個失敗時自動重啟的系統，此時日志和錯誤聚合也就更加重要，避免不同任務出現混淆。

作者常遇到的錯誤包括：

• 不同Rank 間參數傳遞不匹配，比如“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，導致都用了 0 號 GPU，通?？梢詸z查最新修改的代碼。
• CPU RAM OOM，有些時候從錯誤日志中不太容易發現，通常最好通過 Docker 容器外 Node 上的 demsg 日志檢測。

5.2 訓練中崩潰

首要任務是構建自動運行系統，重新運行所有診斷檢查工具，然后驅逐異常機器，并自動重新啟動訓練任務。有些異常通過重啟可以解決，但也有些錯誤需要返廠或更換，比如無法糾正的 ECC Error。

此外，作者也遇到訓練數據導致的異常。比如，語料庫中一個非常大的單個文件可能導致 CPU 或 GPU OOM。為了防止這種問題，通常需要一個完全確定性的 DataLoader，可以指定 epoch 或 step 數，以便復現或跳過部分數據。（PS：訓練中有些時候 loss 會存在 spike，也需要跳過部分 step）。

最后，通過聚合網絡或 Node 的統計數據也很有幫助，有些短暫的問題可能不容易被發現，聚合后會更容易。

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

由于缺乏有用的信息，通常很難可靠的復現這類錯誤，因此調試起來非常困難。如下所示為常見的令人頭疼的信息，因為訓練通常是同步方式，所以可能所有節點都有同樣的錯誤，不能區分具體是哪一個有問題：

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

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

此外，為了識別可能存在問題的 Node，經常會找出哪些 Node 沒有生成某些日志消息，缺少此類消息表明該 Node 的工作進程落后或者已經崩潰。其他沒有有用錯誤信息的響應實例通常可能與硬件相關，為了區分 NCCL 掛起，驅動進程掛起或 Python 代碼中的死鎖等問題，作者使用 Py-Spy 和 GDB 等工具來實時調試 Hang 住的進程，使用此方法能夠捕獲一些特定的問題。

5.4 訓練變慢（MFU 下降）

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

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

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



• 一開始良好，然后突然下降（預期 70%），并以高頻率持續（每 15s）：最終發現這個可能與 GPU 的自動調頻有關，可以通過 DCGM 收集。這通常是散熱不好，溫度過高或者電源故障，電壓不穩等原因導致。
• MFU 良好，但偶爾會有噪聲（降到預期的 90%）：這通常是網絡中較高的鏈路（比如 T3，T4）抖動。遺憾的是，許多問題并不能追溯到特定的 Node，與 IB 相關的問題尤其難以排查。

作者也總結了一系列用于快速調試吞吐量下降的措施：

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

六、改進 Infra 工具

經過以上的措施通常能在訓練時獲得良好的性能。本節中，介紹一些工具和系統，旨在確保訓練繼續順利運行，理想情況下，人為干預盡量少。

幾乎所有訓練運行中的問題都可以歸咎于 Node 或者網絡組件故障，這些故障在大型集群中經常發生，因此必須自動執行故障 Node 驅逐以及請求維修過程。

6.1 故障機器

作者開發了一個系統，用于任務異常時自動從最新的 Checkpoint 啟動。重新啟動中將在每個可用 Node 上運行健康檢查，并根據檢查結果進行分類，然后從最健康的 Node 上重新啟動訓練作業。

6.2 網絡組件故障

作者觀察到所有網絡組件故障都被 UFM 檢測到并記錄在 UFM Event 日志中，因此響應網絡組件故障只需解析 UFM 日志并針對每個 Event 采取適當的操作即可。

UFM Event 系統相當復雜，包含數十種類型。然而，在實踐中，作者發現只有極少數 Event 表明存在問題，主要與鏈路斷開或高的符號錯誤數量有關。識別到這些 Event 之后，就能夠編寫相應的腳本來禁用與最近 Event 相關的連接或 Port。

6.3 本地文件緩存

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

6.4 本地鏡像倉庫

作者還使用 Kraken 來實現 Docker 鏡像的點對點傳輸，并且使用中沒有遇到任何問題。

6.5 各種性能監控工具

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

作者發現自己編寫工具來檢查緩慢的訓練 Batch 并了解緩慢的潛在原因很有幫助，其中最有用的工具可以監控每個 Batch 花費的時間，并在異常慢時轉存每個 worker 堆棧，以便進一步識別細微的硬件或軟件問題。

6.6 對集群進行細分，以排查故障機器

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

七、經驗和教訓

在構建和維護該訓練 Infrastructure 的過程中，作者整理了一系列有用的經驗教訓：

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

八、參考鏈接

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

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