一、引言：GPU 利用率 96%，为什么训练性能依然可能很差？

当 GPU 真正运行一个大模型训练任务时，我们如何知道这些硬件资源有没有被充分利用？

举个例子。

假设现在有一个 8 卡 H100 训练集群，监控面板显示：

从 GPU 利用率来看，96% 已经非常高了，似乎 GPU 正在全力工作。

但再看功耗，320W 只占 H100 SXM 约 700W 设计功耗的 45.7%。

这就产生了一个值得思考的问题：

GPU 明明一直处于忙碌状态，为什么功耗却没有达到预期？

这说明我们不能简单地把 GPU 利用率等同于 GPU 计算效率。

GPU 可能正在执行大量小规模 Kernel，可能受限于数据搬运，也可能存在多卡通信等待。甚至可能出现 GPU 看起来很忙，但真正用于有效计算的时间并不多的情况。

这也是本篇学习 DCGM 的出发点。

DCGM 不只是一个 GPU 监控工具，更重要的是，它能够帮助我们建立一套观察 GPU 运行状态、分析性能瓶颈和发现硬件异常的方法。

本篇将围绕四个层次展开：

1. 监控基础设施：DCGM 如何接入 Prometheus 和 Grafana？

2. 硬件运行状态：GPU 利用率、功耗、显存和温度分别说明什么？

3. 性能瓶颈分析：如何利用 PROF 指标分析 GPU 为什么没有发挥全部性能？

4. 故障诊断：如何排查训练停滞、多卡性能不一致以及 GPU 硬件异常？

二、从 nvidia-smi 到 DCGM：为什么需要专业的 GPU 监控体系？

2.1 nvidia-smi 能看到什么？

在学习 GPU 时，我们最常使用的命令就是：

nvidia-smi

它可以帮助我们查看 GPU 的基本运行状态，例如：

• GPU 型号。

• 显存总量和使用量。

• GPU 利用率。

• GPU 功耗。

• GPU 温度。

• GPU 时钟频率。

• 当前运行的 GPU 进程。

如果想持续观察 GPU 状态，可以使用：

watch -n 1 nvidia-smi

每隔一秒刷新一次监控信息。

对于个人学习、单机实验和临时故障排查来说，这些功能已经很实用。

但是，当环境从一台 GPU 服务器扩展到几十台、几百台 GPU 服务器时，问题就出现了。

例如：

• 如何同时监控整个 GPU 集群？

• 如何保存过去 24 小时的 GPU 运行数据？

• 如何发现某台机器长期存在性能下降？

• 如何根据 GPU 温度和功耗配置自动告警？

• 如何判断某个训练任务是不是一直占用 GPU，却没有产生有效进展？

nvidia-smi 更适合查看当前设备状态，而大规模 GPU 集群需要的是持续采集、历史分析、任务关联和自动告警。

这就需要引入 DCGM。

2.2 DCGM 到底是什么？

DCGM 的全称是 Data Center GPU Manager，即 NVIDIA 数据中心 GPU 管理工具。

它是 NVIDIA 面向数据中心 GPU 环境提供的管理和监控组件，可以获取 GPU 的设备状态、性能数据和健康信息。

与只观察 GPU 当前状态不同，DCGM 更适合融入自动化监控系统。

例如，我们不仅可以知道某张 GPU 当前温度是 80℃，还可以通过历史监控曲线判断：

• 它是不是每天训练一段时间后就开始升温？

• 温度升高之后，SM 时钟频率有没有下降？

• GPU 是否出现过功耗限制？

• 性能下降是不是与硬件异常同时发生？

这些信息对于 AI 数据中心运维非常重要。

这里需要区分两个概念：

DCGM 是 GPU 管理与监控体系的核心组件，DCGM Exporter 则是把 GPU 监控指标暴露给 Prometheus 的服务。

两者并不是同一个东西。

2.3 DCGM + Prometheus + Grafana 的完整架构

实际生产环境中，我们通常不会让运维人员手动登录每一台 GPU 服务器查看数据，而是建立统一的监控平台。

典型架构如下：

GPU 集群 | +-------------+-------------+ | | | v v v GPU Node 1 GPU Node 2 GPU Node 3 | | | +-------+ +-------+ +-------+ | DCGM | | DCGM | | DCGM | +-------+ +-------+ +-------+ | | | +-------+ +-------+ +-------+ |Exporter| |Exporter| |Exporter| +-------+ +-------+ +-------+ | | | +-------------+-------------+ | v Prometheus | +----------+----------+ | | v v Grafana Alertmanager | | v v 监控大屏 告警通知

