DeepSeek-R1-Distill-Qwen-1.5B监控面板搭建：Prometheus+Grafana可视化

雷鸣泽基

800人浏览 · 2026-04-29 03:41:18

雷鸣泽基 · 2026-04-29 03:41:18 发布

DeepSeek-R1-Distill-Qwen-1.5B监控面板搭建：Prometheus+Grafana可视化

当你把DeepSeek-R1-Distill-Qwen-1.5B模型用vLLM部署起来后，看着服务正常启动，测试调用也能返回结果，是不是觉得大功告成了？先别急着庆祝，这只是第一步。

模型服务跑起来只是开始，真正考验在后面。你怎么知道它现在运行得怎么样？内存用了多少？GPU利用率高不高？每秒能处理多少请求？有没有请求失败？这些关键信息如果看不到，就像开车不看仪表盘，迟早要出问题。

今天我就带你搭建一个专业的监控面板，用Prometheus+Grafana这套黄金组合，把模型服务的运行状态看得清清楚楚。这不是什么高深的技术，跟着我做，30分钟就能搞定。

1. 为什么需要监控模型服务？

你可能觉得，模型能正常返回结果不就行了吗？干嘛还要折腾监控？我给你说几个真实场景，你就明白了。

上周有个朋友找我，说他的模型服务突然变慢了，用户投诉响应时间从1秒变成了5秒。他查了半天，重启了好几次，问题还是时好时坏。最后发现是GPU内存泄漏，服务运行时间长了，内存占用越来越高，导致推理速度下降。

要是他有个监控面板，一眼就能看到GPU内存的使用趋势，问题早就解决了。

还有一次，另一个团队的服务突然挂了，他们以为是模型有问题，各种调试。后来发现是请求量突然暴增，把服务打崩了。如果有请求量的监控，就能提前扩容或者限流。

监控能帮你解决这些问题：

实时掌握服务状态：CPU、内存、GPU使用率，一目了然
快速定位问题：响应时间变长？先看GPU利用率是不是满了
容量规划依据：根据历史数据决定要不要升级硬件
服务质量保障：确保用户获得稳定、快速的响应

DeepSeek-R1-Distill-Qwen-1.5B虽然是个轻量级模型，只有1.5B参数，但在实际使用中，它的资源消耗、响应速度、稳定性都需要持续关注。特别是用vLLM部署时，vLLM有自己的内存管理机制，更需要监控来了解实际运行情况。

2. 监控方案选型：为什么是Prometheus+Grafana？

市面上监控工具不少，为什么我推荐Prometheus+Grafana这套组合？简单说就是：成熟、强大、易用。

Prometheus是个时间序列数据库，专门用来存储监控数据。它的特点是：

拉取模式：主动去各个服务拉取数据，不需要服务自己推送
多维数据模型：用标签来区分不同的监控指标，查询灵活
强大的查询语言：PromQL，能对监控数据做各种计算和分析
生态丰富：有各种 exporter，能监控几乎所有常见服务

Grafana是个数据可视化平台，能把Prometheus里的数据变成漂亮的图表。它的特点是：

拖拽式操作：点点鼠标就能创建仪表盘，不用写代码
图表类型丰富：折线图、柱状图、仪表盘、热力图，要啥有啥
告警功能：数据异常时自动发通知
社区活跃：有大量现成的仪表盘模板可以直接用

这套组合在业界用了很多年，特别适合监控微服务、容器化应用。我们的模型服务虽然不算复杂，但用这套方案能获得企业级的监控能力。

最重要的是，它们都是开源的，部署简单，资源消耗也不大。在一台普通的云服务器上就能跑起来。

3. 环境准备与组件部署

3.1 检查现有环境

首先确认你的DeepSeek-R1-Distill-Qwen-1.5B服务已经正常启动。按照你提供的步骤，应该已经完成了：

# 进入工作目录
cd /root/workspace

# 查看启动日志
cat deepseek_qwen.log

如果看到服务启动成功的日志，说明模型服务已经在运行了。默认情况下，vLLM会在8000端口提供API服务。

3.2 安装Prometheus

Prometheus的安装很简单，我们直接用官方提供的二进制包：

# 创建监控相关目录
mkdir -p /opt/monitoring
cd /opt/monitoring

