GPU监控指标

先给出一个总图：

GPU 硬件
   │
   ├── SM / Tensor Core        → 计算利用率
   ├── HBM / Memory Controller→ 显存容量、带宽
   ├── PCIe                    → CPU↔GPU 数据传输
   ├── NVLink / NVSwitch       → GPU↔GPU 通信
   ├── Power / Clock           → 功耗、频率、降频
   ├── Thermal                 → 温度
   ├── ECC / RAS               → 硬件错误
   └── MIG / Process           → GPU 切分和任务归属

                    ↓

                NVML / DCGM

                    ↓

              DCGM Exporter

                    ↓

                Prometheus

                    ↓

         Grafana / Alertmanager / AIOps

NVIDIA 官方目前仍然推荐在 Kubernetes GPU 集群中使用 DCGM Exporter 将 DCGM 指标暴露给 Prometheus；nvidia-smi 更适合作为节点侧临时诊断工具。nvidia-smi 本身底层调用 NVML，而 DCGM 是面向数据中心 GPU 集群监控、健康检查和性能分析的更高层组件。(NVIDIA Docs)

1. 第一类：GPU 计算资源指标

这是最容易被关注、同时也最容易被误判的一组指标。

1.1. GPU Utilization

最基础的是：

DCGM_FI_DEV_GPU_UTIL

它表示 GPU 在采样周期内有多少时间处于忙碌状态，可以近似理解为 nvidia-smi 中的：

GPU-Util

例如：

GPU Util = 95%

只能说明：

GPU 大部分时间存在活动。

它不能直接说明 Tensor Core 是否被充分利用，也不能直接说明训练效率高。

所以：

GPU Util = 100%

并不等价于：

模型训练效率 = 100%

这是 GPU 运维中非常重要的区别。

1.2. SM Active

对于训练集群，比普通 GPU Util 更值得关注的是 SM 活跃程度。

典型 DCGM profiling 指标包括：

DCGM_FI_PROF_SM_ACTIVE

SM 是 GPU 的主要计算执行单元，因此这个指标更接近：

SM 有多少时间真正处于执行状态。

例如：

GPU Util        95%
SM Active       90%

一般说明计算资源确实比较繁忙。

但如果：

GPU Util        95%
SM Active       25%

就说明虽然设备被认为“忙”，但是实际 SM 计算利用率并不高。

DCGM 的 profiling 模块就是为了暴露这类更细粒度的 GPU 性能指标。(NVIDIA Docs)

1.3. Tensor Core 利用率

大模型训练最核心的计算资源通常不是普通 CUDA Core，而是 Tensor Core。

对应的 DCGM profiling 指标常见为：

DCGM_FI_PROF_PIPE_TENSOR_ACTIVE

它反映 Tensor Core 相关计算管线的活跃程度。

例如 Transformer 训练：

GPU Util            100%
SM Active            90%
Tensor Active        85%

这种情况通常比较理想。

但如果：

GPU Util            100%
SM Active            85%
Tensor Active         5%

则意味着大量 GPU 时间并不是用于 Tensor Core 矩阵计算。

可能是：

非 Tensor Core kernel
数据整理
memory operation
通信相关 kernel
精度或算子未充分利用 Tensor Core

所以对于大模型训练：

GPU Util 是“忙不忙”，Tensor Active 才更接近“是不是在做最有价值的 AI 计算”。

2. 第二类：显存容量指标

GPU 显存可以分成两个完全不同的问题：

容量够不够 带宽够不够

很多人把两者混在一起。

2.1. 显存使用量

常见指标：

DCGM_FI_DEV_FB_USED
DCGM_FI_DEV_FB_FREE
DCGM_FI_DEV_FB_TOTAL

这里的 FB 指 Framebuffer Memory，本质上就是通常所说的 GPU 显存。

例如：

Used  = 72 GiB
Total = 80 GiB

显存使用率：

