FastDeploy2.0:Prometheus3.5.0通过直接采集，进行性能指标分析

Prometheus的安装部署详见《大模型性能指标的监控系统（prometheus3.5.0）和可视化工具(grafana12.1.0)基础篇》

一、概述

下图就是FastDeploy2.0的几个核心指标显示效果，后面详细介绍如何操作。

二、Prometheus的两种采集方式

直接采集和间接采集

直接采集就是埋点式的，比如你自己的应用程序用 Prometheus 客户端的代码自己去埋点。比如FastDeploy就是直接采集，它已经将埋点埋好了，把 metrics 断点暴露出来了。
间接采集:虽然TensorRT-LLM也把metrics 断点暴露出来了，但格式不满足要求，我们就需要利用第三方工具（json_exporter）转换成Prometheus识别的指标。

可以使用的第三方Exporter，详见《第三方的Exporter列表》。

三、修改prometheus.yml

2.1进入容器里面：

docker exec -it prometheus /bin/sh

2.2增加数据来源

#vi  /etc/prometheus/prometheus.yml

  - job_name: "llm_job"

    static_configs:

      - targets: ["192.168.1.154:9401"]

2.3手动启动

使用 promtool 工具

promtool check config /etc/prometheus/prometheus.yml

使用 Prometheus 的 Web 接口发送一个 HTTP POST 请求到 /targets/-/reload 来重新加载配置

curl -X POST http://172.26.142.154:9090/-/reload

2.4查看抓取状态

Endpoint：端点，可以抓取的指标来源。

Target：目标，包含了端点地址，端口的状态等信息。

四、Grafana添加数据源Prometheus

五、FastDeploy2.0性能指标说明

http://192.168.1.154:9401/metrics可以看到下面的具体指标。

5.1首次token时间（time_to_first_token_seconds）

fastdeploy:time_to_first_token_seconds_count 30.0

fastdeploy:time_to_first_token_seconds_sum 174.25801753997803

总请求数（count）：30 个

总首 token 延迟时间（sum）：约 174.26 秒

平均首 token 延迟（mean）：174.26/30≈5.81 秒

首 token 延迟主要由 Prefill 阶段耗时 决定，因为：

Prefill = 输入编码 + KV Cache 构建

• • 模型需要处理整个输入 prompt
  • 并为每个 token 计算并缓存 Key/Value 向量
  • 复杂度为 O(n²)，n 是输入长度

5.2生成每个输出 token 所需的时间（time_per_output_token_seconds）

fastdeploy:time_per_output_token_seconds_count 6925.0
fastdeploy:time_per_output_token_seconds_sum 828.3923425674438

用 sum / count 得到 平均每个 token 的生成时间：

衡量大语言模型（LLM）在流式输出（streaming）过程中，生成每一个输出 token 的延迟性能。它反映了模型的“首 token 延迟之后的流畅度”，也就是常说的“吐字速度”。

5.3模型“持续输出”阶段的耗时request_decode_time_seconds(from first token to last token)
 

fastdeploy:request_decode_time_seconds_count 1.0
fastdeploy:request_decode_time_seconds_sum 4.071532964706421

在大模型推理中，整个过程可以分为两个主要阶段：

阶段	说明
1. Prefill / Encoding	处理输入 prompt，计算 KV Cache，生成 第一个输出 token（首 token）
2. Decode / Generation	基于已生成的 token，逐个预测下一个 token，直到结束（EOS）

request_decode_time_seconds 就是 第 2 阶段的耗时。

5.4模型推理时间request_inference_time_seconds

fastdeploy:request_inference_time_seconds_count 30.0
fastdeploy:request_inference_time_seconds_sum 1002.6503601074219

fastdeploy:request_inference_time_seconds指从 “模型推理开始” 到 “生成最后一个 token”

5.5端到端完整延迟request_latency_seconds

fastdeploy:e2e_request_latency_seconds_count 1.0
fastdeploy:e2e_request_latency_seconds_sum 5.990736722946167

e2e_request_latency_seconds 指从请求到达系统到最终响应返回（端到端完整延迟）.

类比：

• request_inference_time ≈ 厨师炒菜的时间
• e2e_request_latency  ≈ 顾客从点餐到上菜的总时间（含等位、下单、传菜）

注：e2e_request_latency ≥ request_inference_time

5.6请求在系统中排队等待处理的时间request_queue_time_seconds

含义：请求在 预处理完成后，到 推理开始前 所等待的时间。
也就是 排队时间（Queue Time），反映了系统调度能力和当前负载情况。
这段时间内，请求已经准备好（prompt 已解析、tokenized），但因资源不足或调度策略未能立即执行。

这个指标直接体现了系统的 资源紧张程度 和 调度效率。

queue_time 值	可能原因
✅ 接近 0s	系统空闲，资源充足，请求立即处理
⚠️ 几秒 ~ 十几秒	系统负载较高，有少量排队
❌ 数十秒或更高	系统过载，资源不足，可能出现雪崩

可以理解为 “我在排队，等系统有资源来处理我”。

5.7 GPU 缓存使用率gpu_cache_usage_perc 

fastdeploy:gpu_cache_usage_perc 0.14959652389819988

当前 GPU 上用于存储 KV Cache（Key-Value Cache）的显存占用百分比。
（一）在大语言模型的 自回归生成（autoregressive decoding） 过程中：
1.每次生成一个 token，都需要依赖之前所有 token 的注意力（attention）计算。
2.为了避免重复计算历史 token 的 Key 和 Value 向量，系统会将它们缓存在 GPU 显存中，这就是 KV Cache。
（二）KV Cache 的作用：
避免重复计算，大幅提升生成速度（降低延迟）
支持流式输出（streaming）
是实现高效批处理（batching）和连续批处理（continuous batching）的基础

5.8生成的输出 token 数（request_generation_tokens）

fastdeploy:request_generation_tokens_count 1.0
fastdeploy:request_generation_tokens_sum 56.0

含义：每个请求实际生成的输出 token 数量（即 max_new_tokens 或 stream 结束前生成的 token 数）
这是衡量 响应长度 和 decode 负载 的关键指标。

作用：

用途	说明
🔢 吞吐量计算	结合时间指标可计算 tokens per second (TPS)
💰 成本计量	输出 token 是 LLM 计费的主要依据（如 OpenAI）
📊 性能归因	分析长输出是否导致延迟升高
🚫 防滥用	检测是否有异常长输出（如无限生成）

5.9用户在请求中设置的 max_tokens 参数值request_params_max_tokens

fastdeploy:request_params_max_tokens_count 1.0
fastdeploy:request_params_max_tokens_sum 110.0

作用：

用途	说明
📏 资源预估	系统可根据此值预分配 KV Cache 显存
⏱️ 延迟预测	可预估最大生成时间（结合 TPOT）
🔒 安全控制	防止用户请求过长输出导致服务过载
🆚 利用率分析	对比 generation_tokens 看实际使用率

5.10输入 prompt 的长度（token 数）request_prompt_tokens

fastdeploy:request_prompt_tokens_count 1.0
fastdeploy:request_prompt_tokens_sum 9.0

作用：

用途	说明
⏱️ 首 token 延迟分析	prompt 越长，time_to_first_token 通常越长
💾 显存占用评估	长 prompt 占用更多 KV Cache（prefill 阶段）
📈 上下文利用率	对比 max_model_len 看是否支持长文本
🤖 RAG/Agent 场景监控	检测是否传入了过长的知识库内容

5.11request_prefill_time

指标全是0，不知道为什么，有清楚的朋友，麻烦告知我。