什么是 延迟（Latency）？
延迟（Latency）是 AI 系统中两个明确事件之间经过的墙钟时间，例如客户端发起请求到收到首个内容 Token、最终响应或完整工具结果。
工作原理
先定义测量边界
采集前必须命名时钟、开始事件与终止事件。单进程内使用 Monotonic Clock；分布式 Span 要么同步时钟，要么在各 Hop 本地计算 Duration。分别记录 Client、Gateway、Queue、Prefill、Decode、Retrieval、Tool 与 Network 区间。多个阶段可能重叠，只有 Trace 证明它们顺序执行时才能直接相加。成功、失败、超时、取消和截断请求都应保留，不能静默删除较慢结果。
定位真正阶段
TTFT 变高可能来自 Queue、冷模型加载、长输入 Prefill、Cache Miss 或网络；TPOT/ITL 变高通常指向 Decode 调度、显存带宽、增长中的 KV Cache、Preemption 或过载 Batch。模型指标正常但端到端延迟升高时，还应检查输出长度、检索、Tool 与后处理。[NVIDIA 指标文档](https://docs.nvidia.com/nim/benchmarking/llm/1.0.0/metrics.html)也明确指出，不同 Benchmark Tool 的事件和聚合口径并不一致，指标同名不代表结果可直接比较。
把分位数转为 SLO
应从请求级样本计算 Percentile，或合并兼容的 Histogram Bucket，不能平均多个 Replica 的 p95。先按工作负载形态和版本切片，再提高 Offered Load，直到尾延迟或错误超出目标。SLO 必须声明 Eligible Request Population、指标边界、分位数、阈值与评估窗口；同时使用 Goodput，避免某个配置通过牺牲延迟、正确性、质量或安全门禁来获得更高流量后仍被误判为更快。
主要特点
- 只有声明开始、结束、时钟与请求集合后才具有可比意义
- 区分客户端感知、服务端、Queue、Prefill、Decode 与依赖边界
- 需要 p50、p95、p99 等请求级分布，不能只看平均值
- 会随输入输出长度、Cache、到达形态、并发与失败状态变化
- 可能在聚合吞吐上升时恶化，因为批处理与排队会用等待换容量
- 与 SLO Goodput 和 Trace 证据结合后才能支持生产决策
常见用途
- 为流式助手分别设置 TTFT、TPOT 与端到端目标
- 定位回退来自 Queue、Prefill、Decode、Retrieval 还是 Tool
- 在相同模型、工作负载与 Offered Load 下比较服务配置
- 按尾延迟与 Goodput 而非平均响应时间规划容量
- 在扩大流量前验证 Canary、自动扩缩容与超时策略
示例
Loading code...常见问题
TTFT、TPOT 与端到端延迟有什么区别？
TTFT 在首个内容 Token 到达时结束；TPOT 按声明口径平均首 Token 之后的生成间隔；端到端延迟在最终可用响应到达时结束。三者回答的是不同体验与系统问题。
为什么 LLM 延迟不能只报告平均值？
平均值可能保持稳定，但少数请求正在经历长 Queue、Retry、Cold Start 或下游阻塞。尾部分位数能暴露这些体验，但仍需同时声明请求集合、统计窗口和结果处理规则。
服务端延迟可以直接与浏览器延迟比较吗？
不可以。服务端计时可能不包含客户端网络、Gateway、建连与渲染。只有开始和结束事件一致时才能直接比较，否则应通过分布式 Trace 分别保留各段边界。
取消、失败和超时请求应如何计入延迟报告？
应把它们作为独立结果报告，并在可靠性或 Goodput 中纳入尝试请求分母。删除这些样本会让过载系统看起来比实际更快。
平均延迟下降能证明服务配置更好吗？
不能。还要在相同工作负载和 Offered Load 下检查尾延迟、错误、Goodput、输出质量、安全与成本。拒绝困难请求、缩短输出或把工作移出测量边界都可能制造虚假改善。