首token延迟-大模型多久才开始回答

Table of Contents

使用大模型时，我们对“快”通常有两种感受：一种是问题发出后，第一个字多久出现；另一种是开始回答后，后面的文字生成得是否流畅。

这很像与人对话：你问完问题后，对方可能会先停顿一下，然后才开口。TTFT（Time to First Token，首 token 延迟）衡量的就是这段“开口前的等待”。我们可以从三个方面把它说清楚。

一、什么是 TTFT（Time to First Token）？

大模型不是一次性写完答案的。它会先用分词器把文本转换成 token，再一个接一个地生成输出。Token 不一定等于一个字：它可能是一个汉字、英文单词的一部分，也可能包含标点或多个字符。

不同模型使用的分词器可能不同，同一句话未必会被切成相同数量的 token。因此，token 是模型内部处理文本的基本单位，不是一个固定的“字数”单位。

TTFT 表示从请求开始，到第一个输出 token 可用所经过的时间。从客户端测量时，通常可以近似写成：

客户端 TTFT ≈ 收到首个非空生成内容的时间 − 发出请求的时间

之所以说“近似”，是因为客户端收到的是流式事件，它不一定与模型内部的 token 一一对应。有些初始事件只包含角色或元数据，并没有用户能看到的内容。

TTFT 也不等于模型的整体速度。可以把几个常见指标记成一句话：

一个模型可以很快说出第一个字，后面却生成得很慢。所以 TTFT 只回答“多久开始”，不回答“多久完成”，更不衡量答案是否正确。

例如，模型 A 可能在半秒后开始回答，却需要很久才写完；模型 B 可能两秒后才开始，但后续生成得更快。对短回复来说，A 的体验可能更好；对长文章来说，B 反而可能更早完成。

以客户端端到端口径来看，在第一个 token 出现前，请求需要经过一条完整的链路。TTFT 不是某一步单独产生的延迟，而是这些等待叠加后的结果：

请求上行 → 请求预处理与排队 → Prefill → 首 token 下行

这是为了便于理解而做的简化。不同服务会以不同顺序完成鉴权、分词、排队和调度，各家基准工具的计时起点也可能不同。

网络传输（Network Latency）：请求需要从客户端到达服务端，首个有效输出也要再传回客户端。网络距离、拥塞、网关和代理都可能带来额外等待。
请求预处理（Request Preprocessing）：服务端需要解析请求，并用分词器把 prompt 转换成模型可处理的 token；具体耗时取决于服务实现和输入。
排队等待（Queueing Time）：当大量请求同时到达时，新请求可能要等待计算资源或服务调度。这时 TTFT 会上升，却不一定是模型本身变慢了。
预填充阶段（Prefill Phase）：模型并行处理全部输入 token，建立后续生成所需的中间状态（通常包括 KV cache），并计算首个输出 token。这一阶段通常偏计算密集，输入越长，工作量通常越大。

这里的“输入”不只是用户刚输入的一句话。在聊天、知识库问答或 Agent 中，一个看似简单的问题，背后可能带着很长的对话记录、检索文档和工具说明。用户看到的问题很短，不代表模型实际需要处理的上下文也很短。

首 token 产生后，模型才进入 Decode（解码）阶段，根据已有上下文逐个生成后续 token。TTFT 到此已经结束，后面的快慢则属于生成速度。这也是 TTFT 与“整段答案生成多快”最根本的区别。

但长输入不是唯一原因。模型规模与架构、硬件、推理引擎、冷启动、缓存命中和网络距离都会改变结果。对推理模型来说，最终回答前的额外计算也可能增加第一个可见内容的等待时间。

因此，客户端测到的 TTFT 是整条服务链路的结果，不能直接当作 GPU 或模型的计算耗时。

降低 TTFT 的关键，是减少首 token 出现前的无效等待。上一节将 TTFT 拆成了几个部分，优化也可以沿着同一条链路进行。

减少不必要的输入：过长的 system prompt、不断累积的历史对话，以及与问题关系不大的检索资料，都会增加 Prefill 的工作量。在不丢失关键信息的前提下摘要旧对话、只保留相关内容，通常比盲目扩大上下文更有效。
利用 Prompt Cache（提示缓存）：如果多次请求共享相同的提示前缀，例如固定的系统提示、工具定义或公共资料，在服务支持且缓存命中时，可以减少重复的输入处理。
减少排队和无效调度：当并发请求超过系统能力时，即使单次模型计算很快，TTFT 也会因等待资源而上升。更合理的请求调度和批处理，可以在响应速度与系统吞吐量之间取得平衡。
选择适合任务的模型：更大的模型或需要额外计算的推理模型，不一定适合所有任务。对简单、强交互的问题，较小或更快的模型可能带来更好的体验；对复杂推理，则可能需要接受更长的等待。

流式输出也很重要，但需要分清它优化的是什么。它能把已经生成的内容尽早显示给用户，避免等到完整答案生成后才一次性出现；但它不会缩短模型产出首 token 所需的计算时间。与非流式返回相比，它主要让已生成内容更早对用户可见。

最后，TTFT 越低不代表模型越好。它只衡量开始输出的速度，不衡量答案是否正确。真正的体验还要同时考虑后续生成速度、完整答案所需的时间和答案质量。