控與故障診斷：NCCL Benchmark與GPU指標(biāo)實(shí)戰(zhàn))
1. 智算集群為什么需要一套“聽診器”搞過大規(guī)模訓(xùn)練的人都有一個(gè)共同體會(huì)集群規(guī)模一旦上去故障就不再是“某臺(tái)機(jī)器壞了”這么簡單而是變成了一種系統(tǒng)性、間歇性、難以復(fù)現(xiàn)的疑難雜癥。你可能遇到過訓(xùn)練跑了三天突然 loss 炸了重啟之后又好了也可能遇到過某個(gè)節(jié)點(diǎn)吞吐量莫名其妙比其他節(jié)點(diǎn)低 30%但查遍日志什么錯(cuò)誤都沒有。這類問題靠傳統(tǒng)的nvidia-smi和dmesg根本定位不了你需要一套專門為 AI 集群設(shè)計(jì)的“聽診器”——這就是Benchmark、監(jiān)控與故障診斷體系存在的意義。這套體系解決的核心問題有三個(gè)第一性能基線問題你得知道集群在健康狀態(tài)下應(yīng)該跑出什么數(shù)字才能判斷現(xiàn)在是不是有問題第二實(shí)時(shí)可觀測性問題訓(xùn)練過程中的 GPU 利用率、顯存帶寬、NVLink 流量、網(wǎng)絡(luò) RDMA 吞吐這些指標(biāo)必須持續(xù)采集而不是出事了才去看第三故障歸因問題當(dāng)性能下降發(fā)生時(shí)能快速定位到是計(jì)算、通信、存儲(chǔ)還是調(diào)度層面的瓶頸。適合讀這篇內(nèi)容的人包括正在搭建或運(yùn)維 GPU 集群的工程師、負(fù)責(zé)大模型訓(xùn)練基礎(chǔ)設(shè)施的 SRE、需要做集群驗(yàn)收和性能調(diào)優(yōu)的技術(shù)負(fù)責(zé)人以及想了解 AI 集群運(yùn)維體系長什么樣的開發(fā)者。我會(huì)從整體設(shè)計(jì)思路講到具體實(shí)操包括 NCCL 測試怎么做、Prometheus 怎么采集 GPU 指標(biāo)、常見故障怎么排查盡量把踩過的坑都攤開講。2. 整體設(shè)計(jì)思路從“事后救火”到“事前體檢”2.1 為什么傳統(tǒng)監(jiān)控方案在 AI 集群上不夠用傳統(tǒng) IDC 監(jiān)控關(guān)注的是 CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)帶寬這些通用指標(biāo)用 Zabbix 或者基礎(chǔ)的 Prometheus 就能覆蓋。但 AI 集群的負(fù)載特征完全不同GPU 是核心計(jì)算資源它的利用率、顯存占用、溫度、功耗、ECC 錯(cuò)誤、NVLink 帶寬這些指標(biāo)傳統(tǒng)工具根本采集不到。更關(guān)鍵的是AI 訓(xùn)練是集合通信密集型的負(fù)載一次 AllReduce 操作涉及成百上千張卡同步任何一張卡或任何一條鏈路出現(xiàn)微小的性能抖動(dòng)都會(huì)拖慢整個(gè)通信組進(jìn)而拖慢整個(gè)訓(xùn)練任務(wù)。我見過一個(gè)真實(shí)案例一個(gè) 64 卡集群訓(xùn)練吞吐比預(yù)期低了 15%查了一周沒找到原因最后用 NCCL 的帶寬測試逐對(duì)檢測發(fā)現(xiàn)其中兩臺(tái)機(jī)器之間的 InfiniBand 鏈路協(xié)商速率從 200Gbps 降到了 100Gbps原因是其中一端的線纜接頭有輕微松動(dòng)。這種問題傳統(tǒng)監(jiān)控完全看不到只有專門的集合通信 Benchmark 才能暴露出來。所以 AI 集群的“聽診器”體系必須包含三個(gè)層次基準(zhǔn)測試層Benchmark回答“應(yīng)該多快”、持續(xù)監(jiān)控層Monitoring回答“現(xiàn)在多快”、故障診斷層Diagnosis回答“為什么變慢”。三者缺一不可而且必須形成閉環(huán)——Benchmark 提供基線監(jiān)控對(duì)比基線發(fā)現(xiàn)異常診斷定位根因。2.2 三層體系的具體分工與工具選型基準(zhǔn)測試層的核心工具是 NCCL Tests、GPU Burn、STREAM Benchmark、FIO存儲(chǔ)、iperf3網(wǎng)絡(luò)。其中 NCCL Tests 是重中之重因?yàn)榧贤ㄐ判阅苤苯記Q定分布式訓(xùn)練效率。NCCL Tests 包含 all_reduce、all_gather、broadcast、reduce_scatter 等多個(gè)測試項(xiàng)可以測不同消息大小下的帶寬和延遲。持續(xù)監(jiān)控層的標(biāo)準(zhǔn)組合是 Prometheus Grafana DCGM Exporter。DCGM 是 NVIDIA 的數(shù)據(jù)中心 GPU 管理器它暴露的指標(biāo)非常全面包括 GPU 利用率、顯存使用、SM 活躍度、Tensor Core 活躍度、NVLink 帶寬、PCIe 帶寬、ECC 錯(cuò)誤計(jì)數(shù)、XID 錯(cuò)誤等。Prometheus 負(fù)責(zé)拉取和存儲(chǔ)Grafana 負(fù)責(zé)可視化。對(duì)于網(wǎng)絡(luò)層可以加上 InfiniBand 的 performance counters 采集對(duì)于節(jié)點(diǎn)層node_exporter 負(fù)責(zé) CPU、內(nèi)存、磁盤指標(biāo)。故障診斷層則更多依賴工具組合和排查經(jīng)驗(yàn)。常用手段包括NCCL 的 debug 日志NCCL_DEBUGINFO、nvidia-smi -q的詳細(xì)輸出、DCGM 的診斷模式dcgmi diag、XID 錯(cuò)誤碼查詢、以及針對(duì)性的微基準(zhǔn)測試。這一層沒有銀彈更多是靠體系化的排查流程和積累的經(jīng)驗(yàn)。注意工具選型不要貪多求全。我見過有團(tuán)隊(duì)同時(shí)跑了三套監(jiān)控系統(tǒng)結(jié)果數(shù)據(jù)互相矛盾排查時(shí)反而更混亂。建議以 Prometheus DCGM Exporter 為核心其他工具按需補(bǔ)充。2.3 基線建立一切診斷的前提沒有基線的監(jiān)控就是一堆沒有意義的數(shù)字。建立基線的方法是在集群健康且空閑的狀態(tài)下跑一輪完整的 Benchmark 套件記錄下每個(gè)測試項(xiàng)的性能數(shù)據(jù)。這個(gè)基線要包括單卡 FP16/FP32 算力用 GPU Burn 或?qū)ｉT的算力測試、單機(jī)內(nèi) NVLink 帶寬、跨機(jī) InfiniBand 帶寬用 NCCL Tests 的 all_reduce、存儲(chǔ)讀寫帶寬用 FIO、以及典型訓(xùn)練任務(wù)的吞吐tokens/sec 或 samples/sec。基線數(shù)據(jù)要存檔并且標(biāo)注測試時(shí)的環(huán)境信息驅(qū)動(dòng)版本、CUDA 版本、NCCL 版本、交換機(jī)固件版本、拓?fù)浣Y(jié)構(gòu)。因?yàn)槿魏我豁?xiàng)變更都可能導(dǎo)致基線漂移比如 NCCL 版本升級(jí)后 all_reduce 帶寬可能提升也可能下降沒有版本標(biāo)注的基線數(shù)據(jù)是沒有參考價(jià)值的。3. 核心細(xì)節(jié)解析NCCL Benchmark 與 GPU 監(jiān)控實(shí)操3.1 NCCL Tests 的正確打開方式NCCL Tests 的編譯很簡單從官方倉庫 clone 下來make就行但關(guān)鍵在于怎么跑才有意義。很多人直接跑一個(gè)默認(rèn)參數(shù)的 all_reduce 就完事了這樣得到的數(shù)據(jù)參考價(jià)值有限。正確的做法是覆蓋多個(gè)維度消息大小從 8 bytes 到 8 GB覆蓋小消息延遲敏感和大消息帶寬敏感兩個(gè)區(qū)間GPU 數(shù)量至少測 2 卡、8 卡單機(jī)、16 卡、32 卡、64 卡跨機(jī)觀察擴(kuò)展效率拓?fù)涓兄肗CCL_TOPO_DUMP_FILE導(dǎo)出拓?fù)浯_認(rèn) NCCL 是否識(shí)別到了正確的 NVLink 和 InfiniBand 路徑一個(gè)典型的 all_reduce 測試命令如下# 8 卡單機(jī) all_reduce 測試 ./build/all_reduce_perf -b 8 -e 8G -f 2 -g 8 # 跨機(jī)測試需要 mpirun 或 torchrun 啟動(dòng) mpirun -np 16 -H node1:8,node2:8 \ -x NCCL_DEBUGINFO \ -x NCCL_IB_HCAmlx5_0,mlx5_1 \ ./build/all_reduce_perf -b 8 -e 8G -f 2 -g 1參數(shù)解釋-b是起始消息大小-e是結(jié)束大小-f是倍增因子2 表示每次翻倍-g是每進(jìn)程使用的 GPU 數(shù)?？鐧C(jī)測試時(shí)-g 1表示每個(gè)進(jìn)程用一張卡總共 16 個(gè)進(jìn)程對(duì)應(yīng) 16 張卡。跑完之后重點(diǎn)看兩個(gè)數(shù)字algbw算法帶寬和busbw總線帶寬。busbw 更能反映實(shí)際鏈路利用率計(jì)算公式是busbw algbw * 2 * (n-1) / n其中 n 是參與通信的 GPU 數(shù)。對(duì)于 8 卡 NVLink 全互聯(lián)的機(jī)器busbw 應(yīng)該接近 NVLink 的理論帶寬對(duì)于跨機(jī) InfiniBandbusbw 應(yīng)該接近 IB 鏈路帶寬的 80% 以上。實(shí)操心得跑 NCCL Tests 之前一定要確認(rèn) GPU 處于空閑狀態(tài)并且鎖定頻率。用nvidia-smi -lgc鎖定 GPU 時(shí)鐘用nvidia-smi -lmc鎖定顯存時(shí)鐘否則 GPU 會(huì)因?yàn)楣墓芾韯?dòng)態(tài)調(diào)頻導(dǎo)致測試結(jié)果波動(dòng)很大。我一般會(huì)把時(shí)鐘鎖在基頻這樣測出來的數(shù)據(jù)可比性最強(qiáng)。3.2 DCGM Exporter 部署與關(guān)鍵指標(biāo)解讀DCGM Exporter 的部署方式取決于你的環(huán)境。如果是 Kubernetes 集群用 Helm chart 部署最方便如果是裸機(jī)可以用 Docker 跑docker run -d --gpus all --rm \ -p 9400:9400 \ --name dcgm-exporter \ nvcr.io/nvidia/k8s/dcgm-exporter:3.3.0-3.2.0-ubuntu22.04跑起來之后訪問http://localhost:9400/metrics就能看到所有指標(biāo)。指標(biāo)很多但真正需要重點(diǎn)關(guān)注的其實(shí)就那么幾個(gè)指標(biāo)名稱含義異常判斷DCGM_FI_DEV_GPU_UTILGPU 計(jì)算利用率持續(xù)低于 80% 可能有瓶頸DCGM_FI_DEV_MEM_COPY_UTIL顯存帶寬利用率接近 100% 說明顯存瓶頸DCGM_FI_DEV_NVLINK_BANDWIDTH_TOTALNVLink 總帶寬突然下降可能是鏈路問題DCGM_FI_DEV_PCIE_REPLAY_COUNTERPCIe 重傳計(jì)數(shù)持續(xù)增長說明 PCIe 有問題DCGM_FI_DEV_XID_ERRORSXID 錯(cuò)誤碼非零值需要立即排查DCGM_FI_DEV_ECC_DBE_VOL_TOTAL顯存雙比特錯(cuò)誤非零值說明顯存硬件故障DCGM_FI_DEV_POWER_USAGE功耗異常低可能是降頻DCGM_FI_DEV_GPU_TEMP溫度超過 85 度需要關(guān)注散熱這些指標(biāo)接入 Prometheus 之后在 Grafana 上配置看板。我建議至少做三個(gè)看板集群總覽所有 GPU 的利用率熱力圖、單節(jié)點(diǎn)詳情單機(jī) 8 卡的各項(xiàng)指標(biāo)曲線、異常告警XID 錯(cuò)誤、ECC 錯(cuò)誤、溫度超限的實(shí)時(shí)列表。3.3 Prometheus 告警規(guī)則配置要點(diǎn)監(jiān)控沒有告警等于沒有監(jiān)控。Prometheus 的告警規(guī)則用 YAML 配置以下是我在實(shí)際環(huán)境中驗(yàn)證過有效的幾條核心規(guī)則groups: - name: gpu_alerts rules: - alert: GPUXIDError expr: DCGM_FI_DEV_XID_ERRORS 0 for: 1m labels: severity: critical annotations: summary: GPU XID error detected on {{ $labels.instance }} - alert: GPUTemperatureHigh expr: DCGM_FI_DEV_GPU_TEMP 83 for: 5m labels: severity: warning annotations: summary: GPU temperature high on {{ $labels.instance }} - alert: GPUMemoryECCDoubleBit expr: DCGM_FI_DEV_ECC_DBE_VOL_TOTAL 0 for: 1m labels: severity: critical annotations: summary: GPU double-bit ECC error on {{ $labels.instance }} - alert: NCCLBandwidthDrop expr: rate(DCGM_FI_DEV_NVLINK_BANDWIDTH_TOTAL[5m]) 100e9 for: 10m labels: severity: warning annotations: summary: NVLink bandwidth dropped on {{ $labels.instance }}注意告警閾值不要照搬網(wǎng)上的配置。不同型號(hào)的 GPU 溫度閾值不同A100 和 H100 的功耗曲線也不一樣。建議先跑一周的監(jiān)控觀察正常波動(dòng)范圍再設(shè)定閾值。告警太敏感會(huì)導(dǎo)致“狼來了”效應(yīng)運(yùn)維人員逐漸忽略告警這比沒有告警更危險(xiǎn)。4. 故障診斷實(shí)戰(zhàn)從現(xiàn)象到根因的排查路徑4.1 訓(xùn)練吞吐下降的排查決策樹訓(xùn)練吞吐下降是最常見的故障現(xiàn)象但原因可能五花八門。我總結(jié)了一套排查決策樹按順序執(zhí)行可以覆蓋 90% 以上的場景第一步確認(rèn)是全局問題還是局部問題。對(duì)比所有節(jié)點(diǎn)的 GPU 利用率如果所有節(jié)點(diǎn)都低說明是全局性問題可能是數(shù)據(jù)加載瓶頸、通信瓶頸、或者調(diào)度問題如果只有部分節(jié)點(diǎn)低說明是局部性問題可能是某張卡降頻、某條鏈路故障。第二步檢查 GPU 狀態(tài)。用nvidia-smi -q查看是否有降頻clocks throttle reason、是否有 ECC 錯(cuò)誤、是否有 XID 錯(cuò)誤。特別關(guān)注Clocks Throttle Reasons字段如果顯示HW Slowdown或SW Thermal Slowdown說明是散熱或功耗問題。第三步檢查通信。在訓(xùn)練腳本里設(shè)置NCCL_DEBUGINFO和NCCL_DEBUG_SUBSYSALL觀察 NCCL 初始化時(shí)選擇的通信路徑。如果發(fā)現(xiàn) NCCL 沒有走 InfiniBand 而是走了 TCP socket那性能肯定差。常見原因是NCCL_IB_HCA沒設(shè)置對(duì)或者 IB 驅(qū)動(dòng)有問題。第四步檢查存儲(chǔ)。如果數(shù)據(jù)加載是瓶頸GPU 利用率會(huì)呈現(xiàn)周期性波動(dòng)等待數(shù)據(jù)時(shí)降到 0數(shù)據(jù)來了又升上去。用iostat和fio檢查存儲(chǔ)帶寬是否達(dá)到預(yù)期。第五步檢查 CPU 和內(nèi)存。數(shù)據(jù)預(yù)處理如果放在 CPU 上做CPU 可能成為瓶頸。用htop看 CPU 利用率如果某個(gè)核跑滿而 GPU 在等那就是數(shù)據(jù)加載的問題。4.2 XID 錯(cuò)誤碼速查與處理XID 錯(cuò)誤是 NVIDIA GPU 的硬件級(jí)錯(cuò)誤碼每個(gè)碼對(duì)應(yīng)不同的故障類型。以下是我實(shí)際遇到過的高頻 XID 錯(cuò)誤XID 碼含義處理方式13Graphics engine exception通常是應(yīng)用程序 bug檢查 CUDA 代碼31GPU memory page fault顯存訪問越界檢查 kernel 代碼43GPU stopped processingGPU 掛起需要重置 GPU48Double-bit ECC error顯存硬件故障需要更換 GPU63ECC page retirement顯存頁退役記錄并觀察74NVLink errorNVLink 鏈路故障檢查物理連接79GPU has fallen off the busGPU 掉卡通常是硬件或供電問題92High single-bit ECC error rate單比特錯(cuò)誤率過高可能發(fā)展為雙比特94Contained ECC error可糾正的 ECC 錯(cuò)誤記錄觀察95Uncontained ECC error不可糾正的 ECC 錯(cuò)誤需要重置 GPU遇到 XID 錯(cuò)誤第一步是記錄錯(cuò)誤碼和發(fā)生時(shí)間第二步是查 NVIDIA 官方的 XID 錯(cuò)誤碼文檔確認(rèn)含義第三步是根據(jù)嚴(yán)重程度決定是重置 GPU、重啟節(jié)點(diǎn)還是報(bào)修硬件。XID 48 和 95 基本意味著 GPU 需要更換XID 74 需要檢查 NVLink 線纜和連接器。4.3 NCCL 通信故障的典型場景NCCL 相關(guān)的故障有幾個(gè)經(jīng)典場景我逐個(gè)說一下排查方法。場景一NCCL 初始化超時(shí)。訓(xùn)練啟動(dòng)時(shí)卡在 NCCL 初始化階段日志顯示NCCL INFO Bootstrap之后就沒有下文了。這通常是網(wǎng)絡(luò)連通性問題檢查所有節(jié)點(diǎn)之間的 SSH 免密是否配置正確、防火墻是否放行了 NCCL 使用的端口范圍、IB 網(wǎng)絡(luò)是否正常?？梢杂胕bstat檢查 IB 卡狀態(tài)用ibping測試節(jié)點(diǎn)間連通性。場景二NCCL 走了錯(cuò)誤的通信路徑。日志顯示NCCL INFO NET/Socket而不是NCCL INFO NET/IB說明 NCCL 沒有使用 InfiniBand。檢查NCCL_IB_HCA環(huán)境變量是否指向了正確的 HCA 設(shè)備檢查NCCL_IB_DISABLE是否被設(shè)為了 1檢查 IB 驅(qū)動(dòng)是否加載lsmod | grep ib。場景三AllReduce 帶寬遠(yuǎn)低于預(yù)期。用 NCCL Tests 測出來的 busbw 只有理論值的 30%?？赡茉虬℅PU 降頻、NVLink 鏈路降速、IB 交換機(jī)擁塞、NCCL 算法選擇不當(dāng)。可以嘗試設(shè)置NCCL_ALGORing或NCCL_ALGOTree強(qiáng)制使用不同算法看是否有改善。也可以設(shè)置NCCL_PROTOLL或NCCL_PROTOSimple切換協(xié)議。場景四訓(xùn)練過程中隨機(jī)出現(xiàn) NCCL timeout。這種間歇性故障最難排查。常見原因是某條鏈路有丟包或誤碼導(dǎo)致偶發(fā)的通信超時(shí)。檢查 IB 的 error countersperfquery命令如果SymbolErrorCounter或LinkErrorRecoveryCounter在增長說明鏈路質(zhì)量有問題。也可能是 GPU 偶發(fā)降頻導(dǎo)致通信超時(shí)檢查是否有 XID 錯(cuò)誤或溫度告警。實(shí)操心得NCCL 的日志級(jí)別用NCCL_DEBUGWARN就夠了INFO級(jí)別日志量太大在千卡集群上會(huì)把日志系統(tǒng)沖垮。只有在排查特定問題時(shí)才臨時(shí)開到INFO并且只對(duì)可疑節(jié)點(diǎn)開。另外NCCL_DEBUG_FILE可以把日志寫到文件而不是 stderr方便后續(xù)分析。5. 監(jiān)控體系的持續(xù)運(yùn)營與常見問題5.1 監(jiān)控?cái)?shù)據(jù)采集頻率與存儲(chǔ)規(guī)劃Prometheus 的采集頻率直接影響監(jiān)控精度和存儲(chǔ)成本。對(duì)于 GPU 指標(biāo)我建議采集間隔設(shè)為 15 秒這個(gè)精度足以捕捉到大多數(shù)性能波動(dòng)同時(shí)不會(huì)產(chǎn)生太大的存儲(chǔ)壓力。按 1000 張 GPU 計(jì)算每張卡約 50 個(gè)指標(biāo)15 秒采集一次每天產(chǎn)生的數(shù)據(jù)量大約是 1000 × 50 × 5760 2.88 億個(gè)數(shù)據(jù)點(diǎn)。Prometheus 的壓縮率大約是每樣本 1-2 字節(jié)所以每天約 300-600 MB保留 30 天需要 10-20 GB 存儲(chǔ)完全可以接受。如果需要更高精度的數(shù)據(jù)比如排查瞬時(shí)的性能抖動(dòng)可以臨時(shí)把采集間隔調(diào)到 1 秒但只針對(duì)可疑節(jié)點(diǎn)排查完就調(diào)回去。長期 1 秒采集會(huì)導(dǎo)致存儲(chǔ)爆炸。Grafana 看板的配置也有講究。集群總覽看板不要放太多面板否則加載慢且信息過載。我一般放四個(gè)核心面板GPU 利用率熱力圖、GPU 溫度分布、XID 錯(cuò)誤統(tǒng)計(jì)、NCCL 帶寬趨勢。詳細(xì)指標(biāo)放到下鉆看板里需要時(shí)再點(diǎn)進(jìn)去看。5.2 常見監(jiān)控問題與排查問題一DCGM Exporter 采集不到數(shù)據(jù)。首先確認(rèn)容器是否有--gpus all權(quán)限其次確認(rèn) NVIDIA 驅(qū)動(dòng)版本和 DCGM 版本是否兼容。DCGM 3.x 需要驅(qū)動(dòng) 450 以上DCGM 3.3 需要驅(qū)動(dòng) 525 以上。如果驅(qū)動(dòng)版本太低升級(jí)驅(qū)動(dòng)或者降級(jí) DCGM。問題二Prometheus 抓取目標(biāo)顯示 down。檢查 DCGM Exporter 的端口是否監(jiān)聽netstat -tlnp | grep 9400檢查 Prometheus 配置的 target 地址是否正確檢查防火墻是否放行了 9400 端口。如果是 Kubernetes 環(huán)境檢查 Service 和 Pod 的標(biāo)簽選擇器是否匹配。問題三Grafana 看板顯示 No Data。最常見的原因是時(shí)間范圍選錯(cuò)了或者 Prometheus 數(shù)據(jù)源配置錯(cuò)誤。檢查 Grafana 的 Data Source 設(shè)置點(diǎn)“Save Test”確認(rèn)連接正常。如果數(shù)據(jù)源正常但還是 No Data檢查查詢語句的指標(biāo)名稱是否和 DCGM Exporter 暴露的一致不同版本的 DCGM Exporter 指標(biāo)名稱可能有差異。問題四監(jiān)控?cái)?shù)據(jù)與實(shí)際不符。比如nvidia-smi顯示 GPU 利用率 90%但 DCGM 顯示 60%。這種差異通常是因?yàn)椴蓸訒r(shí)間窗口不同。nvidia-smi顯示的是瞬時(shí)值DCGM 采集的是采樣周期內(nèi)的平均值。另外 DCGM 的 GPU 利用率定義和nvidia-smi可能略有不同以 DCGM 為準(zhǔn)即可因?yàn)樗菍ｉT為數(shù)據(jù)中心場景設(shè)計(jì)的。5.3 故障診斷的自動(dòng)化嘗試手動(dòng)排查故障效率低且依賴經(jīng)驗(yàn)我嘗試過一些自動(dòng)化手段。最簡單的是寫一個(gè)巡檢腳本定期跑 NCCL Tests 和 GPU 健康檢查把結(jié)果寫入數(shù)據(jù)庫發(fā)現(xiàn)異常時(shí)自動(dòng)告警。這個(gè)腳本用 Python 寫就行核心邏輯是調(diào)用subprocess執(zhí)行測試命令解析輸出對(duì)比基線。更進(jìn)一步的做法是用 DCGM 的診斷模式dcgmi diag它內(nèi)置了一套完整的硬件診斷流程包括 GPU 計(jì)算測試、顯存測試、PCIe 測試、NVLink 測試等?？梢栽O(shè)置成每天凌晨自動(dòng)跑一次生成診斷報(bào)告。如果診斷不通過說明硬件可能有問題提前報(bào)修避免訓(xùn)練中斷。不過自動(dòng)化診斷也有局限。它只能發(fā)現(xiàn)已知的、有明確判斷標(biāo)準(zhǔn)的問題對(duì)于性能退化這類模糊問題還是需要人工分析監(jiān)控?cái)?shù)據(jù)。我的經(jīng)驗(yàn)是自動(dòng)化負(fù)責(zé)“發(fā)現(xiàn)異常”人工負(fù)責(zé)“定位根因”兩者配合效率最高。6. 一些踩過的坑和實(shí)用建議先說一個(gè)最容易被忽略的點(diǎn)GPU 時(shí)鐘鎖定。很多集群為了省電默認(rèn)開啟 GPU 的動(dòng)態(tài)調(diào)頻。這在推理場景沒問題但在訓(xùn)練場景會(huì)導(dǎo)致性能波動(dòng)。我建議在訓(xùn)練節(jié)點(diǎn)上通過nvidia-smi -lgc鎖定 GPU 時(shí)鐘到基頻或略高于基頻顯存時(shí)鐘也鎖定。這樣雖然功耗高一些但性能穩(wěn)定可預(yù)測。實(shí)測下來鎖定時(shí)鐘后 NCCL 帶寬測試的波動(dòng)從 ±15% 降到了 ±3%。第二個(gè)坑是NCCL 版本與驅(qū)動(dòng)的兼容性。NCCL 版本更新很快新版本通常性能更好但也可能引入新的 bug。我遇到過升級(jí) NCCL 后 all_reduce 帶寬反而下降 20% 的情況回退版本后恢復(fù)正常。所以升級(jí) NCCL 之前一定要在測試環(huán)境驗(yàn)證確認(rèn)性能不降反升再上生產(chǎn)。另外 NCCL 版本要和 CUDA 版本匹配CUDA 11.x 配 NCCL 2.10-2.14CUDA 12.x 配 NCCL 2.16 以上。第三個(gè)坑是InfiniBand 的 PFC 和 ECN 配置。在 RoCE 環(huán)境下PFCPriority Flow Control和 ECNExplicit Congestion Notification的配置直接影響網(wǎng)絡(luò)性能。配置不當(dāng)會(huì)導(dǎo)致丟包和重傳進(jìn)而導(dǎo)致 NCCL 超時(shí)。建議參考交換機(jī)和網(wǎng)卡廠商的最佳實(shí)踐文檔來配置不要用默認(rèn)值。配置完之后用ib_send_bw和ib_send_lat測試一下實(shí)際帶寬和延遲。第四個(gè)坑是監(jiān)控?cái)?shù)據(jù)的保留策略。Prometheus 默認(rèn)保留 15 天數(shù)據(jù)對(duì)于故障排查來說可能不夠。我建議至少保留 30 天重要集群保留 90 天?？梢杂?Prometheus 的 remote write 功能把數(shù)據(jù)寫到長期存儲(chǔ)比如 Thanos 或 VictoriaMetrics這樣既不影響 Prometheus 的性能又能長期保留數(shù)據(jù)。最后一個(gè)建議建立故障知識(shí)庫。每次排查完一個(gè)故障把現(xiàn)象、排查過程、根因、解決方案記錄下來。時(shí)間長了這就是團(tuán)隊(duì)最寶貴的財(cái)富。我現(xiàn)在的團(tuán)隊(duì)有一個(gè)內(nèi)部 Wiki記錄了上百個(gè)故障案例新同事遇到問題先查知識(shí)庫80% 的情況能直接找到答案。這比任何監(jiān)控工具都管用。這套“聽診器”體系不是一次建成的而是隨著集群規(guī)模增長和故障經(jīng)驗(yàn)積累逐步完善的。從最基礎(chǔ)的nvidia-smi巡檢開始到部署 DCGM Prometheus Grafana再到建立 NCCL Benchmark 基線和故障知識(shí)庫每一步都能實(shí)實(shí)在在提升集群的可用性和訓(xùn)練效率。 AI智算集群監(jiān)控與故障診斷：NCCL Benchmark與GPU指標(biāo)實(shí)戰(zhàn)
1. 智算集群為什么需要一套“聽診器”搞過大規(guī)模訓(xùn)練的人都有一個(gè)共同體會(huì)集群規(guī)模一旦上去故障就不再是“某臺(tái)機(jī)器壞了”這么簡單而是變成了一種系統(tǒng)性、間歇性、難以復(fù)現(xiàn)的疑難雜癥。你可能遇到過訓(xùn)練跑了三天突然 loss 炸了重啟之后又好了也可能遇到過某個(gè)節(jié)點(diǎn)吞吐量莫名其妙比其他節(jié)點(diǎn)低 30%但查遍日志什么錯(cuò)誤都沒有。這類問題靠傳統(tǒng)的nvidia-smi和dmesg根本定位不了你需要一套專門為 AI 集群設(shè)計(jì)的“聽診器”——這就是Benchmark、監(jiān)控與故障診斷體系存在的意義。這套體系解決的核心問題有三個(gè)第一性能基線問題你得知道集群在健康狀態(tài)下應(yīng)該跑出什么數(shù)字才能判斷現(xiàn)在是不是有問題第二實(shí)時(shí)可觀測性問題訓(xùn)練過程中的 GPU 利用率、顯存帶寬、NVLink 流量、網(wǎng)絡(luò) RDMA 吞吐這些指標(biāo)必須持續(xù)采集而不是出事了才去看第三故障歸因問題當(dāng)性能下降發(fā)生時(shí)能快速定位到是計(jì)算、通信、存儲(chǔ)還是調(diào)度層面的瓶頸。適合讀這篇內(nèi)容的人包括正在搭建或運(yùn)維 GPU 集群的工程師、負(fù)責(zé)大模型訓(xùn)練基礎(chǔ)設(shè)施的 SRE、需要做集群驗(yàn)收和性能調(diào)優(yōu)的技術(shù)負(fù)責(zé)人以及想了解 AI 集群運(yùn)維體系長什么樣的開發(fā)者。我會(huì)從整體設(shè)計(jì)思路講到具體實(shí)操包括 NCCL 測試怎么做、Prometheus 怎么采集 GPU 指標(biāo)、常見故障怎么排查盡量把踩過的坑都攤開講。2. 整體設(shè)計(jì)思路從“事后救火”到“事前體檢”2.1 為什么傳統(tǒng)監(jiān)控方案在 AI 集群上不夠用傳統(tǒng) IDC 監(jiān)控關(guān)注的是 CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)帶寬這些通用指標(biāo)用 Zabbix 或者基礎(chǔ)的 Prometheus 就能覆蓋。但 AI 集群的負(fù)載特征完全不同GPU 是核心計(jì)算資源它的利用率、顯存占用、溫度、功耗、ECC 錯(cuò)誤、NVLink 帶寬這些指標(biāo)傳統(tǒng)工具根本采集不到。更關(guān)鍵的是AI 訓(xùn)練是集合通信密集型的負(fù)載一次 AllReduce 操作涉及成百上千張卡同步任何一張卡或任何一條鏈路出現(xiàn)微小的性能抖動(dòng)都會(huì)拖慢整個(gè)通信組進(jìn)而拖慢整個(gè)訓(xùn)練任務(wù)。我見過一個(gè)真實(shí)案例一個(gè) 64 卡集群訓(xùn)練吞吐比預(yù)期低了 15%查了一周沒找到原因最后用 NCCL 的帶寬測試逐對(duì)檢測發(fā)現(xiàn)其中兩臺(tái)機(jī)器之間的 InfiniBand 鏈路協(xié)商速率從 200Gbps 降到了 100Gbps原因是其中一端的線纜接頭有輕微松動(dòng)。這種問題傳統(tǒng)監(jiān)控完全看不到只有專門的集合通信 Benchmark 才能暴露出來。所以 AI 集群的“聽診器”體系必須包含三個(gè)層次基準(zhǔn)測試層Benchmark回答“應(yīng)該多快”、持續(xù)監(jiān)控層Monitoring回答“現(xiàn)在多快”、故障診斷層Diagnosis回答“為什么變慢”。三者缺一不可而且必須形成閉環(huán)——Benchmark 提供基線監(jiān)控對(duì)比基線發(fā)現(xiàn)異常診斷定位根因。2.2 三層體系的具體分工與工具選型基準(zhǔn)測試層的核心工具是 NCCL Tests、GPU Burn、STREAM Benchmark、FIO存儲(chǔ)、iperf3網(wǎng)絡(luò)。其中 NCCL Tests 是重中之重因?yàn)榧贤ㄐ判阅苤苯記Q定分布式訓(xùn)練效率。NCCL Tests 包含 all_reduce、all_gather、broadcast、reduce_scatter 等多個(gè)測試項(xiàng)可以測不同消息大小下的帶寬和延遲。持續(xù)監(jiān)控層的標(biāo)準(zhǔn)組合是 Prometheus Grafana DCGM Exporter。DCGM 是 NVIDIA 的數(shù)據(jù)中心 GPU 管理器它暴露的指標(biāo)非常全面包括 GPU 利用率、顯存使用、SM 活躍度、Tensor Core 活躍度、NVLink 帶寬、PCIe 帶寬、ECC 錯(cuò)誤計(jì)數(shù)、XID 錯(cuò)誤等。Prometheus 負(fù)責(zé)拉取和存儲(chǔ)Grafana 負(fù)責(zé)可視化。對(duì)于網(wǎng)絡(luò)層可以加上 InfiniBand 的 performance counters 采集對(duì)于節(jié)點(diǎn)層node_exporter 負(fù)責(zé) CPU、內(nèi)存、磁盤指標(biāo)。故障診斷層則更多依賴工具組合和排查經(jīng)驗(yàn)。常用手段包括NCCL 的 debug 日志NCCL_DEBUGINFO、nvidia-smi -q的詳細(xì)輸出、DCGM 的診斷模式dcgmi diag、XID 錯(cuò)誤碼查詢、以及針對(duì)性的微基準(zhǔn)測試。這一層沒有銀彈更多是靠體系化的排查流程和積累的經(jīng)驗(yàn)。注意工具選型不要貪多求全。我見過有團(tuán)隊(duì)同時(shí)跑了三套監(jiān)控系統(tǒng)結(jié)果數(shù)據(jù)互相矛盾排查時(shí)反而更混亂。建議以 Prometheus DCGM Exporter 為核心其他工具按需補(bǔ)充。2.3 基線建立一切診斷的前提沒有基線的監(jiān)控就是一堆沒有意義的數(shù)字。建立基線的方法是在集群健康且空閑的狀態(tài)下跑一輪完整的 Benchmark 套件記錄下每個(gè)測試項(xiàng)的性能數(shù)據(jù)。這個(gè)基線要包括單卡 FP16/FP32 算力用 GPU Burn 或?qū)ｉT的算力測試、單機(jī)內(nèi) NVLink 帶寬、跨機(jī) InfiniBand 帶寬用 NCCL Tests 的 all_reduce、存儲(chǔ)讀寫帶寬用 FIO、以及典型訓(xùn)練任務(wù)的吞吐tokens/sec 或 samples/sec。基線數(shù)據(jù)要存檔并且標(biāo)注測試時(shí)的環(huán)境信息驅(qū)動(dòng)版本、CUDA 版本、NCCL 版本、交換機(jī)固件版本、拓?fù)浣Y(jié)構(gòu)。因?yàn)槿魏我豁?xiàng)變更都可能導(dǎo)致基線漂移比如 NCCL 版本升級(jí)后 all_reduce 帶寬可能提升也可能下降沒有版本標(biāo)注的基線數(shù)據(jù)是沒有參考價(jià)值的。3. 核心細(xì)節(jié)解析NCCL Benchmark 與 GPU 監(jiān)控實(shí)操3.1 NCCL Tests 的正確打開方式NCCL Tests 的編譯很簡單從官方倉庫 clone 下來make就行但關(guān)鍵在于怎么跑才有意義。很多人直接跑一個(gè)默認(rèn)參數(shù)的 all_reduce 就完事了這樣得到的數(shù)據(jù)參考價(jià)值有限。正確的做法是覆蓋多個(gè)維度消息大小從 8 bytes 到 8 GB覆蓋小消息延遲敏感和大消息帶寬敏感兩個(gè)區(qū)間GPU 數(shù)量至少測 2 卡、8 卡單機(jī)、16 卡、32 卡、64 卡跨機(jī)觀察擴(kuò)展效率拓?fù)涓兄肗CCL_TOPO_DUMP_FILE導(dǎo)出拓?fù)浯_認(rèn) NCCL 是否識(shí)別到了正確的 NVLink 和 InfiniBand 路徑一個(gè)典型的 all_reduce 測試命令如下# 8 卡單機(jī) all_reduce 測試 ./build/all_reduce_perf -b 8 -e 8G -f 2 -g 8 # 跨機(jī)測試需要 mpirun 或 torchrun 啟動(dòng) mpirun -np 16 -H node1:8,node2:8 \ -x NCCL_DEBUGINFO \ -x NCCL_IB_HCAmlx5_0,mlx5_1 \ ./build/all_reduce_perf -b 8 -e 8G -f 2 -g 1參數(shù)解釋-b是起始消息大小-e是結(jié)束大小-f是倍增因子2 表示每次翻倍-g是每進(jìn)程使用的 GPU 數(shù)?？鐧C(jī)測試時(shí)-g 1表示每個(gè)進(jìn)程用一張卡總共 16 個(gè)進(jìn)程對(duì)應(yīng) 16 張卡。跑完之后重點(diǎn)看兩個(gè)數(shù)字algbw算法帶寬和busbw總線帶寬。busbw 更能反映實(shí)際鏈路利用率計(jì)算公式是busbw algbw * 2 * (n-1) / n其中 n 是參與通信的 GPU 數(shù)。對(duì)于 8 卡 NVLink 全互聯(lián)的機(jī)器busbw 應(yīng)該接近 NVLink 的理論帶寬對(duì)于跨機(jī) InfiniBandbusbw 應(yīng)該接近 IB 鏈路帶寬的 80% 以上。實(shí)操心得跑 NCCL Tests 之前一定要確認(rèn) GPU 處于空閑狀態(tài)并且鎖定頻率。用nvidia-smi -lgc鎖定 GPU 時(shí)鐘用nvidia-smi -lmc鎖定顯存時(shí)鐘否則 GPU 會(huì)因?yàn)楣墓芾韯?dòng)態(tài)調(diào)頻導(dǎo)致測試結(jié)果波動(dòng)很大。我一般會(huì)把時(shí)鐘鎖在基頻這樣測出來的數(shù)據(jù)可比性最強(qiáng)。3.2 DCGM Exporter 部署與關(guān)鍵指標(biāo)解讀DCGM Exporter 的部署方式取決于你的環(huán)境。如果是 Kubernetes 集群用 Helm chart 部署最方便如果是裸機(jī)可以用 Docker 跑docker run -d --gpus all --rm \ -p 9400:9400 \ --name dcgm-exporter \ nvcr.io/nvidia/k8s/dcgm-exporter:3.3.0-3.2.0-ubuntu22.04跑起來之后訪問http://localhost:9400/metrics就能看到所有指標(biāo)。指標(biāo)很多但真正需要重點(diǎn)關(guān)注的其實(shí)就那么幾個(gè)指標(biāo)名稱含義異常判斷DCGM_FI_DEV_GPU_UTILGPU 計(jì)算利用率持續(xù)低于 80% 可能有瓶頸DCGM_FI_DEV_MEM_COPY_UTIL顯存帶寬利用率接近 100% 說明顯存瓶頸DCGM_FI_DEV_NVLINK_BANDWIDTH_TOTALNVLink 總帶寬突然下降可能是鏈路問題DCGM_FI_DEV_PCIE_REPLAY_COUNTERPCIe 重傳計(jì)數(shù)持續(xù)增長說明 PCIe 有問題DCGM_FI_DEV_XID_ERRORSXID 錯(cuò)誤碼非零值需要立即排查DCGM_FI_DEV_ECC_DBE_VOL_TOTAL顯存雙比特錯(cuò)誤非零值說明顯存硬件故障DCGM_FI_DEV_POWER_USAGE功耗異常低可能是降頻DCGM_FI_DEV_GPU_TEMP溫度超過 85 度需要關(guān)注散熱這些指標(biāo)接入 Prometheus 之后在 Grafana 上配置看板。我建議至少做三個(gè)看板集群總覽所有 GPU 的利用率熱力圖、單節(jié)點(diǎn)詳情單機(jī) 8 卡的各項(xiàng)指標(biāo)曲線、異常告警XID 錯(cuò)誤、ECC 錯(cuò)誤、溫度超限的實(shí)時(shí)列表。3.3 Prometheus 告警規(guī)則配置要點(diǎn)監(jiān)控沒有告警等于沒有監(jiān)控。Prometheus 的告警規(guī)則用 YAML 配置以下是我在實(shí)際環(huán)境中驗(yàn)證過有效的幾條核心規(guī)則groups: - name: gpu_alerts rules: - alert: GPUXIDError expr: DCGM_FI_DEV_XID_ERRORS 0 for: 1m labels: severity: critical annotations: summary: GPU XID error detected on {{ $labels.instance }} - alert: GPUTemperatureHigh expr: DCGM_FI_DEV_GPU_TEMP 83 for: 5m labels: severity: warning annotations: summary: GPU temperature high on {{ $labels.instance }} - alert: GPUMemoryECCDoubleBit expr: DCGM_FI_DEV_ECC_DBE_VOL_TOTAL 0 for: 1m labels: severity: critical annotations: summary: GPU double-bit ECC error on {{ $labels.instance }} - alert: NCCLBandwidthDrop expr: rate(DCGM_FI_DEV_NVLINK_BANDWIDTH_TOTAL[5m]) 100e9 for: 10m labels: severity: warning annotations: summary: NVLink bandwidth dropped on {{ $labels.instance }}注意告警閾值不要照搬網(wǎng)上的配置。不同型號(hào)的 GPU 溫度閾值不同A100 和 H100 的功耗曲線也不一樣。建議先跑一周的監(jiān)控觀察正常波動(dòng)范圍再設(shè)定閾值。告警太敏感會(huì)導(dǎo)致“狼來了”效應(yīng)運(yùn)維人員逐漸忽略告警這比沒有告警更危險(xiǎn)。4. 故障診斷實(shí)戰(zhàn)從現(xiàn)象到根因的排查路徑4.1 訓(xùn)練吞吐下降的排查決策樹訓(xùn)練吞吐下降是最常見的故障現(xiàn)象但原因可能五花八門。我總結(jié)了一套排查決策樹按順序執(zhí)行可以覆蓋 90% 以上的場景第一步確認(rèn)是全局問題還是局部問題。對(duì)比所有節(jié)點(diǎn)的 GPU 利用率如果所有節(jié)點(diǎn)都低說明是全局性問題可能是數(shù)據(jù)加載瓶頸、通信瓶頸、或者調(diào)度問題如果只有部分節(jié)點(diǎn)低說明是局部性問題可能是某張卡降頻、某條鏈路故障。第二步檢查 GPU 狀態(tài)。用nvidia-smi -q查看是否有降頻clocks throttle reason、是否有 ECC 錯(cuò)誤、是否有 XID 錯(cuò)誤。特別關(guān)注Clocks Throttle Reasons字段如果顯示HW Slowdown或SW Thermal Slowdown說明是散熱或功耗問題。第三步檢查通信。在訓(xùn)練腳本里設(shè)置NCCL_DEBUGINFO和NCCL_DEBUG_SUBSYSALL觀察 NCCL 初始化時(shí)選擇的通信路徑。如果發(fā)現(xiàn) NCCL 沒有走 InfiniBand 而是走了 TCP socket那性能肯定差。常見原因是NCCL_IB_HCA沒設(shè)置對(duì)或者 IB 驅(qū)動(dòng)有問題。第四步檢查存儲(chǔ)。如果數(shù)據(jù)加載是瓶頸GPU 利用率會(huì)呈現(xiàn)周期性波動(dòng)等待數(shù)據(jù)時(shí)降到 0數(shù)據(jù)來了又升上去。用iostat和fio檢查存儲(chǔ)帶寬是否達(dá)到預(yù)期。第五步檢查 CPU 和內(nèi)存。數(shù)據(jù)預(yù)處理如果放在 CPU 上做CPU 可能成為瓶頸。用htop看 CPU 利用率如果某個(gè)核跑滿而 GPU 在等那就是數(shù)據(jù)加載的問題。4.2 XID 錯(cuò)誤碼速查與處理XID 錯(cuò)誤是 NVIDIA GPU 的硬件級(jí)錯(cuò)誤碼每個(gè)碼對(duì)應(yīng)不同的故障類型。以下是我實(shí)際遇到過的高頻 XID 錯(cuò)誤XID 碼含義處理方式13Graphics engine exception通常是應(yīng)用程序 bug檢查 CUDA 代碼31GPU memory page fault顯存訪問越界檢查 kernel 代碼43GPU stopped processingGPU 掛起需要重置 GPU48Double-bit ECC error顯存硬件故障需要更換 GPU63ECC page retirement顯存頁退役記錄并觀察74NVLink errorNVLink 鏈路故障檢查物理連接79GPU has fallen off the busGPU 掉卡通常是硬件或供電問題92High single-bit ECC error rate單比特錯(cuò)誤率過高可能發(fā)展為雙比特94Contained ECC error可糾正的 ECC 錯(cuò)誤記錄觀察95Uncontained ECC error不可糾正的 ECC 錯(cuò)誤需要重置 GPU遇到 XID 錯(cuò)誤第一步是記錄錯(cuò)誤碼和發(fā)生時(shí)間第二步是查 NVIDIA 官方的 XID 錯(cuò)誤碼文檔確認(rèn)含義第三步是根據(jù)嚴(yán)重程度決定是重置 GPU、重啟節(jié)點(diǎn)還是報(bào)修硬件。XID 48 和 95 基本意味著 GPU 需要更換XID 74 需要檢查 NVLink 線纜和連接器。4.3 NCCL 通信故障的典型場景NCCL 相關(guān)的故障有幾個(gè)經(jīng)典場景我逐個(gè)說一下排查方法。場景一NCCL 初始化超時(shí)。訓(xùn)練啟動(dòng)時(shí)卡在 NCCL 初始化階段日志顯示NCCL INFO Bootstrap之后就沒有下文了。這通常是網(wǎng)絡(luò)連通性問題檢查所有節(jié)點(diǎn)之間的 SSH 免密是否配置正確、防火墻是否放行了 NCCL 使用的端口范圍、IB 網(wǎng)絡(luò)是否正常?？梢杂胕bstat檢查 IB 卡狀態(tài)用ibping測試節(jié)點(diǎn)間連通性。場景二NCCL 走了錯(cuò)誤的通信路徑。日志顯示NCCL INFO NET/Socket而不是NCCL INFO NET/IB說明 NCCL 沒有使用 InfiniBand。檢查NCCL_IB_HCA環(huán)境變量是否指向了正確的 HCA 設(shè)備檢查NCCL_IB_DISABLE是否被設(shè)為了 1檢查 IB 驅(qū)動(dòng)是否加載lsmod | grep ib。場景三AllReduce 帶寬遠(yuǎn)低于預(yù)期。用 NCCL Tests 測出來的 busbw 只有理論值的 30%?？赡茉虬℅PU 降頻、NVLink 鏈路降速、IB 交換機(jī)擁塞、NCCL 算法選擇不當(dāng)。可以嘗試設(shè)置NCCL_ALGORing或NCCL_ALGOTree強(qiáng)制使用不同算法看是否有改善。也可以設(shè)置NCCL_PROTOLL或NCCL_PROTOSimple切換協(xié)議。場景四訓(xùn)練過程中隨機(jī)出現(xiàn) NCCL timeout。這種間歇性故障最難排查。常見原因是某條鏈路有丟包或誤碼導(dǎo)致偶發(fā)的通信超時(shí)。檢查 IB 的 error countersperfquery命令如果SymbolErrorCounter或LinkErrorRecoveryCounter在增長說明鏈路質(zhì)量有問題。也可能是 GPU 偶發(fā)降頻導(dǎo)致通信超時(shí)檢查是否有 XID 錯(cuò)誤或溫度告警。實(shí)操心得NCCL 的日志級(jí)別用NCCL_DEBUGWARN就夠了INFO級(jí)別日志量太大在千卡集群上會(huì)把日志系統(tǒng)沖垮。只有在排查特定問題時(shí)才臨時(shí)開到INFO并且只對(duì)可疑節(jié)點(diǎn)開。另外NCCL_DEBUG_FILE可以把日志寫到文件而不是 stderr方便后續(xù)分析。5. 監(jiān)控體系的持續(xù)運(yùn)營與常見問題5.1 監(jiān)控?cái)?shù)據(jù)采集頻率與存儲(chǔ)規(guī)劃Prometheus 的采集頻率直接影響監(jiān)控精度和存儲(chǔ)成本。對(duì)于 GPU 指標(biāo)我建議采集間隔設(shè)為 15 秒這個(gè)精度足以捕捉到大多數(shù)性能波動(dòng)同時(shí)不會(huì)產(chǎn)生太大的存儲(chǔ)壓力。按 1000 張 GPU 計(jì)算每張卡約 50 個(gè)指標(biāo)15 秒采集一次每天產(chǎn)生的數(shù)據(jù)量大約是 1000 × 50 × 5760 2.88 億個(gè)數(shù)據(jù)點(diǎn)。Prometheus 的壓縮率大約是每樣本 1-2 字節(jié)所以每天約 300-600 MB保留 30 天需要 10-20 GB 存儲(chǔ)完全可以接受。如果需要更高精度的數(shù)據(jù)比如排查瞬時(shí)的性能抖動(dòng)可以臨時(shí)把采集間隔調(diào)到 1 秒但只針對(duì)可疑節(jié)點(diǎn)排查完就調(diào)回去。長期 1 秒采集會(huì)導(dǎo)致存儲(chǔ)爆炸。Grafana 看板的配置也有講究。集群總覽看板不要放太多面板否則加載慢且信息過載。我一般放四個(gè)核心面板GPU 利用率熱力圖、GPU 溫度分布、XID 錯(cuò)誤統(tǒng)計(jì)、NCCL 帶寬趨勢。詳細(xì)指標(biāo)放到下鉆看板里需要時(shí)再點(diǎn)進(jìn)去看。5.2 常見監(jiān)控問題與排查問題一DCGM Exporter 采集不到數(shù)據(jù)。首先確認(rèn)容器是否有--gpus all權(quán)限其次確認(rèn) NVIDIA 驅(qū)動(dòng)版本和 DCGM 版本是否兼容。DCGM 3.x 需要驅(qū)動(dòng) 450 以上DCGM 3.3 需要驅(qū)動(dòng) 525 以上。如果驅(qū)動(dòng)版本太低升級(jí)驅(qū)動(dòng)或者降級(jí) DCGM。問題二Prometheus 抓取目標(biāo)顯示 down。檢查 DCGM Exporter 的端口是否監(jiān)聽netstat -tlnp | grep 9400檢查 Prometheus 配置的 target 地址是否正確檢查防火墻是否放行了 9400 端口。如果是 Kubernetes 環(huán)境檢查 Service 和 Pod 的標(biāo)簽選擇器是否匹配。問題三Grafana 看板顯示 No Data。最常見的原因是時(shí)間范圍選錯(cuò)了或者 Prometheus 數(shù)據(jù)源配置錯(cuò)誤。檢查 Grafana 的 Data Source 設(shè)置點(diǎn)“Save Test”確認(rèn)連接正常。如果數(shù)據(jù)源正常但還是 No Data檢查查詢語句的指標(biāo)名稱是否和 DCGM Exporter 暴露的一致不同版本的 DCGM Exporter 指標(biāo)名稱可能有差異。問題四監(jiān)控?cái)?shù)據(jù)與實(shí)際不符。比如nvidia-smi顯示 GPU 利用率 90%但 DCGM 顯示 60%。這種差異通常是因?yàn)椴蓸訒r(shí)間窗口不同。nvidia-smi顯示的是瞬時(shí)值DCGM 采集的是采樣周期內(nèi)的平均值。另外 DCGM 的 GPU 利用率定義和nvidia-smi可能略有不同以 DCGM 為準(zhǔn)即可因?yàn)樗菍ｉT為數(shù)據(jù)中心場景設(shè)計(jì)的。5.3 故障診斷的自動(dòng)化嘗試手動(dòng)排查故障效率低且依賴經(jīng)驗(yàn)我嘗試過一些自動(dòng)化手段。最簡單的是寫一個(gè)巡檢腳本定期跑 NCCL Tests 和 GPU 健康檢查把結(jié)果寫入數(shù)據(jù)庫發(fā)現(xiàn)異常時(shí)自動(dòng)告警。這個(gè)腳本用 Python 寫就行核心邏輯是調(diào)用subprocess執(zhí)行測試命令解析輸出對(duì)比基線。更進(jìn)一步的做法是用 DCGM 的診斷模式dcgmi diag它內(nèi)置了一套完整的硬件診斷流程包括 GPU 計(jì)算測試、顯存測試、PCIe 測試、NVLink 測試等?？梢栽O(shè)置成每天凌晨自動(dòng)跑一次生成診斷報(bào)告。如果診斷不通過說明硬件可能有問題提前報(bào)修避免訓(xùn)練中斷。不過自動(dòng)化診斷也有局限。它只能發(fā)現(xiàn)已知的、有明確判斷標(biāo)準(zhǔn)的問題對(duì)于性能退化這類模糊問題還是需要人工分析監(jiān)控?cái)?shù)據(jù)。我的經(jīng)驗(yàn)是自動(dòng)化負(fù)責(zé)“發(fā)現(xiàn)異常”人工負(fù)責(zé)“定位根因”兩者配合效率最高。6. 一些踩過的坑和實(shí)用建議先說一個(gè)最容易被忽略的點(diǎn)GPU 時(shí)鐘鎖定。很多集群為了省電默認(rèn)開啟 GPU 的動(dòng)態(tài)調(diào)頻。這在推理場景沒問題但在訓(xùn)練場景會(huì)導(dǎo)致性能波動(dòng)。我建議在訓(xùn)練節(jié)點(diǎn)上通過nvidia-smi -lgc鎖定 GPU 時(shí)鐘到基頻或略高于基頻顯存時(shí)鐘也鎖定。這樣雖然功耗高一些但性能穩(wěn)定可預(yù)測。實(shí)測下來鎖定時(shí)鐘后 NCCL 帶寬測試的波動(dòng)從 ±15% 降到了 ±3%。第二個(gè)坑是NCCL 版本與驅(qū)動(dòng)的兼容性。NCCL 版本更新很快新版本通常性能更好但也可能引入新的 bug。我遇到過升級(jí) NCCL 后 all_reduce 帶寬反而下降 20% 的情況回退版本后恢復(fù)正常。所以升級(jí) NCCL 之前一定要在測試環(huán)境驗(yàn)證確認(rèn)性能不降反升再上生產(chǎn)。另外 NCCL 版本要和 CUDA 版本匹配CUDA 11.x 配 NCCL 2.10-2.14CUDA 12.x 配 NCCL 2.16 以上。第三個(gè)坑是InfiniBand 的 PFC 和 ECN 配置。在 RoCE 環(huán)境下PFCPriority Flow Control和 ECNExplicit Congestion Notification的配置直接影響網(wǎng)絡(luò)性能。配置不當(dāng)會(huì)導(dǎo)致丟包和重傳進(jìn)而導(dǎo)致 NCCL 超時(shí)。建議參考交換機(jī)和網(wǎng)卡廠商的最佳實(shí)踐文檔來配置不要用默認(rèn)值。配置完之后用ib_send_bw和ib_send_lat測試一下實(shí)際帶寬和延遲。第四個(gè)坑是監(jiān)控?cái)?shù)據(jù)的保留策略。Prometheus 默認(rèn)保留 15 天數(shù)據(jù)對(duì)于故障排查來說可能不夠。我建議至少保留 30 天重要集群保留 90 天?？梢杂?Prometheus 的 remote write 功能把數(shù)據(jù)寫到長期存儲(chǔ)比如 Thanos 或 VictoriaMetrics這樣既不影響 Prometheus 的性能又能長期保留數(shù)據(jù)。最后一個(gè)建議建立故障知識(shí)庫。每次排查完一個(gè)故障把現(xiàn)象、排查過程、根因、解決方案記錄下來。時(shí)間長了這就是團(tuán)隊(duì)最寶貴的財(cái)富。我現(xiàn)在的團(tuán)隊(duì)有一個(gè)內(nèi)部 Wiki記錄了上百個(gè)故障案例新同事遇到問題先查知識(shí)庫80% 的情況能直接找到答案。這比任何監(jiān)控工具都管用。這套“聽診器”體系不是一次建成的而是隨著集群規(guī)模增長和故障經(jīng)驗(yàn)積累逐步完善的。從最基礎(chǔ)的nvidia-smi巡檢開始到部署 DCGM Prometheus Grafana再到建立 NCCL Benchmark 基線和故障知識(shí)庫每一步都能實(shí)實(shí)在在提升集群的可用性和訓(xùn)練效率。