各组件的职责如下：

在 Kubernetes 环境中，DCGM Exporter 通常以 DaemonSet 方式部署。

为什么使用 DaemonSet？

因为 DaemonSet 可以保证符合条件的每个 GPU 节点都运行一个 Exporter 实例。

这样，无论集群中有多少台 GPU 服务器，都可以通过统一的 Prometheus 进行数据采集。

2.4 监控数据是如何流动的？

DCGM Exporter 默认情况下通常通过 9400 端口暴露 Prometheus 指标。

我们可以使用下面的命令查看：

curl -s localhost:9400/metrics

例如：

# HELP DCGM_FI_DEV_GPU_UTIL GPU utilization (in %). # TYPE DCGM_FI_DEV_GPU_UTIL gauge DCGM_FI_DEV_GPU_UTIL{gpu="0",UUID="GPU-abc-123",pod="training-job-1"} 45.2 DCGM_FI_DEV_GPU_UTIL{gpu="1",UUID="GPU-def-456",pod="inference-svc"} 12.8

这里包含三个重要信息：

第一，指标名称。

DCGM_FI_DEV_GPU_UTIL表示 GPU 利用率。

第二，标签。

例如：

• gpu：GPU 编号。

• UUID：GPU 设备唯一标识。

• pod：关联的 Kubernetes Pod。

标签的作用是给监控数据添加上下文，让我们知道这条数据属于哪台 GPU、哪个设备或者哪个工作负载。

第三，指标数值。

45.2 表示当前采集到的 GPU 利用率为 45.2%。

这也引出了一个很重要的工程思想：

监控系统不能只有数值，还必须有上下文。

如果监控平台只告诉我们某张 GPU 的利用率是 96%，却不知道它属于哪个节点、哪个任务，那么故障定位仍然会非常困难。

因此，在构建 AI Infra 监控体系时，除了采集 GPU 指标，还应该建立 GPU、节点、Pod、训练任务之间的关联关系。

三、GPU 监控指标体系：不要只盯着 GPU Utilization

理解 DCGM 之后，下一步就是认识它能够提供哪些指标。

在 GPU 监控中，我认为可以把指标分为五类：

1. 计算资源指标。

2. 显存与数据访问指标。

3. 功耗和温度指标。

4. 多卡通信指标。

5. 硬件健康指标。

这样分类的好处是：当出现异常时，我们能够按照资源类型逐层分析，而不是面对几十个指标无从下手。

3.1 计算资源指标

常见指标：

这些指标主要帮助我们理解 GPU 的计算资源有没有得到有效利用。

其中最容易被误解的是 GPU Utilization。

GPU 利用率高，只能说明在采样周期内 GPU 有较高比例的时间处于执行活动状态。

它并不能直接说明：

• Tensor Core 是否充分利用。

• 每个 SM 是否都处于高效工作状态。

• 执行的 Kernel 是否具有较高计算效率。

• GPU 是否达到了理论算力峰值。

因此，GPU 利用率应该作为第一层监控指标，而不是最终性能评价指标。

3.2 显存与数据访问指标

常见指标：

这里要特别区分两个概念：

显存容量和显存带宽不是一回事。

显存容量回答的是：

GPU 能够存储多少数据？

显存带宽回答的是：

GPU 每秒能够从显存读取或写入多少数据？

例如，一张 GPU 使用了 70GB 显存，并不意味着显存带宽已经达到上限。

同样，显存只使用了 30GB，也不意味着 GPU 不会遇到显存访问瓶颈。

所以，在分析 GPU 性能时，不能只看显存占用，还要关注数据访问活动。

3.3 功耗与温度指标

常见指标：

这三个指标之间存在一定联系。

GPU 运行时会消耗电能并产生热量。

当温度过高或者触发功耗限制时，GPU 可能降低工作频率，从而影响性能。

因此，如果发现：

• GPU 利用率下降。

• GPU 温度持续升高。

• SM 时钟频率下降。

• 训练吞吐量同时下降。

就应该进一步检查散热、功耗限制和 GPU 降频情况。

需要注意，温度升高不一定意味着 GPU 已经降频，必须结合时钟频率和实际性能变化判断。

