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，实现自动服务发现。
写在最后：监控不是功能，而是思维方式
很多人把监控当成上线后的“补丁”，其实它应该从第一天就融入系统设计。对 HunyuanOCR 这样的AI服务而言，模型能力再强，如果没有可靠的可观测性支撑，依然难以规模化落地。
Prometheus 提供了一个轻量、标准、易于集成的指标采集框架，而 Grafana 则赋予我们“看见系统脉搏”的能力。两者结合，不仅让我们能回答“现在怎么样”，更能预见“将来会不会出事”。
更重要的是，这套方案完全基于开源生态，无需依赖云厂商锁定，特别适合私有化部署、边缘计算等场景。无论是单机服务器还是集群环境，都能快速搭建起属于自己的智能监控中枢。
当你能在大屏上一眼看出哪块GPU在“躺平”，哪个接口即将“崩盘”，你就不再是被动救火的运维，而是掌控全局的指挥官。而这，正是现代 AI 工程化的起点。
