大模型推理中的 TTFT、TPOT、吞吐量和端到端延迟分别是什么？

简化版

四个核心指标：TTFT（首 token 延迟） 是请求到达后吐出第一个 token 的时间，主要受排队和 Prefill 影响；TPOT（平均每输出 token 时间） 通常用首 token 后的生成时长除以后续 token 数，ITL 则记录相邻 token 的单次间隔，二者相关但统计口径不完全相同；端到端延迟（E2E） 是整个请求从开始到最后一个 token 的总时间；吞吐量 是单位时间处理的 token 数或请求数。它们互相牵制，报告时必须同时说明输入/输出长度、并发和统计口径，否则数字不可比。

详细版

常用指标：

TTFT：客户端发请求 → 收到第一个输出 token（含排队 + Prefill）；
TPOT：首 token 后的生成时长除以后续输出 token 数；ITL 是逐个相邻 token 的时间间隔，可进一步报告其分布；
端到端延迟 E2E：请求开始 → 最后一个 token 返回；
输出吞吐：每秒生成的输出 token 数；
总 token 吞吐：每秒处理的输入 + 输出 token 数；
请求吞吐（QPS）：每秒完成的请求数。

平均值会掩盖尾延迟，生产报告必须给 P50/P95/P99，并区分冷启动与稳态。不同输入长度、输出长度、并发下的数字不能直接横向比较。

完整版教学

一、延迟如何分解：一个公式和一次请求的旅程

一次请求大致经历：网关 → 排队 → Tokenize → Prefill → 逐 token Decode → 流式返回。TTFT 覆盖「首 token 之前」的全部环节，E2E 再加上后续所有 Decode。粗略关系：

E2E ≈ TTFT + (M − 1) × TPOT     （M = 输出 token 数）

举个数字例子：TTFT = 400ms，TPOT = 20ms，输出 200 token：

E2E ≈ 400 + 199 × 20 = 400 + 3980 ≈ 4380ms ≈ 4.4 秒

可以看出：短输出时 TTFT 主导 E2E，长输出时 TPOT 主导。想优化一个 500 token 的长回答，压 TPOT 比压 TTFT 更划算（4380ms 里 Decode 占了 90%）。这只是平均近似——动态批处理、网络抖动、每轮调度会让 token 间隔并不均匀。

二、TTFT 受什么影响，怎么优化

TTFT = 排队时间 + Prefill 时间。影响因素：

长 prompt → Prefill 计算和显存访问增多 → TTFT 高；标准全注意力整段 Prefill 的注意力计算量对序列长度近似二次增长，不能笼统写成总计算量与长度严格成正比；
队列拥塞、大批次 → 请求排队等待，TTFT 升高；
Prefix Cache 命中 → 跳过重复前缀的 prefill，显著降 TTFT（但缓存查找、跨节点传输、未命中部分仍有成本）。

交互式聊天对 TTFT 极敏感（用户盯着屏幕等第一个字），离线批量任务则更看总吞吐。所以优化目标要按场景定。

三、TPOT 受什么影响，怎么优化

TPOT 是 Decode 每轮的耗时。Decode 每轮为每个活跃序列生成一个 token，要反复读权重和 KV Cache。影响因素：

并发序列数（batch）：batch 越大，权重读取被更多 token 摊薄，单 token 平均更快（但总延迟可能升）；
上下文长度：KV Cache 越大，每轮读取越多，TPOT 升高；
模型并行的通信、调度抢占：都会拖慢每轮。

易错点：流式输出改善的是”体感”，不降低模型实际 Decode 时间——它只是把已生成的 token 尽早推给用户，TPOT 该多少还是多少。

四、吞吐量为什么最容易误导

吞吐是最容易被「刷」出来好看、也最容易误导的指标：

增大 batch 通常提高总 token 吞吐，却抬高 TTFT 和尾延迟——吞吐和延迟是跷跷板。
请求吞吐（QPS）高度依赖输出长度：一个只答几个字的服务，天然每秒完成更多请求；不能拿它和长文生成服务比。

