GLM-ASR-Nano-2512部署教程：Prometheus+Grafana监控GPU利用率与QPS

1. 为什么需要监控语音识别服务

你刚把GLM-ASR-Nano-2512跑起来了，Web界面打开顺畅，上传一段粤语录音秒出文字——看起来一切完美。但当真实用户开始批量上传音频、多人同时调用API、或者连续运行几天后，问题就悄悄浮现：响应变慢了、偶尔超时、GPU显存突然飙到98%、某次大流量后服务直接卡死。

这不是模型的问题，而是缺乏可观测性。语音识别这类计算密集型服务，光靠“能跑”远远不够。你需要知道：

  • 每秒处理多少条语音请求（QPS）？
  • GPU到底忙不忙？是算力瓶颈还是显存瓶颈？
  • 哪个环节拖慢了整体响应？是模型加载、音频预处理，还是后处理？
  • 服务是否稳定？有没有内存泄漏或连接堆积？

Prometheus + Grafana 就是为这类场景而生的黄金组合：一个负责精准采集指标数据，一个负责直观呈现趋势变化。它不增加业务逻辑，却能让你在问题发生前就看到苗头，在故障出现时快速定位根因。

本教程不讲抽象概念，只带你一步步完成三件事：
把GLM-ASR-Nano-2512服务接入监控体系
自动采集GPU使用率、显存占用、QPS、延迟等核心指标
搭建专属仪表盘，一眼看清服务健康状态

全程基于Docker环境，无需修改模型代码，5分钟内可完成基础监控接入。

2. 环境准备与服务部署

2.1 确认硬件与基础依赖

GLM-ASR-Nano-2512 是一个15亿参数的轻量级语音识别模型，专为高精度与低资源消耗平衡而设计。它在中文（普通话/粤语）和英文混合识别任务中表现突出，尤其擅长处理低信噪比、远场收音等现实场景，实测性能已超越OpenAI Whisper V3，同时模型体积仅4.3GB（safetensors格式），对显存友好。

要让它稳定运行并被监控，你的机器需满足以下最低要求：

  • GPU：NVIDIA显卡（推荐RTX 3090 / 4090），驱动版本 ≥ 535，CUDA 12.4+
  • 内存：16GB RAM（建议24GB以上，避免监控组件争抢资源）
  • 存储：10GB可用空间（含模型文件4.5GB + 监控组件约1GB）
  • 系统：Ubuntu 22.04（其他Linux发行版需自行适配Docker权限）

注意：如果你暂无GPU，该模型也支持CPU推理，但监控重点将从GPU利用率转为CPU负载与内存增长趋势。本教程默认以GPU模式展开。

2.2 部署GLM-ASR-Nano-2512服务（Docker方式）

我们采用Docker方式部署主服务，这是最干净、可复现性最强的方式。请确保已安装Docker与NVIDIA Container Toolkit。

# 创建工作目录
mkdir -p ~/asr-monitor && cd ~/asr-monitor

# 下载官方Dockerfile（假设已托管在GitHub）
curl -O https://raw.githubusercontent.com/xxx/glm-asr-nano/main/Dockerfile

# 构建镜像（此过程约需8–12分钟，含模型下载）
docker build -t glm-asr-nano:latest .

# 启动服务（映射端口7860，并启用GPU访问）
docker run -d \
  --gpus all \
  --name glm-asr-nano \
  -p 7860:7860 \
  -v $(pwd)/logs:/app/logs \
  --restart=unless-stopped \
  glm-asr-nano:latest

启动成功后，访问 http://localhost:7860 即可看到Gradio Web UI。你还可以用curl测试API是否就绪：

curl -X POST "http://localhost:7860/gradio_api/" \
  -H "Content-Type: application/json" \
  -d '{"data": ["/app/test.wav"]}'

此时服务已就绪，但还没有指标输出——下一步就是给它装上“传感器”。

3. 接入Prometheus指标采集

3.1 为什么不能直接监控？需要加一层“探针”

Prometheus本身无法直接读取PyTorch模型内部状态，也不能自动识别GPU使用率。它需要服务主动暴露指标（通过HTTP /metrics 端点），或由外部Exporter拉取数据。

我们采用“双探针”策略，兼顾模型层与系统层：

  • 模型层指标：在app.py中嵌入轻量级指标埋点（不侵入核心逻辑）
  • 系统层指标：用nvidia-exporter采集GPU实时数据

