一、背景

在之前的多篇文章中，我們曾零星提到過 GPU 利用率以及 GPU 異常引發的大規模任務失敗問題。在本文中，我們將對這些內容進行更為系統的匯總，具體介紹常見的 GPU 監控指標及各種 GPU 異常情況。為了更好地說明問題，我們還將結合我們自己的實踐經驗以及其他相關論文中的案例進行分析和討論。

二、引言

2.1 MFU & HFU

為了評估 LLM 訓練時的效率，業界通常會使用 Model FLOPS Utilization（MFU） 和 Hardware FLOPS Utilization（HFU） 兩個關鍵指標來評估模型的 Forward 和 Backward 過程中（包括任何的網絡同步開銷和 DataLoader IO）硬件的利用率。

• MFU= 預估 FLOPS/硬件理論 FLOPS。其中，預估 FLOPS 就是模型訓練時理論需要的計算量，并不包括各種優化方案額外引入的計算量，比如 Gradient Checkpointing/Activation Recomputation 等引入的額外計算量。
• HFU= 實際 FLOPS/硬件理論 FLOPS。其中，實際 FLOPS 也就是理論上所有實際發生的計算量，包含 Gradient checkpointing/Activation Recompution 等引入的額外計算量，因此 HFU 應該總是 >= MFU。

如下所示為 Maximizing training throughput using PyTorch FSDP [1] 中 Meta 在 LLM 訓練時的 MFU 和 HFU。對于 LLM 訓練任務而言，通常在 A100/A800 GPU 集群中，MFU 可以達到 50%+，甚至接近 60%；而在 H100/H800 GPU 集群中， MFU 往往不超過 50%。

2.2 GPU 監控集成

NVIDIA DCGM（GitHub - NVIDIA/DCGM: NVIDIA Data Center GPU Manager (DCGM) is a project for gathering telemetry and measuring the health of NVIDIA GPUs [2]）是一套專為 NVIDIA GPU 集群管理和監控而設計的工具，其涵蓋健康檢測、全面診斷、系統報警及治理策略等。DCGM 通過 DCGM-Exporter（NVIDIA GPU metrics exporter for Prometheus leveraging DCGM [3]）可以很方便的與 Kubernetes 生態系統集成，為容器化環境提供豐富的 GPU 監測數據。

如下圖所示是一種簡單又常用的使用方式，每個 Node 上會部署一個 dcgm-exporter 實例，然后由 Prometheus 來周期性的抓取監控數據，并由 Grafana 進行相應監控的可視化（https://github.com/NVIDIA/dcgm-exporter/tree/main/grafana [4] 中也有相應的 Grafana config）：

2.3 GPU 監控指標

DCGM 的監控指標非常豐富，包括顯存占用，各種算力利用率，溫度、功率、頻率以及 NVLink 和各種異常相關指標。其實可以在 github/DCGM/dcgmlib/src/dcgm_fields.cpp [5] 中看到所有相關指標，甚至一些單位不清晰的指標也可以從中獲取。如下圖所示，可以看出 DCGM_FI_DEV_NVLINK_BANDWIDTH_L0 的單位為 MB/s。

部分監控的說明也可以參考：ACK集群GPU監控2.0指標有哪些- 容器服務Kubernetes 版 ACK - 阿里云 [6]

PS：由于指標眾多，本文中只會介紹一些關鍵指標，更多指標可以根據實際需求相應添加。

2.4 NVIDIA Fabric Manager

要想使用 NVSwitch 的 Sharp 能力，也就是 NCCL AllReduce 中的 NCCL_ALGO=NVSL 以及 NCCL_NVLS_ENABLE，需要啟動對應的 nvidia-fabricmanager，可以參考 1. Overview — Fabric Manager for NVIDIA NVSwitch Systems r560 documentation [7]。

NVIDIA FM（Fabric Manager）負責配置 NVSwitch 內存結構，以在所有參與的 GPU 之間形成一個統一的內存結構，并監控支持該結構的 NVLink。從較高層次來看，FM 承擔以下職責：

• 配置 NVSwitch 端口之間的路由；
• 與 GPU 驅動程序協調，初始化GPU；
• 監控結構中的 NVLink 和 NVSwitch 錯誤。?