3.4 多卡通信指标

常见指标：

DCGM_FI_DEV_NVLINK_BANDWIDTH_TOTAL

它用于观察 NVLink 链路带宽相关活动。

为什么多卡训练需要关注这个指标？

因为在分布式训练中，GPU 不再是独立工作的计算设备。

多张 GPU 需要不断交换数据，例如：

• 张量并行中的中间结果传递。

• 数据并行中的梯度同步。

• 流水线并行中的激活值传递。

如果计算速度很快，但 GPU 之间的数据交换速度跟不上，就会产生通信瓶颈。

这也是为什么 AI 数据中心不仅需要高性能 GPU，还需要高速互联网络。

3.5 硬件健康指标

常见指标：

• DCGM_FI_DEV_XID_ERRORS

• DCGM_FI_DEV_ROW_REMAP_FAILURE

• DCGM_FI_DEV_UNCORRECTABLE_REMAPPED_ROWS

这些指标主要用于发现 GPU 设备自身的问题。

例如：

• GPU 运行过程中出现 XID 错误。

• HBM 出现异常显存行。

• 显存行重映射失败。

这些问题不一定会立即表现为 GPU 利用率异常，但可能影响设备的长期稳定性。

因此，生产环境中的 GPU 监控不能只关注性能，还需要关注硬件健康。

四、深入理解 PROF：为什么 GPU 忙，不代表 GPU 算得好？

这一部分是整篇文章最重要的内容。

前面我们已经知道，GPU 利用率只能反映 GPU 的活动状态。

那么，有没有更进一步的指标，可以帮助我们分析 GPU 到底在执行什么类型的计算？

答案就是 DCGM 中的 Profiling 指标。

4.1 先理解 GPU 的计算过程

GPU 并不是一个单独的计算核心，而是由大量计算单元组成的并行处理器。

理解 PROF 指标之前，需要先建立几个基本概念。

Kernel：

Kernel 是运行在 GPU 上的计算程序。

例如矩阵乘法、向量加法、数据归一化等操作，都可以通过不同的 GPU Kernel 实现。

Warp：

Warp 是 NVIDIA GPU 的基本线程调度单位，通常包含 32 个线程。

GPU 会按照 Warp 组织和调度线程。

SM：

SM，即 Streaming Multiprocessor，是 GPU 内部重要的计算执行单元。

每个 SM 可以管理多个 Warp，并执行不同类型的计算任务。

Tensor Core：

Tensor Core 是 NVIDIA GPU 中专门加速矩阵运算的计算单元。

在深度学习训练中，矩阵乘法占据了大量计算工作，因此 Tensor Core 的利用情况非常值得关注。

可以把它们之间的关系理解为：

GPU 由多个 SM 组成，SM 调度 Warp 执行 Kernel，而 Tensor Core 则参与执行适合其硬件架构的矩阵计算。

4.2 PROF_SM_ACTIVE：SM 是否在工作？

SM Active 主要反映 SM 的活动情况。

如果 SM Active 较低，说明 GPU 的 SM 计算单元没有充分参与执行活动。

可能原因包括：

• Kernel 数量不足。

• 任务并行度不足。

• GPU 正在等待数据。

• 计算任务本身存在阻塞。

但 SM Active 较高，也不代表计算效率一定很高。

因为 SM 可以执行大量不同类型的任务，并不是所有任务都能够充分利用 GPU 的高性能矩阵计算单元。

4.3 PROF_SM_OCCUPANCY：SM 内部的并行资源利用情况

Occupancy 可以理解为 SM 中活跃 Warp 数量与硬件支持的最大 Warp 数量之间的关系。

例如：

如果某个 SM 的理论最大 Warp 容量为 64，而实际只有 32 个活跃 Warp，那么对应的 Occupancy 可以理解为：

为什么 Occupancy 重要？

因为 GPU 是通过大量线程并行执行任务的。

当某些 Warp 因为内存访问而等待时，SM 可以调度其他 Warp 继续工作。

如果同时存在足够多的活跃 Warp，就有机会隐藏一部分内存访问延迟。

但是，这里有一个容易忽略的地方：

Occupancy 越高，不一定意味着性能越好。

因为 Occupancy 还会受到寄存器数量、共享内存使用量、线程块大小等因素影响。

有些 Kernel 即使 Occupancy 只有 50%，也可能已经达到非常高的计算效率。

