大模型推理生产环境GPU可观测性实战：DCGM + Prometheus + Grafana 完整监控体系搭建指南

Table of Contents

为什么大模型生产环境需要专业的GPU监控？

在AI基础设施（AI Infra）的日常运维中，GPU监控与可观测性往往是最容易被忽视的一环。很多团队在部署大模型推理服务时，只关注模型的推理延迟和吞吐量，却忽略了GPU本身的健康状态、功耗曲线、内存带宽利用率等关键指标。这就像开车只看车速表而忽略发动机温度——等到GPU出现ECC错误、NVLink带宽下降或显存老化问题时，往往已经对服务质量造成了实质影响。

事实上，在大模型推理生产环境中，GPU的异常行为是导致推理质量波动（Token生成速度忽快忽慢）和服务可用性下降的最常见根因之一。本文将从实践角度出发，详细介绍如何利用NVIDIA DCGM（Data Center GPU Manager）、Prometheus和Grafana构建一套完整的GPU可观测性体系。

与以往偏重理论的文章不同，本文会给出完整的配置脚本、告警规则和Dashboard JSON模板，让读者能够直接在生产环境中落地使用。

理解GPU监控的关键指标维度

在搭建监控系统之前，我们首先需要明确：对于大模型推理场景，哪些GPU指标真正有价值？按照重要程度，我们可以将指标分为四个层级：

层级	指标类别	具体指标	大模型场景下的意义
L1 – 生存指标	硬件健康	GPU温度、风扇转速、电源状态、XID错误	GPU硬件是否存活，是否有不可纠正的ECC错误
L2 – 性能指标	计算利用率	GPU利用率、SM占用率、张量核心利用率	推理引擎是否充分利用了GPU算力
L3 – 访存指标	内存子系统	显存使用量、显存带宽利用率、NVLink收发速率	推理瓶颈是算力还是访存（这对Decode阶段至关重要）
L4 – 服务质量	推理质量	TTFT（首Token延迟）、ITL（Token间延迟）、请求排队长度	最终用户体验层面的指标，与GPU指标联动分析

需要特别强调的是，单独看GPU利用率（Utilization）在大模型推理场景下很容易产生误判。由于Decode阶段是访存受限的，GPU计算核心可能大部分时间在等待数据加载，此时GPU利用率看似很低，但系统实际已经达到了性能上限。因此，必须将GPU利用率与显存带宽利用率、SM Active Cycles等指标综合起来分析。

DCGM：NVIDIA官方GPU监控利器

DCGM是什么？

NVIDIA DCGM（Data Center GPU Manager）是NVIDIA官方的GPU集群管理和监控工具集，它通过一套轻量级的Agent（nv-hostengine）在宿主机上采集GPU的遥测数据，并通过与Prometheus兼容的exporter暴露指标。DCGM的主要优势在于：

零侵入性：无需在容器内安装任何Agent，DCGM Exporter通过访问宿主机的NVML（NVIDIA Management Library）获取数据
丰富的指标集：提供超过200个GPU相关的遥测指标
诊断能力：支持GPU健康诊断（dcgm diag），可以执行从Level 0到Level 3不同深度的硬件检测
集群级管理：支持GPU分组、策略管理和事件监控

部署DCGM Exporter

我们使用Docker部署DCGM Exporter，这是最推荐的方式：


1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 拉取官方DCGM Exporter镜像

docker pull nvidia/dcgm-exporter:latest



# 运行DCGM Exporter

docker run -d \

  --name dcgm-exporter \

  --restart unless-stopped \

  --gpus all \

  -p 9400:9400 \

  -v /run/nvidia-smi:/run/nvidia-smi:ro \

  nvidia/dcgm-exporter:latest



# 验证指标端点是否正常

curl -s http://localhost:9400/metrics | head -20

如果使用Kubernetes部署，可以通过DaemonSet来确保每个GPU节点上都有一个DCGM Exporter实例：


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
apiVersion: apps/v1

