vLLM监控体系GLM-4-9B-Chat-1M服务健康检查方案1. 引言当你把GLM-4-9B-Chat-1M这样的大模型部署到生产环境后最让人头疼的问题就是我怎么知道它现在运行得好不好GPU利用率是不是正常请求响应速度有没有变慢错误率有没有突然升高这些问题如果靠人工盯着不仅效率低下还容易遗漏关键问题。今天我就来分享一套完整的vLLM服务监控方案帮你实时掌握模型服务的健康状况。这套方案基于Prometheus和Grafana配置简单效果直观让你对模型服务的运行状态了如指掌。2. 监控体系设计思路2.1 核心监控指标一个好的监控体系需要覆盖以下几个关键维度资源利用率GPU内存使用率、GPU计算利用率、系统内存和CPU使用情况服务性能请求延迟P50、P95、P99、吞吐量QPS、并发请求数服务质量错误率、请求成功率、超时率业务指标token生成速度、请求内容分布2.2 技术选型我们选择Prometheus Grafana的组合原因很简单Prometheus擅长时序数据采集和存储支持灵活的查询语言Grafana提供强大的数据可视化能力配置简单效果美观两者都是开源工具社区活跃文档丰富3. 环境准备与部署3.1 安装Prometheus首先下载并安装Prometheus# 下载最新版Prometheus wget https://github.com/prometheus/prometheus/releases/download/v2.47.0/prometheus-2.47.0.linux-amd64.tar.gz tar xvfz prometheus-*.tar.gz cd prometheus-* # 创建配置文件 cat EOF prometheus.yml global: scrape_interval: 15s scrape_configs: - job_name: vllm static_configs: - targets: [localhost:8000] # vLLM metrics端口 - job_name: node static_configs: - targets: [localhost:9100] # node-exporter端口 EOF # 启动Prometheus ./prometheus --config.fileprometheus.yml3.2 安装Grafana# Ubuntu/Debian系统 wget -q -O - https://packages.grafana.com/gpg.key | sudo apt-key add - echo deb https://packages.grafana.com/oss/deb stable main | sudo tee -a /etc/apt/sources.list.d/grafana.list sudo apt-get update sudo apt-get install -y grafana # 启动Grafana sudo systemctl start grafana-server sudo systemctl enable grafana-server3.3 安装节点监控组件# 安装node-exporter监控系统资源 wget https://github.com/prometheus/node_exporter/releases/download/v1.6.1/node_exporter-1.6.1.linux-amd64.tar.gz tar xvfz node_exporter-*.tar.gz cd node_exporter-* ./node_exporter # 安装NVIDIA GPU监控 wget https://github.com/utkuozdemir/nvidia_gpu_exporter/releases/download/v1.2.0/nvidia_gpu_exporter_1.2.0_linux_x86_64.tar.gz tar xvfz nvidia_gpu_exporter_*.tar.gz ./nvidia_gpu_exporter 4. vLLM监控配置4.1 启用vLLM指标导出启动vLLM服务时需要开启metrics功能python -m vllm.entrypoints.openai.api_server \ --model THUDM/glm-4-9b-chat-1m \ --tensor-parallel-size 2 \ --served-model-name glm4 \ --port 8000 \ --metric-interval-ms 5000 \ # 每5秒收集一次指标 --disable-log-requests4.2 关键监控指标说明vLLM会自动暴露以下重要指标vllm_num_requests_running当前正在处理的请求数vllm_num_requests_waiting等待处理的请求数vllm_request_latency_seconds请求延迟分布vllm_gpu_utilizationGPU利用率vllm_gpu_memory_utilizationGPU内存使用率5. Grafana仪表板配置5.1 数据源配置在Grafana界面中添加Prometheus数据源访问 http://localhost:3000用户名/密码admin/admin配置 → Data Sources → Add data source选择PrometheusURL填写 http://localhost:90905.2 创建监控仪表板新建一个名为vLLM GLM-4监控的仪表板添加以下面板GPU监控面板# GPU利用率 avg(rate(nvidia_gpu_duty_cycle[1m])) by (gpu) * 100 # GPU内存使用率 avg(rate(nvidia_gpu_memory_used_bytes[1m])) by (gpu) / avg(rate(nvidia_gpu_memory_total_bytes[1m])) by (gpu) * 100服务性能面板# 请求QPS rate(vllm_num_requests_started[1m]) # 平均延迟 histogram_quantile(0.5, rate(vllm_request_latency_seconds_bucket[1m]))资源使用面板# 系统内存使用 100 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes * 100) # CPU使用率 100 - (avg by (instance) (rate(node_cpu_seconds_total{modeidle}[1m])) * 100)6. 告警规则配置6.1 Prometheus告警规则创建告警规则文件alerts.ymlgroups: - name: vllm_alerts rules: - alert: HighGPUUsage expr: avg(rate(nvidia_gpu_duty_cycle[5m])) by (gpu) * 100 90 for: 5m labels: severity: warning annotations: summary: GPU利用率过高 description: GPU {{ $labels.gpu }} 利用率持续超过90% - alert: HighRequestLatency expr: histogram_quantile(0.95, rate(vllm_request_latency_seconds_bucket[5m])) 5 for: 2m labels: severity: critical annotations: summary: 请求延迟过高 description: 95%分位请求延迟超过5秒 - alert: HighErrorRate expr: rate(vllm_num_requests_failed[5m]) / rate(vllm_num_requests_started[5m]) 0.05 for: 2m labels: severity: critical annotations: summary: 错误率过高 description: 请求错误率超过5%6.2 告警通知配置配置告警通知到常用的渠道# 配置alertmanager.yml route: receiver: slack-notifications routes: - match: severity: critical receiver: slack-critical receivers: - name: slack-notifications slack_configs: - api_url: https://hooks.slack.com/services/your/webhook/url channel: #alerts - name: slack-critical slack_configs: - api_url: https://hooks.slack.com/services/your/webhook/url channel: #critical-alerts7. 实际效果展示部署完成后你可以在Grafana中看到完整的监控仪表板。我这边实际运行的效果是GPU利用率面板实时显示各显卡的使用情况当模型处理请求时能看到明显的利用率峰值。请求延迟面板帮助我发现某个时间段的性能下降经过排查发现是同时有其他任务在占用GPU资源。错误率监控在一次模型更新后发挥了重要作用及时发现了兼容性问题避免了影响扩大。内存使用监控则帮助我合理调整了vLLM的配置参数避免了OOM错误。8. 总结搭建这套监控体系后我对GLM-4-9B-Chat-1M服务的运行状态有了全面的掌握。不再需要手动检查日志所有关键指标都能实时可视化出现问题时也能第一时间收到告警。实际使用中建议根据你的具体需求调整监控指标和告警阈值。比如对于在线服务可能需要更关注P99延迟对于批处理任务可能更关注吞吐量和资源利用率。这套方案提供了基础框架你可以在此基础上不断完善和优化。监控不是一劳永逸的事情需要根据业务发展和技术演进持续调整。但有了这个基础你就能更好地保证模型服务的稳定性和性能。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。