因此，Occupancy 更适合用来解释资源使用情况，而不是单独作为性能排名指标。

4.4 PROF_PIPE_TENSOR_ACTIVE：Tensor Core 有没有真正参与计算？

这是深度学习训练中非常值得关注的指标。

Tensor Core 主要负责加速矩阵乘法等适合其执行的计算。

对于大模型训练而言，矩阵乘法通常是重要的计算组成部分。

如果 GPU 利用率很高，但 Tensor Active 长期较低，就需要思考：

GPU 是不是一直在执行其他类型的任务？

例如：

• 数据格式转换。

• 小规模向量计算。

• 归一化操作。

• 数据搬运。

• 通信相关操作。

这些任务可能占用 GPU 执行资源，但不一定能充分利用 Tensor Core。

所以，Tensor Active 可以帮助我们从另一个角度观察 GPU 的计算活动。

需要注意，Tensor Active 反映的是 Tensor 管线活跃情况，并不是直接测量 GPU 的实际 FLOPS，也不能简单将其百分比等同于峰值算力利用率。

4.5 PROF_DRAM_ACTIVE：数据搬运是不是瓶颈？

GPU 的计算速度很快，但计算需要的数据必须及时从显存中获取。

如果 GPU 的计算单元需要数据，而显存访问无法及时满足需求，那么计算单元就可能出现等待。

这就是典型的访存瓶颈。

可以用算术强度来理解：

其中：

• AI：Arithmetic Intensity（算术强度）。

• 分子：计算操作次数（通常以 FLOPs 表示）。

• 分母：数据搬运量（通常以 Bytes 表示）。

算术强度越低，意味着每搬运一份数据所能完成的计算越少。

这类任务通常更容易受到内存带宽限制。

因此，当 DRAM Active 较高，而 Tensor Active 较低时，就应该进一步分析显存访问模式。

但也要注意，DRAM Active 并不是简单的显存使用率，也不是显存占用百分比。它反映的是 DRAM 活动情况，具体解释应结合 GPU 架构和指标定义。

4.6 把指标放在一起分析

单独观察每个指标的意义有限。

真正有价值的是将多个指标结合起来分析。

这里我认为最重要的不是记住某一种指标组合，而是建立一个分析习惯：

先确定 GPU 在执行什么类型的工作，再判断这些工作是否真正消耗了我们关心的计算资源。

这比单纯看到 GPU 利用率 90% 就认为性能很好，要可靠得多。

五、案例分析：96% GPU 利用率，为什么功耗只有 320W？

现在回到开头的案例。

假设一台服务器运行 8 卡 H100 训练任务，每张 GPU 的监控数据如下：

首先要强调：这里的 320W 和 62GB 都是单卡数据，而不是 8 卡总和。

5.1 不要急着下结论，先做数据口径校验

GPU 运维中，一个很容易犯的错误就是没有弄清楚指标的统计范围。

例如：

• 是单卡数据还是多卡合计？

• 是瞬时值还是五分钟平均值？

• 是显存已用容量还是显存带宽？

• 是 NVLink 单条链路还是所有链路聚合？

这些口径不同，最终得出的结论可能完全不同。

先计算功耗比例：

再计算显存占用比例：

M=77.5%

现在可以确定：

GPU 利用率很高，功耗没有达到设计功耗上限，显存也已经占用了约 77.5%。

但这些数据仍然不足以确定故障原因。

我们需要进一步观察 GPU 内部的计算活动。

5.2 从模型参数量推导显存占用

假设训练一个 8B 参数模型。

如果采用 FP16 或 BF16 存储权重，每个参数占用 2 Bytes。

那么：

但训练时，显存中不仅存放模型权重。

还可能包括：

• 模型权重。

• 梯度。

• 优化器状态。

• 激活值。

• 临时计算缓冲区。

• CUDA 运行时开销。

如果采用一种常见的混合精度 Adam 训练估算方式，模型状态可能达到约 16 Bytes/Parameter：

如果通过 8 张 GPU 对模型状态进行均匀分片：

这里的 16GB 只是模型状态分片的估算，并不是固定的单卡显存需求。

如果实际单卡使用了 62GB，那么剩余的空间还可能用于激活值、临时缓冲区和其他运行时数据。

因此，不能仅凭 62GB 显存占用就判断 GPU 正在等待数据。

5.3 为什么高利用率不等于高计算效率？