NCCL 在 2.17+ 版本開始支持 NVLink Sharp，這個也是在 H100 的 NVSwitch 才支持的。

2.5 GPU 故障

GPU 故障是大規模 GPU 集群中最常見的問題之一，通常會暴露 ECC Error 或 Xid Code，有關 Xid Code 的錯誤可以參考 NVIDIA 的官方文檔 XID Errors :: GPU Deployment and Management Documentation [8]。也可參考一些公有云平臺上的 FAQ，比如 常見 Xid 事件的處理方法--機器學習平臺-火山引擎 [9]，此外也會提供一些排查手段，比如 自助診斷GPU節點問題-阿里云 [10]。

GPU 故障最大的挑戰是其數量比較多，故障率比較高，一個 GPU 異常往往意味這個訓練任務的暫停，而且通常需要按照整機的方式替換。比如 1 個 GPU 異常，通常是直接驅逐整機。這是因為大規模 LLM 預訓練往往要利用單機內高速的 NVLink，如果不是整機調度很可能會影響整體吞吐。假設一天內 GPU 發生故障的概率為 0.1%，則一臺 8 卡 GPU 機器每天發生故障的概率為 1-(1-0.1%)^8=0.8%，萬卡 GPU 一天內有 GPU 發生故障的概率為 1-(1-0.1%)^10000=99.99%。

三、GPU 利用率指標

3.1 GPU Utilization

對應 DCGM 的 DCGM_FI_PROF_GR_ENGINE_ACTIVE，表示在一個時間間隔內 Graphics 或 Compute 引擎處于 Active 的時間占比。Active 時間比例越高，意味著 GPU 在該周期內越繁忙。該值比較低表示一定沒有充分利用 GPU，比較高也不意味著已經充分利用 GPU。如下圖所示，表示幾個 GPU 的 Utilization 到了 80%-90% 左右：

其實更早之前的 Utilization 指標為 DCGM_FI_DEV_GPU_UTIL，只是因為其局限性現在往往會使用 DCGM_FI_PROF_GR_ENGINE_ACTIVE，更多說明也可以參考：Question about DCGM fields · Issue #64 [19]。

3.2 GPU SM Active

對應 DCGM 的 DCGM_FI_PROF_SM_ACTIVE，表示一個時間間隔內，至少一個 Warp 在一個 SM 上處于 Active 的時間占比，該值表示所有 SM 的平均值，對每個 Block 的線程數不敏感。該值比較低表示一定未充分利用 GPU。如下為幾種 Case（假設 GPU 包含 N 個 SM）：

• Kernel 在整個時間間隔內使用 N 個 Block 運行在所有的 SM 上，對應 100%。
• Kernel 在一個時間間隔內運行了 N/5 個 Block，該值為 20%。
• Kernel 有 N 個 Block，在一個時間間隔內只運行了 1/4 時間，該值為 25%。

如下圖所示為幾個 GPU 的 SM Active，可見只有 60% 左右，還有一定提升空間：

3.3 GPU SM Occupancy

對應 DCGM 的 DCGM_FI_PROF_SM_OCCUPANCY，表示一個時間間隔內，駐留在 SM 上的 Warp 與該 SM 最大可駐留 Warp 的比例。該值表示一個時間間隔內的所有 SM 的平均值，該值越高也不一定代表 GPU 使用率越高。

如下圖所示為幾個 GPU 的 SM Occupancy，只有 20% 多：

3.4 GPU Tensor Active

對應 DCGM 的 DCGM_FI_PROF_PIPE_TENSOR_ACTIVE，表示一個時間間隔內，Tensor Core 處于 Active 的時間占比，該值表示的是平均值，而不是瞬時值。如下所示是幾種 Case（假設 GPU 包含 N 個 SM）：

• 整個時間間隔內，N/2 個 SM 的 Tensor Core 都以 100% 的利用率運行，該值為 50%。
• 整個時間間隔內，N 個 SM 的 Tensor Core 都以 50% 的利用率運行，該值為 50%。
• 整個時間間隔內，N/2 個 SM 的 Tensor Core 都以 50% 的利用率運行，該值為 25%。
• 整個時間間隔的 80% 時間內，N/2 的 SM 的 Tensor Core 都以 50% 的利用率運行，該值為 20%。

3.5 GPU NVLink Bandwidth

