推理性能指标：延迟、吞吐量、首Token延迟、TTFT、ITL等关键指标定义

在对比 TensorRT-LLM 与 vLLM 的性能之前，必须先建立一套精确、可复用的度量体系。推理性能指标并非简单的“快与慢”，而是由多个维度构成：用户感受到的“响应速度”、系统层面的“处理能力”、以及反映解码过程内部效率的“细粒度时延”。如果对这些指标的定义、计算口径和适用场景理解不一致，任何对比结论都可能失真。本节将系统梳理 LLM 推理中最核心的六项指标：TTFT、ITL、TPOT、端到端延迟、吞吐量与并发数，并厘清它们之间的数学关系与业务含义。

一、核心指标定义与计算口径

LLM 推理通常分为两个阶段：预填充（Prefill）阶段处理输入提示词并生成 KV Cache，解码（Decode）阶段逐 token 自回归生成输出。不同指标分别刻画这两个阶段及整体表现。下表汇总了各指标的精确定义与典型测量方式：

指标 全称 定义 测量口径
TTFT Time To First Token 从请求发出到收到第一个输出 token 的时间 包含网络传输 + 排队 + Prefill 计算时间
ITL Inter-Token Latency 相邻两个输出 token 之间的时间间隔 仅统计 Decode 阶段，通常取均值或 P95
TPOT Time Per Output Token 生成单个输出 token 的平均耗时 与 ITL 等价，但强调单 token 视角
端到端延迟 E2E Latency 从请求发出到完整响应返回的总时间 TTFT + (输出 token 数 × ITL) + 网络回传
吞吐量 Throughput 单位时间内系统处理的请求数或 token 数 通常以 tokens/s 或 requests/s 计
并发数 Concurrency 同时处于处理状态（排队或执行）的请求数 压测工具中的并发连接数
关键区分：TTFT 与 ITL 是不同阶段的指标。TTFT 主要受 Prefill 计算量、输入长度和排队等待影响；ITL 则反映 Decode 阶段每次前向传播的耗时，受 batch size、模型大小和显存带宽制约。两者不可混用，例如“首 token 快但后续生成慢”的系统，TTFT 低而 ITL 高。

二、指标间的数学关系与业务映射

理解指标间的推导关系，有助于从单一测量值推算其他维度。假设某请求输入长度为 P，输出长度为 G，则：

端到端延迟 ≈ TTFT + G × ITL
系统吞吐量 ≈ 并发数 × G / 端到端延迟（理想流水线）
单用户感知速度 ≈ 1 / TTFT（首字响应）与 1 / ITL（续写流畅度）

从业务视角看，不同场景对指标的敏感度截然不同：

  • 聊天机器人/交互式对话：TTFT 决定“第一印象”，ITL 决定打字机效果的流畅度。用户期望 TTFT < 500ms，ITL < 100ms。
  • 离线批量处理/文档摘要：更关注吞吐量（tokens/s），对单请求延迟不敏感，可接受较高并发以换取整体效率。
  • 代码补全/流式输出：ITL 的稳定性（P95 而非均值）至关重要，偶发卡顿会严重破坏体验。
实践建议：性能对比报告中应同时报告 TTFT 与 ITL 的均值、P50、P95 和 P99，而非仅给平均值。平均值会掩盖长尾延迟问题，而 P95/P99 才能暴露调度器或显存分配不均导致的抖动。

三、可视化：LLM 推理时间线中的指标定位

下图展示了一个典型请求在 TensorRT-LLM 或 vLLM 服务中的完整时间线，清晰标出各指标的测量区间：

LLM 推理请求时间线与性能指标定位 网络 排队 Prefill t1 t2 t3 t4 t5 t6 t7 t8 网络 t₀ t₁ t₂ t₃ t₄ TTFT ITL×8 端到端延迟 指标计算示例（输入 100 token，输出 8 token） Prefill 耗时 = 45ms → TTFT ≈ 45ms + 排队 + 网络 Decode 总耗时 = 8 × 12ms = 96ms → ITL 均值 = 12ms 端到端 = 45ms + 96ms + 网络 ≈ 145ms（理想无排队）

图中可见，TTFT 覆盖从请求发出到第一个 token（t1）返回的全部时间，包含网络往返、排队等待和 Prefill 计算。ITL 则测量 t1→t2、t2→t3 等相邻 token 的间隔，反映 Decode 阶段的稳定速度。端到端延迟是两者之和（加上末次网络回传）。值得注意的是，在连续批处理（Continuous Batching）机制下，ITL 并非恒定值——当新请求插入 batch 或旧请求完成时，剩余请求的 ITL 可能瞬时增大，这正是需要关注 P95 而非仅均值的原因。

四、典型场景案例：指标如何指导选型

假设某企业需要为智能客服系统选择推理引擎，输入提示词平均 200 token，输出平均 150 token，目标并发 50。使用相同 GPU（A100-80G）分别压测 TensorRT-LLM 与 vLLM，得到以下简化数据：

