Kimi-VL-A3B-Thinking生产环境：Prometheus+Grafana模型服务监控

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

想象一下，你花了好几天时间，终于把一个强大的多模态模型部署到了生产环境。用户开始使用，一切看起来都很美好。但突然有一天，你发现用户反馈说“模型响应变慢了”，或者“有时候会报错”。你打开服务器一看，CPU和内存都跑满了，但具体是哪个环节出了问题？是模型推理太慢，还是并发请求太多？你完全不知道。

这就是为什么我们需要监控。没有监控的生产环境，就像在黑暗中开车——你不知道前面是直路还是悬崖。

今天我们要聊的，就是如何为Kimi-VL-A3B-Thinking这个强大的图文对话模型搭建一套完整的监控系统。这个模型本身就很厉害——它能看懂图片、理解长文本、进行复杂的推理，而且只激活2.8B参数，效率很高。但再好的模型，如果没有好的监控，在生产环境里也可能会出问题。

我们将使用Prometheus来收集各种指标数据，然后用Grafana把这些数据变成直观的图表。这样你就能随时知道：

• 模型服务现在健康吗？
• 响应速度怎么样？
• 资源使用情况如何？
• 有没有异常情况？

2. 监控系统架构概览

在开始动手之前，我们先看看整个监控系统是怎么工作的。这样你就能明白每个组件的作用，而不是盲目地跟着步骤做。

2.1 核心组件介绍

我们的监控系统主要由三个部分组成：

Prometheus：这是监控系统的“数据收集器”。它会定期从各个服务（包括我们的模型服务）拉取指标数据，然后存储起来。你可以把它想象成一个不断问“你现在怎么样？”的机器人。

Grafana：这是“数据展示器”。它从Prometheus那里拿到数据，然后生成漂亮的图表和仪表盘。这样你就不用看一堆枯燥的数字，而是能看到直观的曲线图、柱状图。

模型服务本身：我们需要让模型服务暴露一些指标，这样Prometheus才能收集到数据。对于vLLM部署的服务，这通常需要一些配置。

2.2 数据流向

整个系统的数据流向是这样的：

1. 模型服务运行，并暴露指标接口（比如在某个端口提供/metrics端点）
2. Prometheus定期（比如每15秒）去访问这个接口，获取当前的指标数据
3. Prometheus把数据存储在自己的时序数据库中
4. Grafana连接到Prometheus，查询数据
5. 你在Grafana的网页界面上看到漂亮的图表

2.3 我们要监控什么？

对于模型服务，我们主要关心这几类指标：

性能指标：

• 请求延迟：用户从发送请求到收到响应要等多久？
• 吞吐量：每秒能处理多少个请求？
• 并发数：同时有多少个请求在处理？

资源指标：

• CPU使用率：模型推理用了多少CPU？
• 内存使用量：模型加载后占用了多少内存？
• GPU使用情况（如果有的话）：显存用了多少？GPU利用率多少？

业务指标：

• 请求成功率：有多少请求成功了？有多少失败了？
• 错误类型：如果失败了，是什么原因？

3. 环境准备与组件安装

好了，理论说完了，我们开始动手。首先得把需要的软件装好。

3.1 检查现有环境

你的Kimi-VL-A3B-Thinking应该已经用vLLM部署好了，并且用Chainlit做了前端。我们先确认一下服务是否正常运行：

# 查看模型服务日志
cat /root/workspace/llm.log

# 检查服务进程
ps aux | grep vllm

# 测试服务是否响应
curl http://localhost:8000/health

如果看到模型加载成功的日志，并且服务能正常响应，那就可以继续了。

3.2 安装Prometheus

Prometheus的安装其实挺简单的。我们下载官方发布包，然后解压配置就行：

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

# 下载Prometheus（这里以2.45.0版本为例，你可以去官网看最新版本）
wget https://github.com/prometheus/prometheus/releases/download/v2.45.0/prometheus-2.45.0.linux-amd64.tar.gz

# 解压
tar xvfz prometheus-2.45.0.linux-amd64.tar.gz

# 重命名目录，方便使用
mv prometheus-2.45.0.linux-amd64 prometheus

# 进入目录
cd prometheus

现在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']
    
  # 监控模型服务（假设模型服务在8000端口暴露指标）
  - job_name: 'kimi-vl-model'
    static_configs:
      - targets: ['localhost:8000']
    metrics_path: '/metrics'  # 指标端点路径
    scrape_interval: 10s  # 模型服务指标收集频繁一些
    
  # 监控系统资源（通过node_exporter，后面会安装）
  - job_name: 'node'
    static_configs:
      - targets: ['localhost:9100']