對應 DCGM 的 DCGM_FI_DEV_NVLINK_BANDWIDTH_TOTAL，表示 GPU 通過 NVLink 的通信帶寬情況。甚至還可以使用 DCGM_FI_DEV_NVLINK_BANDWIDTH_L0 獲取其中 Lane 0 的通信帶寬情況，由于 H100 GPU 有 18 個 NVLink Lane，因此對應的通信帶寬往往是上述總帶寬的 1/18。

3.5 實驗

3.5.1 GPU Util & SM Active

如下圖所示，我們在 T4 GPU（包含 40 個 SM） 上通過一個小的實驗來說明幾個指標的關系：

• 當只有1 個 Block，1 個 Thread時，GPU Util 也是 100%，因為 GPU 一直在占用，此時 40 個 SM 中只有 1 個一直 Active，所以 SM Active 為 2.5%。
• 當有 40 個 Block，每個 Block 1 個 Thread時，GPU Util 為 100%，SM Active 也為 100%，因為每個 Block 都會占用一個 SM。
• 當有 40 個 Block，每個 Block 128 個 Thread時，GPU Util 為 100%，SM Active 也為 100%，因為每個 Block 都會占用一個 SM。此時 SM Occupancy 到了 12.5%。?

3.5.2 Tensor Active

如下圖所示，我們在 H100 GPU（包含 132 個 SM，每個 SM 上 4 個 Tensor Core） 上通過一個小的實驗來說明 Tensor Active 指標的關系。因為 Tensor Core 用于矩陣乘法，所以這里我們構造了一個 C(M, N) = A(M, K) x B(K, N) 的矩陣乘法操作， 而每個 Block 負責的是 C(16, 16) = A(16, K) x B(K, 16) 的計算：

• A100 Tensor Core 一次可以完成 8x4x8 的矩陣乘法，而 H100 Tensor Core 一次可以完成 8x4x16 的矩陣乘法，因此上述一個 Block 里 16x16x16 可以充分利用上一個 SM 里的 4 個 Tensor Core。
• 當只有1 個 Block時（16,16,16），只用 1 個 SM，也能充分利用該 SM 的 Tensor Core，因此 SM Active 和 Tensor Active 都是 0.69%，接近 1/132=0.8%。
• 當有16 個 Block時（64,512,64），可以利用 16 個 SM，也能充分利用該 SM 的 Tensor Core，因此 SM Active 和 Tensor Active 都是 12.1%，接近 16/132=12.1%。
• 當有128 個 Block時（128,16,256），可以利用 128 個 SM，也能充分利用該 SM 的 Tensor Core，因此 SM Active 和 Tensor Active 都是 96.3%，接近 128/132=97%。?

PS：Tensor Core 不支持 FP32 的矩陣乘法，上述實驗使用的是 FP16 的矩陣乘法。

3.5.3 Tensor Active & HFU

我們在進行大規模 LLM 預訓練時通常會關注相應的 MFU，以便評估 GPU 算力發揮水平，了解當前訓練任務是否還有比較大的優化空間。然而，有些任務并沒有提供相應的 MFU 指標，此時可以使用 Tensor Active 指標來近似 HFU。

Tensor Active 可以近似 HFU 的上限，主要是因為 LLM 中的大部分操作是矩陣乘法，而且往往會采用 BF16 來訓練，此時主要的計算都由 Tensor Core 來承擔，而 Tensor Active 正好可以反應 Tensor Core 的發揮水平。（PS：我們在實際的訓練任務中也有驗證，基本符合預期。）

如下圖所示，我們在一個 2 個 8 * H100 GPU 的節點上使用 Megatron-LM 訓練一個 3B LLM，采用 16DP 配置，基于 Megatron-LM 輸出的 MFU 為 45.5%，而下面對應的平均 SM Active 為 80% 左右，平均 Tensor Active 為 48% 左右，符合我們的上述結論：

3.5.4 NVLink Bandwidth - all2all

如下圖所示，在 8*H100 GPU 節點上使用 alltoall_perf -b 4G -e 4G -N 10000 -g 8 測試 All2All 的通信帶寬，可以看出：

對應的 busbw 約為 350GB/s:

每個 GPU 的 NVLink Bandwidth 達到 290 GiB/s（極限 600 GiB/s）：

