Qwen3-1.7B推理监控：Prometheus集成部署实战
1. 背景与目标
随着大语言模型在实际业务场景中的广泛应用，模型推理服务的稳定性、响应性能和资源利用率成为关键运维指标。Qwen3（千问3）是阿里巴巴集团于2025年4月29日开源的新一代通义千问大语言模型系列，涵盖6款密集模型和2款混合专家（MoE）架构模型，参数量从0.6B至235B。其中，Qwen3-1.7B作为轻量级密集模型，在边缘计算、低延迟对话系统和本地化部署等场景中表现出色。
然而，仅有高性能的模型服务还不够，可观测性是保障长期稳定运行的核心能力。本文聚焦于如何为 Qwen3-1.7B 的推理服务构建完整的监控体系，重点介绍 Prometheus 的集成部署方案，实现对请求延迟、吞吐量、GPU 利用率等关键指标的实时采集与可视化。
通过本实践，读者将掌握：
- 如何在 LangChain 中调用 Qwen3-1.7B 推理服务
- 如何暴露模型推理的关键性能指标
- 如何使用 Prometheus 抓取并存储这些指标
- 构建可落地的 LLM 服务监控闭环
2. 环境准备与服务启动
2.1 启动镜像并进入 Jupyter 环境
首先，确保已获取支持 Qwen3 模型推理的 GPU 容器镜像。可通过 CSDN 星图平台或官方镜像仓库拉取包含vLLM或TGI（Text Generation Inference）推理后端的镜像。
启动容器后，访问提供的 Web URL 进入 Jupyter Notebook 环境。该环境预装了langchain_openai、prometheus_client、fastapi等必要依赖库，便于快速开发与调试。
# 示例：本地启动容器（假设使用 Docker） docker run -d \ --gpus all \ -p 8000:8000 \ -p 8888:8888 \ --name qwen3-inference \ csdn/qwen3-inference:latest访问http://<your-host>:8888即可打开 Jupyter 页面。
2.2 使用 LangChain 调用 Qwen3-1.7B 模型
在 Jupyter Notebook 中，可通过如下方式调用远程部署的 Qwen3-1.7B 模型服务：
from langchain_openai import ChatOpenAI import os chat_model = ChatOpenAI( model="Qwen3-1.7B", temperature=0.5, base_url="https://gpu-pod69523bb78b8ef44ff14daa57-8000.web.gpu.csdn.net/v1", # 替换为实际服务地址 api_key="EMPTY", # 多数开源推理服务无需密钥 extra_body={ "enable_thinking": True, "return_reasoning": True, }, streaming=True, ) # 发起测试调用 response = chat_model.invoke("你是谁？") print(response.content)注意：
base_url需根据实际部署环境替换，端口通常为8000，路径需包含/v1前缀以兼容 OpenAI API 兼容接口。
此时模型已可正常响应请求，但缺乏运行时监控能力。接下来我们将为其添加 Prometheus 监控支持。
3. 集成 Prometheus 实现推理指标监控
3.1 监控指标设计原则
对于 LLM 推理服务，核心监控维度包括：
| 维度 | 关键指标 | 说明 |
|---|---|---|
| 请求性能 | request_latency_seconds | 单次请求处理耗时 |
| 流量统计 | request_total | 总请求数，按状态码分类 |
| 并发负载 | active_requests | 当前正在处理的请求数 |
| 推理行为 | thinking_steps_count | 启用“思维链”时的推理步数 |
| 资源消耗 | gpu_utilization_percent | GPU 利用率（需外部采集） |
我们将在推理服务层暴露这些指标，并通过 Prometheus 主动抓取。
3.2 在 FastAPI 服务中集成指标暴露
假设 Qwen3-1.7B 服务基于 FastAPI + vLLM 构建，可在其主应用中引入prometheus_client来暴露/metrics接口。
安装依赖
pip install prometheus-client starlette修改主应用代码（app.py）
from fastapi import FastAPI, Request from starlette.middleware.base import BaseHTTPMiddleware from prometheus_client import Counter, Histogram, Gauge, generate_latest import time import threading app = FastAPI() # 定义 Prometheus 指标 REQUEST_COUNT = Counter( 'request_total', 'Total number of requests', ['method', 'endpoint', 'status_code'] ) REQUEST_LATENCY = Histogram( 'request_latency_seconds', 'Request latency in seconds', ['method', 'endpoint'] ) ACTIVE_REQUESTS = Gauge( 'active_requests', 'Number of active requests', ['method', 'endpoint'] ) THINKING_STEPS = Counter( 'thinking_steps_count', 'Number of thinking steps in reasoning mode' ) # 中间件：记录请求指标 class MetricsMiddleware(BaseHTTPMiddleware): async def dispatch(self, request: Request, call_next): start_time = time.time() ACTIVE_REQUESTS.labels(method=request.method, endpoint=request.url.path).inc() try: response = await call_next(request) latency = time.time() - start_time REQUEST_LATENCY.labels(method=request.method, endpoint=request.url.path).observe(latency) REQUEST_COUNT.labels( method=request.method, endpoint=request.url.path, status_code=response.status_code ).inc() return response finally: ACTIVE_REQUESTS.labels(method=request.method, endpoint=request.url.path).dec() app.add_middleware(MetricsMiddleware) # 模拟推理接口（实际对接 vLLM / TGI） @app.post("/v1/chat/completions") async def chat_completions(): # 模拟启用 thinking 模式返回多步推理 THINKING_STEPS.inc(3) # 假设本次生成包含3个推理步骤 return {"message": "Generated response with reasoning"} # 暴露 Prometheus metrics @app.get("/metrics") async def metrics(): return generate_latest(), {"Content-Type": "text/plain"}3.3 启动服务并验证指标输出
运行上述服务后，访问http://localhost:8000/metrics可看到类似以下原始指标数据：
# HELP request_total Total number of requests # TYPE request_total counter request_total{method="POST",endpoint="/v1/chat/completions",status_code="200"} 5 # HELP request_latency_seconds Request latency in seconds # TYPE request_latency_seconds histogram request_latency_seconds_sum{method="POST",endpoint="/v1/chat/completions"} 2.34 request_latency_seconds_count{method="POST",endpoint="/v1/chat/completions"} 5 # HELP active_requests Number of active requests # TYPE active_requests gauge active_requests{method="POST",endpoint="/v1/chat/completions"} 1 # HELP thinking_steps_count Number of thinking steps in reasoning mode # TYPE thinking_steps_count counter thinking_steps_count 15这表明指标已成功暴露。
4. 配置 Prometheus 抓取与存储
4.1 编写 Prometheus 配置文件
创建prometheus.yml文件，配置目标抓取任务：
global: scrape_interval: 15s evaluation_interval: 15s scrape_configs: - job_name: 'qwen3-inference' static_configs: - targets: ['<your-inference-service-ip>:8000'] metrics_path: /metrics scheme: http注意：若服务运行在容器内，请确保网络互通，IP 地址可被 Prometheus 访问。
4.2 启动 Prometheus 服务
docker run -d \ -p 9090:9090 \ -v $(pwd)/prometheus.yml:/etc/prometheus/prometheus.yml \ --name prometheus \ prom/prometheus访问http://localhost:9090打开 Prometheus Web UI，进入Targets页面确认qwen3-inference状态为 UP。
4.3 查询关键指标示例
在 Prometheus 表达式浏览器中输入以下查询语句：
平均每秒请求数（QPS）：
rate(request_total[1m])P95 请求延迟（秒）：
histogram_quantile(0.95, sum(rate(request_latency_seconds_bucket[1m])) by (le))当前活跃请求数：
active_requests每分钟平均推理步数：
rate(thinking_steps_count[1m])
这些指标可用于设置告警规则，例如当 P95 延迟超过 5 秒时触发通知。
5. 可视化与告警建议
5.1 使用 Grafana 进行可视化
推荐将 Prometheus 作为数据源接入 Grafana，创建专属的LLM Inference Dashboard，展示以下图表：
- 请求 QPS 与成功率趋势图
- 延迟分布热力图（Histogram）
- 实时活跃请求数仪表盘
- 推理步数随时间变化曲线
- 结合 Node Exporter 展示 GPU/CPU/内存使用率
5.2 建议告警规则
在 Prometheus 中配置如下告警规则（rules.yml）：
groups: - name: qwen3-inference-alerts rules: - alert: HighLatency expr: histogram_quantile(0.95, sum(rate(request_latency_seconds_bucket[1m])) by (le)) > 5 for: 2m labels: severity: warning annotations: summary: "High latency on Qwen3-1.7B inference" description: "P95 latency is above 5s" - alert: HighErrorRate expr: sum(rate(request_total{status_code!="200"}[5m])) / sum(rate(request_total[5m])) > 0.1 for: 5m labels: severity: critical annotations: summary: "High error rate detected" description: "More than 10% of requests are failing"6. 总结
6.1 核心价值回顾
本文围绕 Qwen3-1.7B 推理服务，完整实现了基于 Prometheus 的监控体系建设。主要内容包括：
- 介绍了 Qwen3-1.7B 模型的基本调用方式，通过 LangChain 快速集成
- 设计了面向 LLM 推理场景的核心监控指标体系
- 在 FastAPI 服务中嵌入 Prometheus Client，暴露
/metrics接口 - 配置 Prometheus 主动抓取指标并持久化存储
- 提供了可视化与告警的最佳实践建议
6.2 工程落地建议
- 生产环境建议分离监控组件：将 Prometheus 部署在独立节点，避免与推理服务争抢资源。
- 结合 GPU 指标增强监控维度：可通过
dcgm-exporter或nvidia-smi脚本补充 GPU 利用率、显存占用等硬件指标。 - 自动化部署：使用 Helm Chart 或 Kubernetes Operator 实现整套监控栈的声明式部署。
- 安全加固：限制
/metrics接口访问权限，防止信息泄露。
通过以上实践，可显著提升大模型服务的可观测性与运维效率，为后续性能优化与容量规划提供数据支撑。
获取更多AI镜像
想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。