EOF

这个配置文件做了几件事：

1. 设置全局的收集频率为15秒
2. 定义要监控的三个目标：Prometheus自己、模型服务、系统资源
3. 为模型服务设置了更频繁的收集间隔（10秒），因为模型服务的指标变化可能比较快

3.3 安装Node Exporter

Node Exporter是用来收集系统资源指标的，比如CPU、内存、磁盘、网络等。没有它，我们就不知道服务器的整体资源使用情况。

# 回到监控目录
cd /opt/monitoring

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

# 解压
tar xvfz node_exporter-1.6.0.linux-amd64.tar.gz

# 重命名
mv node_exporter-1.6.0.linux-amd64 node_exporter

# 进入目录
cd node_exporter

3.4 安装Grafana

Grafana是我们看数据的界面，安装也很简单：

# 添加Grafana的APT源（如果是Ubuntu/Debian系统）
sudo apt-get install -y software-properties-common
sudo add-apt-repository "deb https://packages.grafana.com/oss/deb stable main"
wget -q -O - https://packages.grafana.com/gpg.key | sudo apt-key add -

# 更新并安装
sudo apt-get update
sudo apt-get install -y grafana

# 如果是CentOS/RHEL系统，用这个：
# sudo yum install -y https://dl.grafana.com/oss/release/grafana-10.0.0-1.x86_64.rpm

4. 配置模型服务暴露指标

现在监控组件都装好了，但还有个关键问题：我们的模型服务怎么把指标数据给Prometheus？

4.1 vLLM的指标暴露

vLLM本身是支持Prometheus指标的，但需要一些配置。我们需要修改vLLM的启动参数，让它暴露指标接口。

首先，找到你启动vLLM的地方。可能是在某个脚本里，或者直接用的命令行。我们需要添加几个参数：

# 假设原来的启动命令是这样的：
# python -m vllm.entrypoints.openai.api_server \
#   --model /path/to/model \
#   --served-model-name kimi-vl \
#   --port 8000

# 修改后的命令应该加上这些参数：
python -m vllm.entrypoints.openai.api_server \
  --model /path/to/model \
  --served-model-name kimi-vl \
  --port 8000 \
  --metrics-port 8001 \          # 单独开一个端口给指标
  --enable-metrics \            # 启用指标收集
  --metric-export-interval 10   # 每10秒导出一次指标

关键参数说明：

• --metrics-port 8001：指标会在8001端口提供，这样就不会和API端口（8000）冲突
• --enable-metrics：必须加这个参数，否则vLLM不会收集指标
• --metric-export-interval 10：每10秒更新一次指标数据

4.2 验证指标是否正常

配置好后，重启模型服务，然后验证指标是否正常暴露：

# 检查8001端口是否在监听
netstat -tlnp | grep 8001

# 直接访问指标端点
curl http://localhost:8001/metrics

如果一切正常，你会看到一大堆以# HELP和# TYPE开头的注释，然后是各种指标数据，比如：

# HELP vllm:request_latency_seconds Request latency in seconds
# TYPE vllm:request_latency_seconds histogram
vllm:request_latency_seconds_bucket{le="0.01"} 123
vllm:request_latency_seconds_bucket{le="0.05"} 456
...

4.3 更新Prometheus配置

现在模型服务已经暴露指标了，我们需要更新Prometheus的配置，让它去收集这些指标：

cd /opt/monitoring/prometheus

# 编辑配置文件
cat >> prometheus.yml << 'EOF'

  # 监控vLLM模型服务的指标（在8001端口）
  - job_name: 'vllm-metrics'
    static_configs:
      - targets: ['localhost:8001']
    scrape_interval: 10s
EOF

5. 启动所有服务

好了，所有组件都配置好了，现在启动它们。

5.1 启动Node Exporter

Node Exporter很简单，直接运行就行：

cd /opt/monitoring/node_exporter

# 前台运行（测试用）
./node_exporter

# 或者后台运行
nohup ./node_exporter > node_exporter.log 2>&1 &

启动后，你可以访问 http://localhost:9100/metrics 看看系统指标是否正常。

5.2 启动Prometheus

cd /opt/monitoring/prometheus

