等待响应尚未发送
完整结果会直接出现在这条助手气泡里。
AI 与提示 · 安全与运营
延迟Latency
Latency 是一次 AI 请求从发出到首 token 或完整结果的端到端等待时间。拆成排队、首 token（TTFT）、生成（吞吐 × 个数）、网络四段，才能定位最大阶段、按 SLO 优化，并与成本 / 质量做有意识的权衡。它和 routing 的分工是：routing 决定发去哪，latency 度量这一路有多快。
一条客服消息为什么迟迟回不完整？沿同一请求拆段查
先认物：这是客服聊天 req-82a，用户正等两句退款摘要。先让慢路径真实超时，再把流式与精简上下文应用到这条消息，最后用同一请求复测；首字、完整回复和四段 trace 都长在聊天对象上。
场景：客服聊天 req-82a 要把退款工单总结成两句；SLO 是首字 ≤ 600 ms、完整回复 ≤ 2 s。请求不变，沿真实回复路径定位并复测。
待发送发现超时应用修复同条件复测
AC
在线Acme 客服助手退款队列 · req-82a
把退款工单总结成两句。
TRACEreq-82a
—排队—TTFT—生成—网络—
用户看到首字—
预算线首字 600 ms · 完整 2 s
待发送：真实用户在聊天窗口里等两句摘要。先跑一次慢路径，看“首字迟到”和“总耗时超时”分别长在哪一段。
判断法：先看用户何时看到首字，再看何时拿完整结果；把同一个 request id 拆成排队、TTFT、生成、网络，修最大阶段后用同一请求复测。
离开这页，只记这几条
上面的聊天已经把首字迟到、完整回复超时和同条件恢复演示过一遍；这里给四段路径命名，方便复述。
- 端到端 = 排队 + 首 token + 生成 + 网络
- 一次 AI 响应的延迟不是单一数字。排队（dispatcher/限流）、TTFT（prefill + 首字节）、生成（token/s × 个数）、网络（首/末 chunk）各有 owner，要分开量、分开优化。
- TTFT 决定“何时看到内容”
- 用户感知的“快”首先是首 token 出现的时间。长 prompt、大模型、冷启动都拉长 prefill，把 TTFT 推后；流式让用户在 TTFT 就读到内容，而不是等总耗时。
- 吞吐决定“生成段多长”
- 生成段 = 输出 token 数 ÷ 吞吐（token/s）。小模型吞吐高、生成快；批处理饱和 GPU 能抬高吞吐，但批越大排队等待也越长。
- 四个因子各动哪段
- 模型档位同时动 TTFT 和吞吐；prompt 长度动 prefill（TTFT）；批大小动吞吐和排队；流式只改“用户何时看到”，不改模型计算量。优化前先看最大阶段是谁。
- 与成本 / 质量权衡
- 强模型延迟更高、更贵，但质量更好；经济模型快而便宜，但能力下限低。延迟不是越低越好——要按场景定 SLO，再在质量、成本、错误率之间做有意识的取舍。
- 和 routing 的分工
- routing 决定一次请求发去哪个模型 / 工具 / 地域；latency 度量这一路有多快。先把路定对，再量快慢——给慢请求换更快的路（routing）和缩短某一段（latency 优化）是两件事。
什么时候要盯延迟，盯这些信号
出现下面这些情况，延迟值得单独拆开量；否则可能只是体感问题。
- 用户感到“卡”：首字迟迟不出 → 多半是 TTFT 超预期。先查 prefill（prompt 长度、模型大小、冷启动），再看排队。
- SLO 超预算：总耗时偶尔飙高 → 分场景、地域、模型版本切片 P95，找最大阶段，针对性优化而不是整体换大模型。
- 调成本或质量：换挡位时延迟会跟着动——经济模型快但可能掉质量，强模型慢且贵；延迟是三方权衡里的第三根轴。
- 不适合单独盯：离线批处理、无人等的后台任务——吞吐和成本比单次延迟更重要，不必卡 P95 TTFT。
怎么把一次延迟查清楚
从一条慢请求到可执行的优化，最短路径是这五步。
- 记 request id、模型/版本、queue、TTFT、token 速率、每个 tool span、network 和终止原因。
- 按场景、地域、模型版本切片 P50/P95 TTFT 和总耗时，不要只看平均值。
- 找 P95 中最大的阶段——排队、TTFT、生成还是网络。
- 针对最大阶段选手段：缩上下文 / 换小档（TTFT）、流式 / 提前返回（感知）、批 / 投机解码（吞吐）、并行工具 / 就近地域（网络与工具）。
- 优化后回看质量、成本、错误率和降级比例——延迟降了但质量塌了不算成功。
同一请求，差一个关键选择
都要给用户两句摘要。差别只在流式和模型档位的组合。
首 token 很快出现，用户在几百毫秒内开始读到摘要，整体在 SLO 内。质量足够回答“退款工单摘要”这类结构化任务，成本也低。感知快、可控。
为了“质量更好”默认上强模型还关掉流式：prefill 长、吞吐低，用户必须等到总耗时才看到任何内容，体感很慢，且单次成本翻倍。摘要这种任务用强模型是浪费，延迟和成本一起被拖垮。
快速自测
一条请求的 TTFT 是 320 ms（达标），但总耗时 2600 ms（超预算）。最大阶段是生成（token 输出），工具调用没超时。下一步先动哪个因子最合理？
继续查证
术语的技术定义和行为以这些一手或权威资料为准。
下一步学
和本知识点经常一起出现的概念。