从“黑盒”到“透明”：构建 vLLM 生产级监控体系

在大模型推理服务上线的那一刻，真正的挑战才刚刚开始。很多团队在开发阶段只关注“能不能跑通”，一旦服务挂进生产环境，面对高并发流量和复杂的硬件状态，往往瞬间陷入“黑盒”困境：请求突然变慢是显存爆了还是网络抖了？半夜收到告警是因为 GPU 过热降频还是进程僵死？如果没有一套可观测性体系，运维人员只能靠猜，甚至要在故障发生后对着日志大海捞针。

特别是在使用 AMD Instinct GPU 搭配 ROCm 7.x 和 vLLM 的场景下，硬件指标的特殊性（如 HBM 带宽利用率、RCCL 通信状态）让监控变得更为关键。本文将基于真实的 DevCloud 实战经验，手把手带你搭建一套基于 DCGM Exporter + Prometheus + Grafana 的监控闭环。这套方案不仅能让你实时看清每张卡的“健康状况”，还能通过精准的告警规则，把故障扼杀在萌芽状态，彻底告别半夜被电话叫醒的噩梦。

部署 DCGM Exporter：打通 GPU 指标采集链路

监控的第一步是数据获取。在 NVIDIA 生态中我们习惯用 nvidia-smi，而在 AMD ROCm 环境下，对应的核心工具是 DCGM (Data Center GPU Manager)。AMD 官方提供的 dcgm-exporter 能够将 GPU 的温度、功耗、显存使用率、SM 活跃度等底层指标暴露为 HTTP 接口，供 Prometheus 抓取。

在 DevCloud 或自建的 Kubernetes/裸机环境中，推荐使用 Docker 方式部署，这样能避免污染宿主机的 Python 环境，也便于版本管理。以下是一个经过验证的启动命令，专门针对 ROCm 7.x 进行了适配：

docker run -d --rm \
  --name dcgm-exporter \
  --pid=host \
  --cap-add SYS_ADMIN \
  --device /dev/kfd \
  --device /dev/dri \
  --group-add video \
  -v /opt/rocm:/opt/rocm \
  -p 9400:9400 \
  nvcr.io/nvidia/k8s/dcgm-exporter:3.3.6-3.1.7-ubuntu22.04 \
  --collectors "D_FI, D_FC, D_FG, D_FT, D_FX"

这里有几个关键点需要注意：

• 设备映射：--device /dev/kfd 和 /dev/dri 是必须的，否则容器无法访问 AMD GPU 硬件。
• 权限提升：--cap-add SYS_ADMIN 允许 exporter 读取深层的性能计数器，缺少它会导致部分指标为空。
• 收集器配置：--collectors 参数指定了要采集的指标组。D_FI 包含实例信息，D_FC 包含时钟频率，D_FT 包含温度，D_FX 包含 PCIe 和错误计数。对于 vLLM 推理场景，重点关注显存和温度，这些默认都在采集范围内。

启动后，可以通过 curl http://localhost:9400/metrics 快速验证。如果能看到类似 DCGM_FI_DEV_GPU_TEMP 或 DCGM_FI_DEV_MEM_COPY_UTIL 的指标输出，说明数据采集链路已经打通。如果发现指标缺失，请检查 dmesg 日志，确认 ROCm 驱动是否正常加载，以及当前用户是否有权限访问 /dev/kfd。

配置 Prometheus 抓取与数据持久化

有了数据源，接下来需要配置 Prometheus 来定期拉取这些指标。如果你已经在运行 Prometheus 集群，只需在 prometheus.yml 配置文件中添加一个新的 job_name。

scrape_configs:
  - job_name: 'amd-gpu-monitor'
    static_configs:
      - targets: ['<your-server-ip>:9400']
    scrape_interval: 15s
    metrics_path: /metrics

对于 vLLM 这种高吞吐服务，抓取间隔（scrape_interval） 的设置很有讲究。设得太长（如 1 分钟）可能会漏掉瞬间的显存尖峰，导致 OOM 原因难以追溯；设得太短（如 5 秒）则会增加 Prometheus 自身的存储压力。在实际生产中，15 秒 是一个兼顾灵敏度和资源消耗的平衡点。

此外，建议为这些指标打上业务标签（Labels）。可以在 Prometheus 配置中使用 relabel_configs，将实例 IP 映射为具体的业务节点名称，例如：

    relabel_configs:
      - source_labels: [__address__]
        target_label: instance_name
        replacement: 'vllm-inference-node-01'
      - source_labels: [instance_name]
        target_label: service
        replacement: 'llama3-70b-instruct'

这样在后续查询时，你可以直接通过 {service="llama3-70b-instruct"} 来过滤数据，而不必记住一堆枯燥的 IP 地址。数据持久化方面，考虑到 GPU 指标随时间累积量较大，建议配置合理的保留策略（retention policy），通常保留 7-15 天的详细数据足以覆盖绝大多数故障排查周期。