MemoryUsage = \frac{MemoryUsed}{MemoryTotal}

得到：

\frac{72}{80}=90%

2.2. 显存容量主要解决什么问题？

主要判断：

模型是不是太大
batch size 是否过大
optimizer state 是否占用过多
是否存在显存泄漏
是否接近 OOM

例如：

Memory Used    79.5 GiB / 80 GiB
GPU Util       90%

这是 OOM 高风险状态。

而：

Memory Used    75 GiB
GPU Util        5%

说明：

模型已经加载在显存里，但 GPU 计算可能几乎没有推进。

所以不能看到“显存占用高”就认为 GPU 使用充分。

3. 第三类：显存带宽与 Memory Controller

对于现代 GPU，尤其是 Transformer，很多 workload 不一定是算力瓶颈，也可能是 memory-bound。

典型指标：

DCGM_FI_PROF_DRAM_ACTIVE

它用于观察显存 DRAM/HBM 子系统活跃程度。

可以粗略理解成：

SM
 │
 │ 请求数据
 ▼
L2 Cache
 │
 ▼
Memory Controller
 │
 ▼
HBM

如果 HBM 带宽接近饱和，SM 可能不断等待数据。

例如：

SM Active       45%
DRAM Active     95%
Tensor Active   30%

这非常像：

Memory bandwidth bottleneck

也就是显存带宽成为瓶颈。

而如果：

SM Active       95%
DRAM Active     40%
Tensor Active   90%

就更像典型的 compute-bound workload。

这也是为什么 GPU 性能分析不能只看 nvidia-smi 的 GPU Util。

4. 第四类：温度指标

GPU 芯片内部有多个热传感器，由驱动/DCGM 暴露状态。

基础指标：

DCGM_FI_DEV_GPU_TEMP

表示 GPU 核心温度。

例如：

GPU TEMP = 72°C

单看温度没有意义，真正需要同时看：

Temperature
Clock
Power
Throttle Reason

因为温度真正影响性能的机制是：

温度升高
   ↓
超过硬件控制阈值
   ↓
GPU降低频率
   ↓
SM吞吐下降
   ↓
训练速度下降

也就是：

Thermal throttling

5. 第五类：GPU 时钟频率

常见指标：

DCGM_FI_DEV_SM_CLOCK
DCGM_FI_DEV_MEM_CLOCK

分别表示：

SM Clock
Memory Clock

例如：

SM Clock     1800 MHz
Memory Clock 1600 MHz

时钟本身不是越高越好，关键是看：

在相同 workload 下，频率是否异常下降。

例如正常：

GPU Util     98%
SM Clock     1800 MHz
Temp         72°C

故障状态：

GPU Util     98%
SM Clock      900 MHz
Temp         89°C

这时候很可能正在发生降频。

DCGM 还可以记录 GPU 处于不同 clock slowdown 状态的时间，因此 SRE 可以进一步判断是不是 power、thermal 等原因导致频率下降。(NVIDIA Docs)

6. 第六类：功耗指标

常见指标：

DCGM_FI_DEV_POWER_USAGE

以及功耗上限相关字段。

例如：

Power Usage = 620 W
Power Limit = 700 W

功耗是一个非常有价值的辅助指标。

例如：

GPU Util     100%
Power        650W
Clock        正常

一般说明 GPU 正在高负载运行。

但是：

GPU Util     100%
Power        200W
Clock        很低

就非常异常。

可能出现：

Power limit
Thermal throttle
Clock throttle

因此：

GPU 利用率 + Power + Clock

是判断 GPU 是否真正发挥性能的一组重要指标。

7. 第七类：PCIe 指标

PCIe 是主机与 GPU 之间的重要通信总线。

数据链路通常是：

NVMe / Network
     ↓
CPU RAM
     ↓
PCIe
     ↓
GPU HBM

因此需要关注：

PCIe TX
PCIe RX
PCIe Link Width
PCIe Link Generation
Replay / Error

