标准回答
Prefill（预填充）
把整个输入 prompt 一次性喂入模型并行前向，所有 token 同时计算注意力。这是一个大矩阵乘为主的过程，算术强度高，能把 GPU 算力打满，属于计算受限。它产出第一个输出 token，并把 prompt 全部 token 的 K、V 写入 KV-cache。Prefill 的耗时主导首 token 延迟（TTFT），随 prompt 长度增长。
Decode（解码）
之后逐个生成 token：每步只处理一个新 token，但要读取全部历史 token 的 KV-cache 做注意力。每步搬动整套权重和不断变大的 KV-cache，却只产出一个 token，算术强度极低，属于访存受限。Decode 的每步耗时主导吐字速度（TPOT），并随已生成长度缓慢上升。
两者的联系与影响
KV-cache 是连接两阶段的桥梁：Prefill 算好缓存，Decode 反复复用并追加。因为瓶颈不同，工程上常做 PD 分离（prefill/decode 分到不同实例），分别优化算力与带宽，并用 chunked prefill、continuous batching 平衡 TTFT 与吞吐。详见 LLM 推理优化 2026。
常见误区
⚠️ 常见踩坑
别把 Decode 当成「和 Prefill 一样只是少了几个 token」——两者瓶颈相反：Prefill 缺算力、Decode 缺带宽，因此优化手段（更大 batch、更快显存、KV 压缩）侧重点完全不同。
追问
追问 1：为什么要做 Prefill/Decode 分离部署？
两阶段瓶颈相反、相互干扰：长 prefill 会阻塞 decode 造成卡顿。分到不同实例后可各自用合适的并行策略与批大小，独立扩缩容，兼顾 TTFT 与 TPOT。
追问 2：chunked prefill 解决什么问题？
把长 prompt 的 prefill 切成小块，与正在进行的 decode 混排进同一批，避免一次长 prefill 长时间霸占 GPU、拖垮其他请求的吐字延迟，使延迟更平滑。
追问 3：为什么 Decode 阶段增大 batch 能提吞吐却几乎不增延迟？
Decode 访存受限，单请求时算力闲置。多请求共享同一次权重读取，把算力填满，总吞吐随 batch 上升，而单步延迟在带宽未饱和前变化很小。
延伸学习
与本题相关的知识库文章、术语、工具与行业资讯。
📚 知识库
📖 术语表
🛠️ AI 工具
- vLLM
高吞吐 LLM 推理引擎，77,418+ stars。采用 PagedAttention 显存优化技术，吞吐量比 HuggingFace Transformers 高 24 倍，是生产环境部署大模型推理的首选方案，支持 OpenAI 兼容 API
- TensorRT-LLM
NVIDIA TensorRT-LLM 提供易用的 Python API 定义 LLM，支持最先进的推理优化，在 NVIDIA GPU 上实现极致推理性能