聊大模型推理性能，张口就是几个缩写：TTFT、TPOT、ITL、QPS、TPS、P99。但一问细节就露馅：TTFT 到底包不包括排队？TPOT 和 ITL 是不是一回事？QPS 明明很高，用户为什么还喊慢？GPU 利用率拉满了，吞吐为什么没跟上？平均延迟很好看，P99 为什么还是爆？
这六个问题在工程现场被反复问，答案散落在各种文档里，越看越乱。根子上只有一个原因：这些词被当成了名词来背，而不是放回"一条请求真正走过的链路"里去理解。指标不是词汇表，是同一条推理链路上不同位置的观测点。这篇把链路拆开，每个指标放回它该在的位置。
一条请求的七段路
先把链路铺开。一条大模型推理请求，从发出到结束，大致走七段路：请求到达网关（鉴权、路由、限流）→ 排队与调度（分给哪个 Prefill 实例、是否合批、是否命中 KV Cache）→ Prefill 阶段（整段输入一次性算进去，生成 KV Cache）→ KV Cache 处理（复用、补齐或跨节点迁移）→ Decode 循环（逐个 token 往外吐）→ 输出持续 → 请求结束。
这段拆解来自一篇实操笔记（公众号"算力网络架构手记"，《从首 Token 到最后一个 Token》，2026-08-10），它把推理指标的定义全部挂在链路阶段上：
图：指标不是孤立名词，而是链路上不同位置的观测点。
- **TTFT**（首字延迟）：从请求发出到第一个 token 返回。它横跨了排队、Prefill 和第一次 Decode，所以"包不包括排队"取决于你在哪一层观测。用户体感的"慢不慢"，主要看它。
- **TPOT / ITL**（出字间隔）：Decode 阶段相邻两个 token 之间的时间。打字机快不快，看它。
- **E2E**（端到端时延）：整条请求走完的总时间。
- **QPS / TPS**：吞吐，系统视角。注意陷阱：同样是 tokens/s，有人说的是输出 token，有人说的是输入+输出，对比前先问清楚口径。
- **P99**：尾延迟。平均数漂亮没用，1% 的请求炸了，那 1% 的用户会去投诉。
为什么 GPU 利用率高，吞吐却没上来
这是最反直觉的一组问题。笔记给出的解释涉及 Prefill 和 Decode 的本质差异：Prefill 是计算密集型，一次性吃掉整段输入；Decode 是显存带宽密集型，每个 token 都要把历史 KV 重新读一遍。
两类负载挤在同一张卡上，互相打架。长 Prompt 的 Prefill 会抢占算力，阻塞正在进行的 Decode，字间延迟开始抖动，P99 长尾恶化——这就是"头阻塞"。GPU 利用率看起来很高，但有效吞吐（Goodput）上不去，因为算力花在了错配的地方。（来源：KimKB 笔记《PD分离技术详细分析》，2026-08-16）
解法是 PD 分离：Prefill 集群和 Decode 集群拆开，各自配最合适的硬件——Prefill 节点选高算力卡，Decode 节点选大显存高带宽的性价比推理卡。中间用 RDMA 或高速网络传 KV Cache，只传中间状态，不传原始 Prompt 和模型权重，传输延迟必须控制在几十毫秒级，否则白拆。
这个架构已经被 vLLM、SGLang、DistServe 等主流引擎支持，Mooncake 这类方案更进一步，把 KV Cache 放进分布式缓存池，支持会话迁移和跨请求复用，不够用时还能落盘到 SSD 扩容。拆完之后，扩缩容也跟着解耦了：Prefill 请求暴涨只扩 Prefill 集群，Decode 会话并发上涨只扩 Decode 集群，不再需要整体扩容。对成本敏感的团队，这一条和抖动问题同样值钱。
图：每个指标观测的是链路上的一段，不是整个黑盒。
图：理解指标的第一步，是知道请求从哪走。
平均延迟好看，P99 为什么还是爆
有了链路视角，这个常见悖论就有了答案。
平均延迟是被大量短请求拉低的。真正决定用户口碑的是尾部：排队排到队尾的请求、撞上长 Prefill 头阻塞的 Decode、KV Cache 要跨节点迁移的会话。这些请求的延迟可能是平均值的十倍，但它们只占百分之几，对平均数贡献微乎其微，对用户伤害却实打实。
所以做容量规划和选型时，正确的盯法不是看均值，而是把 P99 拆到链路的每一段：排队占了多少、Prefill 占了多少、KV 迁移占了多少。哪一段长，优化哪一段——加调度策略、上 PD 分离、调合批粒度，各段的药方不一样。
同样的思路也能解释另一个常见困惑：QPS 明明很高，用户还是觉得慢。QPS 是系统吞吐，衡量的是单位时间处理完多少请求；用户感受到的是单条请求的等待。高并发恰恰可能意味着排队更深——请求在调度层积压，TTFT 被拉长，吞吐数字却越跑越好看。吞吐和延迟是两个方向的目标，合批能提吞吐，但每个请求的等待变长了。做对话产品要延迟优先，做离线批处理可以吞吐优先，混在一起谈就是鸡同鸭讲。
源势AI观点
我们给客户做推理部署时，有一条内部纪律：交付报告里不允许只写平均延迟。
原因很实际。能源、金融这些行业里，Agent 调用是长尾分布——大量短请求中间混着少量超长上下文的复杂任务，后者恰好是平均数掩盖、P99 暴露的那批。客户投诉的从来不是平均体验，是那几次转圈转到怀疑人生的请求。
对正在自建推理服务的团队，建议三件事：第一，监控先建链路分段计时，没有分段数据，一切优化都是猜；第二，选型对比时统一口径，先确认对方的 tokens/s 算的是输入还是输出；第三，长上下文业务认真评估 PD 分离，混合部署的抖动在 128K 以上的场景会被显著放大。
指标背得再熟，不如链路拆得清楚。指标体系搭起来之后还有一个附带好处：沟通成本降下来了。过去报障说"模型有点慢"，现在说"Prefill 段 P99 涨了 40%"，排查范围立刻收敛到一个阶段。对团队来说，一套共同语言比任何监控面板都先起作用。
图：五个核心指标各自的观测位置与使用场景。
