DCGM Exporter 指标级别的工程化

DCGM Exporter 的指标工程化不应停留在“指标字典”层面，而应围绕以下链路建立分析方法：

GPU 硬件模块 → DCGM 指标 → Prometheus 中怎么看 → 指标组合意味着什么 → 出问题后往哪里继续查

来建立完整的 GPU 运维思维模型。

先说明一个版本问题：截至 2026 年的 DCGM 4.6 文档，NVIDIA 对部分字段做了规范化，例如 NVLink 的一些 BANDWIDTH 字段已经规范为 THROUGHPUT；DCGM Exporter 为兼容旧配置仍可能暴露旧名称。因此生产环境中要区分“Exporter 暴露的 metric 名称”和“DCGM 当前 canonical field name”。(NVIDIA Docs)

1. 先理解 DCGM Exporter 到底采集了什么

整个链路是：

GPU Hardware
     │
     ▼
NVIDIA Driver
     │
     ▼
   DCGM
     │
     │ watch GPU fields
     ▼
dcgm-exporter
     │
     │ /metrics
     ▼
Prometheus
     │
     ├── Grafana
     ├── Alertmanager
     └── AIOps

DCGM 本身负责观察 GPU 的 telemetry、健康状态、profiling 信息以及诊断数据，而 dcgm-exporter 把选择的 DCGM field 转成 Prometheus metric。哪些字段会真正暴露，不仅取决于配置，还取决于 GPU 型号、驱动、权限以及相关硬件是否支持该字段。(NVIDIA Docs)

目前 DCGM Exporter 默认 collector 已经包含一些非常有价值的训练性能指标，例如：

DCGM_FI_DEV_GPU_UTIL
DCGM_FI_DEV_FB_USED
DCGM_FI_DEV_FB_FREE

DCGM_FI_PROF_PCIE_TX_BYTES
DCGM_FI_PROF_PCIE_RX_BYTES

DCGM_FI_PROF_PIPE_TENSOR_ACTIVE
DCGM_FI_PROF_DRAM_ACTIVE

DCGM_FI_DEV_SM_CLOCK
DCGM_FI_DEV_MEM_CLOCK

DCGM_FI_DEV_GPU_TEMP
DCGM_FI_DEV_POWER_USAGE

DCGM_FI_DEV_XID_ERRORS

而 ECC、thermal violation、power violation 等部分字段在 NVIDIA 当前默认 collector 中属于可选项，需要按需求显式启用。(NVIDIA Docs)

2. 第一组：`DCGM_FI_DEV_GPU_UTIL`

这是最常见，但也是最容易误解的 GPU 指标。

Exporter 中：

DCGM_FI_DEV_GPU_UTIL

当前 canonical DCGM field 是：

DCGM_FI_DEV_GPU_UTIL_RATIO

它表示 GPU utilization。(NVIDIA Docs)

假设 Prometheus 中：

DCGM_FI_DEV_GPU_UTIL

得到：

gpu="0"   97
gpu="1"   95
gpu="2"   20
gpu="3"   96

第一反应应该是：

GPU2 和其他 GPU 的行为不一致。

但不能马上得出：

GPU2 有故障。

因为 GPU Util 只能说明 GPU 是否繁忙，不能说明它为什么不繁忙。

因此实际分析通常要继续看：

GPU Util
   │
   ├── SM / Tensor 是否工作？
   ├── HBM 是否忙？
   ├── PCIe 是否堵塞？
   ├── NVLink 是否等待？
   └── CPU / Storage 是否喂不进数据？

例如训练节点平均 GPU 利用率：

avg by (instance) (
  DCGM_FI_DEV_GPU_UTIL
)

而对于单卡长期低利用率，更建议看一段时间平均：

avg_over_time(
  DCGM_FI_DEV_GPU_UTIL[5m]
)

如果某 GPU：

GPU Util = 20%

而同节点其他 GPU：

GPU Util ≈ 95%

这种相对异常往往比单纯设置：

GPU Util < 50%

更有价值。

3. 第二组：Tensor Core 利用情况

对于大模型训练，这组性能指标通常比单独观察 GPU Util 更有价值。

DCGM Exporter 当前默认包含：

