延迟分解是什么
端到端延迟不是一个数字，而是几段相加：排队等待、预处理与检索、首 token 生成、逐 token 输出、格式校验与后处理。不同环节的优化手段完全不同——排队久要扩容量或限流，首 token 慢多半与输入长度和缓存有关，逐 token 慢则看模型与批处理策略。不分解就只能笼统地说「模型变慢了」，然后改错地方。
基本信息
| 适用平台 | 自建推理或调用第三方 API 的在线服务 |
|---|---|
| 关键指标 | 排队时长、TTFT（首 token 延迟）、TPOT（每 token 耗时）、总时长 |
| 统计口径 | P50 / P95 / P99 分开看，另加超时率 |
| 埋点要求 | 各阶段打时间戳，能区分自有代码耗时与模型耗时 |
典型使用场景
- 体验优化：确认用户等待主要发生在哪一段
- 容量规划：判断瓶颈在并发排队还是在单请求生成
- 成本与性能权衡：换更大模型时评估对 TPOT 的影响
- 检索链路调优：区分检索耗时与生成耗时，避免误判
- 超时配置：按 P99 设定阈值，减少误杀与漏判
延迟指标分解
| 指标 | 含义 | 优化方向 |
|---|---|---|
| 排队时长 | 等待容量与调度的时间 | 扩容、限流、优先级队列 |
| TTFT | 从开始推理到首 token 返回 | 提示瘦身、预处理优化、缓存命中 |
| TPOT | 每个输出 token 的平均耗时 | 模型与批处理策略、输出精简 |
| 检索与工具 | 向量检索与外部调用耗时 | 缓存、并行调用、降 top_k |
| 校验收尾 | 格式检查与后处理 | 并行化、简化校验路径 |
埋点口径
埋点口径
# t0 请求进入
# t1 开始推理（排队结束、检索与预处理完成）
# t2 首 token 返回 TTFT = t2 - t1
# t3 生成结束 生成耗时 = t3 - t2，TPOT ≈ (t3 - t2) / 输出 token 数
# t4 校验与后处理完成 总时长 = t4 - t0，另记排队 = t1 - t0
# 统计：P50 / P95 / P99 分段报告；失败与超时请求单独统计
# 归因：区分「自有代码耗时」与「模型耗时」，避免把排队算进模型流式与非流式的观察重点不同：流式场景用户先看到首字，TTFT 决定感受；非流式场景用户要等完整结果，总时长更关键。报表要按调用方式分开统计。
检索与工具调用常被忽略：它们串行执行时会显著推高总时长。能并行的独立调用改为并行，往往比换模型见效更快。