调查研究-224 Prefill 与 Decode 分离：高并发 LLM Serving 的下一层架构

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。版本矩阵#功能 / 主题状态说明1vLLM Disaggregated Prefilling实验性✅ 已验证vLLM 0.7--kv-transfer-configKVTransferConfigPR #61702024-07-06 合并2vLLM NixlConnector✅ 已验证NVIDIA NIXL 传输层支持 RDMA / NVLink / PCIe / TCP3vLLM Mooncake Transfer Engine✅ 已验证vLLM 0.8PR #108842024-12-02 合并Mooncake 风格 KV 传输4DistServeGoodput 模型✅ 已验证OSDI 2024arXiv 2401.096704.48× 吞吐 / 10.2× SLO tightervLLM 正在集成5MooncakeKVCache-centric 架构✅ 已验证FAST 2025 最佳论文arXiv 2407.00079Kimi / Moonshot AI 出品6Sarathi-Servechunked prefill 起源✅ 已验证arXiv 2403.02310piggyback decodes on chunked prefills7SplitWise✅ 已验证微软PD 分离提升 GPU 利用率8TetriInfer✅ 已验证学术工作PD 分离 二维装箱9MemServe✅ 已验证学术工作弹性内存池 context caching10EPD Disaggregation✅ 已验证arXiv 2501.05460把 Encode / Prefill / Decode 三段全拆多模态场景11NVIDIA DynamoGTC 2025✅ 已验证GPU Planner / Smart Router / Disaggregated Serving / KV Cache ManagerNIXL 通信支持 vLLM / SGLang / TensorRT-LLM12SGLang disaggregated serving✅ 已验证SGLang 官方支持与 RadixAttention 配合13TensorRT-LLM disaggregated serving✅ 已验证NVIDIA TensorRT-LLM 提供 P/D 分离示例与脚本14vLLM chunked prefill默认开启✅ 已验证0.6.5 默认--enable-chunked-prefill--max-num-batched-tokens控制预算15Automatic Prefix Caching✅ 已验证v1 zero-overhead prefix cachingPD 分离后仍可命中跨节点 prefix16TTFT / TPOT / ITL / Goodput 指标✅ 已验证DistServe 引入 GoodputSLO 约束下才计为有效17KV transfer 指标拆解✅ 已验证prefill queue / prefill exec / KV transfer / decode queue / TPOT / stream jitter18NIXLNVIDIA Inference tranXfer Layer✅ 已验证NVIDIA 统一传输抽象RDMA / NVLink / GPUDirect19Mooncake Transfer Engine✅ 已验证RDMA async 流水线 chunked layer-wise prefill20RDMA / RoCE / GPUDirect✅ 已验证跨机 P/D 分离的常用网络底座21Prefill 池 Decode 池独立 HPA✅ 已验证Kubernetes 维度的独立扩缩容22prefill queue / decode queue 拆开监控✅ 已验证Prometheus 指标 Grafana 仪表板23跨节点 prefix cache 复用✅ 已验证Dynamo Smart Router 用 Radix Tree 索引 重叠得分24vLLM CVE-2025-62164PD 分离相关⚠️ 需关注vLLM 0.10.2Completions API 内存损坏CVSS 8.8建议升级到最新稳定版25Chunked 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 CacheTTFT、prefill queue time长上下文、RAG、Agent 历史Decode逐 token 生成并更新 KVTPOT、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、流式输出的调度策略。一个简化链路可以写成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 timeprompt 处理本身耗时KV transfer timeKV Cache 从 prefill 到 decode 的传输耗时decode queue time请求进入 decode 池前等待多久TPOT / ITLdecode 阶段流式 token 间隔transfer failure / retryKV 传输失败和重试次数如果这些指标没有拆开出了问题很难判断到底是 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.htmlvLLM Blog, Inside vLLM: Anatomy of a High-Throughput LLM Inference System: https://vllm.ai/blog/2025-09-05-anatomy-of-vllmvLLM 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.06180NVIDIA TensorRT-LLM Documentation: https://nvidia.github.io/TensorRT-LLM/Hugging Face Text Generation Inference: https://github.com/huggingface/text-generation-inferenceSGLang Documentation: https://docs.sglang.ai/3. 错误速查卡#症状根因定位方法修复方案1长 prompt 进入后 decode 抖动 / 流式卡顿prefill 抢占 decode 资源单池混部监控prefill_chunks_total 单请求 decode step 间隔开 chunked prefill、--max-num-batched-tokens调小、prefix caching 命中2TTFT 高 / TPOT 正常prefill 池资源不足 / 排队重拆prefill_queue_timevsprefill_execution_time加 prefill GPU 节点 / 提 gpu-memory-utilization / prompt 压缩3TPOT 抖动 / TTFT 正常decode 池 KV 读取压力大 / 长上下文监控decode_step_timeP95/P99 kv_cache_usage提 decode 池并发 / 限制max_model_len/ 量化 KV4KV transfer 慢 / P99 飙升跨机 RDMA 带宽不足 / 跨 AZ 传输 / TCP fallback监控kv_transfer_timeP95 网络层指标启用 NIXL / RoCE / 同 AZ 部署 / Mooncake Transfer Engine async 流水线5Prefill 池排队高 / GPU 利用率不满prefill 并行不足 / 单 batch token budget 偏小监控prefill_queue_depth 池内 GPU util扩 prefill 池 / 提--max-num-batched-tokens/ chunked prefill6Decode 池排队高 / preemption 多decode 并发过高 / KV 不足监控decode_queue_depthpreemptions_total扩 decode 池 / 降max_num_seqs/ 量化 KVfp8/int87Goodput 远低于 throughputSLO 配置过严 / 短长任务混部 / P95 阻断算 SLO 命中比例 vs 总完成数放宽 SLO / 拆 SLO 维度 / 长任务走 prefill-heavy 路径8prefix cache 命中率长期 10%prompt 模板不稳定 / 跨池不共享监控 prefix cache hit rate hash 分布稳定 system prompt 跨池 prefix sharingSmart Router Radix Tree9GPU 池扩展不均衡没按 P:D 比例扩 / 单指标触发 HPA看 prefill / decode 池 GPU util 比拆两套 HPA、按业务侧输入/输出比扩容10客户端断连后 decode 池资源不释放Streamer 取消路径不通 / KV transfer 重试卡死监控cancelled_requests_totalkv_transfer_retry_total修复取消回调 传输超时 回收路径作者武子康的个人博客