DCGM_FI_PROF_PIPE_TENSOR_ACTIVE

它对应当前 canonical field：

DCGM_FI_PROF_TENSOR_UTIL_RATIO

主要反映 Tensor execution pipeline 的活跃程度。(NVIDIA Docs)

GPU 内部可以粗略理解为：

                 SM

      ┌─────────────────────┐
      │                     │
      │ CUDA / FP pipeline  │
      │                     │
      │ Tensor pipeline     │
      │                     │
      │ Load / Store        │
      │                     │
      └─────────────────────┘

大模型里的 GEMM、Attention 等大量矩阵运算，如果能够有效走 Tensor Core，那么 Tensor pipeline 应该出现明显活动。

PromQL：

DCGM_FI_PROF_PIPE_TENSOR_ACTIVE

假设：

GPU Util       98%
Tensor Active  85%

说明：

GPU 很忙，而且大量时间用于 Tensor Core 工作。

这是比较理想的 AI workload。

但是：

GPU Util       98%
Tensor Active   5%

就必须继续调查。

它可能意味着：

GPU虽然忙
    ↓
但不是主要忙在Tensor计算
    ↓
可能在执行
    ↓
普通CUDA kernel
memory operation
communication kernel
数据重排
不适合Tensor Core的算子

所以对于训练性能分析：

GPU Util

解决的是：

GPU 忙不忙？

而：

Tensor Active

更接近：

GPU 是否在执行任务所需的矩阵计算？

4. 第三组：Graphics/Compute Engine Active

当前默认 collector 还包含：

DCGM_FI_PROF_GR_ENGINE_ACTIVE

对应新的 canonical profiling utilization 字段。(NVIDIA Docs)

不要被 GR 这个名字误导。在数据中心 GPU 场景，它并不只是“图形渲染”。

可以把它理解为：

GPU 主要计算执行引擎的活跃情况。

因此在工程分析里：

GPU Util
GR Engine
Tensor Active

三个指标放在一起会比 GPU Util 单独使用可靠很多。

例如：

GPU Util       95%
GR Engine      高
Tensor Active  高

大概率：

GPU 正在有效执行训练计算。

如果：

GPU Util       95%
GR Engine      高
Tensor Active  低

说明：

GPU 的确在计算，但 workload 未大量使用 Tensor pipeline。

5. 第四组：显存容量——`FB_USED / FREE / RESERVED`

GPU 的显存监控首先解决的是：

HBM 容量够不够？

DCGM 提供：

DCGM_FI_DEV_FB_TOTAL
DCGM_FI_DEV_FB_FREE
DCGM_FI_DEV_FB_USED
DCGM_FI_DEV_FB_RESERVED

目前还提供：

DCGM_FI_DEV_FB_USED_RATIO

其定义为：

\frac{Used}{Total-Reserved}

范围为 0 到 1。(NVIDIA Docs)

Exporter 默认提供：

DCGM_FI_DEV_FB_USED
DCGM_FI_DEV_FB_FREE
DCGM_FI_DEV_FB_RESERVED

(NVIDIA Docs)

Prometheus 里可以自己算使用比例，例如：

DCGM_FI_DEV_FB_USED
/
(
  DCGM_FI_DEV_FB_USED
  +
  DCGM_FI_DEV_FB_FREE
)

不过训练场景下，不建议简单设置：

显存 > 80% → 告警

因为：

大模型训练本来就希望尽可能充分利用显存。

例如：

79 GiB / 80 GiB

未必异常。

真正需要关注的是：

显存持续增长

例如：

10:00  50 GiB
10:10  55 GiB
10:20  61 GiB
10:30  68 GiB
10:40  74 GiB

这比单纯：

Memory Usage = 92%

更值得怀疑。

它可能意味着：

tensor/reference 没有释放
cache 持续增长
batch 行为异常
应用层显存泄漏

可以看变化趋势：

delta(
  DCGM_FI_DEV_FB_USED[30m]
)

所以：

Capacity 是静态问题，growth rate 是动态问题。

对于 AIOps，这一点非常重要。

6. 第五组：`DCGM_FI_PROF_DRAM_ACTIVE`

现在进入一个真正的 GPU 性能指标。

