什么是 TTFT，如何降低大模型首字延迟？｜字节跳动技术客户成功面经解析

60 秒回答模板

TTFT 可以理解为首字延迟，通常指请求开始后到客户端收到第一个生成 token 的时间。它由多段组成：客户端到服务端网络、网关鉴权、请求排队、检索和 Prompt 构造、模型 prefill、调度等待以及流式传输启动。降低 TTFT 不能只盯模型推理，要先分段埋点。常见优化包括减少 Prompt 长度和检索上下文、缓存系统 Prompt 与 KV、使用更快模型或 speculative decoding、预热实例、降低队列等待、按请求长度调度、启用流式输出、边检索边生成可行部分、优化网关和连接复用。要同时关注 TTFT、总时延、吞吐、成本和答案质量，避免为了首字快牺牲正确性。

考点 指标口径

难度 真实面经高频题

回答目标 讲清机制、边界和追问

深入解析

TTFT 的定义

TTFT 全称 Time To First Token，是大模型服务中衡量首个输出 token 到达速度的指标。不同团队的起点可能不同，有的从客户端发起请求算起，有的从服务端接收请求算起，因此指标口径必须统一。它不同于总生成耗时，TTFT 只关注第一个 token 之前的等待；用户在流式对话里通常先感受到 TTFT，再感受到后续 token 速度。

首字前发生了什么

第一个 token 出来之前，系统已经做了很多工作：请求经过 DNS、TLS、网关、鉴权和限流；应用层可能要做用户上下文加载、RAG 检索、重排、Prompt 拼接和安全检查；模型侧要排队、分配显存、做 prefill，把输入 prompt 编码成 KV cache，然后才能开始 decode 第一个 token。任何一段变慢都会抬高 TTFT。

模型侧优化

模型侧最大的影响通常来自 prefill 和排队。Prompt 越长，prefill 计算越重；并发越高，调度等待越明显。优化方式包括减少上下文长度、裁剪无关历史、对稳定前缀做 KV cache、按输入长度分桶调度、连续批处理、模型量化、选择更合适的小模型、预热实例和减少冷启动。对于可接受轻微复杂度的场景，还可以探索推测解码或草稿模型降低首个 token 等待。

应用侧优化

应用侧往往也有很大空间。RAG 检索要控制召回数量、重排耗时和上下文拼接长度；用户画像、权限和配置应尽量缓存；网关要复用连接并减少串行依赖；流式响应要尽早 flush，避免中间层缓冲。对于复杂 Agent，不能等所有工具都完成后才响应，可以先返回状态 token 或把可并行步骤并发化，但前提是不会误导用户。

观测与取舍

降低 TTFT 必须先把链路分段观测清楚，包括网络、网关、应用、检索、排队、prefill、decode 首 token 和客户端渲染。优化时要看 p50、p95、p99，而不是只看平均值。过度缩短 Prompt 可能伤害答案质量，过小 batch 可能降低吞吐并增加成本，过早输出可能带来错误承诺。成熟方案会在用户体验、质量、吞吐和成本之间做可量化权衡。

易错点

把 TTFT 等同于完整回答耗时，忽略它只关注首个 token 前的等待。
只从模型参数入手优化，没有统计网关、RAG、排队和客户端缓冲。
为了减少首字延迟粗暴删除上下文，导致答案正确性和可追溯性下降。
只看平均 TTFT，不看 p95 和 p99，无法发现队列拥塞和冷启动问题。

面试官追问

TTFT 和 TPOT 有什么区别？

TTFT 衡量第一个 token 到达前的等待，TPOT 通常衡量后续每个 token 的平均生成时间。前者影响响应是否立刻开始，后者影响持续输出是否顺滑。

为什么长 Prompt 会增加 TTFT？

因为模型需要先对输入做 prefill，计算每个输入 token 的表示并建立 KV cache。输入越长，首个输出 token 前的计算量越大。

启用流式输出一定能降低服务端 TTFT 吗？

不一定。流式输出主要减少客户端等待完整答案的时间，并确保首个 token 生成后尽快发送。模型 prefill 和排队时间仍然存在。

优化 TTFT 最先做什么？

先统一指标口径并分段埋点，确认瓶颈在检索、排队、prefill、网络还是客户端渲染。没有分段数据时很容易误判。