vLLM与prometheus指标监控在并发压测中的关键指标解读

文章导读
压测 vLLM 时,Prometheus 里能拿到的指标很杂,先分两组看:一组是 vLLM 暴露的调度状态和延迟指标(通常以 vllm: 或 vllm_ 开头),另一组是容器/进程级别的 CPU、内存、GPU 利用率。瓶颈往往先反映在等待队列和 KV cache 占用上,然后才扩散到首 token 延迟和吞吐。只盯平均生成速率,容易漏掉 preemption 造成的隐性浪费。
📋 目录
  1. 一 关键指标与瓶颈假设
  2. 二 一次只改变一个变量的调整顺序
  3. 三 可执行的观测方式
A A

压测 vLLM 时,Prometheus 里能拿到的指标很杂,先分两组看:一组是 vLLM 暴露的调度状态和延迟指标(通常以 vllm: 或 vllm_ 开头),另一组是容器/进程级别的 CPU、内存、GPU 利用率。瓶颈往往先反映在等待队列和 KV cache 占用上,然后才扩散到首 token 延迟和吞吐。只盯平均生成速率,容易漏掉 preemption 造成的隐性浪费。

关键指标与瓶颈假设

先确认 vLLM 的 metrics 接口能正常暴露。启动 vLLM 后,访问 http://<vllm-host>:8000/metrics 应能看到一系列指标;不同版本指标名有差异,先用 curl 抓一遍再写 PromQL。下面几个指标通常对应明确的瓶颈假设:

  • vllm:num_requests_running:正在生成 token 的请求数。压测时如果该值长期远低于配置的并发上限,说明调度层或计算层有阻塞。
  • vllm:num_requests_waiting:排队请求数。持续非零且增长,说明服务端处理能力不足,或 `--max-num-seqs` 设置得小于实际并发。
  • vllm:gpu_cache_usage_perc:KV cache 使用率。接近 100% 时 preemption 会频繁发生,此时继续增加并发通常不会提升吞吐,只会增加等待。
  • vllm:time_to_first_token_seconds:首 token 延迟的 histogram。p99 和均值反映调度 + prefill 整体效率。
  • vllm:num_preemptions_total:preemption 累计计数。压测期间持续增长,说明 KV cache 不足或长序列请求挤占了短序列。

这些指标要与进程级指标交叉看。例如 GPU 利用率低但 num_requests_waiting 高,可能是调度器在等 batch 聚合;KV cache 未满但 GPU 利用率低,则要检查 `--max-num-seqs` 是否限制了批次规模。

一次只改变一个变量的调整顺序

压测前先建立基线:固定模型、输入输出长度、并发策略和随机种子,记录单个请求的端到端耗时和 TTFT。之后每次只改一个配置项,压测相同负载,观察上述指标的变化趋势。

  1. 先调整 `--max-num-seqs`。如果 gpu_cache_usage_perc 打满而 num_requests_running 仍低于设定值,说明并发加得过大,需要降低 `--max-num-seqs`。
  2. 再调整 `--max-model-len`。如果 preemption 计数持续增长且 cache 打满,考虑缩短最大序列长度,或降低 `--gpu-memory-utilization` 给临时 batch 留出缓冲。
  3. 然后才考虑调度或批次相关参数。cache 没有打满但 num_requests_waiting 很高,通常是 continuous batching 在特定输入长度下效率不足,需要结合版本和参数再判断。
  4. 最后才调整请求侧的超时和重试。服务端容量未确认前,客户端重试只会放大压力。

每次调整后,建议跑两个完整的 10 分钟窗口:一个窗口覆盖启动和预热,另一个窗口取稳定值。记录改动前、改动后、是否回滚三个状态,再进下一步。

可执行的观测方式

先用 curl 确认指标名和前缀是否和预期一致:

vLLM与prometheus指标监控在并发压测中的关键指标解读
curl -s http://<vllm-host>:8000/metrics | grep -E '^(vllm:|vllm_)' | head -50

如果只需要看关键指标,可以过滤:

curl -s http://localhost:8000/metrics | grep -E 'num_requests_(running|waiting)|gpu_cache_usage_perc|num_preemptions_total|time_to_first_token_seconds_count'

PromQL 判断等待队列是否持续增长:

rate(vllm:num_requests_waiting[5m]) > 0

计算最近 5 分钟的平均 TTFT:

rate(vllm:time_to_first_token_seconds_sum[5m]) / rate(vllm:time_to_first_token_seconds_count[5m])

如果实际指标名与上述不同,以第一步 curl 返回为准,把前缀和名称替换进 PromQL。Prometheus 抓取间隔通常为 10-15 秒,短时尖峰可能被平滑,需要结合 vLLM 日志直接看 preemption 事件。

风险边界要记住:这些指标只反映配置和负载之间的相对关系,不能跨环境比较。不同模型、不同输入长度、不同 GPU 显存布局下,同一指标的最优区间差异很大。没有明确的硬件和模型参数时,不要用某个固定阈值作为压测通过标准。