每個 GPU Lane 0 的 Bandwidth 達到 16 GiB/s，對應總帶寬為 16*18=288 GiB/s

此時的 SM Active 約為 12.1%，表明大概使用了 132*12.1%=16 個 SM，也就是通信依然會占用 GPU SM，可能與計算之間存在競爭：

3.5.5 NVLink Bandwidth - allreduce

NCCL 的 AllReduce 支持多種算法，比如常見的 Ring 和 Tree，也包括 NVLS，也就是啟用 NVLink SHARP。NVLink SHARP 適用于搭載 Hopper 及后續 GPU 架構的第三代 NVSwitch 系統（NVLink4），支持將諸如 ncclAllReduce 等集合通信操作卸載至 NVSwitch 執行。

可以使用 NCCL_NVLS_ENABLE 環境變量來啟用或禁用 NVLink SHARP（NVLS）功能。

如下圖所示，關閉 NVLink SHARP，也就是：NCCL_NVLS_ENABLE=0 all_reduce_perf -b 16G -e 16G -N 10000 -g 8。可以看出，busbw 可以達到 363 GiB/s，而每個 GPU 的 NVLink 通信帶寬可以達到 170-190 GiB/s。

如下圖所示，啟用 NVLink SHARP，也就是：NCCL_NVLS_ENABLE=1 all_reduce_perf -b 16G -e 16G -N 10000 -g 8。可以看出，busbw 可以達到 480 GiB/s，而每個 GPU 的 NVLink 通信帶寬則只有達到 100-130 GiB/s。也就是說，此時的 busbw 更大，而 NVLink 通信帶寬更低，這主要是利用了 NVSwitch 的 BroadCast 和 Reduce 能力，可以降低通信量。

同時，我們也將 8 個 GPU 分成 2 組，每組 4 個 GPU 進行 AllReduce 操作，首先在 22:29 啟動 0-3 號 GPU 的 AllReduce，然后在 22:32 啟動 4-7 號 GPU 的 AllReduce。可以看出，0-3 號 GPU 的通信帶寬并沒有下降，始終為 254 GiB/s 左右。表明不同 GPU 之間的 NVLink 并沒有產生干擾，這主要得益于使用 NVSwitch 實現了 GPU 全互聯，每個 GPU 理論上都能達到 NVLink 帶寬的極限。

四、GPU 異常或錯誤

4.1 Xid Error

Xid Error 是 NVIDIA GPU 在運行過程中遇到的一種硬件或驅動層面的錯誤。Xid Error 通常會出現在 NVIDIA 驅動程序的日志中，并帶有一個特定的錯誤代碼。此錯誤碼可以通過 DCGM 的  DCGM_FI_DEV_XID_ERRORS 獲取，表示一段時間內，最后發生的 Xid 錯誤碼。

如下圖所示為一些常見的通常由用戶應用程序導致的錯誤：

如下圖所示為一些常見的通常由硬件導致的錯誤，往往需要重置 GPU 或者報修：

4.2 SXid Error

 Sxid Error 是 NVIDIA 為 NVSwitch 提供的類似于 Xid Error 的機制，會在系統內核日志中報告與 NVSwitch 硬件相關的錯誤狀況。Sxid Error 分為非致命性（Non-Fatal）錯誤和致命性（Fatal）錯誤。

NVSwitch 非致命性 SXid Error 僅用于參考，nvidia-fabricmanager 不會終止正在運行的 CUDA 應用，亦不會阻止新的 CUDA 應用啟動。已有的 CUDA 應用應該能恢復運行；然而，根據具體錯誤類型，CUDA 應用可能會遭遇性能下降、短暫停滯不前等問題。

當在連接 GPU 與 NVSwitch 之間的 NVSwitch 端口上報致命性 SXid Error 時，該錯誤將傳播至 GPU。運行在該 GPU 上的 CUDA 應用將被終止，且 GPU 可能報告 Xid 74 和 Xid 45 錯誤。FabricManager 服務將在其日志文件和系統日志中記錄相應的 GPU 索引及 PCI 總線信息。系統管理員必須在為 GPU 分配額外的 CUDA 工作負載前，采用以下恢復程序清除錯誤狀態：

