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

简化版

四个核心指标：TTFT（首 token 延迟） 是请求到达后吐出第一个 token 的时间，主要受排队和 Prefill 影响；TPOT（每 token 延迟，又叫 ITL） 是首 token 之后相邻 token 的平均间隔，反映 Decode 速度；端到端延迟（E2E） 是整个请求从开始到最后一个 token 的总时间；吞吐量 是单位时间处理的 token 数或请求数。它们互相牵制（如增大 batch 提吞吐但可能抬高 TTFT），报告时必须同时说明输入/输出长度和并发条件，否则数字不可比。

详细版

常用指标：

TTFT：客户端发请求 → 收到第一个输出 token（含排队 + Prefill）；
TPOT / ITL：首 token 之后，相邻输出 token 的平均间隔（反映 Decode）；
端到端延迟 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 是 SLA 的关键——它反映「最糟的那批用户」的体验。优化时若平均降了但 P99 涨了，往往是并发调过头、尾延迟恶化。

六、正确的压测方法

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

七、加强记忆

四指标记「开始/流畅/答完/总产出」：TTFT（首 token，排队+Prefill）、TPOT（每 token 间隔，Decode 速度）、E2E ≈ TTFT +(M−1)×TPOT（短输出 TTFT 主导、长输出 TPOT 主导）、吞吐（token/s 或 QPS）。三条铁律钉死：吞吐与延迟是跷跷板（增 batch 提吞吐但抬尾延迟）、必须看 P99 而非平均（平均掩盖尾部）、任何数字都要附输入输出长度和并发条件才可比。压测用开放环 + 真实长度分布 + 先预热。

简化版

详细版