LLM 推理 · PD 分离部署架构

大模型服务 PD 分离部署原理与架构详解：
为什么要把 Prefill 和 Decode 拆开跑？

Prefill 吃算力、Decode 吃带宽——把两阶段拆到独立 GPU 池，goodput 最高提升 4.48 倍

大模型推理天然分两段：Prefill（预填充）先把你的输入「读懂」，Decode（解码）再一个字一个字往外吐。这两段的资源需求几乎相反——Prefill 是计算密集型（吃 GPU 算力），Decode 是访存密集型（吃显存带宽）。把它们混在同一批 GPU 上跑，就像把举重和马拉松安排在同一块场地，互相干扰、两头不讨好。

PD 分离（Prefill-Decode Disaggregation）就是把这两人分开：Prefill 交给一群算力强的高性能 GPU，Decode 交给另一群（甚至可以是更便宜、更低功耗的）GPU，中间用高速网络传递 KV Cache。

业界数据已经证明它的价值：

下面从原理到架构、从传输方案到落地建议，一次讲清。

两阶段本质

一、先搞懂两阶段：Prefill 和 Decode 的本质差异

一次完整的 LLM 推理，其实分为性质完全不同的两段：

Prefill（预填充）：读懂输入

Decode（解码）：逐字输出

维度PrefillDecode
任务并行处理输入，生成 KV Cache + 首 token自回归逐 token 生成
瓶颈计算密集（GPU 算力）访存密集（显存带宽）
并行度高（整段并行）低（逐 token 串行）
对应延迟指标TTFT（首 token 延迟）TPOT（每 token 延迟）
对硬件的要求算力强、矩阵计算快显存带宽大即可，算力可以弱

记住这张表，后面所有的「为什么」都源自这两行的反差。

分离动机

二、为什么要分离：合池部署的三大原罪

传统做法（vLLM 等默认的合池模式）把 Prefill 和 Decode 放在同一批 GPU 上。它有三个绕不开的问题：

1. 资源需求冲突：要算力的和要带宽的抢同一张卡

Prefill 阶段 GPU 算力拉满但带宽吃不满，Decode 阶段带宽吃满但算力闲置。合池时，任何一张卡都无法同时让两者满意——要么算力配少了 TTFT 超标，要么带宽配少了 TPOT 超标，要么两者都配足但总有一半资源在空转。

2. SLO 互踩：TTFT 和 TPOT 此消彼长

DistServe 论文点破了合池的困局：在严格的延迟约束下，现有系统必须牺牲一个延迟来保另一个。一个超长 prompt 的 Prefill 会阻塞整批 Decode（首 token 慢、吞吐抖动），而 Decode 占满显存又反过来挤压 Prefill 的可用 KV Cache 空间。

3. 调度耦合：批处理策略没法各自优化

Prefill 适合大 batch（并行度高），Decode 适合小而持续的 batch（受显存限制）。合池时只能用一个折中的 batch 策略，两头都优化不到位；扩缩容也只能整池一起扩，无法针对瓶颈单独加卡。

结论：分开，才能各自按需配置硬件、按需调度、按需扩缩容。

架构组成

三、PD 分离架构长什么样

一个标准的 PD 分离架构由四部分组成：

模块职责
Prefill 实例池只做预填充：生成 KV Cache 和首 token
Decode 实例池只做解码：接收 KV Cache，逐 token 生成
KV Cache 传输层把 KV Cache 从 Prefill 侧搬到 Decode 侧（架构的核心代价所在）
调度器 / 路由请求路由（KV-aware routing）、弹性扩缩容、负载均衡

请求的完整旅程：

用户请求 → 调度器路由
              ↓
        Prefill 实例（算力强）
              ↓ 计算 KV Cache + 首 token
        【KV Cache 跨机传输】（RDMA / 零拷贝）
              ↓
        Decode 实例（带宽大）
              ↓ 逐 token 生成，流式返回

