Nanbeige4.1-3B vLLM服务监控：Prometheus+Grafana显存/请求/延迟指标接入

1. 引言：为什么需要监控你的大模型服务？

想象一下，你刚刚用vLLM成功部署了Nanbeige4.1-3B模型，并通过Chainlit搭建了一个漂亮的前端界面。用户开始提问，模型流畅地回答，一切看起来都很完美。

但几天后，你发现服务响应越来越慢，有时甚至直接崩溃。用户抱怨不断，你却一头雾水：是显存不够了？还是请求太多把服务压垮了？或者是某个请求处理时间过长，拖累了整个系统？

这就是为什么我们需要监控——你不能等到服务出问题了才去排查，而是要在问题发生前就发现苗头。

今天我要分享的，就是如何为你的Nanbeige4.1-3B vLLM服务搭建一套完整的监控系统。这套系统能让你实时看到：

• 显存使用情况：模型占用了多少GPU内存？还有多少可用？
• 请求处理性能：每秒处理多少个请求？平均响应时间是多少？
• 服务健康状态：服务是否在正常运行？有没有异常错误？

我们将使用Prometheus来收集这些指标，然后用Grafana把它们变成直观的图表。听起来有点技术？别担心，我会用最直白的方式，带你一步步完成整个配置过程。

2. 监控系统架构：Prometheus+Grafana如何工作？

在开始动手之前，我们先花几分钟了解一下这套监控系统是怎么运转的。理解了原理，配置起来就会容易得多。

2.1 核心组件介绍

整个监控系统由三个主要部分组成：

1. vLLM服务（被监控对象）

   • 这是我们部署的Nanbeige4.1-3B模型服务
   • vLLM内置了指标暴露功能，可以把运行数据通过HTTP接口提供出来

2. Prometheus（数据收集器）

   • 这是一个专门收集和存储时间序列数据的工具
   • 它会定期（比如每15秒）去vLLM服务的指标接口"拉取"数据
   • 把所有收集到的数据存储在自己的数据库中

3. Grafana（数据可视化平台）

   • 这是一个强大的仪表盘工具
   • 它从Prometheus读取数据，然后生成各种图表
   • 你可以自定义仪表盘，想怎么看数据就怎么看

2.2 数据流向图

用最简单的话来说，数据是这样流动的：

vLLM服务（产生数据） → Prometheus（收集存储数据） → Grafana（展示数据）

2.3 我们需要监控哪些指标？

对于一个大模型服务，最关键的指标主要有三类：

指标类型	具体指标	为什么重要
资源使用	GPU显存使用量、GPU利用率	知道显存还剩多少，避免服务因OOM崩溃
请求性能	请求速率(QPS)、请求延迟、请求队列长度	了解服务处理能力，发现性能瓶颈
服务状态	服务是否存活、错误率、请求成功率	确保服务稳定运行，及时发现问题

现在你对整个系统有了基本了解，接下来我们就开始动手配置。

3. 第一步：配置vLLM暴露监控指标

要让Prometheus能够收集数据，首先需要让vLLM服务把运行指标"暴露"出来。vLLM很贴心地内置了这个功能，我们只需要在启动时加几个参数就行。

3.1 检查当前vLLM服务配置

首先，我们看看你现在的vLLM服务是怎么启动的。通常启动命令类似这样：

python -m vllm.entrypoints.openai.api_server \
    --model /path/to/nanbeige4.1-3b \
    --served-model-name nanbeige4.1-3b \
    --port 8000

这是最基本的启动方式，但没有开启监控指标。我们需要修改一下。

3.2 启用Prometheus指标端点

在启动命令中添加--metrics-export-port参数，指定一个端口来提供指标数据：

python -m vllm.entrypoints.openai.api_server \
    --model /path/to/nanbeige4.1-3b \
    --served-model-name nanbeige4.1-3b \
    --port 8000 \
    --metrics-export-port 8001

参数解释：

• --port 8000：这是API服务端口，Chainlit通过这个端口调用模型
• --metrics-export-port 8001：这是指标暴露端口，Prometheus通过这个端口获取监控数据

两个端口互不干扰，一个用于业务，一个用于监控。

3.3 验证指标是否正常暴露

