
Phi-3-mini-128k-instruct模型服务监控与调优使用Prometheus与Grafana把模型服务部署上线只是第一步。接下来你可能会遇到一些让人头疼的问题服务怎么突然变慢了GPU是不是快被撑爆了每天到底处理了多少请求如果回答不上来那你的服务就像在黑夜里开车完全不知道路况。今天我们就来给Phi-3-mini-128k-instruct的API服务装上“行车记录仪”和“仪表盘”。通过Prometheus和Grafana这套黄金组合把服务的GPU使用率、请求延迟、吞吐量这些关键指标变成一目了然的图表。这样你不仅能实时看到服务的“健康状况”还能基于数据做出聪明的调优决策比如什么时候该扩容哪个环节是瓶颈。整个过程并不复杂跟着做一遍你就能拥有一个属于自己的专业级监控系统。1. 为什么需要监控先理清思路在开始动手之前我们得先想明白到底要监控什么。漫无目的地收集数据只会得到一堆没用的数字。对于像Phi-3-mini-128k-instruct这样的模型API服务我们最关心的无非是三类问题资源够不够用GPU内存会不会爆显存用了多少CPU和内存压力大不大服务快不快用户请求要等多久服务处理一个请求要花多少时间服务稳不稳每秒能处理多少请求有多少请求失败了服务是不是一直在正常运行对应的我们需要收集以下几类核心指标GPU指标显存使用量、GPU利用率、温度如果支持。系统指标CPU使用率、内存使用量、磁盘I/O、网络流量。应用指标请求延迟从接收到响应的时间、每秒请求数QPS/TPS、错误率HTTP 5xx/4xx状态码数量。业务指标可选根据你的场景还可以监控平均输入/输出token数、特定类型请求的占比等。Prometheus负责定时抓取和存储这些指标数据而Grafana则负责用各种漂亮的图表把它们展示出来让你一眼就能看懂。2. 搭建监控环境一步步来我们假设你的Phi-3服务已经通过类似FastAPI的框架部署好了并且运行在一台Linux服务器上。下面的步骤会引导你完成监控组件的安装和配置。2.1 安装与配置PrometheusPrometheus是一个开源的监控和告警工具。它通过HTTP协议主动从配置好的目标比如我们的模型服务上“抓取”指标数据。首先下载并解压Prometheus。你可以去它的官网找到最新版本的链接。# 下载Prometheus请替换为最新版本号 wget https://github.com/prometheus/prometheus/releases/download/v2.47.0/prometheus-2.47.0.linux-amd64.tar.gz tar xvfz prometheus-2.47.0.linux-amd64.tar.gz cd prometheus-2.47.0.linux-amd64接下来是关键的一步配置Prometheus告诉它要去哪里抓取数据。编辑prometheus.yml配置文件。# prometheus.yml global: scrape_interval: 15s # 每15秒抓取一次数据 scrape_configs: # 监控Prometheus自身 - job_name: prometheus static_configs: - targets: [localhost:9090] # 监控Linux服务器节点通过Node Exporter - job_name: node static_configs: - targets: [localhost:9100] # Node Exporter默认端口 # 监控我们的Phi-3模型API服务 - job_name: phi3-api metrics_path: /metrics # 你的服务暴露指标的路径 static_configs: - targets: [your-api-server-ip:your-api-port] # 替换为你的服务地址和端口 # 可以添加一些标签方便在Grafana里筛选 relabel_configs: - source_labels: [__address__] target_label: instance replacement: phi3-production-01配置好后就可以启动Prometheus了。# 在前台启动方便看日志 ./prometheus --config.fileprometheus.yml # 或者使用nohup在后台运行 nohup ./prometheus --config.fileprometheus.yml prometheus.log 21 现在访问http://你的服务器IP:9090就能看到Prometheus的Web界面了。在“Status - Targets”页面可以看到我们配置的监控目标状态是否为“UP”。2.2 安装与配置Node ExporterNode Exporter是Prometheus的一个组件专门用于收集Linux主机的硬件和操作系统指标CPU、内存、磁盘、网络等。# 下载Node Exporter wget https://github.com/prometheus/node_exporter/releases/download/v1.6.1/node_exporter-1.6.1.linux-amd64.tar.gz tar xvfz node_exporter-1.6.1.linux-amd64.tar.gz cd node_exporter-1.6.1.linux-amd64 # 启动Node Exporter ./node_exporter它默认运行在9100端口。确保Prometheus配置中targets: [localhost:9100]指向正确。2.3 为模型服务添加指标暴露Prometheus只能抓取那些以特定格式通常是纯文本暴露了/metrics接口的服务。我们的FastAPI服务需要集成一个Prometheus客户端库。安装Python的Prometheus客户端pip install prometheus-client然后在你的FastAPI应用主文件中比如main.py添加以下代码from fastapi import FastAPI from prometheus_client import make_asgi_app, Counter, Histogram, Gauge import time app FastAPI() # 创建Prometheus ASGI中间件用于提供/metrics端点 metrics_app make_asgi_app() app.mount(/metrics, metrics_app) # 定义一些自定义指标 # 计数器总请求数 REQUEST_COUNT Counter( phi3_api_requests_total, Total number of requests to Phi-3 API, [method, endpoint, status_code] ) # 直方图请求延迟秒用于计算分位数如P95 P99 REQUEST_LATENCY Histogram( phi3_api_request_duration_seconds, Request latency in seconds, [method, endpoint], buckets(0.1, 0.5, 1.0, 2.0, 5.0, 10.0) # 自定义桶 ) # 仪表盘当前正在处理的请求数 IN_PROGRESS_REQUESTS Gauge( phi3_api_inprogress_requests, Number of requests currently being processed ) # 一个示例的API端点 app.post(/v1/chat/completions) async def chat_completion(request_data: dict): # 记录正在处理的请求数增加 IN_PROGRESS_REQUESTS.inc() start_time time.time() try: # ... 这里是你的模型推理逻辑 ... result {response: This is a simulated response.} status_code 200 except Exception as e: status_code 500 result {error: str(e)} finally: # 记录请求延迟 REQUEST_LATENCY.labels(methodPOST, endpoint/v1/chat/completions).observe(time.time() - start_time) # 记录正在处理的请求数减少 IN_PROGRESS_REQUESTS.dec() # 记录总请求数带标签 REQUEST_COUNT.labels(methodPOST, endpoint/v1/chat/completions, status_codestatus_code).inc() return result重启你的FastAPI服务后访问http://你的API地址:端口/metrics你应该能看到Prometheus格式的指标数据了。别忘了在prometheus.yml中配置这个目标。2.4 安装与配置GrafanaGrafana是数据可视化平台它从Prometheus读取数据并绘制成仪表盘。# 以Ubuntu/Debian为例添加Grafana仓库并安装 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 grafana # 启动Grafana服务 sudo systemctl start grafana-server sudo systemctl enable grafana-server # 设置开机自启Grafana默认运行在3000端口。打开浏览器访问http://你的服务器IP:3000默认用户名和密码都是admin首次登录会要求修改密码。登录后第一件事是添加数据源点击左侧齿轮图标 -Data Sources-Add data source。选择Prometheus。在URL栏填写你的Prometheus地址通常是http://localhost:9090如果Grafana和Prometheus装在同一台机器。点击Save Test如果显示“Data source is working”就成功了。3. 制作Grafana仪表盘让数据说话有了数据源我们就可以创建仪表盘了。你可以从零开始自己拖拽图表但更高效的方法是导入现成的社区仪表盘。3.1 导入Node Exporter仪表盘对于服务器基础监控Grafana社区有非常成熟的仪表盘模板。在Grafana首页点击Dashboards-New-Import。在Import via grafana.com输入框中输入仪表盘ID1860这是一个非常流行的Node Exporter全指标仪表盘。选择我们刚才添加的Prometheus数据源点击Import。瞬间一个包含CPU、内存、磁盘、网络等全方位监控的仪表盘就出现了。你可以在这个基础上调整隐藏不需要的面板。3.2 创建自定义的模型服务监控面板现在我们来创建针对Phi-3 API服务的专属监控视图。点击仪表盘右上角的Add panel-Add a new panel。这里举几个关键面板的配置例子面板1请求速率QPS图表类型选择Stat或Time series。查询语句PromQLrate(phi3_api_requests_total{status_code~2..}[5m])rate()计算指标在5分钟窗口内的平均增长速率即每秒请求数。{status_code~2..}筛选HTTP状态码为2xx的成功请求。设置可以给面板起个名字比如“请求速率成功”单位选择reqs/s。面板2请求延迟P95图表类型选择Time series。查询语句PromQLhistogram_quantile(0.95, sum(rate(phi3_api_request_duration_seconds_bucket[5m])) by (le, endpoint))histogram_quantile(0.95, ...)计算95分位数的延迟。这个值意味着95%的请求响应时间都低于这个值是衡量服务性能的关键指标。phi3_api_request_duration_seconds_bucket是直方图指标自动生成的桶数据。设置单位选择seconds。面板3GPU显存使用率这需要你的服务器上安装了NVIDIA GPU并部署了nvidia_gpu_exporter或dcgm-exporter来暴露GPU指标。假设使用了dcgm-exporter查询语句可能类似DCGM_FI_DEV_FB_USED{instanceyour-gpu-node} / DCGM_FI_DEV_FB_TOTAL{instanceyour-gpu-node} * 100设置单位选择percent。面板4当前活跃请求数查询语句phi3_api_inprogress_requests这个仪表盘Gauge类型的指标可以直接显示当前值帮助你了解服务的实时负载。把这些面板合理排列在你的仪表盘上你就拥有了一个实时监控Phi-3模型服务健康状况的“作战指挥中心”。4. 从监控到行动性能调优与容量规划监控不是为了看漂亮的图表而是为了指导行动。当仪表盘出现异常时你知道该怎么做吗场景一P95延迟持续升高排查首先看GPU利用率和显存是否饱和。如果GPU已满说明当前并发下模型计算成为瓶颈。同时检查IN_PROGRESS_REQUESTS是否过高可能是请求队列积压。调优模型层面如果使用vLLM等推理引擎可以尝试调整max_num_seqs批处理大小在吞吐量和延迟之间找到平衡。服务层面检查API服务本身是否有阻塞操作比如同步的磁盘读写或网络调用。考虑使用异步处理。架构层面如果单实例无法满足需要考虑部署多个服务实例并用负载均衡器如Nginx进行分流。场景二GPU显存使用率接近100%排查确认是模型加载本身占用过高还是在处理请求时因批处理或长序列导致峰值显存溢出。调优限制请求参数在API层面限制用户可输入的max_tokens防止单个请求消耗过多显存。优化批处理减少批处理大小虽然可能降低吞吐但能保证稳定性。使用更高效的格式确保模型以FP16或INT8等量化格式加载可以显著减少显存占用。场景三错误率5xx突然飙升排查结合延迟和资源指标看。如果是资源耗尽如OOM通常会伴随延迟暴涨。也可能是下游依赖服务故障或代码BUG。行动设置Grafana告警Alert当错误率超过阈值如1%时通过邮件、钉钉、Slack等渠道通知你。这样你可以在用户大量投诉前介入处理。容量规划通过长期观察仪表盘你可以回答这些问题在业务高峰时段QPS是多少平均延迟是多少需要多少GPU显存根据这些数据你可以科学地规划资源为了应对下个季度的流量增长我们需要增加多少台服务器现有的GPU型号是否合适是否需要升级你可以利用Prometheus记录的历史数据绘制流量增长趋势图为未来的扩容计划提供数据支撑。5. 总结给Phi-3-mini模型服务配上Prometheus和Grafana就像给汽车装上了全套的仪表和行车电脑。你不再需要靠“感觉”来猜测服务的状态每一个指标、每一次波动都清晰可见。这套监控体系的价值会随着服务运行时间的增长而愈发凸显。它不仅能帮你快速定位和解决眼前的问题更能为你长期的性能优化和容量规划提供坚实的数据基础。花点时间把它搭建起来绝对是笔划算的投资。当你看着仪表盘上平稳的曲线心里会踏实很多。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。