LLM 推理流程：Prefill 与 Decode

推理不只是“把输入送进模型”

在最粗糙的描述里，我们常说：

• 把 prompt 输入模型
• 模型输出回答

但真实的 LLM 推理过程并不是一次性结束的，而更像：

1. 先处理用户提供的 prompt
2. 在 prompt 基础上生成第一个 token
3. 再用“原 prompt + 新 token”继续生成下一个 token
4. 持续循环，直到遇到停止条件

因此，推理至少可以自然拆成两个阶段：

阶段 1：Prefill 预填充

把已有前缀全部处理完。

阶段 2：Decode 解码

在已有前缀基础上，一步步生成新的 token。

Prefill

prefill 可以理解成：

把用户给定的 prompt 整体送进模型，建立后续生成所需的上下文状态。

假设用户输入：

请用一句话解释什么是 KV Cache

模型首先要做的不是立刻输出一整段答案，而是：

• 把这句话切成 token
• 在每一层 attention 中处理这些 token
• 建立模型理解当前上下文所需的内部表示

如果从 decoder-only 自回归视角看，prefill 的目标是：

• 让模型看完整个 prompt
• 为“生成第一个新 token”做好准备

Prefill 的特点

• 输入长度通常等于 prompt 长度
• attention 需要覆盖整段 prompt
• 计算量通常会随着 prompt 变长迅速增大
• 长 prompt 时，prefill 往往是首 token 延迟的重要来源

你可以把它理解为：

• 用户给模型“喂背景”
• 模型把背景吃完
• 然后才开始说第一句话

prefill 的瓶颈常常是：

• prompt 太长
• 首 token 延迟高
• 需要大量矩阵运算吞吐

Decode

decode 可以理解成：

在已有上下文基础上，每次只生成一个新 token，并把它继续接回上下文。

例如在 prompt 处理完之后，模型开始生成回答：

KV

接着下一步生成：

Cache

再下一步生成：

是

于是整个生成序列逐步扩展为：

KV Cache 是 ...

Decode 的特点

• 每一步通常只新增 1 个 token
• 每一步都依赖全部历史上下文
• 历史上下文会越来越长
• 如果没有增量复用机制，后续每一步都会越来越贵

decode 的瓶颈常常是：

• 历史上下文越来越长
• 单步增量计算如何足够快
• cache 如何管理
• 并发请求下如何维持吞吐

首 token 延迟和生成吞吐

TTFT

指从请求到达开始，到模型吐出第一个 token 为止的时间。

它受这些因素影响很大：

• prompt 长度
• prefill 计算量
• 排队与调度
• batch 策略

TPS

指模型在持续生成阶段的 token 产出速度。

它更受这些因素影响：

• decode 的单步效率
• KV Cache 复用效率
• cache 是否成为显存瓶颈
• 多请求并发时的调度和碎片化

所以一个模型/服务可能出现这种情况：

• TTFT 不算低
• 但 decode 很快

也可能出现：

• 首 token 还行
• 但长输出时越生成越慢

这就是为什么不能只用“推理速度”一个词笼统描述性能。