vllm prometheus observability llmops gpu ttft

vLLM推理指标：从TTFT和TPOT到KV缓存与有效吞吐量。

vLLM Prometheus指标使用指南——成功率、延迟百分位数、令牌I/O比率、抢占机制、分块预填充、DPD以及推测性解码接受率。

发布者：REACTAPP.TOP加入本站 2026年9月26日阅读约 13 分钟2973 词

来源: A Deep Dive into vLLM Inference Metrics

为大型语言模型提供服务所面临的可观测性问题与为无状态微服务提供服务不同。当注意力机制、连续批处理以及高带宽内存容量主导系统行为时，CPU使用率与平均请求延迟已不足以作为有效的衡量指标。目前的关注点已从单纯的令牌处理量转向有效吞吐量——即在严格的性能指标范围内成功完成任务的能力。

本指南将详细介绍应展示在 Grafana 面板上的 vLLM 引擎核心指标：可靠性计数器、延迟直方图、令牌经济模型、KV缓存动态变化、调度器压力，以及只有在正确读取遥测数据时才会显示的拓扑结构相关选项。

汇总统计与系统健康状况

LLM引擎的故障往往表现为隐蔽的问题——生成内容质量下降或意外中断——而非明显的HTTP错误。因此，要全面了解系统健康状况，需要语义层面的结束原因，而不仅仅是状态码。

成功率与结束原因分布

成功率是指在特定时间窗口内所有已处理请求中的成功次数。在vLLM中，这意味着要分析生成循环的结束方式，而不仅仅是统计200 OK的状态。状态良好的系统通常能保持99.5%以上的成功率；若持续低于98%，则属于紧急状况。

相关计数器为vllm:request_success_total，并通过finished_reason字段标识具体原因：

Stop — 自然结束或达到预设的停止条件。视为真正成功。
Length — 因上下文长度限制或生成次数上限而被截断。
Abort — 客户端断开连接或系统内部强制终止。

长期出现length超限的情况通常意味着模型在处理任务时过度冗长，或者max_model_len/生成长度限制对于该类型的提示语来说过于严格。典型的PromQL统计方式是计算五分钟窗口内因超长而终止的请求比例与所有请求终止比例之比。

吞吐量与成功率的收敛性

将总请求吞吐量与成功完成的请求数并列绘制。在正常负载下，两条曲线应保持同步变化；若两者差距逐渐扩大，则说明GPU的算力被用于处理那些最终无法成功完成的任务——比如超时（中断）或因长度限制导致的上下文溢出。在负载测试中，较大的差距往往表明模型的注意力机制性能下降，或是生成过程不断逼近长度限制而无法终止。

Python垃圾回收与进程内存

大部分核心计算都在CUDA/C++中完成，但整体调度仍由Python负责。需结合进程的RSS值来监控垃圾回收次数。

频繁的垃圾回收会引入令 token 间时序出现波动。不断上升的 RSS 值表明绑定存在泄漏，最终会触发内存溢出杀手机制。无论处于空闲还是繁忙状态，Pod 在 CPU 使用率方面可能看起来“正常”；而无声的灾难往往发生在未被妥善管理的内存池中。

延迟与用户体验的量化

生成型任务的延迟呈长尾分布。平均值会掩盖问题；必须使用 P50/P90/P99 等指标来准确反映情况。

端到端请求延迟

端到端延迟指的是从请求到达开始到最终 token 生成并处理完成的时间。vLLM 通过直方图形式展示 vllm:e2e_request_latency_seconds 这一指标。分位数计算则采用 histogram_quantile() 方法，并在各个区间内进行线性插值。异常高的 P99 值通常意味着连续批处理机制无法有效交错处理多个请求——是时候检查调度器与缓存压力了。

首个 token 生成时间（TTFT）的 P99 值

TTFT是衡量交互性的指标。HCI指南建议将该时间控制在1秒以内，以避免用户产生挫败感。

TTFT的主要开销来自预填充阶段：需要读取提示语、集中注意力并构建初始的KV缓存。其计算成本大致与序列长度的平方乘以宽度成正比，属于依赖计算的TFLOPS级工作量。举例来说，在约70B参数的模型上对512个标记进行预填充，其计算量大约在数十TFLOPs左右。

用于计算TTFT P99的PromQL公式：

histogram_quantile(0.99, sum(rate(vllm:time_to_first_token_seconds_bucket[5m])) by (le))

对于聊天界面而言，TTFT P99往往是决定性的限制因素。中端GPU（如L40S系列）巨大的显存容量可能导致无论采用何种批处理方式，TTFT值都会高到不可接受的程度，这迫使团队选择参数更小的模型或TFLOPS性能更高的芯片（如H100系列）。

每个输出标记的时间（TPOT）及推理阶段拆解