Exporter 默认：

DCGM_FI_PROF_DRAM_ACTIVE

对应 canonical：

DCGM_FI_PROF_DRAM_UTIL_RATIO

用于描述 GPU DRAM/HBM 子系统的活跃程度。(NVIDIA Docs)

对应硬件链路：

Tensor / CUDA Core
        │
        ▼
       SM
        │
        ▼
       L1
        │
        ▼
       L2
        │
        ▼
Memory Controller
        │
        ▼
       HBM

假设：

Tensor Active     30%
DRAM Active       95%

同时：

SM相关计算指标中等

这时候非常值得怀疑：

memory-bound workload。

也就是说：

计算单元
   ↓
想继续计算
   ↓
但是不断等待HBM数据

所以 GPU 即使理论 FLOPS 很高，也无法发挥出来。

7. Compute-bound 和 Memory-bound 怎么区分

这是 GPU 性能分析最基础的模型之一。

7.1. Compute-bound

例如：

Tensor Active   90%
DRAM Active     50%
GPU Util        99%

说明：

GPU 的计算流水线非常忙，而显存系统还没有明显到极限。

主要瓶颈更可能是：

SM / Tensor Core算力

7.2. Memory-bound

例如：

Tensor Active   35%
DRAM Active     95%
GPU Util        90%

说明：

HBM 子系统非常忙，但计算流水线没有完全利用。

可以形成：

HBM
 │
 │ 带宽接近饱和
 ▼
SM等待数据
 │
 ▼
Tensor Core无法持续工作

这就是为什么单看：

GPU Util = 90%

完全无法说明真正的性能瓶颈。

8. 第六组：SM Clock

对应：

DCGM_FI_DEV_SM_CLOCK

DCGM Exporter 默认启用。(NVIDIA Docs)

它对应 GPU SM 的实际运行频率。

例如：

GPU0  1800 MHz
GPU1  1800 MHz
GPU2   900 MHz
GPU3  1800 MHz

如果四张 GPU 执行相同训练任务：

GPU2 就非常可疑。

但 Clock 本身仍然不是根因。

正确的分析是：

Clock降低
    │
    ├── Temperature高？
    ├── Power limit？
    ├── Reliability限制？
    └── 其他throttling？

所以 Clock 是一个非常重要的症状指标。

9. 第七组：Thermal

基本温度：

DCGM_FI_DEV_GPU_TEMP

默认 collector 会暴露。(NVIDIA Docs)

更重要的是：

DCGM_FI_DEV_THERMAL_VIOLATION

它记录 GPU 因 thermal constraint 受到影响的累计时间，目前属于 Exporter shipped optional metric。DCGM 同时还提供 power、reliability、board limit 等 violation 计数。(NVIDIA Docs)

因此不建议只写一个：

DCGM_FI_DEV_GPU_TEMP > 85

然后就下结论：

GPU 热降频。

更加可靠的判断应该是：

Temperature ↑
       +
SM Clock ↓
       +
Thermal Violation 增长
       +
训练 throughput ↓

这样才能形成：

温度异常
   ↓
硬件触发热限制
   ↓
Clock下降
   ↓
单卡变慢
   ↓
整个DP/TP训练step被拖慢

这才是训练集群里真正有价值的因果链。

10. 第八组：Power

Exporter 默认提供：

DCGM_FI_DEV_POWER_USAGE

对应当前 board power 字段语义。(NVIDIA Docs)

此外可以开启：

DCGM_FI_DEV_POWER_VIOLATION

它记录 power constraint 对 GPU 的影响时间。(NVIDIA Docs)

功耗指标不能简单理解成：

功耗越高越好

真正有意义的是和：

GPU Util
Tensor Active
SM Clock

一起看。

例如：

GPU Util       99%
Tensor Active  90%
Clock          正常
Power          高

通常：

GPU 正在执行高强度计算。

而：

GPU Util       99%
Tensor Active  90%
Clock          明显降低
Power Violation持续增长

则说明：

workload 想继续跑，但 GPU 被 power constraint 限制了。

11. 第九组：PCIe——Host 与 GPU 之间的数据入口

PCIe 是训练节点非常重要的一条数据路径：

