GLM-4.7-Flash实操手册：Prometheus+Grafana监控GPU利用率与QPS指标

GLM-4.7-Flash实操手册：Prometheus+Grafana监控GPU利用率与QPS指标

1. 为什么需要监控大模型服务

你刚部署好GLM-4.7-Flash，界面流畅、响应迅速，一切看起来都很完美。但当真实用户开始接入、并发请求逐渐增多时，问题可能悄然而至：某次批量调用后，GPU显存突然爆满；高峰期QPS飙升，但响应延迟却越来越长；某个请求卡住后，整个推理服务变得迟钝……这些都不是偶然现象，而是缺乏可观测性的典型表现。

单纯“能跑通”不等于“能稳运行”。对GLM-4.7-Flash这类30B参数量、依赖多卡并行的高性能大模型服务来说，GPU利用率、显存占用、请求吞吐（QPS）、平均延迟、错误率这五个指标，直接决定了服务是否健康、能否扩容、何时告警。而Prometheus + Grafana组合，正是当前最轻量、最可靠、最易落地的开源监控方案——它不侵入模型逻辑，不修改vLLM配置，仅通过暴露指标+采集+可视化，就能让你像看仪表盘一样掌握服务脉搏。

本文不讲抽象理论，不堆复杂架构图。我们将从零开始，在已部署好的GLM-4.7-Flash镜像中，实打实完成三件事：
配置vLLM指标导出端点
部署Prometheus自动抓取GPU与QPS数据
搭建Grafana看板，实时查看“每张卡用了多少显存”“当前QPS是多少”“过去一小时最慢请求耗时多久”

所有操作均在镜像内完成，无需额外服务器，5分钟内可验证效果。

2. 环境准备与基础确认

2.1 确认当前服务状态

在开始监控前，请先确保GLM-4.7-Flash服务已正常运行。打开终端，执行：

supervisorctl status

你应该看到类似输出：

glm_ui RUNNING pid 123, uptime 0:15:22 glm_vllm RUNNING pid 456, uptime 0:15:18

若任一服务为STOPPED或STARTING，请先执行：

supervisorctl start all

等待约30秒，再次检查状态。只有两个服务都显示RUNNING，才可继续。

2.2 验证GPU可用性

GLM-4.7-Flash默认启用4卡并行（RTX 4090 D），监控的前提是GPU真实就绪。运行：

nvidia-smi -L

输出应显示4条GPU设备，例如：

GPU 0: NVIDIA GeForce RTX 4090D (UUID: GPU-xxxxxx) GPU 1: NVIDIA GeForce RTX 4090D (UUID: GPU-yyyyyy) GPU 2: NVIDIA GeForce RTX 4090D (UUID: GPU-zzzzzz) GPU 3: NVIDIA GeForce RTX 4090D (UUID: GPU-aaaaaa)

若只显示1–3张卡，或报错NVIDIA-SMI has failed，说明驱动或CUDA环境异常，需先修复硬件层问题。

2.3 检查vLLM版本与指标支持

本镜像预装vLLM v0.6.3+，已原生支持OpenMetrics格式指标导出。验证方式：

python -c "import vllm; print(vllm.__version__)"

输出应为0.6.3或更高版本。vLLM 0.6.0起正式提供/metrics端点，这是后续Prometheus抓取的基础。

小贴士：vLLM的指标端口默认与API端口一致（8000），无需额外开启。你只需确保http://127.0.0.1:8000/metrics能返回文本内容即可。现在就可以试一下：

curl -s http://127.0.0.1:8000/metrics | head -n 10

若返回类似# HELP vllm:gpu_cache_usage_ratio GPU KV cache usage ratio.的指标定义行，说明一切就绪。

3. 配置Prometheus采集vLLM与GPU指标

3.1 创建Prometheus配置文件

Prometheus需要知道“从哪抓数据”“抓哪些数据”“多久抓一次”。我们新建一个专用于GLM-4.7-Flash的配置：

mkdir -p /root/prometheus cat > /root/prometheus/prometheus.yml << 'EOF' global: scrape_interval: 15s evaluation_interval: 15s scrape_configs: - job_name: 'vllm-glm47flash' static_configs: - targets: ['127.0.0.1:8000'] metrics_path: '/metrics' - job_name: 'node-gpu' static_configs: - targets: ['127.0.0.1:9100'] metrics_path: '/metrics' EOF

