大模型推理为什么存在首 Token 延迟，TTFT 背后的计算过程究竟是什么

【中国观察2026年08月26日】
用户向 ChatGPT、Claude 或其他大语言模型发送一句话后，通常不会马上看到完整答案。系统往往需要等待一段时间，随后才出现第一个 Token，接下来文字生成速度明显加快。这段从请求进入推理服务到首个输出 Token 被生成并返回的时间，就是 TTFT，也就是 Time to First Token。

TTFT 是在线大模型服务非常重要的性能指标，因为它直接决定用户感觉系统“有没有反应”。如果首 Token 等待两三秒，即使后续每秒可以生成几十个 Token，用户仍然会感觉系统响应迟缓。

理解 TTFT，首先需要把一个容易混淆的问题分开：模型加载时间和请求级 TTFT 并不是一回事。

在一个已经运行的大模型服务中，模型权重通常早已加载到 GPU 显存，服务会持续等待新的请求。因此正常情况下，用户发送一条 prompt 时，并不会重新把几十 GB 甚至几百 GB 的模型权重从 SSD 读取到 GPU。模型冷启动、GPU 初始化、权重加载当然会影响用户第一次请求的响应时间，但它们属于服务启动阶段或者实例扩容阶段的延迟，而不是每一个请求都会重复发生的 TTFT。

这一区分非常重要。假设一个模型权重为 70 GB，服务器从 NVMe SSD 读取这些数据需要一定时间，那么这部分时间属于模型加载或实例启动成本。模型一旦驻留在显存中，后续请求的 TTFT 就主要由请求排队、Tokenization、调度、Prefill、GPU 计算、跨 GPU 通信以及首 Token 返回等环节决定。

真正理解 TTFT，需要先理解大模型生成答案时发生了什么。

用户输入的自然语言首先需要经过 Tokenizer。比如一句英文或者中文，会被转换成模型词表中的 Token ID。中文、英文、数字、标点以及特殊符号并不一定对应一个 Token，因此输入文本长度不能简单按照字符数量计算。

Tokenization 通常发生在 CPU 侧，速度一般远高于大型 Transformer 的 GPU 计算，但在高并发环境下，Tokenizer、请求解析、JSON 序列化、网络通信以及调度线程仍然可能成为延迟的一部分。

Token ID 准备完成后，请求进入推理调度器。现代大模型服务通常不是简单地让一个请求独占 GPU，而是会同时管理大量正在等待或者正在生成的请求。

这里就涉及 Batch、Concurrency 和 Continuous Batching。

传统静态 Batch 可以理解为把多个请求组织起来一次处理，而现代 LLM serving 更强调动态调度。不同请求的 prompt 长度不同，已经生成的 Token 数量也不同，因此推理系统需要持续决定哪些请求进入下一轮计算。

对于在线服务来说，调度器面对的是一个动态队列。一个请求可能刚刚进入系统，另一个请求已经生成了几十个 Token，还有一个请求正在等待 GPU 显存中的 KV Cache 空间。

因此，TTFT 并不完全由 GPU 的理论算力决定。

如果请求进入系统后需要等待 GPU 调度，那么等待时间本身就会成为 TTFT 的组成部分。高并发情况下，这部分延迟甚至可能超过模型本身的计算时间。

请求真正进入 Transformer 后，最重要的阶段是 Prefill。

假设用户输入了一个包含 1000 个 Token 的 prompt，模型需要对这 1000 个输入 Token 进行一次完整的前向计算。在这个过程中，Transformer 的每一层都会进行 Attention、MLP 等计算，并产生对应的隐藏状态以及用于后续生成的 Key 和 Value。

这个阶段通常被称为 Prefill。

Prefill 是理解 TTFT 的核心。

模型不能凭空知道用户输入了什么。它必须先把整个 prompt 送入 Transformer，完成上下文计算，然后才能根据最后的隐藏状态计算下一个 Token 的概率分布。

因此，当 prompt 很长时，TTFT 往往明显增加。

这也是为什么一个只输入十几个 Token 的问题和一个包含数万 Token 历史上下文的问题，在相同 GPU 上可能表现出完全不同的首 Token 延迟。

Prefill 与 Decode 的计算特征也不同。

Prefill 可以同时处理大量输入 Token，因此 GPU 上的矩阵乘法通常具有较好的计算并行度。Decode 则不同。生成第一个 Token 后，模型需要根据已经存在的上下文继续生成下一个 Token，然后再次进行下一轮计算。

在典型自回归生成过程中，每一轮 Decode 通常只新增一个 Token。模型会利用之前已经计算并缓存的 Key 和 Value，而不需要每次都重新计算整个历史上下文。

这就是 KV Cache 出现的原因。

