通义千问3-Reranker-0.6B实战教程：Prometheus监控指标接入+QPS实时看板

你是不是也遇到过这样的问题：部署了一个AI服务，比如一个重排序模型，但心里完全没底——它现在到底忙不忙？每秒能处理多少请求？内存和显存还够用吗？服务会不会突然卡住？

以前，我们只能靠猜，或者等用户投诉了才发现问题。今天，我就带你彻底解决这个痛点。我们将把通义千问3-Reranker-0.6B这个强大的重排序模型，变成一个“透明”的服务——给它装上监控的眼睛，让你能实时看到它的心跳。

通过这篇教程，你将学会如何为这个模型服务接入Prometheus监控，并搭建一个直观的QPS（每秒查询率）实时看板。从此，模型服务的运行状态一目了然。

在开始动手之前，我们先搞清楚为什么要做这件事。你可能觉得：“我的模型跑得好好的，干嘛要监控？”

我给你几个必须监控的理由：

第一，性能瓶颈无处藏身。 模型服务不是部署完就万事大吉了。用户量上来后ÿ千问 Qwen 教程0c;QPS是多少？平均响应时间多长？GPU利用率高不高？这些数据你不监控就永远不知道。我曾经遇到过，一个服务白天运行正常，晚上突然变慢，查了半天才发现是定时任务占用了大量CPU。

第二，资源使用心中有数。 通义千问3-Reranker-0.6B需要2-3GB的GPU显存，但实际用了多少？内存占用会不会随着时间增长？有了监控，你就能在资源不足前提前预警，而不是等服务崩溃了再手忙脚乱。

第三，问题排查有迹可循。 用户反馈“服务慢了”，你怎么排查？有了历史监控数据，你可以回溯到问题发生的时间点，看看当时的QPS、响应时间、错误率，问题原因可能一目了然。

第四，容量规划有据可依。 当业务增长时，你需要知道什么时候该扩容。是QPS到了瓶颈，还是显存不够用了？监控数据会告诉你答案。

简单说，监控就是把“黑盒”变成“白盒”，让你对自己的服务了如指掌。

2.1 确保模型服务正常运行

首先，确保你的通义千问3-Reranker-0.6B服务已经启动并运行正常。如果你还没部署，可以快速走一遍流程：

启动成功后，你应该能在浏览器访问 看到Gradio界面。试着输入一个查询和几个文档，看看重排序功能是否正常。

2.2 安装监控所需组件

我们需要安装几个关键的监控组件：

如果你没有Docker，也可以直接安装：

现在我们来改造模型服务，让它暴露监控指标。

3.1 创建监控中间件

首先，我们创建一个监控中间件，它会拦截所有请求并记录相关指标：

3.2 集成监控到主应用

接下来，我们需要修改主应用文件，集成监控功能：

3.3 配置Prometheus采集指标

现在我们需要配置Prometheus来采集模型服务暴露的指标。创建Prometheus配置文件：

启动Prometheus：

现在，你可以访问 查看Prometheus的Web界面。在查询框中输入 ，就能看到模型服务的请求总数了。

Prometheus的数据需要可视化才好看。我们来用Grafana创建一个漂亮的监控看板。

4.1 配置Grafana数据源

首先，访问Grafana界面（），默认用户名密码是 。

1. 点击左侧菜单的 Configuration → Data Sources
2. 点击 Add data source，选择 Prometheus
3. 在URL中输入 （Prometheus地址）
4. 点击 Save & Test，应该显示”Data source is working”

4.2 创建QPS实时看板

现在创建我们的核心看板——QPS实时监控。

点击左侧菜单的 Dashboards → New dashboard → Add visualization。

面板1：实时QPS曲线

1. 在查询框中输入：

   这个公式计算每分钟的请求率，即QPS。

2. 在右侧面板设置中：
   • Title: 实时QPS
   • Unit: requests/sec
   • Min interval: 10s
   • 选择漂亮的曲线样式

面板2：请求延迟分布

1. 查询输入：

   这个计算95%的请求延迟。

2. 面板设置：
   • Title: 95%请求延迟
   • Unit: seconds
   • Min: 0

面板3：活跃请求数

1. 查询输入：

2. 面板设置：
   • Title: 当前活跃请求
   • Visualization: Stat（显示为单个大数字）

面板4：请求状态分布

1. 查询输入：

2. 面板设置：
   • Title: 请求状态分布
   • Visualization: Pie chart

