Prefill 就是把用户的 prompt 一次性处理完为 Decode 阶段准备好 KV Cache。具体做了什么用户发来一个 prompt比如请解释什么是AI假设 10 个 token。Prefill 阶段做的事和训练时的前向传播几乎一样输入: [请, 解释, 什么, 是, AI] ← 5 个 token 经过 Embedding → [5, 4096] 经过 32 层 Transformer每层: Self-Attention带 causal mask: Q, K, V 都是完整的 [5, 4096] 计算 5×5 的 attention 矩阵 输出 [5, 4096] FFN: 输出 [5, 4096] 最终层输出: [5, 4096] LM Head: [5, 32000] ← 每个位置的 logits这一步的关键产出有两个1. 第一个生成 token——取最后一个位置的 logits采样得到第一个生成词比如 “AI” → “是”。2. KV Cache 初始化——每层计算出的 K 和 V 全部存入 KV CachePrefill 完成后KV Cache 状态: Layer 0: K [5, 4096] ← prompt 的 5 个 token 的 Key V [5, 4096] ← prompt 的 5 个 token 的 Value Layer 1: K [5, 4096] V [5, 4096] ... Layer 31: K [5, 4096] V [5, 4096]为什么叫 “Prefill”因为它在预先填充KV Cache。Decode 阶段每生成一个 token 都要和所有历史 token 做 Attention而 prompt 部分的 K 和 V 在 Prefill 阶段就已经算好了不需要再算。Prefill 之后进入 Decode: Decode Step 1: 输入 是第 6 个 token 每层计算 Q_6, K_6, V_6 K_6, V_6 追加到 KV Cache现在 6 个 token Q_6 和 KV Cache 中所有 6 个 token 做 Attention → 生成第 7 个 token Decode Step 2: 输入第 7 个 token KV Cache 现在 7 个 token ...如果没有 PrefillDecode 的第一步就要从第 1 个 token 开始逐个生成prompt 的每个 token 也要做一次前向传播太慢了。Prefill 利用了 prompt 已知的特点一次性并行处理所有 prompt token效率远高于逐个 Decode。Prefill vs Decode 的计算特点Prefill: 输入长度: prompt_len比如 1000 个 token 计算: 大矩阵乘法1000×4096 × 4096×4096 特点: compute-boundGPU 计算单元满载 时间: 和 prompt 长度成正比 Decode: 输入长度: 1 个 token 计算: 小向量乘矩阵1×4096 × 4096×4096 特点: memory-bound瓶颈在读取 KV Cache 的显存带宽 时间: 和已生成的 token 总数成正比KV Cache 越来越大这就是为什么长 prompt 场景下比如 RAG 检索后拼接几千 token 的上下文Prefill 阶段会明显卡顿一下TTFT 高然后才开始逐 token 输出TPOT 相对稳定。简单说Prefill “读完题目”Decode “逐字写答案”。
【infra之路】Prefill具体在做什么
发布时间:2026/7/1 14:23:05
Prefill 就是把用户的 prompt 一次性处理完为 Decode 阶段准备好 KV Cache。具体做了什么用户发来一个 prompt比如请解释什么是AI假设 10 个 token。Prefill 阶段做的事和训练时的前向传播几乎一样输入: [请, 解释, 什么, 是, AI] ← 5 个 token 经过 Embedding → [5, 4096] 经过 32 层 Transformer每层: Self-Attention带 causal mask: Q, K, V 都是完整的 [5, 4096] 计算 5×5 的 attention 矩阵 输出 [5, 4096] FFN: 输出 [5, 4096] 最终层输出: [5, 4096] LM Head: [5, 32000] ← 每个位置的 logits这一步的关键产出有两个1. 第一个生成 token——取最后一个位置的 logits采样得到第一个生成词比如 “AI” → “是”。2. KV Cache 初始化——每层计算出的 K 和 V 全部存入 KV CachePrefill 完成后KV Cache 状态: Layer 0: K [5, 4096] ← prompt 的 5 个 token 的 Key V [5, 4096] ← prompt 的 5 个 token 的 Value Layer 1: K [5, 4096] V [5, 4096] ... Layer 31: K [5, 4096] V [5, 4096]为什么叫 “Prefill”因为它在预先填充KV Cache。Decode 阶段每生成一个 token 都要和所有历史 token 做 Attention而 prompt 部分的 K 和 V 在 Prefill 阶段就已经算好了不需要再算。Prefill 之后进入 Decode: Decode Step 1: 输入 是第 6 个 token 每层计算 Q_6, K_6, V_6 K_6, V_6 追加到 KV Cache现在 6 个 token Q_6 和 KV Cache 中所有 6 个 token 做 Attention → 生成第 7 个 token Decode Step 2: 输入第 7 个 token KV Cache 现在 7 个 token ...如果没有 PrefillDecode 的第一步就要从第 1 个 token 开始逐个生成prompt 的每个 token 也要做一次前向传播太慢了。Prefill 利用了 prompt 已知的特点一次性并行处理所有 prompt token效率远高于逐个 Decode。Prefill vs Decode 的计算特点Prefill: 输入长度: prompt_len比如 1000 个 token 计算: 大矩阵乘法1000×4096 × 4096×4096 特点: compute-boundGPU 计算单元满载 时间: 和 prompt 长度成正比 Decode: 输入长度: 1 个 token 计算: 小向量乘矩阵1×4096 × 4096×4096 特点: memory-bound瓶颈在读取 KV Cache 的显存带宽 时间: 和已生成的 token 总数成正比KV Cache 越来越大这就是为什么长 prompt 场景下比如 RAG 检索后拼接几千 token 的上下文Prefill 阶段会明显卡顿一下TTFT 高然后才开始逐 token 输出TPOT 相对稳定。简单说Prefill “读完题目”Decode “逐字写答案”。