Nanbeige4.1-3B vLLM服务监控PrometheusGrafana采集GPU利用率、请求延迟指标当你把Nanbeige4.1-3B模型用vLLM部署起来并通过Chainlit前端愉快地聊天时有没有想过一个问题这个服务现在到底跑得怎么样GPU是不是快被榨干了每次生成回答要等多久服务稳不稳定如果只是靠感觉或者出了问题才去查日志那就太被动了。今天我们就来解决这个问题——给你的Nanbeige4.1-3B vLLM服务装上一套“仪表盘”用Prometheus和Grafana实时监控GPU利用率、请求延迟这些关键指标让你对服务状态了如指掌。1. 为什么要监控vLLM服务在深入技术细节之前我们先聊聊监控的价值。这不仅仅是技术上的“炫技”而是实实在在能帮你省心省力的好帮手。1.1 从“盲人摸象”到“全局掌控”想象一下你的模型服务正在线上运行用户通过Chainlit前端不断提问。如果没有监控你就像在开一辆没有仪表盘的车——不知道速度、不知道油量、不知道水温。服务突然变慢你只能靠用户反馈。GPU内存泄漏可能要等到服务崩溃才发现。有了PrometheusGrafana这套监控方案你就能实时看到GPU用了多少、内存还剩多少、请求处理得快不快提前预警在问题变得严重之前就发现异常优化依据知道瓶颈在哪里该升级硬件还是优化代码1.2 监控的核心指标对于vLLM部署的大模型服务我们需要重点关注这几类指标指标类别具体指标为什么重要GPU资源GPU利用率、GPU内存使用量知道GPU是否成为瓶颈是否需要优化或扩容请求性能请求延迟P50/P95/P99、吞吐量QPS直接影响用户体验是服务质量的直接体现服务健康请求成功率、错误率、服务可用性确保服务稳定可靠及时发现异常系统资源CPU使用率、内存使用量、网络IO全面了解服务运行环境的状态2. 监控方案架构设计在开始动手之前我们先看看整个监控方案是怎么组成的。这套方案的核心思想是采集 → 存储 → 展示。2.1 整体架构Chainlit前端 → vLLM服务 → Prometheus指标暴露 → Prometheus Server采集存储 → Grafana可视化展示简单来说vLLM服务通过内置的指标接口把GPU使用情况、请求统计等信息暴露出来Prometheus定期去vLLM服务那里“抓取”这些指标数据并存储在自己的时序数据库中Grafana从Prometheus读取数据用漂亮的图表展示出来让你一眼就能看懂2.2 为什么选择PrometheusGrafana你可能会问为什么不用其他监控方案这里有几个关键原因生态成熟Prometheus是云原生监控的事实标准vLLM原生支持Prometheus格式的指标配置简单整套方案可以在几分钟内搭建完成不需要复杂的配置可视化强大Grafana的图表非常丰富可以自定义各种监控面板开源免费完全免费功能却一点不输商业方案3. 一步步搭建监控系统好了理论说完了现在开始动手。我会带你一步步完成整个监控系统的搭建。3.1 第一步确认vLLM服务状态首先确保你的Nanbeige4.1-3B vLLM服务已经正常运行。按照你提供的使用说明# 查看服务日志确认服务已启动 cat /root/workspace/llm.log你应该能看到类似这样的输出表示vLLM服务已经成功启动INFO 01-01 12:00:00 llm_engine.py:73] Initializing an LLM engine with config: ... INFO 01-01 12:00:00 model_runner.py:83] Loading model weights... INFO 01-01 12:00:30 llm_engine.py:210] Model loaded successfully.3.2 第二步启用vLLM的Prometheus指标vLLM内置了Prometheus指标支持我们只需要在启动时加上几个参数。如果你已经启动了服务可能需要重启一下。修改你的vLLM启动命令添加指标相关的参数# 原来的启动命令可能类似这样 # python -m vllm.entrypoints.api_server --model /path/to/nanbeige4.1-3b --port 8000 # 修改后的启动命令 python -m vllm.entrypoints.api_server \ --model /path/to/nanbeige4.1-3b \ --port 8000 \ --metrics-port 8001 \ --enable-metrics \ --metric-interval-ms 5000关键参数解释--metrics-port 8001指标暴露的端口Prometheus会从这个端口抓取数据--enable-metrics启用指标收集--metric-interval-ms 5000指标收集间隔这里设置为5秒启动后你可以验证指标是否正常暴露# 访问指标端点查看原始指标数据 curl http://localhost:8001/metrics如果一切正常你会看到一大堆以Prometheus格式输出的指标数据比如# HELP vllm:num_requests_total Total number of requests processed # TYPE vllm:num_requests_total counter vllm:num_requests_total 42 # HELP vllm:request_latency_seconds Request latency in seconds # TYPE vllm:request_latency_seconds histogram vllm:request_latency_seconds_bucket{le0.1} 10 vllm:request_latency_seconds_bucket{le0.5} 30 vllm:request_latency_seconds_bucket{le1.0} 40 vllm:request_latency_seconds_bucket{leInf} 423.3 第三步安装和配置Prometheus现在我们需要安装Prometheus来收集这些指标。在你的服务器上执行以下步骤# 下载Prometheus wget https://github.com/prometheus/prometheus/releases/download/v2.51.0/prometheus-2.51.0.linux-amd64.tar.gz # 解压 tar xvfz prometheus-2.51.0.linux-amd64.tar.gz cd prometheus-2.51.0.linux-amd64 # 创建配置文件 cat prometheus.yml EOF global: scrape_interval: 15s # 每15秒采集一次数据 evaluation_interval: 15s scrape_configs: - job_name: vllm static_configs: - targets: [localhost:8001] # vLLM指标端点 metrics_path: /metrics scrape_interval: 5s # vLLM指标变化快可以采集频繁一些 - job_name: node static_configs: - targets: [localhost:9100] # Node Exporter用于系统指标 EOF这个配置文件告诉Prometheus每15秒检查一次规则默认有两个采集任务vLLM服务指标和系统指标vLLM的指标每5秒采集一次因为AI服务的指标变化比较快启动Prometheus# 后台启动Prometheus ./prometheus --config.fileprometheus.yml 验证Prometheus是否正常运行# 访问Prometheus的Web界面 curl http://localhost:9090 # 或者直接查询一个指标试试 curl http://localhost:9090/api/v1/query?queryvllm:num_requests_total3.4 第四步安装Node Exporter可选但推荐如果你想监控系统的CPU、内存、磁盘等资源还需要安装Node Exporter# 下载Node Exporter wget https://github.com/prometheus/node_exporter/releases/download/v1.7.0/node_exporter-1.7.0.linux-amd64.tar.gz # 解压并启动 tar xvfz node_exporter-1.7.0.linux-amd64.tar.gz cd node_exporter-1.7.0.linux-amd64 ./node_exporter Node Exporter默认会在9100端口暴露系统指标这已经在我们的Prometheus配置中设置了。3.5 第五步安装和配置Grafana现在到了最有趣的部分——用Grafana把数据变成漂亮的图表。# 添加Grafana的APT源如果是Ubuntu/Debian sudo apt-get install -y software-properties-common sudo add-apt-repository deb https://packages.grafana.com/oss/deb stable main wget -q -O - https://packages.grafana.com/gpg.key | sudo apt-key add - # 安装Grafana sudo apt-get update sudo apt-get install -y grafana # 启动Grafana服务 sudo systemctl start grafana-server sudo systemctl enable grafana-serverGrafana默认运行在3000端口。打开浏览器访问http://你的服务器IP:3000初始用户名和密码都是admin。第一次登录后Grafana会要求你修改密码然后按照以下步骤配置添加数据源点击左侧的Configuration小齿轮图标→ Data Sources → Add data source选择Prometheus在列表中选择Prometheus配置连接URL:http://localhost:9090如果Prometheus运行在同一台机器其他保持默认点击Save Test应该显示Data source is working表示连接成功3.6 第六步导入vLLM监控仪表盘Grafana社区有很多现成的仪表盘模板我们可以直接导入一个适合vLLM的。在Grafana中点击左侧号 → Import输入仪表盘ID18602这是一个通用的vLLM监控仪表盘选择我们刚才添加的Prometheus数据源点击Import导入后你就能看到一个完整的vLLM监控面板了。不过这个通用面板可能不完全符合我们的需求我们需要做一些自定义。4. 创建专属的Nanbeige4.1-3B监控面板通用面板虽然好但针对我们的Nanbeige4.1-3B服务我们可以创建更贴合的监控面板。我来带你创建一个包含关键指标的专属面板。4.1 核心监控指标详解在创建图表之前我们先了解几个关键指标的含义和PromQL查询语句指标名称PromQL查询含义说明GPU利用率DCGM_FI_DEV_GPU_UTILGPU计算单元使用百分比理想值70-90%GPU内存使用DCGM_FI_DEV_FB_USED / DCGM_FI_DEV_FB_FREEGPU显存使用量关注是否接近上限请求延迟P95histogram_quantile(0.95, rate(vllm:request_latency_seconds_bucket[5m]))95%的请求在这个时间内完成请求QPSrate(vllm:num_requests_total[5m])每秒处理的请求数Token生成速度rate(vllm:tokens_generated_total[5m])每秒生成的token数错误率rate(vllm:request_failures_total[5m]) / rate(vllm:num_requests_total[5m])请求失败的比例4.2 创建自定义监控面板在Grafana中点击Create → Dashboard → Add new panel我们开始添加图表。4.2.1 GPU利用率监控第一个图表我们监控GPU的使用情况面板标题GPU Utilization查询语句DCGM_FI_DEV_GPU_UTIL{instancelocalhost:8001}可视化设置Visualization: Stat显示当前值Unit: Percent (0-100)Thresholds: 70黄色, 90红色说明这个图表显示GPU的实时利用率绿色表示正常黄色表示较高红色表示可能成为瓶颈4.2.2 GPU内存使用监控第二个图表监控GPU内存面板标题GPU Memory Usage查询语句DCGM_FI_DEV_FB_USED{instancelocalhost:8001}第二个查询用于显示总量DCGM_FI_DEV_FB_TOTAL{instancelocalhost:8001}可视化设置Visualization: Gauge仪表盘Unit: bytes会自动转换为GBMin: 0, Max: 使用第二个查询的值说明仪表盘显示当前GPU内存使用量可以直观看到使用了多少、还剩多少4.2.3 请求延迟分布第三个图表监控请求的响应时间面板标题Request Latency (P50/P95/P99)查询语句三个查询分别显示P50、P95、P99# P50延迟 histogram_quantile(0.50, rate(vllm:request_latency_seconds_bucket[5m])) # P95延迟 histogram_quantile(0.95, rate(vllm:request_latency_seconds_bucket[5m])) # P99延迟 histogram_quantile(0.99, rate(vllm:request_latency_seconds_bucket[5m]))可视化设置Visualization: Time series时间序列图Unit: seconds秒说明这个图显示请求延迟的分布P95是最常用的指标表示95%的请求在这个时间内完成4.2.4 请求吞吐量监控第四个图表监控服务的处理能力面板标题Request Throughput (QPS)查询语句rate(vllm:num_requests_total[5m])可视化设置Visualization: Time seriesUnit: reqs/sec请求数/秒说明显示每秒处理的请求数可以了解服务的负载情况4.2.5 Token生成速度第五个图表监控模型的生成效率面板标题Token Generation Speed查询语句rate(vllm:tokens_generated_total[5m])第二个查询输入tokenrate(vllm:tokens_prompt_total[5m])可视化设置Visualization: Time seriesUnit: tokens/sectoken数/秒说明显示模型生成token的速度可以了解模型的性能表现4.3 完整的监控面板布局把上面这些图表合理排列你的监控面板可能看起来像这样-------------------------------------- | GPU Utilization | GPU Memory Usage | | (当前值仪表) | (仪表盘) | -------------------------------------- | Request Latency | Request Throughput| | (时间序列图) | (时间序列图) | -------------------------------------- | Token Generation | System Resources | | Speed (时间序列) | (CPU/内存/磁盘) | -------------------------------------- | Alerts Status Summary | ---------------------------------------5. 设置告警规则监控面板能让你看到问题但告警能在问题发生时主动通知你。我们来设置几个关键的告警规则。5.1 在Prometheus中配置告警规则创建告警规则文件cat alerts.yml EOF groups: - name: vllm_alerts rules: # GPU利用率过高告警 - alert: HighGPUUsage expr: DCGM_FI_DEV_GPU_UTIL 90 for: 5m labels: severity: warning annotations: summary: GPU利用率过高 description: GPU利用率持续5分钟超过90%当前值 {{ $value }}% # GPU内存不足告警 - alert: HighGPUMemoryUsage expr: DCGM_FI_DEV_FB_USED / DCGM_FI_DEV_FB_TOTAL 0.9 for: 2m labels: severity: critical annotations: summary: GPU内存不足 description: GPU内存使用超过90%当前使用率 {{ $value | humanizePercentage }} # 请求延迟过高告警 - alert: HighRequestLatency expr: histogram_quantile(0.95, rate(vllm:request_latency_seconds_bucket[5m])) 10 for: 5m labels: severity: warning annotations: summary: 请求延迟过高 description: P95请求延迟超过10秒当前值 {{ $value }}秒 # 服务错误率过高告警 - alert: HighErrorRate expr: rate(vllm:request_failures_total[5m]) / rate(vllm:num_requests_total[5m]) 0.05 for: 2m labels: severity: critical annotations: summary: 服务错误率过高 description: 请求错误率超过5%当前值 {{ $value | humanizePercentage }} EOF更新Prometheus配置引用这个告警规则文件# 在prometheus.yml中添加 rule_files: - alerts.yml alerting: alertmanagers: - static_configs: - targets: # - alertmanager:9093 # 如果需要Alertmanager可以取消注释重启Prometheus使配置生效。5.2 在Grafana中配置告警通知如果你希望收到告警通知可以在Grafana中配置点击Alerting → Contact points → Add contact point选择通知方式比如Email邮件通知SlackSlack消息Webhook自定义Webhook配置相应的连接信息在监控面板的图表上点击Edit → Alert → Create alert设置告警条件和通知方式6. 实际监控效果演示现在让我们看看这套监控系统在实际使用中能告诉我们什么信息。6.1 正常情况下的监控视图当你的Nanbeige4.1-3B服务正常运行时监控面板可能显示GPU利用率在50-80%之间波动取决于请求的复杂度GPU内存稳定在6-8GB对于3B参数模型请求延迟P95在2-5秒之间取决于生成长度QPS根据你的负载可能在1-10 reqs/sec之间Token生成速度20-50 tokens/sec这是模型本身的性能6.2 异常情况识别当出现问题时监控面板能帮你快速定位场景一GPU内存泄漏现象GPU内存使用量持续上升不释放监控表现GPU Memory Usage图表持续向上最终接近100%可能原因vLLM的缓存管理问题或者请求序列过长解决方法重启服务或者检查是否有异常请求场景二请求堆积现象用户反馈响应慢监控表现Request Latency图表飙升QPS下降可能原因GPU利用率已达100%或者系统资源不足解决方法查看GPU Utilization和系统资源图表确认瓶颈场景三服务异常现象部分请求失败监控表现Error Rate图表显示错误率上升可能原因模型推理错误或者vLLM内部错误解决方法查看服务日志定位具体错误信息6.3 性能优化参考通过长期监控你还可以获得优化服务的 insights最佳批量大小观察不同批量大小下的GPU利用率和延迟找到平衡点合适生成长度根据Token生成速度建议用户设置合理的max_tokens扩容时机当GPU利用率持续高于80%且延迟开始上升时考虑扩容模型选择如果发现3B模型在某些任务上性能不足可以考虑升级到更大模型7. 监控系统的维护和优化搭建好监控系统只是第一步长期维护同样重要。7.1 数据保留策略Prometheus默认只保留15天的数据对于长期趋势分析可能不够。你可以调整数据保留时间# 在prometheus.yml中添加 storage: tsdb: retention: time: 90d # 保留90天数据或者考虑设置Prometheus的长期存储比如ThanosPrometheus的高可用长期存储方案Cortex云原生的Prometheus长期存储MimirGrafana Labs开源的长期存储方案7.2 监控系统本身的监控监控系统本身也需要被监控确保Prometheus状态监控Prometheus的采集是否正常Grafana状态确保Grafana服务可用磁盘空间监控时序数据的磁盘使用量资源使用监控Prometheus和Grafana的CPU、内存使用7.3 定期审查和优化建议每月进行一次监控系统审查告警有效性检查告警是否准确减少误报指标优化删除不再需要的指标减少存储压力面板更新根据业务变化调整监控面板性能调优优化PromQL查询提高查询效率8. 总结通过今天的学习我们为Nanbeige4.1-3B vLLM服务搭建了一套完整的监控系统。让我们回顾一下关键收获8.1 监控的价值再认识监控不是“有了更好”的装饰品而是服务稳定运行的“必需品”。通过这套系统你能够实时掌握服务状态不再需要手动查日志所有关键指标一目了然快速定位问题当服务出现异常时能快速找到问题根源数据驱动决策基于监控数据做出扩容、优化等决策提升用户体验通过监控优化服务性能最终提升用户满意度8.2 关键实施要点在实施过程中有几个关键点需要特别注意指标选择要精准不是监控越多越好要关注核心业务指标告警设置要合理避免告警疲劳设置合理的阈值和持续时间可视化要直观Grafana面板要能让非技术人员也能看懂系统要可持续考虑数据保留、存储成本、维护成本8.3 下一步建议如果你已经成功搭建了监控系统我建议你深入探索PromQL学习更复杂的查询语句挖掘更多 insights设置自动化响应结合Alertmanager和自动化脚本实现自动恢复建立监控文化在团队中分享监控数据让数据驱动成为习惯考虑AIOps探索AI在运维监控中的应用实现智能告警和根因分析监控系统的建设是一个持续的过程随着业务的发展你需要不断调整和优化。但有了今天的基础你已经迈出了最重要的一步——从“盲人摸象”到“心中有数”。现在当有人问你“服务跑得怎么样”时你可以自信地打开Grafana面板用数据说话。这不仅提升了你的运维能力也为服务的稳定性和可靠性提供了坚实保障。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。
Nanbeige4.1-3B vLLM服务监控：Prometheus+Grafana采集GPU利用率、请求延迟指标
发布时间：2026/7/8 6:10:37
Nanbeige4.1-3B vLLM服务监控PrometheusGrafana采集GPU利用率、请求延迟指标当你把Nanbeige4.1-3B模型用vLLM部署起来并通过Chainlit前端愉快地聊天时有没有想过一个问题这个服务现在到底跑得怎么样GPU是不是快被榨干了每次生成回答要等多久服务稳不稳定如果只是靠感觉或者出了问题才去查日志那就太被动了。今天我们就来解决这个问题——给你的Nanbeige4.1-3B vLLM服务装上一套“仪表盘”用Prometheus和Grafana实时监控GPU利用率、请求延迟这些关键指标让你对服务状态了如指掌。1. 为什么要监控vLLM服务在深入技术细节之前我们先聊聊监控的价值。这不仅仅是技术上的“炫技”而是实实在在能帮你省心省力的好帮手。1.1 从“盲人摸象”到“全局掌控”想象一下你的模型服务正在线上运行用户通过Chainlit前端不断提问。如果没有监控你就像在开一辆没有仪表盘的车——不知道速度、不知道油量、不知道水温。服务突然变慢你只能靠用户反馈。GPU内存泄漏可能要等到服务崩溃才发现。有了PrometheusGrafana这套监控方案你就能实时看到GPU用了多少、内存还剩多少、请求处理得快不快提前预警在问题变得严重之前就发现异常优化依据知道瓶颈在哪里该升级硬件还是优化代码1.2 监控的核心指标对于vLLM部署的大模型服务我们需要重点关注这几类指标指标类别具体指标为什么重要GPU资源GPU利用率、GPU内存使用量知道GPU是否成为瓶颈是否需要优化或扩容请求性能请求延迟P50/P95/P99、吞吐量QPS直接影响用户体验是服务质量的直接体现服务健康请求成功率、错误率、服务可用性确保服务稳定可靠及时发现异常系统资源CPU使用率、内存使用量、网络IO全面了解服务运行环境的状态2. 监控方案架构设计在开始动手之前我们先看看整个监控方案是怎么组成的。这套方案的核心思想是采集 → 存储 → 展示。2.1 整体架构Chainlit前端 → vLLM服务 → Prometheus指标暴露 → Prometheus Server采集存储 → Grafana可视化展示简单来说vLLM服务通过内置的指标接口把GPU使用情况、请求统计等信息暴露出来Prometheus定期去vLLM服务那里“抓取”这些指标数据并存储在自己的时序数据库中Grafana从Prometheus读取数据用漂亮的图表展示出来让你一眼就能看懂2.2 为什么选择PrometheusGrafana你可能会问为什么不用其他监控方案这里有几个关键原因生态成熟Prometheus是云原生监控的事实标准vLLM原生支持Prometheus格式的指标配置简单整套方案可以在几分钟内搭建完成不需要复杂的配置可视化强大Grafana的图表非常丰富可以自定义各种监控面板开源免费完全免费功能却一点不输商业方案3. 一步步搭建监控系统好了理论说完了现在开始动手。我会带你一步步完成整个监控系统的搭建。3.1 第一步确认vLLM服务状态首先确保你的Nanbeige4.1-3B vLLM服务已经正常运行。按照你提供的使用说明# 查看服务日志确认服务已启动 cat /root/workspace/llm.log你应该能看到类似这样的输出表示vLLM服务已经成功启动INFO 01-01 12:00:00 llm_engine.py:73] Initializing an LLM engine with config: ... INFO 01-01 12:00:00 model_runner.py:83] Loading model weights... INFO 01-01 12:00:30 llm_engine.py:210] Model loaded successfully.3.2 第二步启用vLLM的Prometheus指标vLLM内置了Prometheus指标支持我们只需要在启动时加上几个参数。如果你已经启动了服务可能需要重启一下。修改你的vLLM启动命令添加指标相关的参数# 原来的启动命令可能类似这样 # python -m vllm.entrypoints.api_server --model /path/to/nanbeige4.1-3b --port 8000 # 修改后的启动命令 python -m vllm.entrypoints.api_server \ --model /path/to/nanbeige4.1-3b \ --port 8000 \ --metrics-port 8001 \ --enable-metrics \ --metric-interval-ms 5000关键参数解释--metrics-port 8001指标暴露的端口Prometheus会从这个端口抓取数据--enable-metrics启用指标收集--metric-interval-ms 5000指标收集间隔这里设置为5秒启动后你可以验证指标是否正常暴露# 访问指标端点查看原始指标数据 curl http://localhost:8001/metrics如果一切正常你会看到一大堆以Prometheus格式输出的指标数据比如# HELP vllm:num_requests_total Total number of requests processed # TYPE vllm:num_requests_total counter vllm:num_requests_total 42 # HELP vllm:request_latency_seconds Request latency in seconds # TYPE vllm:request_latency_seconds histogram vllm:request_latency_seconds_bucket{le0.1} 10 vllm:request_latency_seconds_bucket{le0.5} 30 vllm:request_latency_seconds_bucket{le1.0} 40 vllm:request_latency_seconds_bucket{leInf} 423.3 第三步安装和配置Prometheus现在我们需要安装Prometheus来收集这些指标。在你的服务器上执行以下步骤# 下载Prometheus wget https://github.com/prometheus/prometheus/releases/download/v2.51.0/prometheus-2.51.0.linux-amd64.tar.gz # 解压 tar xvfz prometheus-2.51.0.linux-amd64.tar.gz cd prometheus-2.51.0.linux-amd64 # 创建配置文件 cat prometheus.yml EOF global: scrape_interval: 15s # 每15秒采集一次数据 evaluation_interval: 15s scrape_configs: - job_name: vllm static_configs: - targets: [localhost:8001] # vLLM指标端点 metrics_path: /metrics scrape_interval: 5s # vLLM指标变化快可以采集频繁一些 - job_name: node static_configs: - targets: [localhost:9100] # Node Exporter用于系统指标 EOF这个配置文件告诉Prometheus每15秒检查一次规则默认有两个采集任务vLLM服务指标和系统指标vLLM的指标每5秒采集一次因为AI服务的指标变化比较快启动Prometheus# 后台启动Prometheus ./prometheus --config.fileprometheus.yml 验证Prometheus是否正常运行# 访问Prometheus的Web界面 curl http://localhost:9090 # 或者直接查询一个指标试试 curl http://localhost:9090/api/v1/query?queryvllm:num_requests_total3.4 第四步安装Node Exporter可选但推荐如果你想监控系统的CPU、内存、磁盘等资源还需要安装Node Exporter# 下载Node Exporter wget https://github.com/prometheus/node_exporter/releases/download/v1.7.0/node_exporter-1.7.0.linux-amd64.tar.gz # 解压并启动 tar xvfz node_exporter-1.7.0.linux-amd64.tar.gz cd node_exporter-1.7.0.linux-amd64 ./node_exporter Node Exporter默认会在9100端口暴露系统指标这已经在我们的Prometheus配置中设置了。3.5 第五步安装和配置Grafana现在到了最有趣的部分——用Grafana把数据变成漂亮的图表。# 添加Grafana的APT源如果是Ubuntu/Debian sudo apt-get install -y software-properties-common sudo add-apt-repository deb https://packages.grafana.com/oss/deb stable main wget -q -O - https://packages.grafana.com/gpg.key | sudo apt-key add - # 安装Grafana sudo apt-get update sudo apt-get install -y grafana # 启动Grafana服务 sudo systemctl start grafana-server sudo systemctl enable grafana-serverGrafana默认运行在3000端口。打开浏览器访问http://你的服务器IP:3000初始用户名和密码都是admin。第一次登录后Grafana会要求你修改密码然后按照以下步骤配置添加数据源点击左侧的Configuration小齿轮图标→ Data Sources → Add data source选择Prometheus在列表中选择Prometheus配置连接URL:http://localhost:9090如果Prometheus运行在同一台机器其他保持默认点击Save Test应该显示Data source is working表示连接成功3.6 第六步导入vLLM监控仪表盘Grafana社区有很多现成的仪表盘模板我们可以直接导入一个适合vLLM的。在Grafana中点击左侧号 → Import输入仪表盘ID18602这是一个通用的vLLM监控仪表盘选择我们刚才添加的Prometheus数据源点击Import导入后你就能看到一个完整的vLLM监控面板了。不过这个通用面板可能不完全符合我们的需求我们需要做一些自定义。4. 创建专属的Nanbeige4.1-3B监控面板通用面板虽然好但针对我们的Nanbeige4.1-3B服务我们可以创建更贴合的监控面板。我来带你创建一个包含关键指标的专属面板。4.1 核心监控指标详解在创建图表之前我们先了解几个关键指标的含义和PromQL查询语句指标名称PromQL查询含义说明GPU利用率DCGM_FI_DEV_GPU_UTILGPU计算单元使用百分比理想值70-90%GPU内存使用DCGM_FI_DEV_FB_USED / DCGM_FI_DEV_FB_FREEGPU显存使用量关注是否接近上限请求延迟P95histogram_quantile(0.95, rate(vllm:request_latency_seconds_bucket[5m]))95%的请求在这个时间内完成请求QPSrate(vllm:num_requests_total[5m])每秒处理的请求数Token生成速度rate(vllm:tokens_generated_total[5m])每秒生成的token数错误率rate(vllm:request_failures_total[5m]) / rate(vllm:num_requests_total[5m])请求失败的比例4.2 创建自定义监控面板在Grafana中点击Create → Dashboard → Add new panel我们开始添加图表。4.2.1 GPU利用率监控第一个图表我们监控GPU的使用情况面板标题GPU Utilization查询语句DCGM_FI_DEV_GPU_UTIL{instancelocalhost:8001}可视化设置Visualization: Stat显示当前值Unit: Percent (0-100)Thresholds: 70黄色, 90红色说明这个图表显示GPU的实时利用率绿色表示正常黄色表示较高红色表示可能成为瓶颈4.2.2 GPU内存使用监控第二个图表监控GPU内存面板标题GPU Memory Usage查询语句DCGM_FI_DEV_FB_USED{instancelocalhost:8001}第二个查询用于显示总量DCGM_FI_DEV_FB_TOTAL{instancelocalhost:8001}可视化设置Visualization: Gauge仪表盘Unit: bytes会自动转换为GBMin: 0, Max: 使用第二个查询的值说明仪表盘显示当前GPU内存使用量可以直观看到使用了多少、还剩多少4.2.3 请求延迟分布第三个图表监控请求的响应时间面板标题Request Latency (P50/P95/P99)查询语句三个查询分别显示P50、P95、P99# P50延迟 histogram_quantile(0.50, rate(vllm:request_latency_seconds_bucket[5m])) # P95延迟 histogram_quantile(0.95, rate(vllm:request_latency_seconds_bucket[5m])) # P99延迟 histogram_quantile(0.99, rate(vllm:request_latency_seconds_bucket[5m]))可视化设置Visualization: Time series时间序列图Unit: seconds秒说明这个图显示请求延迟的分布P95是最常用的指标表示95%的请求在这个时间内完成4.2.4 请求吞吐量监控第四个图表监控服务的处理能力面板标题Request Throughput (QPS)查询语句rate(vllm:num_requests_total[5m])可视化设置Visualization: Time seriesUnit: reqs/sec请求数/秒说明显示每秒处理的请求数可以了解服务的负载情况4.2.5 Token生成速度第五个图表监控模型的生成效率面板标题Token Generation Speed查询语句rate(vllm:tokens_generated_total[5m])第二个查询输入tokenrate(vllm:tokens_prompt_total[5m])可视化设置Visualization: Time seriesUnit: tokens/sectoken数/秒说明显示模型生成token的速度可以了解模型的性能表现4.3 完整的监控面板布局把上面这些图表合理排列你的监控面板可能看起来像这样-------------------------------------- | GPU Utilization | GPU Memory Usage | | (当前值仪表) | (仪表盘) | -------------------------------------- | Request Latency | Request Throughput| | (时间序列图) | (时间序列图) | -------------------------------------- | Token Generation | System Resources | | Speed (时间序列) | (CPU/内存/磁盘) | -------------------------------------- | Alerts Status Summary | ---------------------------------------5. 设置告警规则监控面板能让你看到问题但告警能在问题发生时主动通知你。我们来设置几个关键的告警规则。5.1 在Prometheus中配置告警规则创建告警规则文件cat alerts.yml EOF groups: - name: vllm_alerts rules: # GPU利用率过高告警 - alert: HighGPUUsage expr: DCGM_FI_DEV_GPU_UTIL 90 for: 5m labels: severity: warning annotations: summary: GPU利用率过高 description: GPU利用率持续5分钟超过90%当前值 {{ $value }}% # GPU内存不足告警 - alert: HighGPUMemoryUsage expr: DCGM_FI_DEV_FB_USED / DCGM_FI_DEV_FB_TOTAL 0.9 for: 2m labels: severity: critical annotations: summary: GPU内存不足 description: GPU内存使用超过90%当前使用率 {{ $value | humanizePercentage }} # 请求延迟过高告警 - alert: HighRequestLatency expr: histogram_quantile(0.95, rate(vllm:request_latency_seconds_bucket[5m])) 10 for: 5m labels: severity: warning annotations: summary: 请求延迟过高 description: P95请求延迟超过10秒当前值 {{ $value }}秒 # 服务错误率过高告警 - alert: HighErrorRate expr: rate(vllm:request_failures_total[5m]) / rate(vllm:num_requests_total[5m]) 0.05 for: 2m labels: severity: critical annotations: summary: 服务错误率过高 description: 请求错误率超过5%当前值 {{ $value | humanizePercentage }} EOF更新Prometheus配置引用这个告警规则文件# 在prometheus.yml中添加 rule_files: - alerts.yml alerting: alertmanagers: - static_configs: - targets: # - alertmanager:9093 # 如果需要Alertmanager可以取消注释重启Prometheus使配置生效。5.2 在Grafana中配置告警通知如果你希望收到告警通知可以在Grafana中配置点击Alerting → Contact points → Add contact point选择通知方式比如Email邮件通知SlackSlack消息Webhook自定义Webhook配置相应的连接信息在监控面板的图表上点击Edit → Alert → Create alert设置告警条件和通知方式6. 实际监控效果演示现在让我们看看这套监控系统在实际使用中能告诉我们什么信息。6.1 正常情况下的监控视图当你的Nanbeige4.1-3B服务正常运行时监控面板可能显示GPU利用率在50-80%之间波动取决于请求的复杂度GPU内存稳定在6-8GB对于3B参数模型请求延迟P95在2-5秒之间取决于生成长度QPS根据你的负载可能在1-10 reqs/sec之间Token生成速度20-50 tokens/sec这是模型本身的性能6.2 异常情况识别当出现问题时监控面板能帮你快速定位场景一GPU内存泄漏现象GPU内存使用量持续上升不释放监控表现GPU Memory Usage图表持续向上最终接近100%可能原因vLLM的缓存管理问题或者请求序列过长解决方法重启服务或者检查是否有异常请求场景二请求堆积现象用户反馈响应慢监控表现Request Latency图表飙升QPS下降可能原因GPU利用率已达100%或者系统资源不足解决方法查看GPU Utilization和系统资源图表确认瓶颈场景三服务异常现象部分请求失败监控表现Error Rate图表显示错误率上升可能原因模型推理错误或者vLLM内部错误解决方法查看服务日志定位具体错误信息6.3 性能优化参考通过长期监控你还可以获得优化服务的 insights最佳批量大小观察不同批量大小下的GPU利用率和延迟找到平衡点合适生成长度根据Token生成速度建议用户设置合理的max_tokens扩容时机当GPU利用率持续高于80%且延迟开始上升时考虑扩容模型选择如果发现3B模型在某些任务上性能不足可以考虑升级到更大模型7. 监控系统的维护和优化搭建好监控系统只是第一步长期维护同样重要。7.1 数据保留策略Prometheus默认只保留15天的数据对于长期趋势分析可能不够。你可以调整数据保留时间# 在prometheus.yml中添加 storage: tsdb: retention: time: 90d # 保留90天数据或者考虑设置Prometheus的长期存储比如ThanosPrometheus的高可用长期存储方案Cortex云原生的Prometheus长期存储MimirGrafana Labs开源的长期存储方案7.2 监控系统本身的监控监控系统本身也需要被监控确保Prometheus状态监控Prometheus的采集是否正常Grafana状态确保Grafana服务可用磁盘空间监控时序数据的磁盘使用量资源使用监控Prometheus和Grafana的CPU、内存使用7.3 定期审查和优化建议每月进行一次监控系统审查告警有效性检查告警是否准确减少误报指标优化删除不再需要的指标减少存储压力面板更新根据业务变化调整监控面板性能调优优化PromQL查询提高查询效率8. 总结通过今天的学习我们为Nanbeige4.1-3B vLLM服务搭建了一套完整的监控系统。让我们回顾一下关键收获8.1 监控的价值再认识监控不是“有了更好”的装饰品而是服务稳定运行的“必需品”。通过这套系统你能够实时掌握服务状态不再需要手动查日志所有关键指标一目了然快速定位问题当服务出现异常时能快速找到问题根源数据驱动决策基于监控数据做出扩容、优化等决策提升用户体验通过监控优化服务性能最终提升用户满意度8.2 关键实施要点在实施过程中有几个关键点需要特别注意指标选择要精准不是监控越多越好要关注核心业务指标告警设置要合理避免告警疲劳设置合理的阈值和持续时间可视化要直观Grafana面板要能让非技术人员也能看懂系统要可持续考虑数据保留、存储成本、维护成本8.3 下一步建议如果你已经成功搭建了监控系统我建议你深入探索PromQL学习更复杂的查询语句挖掘更多 insights设置自动化响应结合Alertmanager和自动化脚本实现自动恢复建立监控文化在团队中分享监控数据让数据驱动成为习惯考虑AIOps探索AI在运维监控中的应用实现智能告警和根因分析监控系统的建设是一个持续的过程随着业务的发展你需要不断调整和优化。但有了今天的基础你已经迈出了最重要的一步——从“盲人摸象”到“心中有数”。现在当有人问你“服务跑得怎么样”时你可以自信地打开Grafana面板用数据说话。这不仅提升了你的运维能力也为服务的稳定性和可靠性提供了坚实保障。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。