# 前台运行（测试用）
./prometheus --config.file=prometheus.yml

# 或者后台运行
nohup ./prometheus --config.file=prometheus.yml > prometheus.log 2>&1 &

启动后，访问 http://localhost:9090 应该能看到Prometheus的界面。

5.3 启动Grafana

# 启动Grafana服务
sudo systemctl start grafana-server

# 设置开机自启
sudo systemctl enable grafana-server

# 查看状态
sudo systemctl status grafana-server

Grafana默认运行在3000端口，访问 http://localhost:3000 就能看到登录界面。默认用户名和密码都是admin，第一次登录会要求修改密码。

6. 配置Grafana监控面板

现在所有服务都跑起来了，但Grafana里还是空的。我们需要配置数据源和创建仪表盘。

6.1 添加Prometheus数据源

1. 登录Grafana（http://localhost:3000）
2. 点击左边菜单的"Configuration"（小齿轮图标）
3. 选择"Data Sources"
4. 点击"Add data source"
5. 选择"Prometheus"
6. 在URL那里填写：http://localhost:9090
7. 其他保持默认，点击"Save & Test"

如果看到"Data source is working"的绿色提示，说明连接成功了。

6.2 导入现成的仪表盘

手动创建仪表盘比较麻烦，好在有很多现成的模板可以用。我们导入两个最常用的：

Node Exporter仪表盘（监控系统资源）：

1. 点击左边菜单的"Dashboards"（四个方块图标）
2. 选择"Import"
3. 在"Import via grafana.com"输入框输入：1860
4. 点击"Load"
5. 选择Prometheus数据源，点击"Import"

这个仪表盘编号1860是Node Exporter的官方推荐仪表盘，它会显示CPU、内存、磁盘、网络等所有系统指标。

vLLM监控仪表盘： 对于vLLM，目前没有官方的仪表盘，但我们可以用一些通用的模板，或者自己创建。我们先创建一个简单的：

点击"Dashboards" → "New" → "New Dashboard"，然后添加以下几个面板：

6.2.1 请求延迟面板

添加一个"Time series"面板，配置如下：

• 查询：rate(vllm:request_latency_seconds_sum[5m]) / rate(vllm:request_latency_seconds_count[5m])
• 标题：请求平均延迟
• 单位：seconds（秒）
• 显示：线形图

这个公式计算的是平均请求延迟。[5m]表示过去5分钟的数据，这样曲线会更平滑。

6.2.2 请求吞吐量面板

再添加一个面板：

• 查询：rate(vllllm:request_counter_total[5m])
• 标题：请求吞吐量（QPS）
• 单位：reqs/s（请求/秒）
• 显示：线形图

这个显示每秒处理的请求数。

6.2.3 内存使用面板

对于模型服务，内存使用很重要：

• 查询：process_resident_memory_bytes{job="vllm-metrics"}
• 标题：模型服务内存使用
• 单位：bytes（字节）
• 显示：线形图

6.2.4 错误率面板

监控错误情况：

• 查询：rate(vllm:request_error_counter_total[5m]) / rate(vllm:request_counter_total[5m]) * 100
• 标题：请求错误率
• 单位：percent（百分比）
• 显示：线形图
• 阈值：可以设置一条红线在5%，超过就需要注意

6.3 整理仪表盘布局

把上面这些面板拖拽排列好，让重要的指标放在显眼位置。你可以：

1. 把请求延迟和吞吐量放在第一行，这是最关键的指标
2. 内存使用和错误率放在第二行
3. 系统资源（CPU、内存、磁盘）放在下面

保存仪表盘，命名为"Kimi-VL模型监控"。

7. 实际监控效果演示

现在让我们看看监控系统实际运行起来是什么样子。我会模拟一些场景，让你知道在什么情况下应该关注什么指标。

7.1 正常情况下的监控

当模型服务正常运行，用户请求平稳时，你的监控面板应该显示：

请求延迟：相对平稳的曲线，数值取决于你的硬件和模型大小。对于Kimi-VL-A3B-Thinking，在合适的硬件上，延迟可能在1-3秒左右。

请求吞吐量：根据用户访问量有波动，但不会突然飙升或暴跌。

内存使用：比较稳定。模型加载后会占用固定大小的内存，然后根据请求量有小幅波动。

错误率：接近0，或者偶尔有几个错误（网络波动等）。

7.2 异常情况识别

监控的价值在于发现问题。下面是一些常见问题及其在监控中的表现：