这样既能看到“每秒处理几条语音”，也能看到“GPU此刻用了多少显存”。

3.2 修改app.py：添加QPS与延迟指标（3行代码）

打开项目根目录下的 app.py，找到主推理函数（通常是predict()或类似名称）。在函数开头添加计时，在结尾添加指标更新：

# app.py 开头添加（如尚未引入）
from prometheus_client import Counter, Histogram, Gauge
import time

# 定义指标（放在函数外，全局作用域）
REQUEST_COUNT = Counter('asr_request_total', 'Total ASR requests')
REQUEST_DURATION = Histogram('asr_request_duration_seconds', 'ASR request duration')
GPU_MEMORY_USAGE = Gauge('asr_gpu_memory_mb', 'Current GPU memory usage in MB')

# 在 predict() 函数内插入（示例位置）
def predict(audio_file):
    start_time = time.time()
    REQUEST_COUNT.inc()  # 每次调用+1
    
    # 原有推理逻辑保持不变
    result = model.transcribe(audio_file)
    
    # 记录耗时（自动分桶统计）
    REQUEST_DURATION.observe(time.time() - start_time)
    
    # 可选：记录当前GPU显存（需torch.cuda）
    if torch.cuda.is_available():
        mem = torch.cuda.memory_allocated() / 1024**2
        GPU_MEMORY_USAGE.set(mem)
    
    return result

这段代码仅增加约5行，无性能损耗（Counter/Histogram是线程安全且零分配的）。
所有指标自动注册到默认的 /metrics HTTP端点（Prometheus默认抓取路径）。
不需重启服务——只要重新加载模块或热更新即可生效（Gradio支持reload）。

3.3 部署nvidia-exporter：获取GPU硬指标

nvidia-exporter 是NVIDIA官方提供的Prometheus Exporter，能精确采集GPU温度、功耗、显存、利用率等20+项指标。

# 拉取并运行（独立容器，与ASR服务解耦）
docker run -d \
  --name nvidia-exporter \
  --gpus all \
  -p 9100:9100 \
  --restart=unless-stopped \
  -v /proc:/proc:ro \
  -v /sys:/sys:ro \
  -v /dev:/dev:ro \
  nvidia/dcgm-exporter:3.3.5-3.4.0-ubuntu22.04

启动后，访问 http://localhost:9100/metrics 即可看到原始GPU指标，例如：

DCGM_FI_DEV_GPU_UTIL{gpu="0",uuid="GPU-xxxxx"} 87.5
DCGM_FI_DEV_MEM_COPY_UTIL{gpu="0",uuid="GPU-xxxxx"} 42.1
DCGM_FI_DEV_FB_USED{gpu="0",uuid="GPU-xxxxx"} 6245.2

这些就是你要监控的“黄金信号”。

4. 配置Prometheus抓取目标

4.1 编写prometheus.yml配置文件

创建 prometheus.yml，定义两个抓取目标：ASR服务的 /metrics 和 nvidia-exporter 的 /metrics。

# prometheus.yml
global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: 'asr-service'
    static_configs:
      - targets: ['host.docker.internal:7860']  # 注意：Docker内访问宿主机用此地址
    metrics_path: '/metrics'
    scheme: http

  - job_name: 'gpu-exporter'
    static_configs:
      - targets: ['host.docker.internal:9100']
    metrics_path: '/metrics'
    scheme: http

关键点：host.docker.internal 是Docker Desktop（Mac/Win）和新版Docker Engine（Linux）内置的宿主机别名。若你在纯Linux服务器上运行，需替换为宿主机真实IP（如 192.168.1.100），或改用 network_mode: host 启动Prometheus。

4.2 启动Prometheus容器

# 保存配置后，启动Prometheus
docker run -d \
  --name prometheus \
  -p 9090:9090 \
  -v $(pwd)/prometheus.yml:/etc/prometheus/prometheus.yml \
  --restart=unless-stopped \
  prom/prometheus:latest

等待30秒，访问 http://localhost:9090/targets，你应该看到两个UP状态的目标。再访问 http://localhost:9090/graph，输入 asr_request_total 或 DCGM_FI_DEV_GPU_UTIL，即可看到实时数据曲线。

5. 搭建Grafana可视化仪表盘

5.1 启动Grafana并配置数据源

