什么是 首 Token 延迟（TTFT）？
首 Token 延迟（TTFT）是客户端发送流式 LLM 请求后，到收到首个非空输出 Token 或包含 Token 的 Chunk 之间的耗时。
快速了解
| 全称 | Time to First Token |
|---|---|
| 规范文档 | 官方规范 |
工作原理
先分解再优化
高 TTFT 可能来自网络与网关、Cold Model 或 Adapter、队列饱和、分词与多模态预处理、未缓存 Prefill、Cache Lookup 或 Transfer，以及首输出回传。[vLLM 指标设计](https://docs.vllm.ai/en/stable/design/metrics/)暴露 Queue、Prefill 与首输出事件，可用于拆解区间。应在可信边界采集时间戳，并关联 Prompt Token、Cached Token、Queue Depth、Model Residency 与错误。缩短 Prompt 无法解决队列饱和，Prefix Cache 也无法解决 Cold Worker 或慢客户端网络。
报告分布而非单值
应针对明确的流量分布报告 p50、p95 与 p99 TTFT，而不是只给平均值或最快一次。[AIPerf 指标参考](https://docs.nvidia.com/aiperf/reference/ai-perf-metrics-reference)从请求开始到首个非空响应定义 TTFT，并把它保留为请求级分布。还要记录输入长度分桶、Cache Hit 状态、并发、到达模式、地域、模型与 Runtime 修订版、硬件和成功标准。Cold Start 与 Steady State、失败或中止请求与成功响应应分开。Closed-loop Load 可能隐藏真实到达请求的等待时间，因此也要说明 Load 生成方式。
与其他指标组合
TTFT 只覆盖响应启动。还应结合 ITL 或 TPOT 判断流式节奏，结合端到端延迟判断完成时间，并记录输出长度、错误、质量和系统吞吐。服务可能通过优先短 Prompt 降低 TTFT，却让长请求饥饿；也可能通过大 Batch 提高吞吐，却延迟单个请求。Goodput 只统计同时满足质量与延迟契约的请求。
主要特点
- 从声明的客户端或服务端请求事件开始，到首个非空输出结束
- 除非明确使用引擎内部事件，否则范围大于 Prefill Latency
- 依赖流式返回；非流式响应通常只能观测完成延迟
- 会随排队、冷启动、输入长度、Cache Hit、路由与网络路径变化
- 应按工作负载和缓存状态分组并报告分位数
- 不能描述首 Token 后的节奏、答案质量或系统容量
常见用途
- 为交互式聊天、编程或搜索设置响应启动 SLO
- 区分队列饱和与长 Prompt Prefill
- 比较 Warm、Cold 与 Prefix Cache Hit 行为
- 发现路由、批处理、模型或硬件变更后的回退
- 验证更快首响是否仍保持公平性与答案质量
示例
Loading code...常见问题
TTFT 与 Prefill Latency 相同吗？
不同。Prefill Latency 是引擎阶段；客户端 TTFT 还可能包含传输、鉴权、准入、排队、预处理、分词、首个输出模型步骤与结果回传。只有事件边界一致时，数值才可比较。
TTFT 对非流式响应有意义吗？
通常不能作为独立用户可见指标，因为客户端只在生成完成后收到响应。服务端可能暴露内部首 Token 时间戳，但它不等于流式客户端观测到的 TTFT，必须单独标记。
怎样的 TTFT 才算好？
没有通用阈值。应根据产品交互和风险设定 SLO，再覆盖代表性输入长度、缓存状态、地域和负载进行测量；报告尾延迟和合格任务质量，而不是套用一个固定数字。
为什么 TTFT 上升但 Decode 速度不变？
排队、模型冷启动、更长的未缓存 Prompt、更慢的预处理或 KV 传输，都可能推迟首个输出而不改变稳定 Decode。优化模型或调度器前应先拆分这些区间。
低 TTFT 能证明 LLM 服务很快吗？
不能。它只证明在测量条件下输出开始得快。后续流可能仍有高 ITL、较长完成时间、错误、截断、低质量或低聚合吞吐。生产决策需要完整指标卡。