使用Grafana可视化DeepSeek-R1-Distill-Qwen-1.5B模型服务指标：监控大屏搭建

1. 为什么需要为轻量级大模型服务配置监控大屏

当你在本地或云服务器上部署了DeepSeek-R1-Distill-Qwen-1.5B这样的15亿参数模型，它不像传统Web服务那样有明确的请求-响应周期。模型服务运行时，你可能遇到这些情况：用户反馈响应变慢，但不知道是GPU显存不足、推理队列积压，还是网络带宽瓶颈；服务突然无响应，却无法快速定位是vLLM调度器异常，还是Open WebUI前端连接中断；或者想了解模型每天处理了多少token，平均响应时长是否在合理范围内。

这时候，一个直观的监控大屏就变得特别实用。它不是为了展示技术复杂度，而是帮你快速回答几个关键问题：服务现在健康吗？资源使用是否接近极限？用户实际体验如何？有没有异常请求模式？

Grafana正是解决这类问题的理想工具。它不依赖特定技术栈，能对接Prometheus、InfluxDB等多种数据源，界面简洁但功能强大。更重要的是，它不需要你从零开始写前端代码——用拖拽方式就能把关键指标组织成一张清晰的大屏。对于像DeepSeek-R1-Distill-Qwen-1.5B这样资源占用相对可控的模型，监控配置本身也足够轻量，不会给服务器带来额外负担。

2. 搭建前的环境准备与数据采集基础

2.1 确认模型服务已启用指标暴露

DeepSeek-R1-Distill-Qwen-1.5B通常通过vLLM框架提供API服务。vLLM从0.4.0版本起原生支持Prometheus指标导出，但默认是关闭的。你需要在启动服务时添加两个关键参数：

--enable-metrics \
--metrics-exporter prometheus

完整的vLLM启动命令示例如下（以阿里云GPU实例为例）：

sudo docker run -d -t --network=host --gpus all \
    --privileged \
    --ipc=host \
    --name deepseek-1.5b \
    -v /mnt/1.5b:/data \
    egs-registry.cn-hangzhou.cr.aliyuncs.com/egs/vllm:0.6.4.post1-pytorch2.5.1-cuda12.4-ubuntu22.04 \
    /bin/bash -c "vllm serve /data \
        --port 30000 \
        --served-model-name DeepSeek-R1-Distill-Qwen-1.5B \
        --tensor-parallel-size 1 \
        --max-model-len 16384 \
        --enforce-eager \
        --dtype half \
        --enable-metrics \
        --metrics-exporter prometheus"

启动后，你可以直接访问http://localhost:30000/metrics查看原始指标数据。如果返回404，说明参数未生效；如果返回大量以# HELP开头的文本，说明指标导出已成功启用。

2.2 部署Prometheus服务收集指标

Prometheus是Grafana最常用的后端数据源，它通过定时抓取（scrape）的方式从目标服务获取指标。我们用Docker快速部署一个轻量级Prometheus实例：

# 创建prometheus配置目录
mkdir -p /opt/prometheus/{config,data}

# 创建prometheus.yml配置文件
cat > /opt/prometheus/config/prometheus.yml << 'EOF'
global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: 'vllm-deepseek'
    static_configs:
      - targets: ['host.docker.internal:30000']
    metrics_path: '/metrics'
EOF

# 启动Prometheus容器
sudo docker run -d \
  --name prometheus \
  -p 9090:9090 \
  -v /opt/prometheus/config:/etc/prometheus \
  -v /opt/prometheus/data:/prometheus \
  --restart=always \
  prom/prometheus:latest

这里有个关键点：host.docker.internal是Docker容器内访问宿主机的特殊域名。如果你的vLLM服务运行在宿主机而非容器中，这个配置就能让Prometheus顺利抓取到指标。启动后，访问http://localhost:9090/targets，你应该能看到vllm-deepseek任务状态为UP。

2.3 安装并配置Grafana服务

同样使用Docker部署Grafana，保持环境一致性：

# 创建Grafana数据目录
sudo mkdir -p /opt/grafana/data