绘制 Grafana 监控大盘：让数据开口说话

数据采到了，如果不能直观展示，价值就大打折扣。Grafana 是可视化的最佳选择。你可以导入社区现有的 DCGM 模板（如 ID 12239），但针对 vLLM 推理场景，我更建议自定义一个精简版大盘，只聚焦核心指标。

创建一个新 Dashboard，添加以下几个关键面板：

1. GPU 温度与功耗趋势
   使用 Graph 面板，查询语句如下：

   DCGM_FI_DEV_GPU_TEMP{gpu_uuid=~".*"}
   DCGM_FI_DEV_POWER_USAGE{gpu_uuid=~".*"}
   

   将温度设置为左 Y 轴（单位℃），功耗设置为右 Y 轴（单位 W）。这能让你一眼看出是否存在因散热不良导致的降频（Thermal Throttling）。在 ROCm 环境下，Instinct 系列显卡通常在 85℃以上开始降频，一旦曲线触及红线，必须立即介入。

2. 显存使用率与 KV Cache 增长
   这是 vLLM 最核心的指标。查询语句：

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

   建议叠加一条 vLLM 应用层的指标（如果已接入 Prometheus SDK），对比“系统层显存占用”和“逻辑层 KV Cache 占用”。如果两者差距持续扩大，可能存在显存泄漏或非模型占用的异常进程。

3. SM 活跃度与显存带宽利用率
   用于判断算力是否吃饱。

   DCGM_FI_DEV_SM_ACTIVE{gpu_uuid=~".*"}
   DCGM_FI_DEV_DRAM_BW_UTIL{gpu_uuid=~".*"}
   

   在推理场景中，如果 SM 活跃度低但带宽利用率极高，说明模型受限于内存墙（Memory Bound），此时优化方向应是量化或减小 Batch Size；反之则可能是计算瓶颈。

为了让大盘更“活人”，可以在顶部添加变量（Variables），允许用户通过下拉菜单快速切换不同的 GPU 卡号或节点，避免在一个屏幕上挤入几十条曲线导致无法阅读。

设置智能告警规则：拒绝狼来了

监控的终极目的是防患于未然。很多团队初期喜欢设一堆阈值，结果导致告警风暴，最后大家选择无视邮件。在 vLLM 生产环境中，告警规则必须少而精，且具备抗抖动能力。

以下是两条经过实战检验的告警规则配置（以 Prometheus Alertmanager 格式为例）：

规则一：显存即将溢出预警
不要等到 100% 才报警，那时服务可能已经挂了。建议在持续 1 分钟超过 92% 时触发警告。

- alert: HighGPUMemoryUsage
  expr: (DCGM_FI_DEV_FB_USED / DCGM_FI_DEV_FB_TOTAL) > 0.92
  for: 1m
  labels:
    severity: warning
  annotations:
    summary: "实例 {{ $labels.instance_name }} 显存使用率过高"
    description: "GPU {{ $labels.gpu_uuid }} 显存使用率已达 {{ $value | humanizePercentage }}，持续 1 分钟，存在 OOM 风险。"

这里使用了 for: 1m 来过滤掉瞬间的毛刺。只有当高水位持续存在，才说明是真的负载过高或泄漏。

规则二：GPU 温度异常
针对 AMD Instinct 显卡，设定 80℃为警戒线，90℃为严重线。

- alert: GPUTemperatureCritical
  expr: DCGM_FI_DEV_GPU_TEMP > 90
  for: 2m
  labels:
    severity: critical
  annotations:
    summary: "实例 {{ $labels.instance_name }} GPU 过热"
    description: "GPU {{ $labels.gpu_uuid }} 温度高达 {{ $value }}℃，可能导致降频或硬件损坏，请立即检查散热系统。"

注意这里的持续时间设为 2 分钟，因为风扇调速本身有滞后性，短暂的升温是正常的。

除了技术指标，还可以结合业务指标。例如，如果 vLLM 暴露了 vllm:num_requests_waiting 指标，可以设置当等待队列长度突增时触发告警，这往往比硬件指标更能提前反映服务拥堵。

结语：可观测性是稳定运行的基石

搭建这套监控体系，初看似乎增加了一些工作量，但在实际运行中，它带来的安全感是无法替代的。当深夜流量洪峰到来时，你不再需要祈祷服务别挂，而是可以打开 Grafana，看着平稳的曲线安心入睡；当用户反馈“有点卡”时，你能在几分钟内定位到是某张卡的显存带宽打满，而不是盲目重启服务。

在 AMD ROCm 和 vLLM 构成的新基建上，硬件性能只是底座，完善的可观测性体系才是让大模型服务真正走向生产级、实现长期稳定运行的关键保障。别让你的集群在黑暗中裸奔，现在就动手，把那些看不见的风险变成屏幕上清晰可见的防线。

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