# 下载Prometheus
wget https://github.com/prometheus/prometheus/releases/download/v2.51.2/prometheus-2.51.2.linux-amd64.tar.gz

# 解压
tar xvf prometheus-2.51.2.linux-amd64.tar.gz
mv prometheus-2.51.2.linux-amd64 prometheus
cd prometheus

# 创建配置文件
cat > prometheus.yml << 'EOF'
global:
  scrape_interval: 15s  # 每15秒采集一次数据
  evaluation_interval: 15s  # 每15秒评估一次告警规则

# 告警规则配置
rule_files:
  # - "first_rules.yml"
  # - "second_rules.yml"

# 采集目标配置
scrape_configs:
  # Prometheus自身监控
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']
        labels:
          service: 'prometheus'

  # Node Exporter（系统监控）
  - job_name: 'node'
    static_configs:
      - targets: ['localhost:9100']
        labels:
          service: 'node-exporter'

  # vLLM模型服务监控
  - job_name: 'vllm'
    static_configs:
      - targets: ['localhost:8000']
        labels:
          service: 'deepseek-r1-model'
          model: 'DeepSeek-R1-Distill-Qwen-1.5B'
EOF

# 创建systemd服务文件
cat > /etc/systemd/system/prometheus.service << 'EOF'
[Unit]
Description=Prometheus Monitoring System
Documentation=https://prometheus.io/docs/introduction/overview/
After=network.target

[Service]
User=root
Group=root
Type=simple
ExecStart=/opt/monitoring/prometheus/prometheus \
  --config.file=/opt/monitoring/prometheus/prometheus.yml \
  --storage.tsdb.path=/opt/monitoring/prometheus/data \
  --web.console.templates=/opt/monitoring/prometheus/consoles \
  --web.console.libraries=/opt/monitoring/prometheus/console_libraries \
  --web.listen-address=:9090 \
  --web.enable-lifecycle

ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure

[Install]
WantedBy=multi-user.target
EOF

# 启动Prometheus服务
systemctl daemon-reload
systemctl start prometheus
systemctl enable prometheus

# 检查服务状态
systemctl status prometheus

如果一切正常，你现在可以通过浏览器访问 http://你的服务器IP:9090 看到Prometheus的Web界面了。

3.3 安装Node Exporter

Node Exporter用来采集系统层面的监控数据，比如CPU、内存、磁盘、网络等。

cd /opt/monitoring

# 下载Node Exporter
wget https://github.com/prometheus/node_exporter/releases/download/v1.7.0/node_exporter-1.7.0.linux-amd64.tar.gz

# 解压
tar xvf node_exporter-1.7.0.linux-amd64.tar.gz
mv node_exporter-1.7.0.linux-amd64 node_exporter
cd node_exporter

# 创建systemd服务文件
cat > /etc/systemd/system/node-exporter.service << 'EOF'
[Unit]
Description=Node Exporter
Documentation=https://github.com/prometheus/node_exporter
After=network.target

[Service]
User=root
Group=root
Type=simple
ExecStart=/opt/monitoring/node_exporter/node_exporter \
  --collector.cpu \
  --collector.diskstats \
  --collector.filesystem \
  --collector.loadavg \
  --collector.meminfo \
  --collector.netdev \
  --collector.netstat \
  --collector.stat \
  --collector.time \
  --collector.uname \
  --collector.vmstat \
  --web.listen-address=:9100

Restart=on-failure

[Install]
WantedBy=multi-user.target
EOF

# 启动Node Exporter
systemctl daemon-reload
systemctl start node-exporter
systemctl enable node-exporter

# 检查服务状态
systemctl status node-exporter

Node Exporter默认在9100端口提供服务，Prometheus会从这个端口拉取系统监控数据。

3.4 配置vLLM监控指标

vLLM内置了Prometheus监控支持，我们需要在启动vLLM时开启这个功能。如果你已经启动了vLLM服务，需要先停止，然后用新的参数重新启动。

假设你原来的启动命令是这样的：

python -m vllm.entrypoints.openai.api_server \
  --model /path/to/deepseek-r1-distill-qwen-1.5b \
  --served-model-name DeepSeek-R1-Distill-Qwen-1.5B \
  --port 8000

