3、性能基准测试概念：吞吐量、延迟、首Token延迟、Token生成速率、TTFT、TPOT等关键指标定义与计算方式

在vLLM的调优实践中，性能基准测试是衡量系统能力、定位瓶颈、验证优化效果的基础工程手段。如果指标定义不清晰、计算口径不统一，后续的调优工作将失去可比较的锚点。本章将系统梳理LLM推理服务中最核心的性能指标，包括吞吐量（Throughput）、延迟（Latency）、首Token延迟（TTFT）、单Token生成时间（TPOT）以及Token生成速率等，明确其数学定义、测量方法、适用场景与常见误区，为后续章节的基准测试工具使用和参数调优奠定严谨的度量基础。

3.1 核心指标定义与数学表达

3.1.1 延迟（Latency）与首Token延迟（TTFT）

延迟是用户可感知的最直接指标，定义为从客户端发送请求到收到完整响应所经过的总时间。在LLM推理场景中，延迟需要进一步拆解为两个关键阶段：首Token延迟（TTFT, Time To First Token）和Token间延迟（TPOT, Time Per Output Token）。TTFT衡量的是从请求发出到模型输出第一个Token的时间，它包含了网络传输、请求排队、输入预处理（Prefill）以及首Token生成的全部耗时。TTFT直接决定了用户等待"第一个字"的体验，在交互式应用中（如聊天机器人、实时翻译），TTFT通常要求控制在500ms以内。

从数学角度看，TTFT的计算公式为：

TTFT = T_first_token - T_request_sent

其中，T_request_sent是客户端发出请求的时刻，T_first_token是客户端收到第一个输出Token的时刻。在实际测量中，需要注意网络传输时间的影响，如果客户端与服务端不在同一网络环境，应使用服务端日志中的时间戳来计算，以排除网络波动干扰。

3.1.2 Token生成速率与TPOT

TPOT（Time Per Output Token）是衡量模型生成阶段效率的核心指标，它表示生成每个输出Token所需的平均时间。TPOT的计算方式为：

TPOT = (T_complete - T_first_token) / (N_output_tokens - 1)

其中，T_complete是收到完整响应的时刻，N_output_tokens是输出Token的总数。分母使用(N-1)是因为第一个Token的生成时间已计入TTFT，后续每个Token的生成间隔才是Decode阶段的真实耗时。Token生成速率（Tokens/s）与TPOT互为倒数关系：

Token生成速率 = 1 / TPOT

例如，若TPOT为50ms，则每秒可生成20个Token。在实际部署中，TPOT受模型大小、硬件算力、KV Cache命中率、并发负载等多重因素影响，是调优时最需要关注的指标之一。

3.1.3 吞吐量（Throughput）

吞吐量衡量系统在单位时间内处理的请求数量或生成的Token总量，通常以requests/s或tokens/s为单位。在vLLM的基准测试中，吞吐量有两种常见口径：

• 请求级吞吐量：单位时间完成的请求数，适用于衡量服务端的并发处理能力。
• Token级吞吐量：单位时间生成的Token总数，更直接反映模型的计算效率。

吞吐量的计算公式为：

Throughput = 总请求数 / 总测试时间（或 总生成Token数 / 总测试时间）

需要注意的是，吞吐量与延迟之间存在经典的"倒U型"关系：在低并发下，延迟低但吞吐量也低；随着并发增加，吞吐量上升但延迟也随之恶化；当并发超过系统承载能力时，吞吐量反而下降（因排队和资源争抢）。因此，基准测试必须同时报告吞吐量和延迟分布，才能全面评估系统性能。

指标名称	缩写	定义	计算公式	典型优化目标
首Token延迟	TTFT	请求发出到收到首个Token的时间	T_first_token - T_request_sent	P95 < 500ms（交互式）
Token间延迟	TPOT	生成每个输出Token的平均时间	(T_complete - T_first_token) / (N-1)	P95 < 100ms（流式）
Token生成速率	Tokens/s	每秒生成的Token数量	1 / TPOT	越高越好
请求级吞吐量	Req/s	单位时间完成的请求数	总请求数 / 总时间	满足SLO前提下最大化
Token级吞吐量	Tokens/s	单位时间生成的Token总数	总Token数 / 总时间	满足SLO前提下最大化
端到端延迟	Latency	请求发出到完整响应的时间	T_complete - T_request_sent	P95 < 2s（非流式）

3.2 指标测量方法与操作流程

3.2.1 基准测试的标准流程

为了获得可复现、可比较的性能数据，基准测试必须遵循标准化的操作流程。以下是vLLM性能测试的推荐步骤：

