转写说明
本文基于已校验的公开原文进行结构化转写与事实梳理,非原文转载。 转写保留可核验的技术事实,并将工程建议与来源观点明确分开。
- 原作者: 周末程序猿
- 原始来源: https://juejin.cn/post/7672996833275494410
- 原文发布时间: Wed, 12 Aug 2026 14:48:59 GMT
核心结论
大模型推理系统的评估需要从用户体感与系统产能两个维度同时度量。六个核心指标分别对应推理链路上的不同阶段:TTFT 衡量首字响应速度,ITL/TPOT 衡量吐字流畅度,Time To Publish 衡量用户真正可见的首字延迟,Total Latency 衡量完整回复耗时,Throughput 衡量系统总工作量,Goodput 衡量落在 SLO 内的有效工作量。Prefill 阶段受计算密度支配,Decode 阶段受显存带宽支配,两者的瓶颈特性决定了优化策略的方向差异。吞吐与延迟存在经典权衡,单纯追求 Throughput 可能以牺牲 Goodput 为代价;一个合格的推理系统应以满足延迟约束为前提最大化 Goodput。
能力机制
TTFT 由排队时延、Prefill 前向耗时和首 token 采样三部分构成,其中 Prefill 阶段需要为完整 prompt 序列计算 Q/K/V 并完成全量 Attention 操作。Attention 计算复杂度随序列长度呈平方级增长,模型参数量和层数直接影响每次前向的计算量。在 Continuous Batching 场景下,Decode 阶段占满 GPU 时新请求的 Prefill 可能被延迟调度;Prefill 与 Decode 同卡混跑时存在资源竞争关系。Tensor Parallel 引入的 AllReduce 通信开销若分配不合理会侵蚀算力收益。
ITL/TPOT 描述 Decode 阶段两个连续输出 token 之间的时间间隔。每次 Decode 只需为当前 token 计算 Q/K/V,但 Attention 必须读取完整历史 KV Cache。Decode 属于内存带宽密集型操作,HBM 带宽而非算力成为主要瓶颈。KV Cache 随序列长度线性增长,并发 batch 中多个序列同时读取 KV 会加剧带宽竞争。MHA 架构的 KV head 数最多,GQA/MQA/MLA 通过减少需读取的 KV 字节数来降低带宽压力。
Total Latency 是 TTFT 与 TPOT 的线性组合,公式为 TTFT 加上 TPOT 乘以输出 token 数减一。输出长度越长,Decode 循环在总耗时中的占比越高。Time To Publish 与 TTFT 的差异在于模型可能先生成不可见的中间 token(如思维链、工具调用),用户感知到的首字时间点与模型内部 TTFT 不一致。
Throughput 衡量单位时间完成的工作量,口径需明确区分为每秒请求数或每秒输出 token 数。瓶颈集中在权重与 KV Cache 的 HBM 复用效率、Attention/FFN 的 batch 利用率,以及 KV Cache 能容纳的并发序列数。Continuous Batching 按迭代粒度调度,相比静态 batch 可显著减少 GPU 空泡。PagedAttention 通过消除 KV 显存预留浪费提升有效并发。
Goodput 定义为满足预设 SLO 约束的每秒有效请求数。假设系统处理 100 请求/秒,其中 80 请求满足延迟约束,则 Throughput 为 100,Goodput 为 80。Goodput 受到延迟长尾分布形态、过载导致的全面恶化、以及激进 batch 策略抬高延迟的共同影响。
快速开始
定义推理服务的延迟 SLO,例如:TTFT 不超过 2 秒,TPOT 不超过 50 毫秒,Total Latency 不超过 3 秒。在压测阶段同时采集 TTFT、ITL、Total Latency 的 p50 与 p99 分位数,用于评估长尾表现。计算 Goodput 时使用满足全部三项约束的请求占比乘以总 Throughput。若观察到 Goodput 显著低于 Throughput,表明存在过量请求超出延迟目标,需调整 batch 配置或扩容。监控队列长度与 TTFT 的相关性,当队列积压导致 TTFT 持续上升时应触发准入控制。
适用边界
TTFT 适用于评估 Prompt 密集型场景(如长上下文补全、RAG 检索增强)的响应表现,对短 prompt 场景参考价值相对有限。ITL/TPOT 更适合评估长输出场景(如代码生成、长文写作)的流畅度,短回复场景下该指标对用户体验影响较小。Time To Publish 与产品形态强相关,适用于包含思维链、工具调用或多阶段推理的模型评估。Total Latency 作为端到端指标适用于服务等级协议制定,但需结合流式输出来改善用户实际感知。Throughput 适用于容量规划与成本评估,但不反映用户体验质量。Goodput 适用于存在明确 SLO 约束的在线服务评估,离线批处理场景下重要性相对较低。
指标间的权衡需结合业务优先级:交互式应用优先保障 TTFT 与 Time To Publish,批量生成任务可容忍较高延迟以换取 Throughput,高并发服务需以 Goodput 作为核心优化目标而非单纯追求 Throughput。
核验清单
确认 TTFT 监控是否区分了排队等待、Prefill 执行和首 token 采样三个子阶段的时间占比。确认 ITL/TPOT 监控是否关联了当前上下文长度和并发 batch 大小,以便定位带宽争用。确认是否同时采集模型内部 TTFT 与面向用户的 Time To Publish,两者差异过大时需排查中间 token 处理逻辑。确认 Total Latency 监控是否包含网关转发和重试开销,而非仅统计 GPU 内核耗时。确认 Throughput 统计口径是否为所需类型(请求级或 token 级),避免不同口径的混淆。确认 Goodput 计算使用的 SLO 阈值与业务承诺一致,且覆盖了 TTFT、TPOT 和 Total Latency 三项约束。确认是否存在只优化 Throughput 而导致 Goodput 下降的情况,特别是在激进 batch 配置下。确认是否针对延迟长尾(p99)设置了独立的 SLO 目标和告警阈值。
来源与核验
- 原始文章
- 页面事实以原始来源及其引用的官方资料为准;版本、星标和模型能力会随时间变化。
- AI Stack 不公开抓取到的全文快照,只发布独立转写与来源入口。