该配置定义了两个采集任务：

• vllm-glm47flash：每15秒访问http://127.0.0.1:8000/metrics，获取vLLM原生指标（如QPS、延迟、请求队列长度）
• node-gpu：每15秒访问http://127.0.0.1:9100/metrics，获取GPU硬件指标（需下一步部署Node Exporter）

3.2 部署Node Exporter（GPU指标采集器）

vLLM自身不提供GPU显存、温度、功耗等硬件指标，需借助Node Exporter的nvidia_dcgm插件。我们使用预编译二进制快速部署：

cd /root wget https://github.com/prometheus-community/node-exporter/releases/download/v1.7.0/node_exporter-1.7.0.linux-amd64.tar.gz tar xzf node_exporter-1.7.0.linux-amd64.tar.gz mv node_exporter-1.7.0.linux-amd64/node_exporter . chmod +x node_exporter # 启动Node Exporter，启用GPU指标采集 ./node_exporter \ --collector.nvidia_dcgm \ --collector.textfile.directory /tmp/node_exporter_textfiles \ --web.listen-address=":9100" \ > /root/node_exporter.log 2>&1 &

验证GPU指标是否生效：

curl -s http://127.0.0.1:9100/metrics | grep nvidia_smi

若返回多行以nvidia_smi_开头的指标（如nvidia_smi_temperature_gpu、nvidia_smi_memory_used_bytes），说明GPU监控已就绪。

3.3 启动Prometheus服务

使用Supervisor统一管理Prometheus进程，确保异常自动重启：

cat > /etc/supervisor/conf.d/prometheus.conf << 'EOF' [program:prometheus] command=/root/prometheus/prometheus --config.file=/root/prometheus/prometheus.yml --storage.tsdb.path=/root/prometheus/data --web.enable-lifecycle autostart=true autorestart=true user=root redirect_stderr=true stdout_logfile=/root/prometheus/prometheus.log EOF supervisorctl reread supervisorctl update supervisorctl start prometheus

稍等10秒，检查状态：

supervisorctl status prometheus

输出应为RUNNING。此时Prometheus已在后台持续抓取vLLM和GPU指标。

4. 构建Grafana可视化看板

4.1 安装并启动Grafana

本镜像未预装Grafana，我们采用轻量Docker方式一键部署（无需修改系统环境）：

# 安装Docker（若未安装） apt-get update && apt-get install -y docker.io systemctl enable docker && systemctl start docker # 拉取并运行Grafana（映射到7861端口，避免与Web UI冲突） docker run -d \ --name grafana \ -p 7861:3000 \ -v /root/grafana-storage:/var/lib/grafana \ -e GF_SECURITY_ADMIN_PASSWORD=glm47flash-monitor \ -e GF_USERS_ALLOW_SIGN_UP=false \ --restart=always \ grafana/grafana-enterprise:10.4.0

验证：浏览器访问https://your-gpu-pod-url-7861.web.gpu.csdn.net/（将端口替换为7861），使用账号admin/ 密码glm47flash-monitor登录。

4.2 添加Prometheus数据源

登录Grafana后，按顺序操作：

1. 左侧菜单点击⚙ Configuration → Data Sources
2. 点击Add data source
3. 搜索并选择Prometheus
4. 在HTTP区域填写：
   • URL:http://host.docker.internal:9090

     注意：host.docker.internal是Docker内置DNS，指向宿主机。因Grafana运行在容器内，而Prometheus在宿主机，故必须用此地址。

5. 点击Save & test，看到绿色Data source is working即成功。

4.3 导入预置GLM-4.7-Flash监控看板

我们为你准备了一个开箱即用的看板JSON（含GPU利用率、QPS、P95延迟、错误率四大核心视图）。复制以下内容，粘贴到Grafana的+ → Import → Paste JSON中：