Storage / Network
       │
       ▼
      CPU
       │
       ▼
   Host Memory
       │
       ▼
      PCIe
       │
       ▼
     GPU HBM

当前 DCGM Exporter 默认使用 profiling 字段：

DCGM_FI_PROF_PCIE_TX_BYTES
DCGM_FI_PROF_PCIE_RX_BYTES

旧的：

DCGM_FI_DEV_PCIE_TX_THROUGHPUT
DCGM_FI_DEV_PCIE_RX_THROUGHPUT

已经被 NVIDIA 标记为 deprecated，并推荐使用 profiling byte 字段。(NVIDIA Docs)

Prometheus：

DCGM_FI_PROF_PCIE_RX_BYTES

DCGM_FI_PROF_PCIE_TX_BYTES

这里特别需要注意方向。

从 GPU 视角：

RX

表示 GPU 接收数据。

所以训练输入：

CPU RAM → GPU

通常主要反映到 GPU RX。

如果出现：

GPU Util        ↓
Tensor Active   ↓
PCIe RX         高

有可能 GPU 正在大量搬数据，计算却没有跟上。

但如果：

GPU Util        ↓
PCIe RX         ↓
CPU             100%

则更像：

Host 数据根本没有准备出来。

12. PCIe Link Width / Generation

这一组非常容易被普通监控系统忽略。

DCGM 提供：

DCGM_FI_DEV_PCIE_MAX_LINK_GEN
DCGM_FI_DEV_PCIE_MAX_LINK_WIDTH

DCGM_FI_DEV_PCIE_LINK_GEN
DCGM_FI_DEV_PCIE_LINK_WIDTH

分别表示理论最大能力与当前 PCIe link generation / width。(NVIDIA Docs)

假设：

MAX:
Gen5 x16

Current:
Gen5 x16

正常。

但是出现：

MAX:
Gen5 x16

Current:
Gen1 x8

就必须调查。

可能涉及：

PCIe slot
BIOS
riser
主板
GPU
PCIe link training

这是一类：

GPU 完全没有坏，但是性能明显下降。

特别典型的硬件问题。

13. PCIe Replay Counter

对应：

DCGM_FI_DEV_PCIE_REPLAY_COUNTER

Exporter 兼容名对应 canonical：

DCGM_FI_DEV_PCIE_REPLAY_TOTAL

DCGM 将其定义为 PCIe replay counter，并且 DCGM stats/health 体系也会使用 PCIe replay 作为异常观察对象。(NVIDIA Docs)

简单理解：

PCIe 数据传输如果发生链路层问题：

Packet传输
   ↓
出现异常
   ↓
Replay
   ↓
重新发送

所以：

Replay Counter持续增长

往往比单纯：

PCIe throughput下降

更值得怀疑硬件链路问题。

PromQL：

increase(
  DCGM_FI_DEV_PCIE_REPLAY_COUNTER[5m]
)

如果：

> 0 并持续增长

就值得进一步调查。

14. 第十组：NVLink / NVSwitch

到了多 GPU 训练，NVLink 的重要性会迅速提升。

数据路径：

GPU0
 │
 │ NVLink
 ▼
NVSwitch
 │
 │
 ▼
GPU1

DCGM 现在提供：

DCGM_FI_DEV_NVLINK_THROUGHPUT_L0
...
DCGM_FI_DEV_NVLINK_THROUGHPUT_L17

DCGM_FI_DEV_NVLINK_THROUGHPUT_TOTAL

以及 replay、recovery、CRC 等各种 error counters。(NVIDIA Docs)

值得注意的是，2026 年 DCGM 已将这些字段规范为 THROUGHPUT，旧的 BANDWIDTH 名称继续作为兼容 alias 存在；当前 DCGM Exporter 的默认配置仍可能暴露：

DCGM_FI_DEV_NVLINK_BANDWIDTH_TOTAL

但它映射到 canonical：

DCGM_FI_DEV_NVLINK_THROUGHPUT_TOTAL

(NVIDIA Docs)

15. NVLink Error 为什么特别重要

DCGM 提供：

CRC FLIT ERROR
CRC DATA ERROR
REPLAY ERROR
RECOVERY ERROR
NVLINK_ERROR