面板5：资源使用情况

1. GPU内存查询：

2. 系统内存查询：

3. 面板设置：
   • Title: 内存使用 (GB)
   • 可以放在同一个图表中，用不同颜色表示

面板6：批处理大小分布

1. 查询输入：

2. 面板设置：
   • Title: 批处理大小分布
   • Visualization: Heatmap

4.3 看板布局优化

把上面这些面板拖拽排列，形成一个完整的监控看板。我建议的布局是：

• 第一行：实时QPS（大图） + 活跃请求数（小卡片）
• 第二行：请求延迟 + 请求状态分布
• 第三行：内存使用情况
• 第四行：批处理大小分布

点击右上角的 Save dashboard，给你的看板起个名字，比如”Qwen Reranker监控看板”。

现在，让我们测试一下整个监控系统是否工作正常。

5.1 模拟请求流量

我们写一个简单的脚本，模拟用户请求：

运行这个脚本：

5.2 观察监控看板

在脚本运行的同时，打开Grafana看板（），你会看到：

1. 实时QPS曲线：会从0开始上升，随着流量模拟的变化而波动
2. 活跃请求数：在请求处理期间会有数值
3. 请求延迟：可能会随着流量增加而略有上升
4. 内存使用：应该保持相对稳定

这就是监控的魅力——你能实时看到服务对流量变化的反应。

监控不仅要看，还要能在出问题时及时通知我们。我们来配置几个关键的告警。

6.1 配置Prometheus告警规则

创建告警规则文件：

更新Prometheus配置，添加告警规则：

重启Prometheus使配置生效。

6.2 配置Grafana告警

如果你不想用Alertmanager，Grafana也内置了告警功能：

1. 在Grafana看板中，点击任意面板的标题
2. 选择 Edit → Alert → Create alert
3. 设置告警条件，比如：
   • 当 > 20 持续2分钟
4. 配置通知渠道（需要先在Grafana中配置邮件、Slack等）

上面的教程是在单机环境下演示的。在实际生产环境中，你还需要考虑以下几点：

7.1 监控架构优化

对于生产环境，我建议采用这样的架构：

关键点：

• 每个服务实例都暴露监控指标
• Prometheus从所有实例采集数据
• Grafana聚合展示所有实例的监控数据

7.2 高可用配置

1. Prometheus高可用：运行多个Prometheus实例，或者使用Thanos、Cortex等方案
2. Grafana高可用：多实例+负载均衡
3. 监控数据持久化：确保监控数据不会丢失

7.3 安全考虑

1. 访问控制：给Grafana和Prometheus设置认证
2. 网络隔离：监控服务不要暴露在公网
3. 数据加密：如果监控数据敏感，考虑加密传输

7.4 性能优化

1. 指标采样：对于高频指标，适当降低采样频率
2. 数据保留策略：根据存储容量设置合适的数据保留时间
3. 查询优化：避免过于复杂的PromQL查询

通过这篇教程，我们完成了一件很有价值的事情：把一个”黑盒”的AI模型服务，变成了一个完全透明的、可观测的系统。

让我们回顾一下关键收获：

第一，监控让服务状态一目了然。 现在你随时可以知道通义千问3-Reranker-0.6B服务的QPS是多少、延迟多高、资源用了多少。这种掌控感是运维AI服务的基础。

第二，问题排查变得简单高效。 当用户反馈服务慢时，你可以立即查看监控看板：是QPS突然飙升了？还是延迟变长了？或者是内存不足了？问题原因几分钟就能定位。

第三，容量规划有了数据支撑。 看着QPS曲线稳步上升，你知道什么时候该考虑扩容了。看着内存使用逐渐增长，你知道什么时候该优化代码了。

第四，告警让你高枕无忧。 配置好告警规则后，你可以在问题发生前就收到通知，而不是等用户投诉。

我特别想强调的是，这套监控方案不仅仅适用于通义千问3-Reranker-0.6B。它的设计是通用的，你可以很容易地适配到其他AI模型服务，无论是文本生成、图像处理还是语音识别。

监控不是一次性工作，而是一个持续优化的过程。随着业务发展，你可能需要调整监控指标、优化告警阈值、改进看板布局。但有了今天打下的基础，这些后续工作都会变得轻松很多。

最后，监控的最终目的不是收集数据，而是通过这些数据做出更好的决策。希望这套监控系统能帮助你更好地运维AI服务，让技术真正为业务创造价值。

获取更多AI镜像

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