启动服务后，打开浏览器或者用curl命令访问指标端点：

curl http://localhost:8001/metrics

如果配置正确，你会看到类似这样的输出（内容很多，只展示开头部分）：

# HELP vllm:num_requests_total Total number of requests processed
# TYPE vllm:num_requests_total counter
vllm:num_requests_total 42

# HELP vllm:num_pending_requests Current number of pending requests
# TYPE vllm:num_pending_requests gauge
vllm:num_pending_requests 2

# HELP vllm:gpu_memory_utilization GPU memory utilization
# TYPE vllm:gpu_memory_utilization gauge
vllm:gpu_memory_utilization 0.75

这些就是vLLM暴露的各种监控指标。看到这个输出，说明第一步已经成功了。

3.4 常用vLLM监控指标说明

vLLM会暴露很多指标，对于日常监控，我们主要关注这几个：

指标名称	类型	说明
vllm:num_requests_total	计数器	总共处理了多少个请求
vllm:num_pending_requests	测量值	当前正在等待处理的请求数
vllm:request_latency_seconds	直方图	请求处理延迟分布
vllm:gpu_memory_utilization	测量值	GPU显存使用率（0-1之间）
vllm:gpu_utilization	测量值	GPU计算利用率
vllm:num_running_requests	测量值	当前正在处理的请求数

这些指标已经足够我们了解服务的运行状况了。

4. 第二步：部署和配置Prometheus

现在vLLM已经在提供数据了，接下来我们需要部署Prometheus来收集这些数据。

4.1 安装Prometheus

如果你用的是Linux系统，安装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/

4.2 配置Prometheus监控vLLM

Prometheus的配置文件是prometheus.yml，我们需要修改它，告诉Prometheus去监控我们的vLLM服务。

用文本编辑器打开配置文件：

nano prometheus.yml

找到scrape_configs部分，添加一个新的job来监控vLLM：

global:
  scrape_interval: 15s  # 每15秒收集一次数据
  evaluation_interval: 15s

scrape_configs:
  # 监控vLLM服务
  - job_name: 'vllm-nanbeige'
    static_configs:
      - targets: ['localhost:8001']  # vLLM的指标端口
        labels:
          service: 'nanbeige4.1-3b'
          instance: 'vllm-service-01'
    
  # 监控Prometheus自己（可选）
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

配置说明：

• scrape_interval: 15s：每15秒收集一次数据，这个频率比较合适，既不会太频繁影响性能，又能及时发现问题
• targets: ['localhost:8001']：告诉Prometheus去哪里拉取数据，这里填vLLM的指标端口
• labels：给数据打上标签，方便在Grafana中筛选和分组

4.3 启动Prometheus

保存配置文件后，启动Prometheus：

# 在前台启动（方便查看日志）
./prometheus --config.file=prometheus.yml

# 或者在后台启动
nohup ./prometheus --config.file=prometheus.yml > prometheus.log 2>&1 &

启动后，Prometheus默认会在9090端口提供服务。打开浏览器访问http://localhost:9090，你应该能看到Prometheus的Web界面。

4.4 验证数据收集

在Prometheus的Web界面中，点击顶部菜单的"Status" → "Targets"，你应该能看到我们刚配置的vLLM监控目标：

vllm-nanbeige (1/1 up)

状态显示"UP"表示Prometheus已经成功连接到vLLM并开始收集数据了。

你还可以在"Graph"页面输入一些查询来测试，比如：

• vllm:gpu_memory_utilization：查看GPU显存使用率
• rate(vllm:num_requests_total[5m])：查看最近5分钟的平均请求速率

如果能看到数据曲线，说明一切正常！

5. 第三步：部署和配置Grafana仪表盘

数据已经收集好了，但看Prometheus的原始数据不太直观。接下来我们用Grafana把这些数据变成漂亮的图表。

5.1 安装Grafana

Grafana的安装也很简单：

# Ubuntu/Debian系统
sudo apt-get install -y software-properties-common
sudo add-apt-repository "deb https://packages.grafana.com/oss/deb stable main"
sudo apt-get update
sudo apt-get install grafana

# 或者使用Docker
docker run -d -p 3000:3000 --name=grafana grafana/grafana