# 启动Grafana容器
sudo docker run -d \
  --name grafana \
  -p 3001:3000 \
  -v /opt/grafana/data:/var/lib/grafana \
  --restart=always \
  -e GF_SECURITY_ADMIN_PASSWORD=your_secure_password \
  grafana/grafana-oss:latest

服务启动后，访问http://localhost:3001，用用户名admin和你设置的密码登录。首次登录会提示修改密码，按流程操作即可。

3. Grafana核心监控面板配置详解

3.1 添加Prometheus数据源

登录Grafana后，点击左侧菜单栏的齿轮图标（Configuration），选择"Data Sources"，然后点击"Add data source"。在搜索框中输入"Prometheus"，选择对应选项。

在配置页面中：

• Name：填写Prometheus-VLLM
• URL：填写http://host.docker.internal:9090（注意：这是Grafana容器内部访问Prometheus的地址）
• 其他选项保持默认，滚动到底部点击"Save & test"

如果显示"Data source is working"，说明连接成功。这一步很关键，后续所有面板都依赖这个数据源。

3.2 构建服务健康状态看板

健康状态是监控的第一道防线。我们创建一个简单的状态面板，实时显示服务是否在线以及基本响应时间。

在Grafana首页，点击"+"号，选择"Dashboard"，然后点击右上角的"Add new panel"。在查询编辑器中，输入以下PromQL表达式：

count by (job) (up{job="vllm-deepseek"} == 1)

这个查询统计当前处于UP状态的目标数量。将面板标题设为"服务可用性"，可视化类型选择"Stat"（单值显示）。在"Options"选项卡中，将"Value options"下的"Stat"设为"Current"，"Text mode"设为"Auto"。

接着添加第二个面板，监控平均响应延迟：

histogram_quantile(0.95, sum(rate(vllm_request_latency_seconds_bucket[5m])) by (le))

这个表达式计算过去5分钟内95%请求的延迟上限（P95）。将可视化类型设为"Gauge"，设置合理的阈值：绿色（正常）< 2秒，黄色（警告）2-5秒，红色（严重）> 5秒。这样一眼就能看出服务响应是否在预期范围内。

3.3 GPU资源使用率监控

DeepSeek-R1-Distill-Qwen-1.5B在单卡上运行时，GPU利用率是关键瓶颈指标。vLLM本身不直接暴露GPU指标，我们需要借助Node Exporter来补充这部分数据。

首先安装Node Exporter（同样用Docker）：

sudo docker run -d \
  --name node-exporter \
  -p 9100:9100 \
  --restart=always \
  --pid=host \
  --cgroupns=host \
  -v "/proc:/proc:ro" \
  -v "/sys:/sys:ro" \
  -v "/:/rootfs:ro" \
  quay.io/prometheus/node-exporter:latest

然后在Prometheus配置中添加新任务：

  - job_name: 'node-exporter'
    static_configs:
      - targets: ['host.docker.internal:9100']

重启Prometheus容器后，在Grafana中新建面板，使用以下查询：

100 - (100 * avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])))

这个查询计算CPU整体使用率。对于GPU，我们使用nvidia-smi的指标（需确保宿主机已安装NVIDIA驱动）：

nvidia_smi_duty_cycle{device="0"}

将这个查询的可视化类型设为"Gauge"，阈值设为：绿色< 70%，黄色70-90%，红色> 90%。配合下方的内存使用率图表，你就能全面掌握GPU资源压力。

3.4 模型推理性能深度分析

vLLM暴露的指标中，最有价值的是请求处理相关的计数器。我们构建一个综合性能面板，包含三个核心维度：

请求吞吐量（QPS）：

sum(rate(vllm_num_requests_running[1m]))

这个指标显示当前正在处理的请求数量。数值稳定在1-3之间是理想状态，如果持续高于5，说明推理队列开始积压。

Token生成速率：

sum(rate(vllm_num_generated_tokens[1m])) / sum(rate(vllm_num_prefill_tokens[1m] + vllm_num_generated_tokens[1m]))

这个比值反映模型生成token的效率。对于DeepSeek-R1-Distill-Qwen-1.5B，正常值应该在0.6-0.8之间。如果低于0.4，可能是GPU显存不足导致频繁换页。