场景1：内存泄漏

• 表现：内存使用量持续上涨，即使请求量没有增加
• 监控指标：process_resident_memory_bytes曲线持续向上，不回落
• 可能原因：代码有bug，内存没有正确释放

场景2：请求突增

• 表现：突然有很多用户访问
• 监控指标：请求吞吐量突然飙升，延迟也可能随之增加
• 应对：观察系统资源是否足够，考虑是否需要扩容

场景3：模型推理变慢

• 表现：用户反馈响应慢，但请求量没变
• 监控指标：请求延迟增加，但吞吐量没变
• 可能原因：服务器负载高，或者其他进程占用了资源

场景4：服务异常

• 表现：服务崩溃或无法响应
• 监控指标：所有指标突然变成0或无法采集
• 监控系统本身：Prometheus的up指标会变成0（表示目标不可达）

7.3 设置告警规则

光有监控还不够，我们还需要告警——当出现问题时，能及时通知我们。

在Prometheus中配置告警规则：

cd /opt/monitoring/prometheus

# 创建告警规则文件
cat > rules.yml << 'EOF'
groups:
  - name: model_alerts
    rules:
      # 规则1：错误率过高
      - alert: HighErrorRate
        expr: rate(vllm:request_error_counter_total[5m]) / rate(vllm:request_counter_total[5m]) * 100 > 5
        for: 2m
        labels:
          severity: warning
        annotations:
          summary: "模型服务错误率过高"
          description: "错误率已经超过5%，持续2分钟。当前值: {{ $value }}%"
      
      # 规则2：延迟过高
      - alert: HighLatency
        expr: rate(vllm:request_latency_seconds_sum[5m]) / rate(vllm:request_latency_seconds_count[5m]) > 10
        for: 2m
        labels:
          severity: warning
        annotations:
          summary: "模型服务延迟过高"
          description: "平均延迟超过10秒，持续2分钟。当前值: {{ $value }}秒"
      
      # 规则3：服务宕机
      - alert: ServiceDown
        expr: up{job="vllm-metrics"} == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "模型服务不可用"
          description: "vLLM指标端点无法访问，服务可能已宕机"
      
      # 规则4：内存使用过高
      - alert: HighMemoryUsage
        expr: process_resident_memory_bytes{job="vllm-metrics"} > 1.5e10  # 15GB
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "模型服务内存使用过高"
          description: "内存使用超过15GB，持续5分钟。当前值: {{ $value }} bytes"
EOF

然后更新Prometheus配置，启用这个规则文件：

# 编辑prometheus.yml，取消rule_files的注释，并指向我们的规则文件
sed -i 's|# - "first_rules.yml"|- "rules.yml"|g' prometheus.yml

# 重启Prometheus
pkill prometheus
cd /opt/monitoring/prometheus
nohup ./prometheus --config.file=prometheus.yml > prometheus.log 2>&1 &

7.4 配置告警通知

告警规则有了，但还需要配置通知方式。Prometheus本身不发送通知，它只负责触发告警。我们需要用Alertmanager来发送通知。

安装和配置Alertmanager：

cd /opt/monitoring

# 下载Alertmanager
wget https://github.com/prometheus/alertmanager/releases/download/v0.25.0/alertmanager-0.25.0.linux-amd64.tar.gz
tar xvfz alertmanager-0.25.0.linux-amd64.tar.gz
mv alertmanager-0.25.0.linux-amd64 alertmanager

# 创建配置文件（这里以邮件通知为例）
cd alertmanager
cat > alertmanager.yml << 'EOF'
global:
  smtp_smarthost: 'smtp.example.com:587'  # 你的SMTP服务器
  smtp_from: 'alert@example.com'
  smtp_auth_username: 'your-email@example.com'
  smtp_auth_password: 'your-password'

route:
  group_by: ['alertname']
  group_wait: 10s
  group_interval: 10s
  repeat_interval: 1h
  receiver: 'email-notifications'

receivers:
  - name: 'email-notifications'
    email_configs:
      - to: 'admin@example.com'
        subject: '{{ .GroupLabels.alertname }}'
        body: |
          告警: {{ .GroupLabels.alertname }}
          严重程度: {{ .CommonLabels.severity }}
          摘要: {{ .CommonAnnotations.summary }}
          描述: {{ .CommonAnnotations.description }}
          时间: {{ .StartsAt }}
EOF

启动Alertmanager：