• 通過 nvidia-smi 重置指定的 GPU（以及受影響工作負載中涉及的所有 GPU）。可參考 nvidia-smi 中的 -r 或 --gpu-reset 選項。
• 也可嘗試重啟 nvidia-fabricmanager 服務，若問題依舊，可以嘗試重啟整個節點。

可以在 DCGM 的下述兩個監控中獲得相應 Sxid Error：

• DCGM_FI_DEV_NVSWITCH_FATAL_ERRORS：最后一個致命性錯誤。
• DCGM_FI_DEV_NVSWITCH_NON_FATAL_ERRORS：最后一個非致命性錯誤。

4.3 Memory Row ReMap

NVIDIA GPU 顯存經常出現的一個問題是 GPU 顯存行重映射，可以使用 DCGM_FI_DEV_ROW_REMAP_PENDING 獲取，具體含義是：GPU 的顯存行（row）映射操作正在等待處理或掛起。這通常是一個與顯存或硬件資源重新映射相關的錯誤，可能是由于顯存損壞、硬件故障或內存管理問題導致的。

盡管上述錯誤通常表明 GPU 存在可糾正的錯誤，并且應用程序仍可使用這些 GPU，但強烈建議及時重置這些 GPU。若應用將 GPU 內存使用推向接近滿載，作業崩潰的可能性將顯著增加。

五、案例展示

5.1 任務降速

如下圖所示為我們實際業務中遇到的一個 Fail-slow 問題。具體來說，我們發現任務訓練的速度不符合預期，通過觀察每個 Worker 的 GPU SM Active，發現存在一個 GPU 的 SM Active 指標明顯高于其他 GPU。經調查后發現該 GPU 上存在被搶占的情況，導致對應的 Worker 成為 Straggler，進而整個任務的所有 GPU 被拖累。紅框中驅逐異常搶占后任務速度恢復正常：

如下圖所示，Megatron-LM 最近也加入了 Straggler 檢測相關的實現（Megatron-LM/megatron/training/training.py [11]）：

5.2 周期性降速

我們還遇到過任務周期性降速的問題，起初懷疑過 DataLoader 和 Checkpointing 的問題，也懷疑過節點有周期性任務導致，依次被排除；也進一步排查了 CPU、GPU、網絡等均未發現明顯問題；最終發現某個 Rank 中 Python 的垃圾回收機制會導致一直持有 GIL，進而導致當前 Rank 成為 Straggler，拖累整個訓練任務。當任務規模比較大時，多個 Rank 在一段時間內陸續成為 Straggler，進而放大該問題的影響范圍：

解決上述問題的方法也比較簡單粗暴，比如 Megatron-LM 中就有主動 GC（Garbage Collect） 的選項（Megatron-LM/megatron/training/training.py [11]）。如下圖所示，可以在一定的 Step 后所有 Rank 同時主動 GC，這樣就可以將所有 Rank 的 GC 放在同一時間，降低對整個任務的影響：

5.3 NVSwitch nvidia-fabricmanager 問題

我們在 H100 系統上也遇到過 nvidia-fabricmanager 的問題。具體來說，我們發現多機分布式訓練時 Pytorch 在初始化節點會 Hang 住，甚至用 NCCL 的 AllReduce 測試也會 Hang，但將 NCCL_ALGO=Ring 則可以正常執行。最終發現是節點上某進程 OOM 導致 nvidia-fabricmanager 被 Kill。而在 H100 的 NVSwitch 上支持 NVLink Sharp，所以 NCCL 的 AllReduce 默認會使用 NCCL_ALGO=NVSL，此時 nvidia-fabricmanager service 異常就導致整個任務 Hang 住，通過重啟 nvidia-fabricmanager 可以解決（有些時候也需要重啟機器 NCCL 2.18 / Cuda 12.2 fails on H100 system with transport/nvls.cc:165 NCCL WARN Cuda failure 'invalid argument' · Issue #976 · NVIDIA/nccl · GitHub [12]）。

5.4 用戶 Xid Error 問題

我們遇到過很多 Xid Error，如下圖所示，任務訓練時遇到過 Pytorch 拋出 CUDA error: an illegal memory access was encountered 錯誤：

同時查看相關系統信息發現 GPU 有 Xid 31 的錯誤：

