【免费下载链接】time-to-first-tokenA 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 设计文档中定义的核心指标指标含义为什么重要TTFTTime To First Token请求发出到收到第一个 token 的耗时主要由 prefill 阶段决定用户等回复的体感延迟ITLInter-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 JSONvLLM 官方提供了配套的仪表盘模板向服务灌一点涓流负载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用低负载确认面板实时变化周四阅读把性能工程的每个指标映射到面板删掉无定义的面板周五阅读理解为什么扫请求速率而不是只测一个点、为什么饱和点的数据要丢弃完成每节课后可以在 progress.md 的 Week 3 清单里勾选打卡完整路线说明见 README.md。总结第3周产出的不是一个玩具仪表盘而是整个路线的验证基础设施✅ 一块显示TTFT、ITL、吞吐量、队列深度的实时 Grafana 面板✅ 一份每个面板都有明确定义的监控配置✅ 一套能预警抢占、支撑第5周压测和第6-7周调参的基线记住这条路线的排序哲学先装仪表盘再谈优化——没有透镜的优化只是碰运气。赞分享【免费下载链接】time-to-first-tokenA 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点击查看免费下载相关推荐CogVLM2推理服务监控Prometheus指标与Grafana仪表盘配置CogVLM2推理服务监控Prometheus指标与Grafana仪表盘配置 CogVLM2作为基于Llama3 8B的多模态模型在生产环境部署时需要实时监Pixelle-Video一个主题 5 分钟出片 AI 短视频Pixelle Video一个主题 5 分钟出片 AI 短视频 一条 30 秒的讲解视频自己写文案、找配图、剪节奏至少耗掉 2 小时。Pixelle Vi猫抓插件完整指南三步把网页视频下载到本地猫抓插件完整指南三步把网页视频下载到本地 想保存网页上的视频右键却只有灰掉的菜单强行存下来的文件只有几 KB双击打不开。用猫抓cat catch这款上一篇Zeek NTP 协议分析器全解析从 main.zeek 脚本到 binpac 底层解析与日志输出下一篇SourceGit完全指南10个理由为什么这个开源Git GUI客户端值得尝试创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考