智算集群监控与故障诊断：从性能基线到根因定位实战

1. 从一次训练任务莫名卡死说起

如果你在智算集群上跑过大模型训练，大概率遇到过这种场景：任务启动正常，loss 曲线前几百步也正常，突然某个时刻吞吐掉了一半，再过几分钟直接 hang 住，日志里什么都没有，nvidia-smi看 GPU 利用率在 0% 和 100% 之间反复横跳。你去问网络组，网络组说交换机端口没丢包；你去问存储组，存储组说 IO 延迟正常；你去看调度器，调度器说资源分配没问题。最后所有人围在屏幕前，谁也不知道问题出在哪。

这就是智算集群运维最真实的痛点：故障不是"坏了"，而是"变慢了"或者"时好时坏"。传统监控体系里，CPU、内存、磁盘、网络这些指标都是"资源视角"，但 AI 训练任务真正关心的是"通信效率"和"计算效率"。一块 GPU 的 SM 利用率是 95% 还是 60%，从资源监控上看都是"在用"，但对训练任务来说，后者意味着你花了两倍的钱跑了同样的步数。

这一讲我想聊的就是怎么给智算集群装上一副"听诊器"——用 Benchmark 建立性能基线，用监控体系捕捉异常信号，用故障诊断方法把"玄学卡顿"变成可定位、可复现、可修复的工程问题。内容会覆盖 NCCL 通信测试、GPU 指标采集、Prometheus + Grafana 看板搭建、典型故障的排查链路，以及我自己踩过的一些坑。不管你是刚接手集群的运维，还是天天被训练任务卡死折磨的算法工程师，这套方法都能直接拿去用。

2. 先搞清楚智算集群的"体检指标"有哪些

在动手搭监控之前，得先想明白一件事：你到底要监控什么。很多人一上来就装 Prometheus、装 Grafana、装 DCGM Exporter，看板拉了一堆，结果真出问题的时候还是不知道看哪个指标。原因是没有建立"指标—故障"的映射关系。

2.1 从训练任务的视角倒推关键指标

一个分布式训练任务的性能，本质上取决于三个环节：单卡计算效率、卡间通信效率、数据供给效率。任何一个环节掉链子，整体吞吐都会下降。所以监控指标也应该围绕这三条链路来组织。

单卡计算效率看什么？最直接的是 SM 利用率（sm__throughput.avg.pct_of_peak_sustained_elapsed）和 Tensor Core 利用率。但要注意，SM 利用率高不代表效率高——如果 GPU 一直在等数据，SM 利用率也会显示很高（因为 kernel 在空转）。真正能反映计算效率的是MFU（Model FLOPs Utilization），也就是实际算力除以理论峰值算力。一个健康的训练任务，MFU 应该在 40% 到 60% 之间（取决于模型结构和并行策略），如果掉到 20% 以下，基本可以确定有问题。

卡间通信效率看什么？核心指标是NCCL 通信耗时占比。在 PyTorch 里可以通过torch.profiler拿到 all-reduce、all-gather 这些集合通信操作的时间占比。如果通信占比超过 30%，说明通信成了瓶颈。另外还要看NVLink 和 RDMA 的带宽利用率，前者反映卡间互联，后者反映节点间互联。

数据供给效率看什么？看DataLoader 的等待时间和存储 IO 吞吐。如果 GPU 经常处于"等数据"状态，那再强的算力也白搭。这个指标在 PyTorch 里可以通过torch.utils.data.DataLoader的prefetch_factor和实际 batch 加载时间来估算。

2.2 硬件层指标：GPU、NVLink、RDMA、PCIe

从硬件层面看，一块 GPU 需要关注的指标可以分成几类：

这张表里的"正常范围"不是绝对的，不同型号的卡、不同的模型结构会有差异。关键是建立自己集群的基线，后面讲 Benchmark 的时候会详细说。

2.3 为什么"资源监控"不够用

传统的 Zabbix、Nagios 这类监控工具，采集的是 CPU、内存、磁盘、网络这些通用指标。它们能告诉你"机器活着"，但告诉不了你"训练任务跑得好不好"。举个例子：一台机器的 CPU 利用率 30%、内存利用率 40%、网络带宽利用率 20%，从资源监控看一切正常，但实际上这块 GPU 可能因为 NVLink 降速导致 all-reduce 慢了 3 倍。

