别把 `TTFT`、`TPOT`、吞吐量都当成“延迟优化”：真正先分开的，是排队、prefill、decode、continuous batching 这 4 层

别把TTFT、TPOT、吞吐量都当成“延迟优化”：真正先分开的，是排队、prefill、decode、continuous batching 这 4 层

很多团队一聊大模型推理延迟，嘴里会连续冒出几句话：TTFT要低一点、TPOT要稳一点、吞吐量要高一点、再把continuous batching和chunked prefill打开。问题在于，这几个词经常被当成同一类“推理优化术语”一起说，真到线上排障时反而最容易失焦。你看到TTFT变差，可能第一反应是 decode 太慢；可在很多真实服务里，先拖垮首 token 的并不是生成速度，而是请求排队、长 prompt prefill、调度策略，甚至是你把一个更适合吞吐的开关，当成了所有场景都该开的低延迟开关。

这篇文章不做框架 PK，也不复读 benchmark 榜单。我想把一个更基础但更值钱的问题讲清楚：TTFT、TPOT、端到端时延、吞吐量、continuous batching、chunked prefill到底分别落在请求生命周期的哪一层，它们彼此之间为什么经常一起出现、却绝不该混成一句“延迟优化”。

先把最容易混的 4 句话摆出来

我最近最常见到的混说，大概有这几种：