DCGM/NVML 可以提供相应 PCIe 状态及流量字段。官方 DCGM 统计也包括 PCIe traffic。(NVIDIA Docs)

7.1. 一个很典型的故障

假设一块 GPU 正常应该工作在：

PCIe Gen5 x16

结果因为：

主板问题
插槽问题
BIOS
PCIe link training 问题

最后变成：

PCIe Gen1 x8

GPU 本身：

温度正常
ECC正常
显存正常

但是训练速度明显下降。

这类问题如果只监控 GPU Util，非常难发现。

所以硬件监控一定需要记录：

PCIe generation
PCIe width
PCIe throughput

8. 第八类：NVLink / NVSwitch 指标

单 GPU 监控到这里已经比较完整。

但大型训练服务器，例如 HGX 系列，还必须关注：

GPU ↔ NVLink ↔ NVSwitch ↔ GPU

因为大模型需要频繁进行：

AllReduce
AllGather
ReduceScatter

主要关注：

NVLink RX
NVLink TX
NVLink Error
Link State
NVSwitch Health

profiling 指标中可以观察 NVLink 数据传输。

如果：

GPU0 计算正常
GPU1 计算正常

但：

NVLink throughput异常下降
NCCL latency大幅增加

整个训练仍然会明显变慢。

9. 第九类：ECC 错误

这是数据中心 GPU 运维必须重点监控的硬件健康指标。

显存可能发生 bit error。

ECC 会负责检测和纠正一部分错误。

主要分：

9.1. Correctable Error

通常对应：

可以由 ECC 自动纠正。

单次出现未必意味着 GPU 必须下线，但持续增加需要关注。

9.2. Uncorrectable Error

表示：

无法可靠纠正的数据错误。

这种情况严重得多。

生产环境通常对：

Uncorrectable ECC > 0

采用非常高的告警等级。

DCGM 本身提供大量 ECC/RAS 字段；具体字段和支持情况会因 GPU 架构和驱动不同而变化，所以应以当前 DCGM Field Identifiers 为准。(NVIDIA Docs)

10. Xid Error：GPU 运维最值得掌握的错误体系之一

NVIDIA 驱动会通过 kernel log 报告 GPU Xid Error。

例如后续非常可能看到：

NVRM: Xid ...

Xid 可能涉及：

GPU engine
memory
PCIe
driver
firmware
application

等不同问题。

这类错误不能只靠 Prometheus 数值指标。

所以 GPU 生产监控还应该采集：

kernel log
dmesg
NVIDIA Xid

通常可以通过：

journald
    ↓
Fluent Bit / Vector / Promtail
    ↓
Loki / Elasticsearch

进行日志采集。

11. PCIe / NVLink / ECC 为什么属于“健康指标”而不是性能指标

可以把 GPU 指标分成两类。

第一类：

Performance

例如：

SM Active
Tensor Active
DRAM Active
PCIe bandwidth
NVLink bandwidth

回答：

GPU 为什么跑得慢？

第二类：

Health / RAS

例如：

ECC
Xid
PCIe error
NVLink error
Temperature
Throttle

回答：

GPU 有没有发生硬件异常？

在 GPU 集群里，这两个体系必须同时建设。

12. 第十类：MIG 指标

如果使用：

MIG — Multi-Instance GPU

一张 GPU 会被划分成多个逻辑 GPU 实例。

例如：

Physical GPU
      │
      ├── MIG Instance 0
      ├── MIG Instance 1
      └── MIG Instance 2

这时候如果只做 GPU 卡级别监控，就不够了。

需要把指标细化到：

GPU Instance
Compute Instance
Pod
Container

NVIDIA 的 MIG 管理可以通过 NVML 和 nvidia-smi 完成，DCGM Exporter 也能够结合 Kubernetes 工作负载信息输出 GPU/MIG 级别的指标。(NVIDIA Docs)