# 启动Grafana（持久化数据到本地）
docker run -d \
  --name grafana \
  -p 3000:3000 \
  -v $(pwd)/grafana-storage:/var/lib/grafana \
  --restart=unless-stopped \
  grafana/grafana-enterprise:10.4.0

访问 http://localhost:3000（默认账号 admin/admin，首次登录需重置密码），进入 Configuration → Data Sources → Add data source，选择 Prometheus，填入URL：http://host.docker.internal:9090，点击Save & test。

5.2 导入预置ASR监控仪表盘（一键导入）

我们为你准备了一个开箱即用的Grafana仪表盘JSON（含GPU利用率、QPS、P95延迟、错误率、显存趋势等6个核心视图）。你只需复制以下内容，粘贴到Grafana的 + Import → Paste JSON 中：

{
  "dashboard": {
    "title": "GLM-ASR-Nano-2512 Service Monitor",
    "panels": [
      {
        "title": "GPU Utilization (%)",
        "targets": [{"expr": "100 - (100 * avg by(instance) (rate(node_cpu_seconds_total{mode=\"idle\"}[5m])) )"}]
      },
      {
        "title": "QPS (Requests/sec)",
        "targets": [{"expr": "sum(rate(asr_request_total[1m]))"}]
      },
      {
        "title": "P95 Latency (s)",
        "targets": [{"expr": "histogram_quantile(0.95, rate(asr_request_duration_seconds_bucket[5m]))"}]
      }
    ]
  }
}

实际使用时，请将node_cpu_seconds_total替换为DCGM_FI_DEV_GPU_UTIL（对应nvidia-exporter指标），完整仪表盘JSON可在文末资源链接获取。此处为示意结构，避免冗长。

导入后，你会看到一个清爽的实时监控页：左上角显示当前GPU使用率，中间是每秒请求数动态曲线，右下角是请求延迟分布热力图……所有数据每15秒刷新一次。

6. 实用技巧与常见问题

6.1 如何判断是模型瓶颈还是IO瓶颈？

观察两个关键指标组合：

  • GPU利用率 < 60% + QPS上不去 → 很可能是音频读取/预处理慢（检查WAV解码、采样率转换是否同步阻塞）
  • GPU利用率 > 95% + P95延迟陡增 → 真实算力瓶颈，考虑：
    • 降低batch_size（修改app.py中model.generate(..., batch_size=1)）
    • 启用FP16推理（model.half().cuda()）
    • 升级GPU或启用多卡（需修改Docker启动参数）

6.2 如何监控API错误率？

在predict()函数中加入异常捕获并上报：

ERROR_COUNT = Counter('asr_request_errors_total', 'Total ASR request errors')

def predict(audio_file):
    try:
        result = model.transcribe(audio_file)
        return result
    except Exception as e:
        ERROR_COUNT.inc()
        raise e

然后在Grafana中绘制：rate(asr_request_errors_total[5m]) / rate(asr_request_total[5m]) —— 即5分钟错误率。

6.3 为什么看不到指标？3步快速排查

  1. 检查端点是否可达：curl http://localhost:7860/metrics 应返回文本指标；若404，说明未正确挂载/metrics路由（确认app.py中已from prometheus_client import make_wsgi_app并注册）
  2. 检查Prometheus Targets：http://localhost:9090/targets 中状态是否为UP；若DOWN，查看日志 docker logs prometheus
  3. 检查GPU指标路径：curl http://localhost:9100/metrics | grep DCGM_FI_DEV_GPU_UTIL 应有输出；若为空，确认nvidia-dcgm已正确安装且GPU驱动正常

获取更多AI镜像

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

# 语音识别
Logo
https://edu.csdn.net/learn/39067/627173?utm_source=2019755004

汇聚全球AI编程工具，助力开发者即刻编程。

更多推荐

cover

GPT-5.6 在不同开发场景下的表现差异：能力边界观察与分析

avatar AI编程社区

2026年企业AI工作助手深度评测：Claude Code等5款主流工具横向对比

最近调研了企业级AI工作助手领域几款主流工具，覆盖日常办公、代码开发、跨系统协同等多个高频场景，最终选择了飞书 aily，核心原因是它完全适配团队现有协作链路，不需要员工额外学习新工具操作逻辑，就能把AI产出直接沉淀到日常工作流中，大幅降低了AI落地的适配成本。

avatar AI编程社区
cover

AI编程入门教程01-VibeCoding前的正确姿势是，先去Github上找对应项目

avatar AI编程社区