需要改成：

python -m vllm.entrypoints.openai.api_server \
  --model /path/to/deepseek-r1-distill-qwen-1.5b \
  --served-model-name DeepSeek-R1-Distill-Qwen-1.5B \
  --port 8000 \
  --metrics-port 8001 \
  --enable-metrics

关键参数说明：

--metrics-port 8001：指定监控指标暴露的端口
--enable-metrics：启用Prometheus指标收集

重启服务后，访问 http://localhost:8001/metrics 应该能看到vLLM的监控指标。

然后更新Prometheus配置，添加vLLM的监控目标：

# 编辑Prometheus配置文件
cat >> /opt/monitoring/prometheus/prometheus.yml << 'EOF'

  # vLLM监控指标
  - job_name: 'vllm-metrics'
    static_configs:
      - targets: ['localhost:8001']
        labels:
          service: 'vllm-metrics'
          model: 'DeepSeek-R1-Distill-Qwen-1.5B'
EOF

# 重启Prometheus
systemctl restart prometheus

3.5 安装Grafana

Grafana的安装也很简单：

# 添加Grafana仓库
apt-get install -y software-properties-common
add-apt-repository "deb https://packages.grafana.com/oss/deb stable main"
wget -q -O - https://packages.grafana.com/gpg.key | apt-key add -

# 安装Grafana
apt-get update
apt-get install -y grafana

# 启动Grafana
systemctl start grafana-server
systemctl enable grafana-server

# 检查服务状态
systemctl status grafana-server

Grafana默认在3000端口运行，首次访问 http://你的服务器IP:3000 时，用默认账号admin/admin登录，会要求你修改密码。

4. 配置Grafana数据源和仪表盘

4.1 添加Prometheus数据源

登录Grafana后，按照以下步骤添加数据源：

点击左侧菜单的 Configuration（小齿轮图标）
选择 Data Sources
点击 Add data source
选择 Prometheus
配置如下：
- URL: http://localhost:9090
- 其他保持默认
点击 Save & Test，应该显示"Data source is working"

4.2 导入Node Exporter仪表盘

Grafana社区有现成的Node Exporter仪表盘，我们直接导入：

点击左侧菜单的 Dashboards（四个方块图标）
选择 Import
在"Import via grafana.com"输入框中输入：1860
点击 Load
选择Prometheus数据源
点击 Import

这个仪表盘编号1860是Node Exporter Full，包含了完整的系统监控指标。

4.3 创建vLLM模型服务监控仪表盘

Node Exporter的仪表盘只能看系统资源，我们还需要一个专门监控vLLM和模型服务的仪表盘。我来带你创建一个。

点击左侧菜单的 Dashboards → New → New Dashboard，然后添加以下面板：

4.3.1 GPU使用情况面板

# 查询1：GPU利用率
avg(rate(vllm_gpu_utilization_percent[5m])) by (gpu_id)

# 查询2：GPU内存使用
avg(vllm_gpu_memory_used_bytes) by (gpu_id) / 1024 / 1024 / 1024

# 查询3：GPU内存总量
avg(vllm_gpu_memory_total_bytes) by (gpu_id) / 1024 / 1024 / 1024

配置建议：

图表类型：Stat（显示当前值）或 Time series（显示趋势）
单位：百分比或GB
显示：每个GPU单独显示

4.3.2 请求监控面板

# 查询1：请求速率
rate(vllm_request_count[5m])

# 查询2：请求延迟（P95）
histogram_quantile(0.95, rate(vllm_request_duration_seconds_bucket[5m]))

# 查询3：错误率
rate(vllm_request_failure_count[5m]) / rate(vllm_request_count[5m])

配置建议：

请求速率：用折线图，看请求量变化
请求延迟：用折线图，单位秒，关注P95延迟
错误率：用仪表盘，设置告警阈值（比如>1%）

4.3.3 模型推理性能面板

# 查询1：Tokens生成速率
rate(vllm_tokens_generated_total[5m])

# 查询2：预处理时间
rate(vllm_prefill_time_seconds_total[5m])

# 查询3：解码时间
rate(vllm_decode_time_seconds_total[5m])

配置建议：

Tokens生成速率：反映模型吞吐量
预处理和解码时间：了解模型推理各阶段耗时

