状态：草案（2026-10-05，2026-10-09 更新），已反映实测结果。 指标列表、数值、标签和日志均从实验环境的 dcgm-exporter 中只读获取。对指标含义的补充说明基于 NVIDIA DCGM 和 dcgm-exporter 文档，撰写本文时未重新打开文档进行核对（未确认）。未执行 PromQL 示例（未执行）。编写规则：以实测数据为基础，未测出的内容标记为“未实测”。
目录
- 1. 架构与实验环境配置
- 2. 实际输出的 18 个指标
- 3. 标签
- 4. 通过标签揭示的差异与观察
- 5. 未输出的指标及其原因
- 6. 查询示例（未执行）
- 7. 面试可能遇到的问题
- 8. 常见误区
- 外部依据：通过官方文档和源码确认的内容
- 未确认的内容
- 参考资料
- 确认的版本与日期
1. 架构与实验环境配置
DCGM（Data Center GPU Manager）是 NVIDIA 的 GPU 管理与监控库，而 dcgm-exporter 是将 DCGM 读取的值以 Prometheus 格式导出的程序。其数据流向为：“GPU 驱动 (NVML) → DCGM → dcgm-exporter (HTTP 9400) → Prometheus”。
实验环境配置如下。
| 项目 | 值 |
|---|---|
| 镜像 | nvcr.io/nvidia/k8s/dcgm-exporter:4.5.3-4.8.2-distroless |
| 部署方式 | GPU Operator 的 DaemonSet |
| 服务 | nvidia-dcgm-exporter ClusterIP，端口 9400 |
| 采集列表 | 环境变量 DCGM_EXPORTER_COLLECTORS=/etc/dcgm-exporter/dcp-metrics-included.csv |
| Kubernetes 集成 | DCGM_EXPORTER_KUBERNETES=true |
2. 实际输出的 18 个指标
在一款 8GB 级笔记本 GPU 的 54 行输出中包含了 18 个指标，同一代次的其他笔记本 GPU 也输出了相同的 18 个指标。下表中的数值是该 GPU 处于空闲状态时的示例值。其含义基于指标的 HELP 文本和 DCGM 文档。
2.1 时钟、温度、功耗
| 指标 | 类型 | 单位 | 含义 | 示例值 |
|---|---|---|---|---|
DCGM_FI_DEV_SM_CLOCK |
gauge | MHz | SM（流式多处理器）时钟 | 210 |
DCGM_FI_DEV_MEM_CLOCK |
gauge | MHz | 显存时钟 | 8001 |
DCGM_FI_DEV_GPU_TEMP |
gauge | ℃ | GPU 温度 | 40 |
DCGM_FI_DEV_MEMORY_TEMP |
gauge | ℃ | 显存温度 | 0 |
DCGM_FI_DEV_POWER_USAGE |
gauge | W | 瞬时功耗 | 1.22 |
DCGM_FI_DEV_TOTAL_ENERGY_CONSUMPTION |
counter | mJ | 开机后的累计能耗 | 8,447,476,600 |
- 所有观察到的 GPU 的显存温度均为 0。 这似乎并不意味着指标代表“0℃”，而是这些 GPU 没有提供该数值，但原因尚未确认。在设置告警条件时，不能将 0 视为正常值。
- 累计能耗是一个计数器。 不能直接查看其绝对值，而应查看其增量。由于单位是 mJ，将
rate()除以 1000 即可得到平均瓦特数。例如，上述示例中累计的 8,447,476,600mJ 约为 2.3kWh（开机后）。 - 空闲时钟较低。 在观察到的所有 GPU 处于空闲状态时，SM 时钟均为 210MHz。
2.2 利用率
| 指标 | 类型 | 单位 | 含义 | 示例值 |
|---|---|---|---|---|
DCGM_FI_DEV_GPU_UTIL |
gauge | % | 在采样周期内至少有一个内核处于运行状态的时间比例 | 0 |
DCGM_FI_DEV_MEM_COPY_UTIL |
gauge | % | 内存控制器用于读写操作的时间比例 | 0 |
DCGM_FI_DEV_ENC_UTIL |
gauge | % | 视频编码器利用率 | 0 |
DCGM_FI_DEV_DEC_UTIL |
gauge | % | 视频解码器利用率 | 0 |
GPU_UTIL 最大的一大陷阱是其名称给人带来的直观印象。 该值并不是指“SM 的饱和程度”，而是指“至少有一个内核在运行的时间比例”（根据文档标准）。如果一个小型内核持续运行，即使大部分 SM 处于空闲状态，该值也会达到 100%。因此，仅凭该值无法得知 LLM 推理服务中的 GPU 是否真正饱和。正如第 5 节所示，此实验环境中的 GPU 无法获取更准确的指标（性能分析）。
2.3 内存
| 指标 | 单位 | 含义 | 示例值（8GB 级笔记本 GPU） |
|---|---|---|---|
DCGM_FI_DEV_FB_USED |
MiB | 正在使用的帧缓冲区 | 12 |
DCGM_FI_DEV_FB_FREE |
MiB | 空闲的帧缓冲区 | 7,795 |
DCGM_FI_DEV_FB_RESERVED |
MiB | 驱动程序预留的区域 | 380 |
将这三个值相加即为 GPU 的总内存。 上述示例中为 12 + 7,795 + 380 = 8,187MiB，同级别的其他显卡为 8,186MiB，24GB 级消费级 GPU 则为 24,575MiB，分别符合 8GiB 级和 24GiB 级显卡。因此，在计算利用率时，分母应使用 USED + FREE 而不是 USED + FREE + RESERVED 这样才准确。预留区域是模型无法使用的空间。
2.4 错误与可靠性
| 指标 | 类型 | 含义 | 值 |
|---|---|---|---|
DCGM_FI_DEV_PCIE_REPLAY_COUNTER |
counter | PCIe 重传累计次数 | 0 |
DCGM_FI_DEV_UNCORRECTABLE_REMAPPED_ROWS |
counter | 因不可纠正错误而重新映射的内存行数 | 0 |
DCGM_FI_DEV_CORRECTABLE_REMAPPED_ROWS |
counter | 因可纠正错误而重新映射的内存行数 | 0 |
DCGM_FI_DEV_ROW_REMAP_FAILURE |
gauge | 行重新映射是否失败（0 为正常） | 0 |
DCGM_FI_DEV_VGPU_LICENSE_STATUS |
gauge | vGPU 许可状态 | 0 |
- 如果 PCIe 重传次数增加， 则需要怀疑链路质量问题。PCIe 链路宽度降低是一个典型的排查对象。
- 行重新映射指标因 GPU 而异。 在 Ada 代次的笔记本 GPU 上输出了全部三个指标，但在 24GB 级消费级 GPU 上这三个指标被从输出中移除，仅输出了 15 个指标。如果 GPU 不支持相应的值，导出器似乎就不会输出该指标，但确切的规则尚未确认。
ROW_REMAP_FAILURE如果 为 1，则在数据中心 GPU 上它是考虑进行更换的信号（根据文档标准）。所观察到的 GPU 全部为 0。
3. 标签
所有指标都附加了相同的标签。
| 标签 | 值示例 | 用途 |
|---|---|---|
gpu |
0 |
节点内的 GPU 编号 |
UUID |
GPU-… |
永久区分 GPU（追踪更换情况） |
pci_bus_id |
00000000:01:00.0 |
物理位置 |
device |
nvidia0 |
设备节点 |
modelName |
GPU 模型名称 | 模型 |
Hostname |
节点名称 | 节点 |
DCGM_FI_DRIVER_VERSION |
595.91.07 |
驱动版本 |
如果有正在使用 GPU 的 Pod，则会添加 container, namespace, pod 标签。已确认在拥有使用 GPU 的 Pod 的 GPU 上附加了这三个标签。这三项内容从 kubelet 的 pod-resources 套接字获取，如果 GPU 为空闲状态，则不会附加。
若要附加 Pod 的自定义标签，导出器需要具有读取 API Server 的权限。 在实验环境中，导出器无法在集群内部访问 API Server，并且日志中留下了 Failed to get in-cluster config, pod labels will not be available 。这意味着若要按团队或项目统计 Pod 标签对应的成本，必须授予导出器读取 API Server 的权限，但我并未进行此类更改（未测试）。
标签值的种类与 GPU 数量成正比，因此该指标的基数（Cardinality）较小。这与下一篇文章（Cilium 指标）中的 Hubble 形成了对比。
4. 通过标签揭示的差异与观察
- 同一个集群中可能会混杂不同的驱动版本，这一事实会通过
DCGM_FI_DRIVER_VERSION标签直接显现出来。 在实验环境中，同时存在 595.91.07 和 570.195.03 两个版本。这并非意味着它是问题的根源，而是指在进行升级或故障排查时需要优先筛查的变量。 - 不同 GPU 模型的空闲功耗各不相同。 8GB 级笔记本 GPU 的空闲功耗为 1.22W，而 24GB 级消费级 GPU 即使在空闲时也会消耗 21.1W。
5. 未输出的指标及其原因
导出器的启动日志中直接保留了原因（8GB 级笔记本 GPU，2026-09-23）。
Not collecting DCP metrics: Profiling is not supported for this group of GPUs or GPU
Skipping line 21 ('DCGM_FI_PROF_GR_ENGINE_ACTIVE'): metric not enabled
Skipping line 22 ('DCGM_FI_PROF_PIPE_TENSOR_ACTIVE'): metric not enabled
Skipping line 23 ('DCGM_FI_PROF_DRAM_ACTIVE'): metric not enabled
Skipping line 24 ('DCGM_FI_PROF_PCIE_TX_BYTES'): metric not enabled
Skipping line 25 ('DCGM_FI_PROF_PCIE_RX_BYTES'): metric not enabled
Not collecting NvSwitch metrics; no switches to monitor
Not collecting CPU metrics; ... DCGM module that is not currently loaded
| 缺失指标 | 含义 | 在此环境中缺失的原因 |
|---|---|---|
DCGM_FI_PROF_GR_ENGINE_ACTIVE |
图形引擎处于活动状态的时间比例 | 此 GPU 系列不支持性能分析（日志） |
DCGM_FI_PROF_PIPE_TENSOR_ACTIVE |
张量核心处于活动状态的比例 | 同上 |
DCGM_FI_PROF_DRAM_ACTIVE |
内存接口处于活动状态的比例 | 同上 |
DCGM_FI_PROF_PCIE_TX/RX_BYTES |
PCIe 收发字节数 | 同上 |
| NVSwitch、NVLink 指标 | 交换机与链路状态 | 无交换机（日志） |
| 主机 CPU 指标 | CPU 核心状态 | 未加载 DCGM 模块（日志） |
在 LLM 推理服务运维中最令人遗憾的是性能分析（Profiling）指标。 必须了解张量核心活动比例和 DRAM 活动比例，才能区分“到底是计算成为瓶颈，还是内存带宽成为瓶颈”，但在这些消费级笔记本 GPU 上无法获取这些指标。2026-10-09，我连同桌面端 24GB 级 GPU 一起重新进行了确认。仅通过 API 代理读取了集群中五张 GPU（四种型号：两代笔记本 GPU 和一张桌面端 GPU）的收集器输出，结果发现以 DCGM_FI_PROF_ 开头的行在全部五张卡上都是 0 个。并不是说桌面端 GPU 就一定会输出。指标的种类也不尽相同。最新一代笔记本 GPU 有 18 种，上一代的笔记本和桌面端 GPU 有 15 种，缺少的三个是行重映射指标（DCGM_FI_DEV_CORRECTABLE_REMAPPED_ROWS, ..._UNCORRECTABLE_REMAPPED_ROWS, DCGM_FI_DEV_ROW_REMAP_FAILURE）。NVIDIA 文档针对消费级、工作站级等非数据中心 GPU 仅标注了“limited DCGM functionality”，且功能表（Features Supported on Different GPU Products）中也没有性能分析这一行，因此无法从文档中区分究竟哪些产品会输出该指标。至于数据中心 GPU 是否真的会输出，由于没有设备，仍然是 未实测 。
XID 错误指标以及功耗与温度超限违规指标不在此输出中。 日志的跳过列表中也没有。起初推测所使用的收集列表中原本就没有 XID，但通过外部资料确认该推测是错误的。此 Pod 的配置是 DCGM_EXPORTER_COLLECTORS=/etc/dcgm-exporter/dcp-metrics-included.csv，镜像标签是 4.5.3-4.8.2-distroless ，而在上游仓库的同标签文件中（原文已确认）， DCGM_FI_DEV_XID_ERRORS 作为活动行（去除注释后的序号 11）被包含在内。同一文件中的五个 PROF 行与日志中的从“Skipping line 21”到“line 25”完全重合，我们看到的 18 个指标正好等于该文件活动 26 行减去 XID、NVLink 带宽以及五个 PROF 行。因此， 它似乎存在于列表中，但在此 GPU 上没有输出对应的值（推测。如果 DCGM 返回空值，导出器源码会跳过该指标。未能打开运行中的文件查看（distroless），目前 DCGM_FI_DEV_XID_ERRORS 系列行为 0 个）。功耗与温度超限违规指标在上游文件中被注释掉了，因此原本就不在列表中。目前只能通过内核日志（NVRM: Xid）来确认 XID，该流程将在第 11 篇中继续探讨。
6. 查询示例（未执行）
这是未在实际 Prometheus 中执行的示例。指标名称和单位已与上述实测保持一致。
# 평균 전력(W): 누적 에너지(mJ)의 증가율을 1000 으로 나눈다
rate(DCGM_FI_DEV_TOTAL_ENERGY_CONSUMPTION[5m]) / 1000
# 메모리 사용률: 분모에 예약 영역까지 포함한다
DCGM_FI_DEV_FB_USED / (DCGM_FI_DEV_FB_USED + DCGM_FI_DEV_FB_FREE + DCGM_FI_DEV_FB_RESERVED)
# 알림 후보
DCGM_FI_DEV_ROW_REMAP_FAILURE > 0
increase(DCGM_FI_DEV_PCIE_REPLAY_COUNTER[1h]) > 0
7. 面试可能遇到的问题
GPU_UTIL如果 为 100%，是否意味着 GPU 已饱和？ 不是。由于这是指至少有一个内核在运行的时间比例，它与 SM 占用率或张量核心的使用无关。- 如何通过指标判断是计算瓶颈还是内存瓶颈？ 通过性能分析指标（张量活动比例、DRAM 活动比例）。在不支持的 GPU 上，只能通过服务指标（每个 Token 的时间、批次大小）进行间接推测。
- 在哪里查看 XID？ 默认通过内核日志查看，如果在收集列表中添加相应字段，也可以作为指标来查看。
- 在同一个集群中，驱动程序版本不同时会产生什么问题？ CUDA 兼容性、容器工具包和错误行为可能会有所不同，因此必须在故障排查时首先进行排查。
8. 常见误解
- “内存温度为 0 是正常的”：可能根本没有该数值。
- 「
FB_USED + FB_FREE是全部内存”：保留区域是独立存在的。 - “只要启动 exporter 就能获取所有指标”：这取决于 GPU 系列和采集列表。在此实验环境中共有 18 个。
外部依据：通过官方文档和源码确认的内容
| 主题 | 资料与确认位置 | 确认的内容 | 与本文的关系 |
|---|---|---|---|
| 无法获取性能剖析（Profiling）指标的原因 | DCGM Feature Overview（支持的产品表）、dcgm-exporter default-counters.csv 注释与源码（pkg/cmd/app.go, fieldIsSupported) |
性能剖析指标仅在数据中心级 Volta 及以上架构中支持。exporter 在启动时会向 DCGM 查询是否支持性能剖析，如果失败则会记录「Not collecting DCP metrics」，并将 PROF 行标记为「metric not enabled」后跳过 | 支持。 与本文看到的日志措辞一致 |
| 消费级 GPU 的 DCGM 功能 | 同一张表 | 消费级产品系列支持字段值监视、配置管理、健康检查、作业统计和拓扑，但策略通知仅在 Tesla 上支持，诊断仅支持级别 1 | 支持。 与“功能受限”的描述一致 |
| 无法获取 XID 指标的原因 | dcgm-exporter 上游 dcp-metrics-included.csv（标签 4.5.3-4.8.2） |
DCGM_FI_DEV_XID_ERRORS 是活动行，且 PROF 的五行顺序与日志完全重合 |
反驳（原本的推测）。 修正为：并非不在列表中，而是没有输出数值 |
未能确认的事项
- 时间序列的时间变化。本文中的数值全部为某一时刻的快照，未测量负载情况下的数值。
- 内存温度为 0 的原因，以及在 24GB 级消费级 GPU 中缺少行重排指标的确切规则。
- 正在使用的
dcp-metrics-included.csv的运行内容（镜像中没有 shell，无法打开。改用上游相同标签的文件进行确认，未确认 XID 数值不输出的确切原因）。 - 未重新打开并对照引用的 DCGM 文档来补充说明指标的含义。
- 当赋予 exporter API 服务器读取权限时，Pod 标签是否实际附加成功。
参考资料
- https://github.com/NVIDIA/dcgm-exporter
- https://docs.nvidia.com/datacenter/dcgm/latest/
确认的版本与日期
基于 2026-10-05。dcgm-exporter 4.5.3-4.8.2，驱动程序 595.91.07 与 570.195.03。