如何把LLM推理服务压到1000并发：GuideLLM与genai-perf压测实战，找到吞吐饱和拐点（time-to-first-token 第5周完整指南）

本文基于 time-to-first-token 这个 LLM 推理服务 10 周学习路线图的第 5 周内容，手把手教你用 GuideLLM 和 genai-perf 两款压测工具，把 vLLM 推理服务压到 1000 并发，并找到吞吐饱和拐点。

为什么第5周要专门做压测？

路线图的顺序是刻意的：度量先于优化（measurement before optimization）。第 3 周搭好 Prometheus + Grafana 监控之后，第 5 周就要把压力打满，因为后面量化、投机解码等所有优化手段，都只有在这个压力测试基线之上才可验证、可对比。

这一周的交付物很具体：

• 一个可复现的并发扫描脚本，能把服务压过 1000 并发请求
• 每个并发级别的 p50 / p95 / p99 延迟数据
• 用两个独立工具交叉验证的结果（单一工具的数字没有说服力）

第5周每天学什么：一张表看懂

💡 关键认知：固定输入/输出 token 长度不是随便选的——它直接决定 KV cache 大小，进而决定整个压测结果。这也是为什么发布基准测试时必须写明精确 token 长度。

三步实操：从基线扫到饱和拐点

第一步：安装压测工具链

按路线图 README.md 中的 Setup 章节，除了 vLLM 之外，压测相关只需再装两样：

• pip install guidellm：SLO 感知的速率扫描工具，vLLM 官方团队出品
• genai-perf：来自 Triton 生态的性能分析器，擅长单独测量 TTFT 和 inter-token latency（ITL）

监控侧请确保第 3 周搭好的 Grafana 面板还在正常刷新——第 5 周 1000 并发下才暴露的抓取配置问题，现在就要修。

第二步：用 GuideLLM 做速率扫描

GuideLLM 的核心思路是从同步基线开始逐级加压，直到系统饱和。相比"拍脑袋挑一个负载测一下"，扫描整条曲线才能看到：

• 低并发下 GPU 利用率爬升的斜率
• 吞吐何时不再随并发数增长
• 延迟何时开始非线性恶化

周二建议先跑最简版本：固定输入长度 + 固定输出长度，得到一个干净的可复现基线。

第三步：genai-perf 并发扫描，锁定那个"拐点"

周四用 genai-perf 从 1、2、4 开始倍增并发，一路扫到 128。你要找的是：吞吐还在增长、但延迟已经开始明显劣化的那个位置——业界俗称 knee（拐点），它是整条曲线上唯一真正有趣的点。

这里有个反直觉的点：两个工具给出不同数字，本身就是信息而不是故障。token 计数器实现、请求排队方式、token 化口径的差异都会影响读数，交叉验证正是为了暴露这些差异。

周五大考：把服务压过1000并发

这是整个 10 周里唯一需要 H100 的两个 session 之一（另一个在第 8 周），路线图建议只在这一节租卡，按半小时计费，用完即关。

压过 1000 并发时，眼睛要盯住两个信号：

1. KV cache 利用率：接近打满意味着请求开始排队
2. num_requests_waiting持续上涨：说明服务器正在发生抢占（preemption）

⚠️ 重要判断点：如果 TTFT 在达到目标并发之前就突然尖刺、num_requests_waiting开始爬坡——说明服务已经在抢占，这次测量不可发布。先停下来调--max-num-seqs、--gpu-memory-utilization和 chunked prefill 参数，再重新压。

发布基准测试前的自查清单

路线图 README.md 中列了一份"会被同行评审撕碎"的常见错误清单，第 5 周读完、第 10 周发布时执行：

完成度可以在 progress.md 中勾选跟踪，也可以打开 index.html 的网页版进度页，进度保存在浏览器本地，关标签页也不会丢。

本周小结

• 压测不是"跑一个数字"，而是扫出一条并发 → 吞吐/延迟的曲线
• 拐点（knee）才是可发布、可指导扩容决策的位置
• 双工具交叉验证 + 监控面板信号（KV 利用率、排队数）共同构成可信度
• 抢占发生时的测量结果不可发布，先调参再重测

第 5 周结束时，你就有了一份"可辩护的"基线。第 6 周的量化（FP8 / INT4）和第 7 周的投机解码，都将直接在这套压测框架下与基线对比——这就是路线图"先造好度量尺，再优化"设计的回报所在。🚀