生产环境监控怎么做，Prometheus 加 DCGM 监控 AMD 显卡

环境准备与指标采集在生产环境中AMD Instinct GPU 的稳定性直接决定了大模型推理服务的连续性。很多团队在部署 vLLM 或 PyTorch 服务时往往只关注模型加载是否成功却忽略了底层硬件的实时状态监控。一旦显存溢出OOM或温度过高导致降频服务就会瞬间不可用而缺乏监控意味着我们只能在用户投诉后被动响应。构建一套基于 Prometheus 和 DCGM Exporter 的可观测性体系是运维团队必须补齐的短板。首先我们需要确保宿主机已正确安装 ROCm 驱动并且rocm-smi命令能正常输出显卡状态。DCGM Exporter 是 NVIDIA DCGM 工具的开源适配版但在 AMD 生态中我们通常使用支持 ROCm 的dcgm-exporter或者社区维护的rocm-exporter来暴露指标。为了简化部署推荐直接使用 Docker 容器化运行这样能避免依赖冲突。启动 exporter 时关键在于映射正确的设备节点。执行以下命令将监控容器拉起dockerrun-d--gpusall\--namedcgm-exporter\--restartunless-stopped\-p9400:9400\-v/var/lib/kubelet/device-plugins:/var/lib/kubelet/device-plugins\-v/dev/dri:/dev/dri\nvcr.io/nvidia/k8s/dcgm-exporter:3.3.6-3.4.0-ubuntu22.04注虽然镜像名称带有 nvidia 字样但在新版 DCGM 及社区适配版中已支持通过 HIP 接口读取 AMD GPU 信息。若遇到兼容性问题可替换为社区专门维护的amd/dcgm-exporter镜像。容器启动后访问http://宿主机 IP:9400/metrics你应该能看到类似DCGM_FI_DEV_GPU_TEMP、DCGM_FI_DEV_POWER_USAGE和DCGM_FI_DEV_FB_USED等指标。如果页面空白或报错请检查/dev/dri挂载权限以及当前用户是否在video和render组内。Prometheus 抓取配置指标暴露出来后下一步是让 Prometheus 定期抓取这些数据。如果你已经有一套运行的 Prometheus 集群只需在prometheus.yml配置文件中新增一个 job。对于新建环境一个简单的 standalone 配置即可满足需求。编辑配置文件加入如下抓取规则scrape_configs:-job_name:amd-gpu-monitorstatic_configs:-targets:[宿主机 IP:9400]scrape_interval:15smetrics_path:/metrics这里将抓取频率设置为 15 秒既能保证数据的实时性又不会给服务器带来过重的负载。重启 Prometheus 服务后进入其 Web UI 的 “Targets” 页面确认amd-gpu-monitor任务状态为UP。此时你可以在 “Graph” 页面输入DCGM_FI_DEV_FB_USED进行查询如果能看到随时间变化的曲线说明数据链路已经打通。为了让指标更具可读性建议在 Prometheus 中配置重标签Relabeling将 GPU 的物理索引映射为业务友好的名称例如将gpu-0标记为inference-worker-01方便后续在 Grafana 中快速定位故障节点。Grafana 可视化看板搭建数据有了接下来就是让数据“说话”。Grafana 是展示这些指标的最佳工具。我们可以创建一个专门的 Dashboard聚焦于三个核心维度温度、功耗和显存使用率。新建 Dashboard 后添加三个 Time Series 面板GPU 温度监控查询语句使用DCGM_FI_DEV_GPU_TEMP。设置阈值线当温度超过 85°C 时显示警告颜色。AMD Instinct 系列虽然耐热性较好但长期高温会触发降频影响推理延迟。实时功耗分析对应指标DCGM_FI_DEV_POWER_USAGE。通过观察功耗波峰可以判断模型推理是否处于高负载状态辅助评估电力成本。显存占用趋势这是最关键的指标使用DCGM_FI_DEV_FB_USED除以DCGM_FI_DEV_FB_TOTAL计算百分比。在大模型推理中显存一旦打满服务会直接崩溃。建议将 Y 轴最大值设为 100%并标注出 90% 的安全水位线。除了基础指标还可以利用 Grafana 的变量功能实现按“节点”或GPU ID筛选视图。这样运维人员在排查问题时无需逐个查看服务器只需在下拉框中选择异常节点即可一目了然地看到该卡的历史表现。告警策略与日志联动监控的最终目的是预防故障。在 Grafana 或 Alertmanager 中配置告警规则是必不可少的一环。针对大模型推理场景最致命的风险是显存溢出OOM。建议设置如下告警规则显存高危当显存使用率 95%持续超过 1 分钟时触发 P1 级告警。这通常意味着 KV Cache 已满新请求即将失败。温度异常当GPU 温度 90°C持续 3 分钟触发 P2 级告警提示检查散热系统或降低并发度。进程存活结合黑盒监控如果 exporter 本身停止上报数据立即发送通知防止监控盲区。除了指标监控结构化日志分析同样重要。vLLM 等服务在发生长尾延迟时往往会在日志中留下痕迹。建议将标准输出重定向到 Loki 或 ELK 栈提取request_id、latency和token_count字段。当 Grafana 发现某节点延迟突增时运维人员可以迅速跳转到日志系统通过关联的时间点和节点 ID定位是哪类请求如超长上下文导致了资源争抢。通过这套组合拳我们不再是盲目地等待服务宕机而是能够提前感知风险主动调整调度策略。对于运行 AMD GPU 的生产集群而言这种细粒度的可观测性不仅是运维的保障更是优化推理成本、提升服务稳定性的基石。200小时GPU算力已就位快来领取https://marketing.csdn.net/questions/Q2604140858304426315?utm_sourceAIpaper