请求成功率：

sum(rate(vllm_request_success_total[5m])) by (status_code) / sum(rate(vllm_request_total[5m])) by (status_code)

重点关注status_code="200"的比例。如果成功率低于98%，需要检查日志中是否有OOM（内存溢出）错误。

将这三个指标放在同一行，使用"Time series"可视化类型，并开启"Legend"显示，你就能看到它们随时间变化的趋势关系。

4. 实用技巧与常见问题应对

4.1 如何快速定位响应变慢的原因

当用户反馈"模型变慢了"，不要急于重启服务。打开你的Grafana大屏，按顺序检查：

1. 先看GPU利用率：如果GPU使用率长期低于30%，说明瓶颈不在计算能力，可能是CPU或网络问题。
2. 再查请求队列：观察vllm_num_requests_waiting指标。如果该值持续大于0，说明请求在排队，需要增加--max-num-seqs参数或升级硬件。
3. 最后看延迟分布：切换到"Request Latency"面板，查看P50、P90、P99延迟曲线。如果P50很低但P99很高，说明偶发性长尾请求影响了整体体验，可以检查是否有超长上下文的请求。

这种分层排查方法，比盲目调整参数高效得多。

4.2 监控数据存储优化建议

Prometheus默认保留15天数据，但对于模型服务监控，我们更关注近期趋势。可以在启动时添加参数优化存储：

sudo docker run -d \
  --name prometheus \
  -p 9090:9090 \
  -v /opt/prometheus/config:/etc/prometheus \
  -v /opt/prometheus/data:/prometheus \
  --restart=always \
  -e "ARGS=--storage.tsdb.retention.time=7d --storage.tsdb.max-block-duration=2h" \
  prom/prometheus:latest

7天的数据保留期对日常运维完全够用，而max-block-duration参数能减少磁盘I/O压力，特别适合在系统盘空间有限的GPU实例上运行。

4.3 为不同使用场景定制告警规则

Grafana的Alerting功能可以让你在问题发生前就收到通知。以下是针对DeepSeek-R1-Distill-Qwen-1.5B的三个实用告警：

服务离线告警：

• 表达式：up{job="vllm-deepseek"} == 0
• 条件：持续1分钟
• 通知：企业微信/钉钉机器人

GPU显存告警：

• 表达式：nvidia_smi_memory_used_bytes{device="0"} / nvidia_smi_memory_total_bytes{device="0"} > 0.95
• 条件：持续2分钟
• 通知：邮件+短信（因为显存溢出会导致服务崩溃）

请求失败率告警：

• 表达式：sum(rate(vllm_request_failure_total[5m])) / sum(rate(vllm_request_total[5m])) > 0.03
• 条件：持续5分钟
• 通知：仅企业微信（低优先级，可能是临时网络抖动）

这些告警规则在Grafana的"Alerting" → "Alert rules"中配置，关键是设置合理的触发时长，避免误报。

5. 总结：让监控真正服务于模型迭代

搭建完这套监控体系后，我最大的感受是：它改变了我们和模型服务的互动方式。以前遇到问题，第一反应是"重启试试"；现在，第一反应是打开Grafana看一眼指标。这种转变看似微小，实则深刻——它让我们从经验驱动转向数据驱动。

比如上周，我发现P99延迟曲线出现规律性尖峰，每15分钟一次。起初以为是定时任务干扰，但监控数据显示CPU和GPU使用率都很平稳。最终通过"Request Latency"面板的详细分析，发现是某个测试脚本设置了固定间隔的批量请求，而vLLM的批处理机制在特定负载下产生了微小延迟波动。这个问题如果不靠监控，几乎不可能被发现。

监控的价值不在于炫酷的图表，而在于它把抽象的服务状态转化成了可测量、可追溯、可行动的具体数字。当你能清晰看到每个参数调整对实际指标的影响时，模型服务的优化就不再是玄学，而是一门可以精确计算的工程实践。

如果你刚部署好DeepSeek-R1-Distill-Qwen-1.5B，不妨花30分钟搭起这个监控大屏。它不会让你的模型变得更聪明，但一定会让你在维护它时更从容。

---

获取更多AI镜像

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