prefill 原理
目录
下面给你一个工程视角、和 vLLM 强相关的精确定义，避免“概念听懂了，但调优时还是用错”的情况。
一、一句话定义（先记住这个）
Prefill 是：把「已有输入 prompt」一次性送进模型，计算所有 token 的 Attention，并生成对应的 KV Cache 的阶段。
它发生在 真正开始逐 token 生成（Decode）之前。
二、一次完整推理在 vLLM 里的两个阶段
在 vLLM / LLM 推理中，一次请求严格分为两步：
Prompt tokens ──▶ Prefill ──▶ Decode
三、Prefill 在“干什么”
假设你的 prompt 是：
“你是一个专业的AI助手，请回答以下问题：……”
Tokenizer 后变成：
[token1, token2, token3, ... tokenN]
Prefill 阶段做的事情
-
一次性送入所有 prompt tokens
-
对每一层 Transformer：
- 计算 self-attention
- 生成 K / V
-
把这些 K / V 存进 KV Cache（GPU 显存）
-
Prefill 完成后：
- 模型已经“看过”全部 prompt
- 下一步可以开始生成新 token
Prefill 的输出不是文本，而是 KV Cache + 最后一个 token 的隐藏状态
四、Decode 是什么（对比理解）
Decode 阶段：
-
每一步：
- 输入：上一个生成 token
- Attention 只和 已有 KV Cache 交互
-
每生成 1 个 token：
- KV Cache 增加 1 个 token
这是你看到：
- tokens/s
- 吞吐量
- latency per token
的主要来源。
五、Prefill vs Decode：性能差异（非常重要）
| 维度 | Prefill | Decode |
|---|---|---|
| 计算方式 | 批量并行 | 逐 token |
| 并行度 | 高 | 低 |
| 主要瓶颈 | 显存带宽 / attention | latency |
| 是否受 prefix caching 影响 | 是 | 否 |
| 是否影响 TTFT | 决定性影响 | 间接 |
六、为什么 Prefill 会成为性能瓶颈
1️⃣ Prompt 越长，Prefill 越慢
-
Prefill 复杂度：O(N²)（attention）
-
2048 token 的 prompt：
- Prefill 成本非常高
- TTFT 明显变大
2️⃣ 高并发时，Prefill 会挤占 GPU
-
多个请求同时 Prefill：
- 大量 attention
- 占用 SM + 显存带宽
-
Decode 请求被“挤”慢
七、vLLM 为什么能优化 Prefill
1️⃣ Continuous Batching
- 把多个请求的 Prefill 拼成大 batch
- 提升 GPU 利用率
2️⃣ Prefix Caching（你刚问过的）
-
Prefill 只对没命中的 token 计算
-
命中的前缀：
- Prefill 成本 = 0
-
直接降低 TTFT
3️⃣ FlashAttention / FlashInfer
- Prefill 阶段 attention 的核心加速器
- 你日志里看到的：
Using FLASH_ATTN attention backend
对 Prefill 尤其关键
八、工程上你应该怎么“看 Prefill”
常用指标映射
| 指标 | 对应阶段 |
|---|---|
| TTFT（Time To First Token） | Prefill + 第一次 Decode |
| Prompt latency | Prefill |
| tokens/s | Decode |
| GPU 峰值显存 | Prefill + KV Cache |
九、一句工程级总结（你可以记这一段）
Prefill 是模型“读 prompt 并建立上下文记忆（KV Cache）”的阶段。
Prompt 越长、并发 Prefill 越多，TTFT 越高。
Prefix caching 的价值，本质就是减少 Prefill 的重复计算。
如果你愿意，下一步我可以：
- 画一张 Prefill / Decode / KV Cache 的时间线图
- 告诉你 4090 上 Prefill 和 Decode 谁更吃资源
- 给你一个真实压测脚本，把 Prefill 时间单独测出来
你选一个，我继续。
浙公网安备 33010602011771号