一、背景

在之前的多篇文章中，我們曾零星提到過 GPU 利用率以及 GPU 異常引發(fā)的大規(guī)模任務(wù)失敗問題。在本文中，我們將對這些內(nèi)容進(jìn)行更為系統(tǒng)的匯總，具體介紹常見的 GPU 監(jiān)控指標(biāo)及各種 GPU 異常情況。為了更好地說明問題，我們還將結(jié)合我們自己的實(shí)踐經(jīng)驗(yàn)以及其他相關(guān)論文中的案例進(jìn)行分析和討論。

二、引言

2.1 MFU & HFU

為了評估 LLM 訓(xùn)練時的效率，業(yè)界通常會使用 Model FLOPS Utilization（MFU） 和 Hardware FLOPS Utilization（HFU） 兩個關(guān)鍵指標(biāo)來評估模型的 Forward 和 Backward 過程中（包括任何的網(wǎng)絡(luò)同步開銷和 DataLoader IO）硬件的利用率。

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

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

2.2 GPU 監(jiān)控集成

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 集群管理和監(jiān)控而設(shè)計(jì)的工具，其涵蓋健康檢測、全面診斷、系統(tǒng)報(bào)警及治理策略等。DCGM 通過 DCGM-Exporter（NVIDIA GPU metrics exporter for Prometheus leveraging DCGM [3]）可以很方便的與 Kubernetes 生態(tài)系統(tǒng)集成，為容器化環(huán)境提供豐富的 GPU 監(jiān)測數(shù)據(jù)。

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

2.3 GPU 監(jiān)控指標(biāo)

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

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

PS：由于指標(biāo)眾多，本文中只會介紹一些關(guān)鍵指標(biāo)，更多指標(biāo)可以根據(jù)實(shí)際需求相應(yīng)添加。

2.4 NVIDIA Fabric Manager

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

NVIDIA FM（Fabric Manager）負(fù)責(zé)配置 NVSwitch 內(nèi)存結(jié)構(gòu)，以在所有參與的 GPU 之間形成一個統(tǒng)一的內(nèi)存結(jié)構(gòu)，并監(jiān)控支持該結(jié)構(gòu)的 NVLink。從較高層次來看，F(xiàn)M 承擔(dān)以下職責(zé)：

• 配置 NVSwitch 端口之間的路由；
• 與 GPU 驅(qū)動程序協(xié)調(diào)，初始化GPU；
• 監(jiān)控結(jié)構(gòu)中的 NVLink 和 NVSwitch 錯誤。?

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

2.5 GPU 故障

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

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

三、GPU 利用率指標(biāo)

3.1 GPU Utilization

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

其實(shí)更早之前的 Utilization 指標(biāo)為 DCGM_FI_DEV_GPU_UTIL，只是因?yàn)槠渚窒扌袁F(xiàn)在往往會使用 DCGM_FI_PROF_GR_ENGINE_ACTIVE，更多說明也可以參考：Question about DCGM fields · Issue #64 [19]。

3.2 GPU SM Active

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

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

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

3.3 GPU SM Occupancy

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

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

3.4 GPU Tensor Active

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

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

3.5 GPU NVLink Bandwidth

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

3.5 實(shí)驗(yàn)

3.5.1 GPU Util & SM Active

如下圖所示，我們在 T4 GPU（包含 40 個 SM） 上通過一個小的實(shí)驗(yàn)來說明幾個指標(biāo)的關(guān)系：

• 當(dāng)只有1 個 Block，1 個 Thread時，GPU Util 也是 100%，因?yàn)?GPU 一直在占用，此時 40 個 SM 中只有 1 個一直 Active，所以 SM Active 為 2.5%。
• 當(dāng)有 40 個 Block，每個 Block 1 個 Thread時，GPU Util 為 100%，SM Active 也為 100%，因?yàn)槊總€ Block 都會占用一個 SM。
• 當(dāng)有 40 個 Block，每個 Block 128 個 Thread時，GPU Util 為 100%，SM Active 也為 100%，因?yàn)槊總€ Block 都會占用一個 SM。此時 SM Occupancy 到了 12.5%。?

3.5.2 Tensor Active