所以任何吞吐数字都必须附带：输入/输出长度分布、并发模型、硬件、精度、并行方式、SLA 目标。脱离这些条件的「我们能跑 X tokens/s」是没有意义的。

记忆钩子：TTFT 看”多久开始答”，TPOT 看”答得多流畅”，E2E 看”多久答完”，吞吐看”系统单位时间做多少活”——任何一个都必须连同负载条件一起解释。

五、为什么必须看分位数（P99）而非平均

平均延迟会掩盖尾部：99% 的请求很快，但 1% 因排队或超长输出而极慢，平均值看不出来，用户却真实地被那 1% 伤害到。所以生产必须报 P50/P95/P99：

P50 = 中位数（一半请求比它快）
P95 = 95% 请求比它快（常规体验）
P99 = 99% 请求比它快（最差体验，最能暴露问题）

尤其 P99 TTFT/TPOT 常是 SLO 的关键——它表示约 99% 的观测值不超过该阈值，用来约束尾部而不是描述绝对最慢的一次。优化时若平均下降但 P99 上升，往往说明拥塞、长请求或调度不公平正在伤害尾部体验。

六、正确的压测方法

开放环（open-loop）压测：按目标到达率持续发请求，不管上一个是否完成——更真实，容易暴露过载排队。
闭环（closed-loop）压测：等上一批完成再发下一批——会低估生产流量峰值，容易得出过于乐观的结论。
步骤：先预热模型（避免冷启动污染数据），再同时观测延迟分位数、吞吐、显存、GPU 利用率、队列长度、错误率。
流量分布要真实：输入/输出长度必须贴近线上，全用短请求测的结论上线会翻车。

七、用统一口径比较推理指标

指标比较必须固定起止点、聚合范围和负载条件。服务端测得的首 Token 写出时间不等于客户端收到时间，整机输出吞吐也不能与单请求生成速率直接比较；跨系统对比时应同时披露硬件、模型精度、输入/输出长度分布、到达率、并发和是否命中缓存。

指标	起止点	用户感知
TTFT	请求到首 token	等多久开始回答
TPOT	相邻输出 token	回答流是否顺畅
E2E Latency	请求到完成	总等待时间
Goodput	满足 SLO 的吞吐	有效服务能力

例如系统 A 输出 2,000 token/s，但只有 80% 请求满足 P99 SLO；系统 B 输出 1,850 token/s，却有 99.5% 请求满足 SLO。若业务以按时完成为成功条件，B 的 Goodput 可能更高，不能只用原始 Tokens/s 判定容量。

八、常见误区与追问

误区：TTFT 包含整段输出时间。 TTFT 截止首个有效 token；后续生成速度可用 TPOT 的平均值和 ITL 的分布描述。
误区：tokens/s 不需要说明分母。 它可能指单请求、单 GPU、整机或全服务吞吐，口径不同不可比较。
误区：平均延迟能代表用户体验。 长提示、长输出和排队会形成重尾，必须报告 P95/P99 并按长度切片。
追问：流式请求的端到端延迟怎么算？ 从接收请求到最后一个 token 写出，等于排队、Prefill、逐 token Decode 与网络发送之和。
追问：容量优化后看哪些指标？ 同时看 TTFT、TPOT、完成吞吐、取消率、队列时间、显存水位和质量，防止只移动瓶颈。

九、加强记忆

四指标记「开始/流畅/答完/总产出」：TTFT 看首 token，TPOT 看首 token 后的平均生成间隔，ITL 保留逐间隔分布，E2E ≈ TTFT +(M−1)×TPOT，吞吐看 token/s 或 QPS。三条铁律钉死：吞吐与延迟常有取舍，平均值不能代替 P95/P99，任何数字都要附输入输出长度、并发和测量边界才可比。压测使用开放环、真实长度分布并先预热，最终用满足 SLO 的 Goodput 判断有效容量。

简化版

详细版