生产环境监控方案，Prometheus 加 Grafana 可视化显卡状态

为什么 SRE 需要关注 AMD GPU 监控

在大模型推理服务逐渐从 NVIDIA 独占转向多元化硬件架构的今天，AMD Instinct 系列显卡凭借高性价比和大显存优势，正成为许多团队的生产首选。然而，对于负责系统稳定性的 SRE 工程师而言，硬件切换带来的最大挑战往往不是算力本身，而是可观测性体系的重建。

传统的 CPU 或通用 GPU 监控方案很难直接覆盖 ROCm 生态下的特有指标。一旦显存泄漏或温度异常未能被及时发现，正在运行的 vLLM 推理服务就可能瞬间崩溃，导致业务中断。因此，构建一套基于 Prometheus 和 Grafana 的专用监控体系，不仅是运维规范的要求，更是保障业务连续性的生命线。本文将结合实战经验，分享如何在 ROCm 7.x 环境下搭建这套监控闭环。

部署 DCGM Exporter 采集核心指标

监控的第一步是数据获取。在 AMD 生态中，DCGM（Data Center GPU Manager）是官方推荐的监控工具链核心。虽然它最初为 NVIDIA 设计，但经过适配后，配合 ROCm 驱动同样能高效采集 Instinct 显卡的关键状态。

首先，确保你的服务器已安装 ROCm 7.x 驱动，并能通过rocm-smi正常查看显卡信息。接下来，我们需要以 Docker 容器方式部署dcgm-exporter，这种方式隔离性好且易于升级。

dockerrun-d--namedcgm-exporter\--restart=unless-stopped\--pid=host\--cap-add SYS_ADMIN\-v/usr/lib/x86_64-linux-gnu/librocm_smi64.so:/usr/lib/x86_64-linux-gnu/librocm_smi64.so\-v/dev/dri:/dev/dri\-p9400:9400\nvcr.io/nvidia/k8s/dcgm-exporter:3.3.6-3.4.0-ubuntu22.04

这里有一个关键细节：AMD 环境需要挂载librocm_smi64.so库文件，否则 exporter 无法识别硬件。启动后，访问http://localhost:9400/metrics，如果能看到类似DCGM_FI_DEV_GPU_TEMP、DCGM_FI_DEV_POWER_USAGE等指标输出，说明数据采集层工作正常。

为了让 Prometheus 能够抓取这些数据，需在prometheus.yml中添加如下配置：

scrape_configs:-job_name:'gpu-monitor'static_configs:-targets:['localhost:9400']metrics_path:/metrics

重启 Prometheus 后，你应当能在查询界面看到来自 Instinct GPU 的实时流数据。

导入 Grafana 面板实现可视化

raw 数据虽然准确，但对人并不友好。Grafana 的价值在于将枯燥的数字转化为直观的图表。社区已有不少适配 DCGM 的通用模板，但针对 AMD 大模型推理场景，建议重点关注以下三个维度的可视化：

1. 显存使用率趋势：这是预防 OOM（内存溢出）的核心指标。
2. GPU 温度与功耗：反映硬件负载与健康度，防止过热降频。
3. SM 利用率：判断计算资源是否被充分调度。

你可以创建一个新 Dashboard，添加 Time Series 面板。以显存为例，PromQL 查询语句可写为：

100 * (DCGM_FI_DEV_FB_USED{gpu_uuid=~".*"} / DCGM_FI_DEV_FB_TOTAL{gpu_uuid=~".*"})

这条语句计算了每张卡的显存占用百分比。为了区分不同显卡，建议在 Legend 中使用{{gpu_uuid}}作为标签。同样的逻辑适用于温度（直接使用DCGM_FI_DEV_GPU_TEMP）和功耗（DCGM_FI_DEV_POWER_USAGE）。

如果你希望快速上手，可以参考以下简化的 JSON 面板配置结构，将其导入 Grafana 即可得到基础视图：

{"dashboard":{"title":"AMD Instinct GPU Monitor","panels":[{"title":"Memory Utilization (%)","targets":[{"expr":"100 * (DCGM_FI_DEV_FB_USED / DCGM_FI_DEV_FB_TOTAL)"}]},{"title":"GPU Temperature (C)","targets":[{"expr":"DCGM_FI_DEV_GPU_TEMP"}]}]}}

实际生产中，建议根据集群规模调整刷新频率，通常设置为 15 秒至 30 秒一次，既能保证实时性，又不会给数据库带来过大压力。

配置告警策略预防服务崩溃

监控的最终目的是发现问题并提前干预。对于运行 vLLM 或 SGLang 的生产环境，显存是最脆弱的环节。一旦显存使用率突破临界值，进程往往会被系统直接 Kill 掉，造成请求中断。

因此，我们需要在 Alertmanager 中配置严格的告警规则。以下是一个典型的告警示例，当任意一张显卡的显存使用率持续 1 分钟超过 95% 时，立即触发通知：

groups:-name:gpu-alertsrules:-alert:HighGPUMemoryUsageexpr:100 * (DCGM_FI_DEV_FB_USED / DCGM_FI_DEV_FB_TOTAL)>95for:1mlabels:severity:criticalannotations:summary:"GPU 显存使用率过高"description:"实例 {{ $labels.instance }} 的 GPU {{ $labels.gpu_uuid }} 显存使用率已达 {{ $value }}%，存在 OOM 风险。"

除了显存，温度告警同样重要。建议将阈值设定在 85°C 左右，因为 AMD Instinct 系列在高温下可能会触发降频保护，导致推理延迟飙升。

-alert:HighGPUTemperatureexpr:DCGM_FI_DEV_GPU_TEMP>85for:2mlabels:severity:warningannotations:summary:"GPU 温度异常"description:"GPU {{ $labels.gpu_uuid }} 温度达到 {{ $value }}°C，请检查散热或负载情况。"

将这些规则加载到 Prometheus 后，务必测试告警通道（如邮件、钉钉或 Slack），确保通知能准确送达值班人员。

让监控成为稳定性的基石

搭建好监控体系只是第一步，更重要的是养成定期复盘的习惯。通过分析历史数据，我们可以发现业务流量的波峰波谷规律，从而优化资源分配策略。例如，若发现某段时间显存长期处于高位，可能需要考虑扩容节点或调整模型的量化精度。

在 AMD GPU 日益普及的当下，掌握这套基于 Prometheus + Grafana + DCGM 的监控方案，能让 SRE 团队在面对复杂的大模型推理场景时更加从容。毕竟，只有看清了系统的每一次“呼吸”，才能真正守护好业务的连续性。

200小时GPU算力已就位，快来领取：https://marketing.csdn.net/questions/Q2604140858304426315?utm_source=AIpaper