生成第一个标记之后，便进入解码阶段。TPOT（标记间延迟）用于衡量后续标记的生成速度。

解码过程通常受内存带宽限制：每一步都需要将权重和KV历史数据从HBM加载到计算单元，且算术运算强度较低（密集型非MoE路径的运算强度约为1 FLOP/字节）。

一个有用的分解方式如下：

E2E ≈ TTFT + (N_output − 1) × TPOT

各阶段占比图表展示了预填充时间与解码时间的分配情况：

预填充时间过长 → 提示词过长或TFLOPS性能较弱。
解码时间过长 → 输出内容过长或HBM带宽已饱和。

在负载逐渐增加的情况下比较TTFT与TPOT的值，是快速确定瓶颈所在的最快方法。

令牌吞吐量与工作负载特征

仅考虑延迟而忽略处理量无法准确评估硬件性能。

令牌吞吐量与IO比率

将吞吐量分为提示词处理速率（tokens/sec）和生成内容处理速率（tokens/sec）。更高的持续处理总量能更有效地分摊GPU使用成本。

令牌输入输出比（提示词令牌数与生成令牌数之比）可用于描述任务特性：

较高（约20:1）——输入较长，输出较短：适用于RAG、摘要生成、分类任务。这类任务依赖大量预填充数据。
较低——提示词较短，生成内容较长：适用于开放式对话、代码生成任务。这类任务依赖解码功能或高带宽内存。

若拓扑结构与该比例不匹配，将会造成资源浪费：例如在为解码功能优化的硬件上使用RAG技术，或在预填充数据不足的硬件上进行长文本对话。

请求长度热图（提示词）

提示词长度热图可以显示流量是呈单一分布状态，还是由长短不一的提示词混合构成。即使每秒查询次数看似不高，但若提示词长度存在长尾现象，仍可能导致突发性高负载。

引擎内部机制与缓存动态

外部延迟受KV缓存及调度器状态的影响。

GPU KV缓存使用情况

监控 KV 池的占用程度。随着占用率上升，连续批处理处理的序列数量会减少；超过特定阈值后，系统会强制中断处理。

前缀缓存命中率与节省量

前缀缓存可重复使用 KV 数据来处理共享的提示语前缀（系统提示、RAG 标头）。命中率及节省的前置数据能够量化提示语设计与路由机制是否真的存在前缀共享——还是意外地导致每个请求都使用唯一内容。

调度器状态与系统效率

观察正在处理的任务数与等待中的任务数。如果正在处理的任务数保持不变而等待任务数不断增加，通常意味着 KV 存储或 max_num_seqs 上限的问题，而非“CPU 过载”。

调度器状态与抢占率

当 KV 存储空间无法容纳下一个标记的向量时，vLLM 会提前中断处理。参数 vllm:num_preemptions_total 是一个警戒计数器：若该值非零且持续处于高位，则意味着需要更多的显存、更多的副本，或是降低 max_num_seqs 的上限。

系统效率与请求队列时间

系统效率是指处理速度与请求到达速度的比值。接近 1.0 表示请求能够得到及时处理；而数值低于约 0.7 则说明等待队列的增长速度超过了 GPU 处理请求的速度。

这一问题会体现为 vllm:request_queue_time_seconds——即在开始实际计算之前所花费的等待时间。队列时间的增加会导致即使没有生成任何标记，整体处理时间也会随之上升。

传统的基于 CPU 的动态资源调度机制在此处无法发挥作用。应通过 Prometheus 适配器将 vllm:num_requests_waiting 及队列时间相关指标接入系统，从而使 HPA 根据队列深度（例如等待中的请求数量）来调整资源分配，而非仅依据 CPU 使用率。

基础设施、负载均衡与高级拓扑结构

软件信号必须符合硬件的实际运行情况。

负载均衡与硬件利用率

大语言模型处理请求的时间差异极大——长文本生成可能需要数分钟，而简单回复则瞬间完成。因此轮询式负载均衡会导致资源分配不均。应选择能够感知当前处理深度的负载均衡器。

可通过DCGM进行交叉验证：

GPU利用率——理想的状况是利用率高且队列长度短；若利用率高但队列很长，则说明系统已达到饱和状态。
已使用的VRAM——可确认vLLM在启动时是否已分配了预定比例的内存。

解决预填充与解码之间的冲突

在混合批次中，如果存在耗时较长的预填充操作，它可能会占用所有张量核心，导致正在进行的解码任务全部停滞——这会造成处理时间波动剧烈以及数据流传输不流畅的问题。

主要有两种缓解措施：分块预填充与分离式预填充/解码。

分块预填充

将庞大的提示词分割成固定大小的块（例如512个标记），并将这些块与其他请求的解码步骤交错进行。新用户的TTFT值略有上升，而其他用户的TPOT值则保持平稳。其指标表现为：ITL直方图更加平滑，P50阶段的TTFT成本较低，且P99阶段的流处理稳定性有显著提升。

