延迟到底花在哪里：Latency Decomposition 与 TTFT

前置：Trace / Metrics；HTTP / Database / Queue 的运行时事实
核心问题：一次 Run 慢了 8 秒，怎样判断该优化 Model、Tool、DB、Queue 还是 Streaming，而不是只盯总耗时？

Run 8 秒中模型只占 2 秒，数据库排队 4 秒，则换更快模型只能改善很少。用户 1 秒看到首 token、10 秒结束；体验比 10 秒后一次性返回好，但后端仍占用约 10 秒。

Mental Model

text

Request → budget/routing → queue/pool/cache → model/tool I/O → measured latency/cost → capacity feedback

优化必须同时看 latency、throughput、cost、quality 和 downstream capacity；只追求并发或 cache hit 可能把瓶颈推到别处。

Latency Decomposition

把 total latency 拆成 queue、context/retrieval、TTFT、generation、tool、serialization；只有分段后才能知道真正瓶颈。

TTFT / Generation Time

一次模型调用至少可以拆成两个用户感受完全不同的阶段：

text

request ──等待──> first token ──持续生成──> complete
          TTFT                generation time

TTFT 高时用户觉得“系统没反应”，常与 provider queue、网络、prompt/context 处理有关；generation time 高则通常和输出长度、模型生成速度有关。

Streaming 可以让用户更早看到首个 token，所以改善感知延迟，但不会自动减少模型完成整段输出需要的总时间。

Model vs Tool Latency

Agent 往往交替等待模型和外部 Tool，瓶颈可能随任务变化。trace 应分别统计 model span 与 tool span，避免把所有慢都归因于 LLM。

模型与 Tool latency 分布不同：模型受 token/queue 影响，Tool 受网络/DB/第三方限制。并行化只能重叠无依赖部分，不能消除关键路径。

最小实现 / 数据结构

python

budget = RunBudget(deadline=deadline, max_cost=2.0, max_tokens=100_000)
model = router.select(task, budget)
async with capacity.acquire(model.provider):
    return await model.generate(request)

Failure Modes

只记录总 Latency 无法定位瓶颈

症状： queue、connect、TTFT、generation、Tool 全合成一个 duration。

为什么危险： 优化时无法判断模型慢还是排队/网络/Tool 慢。

处理： 拆分 latency spans/metrics，把 model/tool/queue/pool 关联同一 Run。

如何验证

Case	断言
只记录总 Latency 无法定位瓶颈	人为让 Tool 变慢，dashboard 能定位到 Tool span。

自测

TTFT 很高但 token generation 很快，与 TTFT 正常但总耗时很长，优化方向为什么不同？
把 queue wait、model latency、tool latency 合成一个 duration_ms 会失去哪些容量诊断能力？

延迟到底花在哪里：Latency Decomposition 与 TTFT ​

Mental Model ​

Latency Decomposition ​

TTFT / Generation Time ​

Model vs Tool Latency ​

最小实现 / 数据结构 ​

Failure Modes ​

只记录总 Latency 无法定位瓶颈 ​

如何验证 ​

自测 ​

Sources ​