从“黑盒”到透明构建 AMD GPU 推理服务的监控防线在大模型推理服务上线后最让人提心吊胆的时刻往往不是流量洪峰而是面对一堆毫无波动的日志却不知道显卡内部是否已经“高烧”或显存即将溢出。对于运维工程师而言AMD Instinct GPU 在 ROCm 7.x 环境下虽然提供了强大的算力但若缺乏细粒度的监控体系生产环境就像一个黑盒。一旦遇到 OOM内存溢出或过热降频排查过程极其痛苦。本文将分享如何基于 Prometheus 和 Grafana为 AMD GPU 推理服务搭建一套“生产级”的监控方案让每一度功耗、每一字节显存都清晰可见。打通数据链路DCGM Exporter 在 ROCm 下的特殊配置监控的第一步是数据采集。在 NVIDIA 生态中DCGMData 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_sourceAIpaper