如下圖所示，我們在 H100 GPU（包含 132 個 SM，每個 SM 上 4 個 Tensor Core） 上通過一個小的實(shí)驗(yàn)來說明 Tensor Active 指標(biāo)的關(guān)系。因?yàn)?Tensor Core 用于矩陣乘法，所以這里我們構(gòu)造了一個 C(M, N) = A(M, K) x B(K, N) 的矩陣乘法操作， 而每個 Block 負(fù)責(zé)的是 C(16, 16) = A(16, K) x B(K, 16) 的計(jì)算：

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

PS：Tensor Core 不支持 FP32 的矩陣乘法，上述實(shí)驗(yàn)使用的是 FP16 的矩陣乘法。

3.5.3 Tensor Active & HFU

我們在進(jìn)行大規(guī)模 LLM 預(yù)訓(xùn)練時通常會關(guān)注相應(yīng)的 MFU，以便評估 GPU 算力發(fā)揮水平，了解當(dāng)前訓(xùn)練任務(wù)是否還有比較大的優(yōu)化空間。然而，有些任務(wù)并沒有提供相應(yīng)的 MFU 指標(biāo)，此時可以使用 Tensor Active 指標(biāo)來近似 HFU。

Tensor Active 可以近似 HFU 的上限，主要是因?yàn)?LLM 中的大部分操作是矩陣乘法，而且往往會采用 BF16 來訓(xùn)練，此時主要的計(jì)算都由 Tensor Core 來承擔(dān)，而 Tensor Active 正好可以反應(yīng) Tensor Core 的發(fā)揮水平。（PS：我們在實(shí)際的訓(xùn)練任務(wù)中也有驗(yàn)證，基本符合預(yù)期。）

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

3.5.4 NVLink Bandwidth - all2all

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

對應(yīng)的 busbw 約為 350GB/s:

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

每個 GPU Lane 0 的 Bandwidth 達(dá)到 16 GiB/s，對應(yīng)總帶寬為 16*18=288 GiB/s

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

3.5.5 NVLink Bandwidth - allreduce

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

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

如下圖所示，關(guān)閉 NVLink SHARP，也就是：NCCL_NVLS_ENABLE=0 all_reduce_perf -b 16G -e 16G -N 10000 -g 8?？梢钥闯?，busbw 可以達(dá)到 363 GiB/s，而每個 GPU 的 NVLink 通信帶寬可以達(dá)到 170-190 GiB/s。

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

同時，我們也將 8 個 GPU 分成 2 組，每組 4 個 GPU 進(jìn)行 AllReduce 操作，首先在 22:29 啟動 0-3 號 GPU 的 AllReduce，然后在 22:32 啟動 4-7 號 GPU 的 AllReduce?？梢钥闯?，0-3 號 GPU 的通信帶寬并沒有下降，始終為 254 GiB/s 左右。表明不同 GPU 之間的 NVLink 并沒有產(chǎn)生干擾，這主要得益于使用 NVSwitch 實(shí)現(xiàn)了 GPU 全互聯(lián)，每個 GPU 理論上都能達(dá)到 NVLink 帶寬的極限。

四、GPU 異?；蝈e誤

4.1 Xid Error

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

如下圖所示為一些常見的通常由用戶應(yīng)用程序?qū)е碌腻e誤：

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

4.2 SXid Error

 Sxid Error 是 NVIDIA 為 NVSwitch 提供的類似于 Xid Error 的機(jī)制，會在系統(tǒng)內(nèi)核日志中報(bào)告與 NVSwitch 硬件相關(guān)的錯誤狀況。Sxid Error 分為非致命性（Non-Fatal）錯誤和致命性（Fatal）錯誤。

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

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

• 通過 nvidia-smi 重置指定的 GPU（以及受影響工作負(fù)載中涉及的所有 GPU）?？蓞⒖?nvidia-smi 中的 -r 或 --gpu-reset 選項(xiàng)。
• 也可嘗試重啟 nvidia-fabricmanager 服務(wù)，若問題依舊，可以嘗試重啟整個節(jié)點(diǎn)。

可以在 DCGM 的下述兩個監(jiān)控中獲得相應(yīng) Sxid Error：

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

4.3 Memory Row ReMap

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

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

五、案例展示

5.1 任務(wù)降速