这是整个案例最值得理解的地方。

我们可以把 GPU 的工作简单分成三个环节：

1. 计算：GPU 执行矩阵运算和其他计算任务。

2. 搬运：GPU 从显存或其他设备获取数据。

3. 等待：GPU 等待数据、通信或者其他任务完成。

理想情况下，我们希望 GPU 尽可能把时间花在有效计算上。

但真实训练任务中，这三个环节会不断交错。

例如：

一个 GPU Kernel 可能一直在执行，但执行的任务只是数据处理、同步或小规模计算，并没有充分发挥 Tensor Core 的能力。

于是就会出现：

GPU Utilization 很高，但有效矩阵计算活动并不高。

这也是为什么我们需要 PROF 指标，而不是只依赖 nvidia-smi。

5.4 三类常见性能瓶颈

第一类：通信瓶颈。

8 卡训练时，多张 GPU 需要频繁交换数据。

例如 AllReduce 操作，需要多个 GPU 协同完成梯度同步。

如果通信耗时占据了较大比例，那么 GPU 就可能无法持续执行有效计算。

排查方向：

• 检查 NCCL 配置。

• 检查 NVLink 链路。

• 检查 PCIe 拓扑。

• 检查 TP、PP、DP 并行策略。

• 分析通信与计算是否能够有效重叠。

特别需要关注 NCCL 是否走了预期的高速通信路径。

第二类：计算粒度过小。

GPU 的优势在于大规模并行计算。

如果任务被拆成大量小规模 Kernel，那么每次计算可能无法充分发挥 GPU 的并行能力。

即使 GPU 一直有任务执行，也不意味着计算效率很高。

排查方向：

• 增大合理的 Batch Size。

• 检查矩阵尺寸。

• 优化 Kernel。

• 使用算子融合。

• 减少不必要的 Kernel Launch。

第三类：显存访问瓶颈。

如果任务大量时间用于读取和写入显存，那么 GPU 计算单元就可能因为数据供应不足而等待。

排查方向：

• 检查 DRAM Active。

• 分析显存访问模式。

• 检查数据复用情况。

• 提高算术强度。

• 减少重复数据搬运。

5.5 建立一套真正有用的分析流程

面对 GPU 利用率高、功耗低的问题，我更倾向于采用下面的排查顺序：

GPU Utilization 高 | v 确认单卡数据与采样时间 | v 检查 Power、SM Clock、温度 | v 检查 PROF_PIPE_TENSOR_ACTIVE | v 检查 PROF_DRAM_ACTIVE | v 检查 NVLink / PCIe / NCCL | v 结合训练吞吐量与 Kernel 时间线 | v 定位真正的性能瓶颈

这里有一个重要的认识：

功耗低不一定就是通信瓶颈，Tensor Active 低也不一定就是 GPU 没有发挥性能。

必须把硬件指标、通信指标和训练任务自身的性能数据结合起来。

最终应该关注的是训练吞吐量，例如每秒处理多少 Token，而不只是 GPU 监控面板上的某个百分比。

六、案例分析：GPU 利用率低于 5%，训练任务是不是挂了？

前面分析的是 GPU 看起来很忙，但实际计算效率可能不高。

现在换一个方向：

如果 GPU 利用率突然降到 5% 以下，是不是意味着训练任务已经停止？

答案是不一定。

因为训练任务并不是每时每刻都在执行 GPU 计算。

6.1 为什么训练任务会出现正常的低利用率？

大模型训练通常包含多个阶段：

数据准备 | v 模型加载 | v GPU 初始化 | v 训练计算 | v Checkpoint 保存 | v Evaluation | v 继续训练

在某些阶段，GPU 利用率可能会明显下降。

例如：

• 数据加载期间，CPU 或存储系统可能成为瓶颈。

• Checkpoint 保存期间，GPU 可能暂时等待数据写入。

• Evaluation 阶段，训练和评估的计算模式可能不同。

• 模型初始化期间，GPU 可能还没有进入正式训练。

因此，GPU 利用率低只是一个异常信号，并不是训练任务停止的直接证据。

6.2 第一步：检查训练 Step 是否增长

这是我认为最重要的一步。

对于训练任务而言，真正重要的是训练过程有没有继续推进。

例如：

Step 1000 Step 1001 Step 1002 Step 1003 Step 1004

如果 Step 持续增长，说明训练任务仍然在推进。