進一步根據 NVIDIA Xid 文檔（1. Introduction — XID Errors r555 documentation [13]）可知，Xid 31 大部分為用戶程序問題，比如訪存越界等，但也有一定可能是驅動 Bug 或硬件 Bug：

5.5 硬件 Xid Error

Meta 在 [2410.21680] Revisiting Reliability in Large-Scale Machine Learning Research Clusters [14] 中也提到過一系列 Xid 相關 Error：比如，作者觀察到 PCIe 錯誤常與 Xid 79（通常意味著掉卡，比如從 PCIe 總線上斷開鏈接）和 IPMI “Critical Interrupt” 同時發生。在作者的兩個集群上，作者觀察到 43% 和 63% 的 PCIe 錯誤與 Xid 79 共現。此外，作者在兩個集群還觀察到 2% 和 6% 的 IB 鏈路故障與 GPU 故障（如與總線斷開連接）同時發生，這可能表明與 PCIe 存在關聯。

我們也遇到過類似案例，如下圖所示，使用 Pytorch 訓練時遇到 CUDA error: unknown error 的問題：

進一步排查發現系統中同時出現了 pciehp Link Down，Xid 79（GPU fallen off the bus）以及 NVSwitch timeout 的錯誤，與此同時還在后續出現 Xid 45 的錯誤，這個就是常見的掉卡問題。

其實 Xid 也經常會一起出現，如下圖所示，一個 uncorrectable 的 ECC Error 往往會伴隨多個不同的 Xid 同時出現：

5.6 Meta GPU GSP Error

Meta 在 [2410.21680] Revisiting Reliability in Large-Scale Machine Learning Research Clusters [14] 中也提到過 GSP（GPU System Processor） 相關問題，我們在實際生產環境也遇到過，阿里云的 FAQ 中也有相關介紹，如下所示，具體可以參考 ACK集群GPU使用常見問題和解決方法- 容器服務Kubernetes 版 ACK - 阿里云 [6]：

5.7 IBM GPU Memory Row ReMap 問題

IBM 在 [2407.05467] The infrastructure powering IBM's Gen AI model development [15] 中提到了 GPU 顯存行重映射問題。

作者專門設立了一個面板（如下圖 Figure 12(c) 所示），通知系統管理員發生顯存行重映射的這些節點無負載，可進行重置。需強調的是，GPU 內存損壞故障可能導致應用程序層面的隱晦錯誤。應用程序可能在訓練迭代中日志顯示損失值膨脹前，持續運行而未顯露問題。這些故障可能在訓練過程中的任何時刻發生，若不監控損失曲線的收斂情況，將導致大量 GPU 時間的浪費。DCGM 診斷（1 級和 2 級）無法檢測此問題，需進行 3 級診斷，這要求獨占 GPU 訪問權限。為此，作者的 Autopilot 將此測試納入侵入性測試，當 GPU 未用于 AI 工作負載時運行。測試結果導出至 Prometheus 和節點標簽，以便監控和分析。

5.8 Meta Lemon 節點

Meta 在 [2410.21680] Revisiting Reliability in Large-Scale Machine Learning Research Clusters [14] 中還提到了 Lemon 節點的問題。Lemon 節點是指那些作業失敗率顯著高于平均水平的節點。

為了識別 Lemon 節點，Meta 作者設計、實施并評估了 lemon 檢測機制，在兩個集群成功識別出 RSC-1（共 2000 A100 節點）和 RSC-2（16 個節點，共 1000 A100 節點）中的 40 個故障節點。這些被識別的 lemon 節點占 RSC-1 總規模的 1.2%，每日作業的 13%。這種 lemon 檢測機制使得大規模作業（512+ GPU）的失敗率降低 10%，從 14% 降低至 4%。

我們在新集群的起始階段也遇到過類似問題，具體來說，我們發現某些節點的 GPU 頻繁出現 Xid Error 而導致任務異常，當我們將這些節點驅逐后發現任務穩定性明顯提升。

5.9 幻方 AI 常見 Xid 錯誤

幻方 AI 在 [2408.14158] Fire-Flyer AI-HPC: A Cost-Effective Software-Hardware Co-Design for Deep Learning [16] 中也介紹過一系列的 Xid Error。如下圖 Table V 所示，作者展示了常見的 Xid Error 和對應的原因：

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