如下圖所示為我們實(shí)際業(yè)務(wù)中遇到的一個 Fail-slow 問題。具體來說，我們發(fā)現(xiàn)任務(wù)訓(xùn)練的速度不符合預(yù)期，通過觀察每個 Worker 的 GPU SM Active，發(fā)現(xiàn)存在一個 GPU 的 SM Active 指標(biāo)明顯高于其他 GPU。經(jīng)調(diào)查后發(fā)現(xiàn)該 GPU 上存在被搶占的情況，導(dǎo)致對應(yīng)的 Worker 成為 Straggler，進(jìn)而整個任務(wù)的所有 GPU 被拖累。紅框中驅(qū)逐異常搶占后任務(wù)速度恢復(fù)正常：

如下圖所示，Megatron-LM 最近也加入了 Straggler 檢測相關(guān)的實(shí)現(xiàn)（Megatron-LM/megatron/training/training.py [11]）：

5.2 周期性降速

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

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

5.3 NVSwitch nvidia-fabricmanager 問題

我們在 H100 系統(tǒng)上也遇到過 nvidia-fabricmanager 的問題。具體來說，我們發(fā)現(xiàn)多機(jī)分布式訓(xùn)練時 Pytorch 在初始化節(jié)點(diǎn)會 Hang 住，甚至用 NCCL 的 AllReduce 測試也會 Hang，但將 NCCL_ALGO=Ring 則可以正常執(zhí)行。最終發(fā)現(xiàn)是節(jié)點(diǎn)上某進(jìn)程 OOM 導(dǎo)致 nvidia-fabricmanager 被 Kill。而在 H100 的 NVSwitch 上支持 NVLink Sharp，所以 NCCL 的 AllReduce 默認(rèn)會使用 NCCL_ALGO=NVSL，此時 nvidia-fabricmanager service 異常就導(dǎo)致整個任務(wù) Hang 住，通過重啟 nvidia-fabricmanager 可以解決（有些時候也需要重啟機(jī)器 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，如下圖所示，任務(wù)訓(xùn)練時遇到過 Pytorch 拋出 CUDA error: an illegal memory access was encountered 錯誤：

同時查看相關(guān)系統(tǒng)信息發(fā)現(xiàn) GPU 有 Xid 31 的錯誤：

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

5.5 硬件 Xid Error

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

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

進(jìn)一步排查發(fā)現(xiàn)系統(tǒng)中同時出現(xiàn)了 pciehp Link Down，Xid 79（GPU fallen off the bus）以及 NVSwitch timeout 的錯誤，與此同時還在后續(xù)出現(xiàn) Xid 45 的錯誤，這個就是常見的掉卡問題。

其實(shí) Xid 也經(jīng)常會一起出現(xiàn)，如下圖所示，一個 uncorrectable 的 ECC Error 往往會伴隨多個不同的 Xid 同時出現(xiàn)：

5.6 Meta GPU GSP Error

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

5.7 IBM GPU Memory Row ReMap 問題

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

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

5.8 Meta Lemon 節(jié)點(diǎn)

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

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

我們在新集群的起始階段也遇到過類似問題，具體來說，我們發(fā)現(xiàn)某些節(jié)點(diǎn)的 GPU 頻繁出現(xiàn) Xid Error 而導(dǎo)致任務(wù)異常，當(dāng)我們將這些節(jié)點(diǎn)驅(qū)逐后發(fā)現(xiàn)任務(wù)穩(wěn)定性明顯提升。

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 和對應(yīng)的原因：

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

5.10 Meta LLaMA 3.1 預(yù)訓(xùn)練 GPU 問題

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

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

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

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

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

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

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

• Infrastructure：主要是計(jì)算平臺和遠(yuǎn)程存儲的問題。主要發(fā)生在作業(yè)執(zhí)行中，其會影響訓(xùn)練進(jìn)度。

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

作者甚至提到了高溫可能導(dǎo)致的故障率增加，當(dāng)預(yù)訓(xùn)練時，機(jī)房溫度升高了 5 度，此外作者也發(fā)現(xiàn)大部分異常發(fā)生在 2023.07，是最熱的月份。

• Framework：主要是幾種運(yùn)行錯誤，比如 RuntimeError、ValueError、AttributeError，主要是 Tensor 操作、Shape 以及數(shù)據(jù)類型相關(guān)，或者一系列不符合預(yù)期的行為。通常發(fā)生在作業(yè)起始階段。
• 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??

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