4.3.4 内存使用面板

# 查询1：CPU内存使用
process_resident_memory_bytes{job="vllm-metrics"}

# 查询2：KV缓存使用
vllm_kv_cache_usage_ratio

# 查询3：激活的Blocks数量
vllm_num_active_blocks

配置建议：

内存使用：监控是否内存泄漏
KV缓存使用：vLLM特有的指标，反映缓存效率
Blocks数量：了解vLLM内部调度情况

4.4 设置告警规则

监控不仅要看，还要能及时告警。在Grafana中设置几个关键告警：

GPU内存使用超过90%
- 条件：vllm_gpu_memory_used_bytes / vllm_gpu_memory_total_bytes > 0.9
- 持续时间：5分钟
- 通知方式：邮件、Slack等
请求错误率超过5%
- 条件：rate(vllm_request_failure_count[5m]) / rate(vllm_request_count[5m]) > 0.05
- 持续时间：2分钟
- 说明：短时间内大量错误，可能服务有问题
P95延迟超过3秒
- 条件：histogram_quantile(0.95, rate(vllm_request_duration_seconds_bucket[5m])) > 3
- 持续时间：5分钟
- 说明：响应变慢，影响用户体验
Tokens生成速率低于100 tokens/秒
- 条件：rate(vllm_tokens_generated_total[5m]) < 100
- 持续时间：5分钟
- 说明：模型性能下降，需要检查

5. 实际监控效果演示

配置完成后，你的监控面板应该包含以下几个关键视图：

5.1 系统资源概览

这是Node Exporter提供的面板，可以看到：

CPU使用率：DeepSeek-R1-Distill-Qwen-1.5B推理时CPU使用情况
内存使用：系统总内存和可用内存
磁盘IO：模型加载和推理时的磁盘读写
网络流量：API请求的网络吞吐

对于1.5B的小模型，CPU使用率通常不会太高，除非请求量特别大。内存使用需要关注，vLLM会预分配大量内存用于KV缓存。

5.2 GPU监控专区

这是专门为vLLM模型服务定制的面板：

GPU利用率：显示每个GPU的使用百分比。理想情况下，推理时GPU利用率应该在70-90%之间。如果太低，说明模型没有充分利用GPU；如果持续100%，可能请求排队了。

GPU内存：显示已用内存和总内存。DeepSeek-R1-Distill-Qwen-1.5B在FP16精度下大约需要3GB显存，加上vLLM的KV缓存，总占用可能在4-6GB。如果看到内存使用持续增长，可能是内存泄漏。

温度：GPU温度，长期高温度运行会影响硬件寿命。

5.3 请求性能面板

这个面板告诉你服务处理请求的能力：

请求速率：每秒处理的请求数。根据你的业务需求，这个数字会变化。如果突然下降，可能是服务有问题；如果突然上升，可能需要扩容。

响应时间：重点关注P95和P99延迟。对于对话场景，P95延迟最好在2秒以内。如果延迟变长，先看GPU利用率是不是满了。

错误率：失败请求的比例。健康服务应该接近0%。如果错误率上升，检查日志看具体错误原因。

5.4 模型推理详情

这个面板深入vLLM内部：

Tokens生成速率：模型每秒生成的tokens数。DeepSeek-R1-Distill-Qwen-1.5B在T4 GPU上大概能达到100-200 tokens/秒。

KV缓存命中率：vLLM会缓存Attention的Key-Value，命中率高说明相似请求多，推理速度快。

Blocks使用情况：vLLM把内存分成很多blocks来管理，这个指标反映内存碎片情况。

5.5 业务自定义指标

你还可以根据业务需求添加自定义指标。比如：

不同用户类型的请求分布
不同模型功能的调用频率
高峰时段的请求模式
缓存效果分析

6. 监控数据实战分析

有了监控面板，关键是要会用。我分享几个实际场景，看看怎么用监控数据解决问题。

6.1 场景一：响应时间突然变长

现象：用户反馈API响应变慢，从平均1秒变成了3秒。

排查步骤：

先看请求性能面板，确认P95延迟确实变长了
查看GPU监控，发现GPU利用率从70%升到了95%
查看请求速率，发现请求量增加了50%
结论：请求量增加导致GPU满载，请求开始排队

