Prefill 与 Decode 分离：高并发 LLM Serving 的下一层架构
TL;DR
- 场景：当 LLM Serving 跑长上下文 RAG / Agent / 实时语音时，prefill 的 compute burst 会卡住 decode 的流式输出，TTFT 和 TPOT 难以同时优化 --- 单卡混部开始撞到「资源池不可拆」的天花板。
- 结论 ：P/D 分离（Disaggregated Prefill/Decode）把 prefill 和 decode 拆到不同 GPU 池，可独立扩缩容、独立调优 SLO；但它会引入 KV Cache 传输（NIXL / Mooncake Transfer Engine / RDMA / NVLink / PCIe / TCP）、跨节点路由、状态恢复和 P95/P99 监控 4 个新问题。它不是默认起点，而是「chunked prefill 救不回来」之后的下一层架构。
- 产出：一张覆盖 9 节的 P/D 分离决策导图 + 25 项能力版本矩阵 + 10 行错误速查卡 + 主流论文 / 工业项目索引（DistServe / Mooncake / SplitWise / TetriInfer / MemServe / Sarathi-Serve / NVIDIA Dynamo / vLLM 实验性实现 / SGLang / TensorRT-LLM）。
版本矩阵
| # | 功能 / 主题 | 状态 | 说明 |
|---|---|---|---|
| 1 | vLLM Disaggregated Prefilling（实验性） | ✅ 已验证 | vLLM 0.7+，--kv-transfer-config + KVTransferConfig，PR #6170（2024-07-06 合并） |
| 2 | vLLM NixlConnector | ✅ 已验证 | NVIDIA NIXL 传输层，支持 RDMA / NVLink / PCIe / TCP |
| 3 | vLLM Mooncake Transfer Engine | ✅ 已验证 | vLLM 0.8+，PR #10884（2024-12-02 合并），Mooncake 风格 KV 传输 |
| 4 | DistServe（Goodput 模型） | ✅ 已验证 | OSDI 2024，arXiv 2401.09670，4.48× 吞吐 / 10.2× SLO tighter；vLLM 正在集成 |
| 5 | Mooncake（KVCache-centric 架构） | ✅ 已验证 | FAST 2025 最佳论文，arXiv 2407.00079；Kimi / Moonshot AI 出品 |
| 6 | Sarathi-Serve（chunked prefill 起源） | ✅ 已验证 | arXiv 2403.02310，piggyback decodes on chunked prefills |
| 7 | SplitWise | ✅ 已验证 | 微软，PD 分离提升 GPU 利用率 |
| 8 | TetriInfer | ✅ 已验证 | 学术工作，PD 分离 + 二维装箱 |
| 9 | MemServe | ✅ 已验证 | 学术工作，弹性内存池 + context caching |
| 10 | EPD Disaggregation | ✅ 已验证 | arXiv 2501.05460，把 Encode / Prefill / Decode 三段全拆，多模态场景 |
| 11 | NVIDIA Dynamo（GTC 2025） | ✅ 已验证 | GPU Planner / Smart Router / Disaggregated Serving / KV Cache Manager，NIXL 通信，支持 vLLM / SGLang / TensorRT-LLM |
| 12 | SGLang disaggregated serving | ✅ 已验证 | SGLang 官方支持，与 RadixAttention 配合 |
| 13 | TensorRT-LLM disaggregated serving | ✅ 已验证 | NVIDIA TensorRT-LLM 提供 P/D 分离示例与脚本 |
| 14 | vLLM chunked prefill（默认开启） | ✅ 已验证 | 0.6.5+ 默认，--enable-chunked-prefill，--max-num-batched-tokens 控制预算 |
| 15 | Automatic Prefix Caching | ✅ 已验证 | v1 zero-overhead prefix caching，PD 分离后仍可命中跨节点 prefix |
| 16 | TTFT / TPOT / ITL / Goodput 指标 | ✅ 已验证 | DistServe 引入 Goodput，SLO 约束下才计为有效 |
| 17 | KV transfer 指标拆解 | ✅ 已验证 | prefill queue / prefill exec / KV transfer / decode queue / TPOT / stream jitter |
| 18 | NIXL（NVIDIA Inference tranXfer Layer） | ✅ 已验证 | NVIDIA 统一传输抽象，RDMA / NVLink / GPUDirect |
| 19 | Mooncake Transfer Engine | ✅ 已验证 | RDMA + async 流水线 + chunked layer-wise prefill |
| 20 | RDMA / RoCE / GPUDirect | ✅ 已验证 | 跨机 P/D 分离的常用网络底座 |
| 21 | Prefill 池 + Decode 池独立 HPA | ✅ 已验证 | Kubernetes 维度的独立扩缩容 |
| 22 | prefill queue / decode queue 拆开监控 | ✅ 已验证 | Prometheus 指标 + Grafana 仪表板 |
| 23 | 跨节点 prefix cache 复用 | ✅ 已验证 | Dynamo Smart Router 用 Radix Tree 索引 + 重叠得分 |
| 24 | vLLM CVE-2025-62164（PD 分离相关） | ⚠️ 需关注 | vLLM 0.10.2+，Completions API 内存损坏，CVSS 8.8；建议升级到最新稳定版 |
| 25 | Chunked prefill vs P/D 分离的边界 | ✅ 已验证 | 单池内精细调度 vs 跨资源池架构拆分，混用是常态 |
备注：版本矩阵全部基于 vLLM 官方文档、Anatomy of vLLM 博客（2025-09-05）、DistServe / Mooncake / Sarathi-Serve / EPD 等公开论文（arXiv + OSDI 2024 + FAST 2025）、vllm-project/vllm GitHub PR、SegmentFault / CSDN 公开拆解文章核查；⚠️ 条目为已披露的安全/版本相关问题，需要运维侧主动升级或缓解。
现代 LLM 推理服务里，Prefill 和 Decode 的矛盾越来越明显。
Prefill 负责处理输入 prompt，建立 KV Cache，通常偏计算密集。Decode 负责逐 token 生成，通常偏显存带宽、KV Cache 访问和低延迟稳定性。把这两个阶段混在同一组 GPU 上，简单，但会互相干扰。
当请求量不大、上下文不长时，这种混合没问题。当系统进入长上下文、高并发、Agent、RAG、语音实时交互后，Prefill/Decode 分离就变成值得认真评估的架构方向。
但它不是默认起点。它是系统发展到一定规模后，为了把 TTFT、TPOT、资源池和 SLO 拆开管理而引入的下一层架构。
一、Prefill 和 Decode 的资源特征不同
Prefill 的输入是一整段 prompt。prompt 可能有几百 token，也可能有几万 token。模型可以并行处理输入 token，因此 prefill 往往形成较大的矩阵计算，更偏 compute-bound。
Decode 每一轮通常只为每个请求生成一个 token。单步计算规模小，但要频繁读取模型权重和历史 KV Cache。上下文越长，KV 访问越重，因此 decode 经常更接近 memory-bound。
这两个阶段对 GPU 的使用方式不同。
Prefill 像一次大块计算任务。它更关心输入 token 总量、prefill queue、prefill execution time、TTFT 和大 prompt 处理能力。
Decode 像持续、小步、低延迟的流式任务。它更关心 running requests、KV 读取压力、step time、TPOT、inter-token latency 和流式稳定性。
把它们放在一起，不一定错。vLLM 的 continuous batching、PagedAttention、chunked prefill 已经能覆盖很多场景。但如果 workload 同时满足"长 prompt 多"和"流式低延迟要求高"，混部的矛盾会逐渐变成架构问题。
| 阶段 | 主要工作 | 更敏感的指标 | 常见压力 |
|---|---|---|---|
| Prefill | 处理 prompt，建立 KV Cache | TTFT、prefill queue time | 长上下文、RAG、Agent 历史 |
| Decode | 逐 token 生成并更新 KV | TPOT、ITL、stream jitter | 并发输出、KV 读取、上下文变长 |
二、混部时最常见的问题
第一个问题是长 prompt 阻塞 decode。
一个 RAG 请求带着 30K token prompt 进入系统，prefill 可能占用较长 GPU 时间。与此同时，已有用户正在流式输出。如果调度不够精细，他们的 token 间隔会突然变大，表现为"回答卡顿"。
第二个问题是 TTFT 和 TPOT 难以同时优化。
TTFT 主要受 prefill 排队和 prefill 执行影响。TPOT 主要受 decode 调度和 KV 访问影响。同一套 GPU 和同一套调度参数，很难同时对两者最优。为了降低 TTFT，你可能想让 prefill 尽快进入；为了稳定 TPOT，你又不希望大 prefill 抢占 decode 时间。
第三个问题是 workload 难以隔离。
短 prompt 聊天、长文档总结、Agent 工具调用、代码仓库问答混在一起，长任务会影响短任务。用户感知上就是尾延迟变差：平均速度看起来还行，但 P95/P99 一直不稳。
第四个问题是扩容粒度被绑在一起。
如果业务变成长 prompt 更多，你想加 prefill 能力；如果输出并发更多，你想加 decode 能力。但在混部架构里，扩容往往是整组 GPU 一起扩，很难把两类资源按比例独立扩。
所以混部不是不能用，而是到一定规模后会暴露出"资源池不可拆"的限制。
三、Chunked Prefill 是第一层缓解
在真正拆分 GPU 池之前，可以先做 chunked prefill。
它把长 prompt 切成多个 chunk。Scheduler 可以在处理 prefill chunk 的间隙插入 decode step，避免长 prompt 一次性占满 GPU。
这是一种单实例内的调度优化。它不需要把 prefill 和 decode 部署到不同机器，工程复杂度相对可控。
对于大部分中小规模服务，chunked prefill 通常是比 P/D 分离更先应该做的优化。
它适合解决：
- 长 prompt 偶发；
- decode 偶尔卡顿；
- TTFT 尾延迟变差；
- RAG 或 Agent 请求偶尔把短请求拖慢；
- 还没有足够 GPU 资源拆成两个独立池。
但它不能完全解决 prefill 和 decode 资源池独立扩缩的问题。
Chunked prefill 仍然是在同一组 GPU 上做时间切片。它缓解"长 prefill 独占 GPU"，但没有把 prefill 和 decode 的容量规划拆开。对于大规模服务，尤其是长上下文请求稳定占比较高的场景，P/D 分离才会进入评估范围。
简单说：chunked prefill 是单池内的精细调度，P/D 分离是跨资源池的架构拆分。
四、什么是 Prefill/Decode 分离
Prefill/Decode 分离，也叫 disaggregated prefill/decode serving。
核心思想是：把 prefill 阶段和 decode 阶段放到不同的实例或 GPU 池中。
Prefill GPU 负责处理输入 prompt，生成 KV Cache。Decode GPU 负责接收 KV Cache，继续逐 token 生成。
这样可以分别优化两类资源。
Prefill 池可以配置更适合大 prompt 计算的并行策略，追求更高 prefill 吞吐和更短 TTFT。Decode 池可以配置更适合低 TPOT、稳定 inter-token latency、流式输出的调度策略。
一个简化链路可以写成：
text
Client
-> Router
-> Prefill Queue
-> Prefill Workers
-> KV Transfer
-> Decode Queue
-> Decode Workers
-> Streamer
-> ClientRouter 负责判断请求进入哪个 prefill worker。Prefill worker 负责生成 KV Cache 和首 token 前状态。KV Transfer 层负责把缓存交给 decode worker。Decode worker 负责持续生成 token。Streamer 负责把 token 返回客户端。
vLLM 文档中也把 disaggregated prefilling 作为实验能力，强调它可以分别调优 time-to-first-token 和 inter-token latency。
这套架构的关键不只是"拆成两个服务"。真正难的是：KV Cache 如何传、请求状态如何路由、失败如何恢复、两个资源池如何分别扩缩、metrics 如何归因。
五、P/D 分离带来的收益
第一，资源隔离。
长 prompt 不再直接阻塞 decode 池。已有流式输出更稳定。对于在线聊天、语音助手、实时 Agent，这一点非常关键。
第二，独立扩缩容。
如果业务 prompt 很长，prefill 池可以扩容。如果输出很长、并发生成多，decode 池可以扩容。两者不必绑定。
第三，策略差异化。
Prefill 可以追求高吞吐和大 token budget。Decode 可以追求低 TPOT 和稳定 step time。两个池可以有不同 batch 策略、不同优先级策略、不同并行配置和不同监控目标。
第四，SLO 更清晰。
TTFT 和 TPOT 可以分别监控、分别归因、分别优化。你不再需要猜"用户卡顿到底是 prefill 抢占了 GPU，还是 decode 池本身拥挤"。
第五，workload 隔离更自然。
长文档总结、代码仓库问答、RAG 深度检索、Agent 多轮任务可以进入更适合 prefill-heavy 的资源路径；短对话、语音交互、实时助手可以更重视 decode 稳定性。
六、新瓶颈：KV Cache 传输
P/D 分离不是免费午餐。
Prefill 完成后，KV Cache 必须从 prefill GPU 转移到 decode GPU。这个传输可能发生在同机 GPU 之间，也可能跨机器发生。
同机 NVLink 还好，跨机器就需要走网络。KV Cache 体积很大，传输延迟和带宽会成为新的瓶颈。
这就是为什么 P/D 分离在论文和大厂系统里很常见，但普通团队落地要谨慎。你把 compute 干扰解决了，却可能引入 KV transfer 干扰。
P/D 分离后，系统至少要新增几类指标：
| 指标 | 说明 |
|---|---|
| prefill queue time | 请求在 prefill 池排队多久 |
| prefill execution time | prompt 处理本身耗时 |
| KV transfer time | KV Cache 从 prefill 到 decode 的传输耗时 |
| decode queue time | 请求进入 decode 池前等待多久 |
| TPOT / ITL | decode 阶段流式 token 间隔 |
| transfer failure / retry | KV 传输失败和重试次数 |
如果这些指标没有拆开，出了问题很难判断到底是 prefill 慢、排队慢、传输慢还是 decode 慢。
更麻烦的是，KV transfer 不是只看平均耗时。突发请求、长上下文、重尾 workload、网络抖动都会把 P95/P99 拉高。
因此，P/D 分离不是"把两个阶段部署到不同机器"就结束了。它还要求系统有更强的路由、监控、故障恢复和容量规划能力。
七、什么时候适合 P/D 分离
适合 P/D 分离的场景通常有几个特征。
第一，prompt 很长。比如长文档、代码仓库、RAG、多轮 Agent、长历史对话。
第二，并发高。单机混合调度已经无法稳定控制 TTFT 和 TPOT。
第三，流式体验重要。decode 卡顿会明显影响用户体验，比如语音对话、实时助手、交互式编码助手。
第四，GPU 资源池足够大。至少要有能力划分 prefill 和 decode 资源。
第五，有能力处理 KV Cache 传输、路由、监控和故障恢复。
在 AI 语音链路里，用户最敏感的是首字延迟和连续性。ASR 输出文本后，LLM 要尽快开始生成。TTS 又要尽快拿到前几个字开始合成。如果 LLM 的 TTFT 高，整个语音首包就慢。如果 LLM token 间隔不稳定，TTS chunk 供应也会不稳定，表现为停顿、卡顿或者节奏不自然。
所以语音场景更关心 P95 TTFT、P95 TPOT、token streaming 稳定性，而不是单纯 tokens/s。
Agent 场景也类似。Agent 的问题不是一次 LLM 调用慢，而是一次用户任务可能触发多次 LLM 调用：计划、调用工具、读取工具结果、继续推理、最后总结。如果每次都带完整上下文 prefill，延迟会被链式放大。
Agent 优化首先应该减少重复 prefill。固定 system prompt、工具 schema、角色设定、输出格式都应该尽量稳定，以便 prefix cache 命中。当 Agent 请求很多、上下文很长、decode 又要低延迟时，P/D 分离才会有更大价值。
如果只是单卡或两三张卡的小规模服务，P/D 分离往往过度复杂。先做好 continuous batching、chunked prefill、prefix caching、限流和 prompt 控制，收益更直接。
八、落地前的判断清单
在上 P/D 分离之前，先回答几个问题。
当前 P95 TTFT 是多少？其中 prefill 执行占多少，排队占多少？
当前 P95 TPOT 是多少？是否存在长 prompt 进入后 decode 卡顿？
输入 token 分布是什么？P50、P95、P99 分别多长？
输出 token 分布是什么？长输出请求占比多少？
KV Cache 使用率是否经常接近上限？preemption 是否频繁？
GPU 是单机多卡还是多机多卡？卡之间有 NVLink 吗？机器之间网络带宽够吗？
是否已经启用 chunked prefill 和 prefix caching？
是否有能力监控 prefill queue、prefill execution、KV transfer、decode queue、TPOT 和 stream jitter？
如果这些数据没有，直接做 P/D 分离属于盲目复杂化。
更务实的路径通常是：
- 先把请求链路指标打全。
- 再做 prompt 控制、prefix caching、chunked prefill。
- 再观察 TTFT / TPOT / queue time / KV usage 的 P95/P99。
- 如果混部仍然无法稳定，再评估 P/D 分离。
九、核心结论
Prefill 和 Decode 是 LLM 推理中资源特征完全不同的两个阶段。Prefill 偏大块计算，Decode 偏持续低延迟和 KV Cache 访问。
在普通规模下，混合部署加 chunked prefill 往往够用。在长上下文、高并发、强流式体验场景下，P/D 分离可以提供更好的资源隔离和独立扩缩容。
但 P/D 分离会引入 KV Cache 传输、跨节点路由、调度复杂度和故障恢复问题。它不是默认起点，而是系统发展到一定规模后的下一层架构。
真正成熟的判断不是"要不要上新架构"，而是先把 TTFT、TPOT、prefill queue、KV transfer、decode queue 和流式稳定性拆开看。
当你能清楚知道瓶颈在哪一段，再决定是否分离 Prefill 和 Decode，架构选择才不是拍脑袋。
参考资料
- vLLM Documentation, Disaggregated Prefilling: https://docs.vllm.ai/en/latest/features/disagg_prefill/
- vLLM Documentation, Optimization and Tuning: https://docs.vllm.ai/en/latest/performance/optimization.html
- vLLM Blog, Inside vLLM: Anatomy of a High-Throughput LLM Inference System: https://vllm.ai/blog/2025-09-05-anatomy-of-vllm
- vLLM Documentation, Automatic Prefix Caching: https://docs.vllm.ai/en/latest/features/automatic_prefix_caching/
- Paper, Efficient Memory Management for Large Language Model Serving with PagedAttention: https://arxiv.org/abs/2309.06180
- NVIDIA TensorRT-LLM Documentation: https://nvidia.github.io/TensorRT-LLM/
- Hugging Face Text Generation Inference: https://github.com/huggingface/text-generation-inference
- SGLang Documentation: https://docs.sglang.ai/
3. 错误速查卡
| # | 症状 | 根因 | 定位方法 | 修复方案 |
|---|---|---|---|---|
| 1 | 长 prompt 进入后 decode 抖动 / 流式卡顿 | prefill 抢占 decode 资源，单池混部 | 监控 prefill_chunks_total + 单请求 decode step 间隔 |
开 chunked prefill、--max-num-batched-tokens 调小、prefix caching 命中 |
| 2 | TTFT 高 / TPOT 正常 | prefill 池资源不足 / 排队重 | 拆 prefill_queue_time vs prefill_execution_time |
加 prefill GPU 节点 / 提 gpu-memory-utilization / prompt 压缩 |
| 3 | TPOT 抖动 / TTFT 正常 | decode 池 KV 读取压力大 / 长上下文 | 监控 decode_step_time P95/P99 + kv_cache_usage |
提 decode 池并发 / 限制 max_model_len / 量化 KV |
| 4 | KV transfer 慢 / P99 飙升 | 跨机 RDMA 带宽不足 / 跨 AZ 传输 / TCP fallback | 监控 kv_transfer_time P95 + 网络层指标 |
启用 NIXL / RoCE / 同 AZ 部署 / Mooncake Transfer Engine async 流水线 |
| 5 | Prefill 池排队高 / GPU 利用率不满 | prefill 并行不足 / 单 batch token budget 偏小 | 监控 prefill_queue_depth + 池内 GPU util |
扩 prefill 池 / 提 --max-num-batched-tokens / chunked prefill |
| 6 | Decode 池排队高 / preemption 多 | decode 并发过高 / KV 不足 | 监控 decode_queue_depth + preemptions_total |
扩 decode 池 / 降 max_num_seqs / 量化 KV（fp8/int8） |
| 7 | Goodput 远低于 throughput | SLO 配置过严 / 短长任务混部 / P95 阻断 | 算 SLO 命中比例 vs 总完成数 | 放宽 SLO / 拆 SLO 维度 / 长任务走 prefill-heavy 路径 |
| 8 | prefix cache 命中率长期 < 10% | prompt 模板不稳定 / 跨池不共享 | 监控 prefix cache hit rate + hash 分布 | 稳定 system prompt + 跨池 prefix sharing（Smart Router Radix Tree） |
| 9 | GPU 池扩展不均衡 | 没按 P:D 比例扩 / 单指标触发 HPA | 看 prefill / decode 池 GPU util 比 | 拆两套 HPA、按业务侧输入/输出比扩容 |
| 10 | 客户端断连后 decode 池资源不释放 | Streamer 取消路径不通 / KV transfer 重试卡死 | 监控 cancelled_requests_total + kv_transfer_retry_total |
修复取消回调 + 传输超时 + 回收路径 |
作者：武子康的个人博客