nohup ./alertmanager --config.file=alertmanager.yml > alertmanager.log 2>&1 &

最后，更新Prometheus配置，让它知道Alertmanager在哪里：

cd /opt/monitoring/prometheus

# 在prometheus.yml中添加alerting配置
cat >> prometheus.yml << 'EOF'

alerting:
  alertmanagers:
    - static_configs:
        - targets: ['localhost:9093']  # Alertmanager默认端口
EOF

# 重启Prometheus
pkill prometheus
nohup ./prometheus --config.file=prometheus.yml > prometheus.log 2>&1 &

现在，当触发告警时，你就会收到邮件通知了。

8. 监控系统维护与优化

监控系统搭建好了，但工作还没完。我们还需要定期维护和优化。

8.1 数据保留策略

Prometheus默认只保留15天的数据。对于模型服务监控，你可能需要调整这个设置：

# 编辑prometheus.yml，在global部分添加
cat >> prometheus.yml << 'EOF'

  # 数据保留30天
  retention: 30d
  
  # 每2小时压缩一次数据
  compaction: true
EOF

如果你需要更长时间的数据保留，可以考虑：

1. 使用远程存储（如Thanos、Cortex）
2. 定期备份数据
3. 只保留重要的指标，删除不重要的

8.2 监控系统本身的监控

监控系统自己也需要被监控！否则它挂了我们都不知道。

我们可以监控：

1. Prometheus是否健康：通过up{job="prometheus"}指标
2. Prometheus存储空间：监控磁盘使用量
3. Grafana是否可访问：简单的HTTP检查

8.3 性能优化建议

随着数据量增加，监控系统本身可能会成为负担。这里有几个优化建议：

减少指标采集频率：如果不是特别需要，可以把scrape_interval从10秒调到30秒或60秒。

只收集必要的指标：有些指标可能对你没用，可以在Prometheus配置中过滤掉。

使用记录规则：对于复杂的查询，可以预先计算好，减少查询时的计算量：

# 在rules.yml中添加记录规则
groups:
  - name: recording_rules
    rules:
      - record: job:vllm:request_latency_seconds:avg_rate5m
        expr: rate(vllm:request_latency_seconds_sum[5m]) / rate(vllm:request_latency_seconds_count[5m])
      
      - record: job:vllm:request_error_rate:avg_rate5m
        expr: rate(vllm:request_error_counter_total[5m]) / rate(vllm:request_counter_total[5m]) * 100

然后在Grafana中直接查询这些预计算的指标，速度会快很多。

8.4 定期检查与清理

建议每周检查一次：

1. 监控系统是否正常运行
2. 磁盘空间是否足够
3. 告警规则是否需要调整
4. 仪表盘是否需要更新

9. 总结

好了，到这里我们已经完成了一个完整的模型服务监控系统搭建。让我们回顾一下都做了什么：

第一步，我们理解了为什么需要监控——没有监控的生产环境就像盲人摸象，出了问题都不知道在哪。

第二步，我们了解了监控系统的架构：Prometheus收集数据，Grafana展示数据，模型服务暴露数据。

第三步，我们安装了所有需要的组件：Prometheus、Node Exporter、Grafana。

第四步，我们配置了vLLM模型服务，让它暴露指标数据。

第五步，我们启动了所有服务，并验证它们正常工作。

第六步，我们在Grafana中配置了数据源，创建了监控仪表盘。

第七步，我们设置了告警规则，当出现问题时能及时通知。

第八步，我们讨论了如何维护和优化这个监控系统。

现在，你的Kimi-VL-A3B-Thinking模型服务有了"眼睛"和"耳朵"。你能实时看到：

• 服务是否健康
• 性能怎么样
• 资源使用情况
• 用户访问模式

当出现问题时，你能第一时间知道，而不是等用户投诉。

监控不是一次性的工作，而是一个持续的过程。随着业务发展，你可能需要：

• 调整监控指标（增加新的、删除没用的）
• 优化告警阈值（太敏感了整天告警，太宽松了发现不了问题）
• 扩展监控范围（监控依赖的服务、数据库等）

但最重要的是，你现在有了一个坚实的基础。你可以基于这个系统，不断改进和优化。

最后给个小建议：监控系统搭建好后，不要设完就不管了。定期看看监控数据，了解你的服务的"正常状态"是什么样子。这样当出现异常时，你一眼就能看出来。

---

获取更多AI镜像

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