KV Cache 并不是一个在请求开始之前从外部设备搬进显存的“数据文件”。它主要是在 Prefill 和 Decode 过程中由模型计算产生，并存放在 GPU 显存或者推理系统管理的其他内存层级中。

对于每一个 Transformer Layer，Attention 都会产生 Key 和 Value。系统将这些结果保存下来，后续生成 Token 时直接复用，从而避免重复计算历史 Token 的 Key 和 Value。

KV Cache 的大小与模型结构、Layer 数量、Attention 头配置、KV Head 数量、数据类型以及当前请求已经处理的 Token 数量有关。因此不能简单地说“每个 Token 固定占用 4 KB”。

不同模型的 KV Cache 开销可能相差很大。

采用 Multi-Query Attention、Grouped-Query Attention 等结构后，Key 和 Value 的 Head 数量可以少于 Query Head，从而明显降低 KV Cache 的显存需求。FP16、BF16、FP8 等不同数据格式也会改变其内存占用。

另一个经常出现的错误是把 KV Cache 描述成“指数增长”。

KV Cache 对单个请求而言通常随着上下文 Token 数量增长而近似线性增加。假设模型结构和数据类型固定，那么请求从 1000 Token 增加到 2000 Token，KV Cache 大致也会按照对应的 Token 数量增加，而不是因为 Token 数量翻倍就发生指数级增长。

真正棘手的是高并发。

如果 GPU 同时服务很多请求，每个请求都有自己的 KV Cache，那么所有活跃请求的 KV Cache 加起来可能迅速占据大量显存。

这也是现代 LLM serving 系统非常重视 KV Cache 管理的原因。像 PagedAttention 这样的机制，本质上就是通过更灵活的显存块管理减少 KV Cache 分配和碎片问题，让不同长度的请求能够更加高效地共享 GPU 内存资源。

完成 Prefill 后，模型会根据最后位置的隐藏状态计算 Logits，也就是词表中每个候选 Token 的分数。

随后经过 Softmax、Temperature、Top-k、Top-p 等采样策略，或者使用 Greedy、Beam Search 等其他解码方式，系统确定第一个输出 Token。

这个 Token 生成出来之后，才真正到达 TTFT 的终点附近。

如果把用户看到文字的时间也纳入指标，那么还需要考虑 GPU 到服务进程的数据传递、Token Detokenization、网络发送以及前端渲染等环节。因此不同系统对 TTFT 的精确定义可能存在细微差异，性能测试时必须确认指标边界。

这也解释了为什么 TTFT 与后续 Token 延迟，也就是 ITL，必须分开观察。

TTFT 主要受到请求进入系统后的排队、输入 Token 数量、Prefill 计算、GPU 调度和并行通信等因素影响。

ITL，也就是 Inter-Token Latency，则更多反映 Decode 阶段连续生成 Token 的速度。

一个系统完全可能出现“TTFT 很高，但后续 Token 很快”的情况。例如一个长 prompt 首先需要进行大量 Prefill，完成后 GPU 可以以较高速度进行 Decode。

反过来，如果模型已经完成 Prefill，但是 GPU 当前存在大量并发生成请求，那么 Decode 阶段的资源竞争可能导致 ITL 上升。

多 GPU 环境又会增加另外一层复杂性。

如果模型规模超过单张 GPU 的显存容量，推理系统可能采用 Tensor Parallel、Pipeline Parallel 等模型并行方式。不同 GPU 分担模型计算后，某些阶段需要在 GPU 之间交换激活数据或者进行同步。

Tensor Parallel 通常涉及层内计算的切分，因此 GPU 间通信可能成为性能的重要组成部分。NVLink、NVSwitch、PCIe 以及跨服务器网络之间的通信能力差异，会直接影响这种架构的效率。

Pipeline Parallel 则把不同 Transformer Layer 分布到不同 GPU。推理过程中需要按照流水线阶段传递中间激活，因此调度和流水线气泡也会影响延迟。

这里不能简单把所有多 GPU 推理都描述成“GPU 之间同步导致 TTFT 增加”。实际通信量、并行策略、模型结构、Batch、序列长度和硬件拓扑共同决定通信是否成为瓶颈。

RDMA、InfiniBand、RoCE 等高速网络可以降低跨服务器通信的成本，但它们并不会自动消除分布式推理延迟。对于大规模部署，通信带宽、消息大小、通信模式以及计算和通信是否能够重叠，都会影响最终结果。

还有一个经常被忽略的因素是 Prefill 与 Decode 之间的资源竞争。

在线服务通常同时存在大量新请求和正在生成的请求。新请求需要 Prefill，老请求需要 Decode。如果调度器过度优先 Prefill，新请求的 TTFT 可能下降，但已经开始生成的请求 ITL 可能恶化。如果过度保护 Decode，又可能让新请求排队时间增加。