所以智算集群的监控体系必须是分层的：底层是硬件资源监控（DCGM、Node Exporter），中间层是通信性能监控（NCCL、RDMA），上层是任务级监控（MFU、通信占比、吞吐）。三层缺一不可，而且要做关联分析——当任务级指标异常时，能快速下钻到硬件层找到根因。

3. Benchmark：给集群建立一条"性能基线"

监控的前提是知道"正常"长什么样。没有基线的监控就是耍流氓——你看到 GPU 利用率 60%，怎么判断这是正常还是异常？所以第一步是跑 Benchmark，把集群的性能基线摸清楚。

3.1 NCCL Tests：通信性能的"标尺"

NCCL Tests 是 NVIDIA 官方提供的集合通信性能测试工具，能测 all-reduce、all-gather、broadcast、reduce-scatter 等操作的带宽和延迟。它的核心价值在于：给你一个可对比的基准。

安装很简单，从 GitHub 拉下来编译就行：

git clone https://github.com/NVIDIA/nccl-tests.git cd nccl-tests make MPI=1 MPI_HOME=/usr/lib/x86_64-linux-gnu/openmpi

编译完之后，最常用的测试命令是 all-reduce：

# 单节点 8 卡测试 ./build/all_reduce_perf -b 8 -e 8G -f 2 -g 8 # 多节点测试（假设两个节点，每节点 8 卡） mpirun -np 16 -H node1:8,node2:8 \ -x NCCL_DEBUG=INFO \ ./build/all_reduce_perf -b 8 -e 8G -f 2 -g 1

参数含义：-b是起始数据量（8 字节），-e是结束数据量（8GB），-f是步进倍数（每次翻倍），-g是每进程用的 GPU 数。

跑完之后你会看到一张表，包含不同数据量下的algbw（算法带宽）和busbw（总线带宽）。这里有个坑：很多人只看 algbw，但真正有意义的是 busbw。因为 all-reduce 的算法带宽没有考虑通信模式带来的额外开销，busbw 才是实际的有效带宽。

以 8 卡 A100 NVLink 为例，正常情况下的 busbw 应该达到 200GB/s 以上（NVLink 3.0 单向 300GB/s，双向 600GB/s，all-reduce 理论峰值约 300GB/s）。如果你测出来只有 100GB/s，那说明 NVLink 拓扑或者通信配置有问题。

提示：跑 NCCL Tests 之前一定要确认NCCL_DEBUG=INFO打开，这样能看到 NCCL 实际选择的通信路径（NVLink、PCIe、RDMA）。如果发现本该走 NVLink 的走了 PCIe，那就是拓扑识别有问题。

3.2 单卡算力测试：别让"坏卡"混进来

集群里最怕的就是"坏卡"——不是完全不能用，而是性能只有正常卡的 70%。这种卡在资源监控上看不出来，但会拖慢整个训练任务。所以每批新机器上线前，必须跑单卡算力测试。

常用的工具是gpu-burn和CUDA Samples 里的 matrixMul。gpu-burn 主要测稳定性和浮点性能，跑 10 分钟看有没有报错、温度是否正常。matrixMul 测的是实际算力，可以对比理论峰值。

# gpu-burn 测试，跑 600 秒 ./gpu_burn 600 # 查看结果，正常应该显示 GFLOPS 数值 # 如果某张卡明显低于其他卡，标记为可疑

更精细的测试可以用DCGM 的 diagnostic 模式：

dcgmi diag -r 3

-r 3是最高级别的诊断，会跑完整的硬件自检，包括显存、计算单元、NVLink、PCIe。这个测试大概需要 15-20 分钟，适合新机器验收时跑。

3.3 存储 IO 测试：别让数据加载拖后腿

AI 训练对存储的要求很特殊：大文件顺序读 + 小文件随机读。前者是训练数据，后者是 checkpoint 和日志。很多人只测了顺序读带宽，结果训练时被小文件 IO 拖死。

顺序读用fio：

fio --name=seq_read --ioengine=libaio --direct=1 \ --bs=1M --size=10G --numjobs=8 --rw=read \ --group_reporting --filename=/mnt/data/testfile

