从首 Token 到最后一个 Token大模型推理性能指标全景解析摘要TTFT、TPOT、ITL、TBT、E2E、QPS、TPS、P99、P95、P90 —— 这些词天天挂在嘴边但一问细节就乱。TTFT 包不包括排队TPOT 和 ITL 是不是一回事QPS 高为什么用户还觉得慢本文从一条推理请求的完整生命周期出发将 10 大核心指标放回请求真正走过的链路中给出定义、公式、量化参考、优化策略和排障路径帮你建立一张从用户体验到资源根因的完整观测地图。目录一、为什么推理指标总被讲乱二、一条推理请求到底经历了什么三、第一层用户体验指标TTFT / ITL / TBT / TPOT / E2E四、第二层吞吐与容量指标QPS / TPS五、第三层尾延迟指标P90 / P95 / P99六、第四层阶段拆解指标七、第五层资源与系统指标八、第六层分布式与网络指标九、第七层KV Cache 指标十、因果链排障四大典型场景十一、大模型推理性能指标全景图十二、各指标优化速查表十三、总结推理流程总览图一、为什么推理指标总被讲乱聊推理性能张口无非这几个词TTFT、TPOT、ITL、TBT、E2E、QPS、TPS、P99、P95、P90但一问细节往往就开始乱了TTFT 到底包不包括排队TPOT 和 ITL 是不是一回事QPS 高为什么用户还是觉得慢GPU 利用率很高为什么吞吐没上来平均延迟很好看为什么 P99 还是爆同样是 tokens/s到底是在说输出 token还是输入输出 tokenP90、P95、P99 到底看哪个它们之间是什么关系根本原因只有一个很多人把指标名词记住了但没有把指标放回请求真正走过的链路里去理解。核心认知TTFT、ITL、TPOT、TBT、E2E、QPS、TPS、P90、P95、P99并不是互相独立的名词。它们是同一条推理链路上不同位置、不同视角、不同粒度的观测指标——视角指标回答的问题用户体感TTFT, ITL, TBT, E2E用户多久看到开口说得顺不顺整段话何时说完系统吞吐QPS, TPS系统每秒能处理多少请求/Token尾延迟风险P90, P95, P99最差的那批用户正在经历什么阶段耗时TPOT, 排队, Prefill, Decode时间花在了哪一段资源利用GPU Util, KV Cache, Batch资源是否被有效转化为输出如果不先搞清楚指标在看哪一段链路就一定会越看越乱。二、一条推理请求到底经历了什么在讲指标之前先把链路搭起来。一个大模型推理请求大致会经历以下阶段用户发送 Prompt │ ▼ ┌──────────────┐ │ ① 请求接入 │ 鉴权 / 路由 / 限流 / 请求分类 └──────┬───────┘ ▼ ┌──────────────┐ │ ② 排队调度 │ 分配实例 / 合批 / KV Cache 命中判断 / P-D 分离调度 └──────┬───────┘ ▼ ┌──────────────┐ │ ③ Prefill │ Tokenize → Embedding → 多层前向 → Attention → 生成 KV Cache └──────┬───────┘ ▼ ┌──────────────┐ │ ④ KV Cache │ 命中复用 / 补齐 / 跨节点迁移 / 远端取回 └──────┬───────┘ ▼ ┌──────────────┐ │ ⑤ Decode │ 读 KV → 前向计算 → TP 通信 → 采样 → 返回 Token → 循环 └──────┬───────┘ ▼ ┌──────────────┐ │ ⑥ 请求完成 │ 最后一个 Token 输出 / 命中终止条件 └──────────────┘这条链路是后面所有指标的基础。因为几乎所有推理指标都能放到这个链路上找到自己的位置。关键认知推理性能问题不能脱离请求生命周期来谈。“首 Token 慢和后续 Token 慢”根本不是同一类问题。三、第一层用户体验指标这是业务方、产品方、用户最直观的一层。1. TTFT —— Time To First Token首 Token 时延定义从请求进入系统到第一个输出 Token 返回给用户所花费的时间。TTFT 接入耗时 排队耗时 调度耗时 Prefill 耗时 KV相关耗时 首次Decode耗时 返回耗时注意是第一个 Token返回给用户的时间不是整个回答完成也不是模型开始算的时间。量化参考场景优秀可接受需优化短 Prompt 128 tokens 200ms200~500ms 500ms中等 Prompt128~1024 tokens 500ms500ms~1s 1s长 Prompt1024~8192 tokens 1s1~3s 3s超长 Prompt 8192 tokens 3s3~8s 8s经验法则用户对 TTFT 的体感阈值约在300~500ms。超过 1s 用户会明显感到卡住了。TTFT 高的常见原因原因占比经验排查方法排队时间过长30~40%查队列深度、并发数Prefill 计算重长 Prompt25~35%查输入 token 数、Prefill 耗时KV Cache 未命中需重算10~20%查 KV hit rate调度延迟5~15%查调度器日志KV 跨节点迁移5~10%查迁移耗时P/D 分离架构网络/接入层 5%查网关延迟优化策略缩短排队增加副本数、优化调度策略、实施请求优先级加速 Prefill使用 Chunked Prefill、Prefix Caching、Prompt 压缩提升 KV 命中率前缀复用、KV Cache 池化、合理设置淘汰策略P/D 分离优化减少 KV 迁移距离、预取机制降低首次 Decode 开销优化 TP 通信、减少 kernel launch 开销2. ITL —— Inter-Token LatencyToken 间延迟定义两个相邻输出 Token 之间的时间间隔。ITL_i T(token_{i1}) - T(token_i)核心价值ITL 是最直接反映用户体验流畅度的指标。用户看到的流式输出顺不顺本质就是 ITL 是否稳定。ITL 小且稳定 → 用户觉得回答很流畅ITL 忽快忽慢 → 用户觉得模型在抽搐量化参考体感等级ITL 均值ITL 抖动max-min极流畅 30ms 10ms流畅30~50ms 20ms可接受50~100ms 50ms明显卡顿 100ms 50ms关键不只看平均 ITL还要看 ITL 的分布和抖动。平均 30ms 但偶尔冒到 200ms用户体验仍然差。ITL 抖动的常见来源某一轮 Decode 特别慢batch 重组、调度切换TP 通信出现长尾某个 rank 慢KV 读取延迟波动网络尾延迟冒出GC / runtime 抖动后台流量干扰热路径3. TBT —— Time Between TokensToken 间时间定义连续两个 Token 输出之间的时间间隔。TBT 与 ITL 的关系指标侧重点典型用法ITL强调相邻 Token 间隔的时间序列监控流式输出的实时体验TBT强调Token 间间隔的统计分布分析 Decode 阶段的稳定性工程建议ITL 和 TBT 在很多团队里混用。关键是团队内部统一口径否则一个人说瞬时间隔另一个人说平均值沟通成本极高。4. TPOT —— Time Per Output Token每输出 Token 平均耗时定义系统平均每输出一个 Token 所花费的时间。TPOT (E2E - TTFT) / (输出Token数 - 1) 或者更精确地 TPOT Σ(Decode单轮耗时) / 输出Token数TPOT 与 ITL/TBT 的区别指标本质粒度是否反映抖动ITL瞬时间隔逐 Token是TBT间隔分布逐 Token是TPOT统计平均整体均值否关键TPOT 是统计意义上的平均输出 Token 时间会掩盖抖动。所以不能只看 TPOT必须配合 ITL/TBT 的分布来看。量化参考模型规模优秀 TPOT可接受需优化7B单卡 20ms20~40ms 40ms13B单卡/双卡 TP 30ms30~60ms 60ms70B4~8卡 TP 50ms50~100ms 100ms175B多节点 TP 80ms80~150ms 150ms5. E2E —— End-to-End Latency端到端时延定义从请求进入系统到最后一个 Token 输出完成总共花费的时间。E2E TTFT (输出Token数 - 1) × TPOT 尾部处理时间 简化版 E2E ≈ TTFT 后续所有Token输出时间它直接回答用户从发起请求到看到完整答案一共等了多久E2E 的组成拆解E2E 接入时间 排队时间 Prefill时间 KV处理时间 (输出Token数 × 单轮Decode时间) 采样时间 返回时间各指标的层级关系┌─────────────────────────────────────────────────────┐ │ E2E Latency │ │ │ │ ┌──────────┐ ┌──────────────────────────────────┐ │ │ │ TTFT │ │ 后续 Token 输出时间 │ │ │ │ │ │ │ │ │ │ 接入排队 │ │ Token1 Token2 Token3 ... │ │ │ │ Prefill │ │ │ITL₁│ │ITL₂│ │ITL₃│ │ │ │ │ 首Decode│ │ │ │ │ │ │ │ │ │ │ └──────────┘ └──────────────────────────────────┘ │ │ │ │ TPOT 后续Token输出时间 / (输出Token数-1) │ └─────────────────────────────────────────────────────┘一句话总结指标回答的问题TTFT用户多久看到开始说话ITL / TBT系统说话顺不顺TPOT平均每个 Token 花多久E2E用户多久看到整段话说完四、第二层吞吐与容量指标如果说第一层更偏用户体验那么这一层更多是系统容量视角。1. QPS —— Queries Per Second每秒请求数定义系统每秒能完成的请求数量。QPS 完成请求数 / 统计时间窗口(秒)注意QPS 高不代表用户体验一定好。因为一个请求可能只输出 20 个 Token另一个可能输出 2000 个 TokenQPS 只看请求数量忽略请求长度差异高 QPS 可能是通过小请求堆出来的长请求场景下 QPS 可能骤降QPS 与其他指标的关系理论吞吐上限 ≈ QPS × 平均输出Token数 Output TPS 实际吞吐受限于GPU算力、显存容量、KV Cache空间、网络带宽、调度效率2. TPS —— Tokens Per Second每秒 Token 数定义系统每秒处理的 Token 数量。⚠️ 最容易口径不统一的指标必须明确口径定义业务含义Output TPS每秒输出多少 Token更接近用户感知的生成速度Total TPS每秒处理总 Token输入输出更接近系统整体负载能力Output TPS QPS × 平均输出Token数 Total TPS QPS × (平均输入Token数 平均输出Token数)关键在推理系统里更有业务意义的是Output TPS。Total TPS 更适合评估系统整体负载。报告 TPS 时必须标注口径。吞吐与延迟的权衡并发数和 Batch Size 是连接吞吐与延迟的关键参数参数提高时的效果副作用并发数 ↑GPU 利用率 ↑QPS ↑TPS ↑排队 ↑TTFT ↑P99 ↑KV Cache 压力 ↑Batch Size ↑GPU 利用率 ↑TPS ↑凑批等待 ↑TTFT ↑长短请求拖尾P99 ↑本质Batch 的本质是用延迟换吞吐。没有免费午餐。五、第三层尾延迟指标很多推理系统最大的问题不是平均慢而是偶尔很慢。为什么需要 P90 / P95 / P99假设 100 个请求中90 个都很快但有 10 个特别慢。平均值可能仍然好看但真实用户体验会很差。用户投诉从来不是因为平均值而是因为“怎么今天有些请求特别慢”“怎么有时候一直卡在首 Token”“怎么输出一半突然卡顿”这些问题本质都更接近尾延迟而不是均值。P90 / P95 / P99 / P999 的定义指标定义含义P9090% 的请求延迟低于此值每 10 个请求中有 1 个比这慢P9595% 的请求延迟低于此值每 20 个请求中有 1 个比这慢P9999% 的请求延迟低于此值每 100 个请求中有 1 个比这慢P99999.9% 的请求延迟低于此值每 1000 个请求中有 1 个比这慢直观示例假设有 100 个请求延迟从小到大排序延迟排序: [10ms, 12ms, 15ms, ..., 45ms, 48ms, 52ms, 180ms, 250ms, 500ms] ↑ ↑ ↑ P90 P95 P99平均值可能是 30ms很好看但 P90 52msP99 500msP99 是平均值的 16 倍——这就是为什么只看平均值会骗人P90 vs P95 vs P99到底看哪个指标适用场景特点P90用户体验下限评估、日常监控告警覆盖面广对大多数用户体验敏感P95SLA 制定、服务等级评估业界最常用的 SLA 指标P99极端用户体验、长尾问题排查对系统抖动最敏感适合发现问题P999大规模在线服务、高可用场景万分之一的极端情况工程建议日常监控同时关注 P90/P95/P99设置多级告警SLA 制定以 P95 或 P99 为准问题排查先看 P99 是否爆再看 P90/P95 是否同步恶化趋势分析关注 P99/P50 的比值健康值 3x需关注 5x严重 10x尾延迟的常见来源来源典型表现影响指标排队抖动高峰期 P99 骤升TTFT P99, E2E P99长请求拖住批次周期性卡顿ITL, TPOTKV Cache Miss随机性 TTFT 飙高TTFT P99KV 迁移慢P/D 分离下 TTFT 波动TTFTD 侧过载D 组 P99 上升E2E P99TP 通信长尾某轮 Decode 突然慢ITL P99某 Rank 慢周期性 ITL 抖动ITL网络 Incast多对一汇聚导致拥塞TTFT, ITLGC / Runtime 抖动不规则停顿所有指标后台流量干扰偶发性延迟冒泡ITL, TPOT尾延迟优化策略减少排队抖动请求优先级队列、公平调度、动态扩容隔离长短请求按请求长度分桶调度避免长请求拖住短请求提升 KV 命中率前缀缓存、热点路由、合理淘汰策略均衡负载D 侧副本均匀分配、避免热点网络优化RoCE 配置调优、PFC/ECN 合理设置、rail-aware 调度消除 GC 停顿减少对象分配、预分配内存池六、第四层阶段拆解指标知道 TTFT 高没用因为 TTFT 只是结果。必须拆开才能定位根因。TTFT 拆解TTFT 接入耗时 排队耗时 调度耗时 Prefill耗时 KV相关耗时 首次Decode耗时 返回耗时阶段典型耗时常见瓶颈接入1~10ms网关性能、鉴权开销排队0~数秒并发过高、副本不足调度1~50ms调度算法复杂度Prefill50ms~数秒Prompt 长度、算力KV 处理0~数百ms命中率、迁移距离首次 Decode10~100msTP 通信、采样返回1~10ms网络传输Decode 阶段拆解子阶段监控指标优化方向Decode 排队单轮等待时间减少批次重组频率前向计算单轮前向耗时FlashAttention、算子融合KV 读取KV 读取延迟KV Cache 布局优化TP/EP 通信NCCL collective 时间通信拓扑优化、overlap采样采样耗时采样算法优化发包返回发包延迟批量返回、流式优化七、第五层资源与系统指标1. GPU UtilizationGPU Util 告诉你 GPU 有没有在工作但不告诉你是在高效工作还是在低效地忙是在算 Prefill还是在等通信是在高吞吐合批还是在小批次频繁切换GPU 忙不等于系统快。2. 显存与 KV Cache 占用推理系统中显存不只是放权重还要放激活值、KV Cache、临时 buffer、batch 数据。显存组成典型占比影响模型权重40~60%固定开销KV Cache20~40%影响并发数、上下文长度激活值/Buffer5~15%影响 batch size临时/碎片5~10%影响稳定性3. Batch Fill RateBatch Fill Rate 实际Batch中的请求数 / 理论最大Batch SizeGPU 利用率不高很多时候不是算力不够而是调度没把 batch 填好。4. 更细粒度指标指标判断方向SM Utilization算力是否瓶颈Memory Bandwidth显存带宽是否瓶颈Attention/MatMul 耗时核心算子效率Kernel Launch 开销调度开销是否过大八、第六层分布式与网络指标在大模型推理里网络越来越关键。特别是多 GPU TP、Expert Parallel/MoE、P/D 分离、KV Cache 跨节点迁移。关键网络指标指标含义影响的推理指标TP Collective 时间多 GPU 通信耗时ITL, TPOT, P99NCCL 时间通信库耗时ITLSlow Rank最慢的 GPU rankITL P99KV Migration LatencyKV 跨节点迁移耗时TTFTECN Marked网络拥塞标记P99PFC Pause流控暂停ITL 抖动Queue Depth队列深度排队延迟D-side IncastD 侧汇聚压力TTFT, P99Rail Imbalance路径不均衡吞吐下降分布式推理里网络不是辅助角色它经常直接决定首 Token、后续 Token 和尾延迟。九、第七层KV Cache 指标KV Cache 已经不只是显存里的一个结构。它几乎决定了长上下文能力、TTFT、并发能力、显存压力、网络压力、P/D 分离效率。关键 KV Cache 指标指标定义影响KV Cache Hit Rate请求中可直接复用已有 KV 的比例命中率高 → TTFT 低、Prefill 压力小、吞吐高KV Cache 占用率显存中 KV 占比过高 → 并发下降、需淘汰/迁移KV Migration LatencyKV 跨节点迁移耗时P/D 分离架构下 TTFT 的关键拆项KV Eviction RateKV 被淘汰的频率过高 → 命中率下降、TTFT 波动KV Cache 命中率对 TTFT 的影响KV Hit RateTTFT 表现系统状态 80%显著降低前缀复用好系统健康50~80%正常有优化空间 50%明显升高需优化缓存策略 20%严重恶化Prefill 压力大需排查十、因果链排障四大典型场景场景 1用户说首 Token 很慢TTFT 是否高 ├── 是 → 拆解 TTFT │ ├── 排队高 → 并发是否过高副本是否不足 │ ├── Prefill 高 → Prompt 是否过长算力是否不足 │ ├── KV 相关高 → hit rate 是否下降migration 是否上升 │ └── 调度高 → 调度器是否异常P/D 分配是否不均 └── 否 → 检查网络接入层、客户端侧延迟场景 2用户说输出断断续续ITL 是否抖动 ├── 是 → 拆解 Decode │ ├── TP 通信有长尾 → 查 NCCL 日志、slow rank │ ├── Decode queue 升高 → 查批次重组频率 │ ├── D 侧过载 → 查 D 组负载均衡 │ ├── 网络 P99 上升 → 查 ECN/PFC、后台流量 │ └── 某轮 Decode 特别慢 → 查 KV 读取、采样耗时 └── 否 → 检查客户端流式解析场景 3运营说QPS 上不去GPU Util 是否低 ├── 是 → │ ├── Batch Fill Rate 低 → 调度器是否没凑好批 │ ├── 并发太小 → 是否限制过严 │ └── KV Cache 吃太多显存 → 并发上限被显存卡住 └── 否GPU 很忙但 QPS 低 → ├── TTFT 过高导致周转慢 → 请求占用时间长 ├── 请求输出太长 → 平均 E2E 长QPS 自然低 └── 调度效率低 → 频繁切换、碎片化场景 4监控说平均值还行但 P99 爆了P99 / P50 比值是否 5x ├── 是 → 尾延迟问题 │ ├── 队列抖动 → 高峰期并发波动 │ ├── 长请求拖尾 → 长短请求混批 │ ├── D 组过载 → 负载不均 │ ├── KV miss/migration 长尾 → 缓存策略问题 │ ├── TP 通信长尾 → slow rank │ └── 网络 Incast → 多对一汇聚 └── 否 → 检查 P90 是否也在恶化系统性变慢十一、大模型推理性能指标全景图┌─────────────────────────────────────────────────────────────────┐ │ 大模型推理性能指标全景图 │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ 第一层用户体验指标 │ │ ┌──────┬──────┬──────┬──────┬──────────┐ │ │ │ TTFT │ ITL │ TBT │ TPOT │ E2E │ │ │ └──────┴──────┴──────┴──────┴──────────┘ │ │ │ │ 第二层吞吐与容量指标 │ │ ┌──────┬──────────────┬──────────────┐ │ │ │ QPS │ Output TPS │ Total TPS │ │ │ └──────┴──────────────┴──────────────┘ │ │ ┌────────────┬──────────────┐ │ │ │ 并发数 │ Batch Size │ │ │ └────────────┴──────────────┘ │ │ │ │ 第三层尾延迟指标 │ │ ┌──────┬──────┬──────┬───────┐ │ │ │ P90 │ P95 │ P99 │ P999 │ │ │ └──────┴──────┴──────┴───────┘ │ │ │ │ 第四层阶段拆解指标 │ │ ┌────────┬────────┬──────────┬────────┬──────────┬──────────┐ │ │ │ 排队 │ 调度 │ Prefill │ KV处理 │ Decode │ 采样返回 │ │ │ └────────┴────────┴──────────┴────────┴──────────┴──────────┘ │ │ │ │ 第五层资源与系统指标 │ │ ┌─────────┬────────┬──────────┬─────────────┬───────────────┐ │ │ │ GPU Util│ SM Util│ 显存占用 │ KV Cache占用│ Batch Fill Rate│ │ │ └─────────┴────────┴──────────┴─────────────┴───────────────┘ │ │ │ │ 第六层分布式与网络指标 │ │ ┌──────────┬──────────┬──────────┬──────────────────────────┐ │ │ │ TP/NCCL │ Slow Rank│ KV迁移 │ ECN/CNP/PFC/Incast │ │ │ └──────────┴──────────┴──────────┴──────────────────────────┘ │ │ │ │ 第七层KV Cache 指标 │ │ ┌────────────┬──────────────┬──────────────┬────────────────┐ │ │ │ Hit Rate │ 占用率 │ Migration │ Eviction Rate │ │ │ └────────────┴──────────────┴──────────────┴────────────────┘ │ │ │ └─────────────────────────────────────────────────────────────────┘全景图的意义不是把名词堆在一起而是把它们放回系统里。所有指标都能找到位置所有问题都能找到路径所有路径都能继续拆因果。十二、各指标优化速查表延迟类指标优化指标优化方向具体手段TTFT缩短排队动态扩容、请求优先级、公平调度加速 PrefillChunked Prefill、Prefix Caching、Prompt 压缩提升 KV 命中前缀复用、KV 池化、合理淘汰策略优化 P/D 分离减少迁移距离、预取机制ITL稳定 Decode减少批次重组、固定 batch 调度消除通信长尾排查 slow rank、优化 TP 拓扑减少 KV 读取抖动KV 布局优化、减少 page faultTPOT加速单轮前向FlashAttention、算子融合、量化减少通信开销通信/计算 overlap、减少 TP 层数优化采样采样算法优化、投机解码E2E综合 TTFT TPOT以上所有手段控制输出长度max_tokens 合理设置吞吐类指标优化指标优化方向具体手段QPS提升周转效率降低 TTFT、控制 E2E优化调度合理 batch、动态并发控制资源扩容增加副本、弹性伸缩TPS提升 GPU 利用率增大 batch、连续批处理减少 KV 重复计算提升 hit rate、前缀缓存算力优化量化INT8/FP8、算子优化尾延迟优化指标优化方向具体手段P90日常性能优化以上所有延迟和吞吐优化P95消除系统性抖动负载均衡、调度优化P99消除极端长尾长短请求隔离、网络优化、GC 优化P999极端场景保障冗余部署、快速故障转移十三、总结之所以把推理指标越看越乱不是因为指标太多而是因为没有把它们放回同一条请求链路里。只要把请求链路搭清楚很多事就顺了TTFT不是玄学它是首 Token 之前那一长串事情的总和——排队、调度、Prefill、KV 处理、首次 Decode。ITL / TBT不是一个抽象缩写它就是用户看到的每一下卡不卡。TPOT是统计均值会掩盖抖动必须配合 ITL 分布来看。E2E是用户真正的等待时间等于 TTFT 后续所有 Token 输出时间。QPS 和 TPS不是越高越好它们必须放在并发、batch、TTFT、P99 的约束下看。P90/P95/P99是系统稳定性的 Canary——平均值回答整体大概怎么样尾延迟才回答最差那一批用户正在经历什么。GPU 利用率不是万能指标真正重要的是资源是否有效变成了用户可感知的输出速度。最终认知首 Token 性能看的是系统多久开口。后续 Token 性能看的是系统是否说得顺。尾延迟性能看的是系统最差的时候有多差。全链路推理性能分析看的是从用户体验到阶段耗时再到资源和网络根因能不能被一张图串起来。真正的推理性能分析不是背缩写而是建立一张从用户体验到资源根因的完整观测地图。如果本文对你有帮助欢迎点赞收藏。有问题欢迎评论区交流。