Qwen3-4B部署监控：Prometheus集成实战指南-平芜编程栈

Qwen3-4B部署监控：Prometheus集成实战指南

1. 为什么需要监控Qwen3-4B服务

你刚把Qwen3-4B-Instruct-2507跑起来了——网页能打开、提示词能响应、生成结果也挺像样。但过了一小时，用户反馈变慢；又过两小时，API开始超时；再刷新一次，服务直接503了。你打开终端一看，GPU显存爆了，但没人提前告诉你。

这不是个例。大模型推理服务不像传统Web服务那样“稳如老狗”，它对GPU内存、显存带宽、请求队列、上下文长度极度敏感。一次256K长文本的并发请求，可能瞬间吃光4090D的24GB显存；一段未清理的会话缓存，可能让vLLM的KV Cache持续膨胀直至OOM。

而Qwen3-4B-Instruct-2507作为阿里开源的文本生成大模型，恰恰以强指令遵循、256K长上下文支持、多语言长尾知识覆盖见长——这些能力，正是压测和监控最容易暴露问题的地方。

所以，部署完成只是起点，可观测性才是生产可用的底线。本文不讲概念，不堆术语，只带你用最轻量、最落地的方式，把Prometheus接入你的Qwen3-4B服务，实现：

GPU显存实时告警（比如 >92% 持续30秒就发通知）
每秒请求数（RPS）与平均延迟双指标联动分析
长上下文请求自动标记并单独监控
无需改一行模型代码，5分钟完成集成

2. 环境准备与基础部署确认

2.1 确认Qwen3-4B服务已就绪

你提到的部署方式很典型：在支持镜像一键部署的平台（如CSDN星图、AutoDL或自建K8s集群）上，选择Qwen3-4B-Instruct-2507镜像，使用单卡4090D，等待自动启动后通过“我的算力”进入网页推理界面。

我们先验证服务是否真正健康运行，而不是仅“能访问”。

打开终端，执行：

# 检查服务进程是否存活（假设你用的是vLLM或TGI启动） ps aux | grep -E "(vllm|text-generation-inference)" # 检查端口监听（常见为8000或8080） lsof -i :8000 # 发送一个最小化健康检查请求（替换YOUR_ENDPOINT） curl -X GET "http://localhost:8000/health" # 正常应返回 {"status": "ok"} 或类似

注意：如果返回Connection refused或超时，请先暂停本指南，回到部署环节确认日志中是否有CUDA out of memory或Failed to load model等关键错误。监控不能修复启动失败的服务，只能帮你早发现、快定位。

2.2 安装Prometheus与配套工具

我们采用最简路径：不引入Grafana（初期可读原始指标）、不配置远程存储（本地文件足够）、不碰K8s Operator（单机部署够用）。

在同台服务器（或监控节点）执行：

# 创建监控目录 mkdir -p ~/qwen-monitor && cd ~/qwen-monitor # 下载最新稳定版Prometheus（Linux x86_64） wget https://github.com/prometheus/prometheus/releases/download/v2.49.1/prometheus-2.49.1.linux-amd64.tar.gz tar -xzf prometheus-2.49.1.linux-amd64.tar.gz mv prometheus-2.49.1.linux-amd64 prometheus # 创建基础配置文件 cat > prometheus.yml << 'EOF' global: scrape_interval: 15s evaluation_interval: 15s scrape_configs: - job_name: 'qwen3-4b' static_configs: - targets: ['localhost:8000'] # 假设Qwen服务暴露/metrics端点 metrics_path: '/metrics' scheme: http - job_name: 'node_exporter' static_configs: - targets: ['localhost:9100'] EOF

别急着启动——此时Prometheus还无法从Qwen服务拉取指标，因为Qwen3-4B默认不暴露/metrics端点。我们需要给它“加个探针”。

3. 为Qwen3-4B注入监控能力（零代码改造）

3.1 为什么不用修改模型代码？

Qwen3-4B-Instruct-2507通常基于vLLM或Text Generation Inference（TGI）框架部署。这两个主流推理引擎都原生支持Prometheus指标导出，只需启用对应参数，无需动一行Python代码。

若你用的是vLLM（推荐，对256K上下文更友好）

启动命令中加入--enable-metrics和--metrics-export-port：

# 原始启动命令（示例） python -m vllm.entrypoints.api_server \ --model Qwen/Qwen3-4B-Instruct-2507 \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --host 0.0.0.0 \ --port 8000 # 加入监控后（只需两处新增） python -m vllm.entrypoints.api_server \ --model Qwen/Qwen3-4B-Instruct-2507 \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --host 0.0.0.0 \ --port 8000 \ --enable-metrics \ # 启用指标收集 --metrics-export-port 8001 # 单独开一个端口暴露/metrics

提示：--metrics-export-port必须与主服务端口（--port）不同，避免冲突。这里设为8001。

若你用的是TGI（Text Generation Inference）

在启动命令中添加--metrics-exporter prometheus：

# 原始TGI命令（示例） text-generation-inference --model-id Qwen/Qwen3-4B-Instruct-2507 --num-shard 1 # 加入监控后 text-generation-inference \ --model-id Qwen/Qwen3-4B-Instruct-2507 \ --num-shard 1 \ --metrics-exporter prometheus \ --port 8000