等多个层次的 NVLink 错误统计。(NVIDIA Docs)

这意味着可以区分：

通信忙

和：

通信链路不健康

例如：

NVLink throughput 高
errors 不增长

可能只是正常 AllReduce。

但是：

NVLink throughput ↓
Replay Error ↑
Recovery Error ↑

则应该立即怀疑：

GPU-GPU fabric 存在异常。

如果与此同时：

NCCL latency ↑
training step time ↑

那么因果链就非常完整了：

NVLink异常
    ↓
通信效率下降
    ↓
NCCL collective变慢
    ↓
其他GPU等待
    ↓
training step变慢

16. 第十一组：ECC

ECC 不属于性能指标，而属于 RAS/硬件健康指标。

DCGM 提供了非常细的 ECC 字段。

最基本的是：

DCGM_FI_DEV_ECC_SBE_VOL_TOTAL
DCGM_FI_DEV_ECC_DBE_VOL_TOTAL

DCGM_FI_DEV_ECC_SBE_AGG_TOTAL
DCGM_FI_DEV_ECC_DBE_AGG_TOTAL

其中 SBE 是 single-bit，DBE 是 double-bit；DCGM 同时还细分到了 L1、L2、Device Memory、Register File 等硬件位置。AGG 计数是持久累计并单调增加的。(NVIDIA Docs)

硬件结构可以理解成：

GPU
 │
 ├── Register File
 ├── L1
 ├── L2
 └── HBM

这些地方都可能出现 ECC error。

所以：

ECC Error

并不是简单等于：

显存坏了。

DCGM 的细分指标可以帮助定位错误来源。

17. ECC 告警不要只看当前值

对于 Counter，正确的问题不是：

现在是不是 > 0

而是：

最近是不是产生了新的错误。

例如：

increase(
  DCGM_FI_DEV_ECC_DBE_VOL_TOTAL[10m]
) > 0

相比：

DCGM_FI_DEV_ECC_DBE_VOL_TOTAL > 0

更适合实时告警。

因为 cumulative counter 可能之前已经发生过错误，之后一直保持：

这不代表每一分钟都发生了新错误。

18. 第十二组：Xid Error

Exporter 默认提供：

DCGM_FI_DEV_XID_ERRORS

它映射到当前 canonical：

DCGM_FI_DEV_XID_ERROR

DCGM 将该字段定义为具体的 XID error value。(NVIDIA Docs)

Xid 很重要，因为它是：

NVIDIA 驱动发现 GPU/硬件/软件异常后的核心错误体系之一。

所以训练集群中通常同时建设：

DCGM metric
     +
kernel log

例如：

Prometheus
   │
   └── DCGM_FI_DEV_XID_ERRORS

Loki / ELK
   │
   └── NVRM: Xid ...

指标负责：

哪张卡出现 Xid？

日志负责：

发生了什么具体错误？

19. 把这些指标组合起来，才开始真正做 GPU SRE

现在可以建立第一套“指标矩阵”。

硬件问题	GPU Util	Tensor	DRAM	PCIe	Clock	Temp	ECC/Xid
正常计算饱和	高	高	中高	正常	正常	正常	0
HBM bandwidth瓶颈	高	中低	高	正常	正常	正常	0
Host供数不足	低	低	低	低/间歇	正常	正常	0
PCIe瓶颈	低/波动	低	低/波动	高	正常	正常	0
热降频	高	高/中	正常	正常	低	高	0
硬件异常	波动	波动	波动	异常	异常	异常	ECC/Xid增加

注意，这张表不是严格诊断规则，而是一套假设生成模型。

例如看到：

GPU Util ↓
Tensor ↓

不能直接说：

数据加载慢。

只能说：

GPU 计算没有得到持续供应，接下来检查 HBM、PCIe、CPU、存储和通信。

这才是可靠的运维思维。

20. Prometheus 中建议优先建立的 GPU Dashboard

不要一开始做几十个 Panel。

第一版 Grafana 建议按硬件链路组织：

第一行：训练计算
GPU Util
Tensor Active
GR Engine Active

第二行：显存
FB Used
FB Usage %
DRAM Active

