TTFT：首 Token 延迟定义、原理与应用场景
TTFT 是从请求或 prompt 输入到首个 token 返回的首 Token 延迟。它受 Prefill、排队和调度影响，理解 TTFT 与每 Token 延迟区别，有助于评估聊天机器人响应体验。
什么是 TTFT？
TTFT 是 Time To First Token 的缩写，中文常称为首 Token 延迟或首 Token 时间。它衡量从请求发出、请求到达，或用户输入 prompt 开始，到模型生成或返回第一个输出 token 所花费的时间。
在大模型推理中，TTFT 关注的是用户看到第一个响应前的等待时间，而不是完整回答全部生成完成的总耗时。对于支持流式输出的对话应用来说，TTFT 往往决定了用户是否感觉“系统已经开始回应”。
要点： TTFT 看的是“第一个 token 什么时候出现”，不是“整段回答什么时候结束”。
可以把一次模型回复理解为两段体验：第一段是用户提交问题后等待第一个字出现；第二段是第一个字出现后，内容继续流式输出。TTFT 主要描述第一段。
用一次对话理解首 Token 延迟
假设用户在聊天机器人中发送了一个问题。点击发送后，界面可能会短暂停顿，随后开始出现第一个字、词或 token。这个从发送问题到首个输出出现之前的等待区间，就是 TTFT 所关心的体验区间。
较低的 TTFT 会让应用感觉响应更迅速，尤其是在聊天机器人、智能客服、对话助手等交互式应用中。即使完整回答还需要继续生成，只要首个 token 较快出现，用户通常会更容易判断系统已经收到请求并正在处理。
但 TTFT 不能等同于完整回复时间。完整回复还会受到首个 token 之后连续输出速度的影响，也就是后续每 Token 延迟或类似指标所描述的部分。
| 对话阶段 | 用户看到的现象 | 主要相关指标 |
|---|---|---|
| 发送问题后到首个输出前 | 界面等待，尚未出现回答内容 | TTFT |
| 首个输出出现后 | 回答逐步流式展开 | 每 Token 延迟、输出速度 |
| 全部内容生成完成 | 用户拿到完整答案 | 总完成时间 |
TTFT 与每 Token 延迟有什么区别？
TTFT 与每 Token 延迟都属于大模型推理延迟相关指标，但它们衡量的是不同阶段。TTFT 衡量首个 token 出现前的等待；每 Token 延迟则关注首个 token 之后继续生成 token 的速度，通常不包含首个 token 本身。
| 指标 | 衡量对象 | 关注阶段 | 典型判断方式 |
|---|---|---|---|
| TTFT | 从请求或 prompt 输入到首个 token 生成或返回的时间 | 首个 token 出现前 | 用户是否很久才看到第一个字 |
| 每 Token 延迟 | 首个 token 之后，后续 token 连续输出的延迟 | 流式输出过程中 | 首字已出现，但后续内容是否输出很慢 |
如果用户等待很久才看到第一个字，应优先关注 TTFT。如果第一个字很快出现，但后续回答断断续续、输出缓慢，则更应关注首个 token 之后的生成速度。
要点： TTFT 和每 Token 延迟不能简单混为一个指标。前者描述“开始响应有多快”，后者描述“开始后输出有多顺”。
TTFT 的主要耗时来自哪些环节？
一次请求进入大模型推理系统后，首个 token 返回前通常会经历多个环节。不同系统的实现细节可能不同，但评估 TTFT 时可以重点关注以下几类耗时来源。
排队与调度
请求进入推理服务后，可能需要等待系统调度计算资源。如果并发请求较多，或者服务端存在批处理、队列管理等机制，排队和调度都可能计入端到端 TTFT。
这意味着用户感知到的 TTFT 不一定只是模型本身的计算时间，也可能包含请求链路中的等待时间。
Prefill 阶段
Prefill 阶段会对整段输入 prompt 进行一次性前向计算，是 TTFT 的核心耗时来源之一。输入内容越需要被模型处理，首个 token 出现前的计算压力通常越值得关注。
在分析 TTFT 时，Prefill 阶段尤其重要，因为模型需要先处理已有上下文，才能进入生成首个输出 token 的过程。
首个 token 生成与返回
完成输入处理后，模型生成第一个输出 token，并通过服务链路返回给调用方或前端界面。这个过程与模型推理、服务通信和返回路径有关。
对于流式输出应用来说，首个 token 一旦返回，用户就会感知到响应已经开始。
硬件性能与注意力机制等因素
硬件性能、注意力机制以及输入内容处理规模都会影响首个 token 返回前的时间。由于不同模型、框架和部署环境差异较大，评估时不宜脱离具体系统给出固定阈值。
| 耗时来源 | 对 TTFT 的影响 | 评估时应关注什么 |
|---|---|---|
| 排队 | 请求尚未开始实际推理 | 并发压力、队列等待 |
| 调度 | 系统分配计算资源和执行计划 | 调度策略、资源可用性 |
| Prefill 阶段 | 对整段 prompt 做前向计算 | 输入长度、上下文处理压力 |
| 首个 token 返回 | 生成并传回第一个输出 | 端到端链路是否顺畅 |
| 硬件与模型机制 | 影响计算效率 | 部署环境、模型结构相关因素 |
哪些场景更需要关注 TTFT？
TTFT 对交互式应用尤其重要，因为用户会直接感知“系统是否立刻有反应”。聊天机器人、智能客服、对话助手等产品通常需要重点关注 TTFT。
| 场景 | 用户需求 | 解决方式 | 效果 |
|---|---|---|---|
| 聊天机器人 | 发送问题后尽快看到回应 | 降低首个 token 前的等待时间 | 应用显得响应更快 |
| 智能客服 | 用户希望确认问题已被处理 | 优化请求排队、调度和首 token 返回链路 | 改善即时反馈感 |
| 对话助手 | 多轮交互中保持流畅 | 同时关注 TTFT 与后续输出速度 | 减少对话停顿感 |
| 长文本生成 | 希望尽快确认任务已开始 | 让首个 token 尽早返回，并继续关注后续生成 | 提升任务启动感，但仍需看完整耗时 |
在报告撰写、长文生成、批量内容生成等场景中，TTFT 仍有意义，但不能单独决定体验。用户不仅关心第一个 token 何时出现，也关心完整内容何时生成完毕，以及生成过程中是否稳定。
评估 TTFT 时应避免的误区
不要只看 TTFT 判断整体推理性能
TTFT 只能说明首个 token 返回前的延迟。整体推理体验还需要结合后续 token 延迟、输出速度、吞吐量以及完整任务耗时一起判断。
如果 TTFT 很低，但后续输出很慢，用户仍可能觉得回答过程拖沓。相反，如果完整生成速度很快，但首个 token 等待过久，交互式体验也可能不理想。
不要把模型纯计算时间等同于端到端 TTFT
端到端 TTFT 可能包含请求排队、系统调度、Prefill 阶段、首个 token 生成和返回等多个环节。只看模型生成首 token 的纯计算时间，可能低估用户真实等待时间。
在实际监控和排查中，应尽量区分服务链路等待与模型计算本身，避免把所有延迟都归因于模型能力。
不要脱离应用类型比较 TTFT
不同应用对 TTFT 的敏感度不同。聊天机器人和智能客服通常更关注首个响应是否及时；离线批量生成或长文本任务则可能更关注总完成时间和资源效率。
因此，比较 TTFT 时应结合业务场景，而不是简单认为某个数值在所有应用中都同样重要。
不要把 TTFT 与每 Token 延迟混用
TTFT 描述首个 token 前的等待，每 Token 延迟描述首个 token 之后的连续输出速度。两者共同影响流式生成体验，但它们指向不同的优化方向。
评估时可以先判断问题发生在哪个阶段：是“迟迟不开始”，还是“开始后输出慢”。这样更容易定位 TTFT、Prefill、排队调度或后续生成速度等不同问题。