两个进阶设计：

KV 传输难题

四、关键难题：KV Cache 怎么跨机传？

PD 分离不是没有代价的。腾讯云的一篇文章说得很直白：代价是需要在 Prefill 和 Decode 的 GPU 之间传输中间状态（即 KV Cache）。一个长上下文的 KV Cache 动辄几 GB 到几十 GB，传慢了，省下的时间全赔在传输上。业界的主流解法：

1. RDMA / GPUDirect RDMA

数据从发起方显存/内存零拷贝直达目标方显存/内存，绕过 CPU，延迟微秒级、带宽吃满网卡。代表：NVIDIA NIXL（NVIDIA Inference Xfer Library）、Mooncake Transfer Engine。

2. 传输与计算重叠（overlap）

TensorRT-LLM 等框架让 KV Cache 的传输与下一段计算流水线并行：Decode 收到第一批 KV 就开始算，剩下的边传边算，把传输延迟「藏」进计算里。

3. 布局适配（staging buffer）

SGLang 的做法：当 Prefill 和 Decode 的张量并行度不一致（如 Prefill TP=4、Decode 等效 TP=1）时，KV 内存布局对不上，先在 Prefill 侧把 KV 头切片汇聚成连续缓冲区整块 RDMA 传输，Decode 侧再散列分发——用一次重组换传输效率。

一句话：PD 分离效果的上限，取决于 KV Cache 传输的速度。没有 RDMA 的普通以太网，会把大半收益吃掉。

业界实现

五、业界实现盘点：从论文到生产

系统/框架出处特点
Splitwise微软，ISCA'24开山之作之一；同构/异构集群设计，Decode 可用低成本低功耗机器
DistServe北大 + UCSD，OSDI'24 最佳论文提出 goodput 概念，按 TTFT/TPOT 分别选 GPU 数与并行策略；国内首篇 PD 分离论文
Mooncake月之暗面 + 清华，FAST'25 最佳论文PD 分离 + KVCache 中心化多级缓存池（DRAM/SSD/RDMA）
NVIDIA DynamoNVIDIA，2025 年 3 月开源数据中心级分布式推理运行时；disaggregated serving + KV-aware routing + 多级 KV 缓存 + 自动扩缩容，NIXL 传输
TensorRT-LLMNVIDIA内置 disaggregated serving，KV Cache 传输与计算重叠
vLLM社区解耦预填充（Disaggregated Prefilling），v1 基于 NixlConnector 的 P2P 模式，可接 LMCache 等第三方 KV connector
SGLang社区进阶到 EPD 分离（见第九节），staging buffer 支持异构 TP
智谱 GLM-5.3-Flash智谱基于 SGLang 专用引擎 + EPD 分离，性能较基线提升约 3 倍
性能数据

六、性能数据汇总：数字说话

来源对比基线成绩
DistServevLLMgoodput 提升 4.48x，或 SLO 严格 10.2x
Splitwise现有合池设计吞吐 +1.4x 且成本 -20%；同预算吞吐 +2.35x
Mooncake未分离架构真实负载多扛 75% 请求，模拟场景吞吐 +525%
智谱 GLM-5.3-Flash自研初始基线端到端性能提升约 3x

规律很明显：并发越高、上下文越长、SLO 越严，PD 分离的收益越大。

代价与挑战

七、PD 分离的代价与挑战（别只看收益）

  1. KV Cache 传输开销：中间状态必须跨机搬，这是硬成本；传输慢则前功尽弃
  2. 网络成为新瓶颈：没有 RDMA/高速互联的集群，不建议强上
  3. 调度复杂度上升：请求路由、KV 路由、弹性扩缩容、故障隔离都要重新设计（Dynamo 这类框架就是来兜这个底的）
  4. 短请求可能亏：短 prompt 时 KV Cache 很小，传输开销占比高，分离收益可能被抵消
  5. 小规模不划算：单机几卡的小集群，拆池后每个池都太小，调度和传输的开销反而占大头
