一篇读懂 PD 分离：Prefill 与 Decode 为什么不再挤在一个 GPU 里

问一个部署过 LLM 服务的人都遇到过的怪事：用户并发一多，首字延迟和逐字速度一起崩，调 batch、调队列都治标不治本。病灶往往不是算力不够，而是 prefill 和 decode 这两个计算特性完全相反的阶段，被塞在了同一块 GPU 上互相拖累。把两者拆到独立扩缩的两个 GPU 池——PD 分离（Prefill-Decode Disaggregation）——在 2024 年刚提出时曾被社区质疑「为了搬 KV cache 而搬 KV cache」，到 2026 年已经成为几乎所有主流推理服务栈的默认打法。本文讲清这条演进线：干扰从哪来、分离怎么工作、成绩单有多漂亮，以及什么时候拆是错的。

一、Prefill 和 Decode 是两种动物

大模型的一次请求内部其实有两个截然不同的阶段。Prefill（预填充）一次并行处理用户输入的全部 prompt：几百上千个 token 同时算，GPU 的计算单元被打满，是典型的计算受限（compute-bound）任务，它决定首字延迟 TTFT。Decode（解码）则是自回归地一个一个吐字：每步只算一个新 token，却要把全部权重和累积的 KV cache 从显存里过一遍，计算单元大量空闲、卡在显存带宽上，是典型的带宽受限（memory-bound）任务，它决定吐字速度 TPOT。

decode 的带宽受限可以算一笔账：以 70B 模型、FP8 权重约 70 GB 计，一块 H200（显存带宽约 4.8 TB/s）每秒至多把全部权重完整读约 68 次——这就是这块卡吐字速度的物理上限，与 batch 里排了多少请求无关。batch 越大，每次权重读取摊给越多请求，单条变快不了、总吞吐却能涨，这恰是 decode 靠批处理摊成本的根源，也解释了为什么混部下 batch 越大越糟：一次 prefill 插入，停等的是整个 batch 里所有会话的吐字。

把这两种动物关在一个笼子里，就产生 DistServe 论文所说的干扰：decode 的每一步随时可能被一个长 prompt 的 prefill 抢占计算资源——prefill 是整批并行的大活，一旦插进来，正在逐字输出的所有会话集体停等。实测数据很刺眼：一个大的 prefill 批可以让在线 decode 的 TPOT 膨胀 2 到 30 倍。反过来，decode 的小碎步也会拖慢 prefill，让 TTFT 变差。

更隐蔽的代价是耦合扩缩容。TTFT 和 TPOT 是两条独立的 SLO——聊天场景要首字快，批处理场景要吞吐高。混部时两种任务共享同一批 GPU，资源配置和并行策略只能迁就更苛刻的一方，等于按两项 SLO 的最坏情况同时预留算力，天然过度供给。扩容也只能整体扩：明明是 prefill 顶不住，却不得不连 decode 一起买。

二、PD 分离怎么工作

思路直白：把 prefill 和 decode 拆成两个独立的 GPU 池，各自按自己的 SLO 和资源画像扩缩容，中间靠一次 KV cache 传输衔接。请求先进 prefill 池算出整段 prompt 的 KV cache，传输到 decode 池，由 decode 节点继续逐字生成。

整个方案成立的关键，是KV cache 的搬运必须足够便宜。DistServe 的实测给了底气：OPT-175B 模型下 KV 传输只占请求总延迟不到 0.1%，95% 以上的请求传输耗时小于 30 毫秒——相比省下的干扰损失，这笔开销近乎免费。2026 年，NVIDIA 的 NIXL 传输库已成为 vLLM 与 Dynamo 的标准选择：有 RDMA（InfiniBand / RoCE）时走亚毫秒级直传，没有则回退 TCP。

效果用 DistServe 提出的 goodput（满足 SLO 达标率前提下每 GPU 能服务的最大请求速率）来衡量：同一套 32 卡 A100 集群上，分离部署最多可多服务 4.48 倍请求，或承受 10.2 倍严格的 SLO；聊天场景请求速率提升 2.0–3.41 倍，代码补全提升 3.2 倍。调度细节上 DistServe 也做了配套：由 decode 侧在自己就绪时拉取请求（pull-based），prefill 的突发再猛也不会把 decode 队列冲垮。

另一条路线是月之暗面的 Mooncake（Kimi 的服务平台，FAST'25 最佳论文）：它把架构反过来做，以 KVCache 为中心组织整个集群——用 GPU 集群里闲置的 CPU、DRAM 和 SSD 池化出一个分布式 KV 缓存层，prefill 与 decode 集群都围着缓存池转，再配上基于预测的提前拒绝做过载保护。真实生产负载下，这套架构让 Kimi 多处理了 75% 的请求。

三、从被质疑到默认架构：十八个月发生了什么

时间线值得细看，因为它是一部压缩版的系统架构演进史。

2024 年，三篇论文几乎同时提出分离思想：DistServe（goodput 视角）、微软 Splitwise（按阶段拆到不同硬件，发表在 ISCA 2024——它的核心主张正是两种阶段该用不同型号的机器）、Mooncake（KVCache 中心化）。发布时社区的主流反应是质疑：KV cache 动辄几个 GB，跨机搬运值吗？

