TTFT、TPOT、吞吐和并发应如何联合分析？

Serving load pattern examples。用于辅助理解本题的数据流或工程结构。

图：用于辅助理解本题的数据流或工程结构。来源：Serving load pattern examples，作者 vLLM Project contributors，许可 Apache-2.0。

考察意图

面试官希望确认候选人能否解释“TTFT、TPOT、吞吐和并发应如何联合分析”中的因果关系，并把公式或流程落实到可测量的工程结果。

60–90 秒口述答案

TTFT 主要覆盖排队、tokenize 和 Prefill，决定交互首响应；TPOT/ITL 描述 Decode 相邻 token 间隔，决定流式速度；端到端延迟还与输出长度相乘。吞吐可按 requests/s 或 tokens/s，必须注明输入/输出 token。并发是系统中的在途请求，不等同于 QPS。面试应给 P50/P95/P99 和负载模型。

深入解释

Little 定律在稳态下 L=λW，可用到达率和平均时延估算在途请求。粗略 E2E≈queue+TTFT+(output_tokens-1)×TPOT，但动态批处理会让各项相关。

白板回答时先声明输入规模、张量或请求状态，再推到输出与瓶颈；不要只罗列术语。

工程权衡

增大 batch 往往提高 tokens/s，却增加排队和单 token 间隔；优化目标应是满足 SLO 下的最大可承载吞吐，而不是离线峰值。压测需 warm-up、固定硬件、报告长度分布与开环/闭环流量。

关键指标包括：TTFT、TPOT/ITL、端到端 P50/P95/P99、tokens/s、并发、队列时间、显存水位与单位 token 成本。

完整复习答案

先拆开一次请求

围绕“TTFT、TPOT、吞吐和并发应如何联合分析”，推理题需要把排队、Prefill 和逐 token Decode 分开。GPU 算力、显存容量、内存带宽与调度空槽可能同时成为约束，一个总体吞吐数字无法定位瓶颈。

用数量级定位瓶颈

请求输出 100 token，TTFT=300ms、TPOT=40ms，则粗略端到端约 300+99×40=4260ms，未计额外网络开销。同样 1000 tokens/s 的服务，可能通过大 batch 获得高吞吐，却让单用户 TPOT 和排队 P99 变差。

这个估算给出量级。代入项目参数时需要写明忽略项，并保持单位一致。

压测应回答什么

围绕“TTFT、TPOT、吞吐和并发应如何联合分析”，压测写明模型、dtype、并行度、硬件、输入输出长度分布和到达方式，同时报告 TTFT、TPOT、端到端尾延迟、tokens/s 与显存水位。容量取满足 SLO 的安全点。

追问参考

吞吐提升但 P99 变差，调度器可能做了什么？

对“TTFT、TPOT、吞吐和并发应如何联合分析”而言，吞吐提高而 P99 变差通常来自更大批次、更长等待窗口或 Prefill 抢占 Decode；查看 queue time、batch token 数和每阶段时间即可区分。

OOM 是权重、激活、临时 workspace 还是 KV Cache 导致？

回到“TTFT、TPOT、吞吐和并发应如何联合分析”，需要区分：OOM 要按权重、KV、激活、workspace 与碎片拆账，并用输入/输出长度、并发和块水位复现，不能只归因于“模型太大”。

怎样判断方案已经达到上线条件？

“TTFT、TPOT、吞吐和并发应如何联合分析”进入发布方案前，性能结论需绑定硬件、dtype、模型、并行度、长度分布、并发模型和 SLO；离线峰值不能直接当线上容量。

常见错误回答

只复述“TTFT、TPOT、吞吐和并发应如何联合分析”涉及的术语，没有说明输入、运算和输出之间的关系。
讨论性能指标时省略模型规模、数据分布或硬件条件，使结论失去适用范围。
只讲收益，没有检查 TTFT、TPOT、SLO 带来的精度、资源或可靠性代价。

连续追问

若改变 TTFT 的关键配置，哪些中间量会先发生变化？
如何设计对照，检验观察到的差异是否来自性能指标？
哪类输入或负载最容易使这一方案失效？

项目结合

准备一个与性能指标直接相关的测量或排障案例。讲清基线、异常指标、被排除的假设和最终判定；没有亲历时，说明会采集哪些数据，不虚构结果。

复习自测

能否脱离笔记解释 TTFT、TPOT、吞吐和并发应如何联合分析的关键运算？
能否把文中的数量级例子换成自己的模型或业务参数？
能否指出一种不适用场景，并给出可观测的判定条件？