解决方案：

短期：增加请求超时时间，避免失败
中期：启用vLLM的排队机制，设置合理队列长度
长期：考虑扩容，增加GPU或部署多个实例

6.2 场景二：服务频繁OOM（内存不足）

现象：服务运行一段时间后崩溃，日志显示OOM。

排查步骤：

查看GPU内存历史图表，发现内存使用缓慢增长
查看Blocks使用情况，发现active blocks数量持续增加
查看请求模式，发现用户发送的对话历史越来越长

结论：用户对话历史积累，导致KV缓存不断增长，最终内存耗尽。

解决方案：

配置vLLM的max_num_seqs参数，限制同时处理的序列数
设置对话历史长度限制
定期重启服务（治标不治本）

6.3 场景三：Tokens生成速度下降

现象：同样的请求，之前每秒生成150个tokens，现在只有80个。

排查步骤：

查看Tokens生成速率图表，确认下降趋势
查看GPU温度，发现温度从65°C升到了85°C
查看系统负载，发现有其他进程占用了CPU

结论：GPU因高温降频，导致性能下降。

解决方案：

改善服务器散热
限制模型服务的CPU使用，避免其他进程影响
考虑使用功耗限制，保持稳定性能

6.4 场景四：错误率周期性上升

现象：每天固定时间错误率上升。

排查步骤：

查看错误率图表，确认周期性模式
对比请求速率，发现错误率高时请求量也大
查看系统资源，发现错误时内存使用率接近100%

结论：高峰时段请求量大，系统资源不足。

解决方案：

在高峰前预先扩容
实施请求限流
优化模型配置，减少内存占用

7. 高级监控技巧

7.1 自定义业务指标

除了vLLM自带的指标，你还可以添加业务相关的监控。比如在API层添加：

from prometheus_client import Counter, Histogram, Gauge
import time

# 定义业务指标
REQUEST_COUNT = Counter('model_request_total', 'Total requests', ['model', 'endpoint'])
REQUEST_LATENCY = Histogram('model_request_latency_seconds', 'Request latency', ['model', 'endpoint'])
ACTIVE_USERS = Gauge('model_active_users', 'Active users')

def track_request(model, endpoint):
    """装饰器：跟踪请求指标"""
    def decorator(func):
        def wrapper(*args, **kwargs):
            start_time = time.time()
            REQUEST_COUNT.labels(model=model, endpoint=endpoint).inc()
            
            try:
                result = func(*args, **kwargs)
                duration = time.time() - start_time
                REQUEST_LATENCY.labels(model=model, endpoint=endpoint).observe(duration)
                return result
            except Exception as e:
                # 可以添加错误计数
                raise e
        return wrapper
    return decorator

# 使用示例
@track_request(model='DeepSeek-R1-Distill-Qwen-1.5B', endpoint='/v1/chat/completions')
def handle_chat_request(request):
    # 处理请求逻辑
    pass

7.2 多实例监控

如果你部署了多个模型实例，可以通过标签区分：

# Prometheus配置
scrape_configs:
  - job_name: 'vllm-cluster'
    static_configs:
      - targets: ['instance1:8001', 'instance2:8001', 'instance3:8001']
    relabel_configs:
      - source_labels: [__address__]
        target_label: instance

在Grafana中，可以用instance标签来区分不同实例的数据。

7.3 长期趋势分析

Prometheus数据默认保留15天，对于长期趋势分析可能不够。你可以：

配置长期存储：修改Prometheus配置，延长数据保留时间
使用Recording Rules：预先计算常用指标，提高查询效率
设置数据归档：定期将数据导出到其他存储（如Thanos、Cortex）

7.4 自动化运维

结合监控数据实现自动化：

# 告警规则示例
groups:
  - name: model_service
    rules:
      - alert: HighGPUUsage
        expr: avg(rate(vllm_gpu_utilization_percent[5m])) by (gpu_id) > 90
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "GPU利用率过高"
          description: "GPU {{ $labels.gpu_id }} 利用率持续5分钟超过90%"
      
      - alert: ServiceDown
        expr: up{job="vllm-metrics"} == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "模型服务下线"
          description: "{{ $labels.instance }} 服务已下线1分钟"