可以通过日志查看：

tail -f train.log | grep -i step

也可以结合训练框架的监控接口查看当前训练进度。

这里需要区分：

GPU 利用率是资源活动指标，而训练 Step 是任务进度指标。

前者只能间接反映任务状态，后者更直接地反映训练有没有推进。

不过，如果训练任务正在执行长时间的评估、保存或数据处理，Step 可能暂时不变，因此还需要结合当前任务阶段判断。

6.3 第二步：观察原始曲线，而不是只看平均值

假设告警规则为：

GPU 利用率五分钟平均值低于 5%。

这里存在一个容易忽略的问题：

平均值会掩盖时间变化。

例如，两种情况：

情况 A：

0% 0% 0% 0% 0% 0% 0%

GPU 长时间没有活动。

如果训练 Step 也没有变化，就需要重点排查训练阻塞、进程异常或者硬件故障。

情况 B：

90% 90% 0% 0% 0% 0% 90% 90%

GPU 利用率呈现周期性变化。

这可能意味着训练任务在某些时间段执行计算，在其他时间段执行耗时操作。

例如，周期性保存大型 Checkpoint。

这两种情况的处理方式完全不同。

前者需要排查任务是否异常，后者则应该分析低利用率阶段的耗时是否合理。

所以，告警负责发现问题，原始曲线负责帮助我们理解问题。

6.4 第三步：检查多卡 GPU 是否一致

单卡训练和多卡训练最大的区别之一，就是 GPU 之间存在同步关系。

在多卡训练中，一张 GPU 的性能下降，可能影响整个训练任务。

例如：

这组数据非常值得关注。

GPU 7 的温度明显高于其他 GPU，利用率也明显不同。

这时候应该重点检查：

• GPU 7 是否出现温度降频。

• SM Clock 是否明显下降。

• 是否存在功耗限制。

• 是否存在 PCIe 或 NVLink 异常。

• GPU 7 是否出现 XID 错误。

但不能仅凭 88℃ 就直接认定 GPU 已经降频。

应该继续观察时钟频率和实际计算耗时。

另外，在分布式训练中，一张卡变慢之后，其他卡不一定表现为相同的低利用率曲线，具体取决于并行策略、同步方式和通信调度。

真正要关注的是：是否存在某张卡的计算或通信时间明显落后于其他卡。

6.5 第四步：检查通信和数据访问

如果所有 GPU 都处于低利用率状态，而且训练 Step 没有推进，就需要进一步检查整个任务的执行路径。

重点关注：

通信问题：

• NCCL 是否正常工作？

• AllReduce 是否长时间等待？

• NVLink 是否存在链路异常？

• 是否存在通信超时？

数据问题：

• 数据加载进程是否正常？

• CPU 是否成为瓶颈？

• 存储系统是否出现延迟？

• 数据预处理是否阻塞？

计算问题：

• Kernel 是否正常执行？

• 是否存在长时间等待？

• 是否发生 CUDA 异常？

这里有一个重要的思路：

不要把所有 GPU 利用率低的问题都归结为 GPU 本身。

AI 训练任务实际上是一条完整的数据处理链路：

数据存储 | v CPU 数据预处理 | v 数据加载 | v GPU 显存 | v GPU 计算 | v GPU 间通信 | v 参数更新 | v 下一轮训练

任何一个环节出现问题，都可能导致 GPU 无法持续获得有效工作。

6.6 第五步：检查硬件错误与进程状态

最后检查 GPU 硬件和训练进程。

查看 XID 错误：

dmesg | grep -i xid

查看训练进程：

nvidia-smi

也可以检查系统日志：

journalctl -k | grep -i xid

如果出现 XID，需要根据错误编号进一步定位。

如果进程仍然存在，但训练 Step 长时间不变，就需要继续判断是否发生了死锁、通信阻塞或者其他异常。

七、从监控到运维：如何建立真正有价值的 GPU 告警？

学完 DCGM 之后，我觉得还有一个问题值得深入思考：

既然可以采集这么多指标，是不是把所有指标都配置成告警就可以了？

显然不是。

如果每个指标稍微波动一下就触发告警，最终只会产生大量无效通知。

真正有价值的监控系统，应该把告警分成三个层次。

7.1 第一层：资源告警

主要监控 GPU 是否存在资源使用异常。

例如：

这类告警主要回答：