1. 环境准备：固定硬件配置（GPU型号、数量）、CUDA版本、vLLM版本、模型权重版本，记录所有环境参数。
2. 数据集构造：使用具有代表性的输入数据，包括不同长度（短、中、长）的Prompt，以及不同的输出长度配置（max_tokens参数）。
3. 预热（Warmup）：在正式测试前发送若干请求，让GPU达到稳态温度、CUDA上下文完成初始化、Page Attention的Block分配器进入稳定状态。通常预热50-100个请求。
4. 并发压力测试：使用vLLM自带的benchmark_serving.py脚本或自定义压测工具，以固定并发数（如1、4、8、16、32、64）发送请求，持续运行足够长时间（建议至少3-5分钟）以获得稳态数据。
5. 数据采集：记录每个请求的TTFT、TPOT、总延迟、成功/失败状态，以及服务端的GPU利用率、显存占用、KV Cache使用率。
6. 统计输出：计算P50/P95/P99分位数、平均值、标准差，并生成吞吐量-延迟曲线。

3.2.2 测量工具与命令示例

vLLM提供了内置的基准测试工具，位于benchmarks/benchmark_serving.py。以下是一个典型的测量命令：

# 启动vLLM服务（后台）
python -m vllm.entrypoints.openai.api_server \
    --model meta-llama/Llama-3.1-8B-Instruct \
    --gpu-memory-utilization 0.90 \
    --max-num-seqs 256 \
    --port 8000 &

# 运行基准测试（固定并发数模式）
python benchmarks/benchmark_serving.py \
    --backend vllm \
    --model meta-llama/Llama-3.1-8B-Instruct \
    --tokenizer meta-llama/Llama-3.1-8B-Instruct \
    --dataset-path ShareGPT_V3_unfiltered_cleaned_split.json \
    --num-prompts 500 \
    --concurrency 32 \
    --max-tokens 512 \
    --warmup 50 \
    --save-result results_concurrency32.json

测试完成后，脚本会输出包含TTFT、TPOT、延迟分位数、吞吐量等指标的JSON文件，并打印汇总表格。对于更细粒度的分析，可以修改脚本或使用自定义客户端记录每个请求的时间戳。

3.3 案例拆解：并发数对性能指标的影响分析

为了直观展示各指标之间的关系，我们设计一个标准测试案例。测试环境为单张NVIDIA A100 80GB GPU，模型为Llama-3.1-8B-Instruct（FP16精度），输入Prompt平均长度512 Token，输出长度固定为256 Token。我们分别以并发数1、8、16、32、64进行测试，记录关键指标。

并发数	吞吐量 (req/s)	Token吞吐 (tokens/s)	TTFT P95 (ms)	TPOT P95 (ms)	端到端延迟 P95 (s)
1	1.2	307	180	45	11.7
8	8.5	2176	320	58	15.2
16	14.2	3635	550	72	18.9
32	18.6	4762	980	95	25.4
64	17.1	4378	2100	140	38.7

案例分析：从数据中可以看到，当并发数从1增加到32时，吞吐量持续上升（从1.2 req/s提升到18.6 req/s），但TTFT和TPOT也在同步恶化。TTFT P95从180ms增长到980ms，已经超过交互式应用500ms的SLO红线。当并发数达到64时，吞吐量反而下降至17.1 req/s，说明系统已进入过载状态——GPU计算资源饱和、KV Cache内存不足导致请求排队时间急剧增加，TTFT P95飙升至2.1秒。

调优决策：对于该配置，最优工作点应选择并发数16-24之间。若业务对TTFT敏感（如聊天场景），应限制最大并发数或使用vLLM的--max-num-seqs参数进行限流；若业务对吞吐量更敏感（如离线批量处理），可以接受较高的延迟，将并发数设置在32左右。此外，可以通过开启--enable-prefix-caching、调整--max-model-len或使用量化（如AWQ）来进一步优化。

3.4 常见误区与总结复盘

3.4.1 误区一：只测吞吐量，忽略延迟分布

许多团队在汇报性能时只给出"吞吐量达到XX tokens/s"的单一数字，这具有很大的误导性。高吞吐量可能是在极高并发下实现的，此时延迟可能已经恶化到不可接受的程度。正确的做法是同时报告吞吐量和延迟分位数，并明确SLO约束条件。例如："在P95 TTFT < 500ms的约束下，最大吞吐量为14.2 req/s"。

3.4.2 误区二：忽略输入/输出长度的影响

LLM推理的耗时与输入长度（影响Prefill计算量）和输出长度（影响Decode步数）强相关。如果基准测试只使用单一长度的数据，结果无法代表真实业务场景。建议使用混合长度的数据集（如ShareGPT数据集），并分别统计不同长度区间下的指标。

3.4.3 误区三：未进行预热或测试时间过短

GPU在冷启动时性能较低，CUDA内核加载、显存分配、Page Attention的Block初始化都会影响前几个请求的延迟。如果测试时间过短（如仅运行30秒），数据会包含大量预热阶段的噪声。建议预热至少50个请求，正式测试持续3分钟以上，并丢弃前10%的数据点。

3.4.4 误区四：混淆TPOT与Token生成速率

TPOT的单位是"毫秒/Token"，而Token生成速率的单位是"Token/秒"，两者互为倒数。但在流式输出场景中，用户感知的"打字机效果"取决于Token生成速率，而非TPOT。例如，TPOT为50ms时，Token生成速率为20 Token/s，用户每50ms看到一个新Token，体验流畅；若TPOT为200ms，则每秒仅生成5个Token，用户会明显感到卡顿。