kind: DaemonSet

metadata:

  name: dcgm-exporter

  namespace: monitoring

spec:

  selector:

    matchLabels:

      app: dcgm-exporter

  template:

    metadata:

      labels:

        app: dcgm-exporter

    spec:

      containers:

      - name: dcgm-exporter

        image: nvidia/dcgm-exporter:latest

        ports:

        - containerPort: 9400

          name: metrics

        volumeMounts:

        - name: nvidia-smi

          mountPath: /run/nvidia-smi

          readOnly: true

        resources:

          limits:

            nvidia.com/gpu: 0  # 不需要分配GPU

      volumes:

      - name: nvidia-smi

        hostPath:

          path: /run/nvidia-smi

自定义DCGM指标配置

DCGM Exporter默认采集的指标集已经足够日常使用，但对于大模型推理场景，我们通常需要额外的指标。可以通过自定义配置文件来扩展：


1
2
3
4
5
6
7
8
9
# /etc/dcgm-exporter/custom.csv

# 格式: "Prometheus Metric Name", "DCGM Field ID", "Type", "Help"

"DCGM_FI_DEV_SM_CLOCK", "1", "gauge", "SM clock frequency (MHz)"

"DCGM_FI_DEV_MEM_CLOCK", "2", "gauge", "Memory clock frequency (MHz)"

"DCGM_FI_DEV_MEMORY_TEMP", "3", "gauge", "Memory temperature (C)"

"DCGM_FI_DEV_NVLINK_BANDWIDTH_TOTAL", "246", "counter", "Total NVLink bandwidth (bytes)"

"DCGM_FI_DEV_NVLINK_CRC_FLIT_ERROR_COUNT", "243", "counter", "NVLink CRC flit error count"

"DCGM_FI_DEV_XID_ERRORS", "70", "gauge", "XID error count (critical for hardware health)"

"DCGM_FI_DEV_RETIRED_PAGES", "117", "gauge", "Retired pages (memory health indicator)"

然后挂载该配置文件启动Exporter：


1
2
3
4
5
6
7
8
docker run -d \

  --name dcgm-exporter \

  --gpus all \

  -p 9400:9400 \

  -v /etc/dcgm-exporter:/etc/dcgm-exporter \

  -v /run/nvidia-smi:/run/nvidia-smi:ro \

  nvidia/dcgm-exporter:latest \

  -f /etc/dcgm-exporter/custom.csv

其中，

1	DCGM_FI_DEV_XID_ERRORS

和

1	DCGM_FI_DEV_RETIRED_PAGES

这两个指标对生产环境至关重要。XID错误是GPU硬件异常的早期信号，而Retired Pages指标显示显存中已经出现永久性坏道的页面数量——这两个指标一旦出现非零值，就应该立即触发告警。

Prometheus采集配置

有了DCGM Exporter暴露的指标端点，接下来我们配置Prometheus进行采集和存储。

Prometheus配置示例


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# prometheus.yml

scrape_configs:

  - job_name: 'dcgm-gpu-metrics'

    scrape_interval: 15s

    scrape_timeout: 10s

    static_configs:

      - targets:

        - 'gpu-node-01:9400'

        - 'gpu-node-02:9400'

        - 'gpu-node-03:9400'

        - 'gpu-node-04:9400'

        labels:

          cluster: 'prod-inference-cluster'



  # 同时采集推理服务的应用层指标

  - job_name: 'vllm-inference-metrics'

    scrape_interval: 10s

    static_configs:

      - targets:

        - 'vllm-svc-01:8000'

        - 'vllm-svc-02:8000'

        labels:

          service: 'vllm-inference'

这里将GPU指标与推理引擎的指标分开采集，但通过Prometheus的label关联起来。vLLM和SGLang都内置了/metrics端点，暴露TTFT、ITL、请求吞吐量等应用层指标，它们与GPU指标的关联分析是最有价值的数据洞察来源。