TGI会自动在:8000/metrics暴露指标，无需额外端口。

3.2 验证指标端点是否生效

重启Qwen服务后，立刻验证：

# 访问指标端点（根据你选的方案调整端口） curl -s http://localhost:8001/metrics | head -20 # 或 curl -s http://localhost:8000/metrics | head -20

你应该看到类似输出：

# HELP vllm:gpu_cache_usage_ratio GPU KV cache usage ratio # TYPE vllm:gpu_cache_usage_ratio gauge vllm:gpu_cache_usage_ratio{gpu="0"} 0.342 # HELP vllm:request_success_total Total number of successful requests # TYPE vllm:request_success_total counter vllm:request_success_total 127

出现vllm:或tgi:开头的指标，说明注入成功。

4. Prometheus采集配置与关键指标解读

4.1 更新Prometheus配置指向正确端点

根据你选择的方案，编辑prometheus.yml中的qwen3-4bjob：

vLLM方案：targets 改为['localhost:8001']，metrics_path 保持/metrics
TGI方案：targets 保持['localhost:8000']

更新后：

- job_name: 'qwen3-4b' static_configs: - targets: ['localhost:8001'] # vLLM用8001；TGI用8000 metrics_path: '/metrics' scheme: http

4.2 启动Prometheus并访问UI

# 启动（后台运行） nohup ./prometheus/prometheus --config.file=prometheus.yml --web.listen-address=":9090" > prometheus.log 2>&1 & # 查看是否启动成功 tail -n 10 prometheus.log | grep "Server is ready"

打开浏览器访问http://你的服务器IP:9090，点击左上角“Graph”，在搜索框输入：

vllm:gpu_cache_usage_ratio{gpu="0"}

回车，点击“Execute”，再点“Graph”标签页——你会看到一条随时间波动的曲线，这就是GPU KV Cache占用率。

4.3 必须关注的5个核心指标（小白也能看懂）

指标名（vLLM为例）	它在告诉你什么	健康阈值	怎么快速查
`vllm:gpu_cache_usage_ratio{gpu="0"}`	显存里有多少比例被KV Cache占了？越高越危险	<0.85（留15%余量防突发）	直接输入指标名查询
`vllm:gpu_memory_utilization_ratio{gpu="0"}`	整块GPU显存用了多少？含模型权重+KV Cache+临时缓冲	<0.92	同上
`vllm:request_success_total`	成功响应了多少次请求？看趋势比看绝对值重要	应随时间稳定上升	输入后点“Table”，看最新值
`vllm:time_in_queue_seconds_sum / vllm:time_in_queue_seconds_count`	请求排队等了多久？高值=服务过载	<0.5秒（理想），>2秒需警惕	在查询框输入： `rate(vllm:time_in_queue_seconds_sum[5m]) / rate(vllm:time_in_queue_seconds_count[5m])`
`vllm:num_requests_running`	当前正在处理几个请求？结合`num_requests_waiting`看负载均衡	running + waiting < 8（4090D建议值）	`vllm:num_requests_running`

小技巧：在Prometheus UI里，把鼠标悬停在指标名上，会显示该指标的完整说明和标签，比查文档快得多。

5. 实战告警：当长上下文请求拖垮服务时自动通知

Qwen3-4B的256K上下文是亮点，也是雷区。一个用户提交20万token的PDF摘要请求，可能让服务卡死30秒，期间其他所有请求排队——而默认指标不区分请求长度。

我们用Prometheus的Recording Rules（预计算规则）来解决：

5.1 创建长上下文专用指标

编辑prometheus.yml，在末尾添加：

rule_files: - "alerts.yml" # ...（原有内容保持不变）

然后创建alerts.yml：

groups: - name: qwen-long-context-alerts rules: - record: qwen:long_context_request_ratio expr: | sum(rate(vllm:request_success_total{prompt_tokens_total > 100000}[5m])) by (job) / sum(rate(vllm:request_success_total[5m])) by (job) labels: severity: warning - alert: QwenLongContextOverload expr: qwen:long_context_request_ratio > 0.3 for: 2m labels: severity: critical annotations: summary: "Qwen3-4B 长上下文请求占比过高（当前{{ $value | humanizePercentage }}）" description: "过去2分钟内，>100K token的请求占比超30%，可能导致整体延迟飙升。请检查用户行为或限流策略。"

5.2 启动告警并测试

重启Prometheus：

killall prometheus nohup ./prometheus/prometheus --config.file=prometheus.yml --web.listen-address=":9090" > prometheus.log 2>&1 &

稍等1分钟，在Prometheus UI的Alerts标签页，你会看到QwenLongContextOverload处于inactive状态——说明规则已加载。

现在，用脚本模拟一个长请求（注意：仅测试用，勿在生产环境高频触发）：

# 发送一个128K token的虚构请求（实际需构造长文本） curl -X POST "http://localhost:8000/generate" \ -H "Content-Type: application/json" \ -d '{ "prompt": "A"'"$(printf ' a' {1..120000})"'", "max_tokens": 50 }'

等待2分钟后，回到Alerts页面，状态应变为firing。你已拥有了第一个业务语义级告警。