从“能跑”到“稳跑”生产环境 GPU 可观测性实战在大模型推理服务上线初期团队最关心的往往是吞吐量RPS和首字延迟TTFT。只要 benchmark 数据好看似乎就万事大吉。但真正进入生产环境后你会发现“能跑”和“稳跑”之间隔着巨大的鸿沟。上周我们就遇到过一次深夜告警服务没有完全挂掉但响应时间突然拉长到秒级排查半天发现是某张卡的显存碎片化导致频繁换页而另一张卡因为散热风扇积灰温度墙触发降频。如果没有一套完善的可观测性体系这种问题就像在黑盒里摸象。对于基于 AMD Instinct GPU 和 ROCm 7.x 构建的推理栈如 vLLM监控不仅仅是看个绿灯而是要深入到底层硬件指标和业务日志的关联分析。今天就来聊聊我们在生产环境中落地 Prometheus Grafana 监控体系的具体实践重点解决“怎么采”、“怎么告”以及“怎么查”这三个核心问题。搭建数据采集链路DCGM Exporter 与 Prometheus监控的第一步是把数据拿上来。在 NVIDIA 生态里大家习惯用 DCGMData Center GPU Manager而在 AMD ROCm 环境下对应的工具链同样成熟。我们需要部署rocm-smi兼容的 exporter目前社区主流方案是使用支持 ROCm 的dcgm-exporter或者专门的amdgpu-exporter。在我们的 DevCloud 生产集群中选择以 DaemonSet 方式部署 exporter确保每台物理机都能采集到本地 GPU 的详细指标。安装过程并不复杂但有几个关键配置项需要注意。首先是权限问题采集进程必须属于video或render用户组否则无法读取/sys/class/drm下的底层寄存器数据。其次针对 ROCm 7.x 的新特性建议开启更细粒度的采集间隔默认通常是 30 秒但在高并发推理场景下我们将其调整为 5 秒甚至更短以便捕捉瞬时的功耗尖峰。配置好 exporter 后Prometheus 的prometheus.yml需要添加对应的 job 配置。这里有一个易错点AMD GPU 的指标命名规范与 NVIDIA 略有不同例如显存使用率通常标记为node_amdgpu_memory_used而非dcgm_fb_used。以下是一个典型的抓取配置示例scrape_configs:-job_name:amd-gpu-nodesstatic_configs:-targets:[node1:9400,node2:9400,node3:9400]metrics_path:/metricsscrape_interval:5s部署完成后你可以在 Prometheus 的 Targets 页面看到所有节点的状态变为 UP。此时像 GPU 温度node_amdgpu_temperature_edge、功耗node_amdgpu_power_average、SM 利用率以及 HBM 带宽使用情况等核心指标已经开始流入时序数据库。设定智能告警规则预防 OOM 与过热有了数据下一步就是定义“什么情况下需要叫醒运维”。很多团队容易犯的错误是只监控“存活状态”即进程还在不在。但对于大模型推理进程活着不代表服务正常。最致命的风险莫过于显存溢出OOM导致的进程崩溃或者因高温降频引发的性能雪崩。我们针对显存使用率设定了分级告警策略。vLLM 在启动时通常会预留一部分显存给 KV Cache我们将gpu-memory-utilization参数设为 0.9这意味着物理显存使用率达到 90% 是正常水位。因此告警阈值不能设在 90%而应该设在 95% 并持续一定时间。PromQL 写法如下(node_amdgpu_memory_used / node_amdgpu_memory_total) 0.95配合for: 1m条件只有当显存连续 1 分钟超过 95% 时才触发 P1 级告警。这能有效过滤掉因瞬间大 Batch 请求导致的毛刺避免狼来了式的误报。一旦触发值班人员可以立即介入检查是否有长尾请求占用了过多 KV Cache或者是否存在显存泄漏。温度监控同样重要。AMD Instinct MI300 系列虽然散热设计强大但在机房通风不佳或风扇故障时结温Junction Temperature很容易突破 85℃的安全线。我们设置了一个动态降频预警node_amdgpu_temperature_edge 80这个告警级别设为 P2目的是提醒运维提前清理风道或调整调度策略防止触发生硬的硬件保护机制导致服务中断。结构化日志与长尾延迟分析硬件指标只能反映“身体”状况业务日志才能告诉我们“大脑”在想什么。在生产环境中单纯的文本日志如print输出已经无法满足排查需求。我们将 vLLM 的标准输出重定向到结构化日志系统如 Loki 或 ELK强制要求每条推理请求都包含唯一的request_id、输入长度、输出 Token 数、处理耗时以及所在的 GPU ID。通过日志分析我们能精准定位长尾延迟Long-tail Latency。有一次监控显示平均延迟正常但 P99 延迟极高。通过检索日志中duration_ms 2000的记录我们发现这些慢请求都有一个共同特征输入 Prompt 极长且包含了复杂的 Few-shot 示例。这导致 PagedAttention 在分配内存块时出现了碎片化增加了内存管理开销。基于这一发现我们优化了前端的截断策略并在后端引入了自适应 Batch 大小调整。此外定期复盘日志还能帮助发现潜在的资源泄漏。例如如果某个request_id对应的日志有“开始”但没有“结束”或者显存占用随时间线性增长而不释放这往往是代码逻辑中存在未关闭的句柄或引用计数错误。让监控成为稳定的基石构建可观测性体系不是一劳永逸的工作而是一个持续迭代的过程。从最初的采集温度、功耗到后来关联业务日志分析延迟再到如今尝试预测性维护每一步都在提升系统的韧性。对于运行在 AMD GPU 上的大模型服务只有将底层的硬件指标与上层的业务表现打通才能真正实现从“被动救火”到“主动防御”的转变。当你的 Grafana 大盘能清晰讲述系统每一秒的故事时深夜的告警电话自然就会少很多。200小时GPU算力已就位快来领取https://marketing.csdn.net/questions/Q2604140858304426315?utm_sourceAIpaper