模型服务监控面板延迟、吞吐、错误率、显存四象限监控一、你的监控面板有 50 个图表但真正有用的是哪几个打开生产环境的 Grafana 面板密密麻麻的折线图、柱状图、饼图、热力图。GPU 利用率、CPU 使用率、内存占用、磁盘 I/O、网络带宽、请求 QPS、错误 4xx、错误 5xx、P50 延迟、P99 延迟……50 多个图表布满了整个屏幕。但当服务真的出问题时你会看哪几个经验表明绝大多数故障定位只需要 4 个核心指标延迟、吞吐、错误率、显存。这四者构成了模型推理服务的生命体征。它们之间存在内在关联——延迟突然升高而吞吐下降通常是模型推理出现了瓶颈如长序列输入激增错误率上升而延迟正常通常是参数校验或预处理出了问题显存持续增长而其他指标正常可能是 KV Cache 的内存泄漏。二、四象限监控面板设计从混乱到聚焦flowchart TD A[模型推理服务监控] -- B{核心四象限} B -- C[象限1: 延迟 Latency] B -- D[象限2: 吞吐 Throughput] B -- E[象限3: 错误率 Error Rate] B -- F[象限4: 显存 VRAM] C -- C1[P50 / P95 / P99 分位数] C -- C2[首 Token 延迟 TTFT] C -- C3[Token 生成速度 tok/s] C -- C4[按请求长度分桶] D -- D1[QPS 每秒请求数] D -- D2[TPS 每秒 Token 数] D -- D3[并发连接数] D -- D4[批处理利用率] E -- E1[HTTP 4xx / 5xx 比例] E -- E2[模型推理失败率] E -- E3[超时率] E -- E4[OOM 事件计数] F -- F1[已分配显存 / 总显存] F -- F2[KV Cache 占用] F -- F3[显存增长趋势] F -- F4[显存碎片率] C -- G{关联分析} D -- G E -- G F -- G G -- H[延迟↑ 吞吐↓ → 推理瓶颈] G -- I[错误↑ 延迟正常 → 参数/预处理问题] G -- J[显存↑ 其他正常 → 内存泄漏] G -- K[全部正常 → 服务健康] style H fill:#ff9800,color:#fff style I fill:#1565c0,color:#fff style J fill:#c62828,color:#fff style K fill:#2e7d32,color:#fff四象限之间的关联是诊断的关键延迟 吞吐反向变化延迟升高同时吞吐下降 → GPU 推理饱和需要扩容或优化延迟 吞吐同向变化延迟和吞吐都正常波动 → 正常负载变化无需干预错误率独立变化错误率上升但延迟吞吐正常 → 问题在输入验证或依赖服务显存独立增长显存持续增长其他指标不变 → 大概率是内存泄漏。三、构建四象限监控面板的 Prometheus Grafana 方案from prometheus_client import ( Counter, Gauge, Histogram, Summary, start_http_server, CollectorRegistry ) import torch import time from functools import wraps import psutil # 设计原因定义四象限的 Prometheus 指标 # 所有指标都带 labels如 model_name, gpu_id方便多模型多卡聚合 registry CollectorRegistry() # 象限1: 延迟指标 inference_latency Histogram( inference_latency_seconds, 端到端推理延迟, [model_name, request_type], # 设计原因使用分桶而非单一值 # 分桶可以计算任意分位数P50/P95/P99 # P95 通常比平均值更能反映用户体验 buckets[0.01, 0.05, 0.1, 0.25, 0.5, 1.0, 2.5, 5.0, 10.0], registryregistry, ) ttft_latency Histogram( ttft_latency_seconds, 首 Token 延迟, [model_name], # 设计原因TTFTTime to First Token影响用户感知 # 用户在等待第一个字的响应TTFT 2s 体验明显下降 buckets[0.1, 0.25, 0.5, 1.0, 2.0, 5.0], registryregistry, ) # 象限2: 吞吐指标 request_qps Counter( inference_requests_total, 推理请求总数, [model_name, status], registryregistry, ) token_throughput Counter( generated_tokens_total, 生成的 Token 总数, [model_name], registryregistry, ) concurrent_requests Gauge( concurrent_requests, 当前并发请求数, [model_name], registryregistry, ) # 象限3: 错误率指标 error_counter Counter( inference_errors_total, 推理错误总数, [model_name, error_type], registryregistry, ) oom_events Counter( oom_events_total, OOM 事件计数, [model_name, gpu_id], registryregistry, ) # 象限4: 显存指标 # 设计原因区分 allocated 和 reserved # allocated 实际在用的显存reserved PyTorch 缓存池占用 # reserved allocated 多出的部分是 PyTorch 的显存缓存可以被复用 vram_allocated Gauge( gpu_memory_allocated_bytes, GPU 已分配显存, [model_name, gpu_id], registryregistry, ) vram_reserved Gauge( gpu_memory_reserved_bytes, GPU 已保留显存, [model_name, gpu_id], registryregistry, ) # 设计原因KV Cache 是显存的最大消耗者 # 单独监控可以识别请求变长导致显存增长的模式 kv_cache_usage Gauge( kv_cache_usage_bytes, KV Cache 显存占用, [model_name], registryregistry, ) def monitor_inference(service_name: str): 推理服务监控装饰器 设计原因在推理函数上添加装饰器无侵入地采集指标 业务代码不需要修改装饰器负责全部指标采集 def decorator(func): wraps(func) def wrapper(*args, **kwargs): # 设计原因先递增并发计数推理结束后递减 # 这样在指标中可以看到实时并发数 concurrent_requests.labels(service_name).inc() start_time time.time() try: result func(*args, **kwargs) elapsed time.time() - start_time # 记录延迟端到端 inference_latency.labels( service_name, kwargs.get(request_type, unknown) ).observe(elapsed) # 记录成功的请求 request_qps.labels(service_name, success).inc() return result except Exception as e: # 设计原因按错误类型分类记录 # OOMTimeoutValidationUnknown 各有不同的处理策略 error_type type(e).__name__ error_counter.labels(service_name, error_type).inc() request_qps.labels(service_name, error).inc() raise finally: concurrent_requests.labels(service_name).dec() return wrapper return decorator def collect_gpu_metrics(model_name: str, gpu_id: int 0): 定时采集 GPU 指标 设计原因用独立的后台线程采集显存指标 不依赖请求触发确保显存数据在无请求时也能持续上报 if not torch.cuda.is_available(): return # 设计原因allocated 是真实使用判断是否即将 OOM # reserved 是 PyTorch 缓存判断内存碎片化程度 allocated torch.cuda.memory_allocated(gpu_id) reserved torch.cuda.memory_reserved(gpu_id) total torch.cuda.get_device_properties(gpu_id).total_memory vram_allocated.labels(model_name, str(gpu_id)).set(allocated) vram_reserved.labels(model_name, str(gpu_id)).set(reserved) # 设计原因计算碎片率用于告警 # (reserved - allocated) / total 0.3 表示大量显存被缓存占用但不能复用 # 常见于频繁分配和释放不同大小的 Tensor fragmentation (reserved - allocated) / total if fragmentation 0.3: print(f[WARNING] GPU{gpu_id} 显存碎片率过高: {fragmentation:.1%}) def start_monitoring_server(port: int 8001): 启动 Prometheus 指标暴露服务 start_http_server(port, registryregistry) print(f监控指标服务启动: http://localhost:{port}/metrics)Prometheus 对应的告警规则prometheus_rules.ymlgroups: - name: inference_alerts rules: # 延迟告警P95 2s 持续 5 分钟 - alert: HighLatency expr: histogram_quantile(0.95, rate(inference_latency_seconds_bucket[5m])) 2 for: 5m labels: severity: warning annotations: summary: 推理延迟过高 description: {{ $labels.model_name }} P95 延迟 {{ $value }}s # 错误率告警错误率 1% 持续 2 分钟 - alert: HighErrorRate expr: | rate(inference_errors_total[2m]) / rate(inference_requests_total[2m]) 0.01 for: 2m labels: severity: critical annotations: summary: 推理错误率超过 1% # 显存告警已分配 90% - alert: HighVRAM expr: | gpu_memory_allocated_bytes / (gpu_memory_allocated_bytes gpu_memory_reserved_bytes) 0.9 for: 1m labels: severity: critical annotations: summary: GPU 显存使用超过 90%四、监控的金丝雀原则不是越多越好增加监控指标会带来隐藏成本采集开销每个指标都需要 CPU 时间来更新高 QPS 下采集开销不可忽视存储成本Prometheus 时序数据库的存储成本随指标数线性增长查询复杂度指标太多时Grafana 面板加载变慢dashboard 的可读性下降认知负载面面俱到的监控往往意味着真正重要的信号被稀释。精简原则每个服务不超过 20 个核心指标新增指标前先确认这个指标会改变我的行动吗。如果不会就不需要指标带足够维度的 label 来支持 drill-down按模型、GPU、请求类型拆分但 label 基数不要太大高基数 label 会炸 Prometheus不要为以防万一而添加指标。等真正需要时再加。五、总结模型推理服务的核心监控指标应聚焦于四象限延迟、吞吐、错误率、显存。四者之间的关联关系是故障诊断的关键——延迟和吞吐反向变化表示推理饱和错误率独立变化表示输入或依赖问题显存独立增长表示内存泄漏。使用 Prometheus 的 Histogram 和 Gauge 指标类型配合合理的分桶和标签维度。监控指标的数量需要控制在 20 个以内避免认知过载和存储膨胀。每个指标在添加前需要回答它是否会改变行动——如果答案是否定的则不添加。
模型服务监控面板延迟、吞吐、错误率、显存四象限监控一、你的监控面板有 50 个图表但真正有用的是哪几个打开生产环境的 Grafana 面板密密麻麻的折线图、柱状图、饼图、热力图。GPU 利用率、CPU 使用率、内存占用、磁盘 I/O、网络带宽、请求 QPS、错误 4xx、错误 5xx、P50 延迟、P99 延迟……50 多个图表布满了整个屏幕。但当服务真的出问题时你会看哪几个经验表明绝大多数故障定位只需要 4 个核心指标延迟、吞吐、错误率、显存。这四者构成了模型推理服务的生命体征。它们之间存在内在关联——延迟突然升高而吞吐下降通常是模型推理出现了瓶颈如长序列输入激增错误率上升而延迟正常通常是参数校验或预处理出了问题显存持续增长而其他指标正常可能是 KV Cache 的内存泄漏。二、四象限监控面板设计从混乱到聚焦flowchart TD A[模型推理服务监控] -- B{核心四象限} B -- C[象限1: 延迟 Latency] B -- D[象限2: 吞吐 Throughput] B -- E[象限3: 错误率 Error Rate] B -- F[象限4: 显存 VRAM] C -- C1[P50 / P95 / P99 分位数] C -- C2[首 Token 延迟 TTFT] C -- C3[Token 生成速度 tok/s] C -- C4[按请求长度分桶] D -- D1[QPS 每秒请求数] D -- D2[TPS 每秒 Token 数] D -- D3[并发连接数] D -- D4[批处理利用率] E -- E1[HTTP 4xx / 5xx 比例] E -- E2[模型推理失败率] E -- E3[超时率] E -- E4[OOM 事件计数] F -- F1[已分配显存 / 总显存] F -- F2[KV Cache 占用] F -- F3[显存增长趋势] F -- F4[显存碎片率] C -- G{关联分析} D -- G E -- G F -- G G -- H[延迟↑ 吞吐↓ → 推理瓶颈] G -- I[错误↑ 延迟正常 → 参数/预处理问题] G -- J[显存↑ 其他正常 → 内存泄漏] G -- K[全部正常 → 服务健康] style H fill:#ff9800,color:#fff style I fill:#1565c0,color:#fff style J fill:#c62828,color:#fff style K fill:#2e7d32,color:#fff四象限之间的关联是诊断的关键延迟 吞吐反向变化延迟升高同时吞吐下降 → GPU 推理饱和需要扩容或优化延迟 吞吐同向变化延迟和吞吐都正常波动 → 正常负载变化无需干预错误率独立变化错误率上升但延迟吞吐正常 → 问题在输入验证或依赖服务显存独立增长显存持续增长其他指标不变 → 大概率是内存泄漏。三、构建四象限监控面板的 Prometheus Grafana 方案from prometheus_client import ( Counter, Gauge, Histogram, Summary, start_http_server, CollectorRegistry ) import torch import time from functools import wraps import psutil # 设计原因定义四象限的 Prometheus 指标 # 所有指标都带 labels如 model_name, gpu_id方便多模型多卡聚合 registry CollectorRegistry() # 象限1: 延迟指标 inference_latency Histogram( inference_latency_seconds, 端到端推理延迟, [model_name, request_type], # 设计原因使用分桶而非单一值 # 分桶可以计算任意分位数P50/P95/P99 # P95 通常比平均值更能反映用户体验 buckets[0.01, 0.05, 0.1, 0.25, 0.5, 1.0, 2.5, 5.0, 10.0], registryregistry, ) ttft_latency Histogram( ttft_latency_seconds, 首 Token 延迟, [model_name], # 设计原因TTFTTime to First Token影响用户感知 # 用户在等待第一个字的响应TTFT 2s 体验明显下降 buckets[0.1, 0.25, 0.5, 1.0, 2.0, 5.0], registryregistry, ) # 象限2: 吞吐指标 request_qps Counter( inference_requests_total, 推理请求总数, [model_name, status], registryregistry, ) token_throughput Counter( generated_tokens_total, 生成的 Token 总数, [model_name], registryregistry, ) concurrent_requests Gauge( concurrent_requests, 当前并发请求数, [model_name], registryregistry, ) # 象限3: 错误率指标 error_counter Counter( inference_errors_total, 推理错误总数, [model_name, error_type], registryregistry, ) oom_events Counter( oom_events_total, OOM 事件计数, [model_name, gpu_id], registryregistry, ) # 象限4: 显存指标 # 设计原因区分 allocated 和 reserved # allocated 实际在用的显存reserved PyTorch 缓存池占用 # reserved allocated 多出的部分是 PyTorch 的显存缓存可以被复用 vram_allocated Gauge( gpu_memory_allocated_bytes, GPU 已分配显存, [model_name, gpu_id], registryregistry, ) vram_reserved Gauge( gpu_memory_reserved_bytes, GPU 已保留显存, [model_name, gpu_id], registryregistry, ) # 设计原因KV Cache 是显存的最大消耗者 # 单独监控可以识别请求变长导致显存增长的模式 kv_cache_usage Gauge( kv_cache_usage_bytes, KV Cache 显存占用, [model_name], registryregistry, ) def monitor_inference(service_name: str): 推理服务监控装饰器 设计原因在推理函数上添加装饰器无侵入地采集指标 业务代码不需要修改装饰器负责全部指标采集 def decorator(func): wraps(func) def wrapper(*args, **kwargs): # 设计原因先递增并发计数推理结束后递减 # 这样在指标中可以看到实时并发数 concurrent_requests.labels(service_name).inc() start_time time.time() try: result func(*args, **kwargs) elapsed time.time() - start_time # 记录延迟端到端 inference_latency.labels( service_name, kwargs.get(request_type, unknown) ).observe(elapsed) # 记录成功的请求 request_qps.labels(service_name, success).inc() return result except Exception as e: # 设计原因按错误类型分类记录 # OOMTimeoutValidationUnknown 各有不同的处理策略 error_type type(e).__name__ error_counter.labels(service_name, error_type).inc() request_qps.labels(service_name, error).inc() raise finally: concurrent_requests.labels(service_name).dec() return wrapper return decorator def collect_gpu_metrics(model_name: str, gpu_id: int 0): 定时采集 GPU 指标 设计原因用独立的后台线程采集显存指标 不依赖请求触发确保显存数据在无请求时也能持续上报 if not torch.cuda.is_available(): return # 设计原因allocated 是真实使用判断是否即将 OOM # reserved 是 PyTorch 缓存判断内存碎片化程度 allocated torch.cuda.memory_allocated(gpu_id) reserved torch.cuda.memory_reserved(gpu_id) total torch.cuda.get_device_properties(gpu_id).total_memory vram_allocated.labels(model_name, str(gpu_id)).set(allocated) vram_reserved.labels(model_name, str(gpu_id)).set(reserved) # 设计原因计算碎片率用于告警 # (reserved - allocated) / total 0.3 表示大量显存被缓存占用但不能复用 # 常见于频繁分配和释放不同大小的 Tensor fragmentation (reserved - allocated) / total if fragmentation 0.3: print(f[WARNING] GPU{gpu_id} 显存碎片率过高: {fragmentation:.1%}) def start_monitoring_server(port: int 8001): 启动 Prometheus 指标暴露服务 start_http_server(port, registryregistry) print(f监控指标服务启动: http://localhost:{port}/metrics)Prometheus 对应的告警规则prometheus_rules.ymlgroups: - name: inference_alerts rules: # 延迟告警P95 2s 持续 5 分钟 - alert: HighLatency expr: histogram_quantile(0.95, rate(inference_latency_seconds_bucket[5m])) 2 for: 5m labels: severity: warning annotations: summary: 推理延迟过高 description: {{ $labels.model_name }} P95 延迟 {{ $value }}s # 错误率告警错误率 1% 持续 2 分钟 - alert: HighErrorRate expr: | rate(inference_errors_total[2m]) / rate(inference_requests_total[2m]) 0.01 for: 2m labels: severity: critical annotations: summary: 推理错误率超过 1% # 显存告警已分配 90% - alert: HighVRAM expr: | gpu_memory_allocated_bytes / (gpu_memory_allocated_bytes gpu_memory_reserved_bytes) 0.9 for: 1m labels: severity: critical annotations: summary: GPU 显存使用超过 90%四、监控的金丝雀原则不是越多越好增加监控指标会带来隐藏成本采集开销每个指标都需要 CPU 时间来更新高 QPS 下采集开销不可忽视存储成本Prometheus 时序数据库的存储成本随指标数线性增长查询复杂度指标太多时Grafana 面板加载变慢dashboard 的可读性下降认知负载面面俱到的监控往往意味着真正重要的信号被稀释。精简原则每个服务不超过 20 个核心指标新增指标前先确认这个指标会改变我的行动吗。如果不会就不需要指标带足够维度的 label 来支持 drill-down按模型、GPU、请求类型拆分但 label 基数不要太大高基数 label 会炸 Prometheus不要为以防万一而添加指标。等真正需要时再加。五、总结模型推理服务的核心监控指标应聚焦于四象限延迟、吞吐、错误率、显存。四者之间的关联关系是故障诊断的关键——延迟和吞吐反向变化表示推理饱和错误率独立变化表示输入或依赖问题显存独立增长表示内存泄漏。使用 Prometheus 的 Histogram 和 Gauge 指标类型配合合理的分桶和标签维度。监控指标的数量需要控制在 20 个以内避免认知过载和存储膨胀。每个指标在添加前需要回答它是否会改变行动——如果答案是否定的则不添加。