关键告警规则配置

以下是一组经过生产验证的GPU告警规则：


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
# gpu_alerts.yml

groups:

  - name: gpu_hardware_alerts

    interval: 30s

    rules:

      - alert: GPUHighTemperature

        expr: DCGM_FI_DEV_GPU_TEMP > 85

        for: 5m

        labels:

          severity: warning

        annotations:

          summary: "GPU {{ $labels.gpu }} on {{ $labels.instance }} temperature > 85°C"



      - alert: GPUCriticalTemperature

        expr: DCGM_FI_DEV_GPU_TEMP > 95

        for: 1m

        labels:

          severity: critical

        annotations:

          summary: "GPU {{ $labels.gpu }} temperature > 95°C — immediate cooling required"



      - alert: GPUECCErrorDetected

        expr: increase(DCGM_FI_DEV_ECC_SBE_VOL_TOTAL[5m]) > 10

        for: 1m

        labels:

          severity: warning

        annotations:

          summary: "GPU {{ $labels.gpu }} has >10 single-bit ECC errors in 5 minutes"



      - alert: GPUUncorrectableECC

        expr: increase(DCGM_FI_DEV_ECC_DBE_VOL_TOTAL[5m]) > 0

        for: 1m

        labels:

          severity: critical

        annotations:

          summary: "GPU {{ $labels.gpu }} has uncorrectable ECC errors — recommend replacement"



      - alert: GPUXIDError

        expr: increase(DCGM_FI_DEV_XID_ERRORS[5m]) > 0

        for: 1m

        labels:

          severity: critical

        annotations:

          summary: "GPU {{ $labels.gpu }} encountered XID error — check nvidia-smi logs"



      - alert: GPUMemoryRetired

        expr: DCGM_FI_DEV_RETIRED_PAGES > 0

        for: 5m

        labels:

          severity: warning

        annotations:

          summary: "GPU {{ $labels.gpu }} has {{ $value }} retired memory pages"



      - alert: GPUNVLinkBandwidthDegraded

        expr: rate(DCGM_FI_DEV_NVLINK_BANDWIDTH_TOTAL[5m]) &lt; 10000000000

        for: 10m

        labels:

          severity: warning

        annotations:

          summary: "GPU {{ $labels.gpu }} NVLink bandwidth degraded"

在告警配置中，有几个关键的设计原则需要特别注意：

所有告警都应该设置
1
for

时间（持续时间），避免瞬时抖动导致的误报
ECC单比特错误（SBE）用
1
increase()

函数检查增量而非绝对值——GPU可能长时间累计了大量SBE，但只要增速不高就无需干预
不可纠正的ECC错误（DBE）是零容忍的——任何DBE增量都应立刻触发Critical告警

Grafana可视化面板设计

采集和告警就绪后，我们需要一套直观的Dashboard来展示GPU集群的运行状态。以下是一个面向大模型推理场景的Dashboard设计思路。

Panel 1：GPU集群总览

顶部使用Stat面板展示集群级别的聚合信息：

在线GPU总数 / 异常GPU数
总显存容量 / 已用显存占比
当前活跃XID错误数
集群平均GPU利用率（取加权平均）

PromQL查询示例：


1
2
3
4
5
6
7
8
# 集群GPU总数

count(DCGM_FI_DEV_GPU_UTIL)



# 集群显存使用率

avg(DCGM_FI_DEV_FB_USED / DCGM_FI_DEV_FB_TOTAL) * 100



# 检测到XID错误的GPU数量

count(DCGM_FI_DEV_XID_ERRORS > 0)

Panel 2：按节点的GPU利用率热力图

使用Heatmap面板，X轴为时间，Y轴为GPU ID，颜色深度表示利用率。这张图可以快速发现集群中某个GPU的利用率异常（比如某张卡的利用率明显低于同节点的其他卡，可能意味着模型分布不均或硬件降频）。

Panel 3：推理延迟与GPU指标联动图

