三亩地 三亩地SAN MU DI · CODE DIARY
ARTICLE DETAIL

日记详情

真实记录编程学习的某一天,欢迎挑你感兴趣的翻一翻。

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

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

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

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

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

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

我最近最常见到的混说,大概有这几种:

← 返回列表