{ "dashboard": { "id": null, "title": "GLM-4.7-Flash 运行监控", "panels": [ { "title": "GPU 显存使用率（每卡）", "type": "stat", "targets": [ { "expr": "100 - (100 * avg by (gpu) (nvidia_smi_memory_free_bytes{gpu=~\"0|1|2|3\"}) / avg by (gpu) (nvidia_smi_memory_total_bytes{gpu=~\"0|1|2|3\"}))", "legendFormat": "GPU {{gpu}}" } ], "options": { "colorMode": "value", "graphMode": "none", "textMode": "auto" } }, { "title": "实时QPS（请求/秒）", "type": "timeseries", "targets": [ { "expr": "sum(rate(vllm:request_success_count_total[1m]))", "legendFormat": "QPS" } ] }, { "title": "P95请求延迟（毫秒）", "type": "timeseries", "targets": [ { "expr": "histogram_quantile(0.95, sum(rate(vllm:time_in_queue_seconds_bucket[5m])) by (le)) * 1000", "legendFormat": "P95 延迟" } ] }, { "title": "错误率（%）", "type": "gauge", "targets": [ { "expr": "sum(rate(vllm:request_failure_count_total[1m])) / (sum(rate(vllm:request_success_count_total[1m])) + sum(rate(vllm:request_failure_count_total[1m]))) * 100", "legendFormat": "错误率" } ], "options": { "min": 0, "max": 100, "showThresholdLabels": true, "showThresholdMarkers": true } } ] } }

点击Import，看板立即生成。你会看到四个实时刷新的面板：

• 左上：四张GPU卡各自的显存使用率（百分比）
• 右上：当前每秒处理请求数（QPS）曲线
• 左下：95%请求的最长等待时间（毫秒级）
• 右下：错误请求占总请求的比例（红色预警线设为5%）

实测提示：现在你可以手动发起几次API请求（如用curl调用/v1/chat/completions），观察QPS曲线是否跳动、P95延迟是否变化——这就是监控真正起效的信号。

5. 关键指标解读与调优建议

5.1 GPU利用率：不是越高越好

看板中“GPU显存使用率”常被误读为“利用率”。需明确：

• 显存使用率高（>90%）≠ GPU算力跑满：可能只是缓存占满，计算单元空闲
• 显存使用率低（<50%）≠ 服务空闲：可能因batch size过小，GPU大量时间在等数据

真正反映计算负载的是nvidia_smi_utilization_gpu_percent指标（本看板未默认展示，可自行添加）。若你发现：

• 显存使用率高 + GPU计算利用率低 → 检查vLLM的--max-num-seqs参数，适当增大批处理数
• 显存使用率低 + QPS上不去 → 尝试提高并发请求量，或检查网络带宽瓶颈

5.2 QPS与延迟的平衡艺术

vLLM的QPS并非线性增长。在4卡4090D上，GLM-4.7-Flash典型表现：

可见，8并发是性价比拐点。超过此值，QPS不增反降，延迟陡升。建议将生产环境最大并发控制在6–8之间，并在Grafana中设置QPS > 5.5 的告警。

5.3 错误率背后的真相

vllm:request_failure_count_total统计的是vLLM内部拒绝的请求，常见原因：

• 队列超时：time_in_queue_seconds超过--request-timeout-s（默认300秒）→ 调高该参数或优化前端重试逻辑
• 显存不足：CUDA out of memory→ 减小--max-model-len或--max-num-batched-tokens
• 输入超长：单次请求token数超过模型上限 → 前端做长度校验

在Grafana中，一旦错误率突破2%，应立即检查/root/workspace/glm_vllm.log末尾的ERROR日志，定位根因。

6. 总结

你已经完成了GLM-4.7-Flash服务的可观测性闭环：
🔹数据采集层：通过vLLM原生/metrics端点 + Node Exporternvidia_dcgm插件，无侵入式获取QPS、延迟、GPU显存/温度等20+核心指标；
🔹存储与查询层：Prometheus以15秒粒度持续抓取，本地存储7天数据，支持任意时间范围回溯分析；
🔹可视化层：Grafana看板直击业务关键——不是“服务器是否活着”，而是“用户此刻体验如何”。

这套方案的价值，不在部署那一刻，而在日常运维中：

• 当客户反馈“回答变慢”，你打开看板，3秒内确认是GPU 3号卡显存达98%，立刻执行supervisorctl restart glm_vllm释放缓存；
• 当计划扩容，你拉取过去7天QPS峰值曲线，发现周末流量是平日2.3倍，据此精准申请资源；
• 当新版本上线，你对比A/B测试期间的P95延迟分布，用数据证明优化效果提升37%。

监控不是给老板看的报表，而是工程师手里的听诊器。它让模糊的“感觉慢”，变成清晰的“GPU 2号卡显存泄漏，每小时增长1.2GB”。

获取更多AI镜像

想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。