第三行：硬件性能状态
SM Clock
Memory Clock
Power
Temperature

第四行：I/O
PCIe RX
PCIe TX
PCIe Replay

第五行：GPU互联
NVLink throughput
NVLink errors

第六行：健康
ECC
Xid
Thermal violation
Power violation

这样出现：

训练吞吐量下降

时，排查过程应按照：

计算
 ↓
显存
 ↓
Clock/Power/Thermal
 ↓
PCIe
 ↓
NVLink
 ↓
RAS

逐层定位，而不是面对 40 张彼此没有关系的折线图。

21. 在 Kubernetes 里还必须给 GPU 指标关联 Pod

单纯看到：

gpu="3"

实际生产意义有限。

真正需要的是：

Node
 ↓
GPU UUID
 ↓
GPU index
 ↓
Pod
 ↓
Namespace
 ↓
Container
 ↓
Job

DCGM Exporter 能结合 Kubernetes 的 workload 资源信息进行 GPU metric 关联；当前 GPU Operator 还可以选择把 Pod label 添加为 Prometheus labels，不过 NVIDIA 明确提醒这是可配置功能，因为 Pod label 会增加 metric label dimensions。(NVIDIA Docs)

最终需要形成：

DCGM_FI_DEV_GPU_UTIL{
  namespace="llm-training",
  pod="llama-train-worker-17",
  gpu="3",
  UUID="GPU-..."
}

那么告警：

GPU3利用率异常

才能真正变成：

llama-train-worker-17 使用的 GPU3 出现性能异常。

22. 采样频率怎么设计

GPU telemetry 和 CPU 内存有一个明显区别：

GPU workload 的行为变化非常快。

例如一次训练 iteration：

0~600 ms       GEMM
600~800 ms     AllReduce
800~1400 ms    GEMM
1400~1600 ms   AllReduce

如果：

scrape_interval = 30s

很多短时性能特征会完全消失。

NVIDIA 的当前 DCGM Exporter/Kubernetes 文档支持把 collection interval 设置为 1000 ms，并且 NVIDIA 还提供了 1 秒 GPU telemetry 的 SRE 场景。(NVIDIA Docs)

但这不代表：

所有 GPU、所有指标永久 1 秒保存。

大型集群中建议区分：

类型	典型采样思路
GPU Util / Tensor / DRAM	较高频
PCIe / NVLink 性能	较高频
Temperature / Power	中等
显存容量	中等
ECC / Xid	中低频也可，但告警优先级高
静态拓扑信息	低频

具体频率最终要根据：

GPU数量
×
指标数量
×
label基数
×
保存时间

计算 Prometheus 的时序数量和存储成本，而不是机械地把所有东西都改成 1 秒。

23. 训练集群 GPU 告警不应只依据利用率阈值

第一批真正有运维价值的告警更应该是：

DBE产生新错误
Xid出现
PCIe Replay异常增长
NVLink error增加
GPU温度异常 + thermal violation
Clock异常下降
某张GPU持续显著慢于同任务其他GPU
GPU显存持续异常增长
训练任务GPU长期低利用率

其中最后两项已经从：

hardware health monitoring

进入了：

performance monitoring。

而再往前一步：

GPU metric
+
CPU metric
+
Storage metric
+
RDMA/NCCL metric
+
training step/tokens metric

就进入真正的：

训练集群可观测性与 AIOps。

23.1. 到这里，应当形成一个重要认识

DCGM 的这些指标其实不是一堆孤立数字。

它们实际上在描述 GPU 内部的一条工作链路：

CPU / Storage
      │
      ▼
     PCIe
      │
      ▼
     HBM
      │
      ▼
Memory Controller
      │
      ▼
      SM
   ┌──┴───────┐
   ▼          ▼
CUDA        Tensor
Core         Core
   │
   └────┬─────┘
        │
        ▼
     计算结果
        │
        ▼
NVLink / NVSwitch
        │
        ▼
      其他GPU

与此同时，整个计算过程受到：

Power
Temperature
Clock
ECC
Xid

这套硬件控制与可靠性体系约束。

所以 GPU 排障本质上是在回答：

数据目前走到这条链路的哪一层被卡住了？

