第1章：压测指标详解

做vLLM性能压测，说白了就是搞清楚你的模型服务到底能扛多大压力。我刚开始接触这玩意儿时，也踩过不少坑——比如盯着一个指标猛调，结果上线后用户骂声一片。后来才明白，压测指标不是孤立的数字，它们是一张网。

今天我就把这六个核心指标掰开揉碎了讲。每个指标我都会结合自己的实战经验，告诉你它到底在说什么、怎么测、以及避坑指南。

1.1 吞吐量（Tokens/s）

吞吐量，就是模型每秒能吐出多少个token。这是最直观的性能指标，也是老板最爱看的数字。

计算公式很简单：

吞吐量 = 总生成token数 / 总耗时（秒）

举个例子：你压测了100个请求，每个请求平均生成200个token，总共花了50秒。那吞吐量就是：

(100 × 200) / 50 = 400 tokens/s

我个人习惯把吞吐量分成两种场景来看：

• 单请求吞吐：一个请求独占GPU时的速度。这能反映模型本身的推理能力。
• 并发吞吐：多个请求同时跑时的总速度。这才是生产环境关心的。

1.2 首Token延迟（TTFT）

TTFT（Time to First Token），从用户发出请求到收到第一个token的时间。这决定了用户的第一印象。

你想想看，用户点了个按钮，等了两秒才看到第一个字，他大概率会关掉页面。我做过一个线上分析，TTFT超过1.5秒，用户流失率直接翻倍。

TTFT主要受这几个因素影响：

• 预填充阶段耗时：模型处理输入prompt的时间
• 调度延迟：请求在队列里排队的时间
• 网络传输：数据在客户端和服务端之间来回的时间

1.3 Token间延迟（ITL）

ITL（Inter-Token Latency），也就是生成每个token的平均时间。它反映了模型生成阶段的流畅度。

计算公式：

ITL = (总生成时间 - TTFT) / (总token数 - 1)

为什么减1？因为第一个token已经算在TTFT里了。

ITL这个指标，说白了就是看模型生成文本时卡不卡。我见过一个项目，TTFT只有200ms，但ITL高达100ms，用户反馈说「打字像在挤牙膏」。后来发现是KV Cache的显存分配策略有问题。

ITL范围	用户体验	建议
< 20ms	流畅，像真人对话	优秀，无需优化
20-50ms	轻微延迟，可接受	可以关注，但非必须
50-100ms	明显卡顿，用户会抱怨	需要优化
> 100ms	无法忍受	必须立即处理

1.4 端到端延迟

端到端延迟，从用户发出请求到收到完整回复的总时间。这是用户真正感知到的延迟。

它等于：

端到端延迟 = TTFT + (总token数 - 1) × ITL + 网络延迟

嗯，这里要注意：端到端延迟和吞吐量往往是跷跷板关系。你追求高吞吐，就得让GPU同时处理更多请求，但每个请求的等待时间就会变长。

1.5 并发数

并发数，就是系统同时处理的请求数量。它决定了你的服务能撑住多少用户。

并发数不是越高越好。每个并发请求都会占用显存和计算资源。vLLM的调度器会把这些请求打包成batch一起处理。

我一般这样评估并发能力：

• 理论上限：显存大小 / 每个请求的显存占用
• 实际上限：在保证SLA（比如TTFT < 1s）的前提下，能支持的最大并发

举个例子，一张A100 80G显卡，如果每个请求占2G显存，理论并发是40。但实际跑起来，可能并发到20时TTFT就已经超标了。

1.6 QPS（每秒查询数）

QPS（Queries Per Second），每秒能处理多少个完整的请求。这是业务视角最关心的指标。

QPS和吞吐量的关系：

QPS = 吞吐量 / 每个请求的平均token数

比如你的吞吐量是400 tokens/s，每个请求平均生成200个token，那QPS就是2。

我个人习惯把QPS和并发数结合起来看：

• 低并发高QPS：说明每个请求处理得快，适合实时对话场景
• 高并发低QPS：说明系统在排队，适合离线批量处理

知识体系总览

下面这张图，我把六个指标的关系画出来了。你看一眼就能明白它们是怎么互相影响的：

这张图你看懂了吗？核心逻辑是：并发数决定了你能同时处理多少请求，这直接影响吞吐量和QPS；而TTFT和ITL共同决定了端到端延迟。压测时，你得在这几个指标之间找到平衡点。

---