13. 真正生产环境建议采集的 GPU 指标集

生产训练节点不应将全部 DCGM 字段直接写入 Prometheus，而应按照用途分层采集。

硬件层	核心指标	主要问题
计算	GPU Util	GPU 是否忙
计算	SM Active	SM 是否真正执行计算
AI计算	Tensor Active	Tensor Core 是否有效工作
显存	FB Used/Free	容量/OOM
显存	DRAM Active	显存带宽瓶颈
频率	SM Clock	GPU 是否降频
频率	Memory Clock	显存频率是否正常
热管理	GPU Temp	过热
功耗	Power Usage	功耗限制/负载状态
PCIe	RX/TX	Host-GPU 数据传输
PCIe	Link Gen/Width	PCIe 链路异常
NVLink	RX/TX	GPU-GPU 通信
NVLink	Error	链路健康
RAS	ECC Correctable	显存健康趋势
RAS	ECC Uncorrectable	严重硬件错误
RAS	Xid	驱动/GPU/PCIe 等异常
资源	MIG 状态	GPU 切分状态

这里还缺一组非常重要的指标：

CPU
RAM
NVMe
NIC
RDMA
NCCL
训练吞吐

因为 GPU 低利用率不一定是 GPU 问题。

14. 采集方式一：nvidia-smi

最简单。

查看：

nvidia-smi

持续观察：

watch -n 1 nvidia-smi

查询指定字段：

nvidia-smi \
  --query-gpu=timestamp,index,name,utilization.gpu,memory.used,memory.total,temperature.gpu,power.draw,clocks.sm \
  --format=csv

例如输出：

timestamp,index,name,utilization.gpu,memory.used,...
2026-08-17 ...,0,NVIDIA H100,97 %,73421 MiB,...

非常适合：

临时排障
Shell 脚本
单节点测试

但不适合承担大型集群监控系统。

NVIDIA 官方也明确说明 nvidia-smi 是 NVML 上的命令行监控和管理工具。(NVIDIA Docs)

15. 采集方式二：直接调用 NVML

如果自己开发 GPU 监控 Agent，可以调用 NVML。

架构：

Python / C / Go Agent
        ↓
       NVML
        ↓
 NVIDIA Driver
        ↓
       GPU

例如 Python 通常可以通过 NVIDIA NVML 的 Python binding 获取：

GPU utilization
Memory
Temperature
Power
Clock
Process

优点是：

可以自己控制采样逻辑和业务逻辑。

适合做：

自定义 GPU Agent
AIOps Agent
GPU scheduler
节点健康检测程序

NVML 是 nvidia-smi 底层使用的 NVIDIA 官方管理 API。(NVIDIA Docs)

16. 采集方式三：DCGM

数据中心环境更推荐：

DCGM

全称：

Data Center GPU Manager

它不是简单的 NVML 封装。

DCGM 面向 GPU 集群提供：

telemetry
profiling
diagnostics
health monitoring
policy
statistics

NVIDIA 官方将 DCGM 定位为数据中心 GPU 管理与监控组件，并且它提供 C、Python、Go 等 API 以及 dcgmi。(NVIDIA Docs)

可以简单理解成：

NVML

GPU管理API

而：

DCGM

GPU数据中心管理系统

17. 生产 Kubernetes 推荐：DCGM Exporter

真正和当前 Prometheus/Kubernetes 学习体系结合起来的是：

dcgm-exporter

架构：

               GPU
                │
             Driver
                │
              DCGM
                │
         DCGM Exporter
                │
            /metrics
                │
          ServiceMonitor
                │
           Prometheus
                │
             Grafana
                │
          AlertManager

这是 NVIDIA 官方推荐的 Kubernetes GPU telemetry 方案。DCGM Exporter 会把选择的 DCGM fields 转换成 Prometheus metrics，并且可以结合 Kubernetes 的 KubeletPodResources API 把 GPU 指标和 Pod/workload 对应起来。(NVIDIA Docs)