掌握这个以后，再看到：

DCGM_FI_PROF_DRAM_ACTIVE

分析对象不应停留在单个 Prometheus 指标，而应扩展为：

HBM/Memory Controller 这一层的数据供应压力。

看到：

DCGM_FI_PROF_PCIE_RX_BYTES

想到的是：

Host 到 GPU 的数据通道。

看到：

DCGM_FI_DEV_THERMAL_VIOLATION

想到的是：

GPU 的硬件热管理机制已经开始干预正常计算。

这才是从“会看 Grafana”进入 GPU Infra / GPU SRE 的分界线。

在实际故障场景中，例如 “8 卡训练任务 tokens/s 突然下降 30%”，可以按照 训练指标 → GPU → HBM → PCIe → NVLink/NCCL → CPU/存储 的顺序逐层排查，将各类指标组合为完整诊断链路。

关联文档

DCGM 完整深度详解：理解 DCGM 的整体架构、组件与字段体系。

GPU监控指标：从 GPU 硬件层面建立完整的监控指标分类。

PromQL：使用 PromQL 聚合 GPU 指标并构建告警规则。

YancheBlog

热门标签

DCGM Exporter 指标级别的工程化

DCGM Exporter 指标级别的工程化

1. 先理解 DCGM Exporter 到底采集了什么

2. 第一组：`DCGM_FI_DEV_GPU_UTIL`

3. 第二组：Tensor Core 利用情况

4. 第三组：Graphics/Compute Engine Active

5. 第四组：显存容量——`FB_USED / FREE / RESERVED`

6. 第五组：`DCGM_FI_PROF_DRAM_ACTIVE`

7. Compute-bound 和 Memory-bound 怎么区分

7.1. Compute-bound

7.2. Memory-bound

8. 第六组：SM Clock

9. 第七组：Thermal

10. 第八组：Power

11. 第九组：PCIe——Host 与 GPU 之间的数据入口

12. PCIe Link Width / Generation

13. PCIe Replay Counter

14. 第十组：NVLink / NVSwitch

15. NVLink Error 为什么特别重要

16. 第十一组：ECC

17. ECC 告警不要只看当前值

18. 第十二组：Xid Error

19. 把这些指标组合起来，才开始真正做 GPU SRE

20. Prometheus 中建议优先建立的 GPU Dashboard

21. 在 Kubernetes 里还必须给 GPU 指标关联 Pod

22. 采样频率怎么设计

23. 训练集群 GPU 告警不应只依据利用率阈值

23.1. 到这里，应当形成一个重要认识

目录

YancheBlog

热门标签

DCGM Exporter 指标级别的工程化

1. 先理解 DCGM Exporter 到底采集了什么

2. 第一组：DCGM_FI_DEV_GPU_UTIL

3. 第二组：Tensor Core 利用情况

4. 第三组：Graphics/Compute Engine Active

5. 第四组：显存容量——FB_USED / FREE / RESERVED

6. 第五组：DCGM_FI_PROF_DRAM_ACTIVE

7. Compute-bound 和 Memory-bound 怎么区分

7.1. Compute-bound

7.2. Memory-bound

8. 第六组：SM Clock

9. 第七组：Thermal

10. 第八组：Power

11. 第九组：PCIe——Host 与 GPU 之间的数据入口

12. PCIe Link Width / Generation

13. PCIe Replay Counter

14. 第十组：NVLink / NVSwitch

15. NVLink Error 为什么特别重要

16. 第十一组：ECC

17. ECC 告警不要只看当前值

18. 第十二组：Xid Error

19. 把这些指标组合起来，才开始真正做 GPU SRE

20. Prometheus 中建议优先建立的 GPU Dashboard

21. 在 Kubernetes 里还必须给 GPU 指标关联 Pod

22. 采样频率怎么设计

23. 训练集群 GPU 告警不应只依据利用率阈值

23.1. 到这里，应当形成一个重要认识

目录

2. 第一组：`DCGM_FI_DEV_GPU_UTIL`

5. 第四组：显存容量——`FB_USED / FREE / RESERVED`

6. 第五组：`DCGM_FI_PROF_DRAM_ACTIVE`