从“盲跑”到“可观测”：AMD 集群监控实战

在 AMD Instinct GPU 集群上跑通 vLLM 只是第一步，真正让团队安心的，是知道它在生产环境里到底“稳不稳”。之前我们花了不少时间解决 ROCm 7.x 的编译坑和显存优化问题，但服务上线后，如果缺乏有效的监控手段，一旦遇到显存泄漏或温度异常，往往只能等到用户投诉才发现。对于承载大模型推理的生产集群而言，可观测性不是锦上添花，而是生存底线。今天就来聊聊如何基于 Prometheus 和 Grafana，为 AMD 集群搭建一套轻量却硬核的监控体系，重点解决 GPU 核心指标的采集与告警落地。

为什么 AMD 集群监控容易“踩空”

很多开发者习惯了 NVIDIA 生态下的 DCGM 工具链，切换到 AMD 平台时容易陷入误区。虽然 ROCm 提供了rocm-smi等命令行工具查看实时状态，但在生产环境中，靠人工轮询或写脚本抓取日志显然无法应对高并发场景。我们需要的是能够持续采集历史数据、支持多维度聚合分析，并能即时触发告警的系统。

AMD 官方其实已经提供了对应的 exporter 方案，关键在于如何将其无缝集成到现有的 Prometheus 栈中。不同于 CPU 监控的通用性，GPU 监控需要关注更细粒度的指标：不仅仅是利用率，更重要的是显存碎片化趋势、功耗波动曲线以及温度阈值。特别是在运行 vLLM 这种对显存管理极其敏感的服务时，任何微小的显存泄漏都可能在数小时后导致 OOM（Out Of Memory）崩溃，而传统的系统监控往往无法在早期捕捉到这一征兆。

部署 DCGM Exporter 采集核心指标

在 AMD 环境下，我们通常使用适配后的 DCGM exporter（或 ROCm 自带的监控导出组件）来暴露指标。假设你的集群已经安装了 ROCm 驱动并能正常识别显卡，第一步是确保 exporter 能正确读取硬件传感器数据。

可以通过 Docker 快速部署 exporter 容器，注意需要以特权模式运行并挂载相关设备文件：

dockerrun-d--gpusall--pid=host\-p9400:9400\--namedcgm-exporter\nvcr.io/nvidia/k8s/dcgm-exporter:3.1.7-3.1.5-ubuntu22.04\# 注：此处需替换为适配 AMD 的 exporter 镜像或使用社区维护版本

注：实际生产中建议使用社区针对 ROCm 适配的 exporter 版本，确保能识别gfx942等架构代码。

启动后，访问http://<node-ip>:9400/metrics应该能看到类似DCGM_FI_DEV_GPU_TEMP、DCGM_FI_DEV_POWER_USAGE和DCGM_FI_DEV_FB_USED等指标。这些分别对应显卡温度、实时功耗和显存使用量。为了验证数据准确性，可以同时在终端运行rocm-smi --showall进行比对，确保 exporter 上报的数值与底层驱动一致。

配置 Prometheus 抓取与告警规则

数据采集上来后，需要在 Prometheus 的配置文件中添加新的 job 来定期拉取 metrics。在prometheus.yml中加入：

scrape_configs:-job_name:'amd-gpu-cluster'static_configs:-targets:['<exporter-node-ip>:9400']scrape_interval:15s

接下来是最关键的告警策略。根据我们在生产环境的经验，显存使用率是最需要警惕的指标。vLLM 在高负载下可能会因为 KV Cache 动态增长而瞬间吃满显存。我们设置了一条规则：当显存使用率超过 95% 且持续时间达到 1 分钟时，立即触发告警。这给了系统一定的缓冲期，避免因瞬时尖刺误报，又能及时拦截真正的泄漏风险。

Prometheus 告警规则示例：

groups:-name:gpu_alertsrules:-alert:HighGpuMemoryUsageexpr:(DCGM_FI_DEV_FB_USED / DCGM_FI_DEV_FB_TOTAL)>0.95for:1mlabels:severity:criticalannotations:summary:"GPU 显存使用率过高"description:"实例 {{ $labels.instance }} 的 GPU 显存使用率已超过 95%，持续 1 分钟。"

此外，温度告警也不容忽视。AMD Instinct 系列虽然散热设计优秀，但在密闭机柜中长时间满载仍可能触发热节流。建议将温度阈值设定在 85°C 左右，提前介入干预。

Grafana 可视化面板搭建技巧

有了数据和告警，最后一步是通过 Grafana 让运维人员一眼看清集群健康度。创建一个全新的 Dashboard，添加 Prometheus 数据源后，重点构建以下几个面板：

1. 全局概览：使用 Stat 面板展示集群整体平均温度、总功耗和显存剩余容量，用颜色区分健康状态（绿/黄/红）。
2. 单卡详情：利用 Time series 图表绘制每张卡的显存使用率曲线。这里有个小技巧，开启Fill below to zero并设置透明度，可以直观看到显存波动的“水位线”。
3. 热力图分布：如果集群规模较大，可以用 Heatmap 展示不同时间段内 GPU 利用率的分布情况，帮助识别业务高峰期和资源闲置时段。

在面板变量设置中，建议加入GPU_ID和Hostname的下拉筛选器，方便快速定位特定故障节点。曾经有一次，我们通过面板发现某张卡的功耗曲线异常平缓，即使在高负载请求下也没有波动，最终排查发现是该卡进入了降频保护模式，及时更换避免了更大范围的服務中断。

让监控成为稳定性基石

监控系统的价值不在于展示漂亮的图表，而在于它能帮你把故障消灭在萌芽状态。通过 Prometheus + Grafana + DCGM exporter 的组合，我们不仅实现了对 AMD 集群温度的实时监控，更重要的是建立了一套基于数据的运维决策机制。当显存告警响起时，运维人员不再是盲目重启服务，而是能依据历史曲线判断是流量突增还是内存泄漏，从而采取扩容或回滚等精准措施。

在大模型推理这条赛道上，硬件性能决定了上限，而监控体系决定了下限。只有把“黑盒”变成“白盒”，才能让 AMD 集群真正成为生产环境中可靠的生产力工具。

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