引擎             TTFT(P50)   TTFT(P95)   ITL(P50)   ITL(P95)   吞吐量(tokens/s)
TensorRT-LLM    180ms       320ms       38ms       72ms       12,500
vLLM            210ms       410ms       42ms       95ms       11,200

从均值看，TensorRT-LLM 全面领先。但进一步分析：

  • 若客服场景要求 P95 TTFT < 400ms，两者均满足；但 P95 ITL 差异明显——TensorRT-LLM 的 72ms 仍能保持流畅打字机效果，vLLM 的 95ms 可能让用户感到轻微卡顿。
  • 若业务包含大量长输出（如生成报告），吞吐量差异 11.6% 将直接转化为 GPU 使用成本差异。
  • 若并发数提升至 100，vLLM 的 P99 ITL 可能急剧恶化（因其调度策略在高负载下产生更多排队），而 TensorRT-LLM 的显存管理更优，性能曲线更平缓。
常见误区：仅比较“吞吐量”或“单请求延迟”就得出结论。吞吐量高不代表用户体验好——如果系统通过牺牲 TTFT 或 ITL 稳定性来换取整体吞吐，交互式场景会明显感知到“首字慢”或“输出卡顿”。正确做法是：先明确业务对 TTFT、ITL 的 SLA 要求，再在满足 SLA 的前提下最大化吞吐量。

五、测量方法与工具链

标准化的指标测量需要控制变量并采用合适的压测工具。推荐以下流程：

  1. 固定输入输出长度：使用真实业务的平均长度，或构造多组长度（短/中/长）分别测试。
  2. 预热模型：正式压测前发送 10~20 个请求，确保 CUDA context、显存池和调度器状态稳定。
  3. 逐步增加并发：从 1 开始，按 1→2→4→8→16→32→64 递增，记录每个并发档位的指标。
  4. 采集分位数：每个档位运行至少 3 分钟，记录 P50/P95/P99 而非仅平均值。

常用工具包括：

  • vLLM 内置 benchmark：benchmark_serving.py 支持输出延迟分布和吞吐统计。
  • TensorRT-LLM 的 benchmarks/python/benchmark_serving.py：类似功能，可对比相同负载下的表现。
  • 通用压测：使用 wrk 或 ghz 发送 HTTP 请求，但需自行解析 SSE 流中的 token 时间戳。
# 示例：使用 vLLM 压测脚本（简化参数）
python benchmark_serving.py \
  --model meta-llama/Llama-3.1-8B-Instruct \
  --tokenizer meta-llama/Llama-3.1-8B-Instruct \
  --num-prompts 500 \
  --request-rate 10 \
  --max-concurrency 32 \
  --output-len 150 \
  --input-len 200

该命令会输出 TTFT、ITL、端到端延迟的直方图与分位数，以及吞吐量（requests/s 和 tokens/s）。对比 TensorRT-LLM 时，需保持相同的模型、输入输出长度、并发数和请求总数，才能获得公平结论。

六、误区与复盘：指标解读中的常见陷阱

在性能对比项目中，以下误区经常导致错误结论：

误区一：忽略 Prefill 与 Decode 的算力差异。Prefill 是计算密集型（矩阵乘），Decode 是访存密集型（显存带宽瓶颈）。TensorRT-LLM 的 kernel 融合优化对 Prefill 提升明显，而 vLLM 的 PagedAttention 主要优化 Decode 阶段的显存利用。若测试输入极短而输出极长，可能掩盖 TensorRT-LLM 在 Prefill 上的优势。
误区二：用吞吐量倒推延迟。系统吞吐量 = 并发数 × 单请求输出长度 / 端到端延迟，但这是理想流水线假设。实际系统中，高并发会导致排队，端到端延迟随并发非线性增长。正确做法是绘制“延迟-吞吐曲线”（Latency-Throughput Curve），观察拐点位置。
误区三：不区分流式与非流式返回。若客户端使用流式（SSE）接收，TTFT 和 ITL 直接决定用户体验；若使用非流式等待完整响应，则只有端到端延迟有意义。对比测试前必须明确 API 模式。

复盘一个真实案例：某团队对比 TensorRT-LLM 与 vLLM 时，仅报告了吞吐量（TensorRT-LLM 高 15%），便决定全量迁移。上线后用户投诉“响应变慢”——原因是该业务为交互式对话，P95 TTFT 从 300ms 恶化到 600ms。进一步排查发现，压测时使用了过大的 batch size，TensorRT-LLM 的连续批处理策略更激进，优先保证吞吐而牺牲了首 token 延迟。最终通过限制最大 batch 并启用 --max-num-seqs 参数，才在保持吞吐优势的同时将 TTFT 拉回 SLA 以内。这一案例说明：任何单一指标都不足以支撑选型决策，必须结合业务场景建立多维度的 SLA 约束，再寻找满足约束的最优解。

← 上一章 📖 返回目录 下一章 →