因此成熟的推理系统需要在 TTFT、ITL、吞吐量和 GPU 利用率之间做动态权衡。

这也是 Continuous Batching 非常重要的原因。系统不需要等待一批请求全部完成，而是可以在已有请求生成过程中不断加入新的请求，根据当前 GPU 资源和 KV Cache 状态重新组织计算。

从性能分析角度看，不能只看 GPU Utilization。

一张 GPU 显示 90% 利用率，并不意味着用户体验一定很好。高利用率可能来自大量请求同时计算，但如果请求在调度队列里等待很久，TTFT 和 P99 延迟仍然可能非常差。

专业部署通常至少应该同时观察 TTFT、P50、P95、P99、ITL、输入 Token 吞吐量、输出 Token 吞吐量、活跃序列数量、KV Cache 使用量、GPU 显存使用率、HBM 带宽、计算单元利用率以及跨 GPU 通信指标。

这些指标放在一起，才能判断瓶颈究竟发生在哪里。

如果 TTFT 很高，但 GPU 利用率长期很低，需要检查请求队列、调度线程、CPU Tokenization、数据传输以及资源分配。

如果 TTFT 随 prompt 长度明显增长，同时 GPU 计算负载很高，那么 Prefill 计算可能是主要因素。

如果 TTFT 在高并发时突然恶化，同时 KV Cache 使用量接近显存容量，则需要重点检查 KV Cache 管理、请求最大上下文长度和并发限制。

如果单 GPU 性能正常，但多 GPU 后 TTFT 明显增加，则应该进一步检查 Tensor Parallel 或 Pipeline Parallel 的通信开销、GPU 拓扑以及 PCIe、NVLink、NVSwitch 或网络链路。

如果 TTFT 本身不高，但生成过程中 ITL 很差，则调查方向又应该转向 Decode 阶段的计算、KV Cache 访问、调度策略和并发请求数量。

模型量化也会影响这一整套过程，但不能简单理解为“量化以后 TTFT 一定降低”。

FP16、BF16、FP8、INT8、INT4 等不同方案可能降低模型权重的存储和显存压力，并可能改善计算或内存带宽效率。但实际收益取决于具体硬件、Kernel 实现、量化格式以及模型结构。

尤其对于 LLM，权重、激活、KV Cache 和通信数据并不是同一个东西。把模型从 FP16 量化到 INT4，并不意味着所有运行时数据都自动按照相同比例缩小。

所以，TTFT 的优化也不能简单归结为“换更大的 GPU”。

如果模型已经驻留 GPU，继续提高 SSD 读取速度可能对单请求 TTFT 几乎没有帮助；如果瓶颈在 Prefill，那么提高 GPU Tensor Core 计算能力可能更加有效；如果瓶颈在 KV Cache，则显存容量和内存访问效率更重要；如果瓶颈来自多 GPU 通信，那么更快的互联和更合理的并行策略可能比增加 GPU 数量更有价值。

对于实际的大模型服务，可以把 TTFT 看成多个阶段共同构成的时间预算：请求进入系统后需要等待调度，输入文本需要完成 Tokenization，模型需要完成 Prefill，分布式模型可能产生通信和同步开销，然后计算首个 Token 的 Logits，完成采样，再经过 Detokenization 和网络传输，用户最终看到第一个输出 Token。

模型加载属于另一条链路。它决定实例冷启动和扩容速度，但在模型已经常驻显存的稳定服务中，不应该把模型权重每次从 SSD 加载的时间算作普通请求的 TTFT。

这一区分也解释了一个很有意思的现象：同一个模型，在离线 Benchmark 中可能拥有非常漂亮的 Token 吞吐量，但放到真实在线服务以后，用户仍然觉得慢。

原因是吞吐量和用户等待时间解决的是不同问题。离线任务可以让 GPU 长时间满载，追求每秒处理更多 Token；在线聊天服务却必须面对请求到达时间随机、prompt 长度不同、用户同时在线、SLO 限制以及 P95、P99 尾延迟等问题。

对于一个真正面向用户的大模型服务，最优目标从来不是单独追求某一个数字，而是在指定并发规模和业务 SLO 下，让 TTFT、ITL、吞吐量、显存占用和 GPU 成本达到合理平衡。

从这个角度看，TTFT 并不是“模型生成第一个字为什么比较慢”这么简单。它实际上是 LLM 推理系统把一次用户请求从排队状态推进到可生成状态所支付的综合成本，而 Prefill 是其中最核心的计算阶段。理解 Prefill、Decode、KV Cache、Continuous Batching、模型并行和 GPU 内存层级之间的关系，才能真正判断一个推理系统为什么慢，以及应该从哪里下手优化。