5.10 Meta LLaMA 3.1 預訓練 GPU 問題

Meta 在訓練 LLaMA 3 405B 模型時，使用了 15T Token，16384 H100 GPU，MFU 為 41%，那么對應的理想訓練時間為：

15T*6*405B/(16384*989T*41%)/3600/24=42.3 天

然而，Meta 在 LLaMA 3 的技術報告 [2407.21783] The Llama 3 Herd of Models [17]  中介紹 LLaMA 3 的預訓練時間在 54 天左右，比 42.3 天多一些，其中一個原因可能是其提到的各種故障導致。

作者提到，在 54 天的訓練中，共遇到了 466 個任務中斷，其中包括 47 次的有計劃中斷，以及 419 次的預期外中斷。在這些非預期中斷中，78% 是硬件問題，例如 GPU 或物理機其他組件的異常，其中 GPU 相關問題占到 58.7%。盡管有大量的異常，但是由于自動化運維手段的幫助，只有 3 次非預期中斷是需要人工干預的。

5.11 上海 AI-Lab 集群異常問題

上海 AI-Lab 等團隊在 [2403.07648] Characterization of Large Language Model Development in the Datacenter [18] 中也對集群中的錯誤進行過歸類，這里的 NVLink Error、ECC Error 等通常也會對應到 Xid Error。

如下圖 Table 3 所示為具體的錯誤類型，總共可以分為 3 類：

• Infrastructure：主要是計算平臺和遠程存儲的問題。主要發生在作業執行中，其會影響訓練進度。

此種異常失敗的作業通常使用了大量 GPU，并且恢復的代價往往比較高。雖然失敗數量上只占了 11%，但GPU 資源（GPU 時間）上占了 82%。并且大部分是預訓練任務，可能會多次遇到硬件故障，例如GPU 問題（CUDAError、ECCError），NVLink 問題（NVLinkError）和網絡問題（NCCLRemoteError、S3StoreError）。而其中的 NodeFailure 表示未知硬件問題導致的故障。解決這些問題需要細致的診斷工作，以查明根因。通常需要維護或更換有缺陷的硬件，然后重啟作業。

作者甚至提到了高溫可能導致的故障率增加，當預訓練時，機房溫度升高了 5 度，此外作者也發現大部分異常發生在 2023.07，是最熱的月份。

• Framework：主要是幾種運行錯誤，比如 RuntimeError、ValueError、AttributeError，主要是 Tensor 操作、Shape 以及數據類型相關，或者一系列不符合預期的行為。通常發生在作業起始階段。
• Script：通常是用戶編碼錯誤等，通過修改代碼解決。?

六、參考鏈接

1. ??https://pytorch.org/blog/maximizing-training/??
2. ??https://github.com/NVIDIA/DCGM??
3. ??https://github.com/NVIDIA/dcgm-exporter??
4. ??https://github.com/NVIDIA/dcgm-exporter/tree/main/grafana??
5. ??https://github.com/NVIDIA/DCGM/blob/b0ec3c624ea21e688b0d93cf9b214ae0eeb6fe52/dcgmlib/src/dcgm_fields.cpp??
6. ??https://www.alibabacloud.com/help/zh/ack/ack-managed-and-ack-dedicated/user-guide/introduction-to-metrics??
7. ??https://docs.nvidia.com/datacenter/tesla/fabric-manager-user-guide/index.html??
8. ??https://docs.nvidia.com/deploy/xid-errors/index.html??
9. ??https://www.volcengine.com/docs/6459/974350??
10. ??https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/user-guide/use-node-diagnosis-to-self-troubleshoot-gpu-node-problems??
11. ??https://github.com/NVIDIA/Megatron-LM/blob/main/megatron/training/training.py??
12. ??https://github.com/NVIDIA/nccl/issues/976#issuecomment-1697103183??
13. ??https://docs.nvidia.com/deploy/xid-errors/index.html??
14. ??https://arxiv.org/abs/2410.21680??
15. ??https://arxiv.org/abs/2407.05467??
16. ??https://www.arxiv.org/abs/2408.14158??
17. ??https://arxiv.org/abs/2407.21783??
18. ??https://arxiv.org/abs/2403.07648??
19. ??https://github.com/NVIDIA/DCGM/issues/64??

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