适用场景

八、什么时候该上 PD 分离

场景判断
长上下文服务（文档问答、超长对话）✅ 强烈推荐，收益最大
高并发、流量波动大✅ 独立扩缩容价值高
TTFT/TPOT 双 SLO 严格✅ 分离后才能分别优化
多模态（视觉编码 + 文本生成）✅ 直接上 EPD 分离
有异构硬件（新旧 GPU 混布）✅ Splitwise 式异构集群，成本大降
短 prompt、离线批跑、小集群❌ 收益低，别强上
演进趋势

九、演进趋势：从 PD 到 EPD，再到 PDD

PD 分离还在快速演进：

落地建议

十、落地建议（五条）

  1. 先量化合池痛点：测出自己业务的 TTFT/TPOT 曲线与显存/算力利用率，确认「冲突」真实存在再动手
  2. 网络先行：RDMA / GPUDirect RDMA 是前提，预算优先给网络
  3. 从小规模试点：先拆 1 个 Prefill 实例 + N 个 Decode 实例跑通数据流，再逐步扩池
  4. 借成熟框架：TensorRT-LLM、vLLM、SGLang、Dynamo 都有现成的 disaggregated serving，别从零造轮子
  5. 异构优先：Decode 侧大胆用低成本、大带宽硬件，这才是 PD 分离省钱的核心
总结

十一、写在最后

PD 分离的本质，是把「算力和带宽的错配」从一张卡内、一个池内摊平到整个集群去解决：让算力强的机器专心算，让带宽大的机器专心读，让便宜的存储和高速网络承载中间状态。它不是银弹，但在长上下文、高并发、严 SLO 的时代，它已经是大模型推理服务的默认架构选项之一。

关于向量云：不必自建集群，也能吃到推理架构红利

自建 PD 分离集群，意味着要搞定 RDMA 网络、异构 GPU 调度、KV 传输层——对绝大多数应用团队来说门槛太高。向量云（向量云南京科技有限公司）面向大模型应用落地，依托字节跳动火山方舟能力，把「高效推理 + 低 Token 成本」做成开箱即用的服务：

向量云能力说明
官方授权接入火山方舟官方授权，提供官方 API 与官方 Key
低折扣 Token专属折扣价，用量越大越划算
独享接入点独立接入点，配额与稳定性更有保障
缓存隔离降本缓存隔离机制，把缓存命中红利吃到最大
计费灵活按量计费、即用即扣、不设账期，注册充值 10 元起
协议兼容OpenAI 兼容协议，业务代码几乎零改动

接入方式：注册后获取官方 API Key，把 base_url 指向向量云接入点即可直接调用火山方舟官方模型——推理架构的优化交给平台，成本的优化直接落在你的账单上。

获取 API Key：https://ark.tokenrize.cn/ · 火山方舟官方 API 与 Key 直连，注册即用

一句话总结：Prefill 要算力、Decode 要带宽，PD 分离把它们拆到各自最合适的硬件上——自建可选、平台可用，关键是把资源错配的钱省回来。

关于向量云
向量云（南京）科技有限公司

面向大模型应用落地的技术服务型企业，依托字节跳动火山方舟能力，为合作方提供低折扣模型 Token、可独立部署的运营支撑平台及全链路运营支持。

火山方舟官方授权 官方 API Key 独享接入点 缓存隔离降本 低折扣 Token 即用即扣 · 不设账期

向量云（南京）科技有限公司

火山方舟官方 API · 独享接入点 · 低折扣 Token · 缓存红利最大化

获取 API Key：https://ark.tokenrize.cn/

常见问题（FAQ）

火山方舟官方 API 与官方 Key 直连 · 向量云 · 大模型推理降本

Q1. 什么是 PD 分离（Prefill-Decode Disaggregation）？