随机读用fio的 randread 模式，bs=4k，iodepth=32。重点看IOPS和延迟，而不是只看带宽。

对于分布式文件系统（比如 Lustre、GPFS），还要测多客户端并发的场景。单客户端跑出 10GB/s 不代表 100 个客户端能跑出 1000GB/s，元数据服务往往是瓶颈。

3.4 基线数据的保存与对比

跑完 Benchmark 之后，一定要把结果结构化保存。我自己的做法是每次测试生成一个 JSON 文件，包含时间戳、机器型号、GPU 型号、驱动版本、测试项、测试结果。然后用一个简单的脚本做对比，新机器的结果和基线偏差超过 10% 就告警。

import json from datetime import datetime baseline = { "gpu_model": "A100-80G", "nccl_busbw_8gpu": 280, # GB/s "single_card_tflops": 312, # TFLOPS FP16 "storage_seq_read": 6500, # MB/s } def check_baseline(new_result): for key, expected in baseline.items(): if key in new_result: actual = new_result[key] deviation = abs(actual - expected) / expected if deviation > 0.1: print(f"警告: {key} 偏差 {deviation*100:.1f}%")

这个脚本很粗糙，但足够用了。关键是要养成"先测基线，再上生产"的习惯。

4. 监控体系搭建：从 DCGM 到 Grafana 看板

Benchmark 解决的是"静态基线"问题，监控解决的是"动态异常"问题。智算集群的监控体系，我推荐DCGM Exporter + Prometheus + Grafana这套组合，成熟、开源、社区活跃。

4.1 DCGM Exporter：GPU 指标的采集入口

DCGM（Data Center GPU Manager）是 NVIDIA 官方的 GPU 管理工具，DCGM Exporter 则把它采集的指标暴露成 Prometheus 格式。安装方式有两种：二进制和容器。生产环境我推荐容器方式，升级方便。

docker run -d --gpus all --rm \ --name dcgm-exporter \ -p 9400:9400 \ nvcr.io/nvidia/k8s/dcgm-exporter:3.3.0-3.2.0-ubuntu22.04

跑起来之后，访问http://localhost:9400/metrics就能看到所有指标。DCGM 默认采集的指标有 100 多个，但常用的就那么十几个：

• DCGM_FI_DEV_GPU_UTIL：GPU 利用率
• DCGM_FI_DEV_MEM_COPY_UTIL：显存带宽利用率
• DCGM_FI_DEV_SM_CLOCK：SM 时钟频率
• DCGM_FI_DEV_POWER_USAGE：功耗
• DCGM_FI_DEV_GPU_TEMP：GPU 温度
• DCGM_FI_DEV_NVLINK_BANDWIDTH_TOTAL：NVLink 总带宽
• DCGM_FI_PROF_PIPE_TENSOR_ACTIVE：Tensor Core 活跃度

注意：DCGM_FI_PROF_*系列的指标（profiling 指标）默认是关闭的，需要在启动时加--collectors参数指定。这些指标对训练任务监控很重要，但采集频率高会带来额外开销，建议采集间隔设为 10s 以上。

4.2 Prometheus 配置：别让采集成为负担

Prometheus 的配置核心是scrape_configs。对于 GPU 监控，典型的配置长这样：

scrape_configs: - job_name: 'dcgm' scrape_interval: 15s static_configs: - targets: - 'gpu-node-01:9400' - 'gpu-node-02:9400' - 'gpu-node-03:9400'

这里有几个经验值：采集间隔 15s 是平衡点。设成 5s 会导致 Prometheus 存储压力大，设成 60s 又会漏掉短时故障。如果集群规模超过 100 个节点，建议用 Prometheus 的联邦模式或者 Thanos 做长期存储。

还有一个坑：DCGM Exporter 在高负载下会超时。如果发现 Prometheus 里经常有context deadline exceeded的报错，把scrape_timeout调大一点，或者给 DCGM Exporter 分配更多 CPU。

4.3 Grafana 看板：怎么设计才"看得懂"

Grafana 看板的设计原则是：一屏之内看到关键信息，异常时能快速下钻。我自己的看板分三层：

第一层是集群总览，用热力图展示所有节点的 GPU 利用率。正常情况下一片绿，有问题的节点会显示为黄色或红色。这一层的作用是"快速定位问题节点"。

第二层是节点详情，展示单节点 8 卡的各项指标：利用率、显存、温度、功耗、NVLink 带宽。这一层的作用是"确认问题类型"。

第三层是任务详情，展示具体训练任务的 MFU、通信占比、吞吐曲线。这一层需要和训练框架集成，把任务级指标也推到 Prometheus 里。

看板配置里有个细节：颜色阈值要按集群基线来设。比如 GPU 利用率，如果你的集群正常是 80%-95%，那阈值就设成 70% 黄色、50% 红色。别照搬网上的模板，那些模板的阈值不一定适合你的场景。

4.4 告警规则：别让告警变成"狼来了"

告警配置最忌讳的是"什么都告警"。我见过一个集群，每天发几百条告警，最后所有人都把告警屏蔽了。告警规则应该遵循"少而精"原则，只对真正影响训练任务的异常告警。

我自己的告警规则大概有这几条：

告警的"持续时间"很重要。瞬时抖动不要告警，只有持续异常才告警。另外，告警要带上下文信息，比如"节点 gpu-node-03 的 GPU 3 温度 87°C，当前运行任务 train-llm-001"，这样收到告警的人能直接判断影响范围。

5. 故障诊断实战：从"卡死"到"定位根因"

前面讲的都是"预防"和"发现"，这一节讲"定位"。智算集群的故障诊断，最难的不是修复，而是找到根因。因为 AI 训练的故障往往是多因素叠加的，网络、存储、GPU、软件栈任何一个环节出问题，表现都是"训练变慢"。

5.1 一个真实的排查案例：all-reduce 慢 3 倍

我遇到过这样一个案例：一个 32 节点的训练任务，前 1000 步正常，之后吞吐突然掉到原来的 1/3。日志里没有任何报错，nvidia-smi看 GPU 利用率在 30%-80% 之间波动。

排查过程是这样的：

第一步，确认是通信问题还是计算问题。用py-spydump 了训练进程的调用栈，发现大量时间花在ncclAllReduce上。初步判断是通信瓶颈。

第二步，看 NCCL 的通信日志。在训练脚本里加了NCCL_DEBUG=INFO，重新跑了一次。日志里发现 NCCL 在某个时刻从 NVLink 切换到了 PCIe——这意味着 NVLink 链路出了问题。

第三步，定位具体节点。用nvidia-smi nvlink -s查看每个节点的 NVLink 状态，发现 node-17 的 GPU 2 和 GPU 3 之间的 NVLink 带宽只有正常值的一半。

第四步，确认硬件问题。用dcgmi diag -r 2跑诊断，报出 NVLink 的 CRC 错误计数异常。基本确定是硬件故障。

第五步，处理。把 node-17 从集群里摘掉，任务重新调度后恢复正常。后续联系厂商更换了 NVLink 板卡。

这个案例的关键在于：NCCL 的日志是排查通信问题的第一手资料。很多人跑训练时不开 NCCL_DEBUG，出问题了才想起来，但故障可能已经过去了。我的建议是生产环境默认开NCCL_DEBUG=WARN，出问题时临时调到INFO。

5.2 用 PyTorch Profiler 定位"慢在哪"

如果确认不是硬件问题，那就要看软件层面。PyTorch Profiler 是最常用的工具：

import torch from torch.profiler import profile, ProfilerActivity with profile( activities=[ProfilerActivity.CPU, ProfilerActivity.CUDA], schedule=torch.profiler.schedule(wait=1, warmup=1, active=3), on_trace_ready=torch.profiler.tensorboard_trace_handler('./log'), record_shapes=True, profile_memory=True, ) as prof: for step, data in enumerate(dataloader): train_step(data) prof.step() if step >= 5: break

跑完之后用 TensorBoard 打开./log，能看到每个操作的耗时。重点看几个地方：

• CUDA kernel 的间隙：如果两个 kernel 之间有明显的空白，说明 GPU 在等待。
• NCCL 操作的耗时：如果 all-reduce 占了 30% 以上，说明通信是瓶颈。
• DataLoader 的等待：如果enumerate(dataloader)耗时很长，说明数据加载慢。

提示：Profiler 本身有开销，不要在生产任务上长期开着。建议在复现问题时临时开，跑几十步就够了。

5.3 常见故障的"症状—根因"对照表

根据我自己的经验，智算集群的故障大概可以归为几类。下面这张表是"症状—可能根因—验证方法"的对照，可以在排查时参考：

这张表不是万能的，但能覆盖 80% 的常见问题。关键是养成"先看症状，再查根因"的习惯，不要一上来就瞎猜。

5.4 日志与指标关联：把"碎片"拼成"全貌"

故障诊断最难的地方在于：信息是碎片化的。NCCL 日志在训练容器里，GPU 指标在 Prometheus 里，网络指标在交换机上，存储指标在文件系统里。要把这些信息关联起来，才能看到全貌。

我的做法是统一时间戳。所有日志和指标都带 UTC 时间戳，排查时先确定故障发生的时间点，然后把那个时间点前后 5 分钟的所有信息拉出来对比。比如：

• 14:23:15，NCCL 日志显示 all-reduce 耗时从 50ms 跳到 200ms
• 14:23:10，Prometheus 显示 node-17 的 NVLink 带宽从 250GB/s 掉到 80GB/s
• 14:23:20，交换机日志显示某个端口有 CRC 错误

三条信息一关联，根因就清楚了：交换机端口故障导致 NVLink 通信降速。

6. 几个容易踩的坑和我的应对经验

6.1 别迷信"官方推荐配置"

NCCL 有很多环境变量可以调，比如NCCL_ALGO、NCCL_PROTO、NCCL_MIN_NCHANNELS。网上有很多"优化指南"推荐一套固定配置，但这些配置不一定适合你的集群。NCCL 的默认配置是自适应的，它会根据拓扑和消息大小自动选择算法。除非你明确知道自己在做什么，否则不要乱改。

我自己的经验是：只调三个变量。NCCL_DEBUG=WARN用于排查问题，NCCL_IB_HCA指定 RDMA 网卡（多网卡时必须设），NCCL_SOCKET_IFNAME指定通信网卡。其他的保持默认。

6.2 监控采集本身也会"拖慢"训练

DCGM 的 profiling 指标采集是有开销的。如果采集频率太高（比如 1s 一次），会占用 GPU 的 SM 资源，导致训练性能下降 5%-10%。我的建议是：profiling 指标采集间隔不低于 10s，非 profiling 指标可以 5s。如果发现训练性能异常，先停掉 profiling 采集再测。

6.3 "重启解决一切"是陷阱

很多运维遇到问题的第一反应是"重启节点"。重启确实能解决一部分问题（比如显存泄漏、驱动异常），但重启会丢失现场。如果问题复现不了，你就永远不知道根因。我的原则是：先收集信息，再重启。至少把dmesg、nvidia-smi -q、NCCL 日志、Prometheus 指标快照保存下来，再动手重启。

6.4 建立"故障知识库"

每次排查完一个故障，我都会写一份简短的复盘文档，记录：症状、排查过程、根因、解决方案、预防措施。时间长了，这就成了一个知识库。下次遇到类似问题，直接搜关键词就能找到参考。这个习惯看起来麻烦，但能省下大量重复排查的时间。

7. 写在最后的一点个人体会

智算集群的监控和故障诊断，本质上是一个**"建立基线—发现异常—定位根因—修复验证"**的闭环。Benchmark 是建立基线的手段，监控是发现异常的眼睛，故障诊断是定位根因的方法。三者缺一不可。

我自己的体会是：不要追求"一步到位"的完美监控体系。一开始可能只有 DCGM + Prometheus + 几个基础看板，但随着你排查的问题越来越多，看板和告警规则会自然生长。关键是养成"用数据说话"的习惯——遇到问题先看指标，而不是凭感觉猜。

另外，多和训练任务的负责人沟通。运维看到的是"GPU 利用率下降"，算法工程师看到的是"loss 曲线异常"。两边的信息结合起来，才能更快定位问题。我见过很多故障，其实算法工程师那边早就有异常信号了，只是没人问。

最后分享一个小技巧：给每个训练任务打上标签（任务名、负责人、优先级），这样在 Grafana 里可以按任务维度过滤指标。当某个任务出问题时，直接看这个任务的所有相关指标，比在集群总览里大海捞针高效得多。