什么是Prefill-Decode分离？为什么分离
1️⃣ 考察意图
面试官想考察你对 LLM 推理引擎底层优化的理解深度，而非仅仅背诵“Prefill 算 prompt，Decode 生 token”。刁钻点在于：能否从计算特性（计算密集型 vs 访存密集型）和 GPU 硬件利用率（SM 调度、显存带宽）角度，解释为什么分离能提升吞吐和降低延迟。答好了，展示出你懂系统级设计（如 vLLM、TensorRT-LLM 的调度策略），而非只会调 API。
2️⃣ 标准答
Prefill 和 Decode 的本质差异
- Prefill 阶段：处理输入 prompt（如 2048 tokens），一次性计算所有 token 的 KV Cache 和首个输出 token 的 logits。核心操作是 矩阵乘法（GEMM），计算密集，GPU 计算单元（SM）满载，但显存带宽压力小。
- Decode 阶段：逐 token 生成，每步只计算 1 个新 token。核心操作是 注意力机制中的 KV Cache 读取，访存密集，GPU 计算单元空闲，显存带宽成为瓶颈（读取整个 KV Cache 但只做少量计算）。
为什么分离？—— 资源冲突与调度优化
- 资源冲突：如果 Prefill 和 Decode 混在同一个 batch 里（如 vLLM 的 continuous batching），Prefill 的 GEMM 会占满 SM，导致 Decode 的 KV Cache 读取被阻塞，增加 ITL（Inter-Token Latency）。反之，Decode 的访存操作也会拖慢 Prefill 的计算速度，增加 TTFT（Time to First Token）。
- 分离动机：将 Prefill 和 Decode 分配到不同的 GPU 或不同的 kernel 流中，让 Prefill 独占计算资源（高 SM 利用率），Decode 独占访存带宽（高显存带宽利用率）。这样 TTFT 降低 30-50%，Decode 吞吐提升 2-3 倍（参考 vLLM 的分离调度实验）。
工程实现方式
- GPU 级分离：用不同 GPU 分别处理 Prefill 和 Decode（如 TensorRT-LLM 的 inflight batching 中的分离策略）。Prefill GPU 专注计算，Decode GPU 专注访存，通过 NCCL 传输 KV Cache。
- Kernel 级分离：在同一 GPU 上，用 CUDA streams 或 MPS（Multi-Process Service） 隔离 Prefill 和 Decode 的 kernel 执行。但需注意显存分配——Prefill 阶段需预分配 Decode 阶段的 KV Cache 空间，避免动态分配导致碎片。
- 调度策略：vLLM 的 分离调度器 会动态调整 Prefill 和 Decode 的 batch 大小。例如，当 Decode 队列积压时，减少 Prefill 的 batch size，优先处理 Decode 请求以降低 ITL。
实际落地的坑 + 解法
- 坑：分离后，Prefill 和 Decode 的 KV Cache 传输延迟 可能抵消收益。例如，跨 GPU 传输 2048 tokens 的 KV Cache（约 8MB 在 FP16 下）需要 0.5-1ms，如果 Decode 阶段只有 1-2 个 token，传输开销占比过高。
- 解法：使用 KV Cache 压缩（如 KIVI 或 FP8 量化）减少传输量，或采用 流水线并行 让 Prefill 和 Decode 在时间上重叠——Prefill 计算下一批时，Decode 同时处理当前批的 KV Cache。
为什么不是所有系统都分离？—— Trade-off
- 代价：分离增加系统复杂度（调度器、显存管理、通信），且在小 batch 场景下（如单用户对话），Prefill 和 Decode 的计算量都小，分离带来的收益被通信开销抵消。
- 适用场景：高并发在线服务（如 ChatGPT 的 API 服务），batch size 大（>16），Prefill 和 Decode 的负载差异明显。离线推理或小 batch 场景，保持混合 batch 更简单高效。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从计算特性、资源冲突、工程实现三个层面回答。Prefill 是计算密集型，Decode 是访存密集型，混在一起会导致 SM 和显存带宽争抢，增加 TTFT 和 ITL。分离后，Prefill 独占计算资源，Decode 独占访存带宽，典型实现如 vLLM 的分离调度器或 TensorRT-LLM 的跨 GPU 分离。总结一句：分离的本质是用系统复杂度换吞吐和延迟，适合高并发场景。”
4️⃣ 高频追问 & 应对
追问 1：分离后，Prefill 和 Decode 的 batch size 如何动态调整？会不会导致 Decode 饥饿？
用 动态优先级调度。vLLM 的做法是维护两个队列：Prefill 队列和 Decode 队列。调度器每步检查 Decode 队列长度，如果超过阈值（如 32 个请求），就暂停 Prefill 新请求，优先处理 Decode。同时，设置 最大 Decode 步数限制（如 128 步），防止单个 Decode 请求占用过多资源。Trade-off：Decode 优先级过高会拖长 Prefill 的等待时间，增加 TTFT；需要根据 SLA 调整阈值（如 TTFT < 500ms，ITL < 50ms）。
追问 2：如果 GPU 显存不够，Prefill 和 Decode 分离后如何管理 KV Cache？
使用 PagedAttention（vLLM 的核心）或 KV Cache 分块。Prefill 阶段只计算并存储当前 batch 的 KV Cache，Decode 阶段按需从显存或 CPU 内存加载。如果显存不足，将不活跃的 KV Cache 换出到 CPU（通过 swap），但注意 CPU-GPU 传输延迟（约 10GB/s），需要预取策略。更激进的做法是 KV Cache 量化（如 FP8 或 INT4），减少显存占用 50-75%，但会引入精度损失。
追问 3：分离后，如何保证 Decode 阶段的注意力计算不成为新瓶颈？
Decode 阶段的注意力计算是 访存瓶颈，因为需要读取整个 KV Cache。优化方法：1）使用 FlashAttention-2 的 Decode 模式，通过分块和重计算减少显存访问；2）采用 Multi-Query Attention（MQA） 或 Grouped-Query Attention（GQA），减少 KV Cache 的 head 数，降低访存量；3）在 kernel 层面，用 triton 手写 Decode 注意力 kernel，利用 shared memory 缓存 KV Cache 块，减少全局显存访问。
5️⃣ 避坑 · 常见错误答法
- ❌ 说“Prefill 和 Decode 分离是为了减少显存占用” → ✅ 正确：分离是为了优化计算和访存资源利用，显存占用反而可能增加（需要额外存储 KV Cache 或通信缓冲区）。
- ❌ 说“所有 LLM 推理系统都应该分离” → ✅ 正确：分离适合高并发场景，小 batch 或离线推理中，混合 batch 更简单高效，分离的通信开销会抵消收益。
- ❌ 说“分离后 Decode 阶段不需要计算” → ✅ 正确：Decode 阶段仍需计算注意力（QK^T 和 softmax），只是计算量远小于 Prefill 的 GEMM，核心瓶颈在访存。
6️⃣ 简历呼应
- 如果你有 RAG 项目：从“RAG 场景中，Prefill 阶段处理长文档（如 4K tokens），Decode 阶段生成短回答，分离能显著降低 TTFT，提升用户体验”切入，展示你理解长上下文推理的优化。
- 如果你只做过传统 NLP：用“传统 seq2seq 模型（如 Transformer）也有类似 Encoder-Decoder 分离，但 LLM 的 Prefill-Decode 分离更关注 GPU 硬件特性”类比，展示迁移能力。
- 如果你是校招无项目：聚焦“在 vLLM 的 GitHub 仓库中复现分离调度器，用 ShareGPT 数据集测试 TTFT 和 ITL 变化”，展示你读过源码并有实验验证。
- vLLM 论文：Efficient Memory Management for Large Language Model Serving with PagedAttention
- TensorRT-LLM 文档：In-flight Batching and Prefill-Decode Separation
- FlashAttention-2 论文：Fast and Memory-Efficient Exact Attention with IO-Awareness
- KIVI 论文：A Tuning-Free Asymmetric 2bit Quantization for KV Cache
- 博客：LLM Inference Optimization: Prefill vs Decode (Anyscale)