A. PD 分离是一种大模型推理部署架构：把推理的 Prefill（预填充，计算密集型）和 Decode（解码，访存密集型）两个阶段从物理上拆开，分配到不同的 GPU 实例池执行。Prefill 池用高算力 GPU 生成 KV Cache 和首 token，Decode 池用大带宽（甚至更低成本）的硬件逐 token 生成，两池之间通过高速网络（RDMA）传递 KV Cache，并可独立扩缩容。

Q2. 为什么要把 Prefill 和 Decode 分开部署？

A. 合池部署有三大问题：① 资源需求冲突——Prefill 吃算力、Decode 吃显存带宽，同一张卡无法同时满足两者；② SLO 互踩——严格的延迟约束下 TTFT（首 token 延迟）与 TPOT（每 token 延迟）此消彼长，必须牺牲一个保另一个；③ 调度耦合——Prefill 适合大 batch、Decode 适合小而持续的 batch，合池只能折中。分离后两阶段可分别配置硬件、分别调度、分别扩缩容。

Q3. PD 分离架构由哪些部分组成？

A. 四部分：① Prefill 实例池（只做预填充，生成 KV Cache 和首 token）；② Decode 实例池（只做解码，接收 KV Cache 逐 token 生成）；③ KV Cache 传输层（把 KV Cache 从 Prefill 侧搬到 Decode 侧，是架构的核心代价所在）；④ 调度器/路由（KV-aware routing、弹性扩缩容、负载均衡）。微软 Splitwise 还提出同构/异构两种集群设计，Decode 侧可用更低成本、低功耗的机器。

Q4. PD 分离中 KV Cache 怎么跨机传输？

A. 主流方案有三种：① RDMA / GPUDirect RDMA 零拷贝传输（如 NVIDIA NIXL、Mooncake Transfer Engine），数据直达目标显存、绕过 CPU；② 传输与计算重叠（overlap），如 TensorRT-LLM 让 Decode 边收边算，把传输延迟藏进计算里；③ 布局适配（staging buffer），如 SGLang 在异构张量并行度下先把 KV 头切片汇聚成连续缓冲区再整块 RDMA。PD 分离效果的上限取决于传输速度，没有 RDMA 的普通以太网会吃掉大半收益。

Q5. PD 分离能带来多大的性能提升？

A. 业界公开数据：DistServe（OSDI'24 最佳论文）相比 vLLM，同等延迟约束下 goodput 提升 4.48 倍，或支持严格 10.2 倍的 SLO；Splitwise（微软，ISCA'24）同构机器下吞吐提升 1.4 倍且成本降 20%，同等预算下吞吐提升 2.35 倍；Mooncake（FAST'25 最佳论文）让 Kimi 多扛 75% 请求；智谱 GLM-5.3-Flash 基于 EPD 分离性能较基线提升约 3 倍。总体规律：并发越高、上下文越长、SLO 越严，收益越大。

Q6. 什么场景适合 PD 分离？什么场景不适合？

A. 适合：长上下文服务（文档问答、超长对话）、高并发且流量波动大、TTFT/TPOT 双 SLO 严格、多模态（可直接上 EPD 分离）、异构硬件混布（成本大降）。不适合：短 prompt、离线批跑、单机几卡的小集群——短请求的 KV Cache 很小、传输开销占比高，小集群拆池后调度与传输开销反而占大头。

Q7. 不打算自建集群，向量云能帮上什么忙？

A. 自建 PD 分离集群需要搞定 RDMA 网络、异构 GPU 调度与 KV 传输层，门槛很高。向量云（向量云南京科技有限公司）依托字节跳动火山方舟官方授权，提供官方 API 与官方 Key、低折扣 Token、独享接入点与缓存隔离降本机制，把「高效推理 + 低成本」做成开箱即用的服务。按量计费、即用即扣、不设账期，注册充值 10 元起，OpenAI 兼容协议业务代码几乎零改动。获取 API Key：https://ark.tokenrize.cn/