TTFT、TPOT 与 ITL：为什么上下文变长不会让逐 token 延迟按 1 x 降低

整理日期：2026-09-14（晚间增量）。依据当天新增问题、可见对话摘录与一手资料整理，不是完整逐字稿。教学推导与用户反馈分别注明，未执行服务器操作。

三个时间指标

TTFT 是从请求开始到首个 token 的时间，通常包含排队、输入处理和 Prefill 等开销。TPOT 是每个输出 token 的平均时间，常见口径排除首 token。ITL 是相邻输出 token 的实际时间间隔，更适合看抖动。

对于输出 N>1 的请求，常用 TPOT=(末 token 时间−首 token 时间)/(N−1)。不同统计工具的请求平均与全局间隔平均可有不同权重。vLLM Benchmark 说明

“优化 60%”应怎样读

如果指 TPOT 降低 60%，则新值为旧值的 40%。假设从 100ms 降到 40ms，对应该口径的单请求生成速率由约 10 token/s 变成 25 token/s，即 2.5 倍。它不等于吞吐只增加 60%，也不保证整个服务吞吐增加 2.5 倍。

这些数字是教学算例。你提到的 TTFT 50%、TPOT 60% 未附基线和测试配置，不作为实测结论。

上下文越长，TPOT 怎样变化

全局 Attention 的 decode 每步需要处理更长历史。固定模型、并发和并行方式时，可用教学模型 TPOT(S)≈a+bS 描述某些区间：a 表示权重计算、调度等相对固定成本，bS 表示随历史增长的部分。

于是生成速率约为 1/(a+bS)；当 bS 占主导时才接近 1/S。下降的是速率，不是延迟。真实系统还受缓存、内核切换、通信、投机接受率影响，曲线不一定平滑线性。

MLA、DSA、KDA 分别改变哪里

MLA 压缩缓存，可降低斜率但不保证消除长度依赖；DSA 减少主要注意力访问范围，仍有索引成本；KDA 的递归状态层可避免历史 KV 线性增长，但混合模型还包含全局层。DCP 分摊容量与读取，同时增加通信。

怎么做一张有解释力的曲线

固定输出长度、并发、版本、精度、并行方式和 prefix 命中状态，只改变输入长度。分别记录 TTFT、TPOT、ITL P95/P99 和总吞吐；明确是否启用投机解码。不要用一次短文本示例的进度条速率代表完整服务性能。

2026-10-07 增量：ITL、流式事件与投机解码

问题起点：10月7日14:41北京时间再次问“ITL是什么”。此前定义需要加上采集口径。

教学例：请求t0发起，3个输出token分别在100、140、220ms到达，则TTFT=100ms，两段ITL为40和80ms，请求级TPOT=60ms。多个请求的TPOT均值不等于把全部间隔合并的均值；长输出请求在后者占更大权重。以上非实测。

客户端测到的流式事件可能一次包含多个token，尤其投机解码/输出缓冲场景。一个事件内没有逐token时间，不能凭空填成0ms间隔并与单token事件分布比较。网络/代理缓冲还会影响客户端可见间隔。

当前vLLM官方指标明确区分inter_token_latency_seconds（连续输出事件间隔）与request_time_per_output_token_seconds（每请求TPOT）；输出≤1token时数学上的TPOT不定义，Prometheus实现可记录0，而bench serve统计会排除。这是工具口径差异，不是模型产生了零延迟。指标说明、Benchmark CLI（2026-10-07）

报表写清测量点、事件/token单位、聚合权重、投机开关、实际输出长度和采样量；同时看TTFT、请求级TPOT、ITL尾部和成功吞吐。低平均值不能遮住长时间停顿。

rollout短样本先结束并不代表整轮结束；训练可能等待长尾或工具/环境返回。相关状态与sleep讨论见verl 入门：连接大模型强化学习后训练与推理系统。