18. DCGM Exporter 实际采集过程

假设节点：

GPU0
GPU1
GPU2
GPU3

每个 GPU 节点运行：

dcgm-exporter

它读取：

DCGM_FI_DEV_GPU_UTIL
DCGM_FI_DEV_FB_USED
DCGM_FI_DEV_GPU_TEMP
...

然后生成类似 Prometheus 格式：

DCGM_FI_DEV_GPU_UTIL{gpu="0",UUID="GPU-xxx"} 96

DCGM_FI_DEV_FB_USED{gpu="0",UUID="GPU-xxx"} 70321

DCGM_FI_DEV_GPU_TEMP{gpu="0",UUID="GPU-xxx"} 72

Prometheus：

GET /metrics

定期抓取。

具体暴露哪些字段由 DCGM Exporter 的 collector 配置决定；当前官方文档明确说明 exporter 会根据 collector CSV、ConfigMap 或 YAML 配置选择字段，并建议以 DCGM Field Identifiers 查询字段的确切含义、单位和硬件支持范围。(NVIDIA Docs)

19. 采样周期应该怎么选择

不能简单把所有 GPU 指标：

scrape_interval: 15s

一刀切。

GPU workload 变化非常快。

例如：

计算 800ms
等待通信 200ms
计算 800ms
等待通信 200ms

如果出现以下情况：

每15秒采样一次

大量性能波动根本看不到。

所以一般可以区分：

19.1. 容量/健康指标

例如：

Memory
Temperature
ECC

可以：

10s~30s

甚至一些健康状态更长。

19.2. 性能分析

例如：

SM Active
Tensor Active
DRAM Active
PCIe
NVLink

做故障分析时通常需要：

1s

左右甚至更细的观察窗口。

NVIDIA 当前 DCGM Exporter 文档也提供了将 collection interval 设置为 1000 ms 的示例，并有专门的 1 秒 GPU/CPU telemetry SRE runbook。(NVIDIA Docs)

但生产环境不能所有节点、所有指标永久 1 秒采集，否则：

GPU数量 × 指标数量 × 采样频率

会导致 Prometheus cardinality 和存储压力迅速上升。

20. GPU 运维真正要做“组合判断”

这是 GPU 监控中需要重点掌握的部分。

20.1. 场景一：计算饱和

SM Active        ↑
Tensor Active    ↑
DRAM Active      中等
GPU Util         ↑
Power            ↑
Clock            正常

判断：

GPU 算力接近瓶颈。

20.2. 场景二：HBM 带宽瓶颈

SM Active        中等
Tensor Active    ↓
DRAM Active      ↑↑

判断：

GPU 很可能 memory-bound。

20.3. 场景三：CPU/数据供应不足

GPU Util         ↓
SM Active        ↓
DRAM Active      ↓
PCIe RX          周期性
CPU              ↑

判断：

GPU 很可能在等 host 侧数据。

20.4. 场景四：热降频

Temperature      ↑
Clock            ↓
GPU Util         ↑
Power            变化

判断：

GPU workload 没停，但硬件性能被 thermal throttling 限制。

20.5. 场景五：硬件故障

ECC Error        ↑
Xid              出现
PCIe Error       ↑
NVLink Error     ↑

判断：

已经从“性能问题”进入“硬件健康问题”。

这时候处理思路通常不应该继续调训练参数，而是：

定位GPU
   ↓
隔离节点
   ↓
保存训练状态
   ↓
运行诊断
   ↓
维修/替换

21. 基于 Prometheus 构建 GPU 监控体系

此前已经在学习 Prometheus、ServiceMonitor 和 Kubernetes，所以最终建议把 GPU telemetry 接到现有体系：

                           Kubernetes Node

                              GPU
                               │
                        NVIDIA Driver
                               │
                              DCGM
                               │
                       DCGM Exporter
                               │
                        :9400/metrics
                               │
                            Service
                               │
                        ServiceMonitor
                               │
                          Prometheus
                               │
           ┌───────────────────┼──────────────────┐
           │                   │                  │
        Grafana            AlertManager        AIOps
           │                                      │
      人工观察                           自动相关性分析

