Prometheus + Grafana监控HunyuanOCR GPU利用率与QPS指标-平芜编程栈

Prometheus + Grafana监控HunyuanOCR GPU利用率与QPS指标

在AI模型服务日益普及的今天，一个看似“聪明”的系统如果背后缺乏可观测性支撑，就可能变成运维团队眼中的“黑盒炸弹”——你不知道它什么时候会慢下来，也不知道为什么突然卡顿。尤其是在部署像腾讯混元OCR（HunyuanOCR）这样高性能、多任务的轻量化多模态模型时，如何确保GPU资源不被浪费、服务吞吐能力始终在线，成了决定用户体验和成本效率的关键。

HunyuanOCR仅用1B参数便实现了多项SOTA表现，支持文档解析、字段抽取、拍照翻译等复杂场景，在Web端和服务化接口中广泛使用。但越是强大的模型，越需要精细的运行时洞察：GPU是不是一直在“摸鱼”？请求量激增时是否已经逼近极限？这些问题不能靠猜，而要靠数据说话。

于是我们引入Prometheus + Grafana这对开源监控黄金组合，构建了一套轻量级、可落地、实时可视化的观测体系，聚焦两大核心指标：
-GPU 利用率—— 看清算力有没有“烧到位”；
-QPS（Queries Per Second）—— 掌握服务能扛住多少并发请求。

这套方案不仅适用于 HunyuanOCR 的本地推理部署，也完全可以复用于其他基于 PyTorch 或 vLLM 的 AI 服务。

指标采集：让服务“开口说话”

监控的第一步，是让服务主动暴露它的状态。Prometheus 正是通过“拉取”模式完成这一步——它定期访问目标服务的/metrics接口，获取格式化的文本数据。因此，我们需要在 HunyuanOCR 的推理服务中嵌入指标上报逻辑。

Python 生态提供了prometheus-client库，几行代码就能实现关键指标的暴露：

from prometheus_client import start_http_server, Counter, Gauge import subprocess import time import torch # 定义核心监控指标 GPU_UTILIZATION = Gauge('gpu_utilization_percent', 'GPU Utilization (%)', ['gpu_id']) GPU_MEMORY_USED = Gauge('gpu_memory_used_mb', 'Used GPU Memory in MB', ['gpu_id']) REQUEST_COUNT = Counter('http_requests_total', 'Total HTTP Requests', ['method', 'endpoint', 'status']) QPS = Gauge('qps', 'Queries Per Second', ['endpoint']) # 获取NVIDIA GPU状态（依赖nvidia-smi） def get_gpu_metrics(): try: result = subprocess.run(['nvidia-smi', '--query-gpu=utilization.gpu,memory.used', '--format=csv,noheader,nounits'], stdout=subprocess.PIPE, text=True) lines = result.stdout.strip().split('\n') for i, line in enumerate(lines): util, mem = line.split(', ') GPU_UTILIZATION.labels(gpu_id=str(i)).set(float(util)) GPU_MEMORY_USED.labels(gpu_id=str(i)).set(float(mem)) except Exception as e: print(f"Failed to fetch GPU metrics: {e}") # 记录每次请求并动态计算QPS request_log = [] def record_request(): REQUEST_COUNT.labels(method='POST', endpoint='/infer', status='200').inc() request_log.append(time.time()) # 维护1秒滑动窗口 now = time.time() recent = [t for t in request_log if now - t <= 1.0] request_log[:] = recent QPS.labels(endpoint='/infer').set(len(recent)) # 启动指标服务 if __name__ == '__main__': start_http_server(8001) print("Metrics server running on http://localhost:8001/metrics") while True: get_gpu_metrics() time.sleep(1)

这段代码有几个设计上的小心思值得提一提：

使用Gauge而非Counter来记录 GPU 利用率，因为它是可上可下的瞬时值；
QPS 并非直接计数，而是通过维护一个时间窗口内的请求日志动态计算，避免采样周期影响精度；
所有指标都加了标签（gpu_id,endpoint），为后续多维分析打下基础；
单独启动一个HTTP服务（端口8001）暴露/metrics，与主推理服务解耦，降低干扰风险。

这个模块可以轻松集成进你的启动脚本，比如1-界面推理-vllm.sh或2-API接口-pt.sh，随模型一起加载即可。

数据抓取与存储：Prometheus 如何“听懂”服务

有了暴露的指标接口，接下来就是配置 Prometheus 主动去“倾听”。只需在prometheus.yml中添加一个 job：

scrape_configs: - job_name: 'hunyuanocr' scrape_interval: 5s static_configs: - targets: ['<server-ip>:8001']

Prometheus 每5秒就会向目标机器的8001端口发起一次拉取请求，抓取所有以文本形式返回的指标，并存入其内置的时间序列数据库（TSDB）。这种 pull 模式相比 push 更适合内部网络环境，稳定性高，且天然兼容服务发现机制。