分离式预填充与解码（DPD）

在更大规模的应用中，可将不同阶段部署在不同的计算资源上：在算力强大的GPU上进行预填充，在内存容量大的GPU上进行解码，预填充完成后再通过网络传输KV数据。需关注NIXL（或类似机制）的传输时间与数据量，例如vllm:nixl_xfer_time_seconds_sum和vllm:nixl_bytes_transferred_sum这些指标。只有当传输时间小于其消除的干扰时间时，DPD方案才能发挥优势；而RDMA/NCCL的技术质量决定了这一条件是否成立。

推测性解码数学

推测性解码通过一个小型草稿模型提出令牌，再由目标模型一次性验证多个令牌，从而加快受内存限制的解码速度。验证多个令牌大约需要一次生成步骤的计算量，当草稿质量良好时，其效率可超越HBM的性能限制。

关键指标为：草稿接受率（vllm:spec_decode_draft_acceptance_rate）。在接受概率α为定值的情况下，每步预期被接受的令牌数呈几何级数增长。若α低于0.5，草稿带来的开销可能超过节省的成本，反而拖慢系统速度。

应在生产环境温度下评估草稿效果。在贪婪模式（T=0）下，α值可能约为0.8；而在创意模式（T=1.0）下，同一参数组合的α值会降至约0.4——这会使优化措施反而导致性能下降。

Prometheus多进程遥测架构

vLLM兼容OpenAI的服务器采用多进程架构。普通的Prometheus客户端无法在多个工作进程间正常工作（受GIL限制且内存被分割）。

解决方案是使用prometheus_client.multiprocess并设置PROMETHEUS_MULTIPROC_DIR：每个工作进程将增量数据追加到内存映射文件中；数据采集器会调用MultiProcessCollector来合并OpenMetrics输出。复杂的PromQL查询（如histogram_quantile、rate）仍在Prometheus上处理，而不占用推理流程的带宽——这样测量延迟就不会本身成为延迟。

综合这些指标——成功与失败原因、TTFT/TPOT/E2E分位数、令牌I/O模式、KV存储占用率、任务抢占情况、队列等待时间，以及针对特定拓扑结构的传输数据和预测性统计信息——便形成了从用户服务等级目标到GPU实际运行状况的闭环。正是这个闭环让vLLM从演示服务器转变为可实际使用的推理平台。

制定一份书面操作手册，将每个关键指标对应到首要措施：预取次数增加 → 减少max_num_seqs值或增加VRAM；仅TTFT P99指标偏高 → 缩短提示词长度、提升TFLOPS性能或启用前缀缓存；当KV内存占用满时TPOT指标上升 → 降低解码压力或减少预填充干扰；推测性α值崩溃 → 调整草稿参数/温度设置。每次调整硬件配置后，都应在同一图表上绘制相应的吞吐量前后对比图，这样硬件投入就能与SLO指标的改善挂钩，而非仅仅体现为每秒处理的请求数。每当产品组合发生变化时，都需重新审视IO比率监控面板——RAG功能的推出以及长文本功能的上线会瞬间改变预填充与解码之间的瓶颈，昨天的自动扩缩容阈值今天可能就会变成导致排队现象的根源。最后，应将多进程指标目录视为容器生命周期的一部分：如果PROMETHEUS_MULTIPROC_DIR路径为空或权限出错，虽然数据看起来仍是零值，看似“正常”，但用户早已能感受到问题存在。

服务中断。

在引入新的模型检查点时，需固定负载参数（提示词长度组合、输出长度组合、并发数），并在放行流量前对比相同的 PromQL 指标。那些在平均每秒处理符号数方面表现优异，但在 TTFT P99 值或抢占率上表现不佳的模型检查点，不适合用于交互式 API。

在引入新的模型检查点时，应固定负载参数（提示词长度组合、输出长度组合、并发数），并在开始分配流量前对比相同的 PromQL 指标。那些在平均每秒处理token数方面表现优异，但在 TTFT P99 值或抢占率上表现不佳的模型检查点，不适合用于交互式 API。

在引入新的模型检查点时，应固定负载参数（提示词长度组合、输出长度组合、并发数），并在开始分配流量前对比相同的 PromQL 指标。那些在平均每秒处理符号数方面表现优异，但在 TTFT P99 值或抢占率上表现不佳的模型检查点，不适合用于交互式 API。

在引入新的模型检查点时，应固定负载参数（提示词长度分布、输出长度分布、并发数），并在开始分配流量前对比相同的 PromQL 指标。如果某个检查点在平均每秒处理令牌数方面表现优异，但在 TTFT P99 值或抢占率上表现不佳，则不适合用于交互式 API。

← 全部文章发送简报