NVIDIA 的 Kubernetes GPU telemetry 集成也正是按照 DCGM Exporter → Prometheus → Grafana 这条链路设计的。(NVIDIA Docs)

21.1. GPU 监控分析模型

分析一张 GPU 时，不应只关注：

GPU Util
Memory
Temperature

而应该想到完整硬件数据路径：

                 CPU / RAM
                    │
                  PCIe
                    │
                    ▼
       ┌─────────────────────────┐
       │           GPU           │
       │                         │
       │       HBM Memory        │
       │           │             │
       │    Memory Controller    │
       │           │             │
       │          L2             │
       │           │             │
       │          SM             │
       │       ┌───┴───┐         │
       │ CUDA Core Tensor Core   │
       │                         │
       │ Power / Clock / Thermal │
       │ ECC / RAS               │
       └───────────┬─────────────┘
                   │
             NVLink/NVSwitch
                   │
                  GPU

然后建立指标映射：

CUDA / Tensor计算
        ↓
SM Active / Tensor Active

HBM
        ↓
FB Used / DRAM Active

CPU ↔ GPU
        ↓
PCIe RX/TX

GPU ↔ GPU
        ↓
NVLink RX/TX

供电和性能控制
        ↓
Power / Clock / Throttle

散热
        ↓
Temperature

硬件可靠性
        ↓
ECC / Xid / PCIe Error

这才是一套真正能支持 GPU SRE 和训练集群排障的监控体系。

后续可按 SM、HBM、PCIe、NVLink、ECC 和 Power 等模块继续拆解 DCGM Exporter 的常用 DCGM_FI_* 指标，并结合 PromQL 与实际故障场景进行验证。

关联文档

从 GPU 硬件结构到监控指标：说明 GPU 硬件模块与观测指标之间的对应关系。

DCGM Exporter 指标级别的工程化：深入理解 DCGM 指标组合、看板与告警设计。

GPU 硬件指标完整监控方案：补充生产环境中的 GPU 硬件监控方案。

YancheBlog

热门标签

GPU监控指标

1. 第一类：GPU 计算资源指标

1.1. GPU Utilization

1.2. SM Active

1.3. Tensor Core 利用率

2. 第二类：显存容量指标

2.1. 显存使用量

2.2. 显存容量主要解决什么问题？

3. 第三类：显存带宽与 Memory Controller

4. 第四类：温度指标

5. 第五类：GPU 时钟频率

6. 第六类：功耗指标

7. 第七类：PCIe 指标

7.1. 一个很典型的故障

8. 第八类：NVLink / NVSwitch 指标

9. 第九类：ECC 错误

9.1. Correctable Error

9.2. Uncorrectable Error

10. Xid Error：GPU 运维最值得掌握的错误体系之一

11. PCIe / NVLink / ECC 为什么属于“健康指标”而不是性能指标

12. 第十类：MIG 指标

13. 真正生产环境建议采集的 GPU 指标集

14. 采集方式一：nvidia-smi

15. 采集方式二：直接调用 NVML

16. 采集方式三：DCGM

17. 生产 Kubernetes 推荐：DCGM Exporter

18. DCGM Exporter 实际采集过程

19. 采样周期应该怎么选择

19.1. 容量/健康指标

19.2. 性能分析

20. GPU 运维真正要做“组合判断”

20.1. 场景一：计算饱和

20.2. 场景二：HBM 带宽瓶颈

20.3. 场景三：CPU/数据供应不足

20.4. 场景四：热降频

20.5. 场景五：硬件故障

21. 基于 Prometheus 构建 GPU 监控体系

21.1. GPU 监控分析模型

目录