2025 年风向逆转。企业把延迟当成业务生死线，模型和流量涨到成百上千 GPU 规模，干扰和耦合扩缩容从「理论缺点」变成「真金白银的浪费」。NVIDIA 在 GTC 2025 发布 Dynamo 编排层（KV 感知路由 + 自动扩缩），vLLM、SGLang、TensorRT-LLM 相继原生支持；Mooncake 拿下 FAST'25 最佳论文；DeepSeek-V3 的官方推理布局就是 3 个 prefill 节点 + 9 个 decode 节点（每节点 8 张 H100）。开源侧的标志性事件：SGLang 用 96 张 H100（3 节点 prefill + 9 节点 decode）在 DeepSeek-R1 上达到 52.3k 输入 TPS 与 22.3k 输出 TPS，成为首个追平 DeepSeek 官方数据的开源实现。

2026 年，分离思想从软件渗进硬件：NIXL 成为事实传输标准，llm-d 把分离部署做成了 Kubernetes 原生的「好走路径」，NVIDIA 更是发布专为 prefill 设计的 Rubin CPX 芯片——PD 分离不再是一种可选优化，而是数据中心推理的组织原则。Fireworks、Perplexity、Meta、Amazon 等自研栈也全部支持。第三方实测（SemiAnalysis InferenceMax）里，TensorRT-LLM 在 NVL72 上跑 DeepSeek-R1 已超过 60k TPS——一年前这是无法想象的开源外成绩。

分离架构被普遍采纳的这十八个月里，DistServe 团队在回顾博客中给出的判断是：单位 token 的推理成本下降速度，已经远超「摩尔定律两倍」的水平——架构红利比制程红利来得更猛。

四、什么时候值得拆，什么时候千万别拆

PD 分离不是免费午餐：多一池 GPU、多一次 KV 传输、多一套运维。2026 年的实践共识可以收敛成一张决策清单。

值得拆的信号：prompt 长（8k token 以上）且并发高，实测吞吐提升约 1.5–2.5 倍。一个有代表性的账本：Llama 3.1 70B 实测中，「1 张 H100 做 prefill + 1 张 H200 做 decode」达到约 2100 tokens/s、p90 TTFT 约 350ms；对比例子「2 张 H100 混部」只有约 1200 tokens/s、TTFT 约 800ms。前者时薪贵约 45%，吞吐却高 75%——规模化之后每百万 token 成本反而更低；若 prefill 池用竞价实例，总成本几乎与混部持平。

千万别拆的信号：prompt 短于 512 token（prefill 本来就便宜，KV 传输得不偿失）；并发低于 10（批处理收益无从谈起）；7B 以下小模型（KV cache 不构成显存压力）；开发测试环境（运维开销不值）。另外要正视网络门槛：Llama 3.1 70B FP8 在 8k 上下文、batch 8 时每个批次的 KV cache 约 10 GB——万兆以太只够 2k 以下短上下文，百 GbE 是 8k+ 场景的最低配置，长上下文和高并发场景该上 InfiniBand/RoCE。

拆之前先做一步：chunked prefill。把长 prompt 切成小块与 decode 交错调度，单节点不改架构就能拿到 20–40% 吞吐提升。它是混部与完全分离之间的过渡档位——很多场景走到这一步就够了。

五、落地清单：七条实践

1. 先量化 SLO 再谈架构。把 TTFT 和 TPOT 的目标（如 TTFT P90 < 1s、TPOT < 50ms）写下来，用满足 SLO 的 goodput 而不是裸吞吐做决策指标。
2. 从 chunked prefill 起步。vLLM 开启 chunked prefill 并限制单批 token 数，单节点先吃 20–40% 的提升。
3. 过了门槛再拆：长提示 + 高并发 + 延迟敏感三条同时命中，才值得维护两个池。
4. 硬件按阶段画像选：prefill 池看算力（FP8 TFLOPS），decode 池看显存带宽（HBM，H200 约 4.8 TB/s）——分离之后终于可以各选各的，这也是异构省钱空间的来源。
5. 网络先行：估算 KV cache 大小（2 × 层数 × KV 头数 × head_dim × 序列长度 × 每元素字节数），按它倒推网络带宽，生产环境直接上 RDMA。
6. 两池独立扩缩、独立监控：分别盯 prefill 与 decode 的队列深度、KV cache 占用率和节点间传输延迟，容量各自弹性。vLLM 暴露的 num_requests_waiting 与 kv_cache_usage_perc 指标就是现成的观察点。
7. KV 存储外置，打通多轮对话：用 LMCache 或 Mooncake 把 KV 池化，多轮会话与共享前缀直接复用缓存，配合前缀感知路由避免重复 prefill。

结语

PD 分离的故事内核很简单：承认 prefill 和 decode 是两种计算动物，然后让它们各过各的日子。十八个月里，它从「为了搬运 KV cache 而搬运 KV cache」的质疑，走到了写进数据中心组织原则的位置；而分离思想还在继续下沉——attention 与 FFN 的分离（A/F 分离）、decode 专用芯片都在路上。下一次给你的推理服务做容量规划时，先问一句：这两半，真的还该挤在一起吗？

参考资料

• DistServe: Disaggregated Prefill and Decoding for Goodput-optimized Serving（arXiv:2401.09670）——goodput 概念与干扰机制的原始定义
• Disaggregated Inference: 18 Months Later（Hao AI Lab）——PD 分离从被质疑到默认架构的全景回顾
• Mooncake: A KVCache-centric Disaggregated Architecture（arXiv:2407.00079）——Kimi 生产平台的 KVCache 中心化设计
• Disaggregated Serving（NVIDIA Dynamo 文档）——生产级分离部署的编排与传输
• Prefill-Decode Disaggregation on GPU Cloud（Spheron）——2026 年传输标准、网络门槛与成本账
• PD Disaggregation Well-Lit Path（llm-d）——Kubernetes 原生分离部署的推荐路径