更进一步，你可以利用标签实现精细化切片分析。例如：

# 查看不同GPU的平均利用率 avg by (gpu_id) (gpu_utilization_percent) # 过去1分钟的QPS趋势 rate(http_requests_total{endpoint="/infer"}[1m]) # 当前各GPU显存占用 gpu_memory_used_mb

这些 PromQL 查询语句将成为你在 Grafana 中绘图的基础语言。

值得一提的是，虽然 Prometheus 默认每5秒采样一次，但在实际部署中可以根据负载适当调整。太频繁会增加服务压力，太稀疏则可能错过尖峰波动。对于 OCR 类短耗时请求，5秒是一个不错的平衡点。

可视化呈现：Grafana 把数字变成“故事”

如果说 Prometheus 是大脑，那 Grafana 就是眼睛。它不负责采集，却能把冷冰冰的数据变成一眼就能看懂的视觉语言。

我们将 Grafana 连接到 Prometheus 数据源后，就可以开始搭建专属的 HunyuanOCR 监控面板。以下是几个实用图表的设计思路：

实时QPS趋势图（折线图）

使用 PromQL：

rate(http_requests_total{endpoint="/infer"}[1m])

展示近一段时间内每秒处理的请求数量，帮助判断流量高峰和系统承载能力。

GPU利用率仪表盘（单值+进度条）

查询：

gpu_utilization_percent{gpu_id="0"}

配合颜色映射：绿色（<30%）、黄色（30%-70%）、红色（>80%），直观反映当前GPU是否处于高负荷运行。

多GPU显存对比（柱状图）

gpu_memory_used_mb

适用于多卡部署场景，快速识别是否存在某张卡内存泄漏或负载不均。

服务健康状态表（表格组件）

显示所有实例的up状态及instance地址，结合表达式：

up{job="hunyuanocr"}

一旦出现0值，立即触发告警提示。

通过合理布局，最终可以形成一张“一屏掌握全局”的运维看板，真正实现“所见即所得”。

典型应用场景与问题诊断

场景一：要不要扩容？

当你看到 QPS 曲线持续贴近理论最大值（比如接近 vLLM 配置的最大并发数），同时响应延迟明显上升，这就意味着系统已接近瓶颈。

此时可以通过 Grafana 观察两个关键信号：
- 如果 GPU 利用率也很高（>80%），说明算力已达上限，应优先考虑横向扩容；
- 如果 GPU 利用率偏低（<40%），但 QPS 上不去，则可能是批处理设置不合理或预处理成为瓶颈。

场景二：GPU怎么总是“空转”？

有时候你会发现 GPU 利用率长期徘徊在20%以下，看起来像是资源浪费。但这不一定代表有问题。

常见原因包括：
- 请求稀疏，无法形成有效批处理（尤其是低频调用的服务）；
- 图像预处理耗时过长，导致 GPU 等待数据；
- I/O阻塞（如从远程读取图片）、解码慢（未使用硬件加速库）。

优化建议：
- 引入异步流水线，提前准备输入数据；
- 使用 NVIDIA DALI 等高性能图像处理库替代 OpenCV；
- 在低负载期合并多个小请求进行模拟批处理测试。

场景三：vLLM 到底比原生快多少？

这是个好问题。我们可以在部署两种模式时，分别打上inference_engine="vllm"和inference_engine="pytorch"的标签，然后在同一面板中对比它们的 QPS 和 GPU 利用率曲线。

实测数据显示，在相同负载下，vLLM 因采用 PagedAttention 和连续批处理技术，QPS 提升可达2~3倍，且 GPU 利用率更加平稳，极少出现剧烈抖动。这对于高并发场景尤为关键。

架构设计与工程实践建议

整个系统的架构非常清晰：

+------------------+ +---------------------+ | | | | | HunyuanOCR App +-----> Prometheus Server +-----> Grafana Dashboard | (on RTX 4090D) | | (scrape :8001) | (visualize) | | | | +--------+---------+ +----------+----------+ | | | Expose /metrics | Pull every 5s v v Embedded Metrics Store Time Series (Python Client) Data (Local TSDB)

几点最佳实践总结：

项目	推荐做法
采样频率	设置为5s，兼顾实时性与性能开销
指标命名	使用蛇形命名法（snake_case），语义清晰，如`gpu_utilization_percent`
标签设计	至少包含`gpu_id`,`endpoint`,`model_version`，便于多维下钻
安全性	将`/metrics`接口置于内网，禁止公网暴露，防止敏感信息泄露
部署隔离	Prometheus 和 Grafana 最好部署在独立节点，避免与推理服务争抢资源

未来扩展方向也很明确：
- 加入task_type标签（如"doc_ocr","field_extraction"），区分不同类型任务的性能差异；
- 结合 Alertmanager 实现阈值告警，如“连续3次QPS低于10自动通知”；
- 在 Kubernetes 环境中接入 ServiceMonitor，实现自动服务发现。