vLLM Metrics 驱动的推理延迟监控基于 Prometheus 的 GPU 推理可观测体系构建一、推理延迟的盲区——当 GPU 利用率和 Token 延迟同时正常一组线上 A100 推理集群的 GPU 利用率稳定在 78%看起来一切正常。但用户反馈下午 3 点后的回复明显变慢。查 GrafanaGPU 利用率没有突变Memory 使用量正常节点 CPU 也稳定。问题在于平均指标掩盖了分布的变化。实际请求中的 P99 TTFT 已经从 320ms 攀升到了 820ms但 GP U 利用率因为同时有短请求加入而保持稳定。平均 GPU 利用率 (长请求 × 高利用率 短请求 × 低利用率) / 总数。短请求增多分母变大平均值看起来没变但长请求的体验已经崩了。推理可观测性的核心问题推理延迟的分布远比平均值复杂而 GPU 层面的利用率指标与用户感知延迟之间没有直接的映射关系。需要建立一套从请求粒度到模型粒度的分层监控体系。二、vLLM Metrics 体系与分层监控架构2.1 vLLM 暴露的核心 MetricsvLLM 从 0.4.0 版本开始原生支持 Prometheus 格式的 Metrics 导出通过--enable-metrics开启/metrics端点。关键指标分为四层flowchart TB subgraph L1[第一层: 请求级指标] A1[request_success_total] A2[request_duration_seconds] A3[request_prompt_tokens] A4[request_generation_tokens] end subgraph L2[第二层: 调度级指标] B1[request_waiting_seconds] B2[request_running_seconds] B3[num_requests_waiting] B4[num_requests_running] end subgraph L3[第三层: KV Cache 指标] C1[gpu_cache_usage_perc] C2[cpu_cache_usage_perc] C3[num_preemptions_total] end subgraph L4[第四层: GPU 硬件指标] D1[GPU 利用率] D2[GPU 显存使用量] D3[NVLink 带宽] end L1 -- L2 L2 -- L3 L3 -- L42.2 指标聚合策略Prometheus 的 Histogram 指标如request_duration_seconds包含_bucket、_sum、_count三种子指标。推理延迟监控的核心需求不是查均值而是查分位值# ❌ 错误取均值掩盖分布 rate(request_duration_seconds_sum[5m]) / rate(request_duration_seconds_count[5m]) # ✅ 正确P99 延迟使用 histogram_quantile histogram_quantile(0.99, rate(request_duration_seconds_bucket[5m]))2.3 自定义延迟分层默认的request_duration_seconds是端到端延迟无法区分排队时间和实际推理时间。vLLM 提供了更细粒度的分解指标含义告警阈值参考time_to_first_token_seconds首个 token 生成时间含排队 PrefillP99 500mstime_per_output_token_seconds每个输出 token 的平均生成时间P99 50msrequest_queue_time_seconds纯排队等待时间P99 200msrequest_inference_time_seconds纯推理计算时间P95 目标值三、Prometheus 采集与 Grafana 看板实现3.1 Prometheus 采集配置# prometheus.yml —— vLLM 推理指标采集配置 global: scrape_interval: 15s # 采集间隔15 秒 evaluation_interval: 15s # 规则评估间隔 scrape_configs: - job_name: vllm-inference # 静态配置 vLLM 实例 static_configs: - targets: - vllm-node-01:8000 # vLLM 服务端口 - vllm-node-02:8000 - vllm-node-03:8000 labels: cluster: production model: qwen2-72b # 采集超时推理服务可能瞬时负载高导致 /metrics 响应慢 scrape_timeout: 30s # 指标 Relabel过滤无关指标减小存储开销 metric_relabel_configs: # 只保留 vLLM 相关指标过滤 Python 运行时指标 - source_labels: [__name__] regex: vllm:.*|process_.*|python_.* action: drop3.2 核心告警规则# vllm_alerts.yml —— 推理服务告警规则 groups: - name: vllm_latency rules: # # 告警 1: P99 TTFT 过高 # - alert: VLLMHighTTFT expr: | histogram_quantile(0.99, rate(vllm:time_to_first_token_seconds_bucket[5m]) ) 0.5 for: 5m labels: severity: warning component: inference annotations: summary: vLLM P99 TTFT 超过 500ms description: 模型 {{ $labels.model_name }} 在 {{ $labels.instance }} 的 P99 TTFT 为 {{ $value | humanizeDuration }} 超过阈值 500ms持续 5 分钟。 # # 告警 2: KV Cache 使用率过高 # - alert: VLLMHighKVCacheUsage expr: | vllm:gpu_cache_usage_perc 0.95 for: 3m labels: severity: critical annotations: summary: GPU KV Cache 使用率超过 95% description: KV Cache 使用率 {{ $value | humanizePercentage }} 接近饱和新的长 prompt 请求可能触发 preemption。 # # 告警 3: 请求排队积压 # - alert: VLLMRequestQueueBacklog expr: | vllm:num_requests_waiting 50 for: 2m labels: severity: warning annotations: summary: 推理请求排队数超过 50 description: 当前排队请求数 {{ $value }}持续 2 分钟。 推测 GPU 负载过高或存在长尾请求积压。 # # 告警 4: Preemption 频繁触发 # - alert: VLLMHighPreemptionRate expr: | rate(vllm:num_preemptions_total[5m]) 0.1 for: 5m labels: severity: warning annotations: summary: KV Cache Preemption 频繁触发 description: Preemption 速率 {{ $value }}/s表示 KV Cache 频繁腾挪会导致请求延迟显著增加。 # # 告警 5: Token 生成速率骤降 # - alert: VLLMThroughputDrop expr: | ( rate(vllm:generation_tokens_total[10m]) / rate(vllm:generation_tokens_total[10m] offset 30m) ) 0.7 for: 5m labels: severity: critical annotations: summary: Token 生成速率较 30 分钟前下降超过 30% description: 当前生成速率与 30 分钟前的比值为 {{ $value | humanizePercentage }} 可能存在 GPU 故障或模型推理异常。3.3 Grafana Dashboard 布局推荐的 Dashboard 布局分为 4 行行面板指标第 1 行总览GPU 利用率、显存使用、请求 QPS、Token 吞吐整体健康状态第 2 行延迟分布P50/P95/P99 TTFT、P50/P95/P99 TPOT用户体验核心指标第 3 行调度健康排队请求数、Preemption 次数、KV Cache 使用率调度是否正常第 4 行错误与异常请求错误率、超时率、OOM 次数可用性监控四、监控成本与过度告警的治理4.1 存储成本Prometheus Histogram 指标的分桶越多存储开销越大。vLLM 默认的延迟 Histogram 有 20 个 bucket每个实例每天产生约 50MB 的延迟指标数据。优化策略调整 bucket 范围根据实际延迟分布裁减无关 bucket。例如 TTFT 不需要Inf以上的 bucket。降低采集频率延迟类指标 30 秒采集一次差异很小P99 的误差约 2%比 15 秒节省一半存储。Recording Rules对高频使用的聚合查询如 P95/P99预先计算 Recording Rule减少查询时的 PromQL 计算量。4.2 告警疲劳告警规则过于激进会导致运维疲劳。P99 TTFT 500ms这条规则在流量高峰期几乎每天触发逐步演变为噪音。治理策略按优先级分层P0 告警KV Cache 饱和、Preemption 爆发→ 电话通知P1 告警P99 延迟超标→ 仅企业微信P2 告警Token 吞吐下降 15%→ 仅记录不通知。基于基线的动态阈值用过去 7 天同时段的 P95 值作为基线当日 P95 超过基线 1.5 倍时才告警而非固定阈值。4.3 监控不全的代价Prometheus vLLM Metrics 覆盖了推理引擎层面的指标但以下链路仍然存在盲区推理前置的 Tokenizer 延迟不属于 vLLM Metrics。网络层的 RTT 和连接建立时间。业务网关层面的限流和鉴权开销。五、总结推理延迟监控的核心要求不是指标多而是能分解到根因分层指标请求级TTFT/TPOT、调度级队列/Premption、缓存级KV Cache 使用率、硬件级GPU 利用率四层指标联动才能从延迟变高了定位到KV Cache 饱和导致 Preemption 爆发。分位值而非均值推理延迟分布厚尾平均值掩盖 P99 恶化。Histogram histogram_quantile是唯一正确的分位值计算方式。告警降噪按影响程度分层P0/P1/P2、按历史基线动态阈值避免所有告警一拥而上导致运维疲劳。盲区补充vLLM Metrics 无法覆盖 Tokenizer 延迟、网关延迟和网络延迟需要应用层面的 Trace 来补齐。