5.2 配置Grafana连接Prometheus

1. 启动Grafana服务

   sudo systemctl start grafana-server
   sudo systemctl enable grafana-server  # 设置开机自启
   

2. 访问Grafana 打开浏览器访问http://localhost:3000，默认用户名和密码都是admin。首次登录会要求修改密码。

3. 添加数据源

   • 点击左侧菜单的"Configuration"（小齿轮图标）→ "Data Sources"
   • 点击"Add data source"，选择"Prometheus"
   • 在URL处填写http://localhost:9090（Prometheus的地址）
   • 点击"Save & Test"，应该显示"Data source is working"

5.3 创建vLLM监控仪表盘

现在我们来创建一个专门监控Nanbeige4.1-3B服务的仪表盘。我会提供一个完整的配置，你直接导入就行。

首先，创建一个新的仪表盘：

1. 点击左侧"+"图标 → "Dashboard"
2. 点击"Add new panel"（添加新面板）

5.3.1 面板1：GPU显存使用情况

这个面板显示GPU显存的使用情况，是我们最关心的指标之一。

配置步骤：

1. 在"Query"选项卡中，数据源选择"Prometheus"
2. 输入查询语句：vllm:gpu_memory_utilization
3. 在右侧"Panel options"中：
   • Title：填写"GPU显存使用率"
   • Unit：选择"percent (0-1)"
   • Min：0，Max：1
   • 显示值：当前值、最大值、最小值
4. 在"Visualization"中选择"Stat"（统计值）或"Gauge"（仪表盘）样式

查询语句解释：

• vllm:gpu_memory_utilization：这个指标值在0到1之间，表示显存使用百分比
• 如果值是0.75，表示显存使用了75%

5.3.2 面板2：请求处理性能

这个面板显示服务的请求处理能力。

创建两个查询：

1. 当前请求数：vllm:num_running_requests

   • 显示当前正在处理的请求数量

2. 等待队列长度：vllm:num_pending_requests

   • 显示在队列中等待处理的请求数量

配置建议：

• 使用"Time series"图表类型
• 添加阈值线：如果等待队列超过5个请求，显示为警告（黄色）；超过10个，显示为严重（红色）
• 标题："请求处理状态"

5.3.3 面板3：请求速率和延迟

这个面板显示服务的吞吐量和响应速度。

创建两个查询：

1. 请求速率(QPS)：

   rate(vllm:num_requests_total[5m])
   

   • 显示最近5分钟平均每秒处理的请求数

2. 请求延迟(P95)：

   histogram_quantile(0.95, rate(vllm:request_latency_seconds_bucket[5m]))
   

   • 显示95%的请求在多少秒内完成

为什么用P95而不是平均值？

• 平均值容易被极端值影响，P95更能反映大多数用户的体验
• 如果P95延迟很高，说明有少量请求处理很慢，需要关注

5.3.4 面板4：历史请求趋势

这个面板显示请求量的变化趋势，帮助你了解使用模式。

查询语句：

sum(rate(vllm:num_requests_total[5m])) by (service)

配置建议：

• 使用"Time series"图表，选择"Lines"样式
• 时间范围选择"Last 24 hours"或"Last 7 days"
• 添加注释：在请求量突增的时间点添加注释，说明可能的原因（比如营销活动、新功能上线等）

5.4 仪表盘布局优化

把上面四个面板合理排列，一个完整的监控仪表盘就完成了：

+-------------------+-------------------+
| GPU显存使用率     | 请求处理状态      |
| (仪表盘)          | (时序图)          |
+-------------------+-------------------+
| 请求速率和延迟    | 历史请求趋势      |
| (双轴图)         | (时序图)          |
+-------------------+-------------------+

布局技巧：

1. 最重要的放上面：GPU显存和当前请求状态是最需要实时关注的，放在第一行
2. 相关指标放一起：请求速率和延迟都反映性能，放在同一个面板用双轴图显示
3. 历史趋势放下面：历史数据主要用于分析，不需要实时紧盯，放在第二行

5.5 设置告警规则（可选但推荐）

监控不仅要看，还要能在出问题时及时通知你。Grafana支持设置告警：

