生产级监控方案,Prometheus 加 Grafana 守护 AMD GPU 推理服务
从“黑盒”到透明:构建 AMD GPU 推理服务的监控防线
在大模型推理服务上线后,最让人提心吊胆的时刻往往不是流量洪峰,而是面对一堆毫无波动的日志,却不知道显卡内部是否已经“高烧”或显存即将溢出。对于运维工程师而言,AMD Instinct GPU 在 ROCm 7.x 环境下虽然提供了强大的算力,但若缺乏细粒度的监控体系,生产环境就像一个黑盒。一旦遇到 OOM(内存溢出)或过热降频,排查过程极其痛苦。本文将分享如何基于 Prometheus 和 Grafana,为 AMD GPU 推理服务搭建一套“生产级”的监控方案,让每一度功耗、每一字节显存都清晰可见。
打通数据链路:DCGM Exporter 在 ROCm 下的特殊配置
监控的第一步是数据采集。在 NVIDIA 生态中,DCGM(Data Center GPU Manager)是标配,而在 AMD ROCm 环境下,我们需要使用适配后的dcgm-exporter来暴露指标。很多同学在部署时直接照搬 NVIDIA 的教程,结果发现 metrics 端口的数据全是空的,这通常是因为忽略了 ROCm 特有的设备映射权限。
首先,确保你的宿主机已安装 ROCm 7.x 驱动,并能通过rocm-smi正常查看显卡状态。在部署 exporter 时,必须将宿主机的/dev/kfd和/dev/dri设备文件映射到容器内部,否则 exporter 无法与内核态驱动通信。以下是一个典型的 Docker 启动命令示例:
docker run -d --gpus all \ --name dcgm-exporter \ -p 9400:9400 \ --device /dev/kfd \ --device /dev/dri \ --group-add video \ nvcr.io/nvidia/k8s/dcgm-exporter:3.1.7-3.1.5-ubuntu22.04注意:虽然镜像来源可能带有厂商标识,但在 ROCm 7.x 社区版中,该 exporter 已广泛支持 AMD 架构。若使用纯开源编译版本,请确保二进制文件针对gfx90a或gfx942等架构进行了正确编译。
启动后,立即访问http://<node-ip>:9400/metrics进行验证。你需要重点寻找以DCGM_FI_DEV_开头的指标,例如DCGM_FI_DEV_GPU_TEMP(温度)、DCGM_FI_DEV_POWER_USAGE(功耗)以及DCGM_FI_DEV_FB_USED(显存使用量)。如果这些指标缺失,请检查用户组权限是否已生效,必要时重启宿主机。
定制 PromQL:从原始数据到业务洞察
拿到原始指标只是开始,真正的价值在于如何通过 PromQL 将其转化为运维视角的可读信息。在 Grafana 中创建 Data Source 连接 Prometheus 后,我们可以编写针对性的查询语句来构建面板。
1. 显存利用率实时监控显存是大模型推理的生命线。为了直观展示每张卡的显存压力,可以使用以下 PromQL 计算百分比利用率:
(1 - (DCGM_FI_DEV_FB_FREE{instance="$node"} / DCGM_FI_DEV_FB_TOTAL{instance="$node"})) * 100将这个查询配置为 Time Series 图表,并设置阈值警戒线(如 90%)。当曲线持续贴近顶部时,意味着你的vLLM或SGLang服务可能正在经历显存碎片化,或者 batch size 设置过大。
2. 功耗与温度关联分析AMD Instinct MI300X 等高端卡在满载时功耗巨大。为了判断散热系统是否正常工作,可以将温度和功耗绘制在同一面板的双 Y 轴上:
- 左轴(温度):
DCGM_FI_DEV_GPU_TEMP{instance="$node"} - 右轴(功耗):
DCGM_FI_DEV_POWER_USAGE{instance="$node"}
正常情况下,两者应呈正相关。如果发现功耗飙升但温度未变,可能是传感器故障;若温度过高而功耗受限,则说明触发了热节流(Thermal Throttling),推理延迟必然增加。
告警规则实战:在 OOM 发生前介入
监控的核心目的是“防患于未然”。在生产环境中,等到服务崩溃再收到通知为时已晚。我们需要配置 Prometheus Alertmanager,在风险萌芽阶段就发出预警。
显存溢出预警规则不要等到显存使用率达到 100% 才报警。建议设置两级告警:
- Warning 级别:当显存使用率连续 2 分钟超过 85% 时,发送钉钉或邮件通知,提示运维人员关注流量波动或考虑扩容。
- Critical 级别:当显存使用率连续 30 秒超过 95% 时,触发电话告警,并自动执行预设的降级脚本(如限制最大并发请求数)。
对应的 Rule 配置片段如下:
groups: - name: amd_gpu_alerts rules: - alert: HighMemoryUsage expr: (1 - (DCGM_FI_DEV_FB_FREE / DCGM_FI_DEV_FB_TOTAL)) * 100 > 85 for: 2m labels: severity: warning annotations: summary: "GPU 显存使用率过高 ({{ $value }}%)" - alert: CriticalMemoryUsage expr: (1 - (DCGM_FI_DEV_FB_FREE / DCGM_FI_DEV_FB_TOTAL)) * 100 > 95 for: 30s labels: severity: critical annotations: summary: "GPU 显存即将溢出,请立即干预!"此外,还可以针对温度设置告警,例如当 GPU 温度超过 85°C 时触发,防止硬件因长期过热而损坏。
可视化复盘:定位性能瓶颈的利器
除了实时看板和告警,Grafana 的历史数据回溯功能对于性能调优至关重要。在一次高并发压测中,我们通过回放历史图表发现,每当 Token 生成速率(Token/s)达到峰值时,显存带宽利用率也随之饱和,导致首字延迟(TTFT)出现毛刺。
通过叠加DCGM_FI_PROF_DRAM_ACTIVE(显存活跃度)和推理服务的 QPS 曲线,我们精准定位了瓶颈所在,进而调整了vLLM的block-size参数和量化策略,最终在不增加硬件成本的情况下提升了 20% 的吞吐量。这种基于数据的决策,远比凭经验猜测要可靠得多。
构建这套监控体系并非一劳永逸,随着模型迭代和业务增长,指标维度也需要不断扩展。但有了这套基础防线,运维团队就能从被动的“救火队员”转变为主动的“系统守护者”,确保 AMD GPU 推理服务在复杂的生产环境中稳如磐石。
200 小时 GPU 算力已就位,快来领取:https://marketing.csdn.net/questions/Q2604140858304426315?utm_source=AIpaper