将vLLM的ITL（Token间延迟）与GPU的SM Active Cycles和显存带宽利用率叠加在同一张时间序列图上。这是大模型推理调优中最有价值的分析视图：

当ITL增加时，如果显存带宽利用率已接近100%，说明瓶颈在访存，增加GPU算力无法解决问题
如果SM Active Cycles很低但显存带宽利用率很高，说明需要优化Attention算子的访存模式
如果GPU利用率和SM Active Cycles都很低但ITL仍然很高，可能是CPU端的数据预处理或Tokenization成为瓶颈

Panel 4：GPU温度与功耗时序

长时间运行的大模型推理服务中，GPU功耗通常不会很高（推理的功耗远低于训练），但如果发现功耗曲线出现剧烈抖动，往往意味着电源管理策略异常，可能是PCIe供电不足或电源模块老化。将功耗与温度叠加显示，可以判断散热系统是否正常工作。

实战案例：一次GPU性能衰减的排查过程

最后，分享一个真实的排查案例，来展示GPU监控体系的实际价值。

问题现象：某推理集群中一台A100-80G节点的Token生成速度突然下降了约30%，从每天约200万Token降到了140万Token左右。推理引擎日志无明显报错，nvidia-smi显示GPU利用率正常（约65%-75%）。

排查过程：

首先检查GPU温度指标，发现该节点GPU平均温度从65°C上升到了82°C，但未超过85°C的告警阈值
查看显存带宽利用率，发现从基线85%降到了55%——这说明问题出在显存带宽上
进一步检查SM时钟频率（SM Clock），发现SM频率从标准的1410 MHz降到了1215 MHz，降幅约14%
交叉对比功耗数据，发现GPU功耗从标准的300W降到了225W左右

根因：连续高温运行导致GPU触发了自主降频保护（Thermal Throttling）。虽然温度没有触发硬件关机阈值，但GPU的Boost Clock机制已经将频率下调了约200 MHz。这直接导致显存控制器频率同步下降，显存带宽降低，进而引起推理Decode阶段的速度显著变慢。

解决方案：

短期：清理服务器进风口灰尘，检查机房空调是否正常工作
中期：为该节点配置更激情的风扇策略，降低机房温度设定值
长期：在该GPU的DCGM指标中增加SM Clock与基础频率的偏离比例告警，当GPU实际运行频率低于标称频率的95%时自动通知运维团队

如果当时没有部署DCGM + Prometheus监控体系，这个问题的排查可能会耗费数天时间。运维团队可能会怀疑模型代码、网络带宽、推理引擎配置等多个方向，而实际原因仅仅是机房的冷却系统出了点小问题。

总结与最佳实践

构建大模型推理生产环境的GPU可观测性体系，需要注意以下要点：

指标采集层面：不要只采集GPU利用率这一项指标。显存带宽利用率、SM Active Cycles和NVLink吞吐量在推理场景下往往更具分析价值
告警策略层面：可纠正ECC错误（SBE）关注增量速度而非绝对值；不可纠正ECC（DBE）和XID错误必须零容忍；温度告警留足余量（建议Warning设在80°C而非85°C）
可视化层面：将GPU硬件指标与推理引擎应用层指标（TTFT、ITL、吞吐量）关联展示，形成从硬件到业务的完整可观测性链路
自动化层面：配置定期dcgm diag诊断（Level 1级别即可，不影响业务），并将诊断结果写入自定义指标供Prometheus采集

GPU监控不仅仅是”防止宕机”的手段，更是理解大模型推理行为、持续优化服务质量的必备基础设施。一套成熟的GPU可观测性体系，应该能回答三个问题：GPU现在健康吗？推理性能是否达到了硬件应有的水平？如果性能下降，根因在硬件层还是软件层？只有当这三个问题都能实时得到回答时，AI基础设施的运维才算真正达到了生产级标准。

数据中心GPU服务器监控系统可视化