如何给LLM推理服务装上仪表盘：TTFT、ITL、吞吐量与队列深度实时监控，Prometheus+Grafana搭建教程（time-to-first-token 第3周）-开发者社区

【免费下载链接】time-to-first-token

A 10-week, 30-minutes-a-day roadmap for LLM inference serving and optimization. vLLM, SGLang, quantization, speculative decoding, benchmarking.

项目地址：https://gitcode.com/gh_mirrors/ti/time-to-first-token

点击查看免费下载

本教程来自 time-to-first-token 学习路线的第3周（Measurement infrastructure），教你用 Prometheus + Grafana 为 LLM 推理服务搭建实时监控仪表盘，覆盖 TTFT、ITL、吞吐量与队列深度四大核心指标。先搭好"测量透镜"，后面的量化、投机解码等所有优化才能被验证。

为什么第3周就要搭监控？

大多数人的错误是：先跑通服务，再优化，最后才想起来看指标——结果调参全靠猜。

time-to-first-token 路线刻意把测量基础设施放在优化之前（第6周才讲量化、第7周才讲投机解码），原因很直接：

没有监控，后面所有优化都不可验证；一份可信的公开 benchmark，本质上就是一个可靠的测量工具加上一个模型。

路线原文的表述是："Everything after this week is only legible because of this week."（这一周之后的所有内容，都因为这一周才变得可读。）

核心指标速查表：TTFT、ITL、吞吐量、队列深度

在动手之前，先搞清楚仪表盘上的每个面板到底在量什么。这是第3周周一的功课，对应 vLLM 的 metrics 设计文档中定义的核心指标：

指标	含义	为什么重要
TTFT（Time To First Token）	请求发出到收到第一个 token 的耗时	主要由 prefill 阶段决定，用户"等回复"的体感延迟
ITL（Inter-Token Latency）	两个 token 之间的间隔	决定流式输出的流畅度，属于 decode 阶段
吞吐量	tokens/s 或 requests/s	服务能力的上限，受 KV cache 大小约束
队列深度	`num_requests_waiting`等待中的请求数	持续上升 = 服务正在抢占（preempt），性能开始崩塌的前兆
`num_requests_running`	正在运行批处理中的请求数	与队列深度配合判断负载水位

⚠️一个关键纪律：TTFT 和 ITL 必须分开记录。把 prefill 和 decode 合并成一个数字，会直接毁掉你的发现——路线在发布前的检查清单中明确要求这一点（见 README.md 的 "Before you publish a benchmark" 一节）。

一键安装步骤：Docker 拉起 Prometheus 和 Grafana

第3周周二的目标是让监控栈跑起来。整个技术栈只需两个容器：

Prometheus：负责定时抓取（scrape）你的推理服务暴露的/metrics端点
Grafana：负责把抓到的时序数据画成面板（panel）

按官方 Prometheus/Grafana 示例文档操作，用 Docker 部署，把 Prometheus 的抓取目标指向你的 vLLM 服务地址（第2周你已经跑好了一个 OpenAI 兼容的推理端点）。

这里有一个容易踩的坑，路线特别点名提醒：

现在就修 scrape 配置，而不是等到第5周顶着 1000 并发请求时再修。

抓不到指标时，最常见的三个原因：目标地址写错、端口没暴露、服务没开/metrics端点。花 5 分钟在低负载下确认每个面板有数据流，比高负载时排障省事得多。

导入 Grafana 仪表盘：确认面板动起来

周三的动手环节：

导入现成的 dashboard JSON（vLLM 官方提供了配套的仪表盘模板）
向服务灌一点"涓流负载"（trickle of load），比如几个并发请求
肉眼确认每个面板的曲线随负载实时变化——静态数字不算通过

通过标准很简单：加载请求时num_requests_waiting上升、TTFT 曲线波动，松开请求后面板回落。

最快配置方法：把每个指标都映射到面板

周四的功课是把外部权威文档中定义的每一个性能指标，都映射到仪表盘上的一个具体面板。路线给的规则很狠：

没有定义的面板，直接删掉。

也就是说，面板不是越多越好，而是每个面板都要能回答"这个数字的定义是什么、超出多少说明出问题"。这样到第8周讲 Kubernetes 自动扩缩时，你才能用num_requests_waiting（队列深度）而不是 CPU 作为扩缩信号——CPU 驱动的 GPU 服务自动扩缩是这个阶段要避免的经典错误。

仪表盘怎么用：抢占预警与决策点

搭好后，仪表盘立刻有两个实用场景：

1. 抢占预警。路线的"决策点"里写明：如果第5周压测时TTFT 飙升且num_requests_waiting持续攀升，说明服务正在抢占请求——先停下来调--max-num-seqs、--gpu-memory-utilization和 chunked prefill，而不是继续测。在抢占点测出的数据不可发布（见 README.md 的 Decision points）。

2. 为后续优化提供基线。第6周量化（FP8/INT4）、第7周投机解码的每一次改动，都要回看同一组面板：TTFT 变了多少？ITL 变了多少？队列深度在哪个 QPS 开始堆积？

本周学习路径

星期	类型	任务
周一	阅读	理解`num_requests_running`、`num_requests_waiting`与延迟直方图的定义
周二	动手	用 Docker 拉起 Prometheus + Grafana，对接你的服务
周三	动手	导入仪表盘 JSON，用低负载确认面板实时变化
周四	阅读	把性能工程的每个指标映射到面板，删掉无定义的面板
周五	阅读	理解"为什么扫请求速率而不是只测一个点"、为什么饱和点的数据要丢弃