1. 在任意面板上，点击标题 → "Edit" → "Alert"
2. 设置告警条件，比如：
   • GPU显存使用率 > 90% 持续5分钟
   • 请求队列长度 > 10 持续2分钟
   • P95延迟 > 5秒 持续3分钟
3. 配置通知渠道：可以发送到邮箱、Slack、钉钉等

设置好告警后，你就不用一直盯着仪表盘了。系统会在出现问题时主动通知你。

6. 实际监控效果展示

配置完成后，你的监控仪表盘大概会长这样（我用文字描述一下）：

顶部状态栏：

• 当前时间：2024-01-15 14:30:00
• 数据刷新间隔：15秒
• 服务状态：✅ 正常

第一行面板：

• GPU显存使用率：显示一个圆形仪表盘，指针指向0.68（68%），颜色为绿色（安全范围）
• 请求处理状态：显示两条曲线，蓝色线（正在处理）在2-3之间波动，橙色线（等待队列）大部分时间为0，偶尔跳到1

第二行面板：

• 请求速率和延迟：左侧Y轴显示QPS在8-12之间波动，右侧Y轴显示P95延迟在0.8-1.2秒之间
• 历史请求趋势：显示24小时内的请求量变化，可以看到白天工作时间请求较多，夜间较少

关键洞察：

1. GPU显存使用稳定在70%以下，还有充足余量
2. 请求处理及时，很少出现排队等待
3. 响应速度在1秒左右，用户体验良好
4. 请求模式符合预期，白天活跃夜间空闲

有了这个仪表盘，你就能：

• 一眼看出服务状态：所有关键指标一目了然
• 快速定位问题：如果某个指标异常，直接就能看到
• 分析使用模式：了解什么时间段请求最多，提前做好准备
• 评估扩容需求：根据历史趋势预测未来需求

7. 总结：从监控到洞察

通过今天的学习，你已经成功为Nanbeige4.1-3B vLLM服务搭建了一套完整的监控系统。让我们回顾一下关键要点：

7.1 你学到了什么？

1. 监控的重要性：没有监控的服务就像闭着眼睛开车，不知道什么时候会出问题
2. vLLM指标暴露：只需要一个启动参数，就能让vLLM提供丰富的运行数据
3. Prometheus数据收集：配置简单，稳定可靠的时间序列数据库
4. Grafana数据可视化：把枯燥的数据变成直观的图表，一眼看懂服务状态
5. 关键监控指标：GPU显存、请求速率、处理延迟、队列长度，这四个指标足够覆盖大部分场景

7.2 实际应用建议

根据我的经验，这里有几点实用建议：

对于刚上线的服务：

• 先关注GPU显存和错误率，确保服务稳定运行
• 设置显存使用超过85%的告警，提前预警
• 记录正常的性能基线，方便后续对比

对于成熟的服务：

• 分析请求模式，优化资源分配（比如在低峰期减少实例）
• 设置更精细的告警（比如延迟突增、错误率上升）
• 定期查看历史趋势，预测扩容需求

常见问题排查：

• 响应变慢：先看GPU显存是否已满，再看请求队列是否堆积
• 服务崩溃：检查显存使用历史，可能是内存泄漏或请求过载
• 性能波动：对比请求量变化，可能是正常流量波动或异常攻击

7.3 下一步可以做什么？

这套监控系统已经能解决80%的问题，如果你还想更深入：

1. 添加业务指标：除了系统指标，还可以监控业务相关的指标，比如：

   • 不同用户类型的请求分布
   • 不同问题类型的处理时间
   • 回答质量评分（如果有的话）

2. 集成日志系统：把vLLM的日志也收集起来，和监控指标关联分析

3. 设置自动化响应：当监控到异常时，自动执行一些修复操作（比如重启服务）

4. 多实例监控：如果你部署了多个vLLM实例，可以在Grafana中对比它们的性能

监控不是一次性的工作，而是一个持续的过程。随着你对服务了解的深入，你会不断调整监控指标和告警规则，让系统更加智能和可靠。

现在，你的Nanbeige4.1-3B服务不再是一个"黑盒"，而是一个透明、可控、可观测的系统。你可以安心睡觉，因为你知道有任何问题，监控系统都会及时告诉你。

---

获取更多AI镜像

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