Prefill / Decode（预填充 / 解码）
LLM 推理的两个阶段：Prefill 阶段一次性处理整个输入 prompt（计算密集，可并行），Decode 阶段逐 token 生成输出（内存密集，串行）。两阶段的瓶颈不同，优化策略也不同。
Prefill / Decode（预填充 / 解码）
一句话理解
Prefill 是"读题"，Decode 是"答题"——读题可以一目十行（并行），答题只能一个字一个字写（串行）。
两阶段详解
Prefill（预填充）
处理用户输入的整个 prompt，一次性计算所有 token 的 Key 和 Value 并填入 KV Cache。
- 输入：完整的 prompt（如 128 个 token）
- 计算特点：大矩阵乘法，计算密集型，可充分利用 GPU 并行能力
- 输出：填满的 KV Cache + 第一个生成 token 的概率分布
Decode（解码）
逐 token 生成输出，每步只处理 1 个新 token。
- 输入：上一步生成的 token
- 计算特点：小矩阵（1×d）与大缓存（t×d）的乘法，内存带宽密集型，GPU 计算单元大量闲置
- 输出：下一个 token 的概率分布
为什么区分两阶段
text
用户输入 (128 tokens) 模型生成 (64 tokens)
├─ Prefill ──────────┤├─── Decode ──────────────┤
│ 一次处理 128 token │ 逐个生成 64 token │
│ GPU 满载 │ │ GPU 大量闲置 │
│ ~50ms │ │ ~640ms (10ms/token) │
两阶段的瓶颈完全不同：
| Prefill | Decode | |
|---|---|---|
| 瓶颈 | 计算量（FLOPS） | 内存带宽（读取 KV Cache） |
| 处理方式 | 并行 | 串行 |
| 耗时占比 | 通常 5-10% | 通常 90-95% |
| 优化方向 | Flash Attention、算子融合 | KV Cache 量化、投机解码 |
对 API 设计的影响
这就是为什么 LLM API 通常区分 input token 和 output token 的计费：
- Input token → Prefill 阶段处理，并行效率高，成本低
- Output token → Decode 阶段生成，串行效率低，成本高（通常是 input 的 2-4 倍）
OpenAI 的 GPT-4 定价就反映了这个成本差异。
首 token 延迟（TTFT）
用户感知的"模型反应速度"主要由 Prefill 阶段决定——从发送请求到收到第一个 token 的时间叫 TTFT（Time To First Token）。Prompt 越长，Prefill 越慢，TTFT 越高。这就是为什么超长 context 的请求"启动"更慢。
引用本术语的文章