Gemma-3-270m性能监控使用Prometheus实现推理指标可视化1. 为什么需要监控Gemma-3-270m的服务表现当你把Gemma-3-270m部署成一个在线服务它就不再只是本地跑跑代码的玩具了。用户会不断发来请求模型要实时响应GPU显存要持续占用系统资源会一点点被吃掉。这时候如果只靠“感觉”来判断服务好不好很容易出问题——比如某天突然发现响应变慢了但根本不知道是显存爆了、CPU过载了还是网络延迟高了。我之前就遇到过类似情况服务看起来一切正常API也能调通但用户反馈说响应时间忽长忽短。查日志没报错重启服务又好了几分钟。后来加了监控才发现是显存碎片化严重每次推理前都要花时间整理内存导致延迟抖动。这种问题不靠数据光靠猜是解决不了的。监控不是给老板看的报表而是给自己装的一双眼睛。它能告诉你用户发来一个请求到底花了多少毫秒才返回结果每秒能稳定处理多少个请求有没有突然跌到零GPU显存用了多少是不是越用越多、从不释放模型进程的pid有没有异常变化是不是在悄悄重启这些信息拼在一起才能真正看清服务的健康状态。而Prometheus Grafana这套组合不需要改模型代码也不依赖特定框架只要服务暴露一个HTTP指标端点就能把关键数据抓出来、画出来、告警出来。2. 准备工作让Gemma-3-270m服务支持指标采集2.1 确认服务已启用指标端点Gemma-3-270m本身不自带监控功能但大多数推理服务框架比如vLLM、Text Generation Inference、或自建FastAPI服务都支持通过中间件暴露Prometheus指标。我们以常见的FastAPI部署为例——如果你用的是其他框架原理相通只是配置位置不同。首先检查你的服务启动命令里有没有类似--metrics或--enable-metrics的参数。如果没有就需要加一层轻量级的指标中间件。这里推荐用prometheus-fastapi-instrumentator它只需要几行代码就能接入from fastapi import FastAPI from prometheus_fastapi_instrumentator import Instrumentator app FastAPI() # 初始化监控器 instrumentator Instrumentator( should_group_status_codesTrue, should_ignore_untemplatedTrue, should_respect_env_varTrue, excluded_handlers[/health, /metrics], ) instrumentator.instrument(app).expose(app) app.get(/generate) def generate_text(prompt: str): # 这里是你的Gemma-3-270m推理逻辑 result run_gemma_inference(prompt) return {response: result}启动服务后访问http://localhost:8000/metrics你应该能看到类似这样的文本输出# HELP http_requests_total Total number of HTTP requests # TYPE http_requests_total counter http_requests_total{methodGET,status200} 42 # HELP http_request_duration_seconds Histogram of HTTP request duration # TYPE http_request_duration_seconds histogram http_request_duration_seconds_bucket{le0.005} 12 http_request_duration_seconds_bucket{le0.01} 38 ...这个端点就是Prometheus要抓取的数据源。注意pid信息不会自动出现我们需要手动加进去——因为进程ID是识别具体实例的关键尤其在多副本部署时不同pod或容器里的服务pid完全不同混在一起看指标会失真。2.2 手动注入pid指标Prometheus默认不采集系统级进程信息所以我们得自己暴露一个process_pid指标。在FastAPI应用里可以这样补充from prometheus_client import Gauge import os # 创建一个Gauge指标记录当前进程pid process_pid Gauge(process_pid, Current process ID, [pid]) app.on_event(startup) async def startup_event(): # 服务启动时记录pid pid os.getpid() process_pid.labels(pidstr(pid)).set(pid)这段代码会在服务启动时把当前进程的pid作为标签写入一个Gauge指标。后续你在Grafana里筛选指标时就能按pid维度区分不同实例了。比如你启了两个Gemma服务一个pid是1234另一个是5678它们的延迟曲线就不会叠在一起排查问题时一目了然。2.3 验证指标是否就绪别急着配Prometheus先手动验证一下。打开终端用curl请求一次metrics端点curl http://localhost:8000/metrics | grep process_pid你应该看到类似这样的输出# HELP process_pid Current process ID # TYPE process_pid gauge process_pid{pid1234} 1234.0如果能看到这行说明pid指标已经成功暴露。接下来就可以让Prometheus来定期抓取了。3. 配置Prometheus定义抓取任务与指标规则3.1 编写prometheus.yml配置文件Prometheus通过一个YAML文件定义它要监控哪些目标。我们新建一个prometheus.yml内容如下global: scrape_interval: 15s evaluation_interval: 15s scrape_configs: - job_name: gemma-3-270m static_configs: - targets: [localhost:8000] labels: instance: gemma-prod-01 model: gemma-3-270m metrics_path: /metrics scheme: http这里的关键点有三个scrape_interval: 15s表示每15秒去你的服务拉一次指标太频繁会增加开销太慢则可能错过瞬时抖动targets: [localhost:8000]是你的服务地址如果部署在其他机器或容器里改成对应IP和端口labels是给这次抓取打的标记instance代表具体机器或容器名model说明这是Gemma-3-270m模型后面在Grafana里做分组筛选全靠这些标签保存好文件后用Docker快速启动Prometheus如果你还没装docker run -d \ --name prometheus \ -p 9090:9090 \ -v $(pwd)/prometheus.yml:/etc/prometheus/prometheus.yml \ prom/prometheus等几秒钟打开浏览器访问http://localhost:9090点击左上角Status → Targets你应该能看到gemma-3-270m这个job状态是UP说明Prometheus已经连上你的服务了。3.2 定义核心推理指标查询表达式光有数据还不够得知道查什么。Prometheus用一种叫PromQL的语言来写查询。针对Gemma-3-270m的推理场景这几个查询最实用平均P95延迟毫秒histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, instance))这个表达式会算出过去5分钟内95%的请求耗时都在多少毫秒以内。比如结果是124.5说明绝大多数请求都在125ms内完成如果某天突然跳到800就得马上查原因。每秒请求数QPSsum(rate(http_requests_total[5m])) by (instance, status)它把所有请求按状态码200、400、500分组统计QPS。重点关注status200那条线如果QPS突然归零可能是服务挂了如果status500飙升说明模型推理出错了。GPU显存使用率需配合node_exporter如果你的服务器装了node_exporter用于采集主机指标可以用100 - (100 * avg by(instance) (node_gpu_memory_free_bytes{devicenvidia0}) / avg by(instance) (node_gpu_memory_total_bytes{devicenvidia0}))这行会算出GPU显存占用百分比。Gemma-3-270m虽然小但在批量推理时也可能把显存吃满一旦达到95%以上就容易OOM崩溃。按pid区分的请求量sum(rate(http_requests_total[5m])) by (pid, instance)这才是我们加pid指标的意义所在——当发现QPS下降时能立刻看出是哪个pid的实例出了问题而不是所有实例一起背锅。3.3 设置简单告警规则监控不只是看图更要能在出事前提醒你。在prometheus.yml同目录下新建alerts.ymlgroups: - name: gemma-alerts rules: - alert: GemmaHighLatency expr: histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le)) 500 for: 2m labels: severity: warning annotations: summary: Gemma-3-270m P95延迟过高 description: P95延迟超过500ms持续2分钟当前值为 {{ $value }}ms - alert: GemmaGPUMemoryFull expr: 100 - (100 * avg(node_gpu_memory_free_bytes{devicenvidia0}) / avg(node_gpu_memory_total_bytes{devicenvidia0})) 95 for: 1m labels: severity: critical annotations: summary: GPU显存使用率超95% description: Gemma服务可能因显存不足而中断当前使用率为 {{ $value }}%然后在prometheus.yml的global块下面加上rule_files: - alerts.yml重启Prometheus容器再进Web界面点Alerts就能看到这两个告警规则已加载。它们不会立刻触发但一旦条件满足就会变成红色ACTIVE状态——这就是你的第一道防线。4. 构建Grafana仪表板把数据变成可读的视图4.1 导入Grafana并连接Prometheus数据源如果你还没装Grafana同样用Docker一行搞定docker run -d \ --name grafana \ -p 3000:3000 \ -e GF_SECURITY_ADMIN_PASSWORDadmin \ grafana/grafana-enterprise启动后访问http://localhost:3000用用户名admin、密码admin登录首次登录会提示改密。进入Configuration → Data Sources → Add data source选择PrometheusURL填http://host.docker.internal:9090Mac/Windows或http://172.17.0.1:9090Linux指向宿主机Docker网关保存即可。4.2 创建核心监控面板我们不追求花哨只做四个最实用的面板每个都解决一个具体问题面板1整体延迟热力图按pid和时间可视化类型选Heatmap查询语句sum by (le, pid) (rate(http_request_duration_seconds_bucket[5m]))X轴设为时间Y轴设为le延迟区间颜色深浅代表该延迟区间的请求数量。你能一眼看出大部分请求落在哪个毫秒区间有没有某个pid的实例在特定时间段大量产生长尾延迟面板2QPS趋势与错误率叠加图可视化类型选Time series添加两条查询QPSsum(rate(http_requests_total{status200}[5m])) by (pid)错误率sum(rate(http_requests_total{status~4..|5..}[5m])) by (pid) / sum(rate(http_requests_total[5m])) by (pid)把错误率设为虚线、红色QPS设为实线、蓝色。当QPS下降的同时错误率上升基本可以断定是模型层出问题而不是网络或客户端问题。面板3GPU显存与温度联动图查询语句需node_exporter显存使用100 - (100 * avg(node_gpu_memory_free_bytes{devicenvidia0}) / avg(node_gpu_memory_total_bytes{devicenvidia0}))GPU温度node_gpu_temperature_celsius{devicenvidia0}用双Y轴左边是百分比右边是摄氏度。你会发现当显存用到90%以上时GPU温度往往也同步飙升——这不是巧合是显存紧张导致计算单元满负荷运转的结果。面板4活跃pid列表与最近请求时间可视化类型选Table查询语句max by (pid) (timestamp(http_requests_total)) * 1000这个查询会返回每个pid最后一次收到请求的时间戳毫秒级。你可以把它转成可读时间格式在表格里直接看到哪个pid还在干活哪个已经半天没动静了。对排查僵尸进程特别有用。4.3 优化仪表板体验的小技巧设置自动刷新右上角时间选择器旁点Refresh every选10s。监控图就得实时等30秒才更新一次问题都发生了。添加注释在面板右上角... → Edit → Annotations可以加一条规则把Prometheus告警事件也显示在时间轴上。这样你看延迟飙升时旁边会标出此时触发了GemmaHighLatency告警因果关系一目了然。导出分享做好后点右上角Share → Export生成JSON。下次部署新环境直接导入就能复用不用重画一遍。5. 实战调试从监控数据定位一个典型问题上周我遇到一个真实案例用户反馈Gemma-3-270m服务偶尔卡顿但日志里全是200看不出毛病。我们打开刚搭好的Grafana仪表板按步骤排查第一步看延迟热力图。发现大部分请求确实在50-100ms区间绿色但每隔3-5分钟就会有一小片深红色区域出现在500ms区间。这不是随机抖动是有规律的。第二步切到QPS趋势图。把时间范围缩到10分钟发现每次红色延迟出现时QPS都会瞬间跌到接近零持续约2秒然后恢复正常。这说明服务不是慢是短暂中断了。第三步查pid列表。发现只有一个pid比如1234在干活另一个pid5678的最后请求时间停留在20分钟前——它早就没响应了但进程还活着成了僵尸。第四步看GPU显存图。在QPS跌落的瞬间显存使用率从85%直接冲到99.8%然后一秒内回落到80%。显然是显存爆了导致推理失败服务自动重启了那个pid但重启过程花了2秒所以QPS归零。最终定位到问题批处理请求时没限制最大token数有个用户传了超长文本把显存撑爆了。解决方案很简单——在FastAPI接口里加个校验app.get(/generate) def generate_text(prompt: str, max_tokens: int Query(512, le1024)): if len(prompt) 2000: # 限制输入长度 raise HTTPException(status_code400, detailPrompt too long) # 后续推理逻辑...没有监控这个问题可能要靠用户反复投诉才能发现有了监控从看到现象到定位根因不到5分钟。6. 总结监控不是负担而是服务的呼吸感做完这一整套你得到的不只是几个漂亮的图表而是一种对服务状态的直觉把握。以后每次上线新版本不用等用户反馈先盯5分钟Grafana——延迟稳不稳定QPS有没有突降显存会不会爬升这些数据会第一时间告诉你答案。更重要的是pid这个看似简单的指标让监控从看整体变成了看个体。你不再说服务好像不太行而是能明确指出pid 1234这个实例在过去一小时里重启了3次显存峰值达99.2%。这种颗粒度是优化稳定性的基础。当然监控本身也需要维护。建议你每周花10分钟看看有没有新出现的告警某个面板的数据是否长时间没更新可能指标暴露失效了但比起半夜被报警电话叫醒排查故障这点时间投入实在太值了。如果你刚部署完Gemma-3-270m别急着优化prompt或者调参先把监控搭起来。它不会让你的模型变得更强但能确保它一直在线、一直可靠——这才是工程落地最实在的底气。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。
Gemma-3-270m性能监控：使用Prometheus实现推理指标可视化
Gemma-3-270m性能监控使用Prometheus实现推理指标可视化1. 为什么需要监控Gemma-3-270m的服务表现当你把Gemma-3-270m部署成一个在线服务它就不再只是本地跑跑代码的玩具了。用户会不断发来请求模型要实时响应GPU显存要持续占用系统资源会一点点被吃掉。这时候如果只靠“感觉”来判断服务好不好很容易出问题——比如某天突然发现响应变慢了但根本不知道是显存爆了、CPU过载了还是网络延迟高了。我之前就遇到过类似情况服务看起来一切正常API也能调通但用户反馈说响应时间忽长忽短。查日志没报错重启服务又好了几分钟。后来加了监控才发现是显存碎片化严重每次推理前都要花时间整理内存导致延迟抖动。这种问题不靠数据光靠猜是解决不了的。监控不是给老板看的报表而是给自己装的一双眼睛。它能告诉你用户发来一个请求到底花了多少毫秒才返回结果每秒能稳定处理多少个请求有没有突然跌到零GPU显存用了多少是不是越用越多、从不释放模型进程的pid有没有异常变化是不是在悄悄重启这些信息拼在一起才能真正看清服务的健康状态。而Prometheus Grafana这套组合不需要改模型代码也不依赖特定框架只要服务暴露一个HTTP指标端点就能把关键数据抓出来、画出来、告警出来。2. 准备工作让Gemma-3-270m服务支持指标采集2.1 确认服务已启用指标端点Gemma-3-270m本身不自带监控功能但大多数推理服务框架比如vLLM、Text Generation Inference、或自建FastAPI服务都支持通过中间件暴露Prometheus指标。我们以常见的FastAPI部署为例——如果你用的是其他框架原理相通只是配置位置不同。首先检查你的服务启动命令里有没有类似--metrics或--enable-metrics的参数。如果没有就需要加一层轻量级的指标中间件。这里推荐用prometheus-fastapi-instrumentator它只需要几行代码就能接入from fastapi import FastAPI from prometheus_fastapi_instrumentator import Instrumentator app FastAPI() # 初始化监控器 instrumentator Instrumentator( should_group_status_codesTrue, should_ignore_untemplatedTrue, should_respect_env_varTrue, excluded_handlers[/health, /metrics], ) instrumentator.instrument(app).expose(app) app.get(/generate) def generate_text(prompt: str): # 这里是你的Gemma-3-270m推理逻辑 result run_gemma_inference(prompt) return {response: result}启动服务后访问http://localhost:8000/metrics你应该能看到类似这样的文本输出# HELP http_requests_total Total number of HTTP requests # TYPE http_requests_total counter http_requests_total{methodGET,status200} 42 # HELP http_request_duration_seconds Histogram of HTTP request duration # TYPE http_request_duration_seconds histogram http_request_duration_seconds_bucket{le0.005} 12 http_request_duration_seconds_bucket{le0.01} 38 ...这个端点就是Prometheus要抓取的数据源。注意pid信息不会自动出现我们需要手动加进去——因为进程ID是识别具体实例的关键尤其在多副本部署时不同pod或容器里的服务pid完全不同混在一起看指标会失真。2.2 手动注入pid指标Prometheus默认不采集系统级进程信息所以我们得自己暴露一个process_pid指标。在FastAPI应用里可以这样补充from prometheus_client import Gauge import os # 创建一个Gauge指标记录当前进程pid process_pid Gauge(process_pid, Current process ID, [pid]) app.on_event(startup) async def startup_event(): # 服务启动时记录pid pid os.getpid() process_pid.labels(pidstr(pid)).set(pid)这段代码会在服务启动时把当前进程的pid作为标签写入一个Gauge指标。后续你在Grafana里筛选指标时就能按pid维度区分不同实例了。比如你启了两个Gemma服务一个pid是1234另一个是5678它们的延迟曲线就不会叠在一起排查问题时一目了然。2.3 验证指标是否就绪别急着配Prometheus先手动验证一下。打开终端用curl请求一次metrics端点curl http://localhost:8000/metrics | grep process_pid你应该看到类似这样的输出# HELP process_pid Current process ID # TYPE process_pid gauge process_pid{pid1234} 1234.0如果能看到这行说明pid指标已经成功暴露。接下来就可以让Prometheus来定期抓取了。3. 配置Prometheus定义抓取任务与指标规则3.1 编写prometheus.yml配置文件Prometheus通过一个YAML文件定义它要监控哪些目标。我们新建一个prometheus.yml内容如下global: scrape_interval: 15s evaluation_interval: 15s scrape_configs: - job_name: gemma-3-270m static_configs: - targets: [localhost:8000] labels: instance: gemma-prod-01 model: gemma-3-270m metrics_path: /metrics scheme: http这里的关键点有三个scrape_interval: 15s表示每15秒去你的服务拉一次指标太频繁会增加开销太慢则可能错过瞬时抖动targets: [localhost:8000]是你的服务地址如果部署在其他机器或容器里改成对应IP和端口labels是给这次抓取打的标记instance代表具体机器或容器名model说明这是Gemma-3-270m模型后面在Grafana里做分组筛选全靠这些标签保存好文件后用Docker快速启动Prometheus如果你还没装docker run -d \ --name prometheus \ -p 9090:9090 \ -v $(pwd)/prometheus.yml:/etc/prometheus/prometheus.yml \ prom/prometheus等几秒钟打开浏览器访问http://localhost:9090点击左上角Status → Targets你应该能看到gemma-3-270m这个job状态是UP说明Prometheus已经连上你的服务了。3.2 定义核心推理指标查询表达式光有数据还不够得知道查什么。Prometheus用一种叫PromQL的语言来写查询。针对Gemma-3-270m的推理场景这几个查询最实用平均P95延迟毫秒histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, instance))这个表达式会算出过去5分钟内95%的请求耗时都在多少毫秒以内。比如结果是124.5说明绝大多数请求都在125ms内完成如果某天突然跳到800就得马上查原因。每秒请求数QPSsum(rate(http_requests_total[5m])) by (instance, status)它把所有请求按状态码200、400、500分组统计QPS。重点关注status200那条线如果QPS突然归零可能是服务挂了如果status500飙升说明模型推理出错了。GPU显存使用率需配合node_exporter如果你的服务器装了node_exporter用于采集主机指标可以用100 - (100 * avg by(instance) (node_gpu_memory_free_bytes{devicenvidia0}) / avg by(instance) (node_gpu_memory_total_bytes{devicenvidia0}))这行会算出GPU显存占用百分比。Gemma-3-270m虽然小但在批量推理时也可能把显存吃满一旦达到95%以上就容易OOM崩溃。按pid区分的请求量sum(rate(http_requests_total[5m])) by (pid, instance)这才是我们加pid指标的意义所在——当发现QPS下降时能立刻看出是哪个pid的实例出了问题而不是所有实例一起背锅。3.3 设置简单告警规则监控不只是看图更要能在出事前提醒你。在prometheus.yml同目录下新建alerts.ymlgroups: - name: gemma-alerts rules: - alert: GemmaHighLatency expr: histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le)) 500 for: 2m labels: severity: warning annotations: summary: Gemma-3-270m P95延迟过高 description: P95延迟超过500ms持续2分钟当前值为 {{ $value }}ms - alert: GemmaGPUMemoryFull expr: 100 - (100 * avg(node_gpu_memory_free_bytes{devicenvidia0}) / avg(node_gpu_memory_total_bytes{devicenvidia0})) 95 for: 1m labels: severity: critical annotations: summary: GPU显存使用率超95% description: Gemma服务可能因显存不足而中断当前使用率为 {{ $value }}%然后在prometheus.yml的global块下面加上rule_files: - alerts.yml重启Prometheus容器再进Web界面点Alerts就能看到这两个告警规则已加载。它们不会立刻触发但一旦条件满足就会变成红色ACTIVE状态——这就是你的第一道防线。4. 构建Grafana仪表板把数据变成可读的视图4.1 导入Grafana并连接Prometheus数据源如果你还没装Grafana同样用Docker一行搞定docker run -d \ --name grafana \ -p 3000:3000 \ -e GF_SECURITY_ADMIN_PASSWORDadmin \ grafana/grafana-enterprise启动后访问http://localhost:3000用用户名admin、密码admin登录首次登录会提示改密。进入Configuration → Data Sources → Add data source选择PrometheusURL填http://host.docker.internal:9090Mac/Windows或http://172.17.0.1:9090Linux指向宿主机Docker网关保存即可。4.2 创建核心监控面板我们不追求花哨只做四个最实用的面板每个都解决一个具体问题面板1整体延迟热力图按pid和时间可视化类型选Heatmap查询语句sum by (le, pid) (rate(http_request_duration_seconds_bucket[5m]))X轴设为时间Y轴设为le延迟区间颜色深浅代表该延迟区间的请求数量。你能一眼看出大部分请求落在哪个毫秒区间有没有某个pid的实例在特定时间段大量产生长尾延迟面板2QPS趋势与错误率叠加图可视化类型选Time series添加两条查询QPSsum(rate(http_requests_total{status200}[5m])) by (pid)错误率sum(rate(http_requests_total{status~4..|5..}[5m])) by (pid) / sum(rate(http_requests_total[5m])) by (pid)把错误率设为虚线、红色QPS设为实线、蓝色。当QPS下降的同时错误率上升基本可以断定是模型层出问题而不是网络或客户端问题。面板3GPU显存与温度联动图查询语句需node_exporter显存使用100 - (100 * avg(node_gpu_memory_free_bytes{devicenvidia0}) / avg(node_gpu_memory_total_bytes{devicenvidia0}))GPU温度node_gpu_temperature_celsius{devicenvidia0}用双Y轴左边是百分比右边是摄氏度。你会发现当显存用到90%以上时GPU温度往往也同步飙升——这不是巧合是显存紧张导致计算单元满负荷运转的结果。面板4活跃pid列表与最近请求时间可视化类型选Table查询语句max by (pid) (timestamp(http_requests_total)) * 1000这个查询会返回每个pid最后一次收到请求的时间戳毫秒级。你可以把它转成可读时间格式在表格里直接看到哪个pid还在干活哪个已经半天没动静了。对排查僵尸进程特别有用。4.3 优化仪表板体验的小技巧设置自动刷新右上角时间选择器旁点Refresh every选10s。监控图就得实时等30秒才更新一次问题都发生了。添加注释在面板右上角... → Edit → Annotations可以加一条规则把Prometheus告警事件也显示在时间轴上。这样你看延迟飙升时旁边会标出此时触发了GemmaHighLatency告警因果关系一目了然。导出分享做好后点右上角Share → Export生成JSON。下次部署新环境直接导入就能复用不用重画一遍。5. 实战调试从监控数据定位一个典型问题上周我遇到一个真实案例用户反馈Gemma-3-270m服务偶尔卡顿但日志里全是200看不出毛病。我们打开刚搭好的Grafana仪表板按步骤排查第一步看延迟热力图。发现大部分请求确实在50-100ms区间绿色但每隔3-5分钟就会有一小片深红色区域出现在500ms区间。这不是随机抖动是有规律的。第二步切到QPS趋势图。把时间范围缩到10分钟发现每次红色延迟出现时QPS都会瞬间跌到接近零持续约2秒然后恢复正常。这说明服务不是慢是短暂中断了。第三步查pid列表。发现只有一个pid比如1234在干活另一个pid5678的最后请求时间停留在20分钟前——它早就没响应了但进程还活着成了僵尸。第四步看GPU显存图。在QPS跌落的瞬间显存使用率从85%直接冲到99.8%然后一秒内回落到80%。显然是显存爆了导致推理失败服务自动重启了那个pid但重启过程花了2秒所以QPS归零。最终定位到问题批处理请求时没限制最大token数有个用户传了超长文本把显存撑爆了。解决方案很简单——在FastAPI接口里加个校验app.get(/generate) def generate_text(prompt: str, max_tokens: int Query(512, le1024)): if len(prompt) 2000: # 限制输入长度 raise HTTPException(status_code400, detailPrompt too long) # 后续推理逻辑...没有监控这个问题可能要靠用户反复投诉才能发现有了监控从看到现象到定位根因不到5分钟。6. 总结监控不是负担而是服务的呼吸感做完这一整套你得到的不只是几个漂亮的图表而是一种对服务状态的直觉把握。以后每次上线新版本不用等用户反馈先盯5分钟Grafana——延迟稳不稳定QPS有没有突降显存会不会爬升这些数据会第一时间告诉你答案。更重要的是pid这个看似简单的指标让监控从看整体变成了看个体。你不再说服务好像不太行而是能明确指出pid 1234这个实例在过去一小时里重启了3次显存峰值达99.2%。这种颗粒度是优化稳定性的基础。当然监控本身也需要维护。建议你每周花10分钟看看有没有新出现的告警某个面板的数据是否长时间没更新可能指标暴露失效了但比起半夜被报警电话叫醒排查故障这点时间投入实在太值了。如果你刚部署完Gemma-3-270m别急着优化prompt或者调参先把监控搭起来。它不会让你的模型变得更强但能确保它一直在线、一直可靠——这才是工程落地最实在的底气。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。
