PD 分离推理架构详解（全网最全）

PD 分离推理架构的讲解视频可以在这里观看https://www.bilibili.com/video/BV1ZTWAzmEEc本文是 LLM 推理系列的第 6 篇介绍 PD 分离推理架构在大语言模型推理过程中prefill 阶段和 decode 阶段具有截然不同的计算特性prefill 阶段需要并行处理整个输入序列来生成首个 token属于计算密集型操作。decode 阶段则逐个生成后续 token需要频繁访问 KV cache属于内存密集型操作。传统的 continuous batching 将两个阶段混合处理导致相互干扰难以同时满足 TTFT首 token 延迟和 TPOTtoken 间延迟的严格要求。为了解决这一问题PD 分离架构应运而生通过将 prefill 和 decode 分配到不同的 GPU 实例上针对各自特性进行专门优化。这种分离式设计不仅消除了阶段间的干扰还能显著提升系统的有效吞吐量Goodput为大规模 LLM 服务提供了更优的解决方案。1 吞吐量Throughputvs 有效吞吐量Goodput目前大多数 LLM 服务系统如 vLLM、TensorRT-LLM都以吞吐量Throughput 作为主要性能指标——即单位时间内处理的请求数RPS或生成的 token 数。这种度量方式直观并且与成本$/req有直接关联因此被广泛采用。实际上下游应用的类型多种多样它们在用户体验上的延迟需求各异因此需要满足的服务等级目标SLO也存在显著差异。大模型服务中最常用的 SLO 包括TTFT (Time To First Token)首 token 响应延迟直接影响用户的等待体验。TPOT (Time Per Output Token)衡量两个连续生成的 token 之间的平均延迟决定交互的流畅程度。例如实时聊天机器人更关注低 TTFT 以保证响应及时而 TPOT 只需快于人类阅读速度约 250 词/分钟即可相反文档摘要则更强调低 TPOT以便更快地产生完整摘要。单纯依赖 Throughput 作为指标并不能反映延迟表现系统看似处理了大量请求但其中不少未能满足 SLO最终呈现给用户的仍是不理想的服务体验。Throughput吞吐量通常指系统单位时间内处理的 token 数或请求数。很多工作把“提高吞吐量”作为主要优化目标但在实际场景下这并不直接代表用户体验。Goodput有效吞吐量指系统在满足延迟约束如 TTFT/TPOT SLO的前提下真正完成的请求数量。如果一个请求因为延迟过长而被用户放弃或者超过服务约束而无效那么即便它产生了 token也不能算作有效产出。在 DistServe 论文中引入了 Goodput 概念即在满足 SLOTTFT 和 TPOT 要求的前提下每秒完成的有效请求数。与单纯的吞吐量相比Goodput 是更优的衡量指标因为它能够体现请求在满足 SLO 情况下的吞吐水平从而同时反映成本效益与服务质量。为了简要说明 Goodput假设某个应用要求至少 90% 的请求满足 TTFT 200ms 且 TPOT 50ms则可以得到如下定义Goodput (P90 TTFT 200ms 且 P90 TPOT 50ms) 表示在至少 90% 的请求同时满足 TTFT 200ms 和 TPOT 50ms 的条件下系统所能维持的最大每秒请求数。下图展示了一个简单的例子某应用的吞吐量为 10 RPS每秒请求数但由于延迟约束的限制只有 3 RPS 的请求满足 SLO因此该系统的 Goodput 仅为 3 RPS。可以想象用户在这样一个 高吞吐但低 Goodput 的系统中依然会感受到较差的服务体验。2 Prefill 与 Decode 共置导致干扰在 LLM 服务中请求的生命周期通常包含两个阶段prefill生成首个 token和 decode逐步生成后续 token。大多数现有系统如 vLLM、TensorRT-LLM采用 continuous batching 技术将 prefill 和 decode 混合在一起统一批处理。这种方式确实能够提升整体吞吐量但由于两者计算特性和 SLO 目标差异显著将它们共置在同一 GPU 上往往并不理想。如下图所示continuous batching 会带来明显的干扰。当 prefill 和 decode 被放在同一批次时decode 请求的延迟TPOT会被显著拉长而 prefill 请求的首 token 延迟TTFT也会有所增加。图中展示了三种不同的执行方式1PnD棕色柱子1 个 prefill 与 n 个 decode 混合批处理。nD蓝色柱子仅包含 decode 请求的批处理。prefill-only红色虚线仅运行 prefill 请求的延迟。在 prompt 长度为 128 时相比仅包含 decode 的请求延迟增加约 1.8 倍而当 prompt 长度为 1024 时干扰效应显著放大decode 延迟提升至 12.6 倍。由于这种干扰如下图所示当服务必须同时满足 TTFT 和 TPOT 的 SLO 时系统往往需要进行资源的过度配置才能达到延迟目标尤其是在任一 SLO 要求较严格的情况下。3 PD 分离的整体思路直观的思路很简单将 prefill 和 decode 分离到不同的 GPU 上并为每个阶段定制并行策略。这自然解决了前面提到的两个问题没有干扰prefill 和 decode 各自独立运行更快地完成计算也更容易满足各自的 SLO。资源分配与并行策略解耦可以针对 prefill 和 decode 分别进行优化。当一个请求到达系统时它会先被分配到 prefill worker 完成 prefill 阶段随后系统将其中间状态主要是 KV Cache迁移到 decode worker并执行多步 decode 以生成后续 token当生成完成后请求才会离开系统。让我们通过一个简单的实验来看看为什么 PD 分离是有益的。我们在一张 A100-80GB GPU 上运行一个 130 亿参数的 LLM请求到达服从泊松分布输入长度为 512输出长度为 64。我们逐步增加请求速率x 轴并在下图测量两类延迟P90 TTFT 和 P90 TPOTy 轴的变化。假设我们设定 SLOP90 TTFT 0.4 秒P90 TPOT 0.04 秒下图中的横线。实验结果表明在单卡情况下现有系统大约可以在 3 rps 下满足 TTFT 的延迟约束而 TPOT 只能维持在 1.6 rps下图左边。由于必须同时满足两个约束条件现有共置系统的 Goodput min(3, 1.6) 1.6 rps/GPU。在分离之后性能得到了显著提升。如果单独处理一个阶段prefill worker 和 decode worker 的 rps 都优于之前的结果 —— 如下图右边所示一个 prefill worker 大约可达到 5.6 rps一个 decode worker 大约可达到 10 rps。更重要的是我们现在可以灵活地分配资源例如配置 2 个 prefill worker 1 个 decode worker记作 2P1D共 3 张 GPU。此时代码语言javascriptAI代码解释Goodput (2P1D) min(5.6 × 2, 10) 10 reqs/s ÷ 3 GPUs ≈ 3.3 rps/GPU。这个实验表明即便没有引入任何并行优化仅仅通过简单的分离Goodput 就提升了约 2 倍。4 分离式推理架构的优化方向4.1 算力与存储prefill 阶段拥有计算受限的性质compute-bound特别是在请求流量较大用户的 prompt 也比较长的情况下。prefill 阶段算完 KV cache 并发给 decode 阶段后理论上 prefill 就不再需要这个 KV cache 了当然你也可以采用 LRU 等策略对 KV cache 的保存做管理而不是一股脑地清除。decode 阶段拥有内存受限的性质memory-bound因为逐个 token 的生成方式decode 阶段要频繁从内存中读取 KV Cache同时也意味着它需要尽可能保存 KV cache。因此在分离式框架下计算和存储可以朝着两个独立的方向做优化。4.2 Batching 策略prefill 阶段随着 batch size 的增加吞吐量的提升很快趋于平缓。这是因为 prefill 属于 compute-bound当 batch 中的总 tokens 数超过一定规模后GPU 的计算能力已经被完全吃满再增加请求只会延长整体处理时间而不会带来明显的吞吐提升。decode 阶段随着 batch size 的增加吞吐量的增长趋势越来越显著。这是因为 decode 阶段是 memory-bound即相比于计算读写数据的时间要更多。所以在 decode 阶段中如果我们能提升 batch size就能把计算强度提起来吞吐量就上去了。在分离架构下我们可以针对 prefill 和 decode 的特性对 batching 策略分别进行优化具体来说对于 prefill 实例需要事先结合特定的 LLM 和 GPU 做性能分析找出输入长度的临界点——一旦超过这个点prefill 就会进入 compute-bound此时增加 batch size 只会拖慢整体处理速度。在实际应用中用户的 prompt 往往已有数百个 tokens因此prefill 的 batch size 通常保持较小。相对地decode 阶段更适合采用较大的 batch size以充分提升 GPU 利用率和整体吞吐。4.3 并行策略由于 prefill 和 decode 具有不同的计算模式和延迟目标这两个阶段的最佳并行策略通常并不相同。例如当 TTFT 要求严格而 TPOT 要求相对宽松时prefill 更适合采用张量并行来满足低延迟而 decode 则通常采用数据并行或流水线并行来提升吞吐。5 KV Cache 传输PD 分离带来的代价是需要在 prefill 和 decode 的 GPU 之间传输中间状态即 KV cache。接下来我们来看看 KV cache 传输的开销分析、传输方式以及相关的优化策略。5.1 KV Cache 传输开销初看之下KV cache 是 LLM 推理中巨大的内存开销而 GPU 之间 KV cache 的传输似乎会成为瓶颈。然而DistServe 的论文中展示了相反的结果通过合理的放置KV Cache 的传输开销可以被有效地最小化甚至低于一次 decode 步骤的时间这得益于当今高速互联网络如 NVLink 和 PCI-e 5.0。假设我们在 GPU 之间使用 8 通道 PCIe 5.0 x16每条链路 64GB/s作为节点内互联。对于一个包含 2048 tokens 的请求在服务 OPT-175B 时传输 KV cache 的延迟可以估算如下代码语言javascriptAI代码解释Latency 2048 tokens * (4.5 MB/token) / (64GB/s * 8) 17.6 ms对于 OPT-175B延迟小于单次 decode 步骤在 A100 上约为 30-50 毫秒。对于更大的模型、更长的序列或更先进的网络例如带宽为 600GB/s 的 A100-NVLink如下图所示与单次 decoe 步骤相比KV cache 传输相关的相对开销变得不那么显著。总之通过精心安排 prefill 和 decode 工作节点以利用高带宽网络可以有效隐藏 KV cache 传输的开销。5.2 KV Cache 传输方式目前 KV cache 的传输主要有两种方式中心存储和点对点P2P当然在实际系统中也可能采用二者结合的混合方案。中心存储建立一个跨设备的 KV store由它统一管理 KV cache 的增、删、查和传递等操作。prefill 和 decode 实例只需与这个 KV store 交互负责写入或读取数据。P2P 传输每个实例独立管理自己的存储。例如一个 prefill 实例完成计算后会直接与目标 decode 实例建立通信将 KV cache 传过去不依赖统一的中介。两种方式各有优劣中心存储更适合构建大规模集群能充分利用多种存储介质和传输通道并提升计算结果的复用效率但在某些场景下性能可能受限同时系统维护成本较高。P2P 传输架构更简单性能表现通常更好但在扩展性和链路稳定性方面会面临挑战。5.3 KV Cache 传输的网络堆栈现有的物理数据链路可以分为 3 类Direct即 GPU 之间通过高速直连链路如 NVLink 或 HCCS相互连接。在这种情况下可以利用底层的内存拷贝原语或集体通信库来完成数据传输。Direct-NIC即 GPU 通过其配套的网卡NIC进行通信。在这里可以使用定制化的库通过 PCIe 和以太网或 InfiniBand进行数据传输。Indirect即当 GPU 之间没有直接链路时必须通过其 CPU 的 DRAM 中转数据从而带来额外的内存拷贝开销。图片来源Inference without Interference: Disaggregate LLM Inference for Mixed Downstream Workloads5.4 KV Cache 传输粒度KV cache 传输粒度可以分为 3 类请求级等到 prefill 阶段完成后将 KV cache 一次性传输。这种方式的好处是能够减少网络传输次数因为每次传输的数据量更大从而降低了通信开销。然而当 KV cache 大小较大时会影响 TTFT 的延迟。层级Splitwise 通过在 prefill 阶段的计算与 KV cache 传输之间实现重叠来优化性能。每一层计算完成后都会异步传输该层的 KV cache同时继续执行下一层的计算从而降低传输开销。层级传输还能带来额外优势例如更早启动 decode 阶段以及更早释放 prefill 端的内存。层级 KV cache 传输与下一层的 prefill 计算并行进行这需要逐层的细粒度同步以确保正确性因此可能会带来性能干扰并增加 TTFT尤其是在小 prompt 的场景下。不过对于小 prompt 来说KV cache 的总体规模很小不需要层级传输来隐藏延迟。由于在计算开始时批次中的 token 数已经是已知的Splitwise 会选择最合适的 KV cache 传输方式小 prompt 使用序列化传输而大 prompt 使用层级传输。图片来源Splitwise: Efficient Generative LLM Inference Using Phase Splitting块级TetriInfer 在 PD 分离的基础上还会将输入的 prompt 划分为固定大小的 chunk以便让 GPU 始终运行在接近计算饱和的状态。因此TetriInfer 论文中也提出了基于块级的 KV cache 传输方案。6 vLLM 的 PD 分离vLLM 提供了KV Connector作为管理实例间 KV cache 交换的抽象层它提供统一接口来实现 KV cache 的保存、加载与传输使不同的 vLLM 实例如 prefill 与 decode 实例能够高效共享计算结果。通过实现这一接口各类 connector例如通过文件系统的 SharedStorageConnector、通过网络的 NixlConnector 等提供了灵活的 KV cache 传输方案从而支持 PD 分离等高级功能。KVConnectorBase_V1是所有 connector 的基类。它是一个抽象基类定义了以下 APIscheduler 侧方法build_connector_meta构建元数据scheduler 告诉 worker 需要保持/加载哪些 KV cache。get_num_new_matched_tokens获取远端已计算的 KV cache 的 token 数量。update_state_after_allocblock 开辟后更新 connector 的状态。worker 侧方法start_load_kv从 connector buffer 加载 KV cache消费端调用。wait_for_layer_load阻塞直到指定层加载结束消费端调用save_kv_layer将 vLLM 的 KV buffer 中某一层的 KV cache 保存到 connector buffer 中生产端调用。wait_for_save阻塞直到所有保存操作完成生产端调用。vLLM v1 中 connector 有两个执行角色Rolescheduler_connector 和 worker_connector分别在 scheduler 线程和 worker 线程中执行。scheduler 负责指挥 worker 进行 KV cache 的传递两者之间的信息桥梁是元数据KVConnectorMetadataworker 通过 metadata 知道哪些 KV 值需要从远端加载。当前 vLLM 支持 5 种类型的 connector分别是SharedStorageConnectorSharedStorageConnector 是 vLLM 中最简单的 KV Connector 实现它通过共享文件系统如本地磁盘或 NFS在 prefill 和 decode 实例之间传递 KV cache使用 MD5 哈希生成唯一文件名来存储和检索每个请求的 KV cache。prefill 实例将每层的 KV cache 序列化为 SafeTensors 格式保存到指定路径decode 实例根据相同的 token_ids 计算哈希值找到对应文件并加载整个过程没有显式的网络传输完全依赖文件系统的读写操作。P2pNcclConnectorP2pNcclConnector 是基于 NCCLNVIDIA Collective Communications Library实现的高性能 KV Connector它通过 NCCL 的 send/recv 原语实现 KV cache 在不同 GPU 之间的点对点传输避免了文件系统的开销。NixlConnectorNixlConnector 使用 NIXLNVIDIA Inference Xfer Library库来加速 GPU 之间以及异构内存与存储之间的 KV cache 传输。LMCacheConnectorV1通过与 LMCache 集成实现 KV cache 的外部存储和检索支持多种存储后端如 CPU 内存、本地文件系统、Redis、 InfiniStore 等。LMCache 通过重用缓存的 KV cache 来减少推理时间消除冗余计算适用于跨请求或跨会话的 KV cache 共享场景。MultiConnector允许同时使用多个 KV connector 来实现 KV cache 的传输它的核心逻辑是从第一个能提供可用 token 的 connector 加载 KV cache但会向所有 connector 保存数据。MultiConnector 适用于需要同时向多个存储后端保存 KV cache 的场景比如同时保存到本地存储和远程存储提供数据冗余和可靠性保障。代码语言javascriptAI代码解释--kv-transfer-config { kv_connector: MultiConnector, kv_connector_extra_config: { connectors: [ { kv_connector: NixlConnector, kv_role: kv_both }, { kv_connector: SharedStorageConnector, kv_connector_extra_config: { shared_storage_path: local_storage }, kv_role: kv_both } ] }, kv_role: kv_both }以上几个 connector 的运行实例代码可以在这里找到https://docs.vllm.ai/en/latest/features/disagg_prefill.html#usage-example7 PD 分离工业界项目7.1 MooncakeMooncake 是 Moonshot AI 提供的领先大模型服务 Kimi 的推理平台。Mooncake 是 PD 分离应用比较早也是规模比较大的成功例子Mooncake 采用了以 KV cache 为核心的解耦架构将 prefill 集群与 decode 集群分离。同时它还利用 GPU 集群中未被充分利用的 CPU、DRAM 和 SSD 资源实现了解耦式的 KV cache 缓存。Mooncake 的核心是一个以 KV cache 为中心的调度器它在最大化整体有效吞吐量和满足延迟相关的 SLO 之间进行平衡。与传统假设所有请求都会被处理的研究不同Mooncake 需要应对高负载场景带来的挑战。为此Mooncake 提出了一种基于预测的早期拒绝策略。图片来源Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving实验结果表明Mooncake 在 长上下文场景下表现尤为突出在某些模拟场景中吞吐量相比基线方法最高可提升 525%同时仍能满足 SLO。在真实负载下Mooncake 的创新架构使 Kimi 能够多处理 75% 的请求。使用 Mooncake 运行 PD 分离服务请参考文档vLLM V1 Disaggregated Serving with Mooncake Store and LMCache7.2 DynamoNVIDIA Dynamo 是一个开源的模块化推理框架用于在分布式环境上实现生成式 AI 模型的服务化部署。Dynamo 通过动态资源调度、智能路由、内存优化与高速数据传输无缝扩展大型 GPU 集群之间的推理工作负载。Dynamo 采用推理引擎无关的设计支持 TensorRT-LLM、vLLM、SGLang 等包括以下 4 个核心组件NVIDIA Dynamo Planner一个智能规划和调度引擎用于监控分布式推理中的容量与延迟并在 prefill 与 decode 阶段之间灵活分配 GPU 资源以最大化吞吐量和效率。Planner 会持续跟踪关键的 GPU 容量指标并结合应用的 SLO如 TTFT 和 ITL智能决策是否采用分离式推理或是否需要为 prefill/decode 阶段动态增加更多 GPU。NVIDIA Dynamo Smart RouterKV cache 感知的路由引擎可在分布式推理环境中将请求转发到最佳的节点从而最大限度减少 KV cache 的重复计算开销。NVIDIA Dynamo Distributed KV Cache Manager通过将较旧或低频访问的 KV cache 卸载到更低成本的存储如 CPU 内存、本地存储或对象存储等大幅降低 GPU 内存占用。借助这种分层管理开发者既能保留大规模 KV cache 重用的优势又能释放宝贵的 GPU 资源从而有效降低推理计算成本。**NVIDIA Inference Transfer Library (NIXL)**高效的推理数据传输库可加速 GPU 之间以及异构内存与存储之间的 KV cache 传输。通过减少同步开销和智能批处理NIXL 显著降低了分布式推理中的通信延迟使得在 prefill/decode 分离部署时prefill 节点也能在毫秒级将大批量的 KV cache 传输至 decode 节点从而避免跨节点数据交换成为性能瓶颈。在 Dynamo 的 PD 分离架构中有 4 个核心组件(decode) worker执行 prefill 和 decode 请求。prefill worker只执行 prefill 请求。disaggregated router决定 prefill 阶段是在本地还是远程执行。prefill queue缓存并负载均衡远程 prefill 请求。当 worker 收到请求时首先会通过 disaggregated router 判断 prefill 应该在本地还是远程完成并分配相应的 KV block。 如果选择远程 prefill请求会被推送到 prefill queue。随后prefill worker 从队列中取出请求读取 worker 中 prefix cache 命中的 KV block执行 prefill 计算并将生成的 KV block 回写给 worker。最后worker 会继续完成剩余的 decode 阶段。Dynamo 提供了 Operator 方便我们在 Kubernetes 环境中以声明式的方式定义 PD 分离服务。只需在DynamoGraphDeployment配置中声明 Frontend、VllmDecodeWorker 和 VllmPrefillWorker 三个组件即可。dynamoNamespace是 Dynamo 分布式运行时的逻辑隔离单元而非 Kubernetes 的 namespace同一dynamoNamespace内的组件可以相互发现并进行通信。代码语言javascriptAI代码解释apiVersion: nvidia.com/v1alpha1 kind:DynamoGraphDeployment metadata: name:vllm-disagg spec: services: Frontend: dynamoNamespace:vllm-disagg componentType:frontend replicas:1 extraPodSpec: mainContainer: image:nvcr.io/nvidia/ai-dynamo/vllm-runtime:0.4.1 VllmDecodeWorker: dynamoNamespace:vllm-disagg componentType:worker replicas:1 resources: limits: gpu:1 extraPodSpec: mainContainer: image:nvcr.io/nvidia/ai-dynamo/vllm-runtime:0.4.1 workingDir:/workspace/components/backends/vllm command: -/bin/sh --c args: -python3 -m dynamo.vllm --model Qwen/Qwen3-0.6B VllmPrefillWorker: dynamoNamespace:vllm-disagg componentType:worker replicas:1 resources: limits: gpu:1 extraPodSpec: mainContainer: image:nvcr.io/nvidia/ai-dynamo/vllm-runtime:0.4.1 workingDir:/workspace/components/backends/vllm command: -/bin/sh --c args: -python3 -m dynamo.vllm --model Qwen/Qwen3-0.6B --is-prefill-workerDynamo 详细的部署教程可以参考博客https://cr7258.github.io/blogs/original/2025/20-dynamo#_3-%E8%BF%90%E8%A1%8C-dynamo7.3 llm-dllm-d 是一个 Kubernetes 原生的分布式推理服务栈为团队提供一条清晰高效的路径以最快的落地速度在大规模环境中部署并管理推理服务。llm-d 通过集成业界标准的开源技术来加速分布式推理使用 vLLM 作为模型服务与引擎Inference Gateway 作为请求调度器与负载均衡器Kubernetes 作为基础设施编排与工作负载控制平面。llm-d 提供以下核心功能基于 vLLM 优化的推理调度器llm-d 基于 IGW 的 Endpoint Picker Protocol (EPP) 实现可定制化的“智能”负载均衡专门针对 vLLM 进行优化。调度器结合运行时遥测数据利用过滤和打分算法在 P/D 分离、KV cache、SLA 与负载感知的基础上做出调度决策同时支持团队自定义策略。PD 分离llm-d 利用 vLLM 的分离式推理能力将 prefill 和 decode 拆分到独立实例运行并通过高性能传输库如 NIXL进行通信。分布式 KV cachellm-d 使用 vLLM 的 KV connector 构建可插拔的 KV cache 层级体系支持将 KV cache 卸载到主机、远程存储或 LMCache 等系统。使用 llm-d 运行 PD 分离服务请参考https://github.com/llm-d/llm-d/tree/main/guides/pd-disaggregation7.4 AIBrixAIBrix 是字节跳动开源的云原生分布式推理框架专为大规模 LLM 部署设计。AIBrix 支持 LoRA 管理、前缀感知和负载感知的智能路由并通过分布式 KV cache 实现跨节点的高效 token 复用。在系统编排层面AIBrix 结合 Kubernetes 与 Ray 的混合调度既能满足大规模集群管理的需求又能灵活执行细粒度任务。AIBrix 基于 SLO 的 GPU 优化器与诊断工具进一步提升了资源利用率和系统可靠性。使用 AIBrix 运行 PD 分离服务请参考https://github.com/vllm-project/aibrix/tree/main/samples/disaggregation/vllm8 Chunked-Prefills VS PD 分离chunked-prefills 方案的核心思想是将长序列的 prefill 请求拆分为几乎相等大小的小块然后构建了由 prefill 小块和 decode 组成的混合 batch。或者说chunked-prefills 策略通过将不同长度的 prompts 拆分成长度一致的 chunks 来进行 prefill以避免长 prompt 阻塞其他请求同时利用这些 chunks 的间隙进行 decode 的插入/捎带piggyback操作从而减少延迟并提高整体的吞吐。decode 阶段的开销不仅来自从 GPU 内存中获取 KV cache还包括提取模型参数。而通过这种 piggyback 方法decode 阶段能够重用 prefill 时已提取的模型参数几乎将 decode 阶段从一个以内存为主的操作转变为一个计算为主的操作。因此这样构建的混合批次具有近乎均匀的计算需求而且增加了计算密集性使我们能够创建平衡的微批处理调度缓解了迭代之间的不平衡导致 GPU 的管道气泡最小化提高了 GPU 的利用率。也最小化了计算新 prefill 对正在进行的 decode 的 TBT 的影响从而实现了高吞吐量和低 TBT 延迟。chunked-prefills 有两个明显的好处所有节点被平等对待使调度更简单。将 chunked prefill 内联到 decode 批处理中可以提高 decode 批次的计算强度从而带来更好的 MFUModel FLOPs Utilization指的是模型实际使用的计算量占 GPU 理论峰值算力的比例用来衡量算力利用效率。然而chunked-prefills 也有一些缺点chunked-prefills 会增加 prefill 的计算开销如果 chunk 大小明显低于 GPU 饱和点会延长 prefill 的执行时间。prefill 阶段仍难以完全最大化 MFU因为在 chunk-prefill 中profiling 只会估算特定设备上一个 batch 的最大 tokens 配额这个配额同时包含 prefill 和 decode而不是分别针对两者优化。chunked-prefills 也会显著增加 prefill 阶段的内存访问量每个 chunk 的 Attention 操作都需重复读取此前的 KV cache增加内存访问负担。而且长序列可能会持久地占据着 KV cache 的存储空间以及 GPU 的计算资源。在 TPOT 方面将 prefill 与 decode 合并批处理实际上会降低所有 decode 任务的平均速度。总之chunked-prefills 可能有助于最大化整体吞吐量但由于动态分割无法完全解耦 prefill 和 decode 操作会导致资源争用以及 TTFT 与 TPOT 之间的妥协。当应用程序无法在 TTFT 和 TPOT 之间进行权衡而是要同时遵守这两者时PD 分离就成为更好的选择。9 PD 分离相关论文DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model ServingSplitwise: Efficient Generative LLM Inference Using Phase SplittingTetriInfer: Inference without Interference:Disaggregate LLM Inference for Mixed Downstream WorkloadsMemServe: Context Caching for Disaggregated LLM Serving with Elastic Memory PoolMooncake: A KVCache-centric Disaggregated Architecture for LLM Serving10 总结PD 分离大模型推理中的一种架构优化策略核心思想是把 prefill 阶段和 decode 阶段分开由不同的 GPU 或实例分别承担。通过分离架构系统可以针对 prefill计算密集型和 decode内存密集型的不同特性分别优化资源配置和并行策略从而在满足 TTFT 和 TPOT SLO 约束的前提下显著提升有效吞吐量Goodput。虽然 PD 分离需要在 GPU 间传输 KV Cache但通过高速互联网络和优化的传输策略这一开销可以被有效隐藏。目前vLLM、Mooncake、Dynamo 等主流推理框架都已支持 PD 分离为大规模 LLM 服务提供了更高效的解决方案。相比于 chunked-prefills 等替代方案PD 分离在需要同时满足严格 TTFT 和 TPOT 要求的场景下具有明显优势。11 参考资料Lecture 58: Disaggregated LLM Inferencehttps://www.youtube.com/watch?vtIPDwUepXcAThroughput is Not All You Need: Maximizing Goodput in LLM Serving using Prefill-Decode Disaggregationhttps://hao-ai-lab.github.io/blogs/distserve/Mooncake阅读笔记深入学习以Cache为中心的调度思想谱写LLM服务降本增效新篇章https://zhuanlan.zhihu.com/p/706097807探秘Transformer系列之26--- KV Cache优化 之 PD分离or合并https://www.cnblogs.com/rossiXYZ/p/18815541大模型推理分离架构五虎上将https://zhuanlan.zhihu.com/p/706218732LLM关于PD分离的最新实测https://zhuanlan.zhihu.com/p/1919794916504114120State of the Model Serving Communities - August 2025https://inferenceops.substack.com/p/state-of-the-model-serving-communities图解大模型训练系列序列并行1Megatron SPhttps://zhuanlan.zhihu.com/p/4083427292序列并行做大模型训练你需要知道的六件事https://zhuanlan.zhihu.com/p/698031151vLLM PD分离KV cache传递机制详解与演进分析https://zhuanlan.zhihu.com/p/1906741007606878764vLLM PD分离方案浅析https://zhuanlan.zhihu.com/p/1889243870430201414P/D Disaggregation of vLLM and Integration with Mooncakehttps://docs.google.com/document/d/1Ab6TMW1E2CdHJJyCrpJnLhgmE2b_6leH5MVP9k72sjw/edit?tabt.0#headingh.611v2r4aqubz0.5x提升:PD分离KV cache传输的实践经验https://zhuanlan.zhihu.com/p/1946608360259577576分布式推理优化思路http://zhuanlan.zhihu.com/p/1937556222371946860图解大模型计算加速系列分离式推理架构2模糊分离与合并边界的chunked-prefillshttps://zhuanlan.zhihu.com/p/710165390图解大模型计算加速系列分离式推理架构1从DistServe谈起https://zhuanlan.zhihu.com/p/706761664LLM推理优化 - Prefill-Decode分离式推理架构https://zhuanlan.zhihu.com/p/9433793184Shaping NIXL-based PD Disaggregation in vLLM V1https://blog.lmcache.ai/2025-04-11-lmcache-vllmv1-nixl/vLLM P2P NCCL Connectorhttps://docs.vllm.ai/en/latest/design/p2p_nccl_connector.htmlvLLM Disaggregated Prefilling (experimental)https://docs.vllm.ai/en/latest/features/disagg_prefill.htmlLMCache Example: Disaggregated prefillhttps://docs.lmcache.ai/getting_started/quickstart/disaggregated_prefill.htmlBringing State-Of-The-Art PD Speed to vLLM v1 with LMCachehttps://blog.lmcache.ai/2025-04-29-pdbench/Demystify vLLM V1 KVconnector SharedStorageConnectorhttps://blog.diabloneo.com/demystify-vllm-v1-kvconnector-sharedstorageconnector-05a487627036vLLM源码之分离式架构https://zhuanlan.zhihu.com/p/1933647687vLLM v1 PD分离设计https://zhuanlan.zhihu.com/p/1894425784107632241Inside vLLM: Anatomy of a High-Throughput LLM Inference Systemhttps://blog.vllm.ai/2025/09/05/anatomy-of-vllm.html[P/D][V1] KV Connector API V1https://github.com/vllm-project/vllm/pull/15960vLLM PD Disaggregation discussionhttps://docs.google.com/document/d/1uPGdbEXksKXeN4Q9nUm9hzotqEjQhYmnpAhidLuAsjk/edit?tabt.0#headingh.qhtgj3vmvwnllm-d: Kubernetes-native Distributed Inference at Scalehttps://github.com/llm-d/llm-d/blob/dev/docs/proposals/llm-d.md