GPU 有没有出现明显的资源异常？

7.2 第二层：性能告警

性能告警不仅关注 GPU 是否繁忙，还要关注训练性能是否下降。

例如：

• Tensor Active 长期偏低。

• DRAM Active 长期偏高。

• NVLink 通信时间异常。

• GPU 利用率很高，但 Token/s 持续下降。

• 多张 GPU 的计算耗时明显不一致。

这类告警主要回答：

GPU 的硬件资源有没有被有效利用？

7.3 第三层：任务告警

这是我认为最值得重视的一层。

因为 GPU 监控最终是为了保障训练任务正常运行。

例如：

• 训练 Step 长时间不增长。

• Loss 长时间没有更新。

• Token/s 持续下降。

• 训练进程异常退出。

• 分布式任务出现通信超时。

这类告警主要回答：

训练任务有没有真正完成它应该完成的工作？

将三层监控结合起来，才能建立比较完整的 AI Infra 可观测性体系。

八、从 DCGM 延伸：GPU 性能分析还需要哪些工具？

DCGM 能够提供大量 GPU 监控指标，但它并不是完整的性能分析工具。

如果想进一步定位 GPU 内部的具体问题，还需要结合 NVIDIA 的其他工具。

这里尤其值得认识 Nsight Systems 和 Nsight Compute。

Nsight Systems：

它更关注整个任务的时间线。

例如：

• CPU 什么时候提交 Kernel？

• GPU 什么时候开始执行？

• CUDA Stream 之间有没有等待？

• NCCL 通信占用了多少时间？

• 计算和通信有没有有效重叠？

Nsight Compute：

它更关注某个具体 Kernel 的执行效率。

例如：

• Tensor Core 是否得到充分利用？

• 显存访问效率如何？

• Warp 是否频繁等待？

• Kernel 是否存在寄存器或 Occupancy 限制？

可以这样理解：

DCGM 负责告诉我们哪里可能出现问题，Nsight Systems 和 Nsight Compute 则帮助我们深入分析问题发生的原因。

这也是从 GPU 监控走向 GPU 性能工程的重要一步。

九、本篇核心知识总结

经过本篇学习，我对 DCGM 的理解不再只是多认识了几个 GPU 监控指标，而是建立了一套从监控到性能分析的思路。

1. 为什么需要 DCGM？

nvidia-smi 适合查看当前 GPU 状态，而 DCGM 配合 Exporter、Prometheus 和 Grafana，可以建立持续采集、历史分析和自动告警体系。

2. GPU 利用率不等于 GPU 计算效率。

GPU 利用率高，只能说明 GPU 处于较高活动状态，不能直接证明 Tensor Core 得到了充分利用。

3. PROF 指标能够进一步分析 GPU 内部运行情况。

重点关注：

• SM_ACTIVE：观察 SM 活动情况。

• SM_OCCUPANCY：观察活跃 Warp 占用情况。

• PIPE_TENSOR_ACTIVE：观察 Tensor 管线活动。

• DRAM_ACTIVE：观察显存接口活动。

4. GPU 性能瓶颈不一定来自 GPU 本身。

还可能来自：

• 多卡通信。

• CPU 数据预处理。

• 数据存储。

• 显存访问。

• Kernel 执行效率。

5. 判断训练是否挂掉，不能只看 GPU 利用率。

训练 Step、Token/s 和任务日志比单独观察 GPU Utilization 更能反映训练进度。

6. 多卡训练必须关注设备之间的性能一致性。

某一张 GPU 的性能下降，可能影响整个分布式训练任务。

7. GPU 监控的最终目标不是让利用率达到 100%。

真正重要的是在满足训练精度和稳定性的前提下，让 GPU 计算、数据搬运和多卡通信之间达到合理平衡，提高整体训练吞吐量。

如果上面不懂，我觉得可以理解如下：

第一，GPU 利用率是资源活动指标，不是性能指标。

真正需要关注的是训练吞吐量（Tokens/s）、计算效率和端到端执行时间。

第二，GPU 性能是整条数据链路共同决定的。

GPU 再强，如果 CPU 数据处理、显存访问或者多卡通信跟不上，整体训练性能依然上不去。

第三，AI Infra 运维的核心是可观测性，而不是堆砌监控指标。

要把 GPU、CPU、存储、网络、容器和训练任务关联起来，才能从发现异常真正走到定位根因。