3. 吞吐量关键指标：吞吐量、延迟、首token延迟、TTFT、TPOT等定义与测量

在评估 vLLM 与 TensorRT-LLM 这类 LLM 推理引擎时，仅凭“快”或“慢”的主观感受远远不够。吞吐量调优的前提是建立一套精确、可复现的度量体系。本章将厘清吞吐量（Throughput）、延迟（Latency）、首 Token 延迟（TTFT）、每个输出 Token 时间（TPOT）等核心指标的定义、测量方法及它们之间的权衡关系。只有正确理解这些指标，才能避免“调优调到了错误的方向”。

3.1 核心指标定义与业务含义

LLM 推理的延迟特性与经典 Web 服务有本质区别：它不是一个单一请求的“请求-响应”时间，而是一个包含 预填充（Prefill） 与 解码（Decode） 两个阶段的流式过程。因此，我们需要用多个维度刻画性能。

3.2 指标间的权衡与测量陷阱

吞吐量与延迟并非总是同向变化。在连续批处理（Continuous Batching）机制下，提高吞吐量往往意味着增大 Batch Size，这会增加单个请求的排队等待时间，从而推高 TTFT 和 TPOT。因此，性能测试必须明确负载场景。

测量时需区分在线流式指标与离线批处理指标。对于在线服务，应使用并发请求模拟真实用户；对于离线任务（如批量文档总结），则更关注纯吞吐量。

3.3 测量方法与工具链

为了准确测量上述指标，我们需要在客户端记录关键时间戳。以下是一个基于 Python 的伪代码流程，展示了如何测量 TTFT 与 TPOT：

import time
from openai import OpenAI

client = OpenAI(base_url="http://localhost:8000/v1", api_key="EMPTY")

start = time.perf_counter()
stream = client.chat.completions.create(
    model="meta-llama/Llama-3.1-8B-Instruct",
    messages=[{"role": "user", "content": "请写一篇关于AI的短文"}],
    stream=True,  # 开启流式
    max_tokens=512
)

first_token_time = None
token_times = []
for chunk in stream:
    if chunk.choices[0].delta.content:
        now = time.perf_counter()
        if first_token_time is None:
            first_token_time = now
            ttft = (now - start) * 1000  # 毫秒
        else:
            token_times.append(now)

end = time.perf_counter()
total_latency = (end - start) * 1000

# 计算 TPOT（排除首Token）
if len(token_times) > 1:
    tpot = (token_times[-1] - token_times[0]) / (len(token_times) - 1) * 1000
else:
    tpot = 0

print(f"TTFT: {ttft:.1f} ms")
print(f"TPOT: {tpot:.1f} ms/token")
print(f"Total Latency: {total_latency:.1f} ms")
print(f"Output tokens: {len(token_times) + 1}")

对于吞吐量压测，推荐使用 vllm/benchmarks/benchmark_serving.py 脚本（vLLM 自带）或 genai-perf（NVIDIA 官方工具）。这些工具支持指定并发数、请求速率、输入/输出 Token 分布，并自动汇总 TTFT、TPOT、端到端延迟及吞吐量分位数。

3.4 案例：并发数对指标的影响

我们在一台 A100-80G 上部署 vLLM，使用 Llama-3.1-8B 模型，固定输入 512 Token，输出 256 Token。通过 benchmark_serving.py 改变并发数，得到如下典型数据：

从数据中可以看到：当并发从 1 增至 32 时，吞吐量提升了约 17 倍，但 TTFT 增加了 6 倍以上，TPOT 也几乎翻倍。这说明吞吐量的提升是以牺牲单请求延迟为代价的。在实际部署中，必须根据业务 SLA（如 TTFT < 500ms）设定并发上限。

3.5 可视化：指标关系与测量点

下图展示了单个请求在 LLM 推理引擎中的时间线，以及各指标对应的测量区间。理解这张图有助于定位性能瓶颈究竟出现在预填充阶段还是解码阶段。

图中清晰地展示了：TTFT 的测量区间是从请求到达（t₀）到首个 Token 返回（t₁），它包含了排队等待、显存分配和预填充计算的全部耗时。而 TPOT 则是解码阶段（t₁ 到 t₂）生成 N 个 Token 的平均时间。总延迟是两者之和。

3.6 误区与复盘：指标解读中的常见错误

在实际调优过程中，工程师常陷入以下误区：

• 误区一：只优化 TTFT 而忽略 TPOT。 对于长文本生成任务（如代码生成、文章撰写），TPOT 对用户体验的影响更大。一个 TTFT 为 200ms 但 TPOT 为 50ms/token 的系统，生成 1000 个 Token 需要 50 秒；而 TTFT 为 500ms 但 TPOT 为 20ms/token 的系统，仅需 20.5 秒。后者体验反而更好。
• 误区二：将吞吐量与延迟指标混在一起比较。 对比 vLLM 与 TensorRT-LLM 时，必须在相同并发数和相同请求分布下比较。若 vLLM 在并发 32 时吞吐量为 1500 tokens/s，而 TensorRT-LLM 在并发 8 时吞吐量为 900 tokens/s，这并不能说明 vLLM 更优，因为负载条件不同。
• 误区三：忽略预热（Warmup）直接测量。 推理引擎在启动初期会进行 CUDA 内核编译、显存池初始化等操作，导致前几个请求延迟极高。正确做法是先发送若干预热请求，待系统稳定后再开始计时。
• 误区四：使用固定输入长度测试。 真实场景中 Prompt 长度差异巨大。建议使用符合业务分布的输入长度（如 128、512、2048 Token 混合），否则测得的 TTFT 无法反映真实负载。