# 【大模型】深入解析大模型推理架构之 Prefill-Decode Disaggregation (PD分离)

> **来源**：CSDN 博客  
> **作者**：烟锁池塘柳0  
> **发布日期**：2025-07-21  
> **原文链接**：https://blog.csdn.net/Zlyzjiabjw547479/article/details/149499063

---

## 深入解析大模型推理架构之 Prefill-Decode Disaggregation (PD分离)

### 1 从统一到分离，推理架构为何演进？

在标准的大型语言模型推理流程中，整个生成任务，从处理用户输入（Prompt）到逐字生成回答，通常都在同一个GPU上完成。这种统一式架构（Unified Architecture）虽然简单，但随着模型规模和并发请求量的激增，其固有的低效率问题逐渐暴露。

问题的根源在于，LLM推理的两个核心阶段——**Prefill**和**Decode**——在计算特性上存在根本性的差异：

1. **Prefill (预填充) 阶段**:

   - **任务**: 并行处理输入的整个Prompt，为其所有Token计算Key和Value，并生成初始的KV Cache。
   - **特性**: 这是**计算密集型 (Compute-Bound)** 任务。计算量巨大，涉及大量的矩阵乘法，可以充分利用GPU强大的并行计算能力（高TFLOPS）。处理一个包含512个Token的Prompt，其计算量可能相当于生成512个Decode步骤的总和。
2. **Decode (解码) 阶段**:

   - **任务**: 逐个生成输出Token。每次只处理一个Token，但需要加载整个模型权重和不断增长的KV Cache。
   - **特性**: 这是**内存带宽密集型 (Memory-Bandwidth-Bound)** 任务。单步计算量小，但需要频繁、大量地从GPU显存中读写数据。其瓶颈在于显存的带宽，而非GPU的计算核心。

> 关于大模型推理中的Prefill、Decode与KV Cache等概念的介绍，请参考我的这篇文章：【大模型】大模型推理中的Prefill、Decode与KV Cache详解 。

在统一式架构中，昂贵且计算能力强大的GPU在执行Decode任务时，其计算单元大部分时间处于空闲状态，等待数据从显存中加载，造成了巨大的资源浪费。反之，当GPU忙于一个长Prompt的Prefill时，其他等待Decode的短任务则必须排队，导致系统整体响应变慢。

为了解决这种资源错配和效率瓶颈，**Prefill-Decode分离（PD分离）**的思想应运而生。其核心目标是：**为不同计算特性的任务匹配最合适的硬件资源，实现系统整体性能的最大化。**

### 2 什么是Prefill-Decode分离？

**Prefill-Decode分离**是一种先进的LLM服务架构，它将推理过程中的Prefill和Decode两个阶段，从物理上或逻辑上调度到不同的、专门优化的硬件集群（或资源池）中执行。

一个典型的PD分离系统架构如下：

- **路由/调度器 (Router/Scheduler)**: 系统的"大脑"，负责接收所有请求，并根据请求类型（是新的Prompt还是正在进行的生成任务）将其分发到合适的集群。
- **Prefill集群**: 由少量但计算能力极强的GPU（如NVIDIA H100/H200）组成，专门用于高效地处理新请求的Prefill阶段。
- **Decode集群**: 由大量GPU组成，这些GPU可能算力不是最顶尖，但拥有高内存带宽（如NVIDIA A100），性价比更高，专门用于处理Decode阶段。
- **KV Cache传输层**: 这是连接两个集群的桥梁，通常是基于高速网络（如RDMA、NVLink）的分布式内存系统或高速网络文件系统，用于在Prefill和Decode节点之间快速传递KV Cache。

### 3 PD分离系统的工作流程

一个用户请求在PD分离架构中的生命周期如下：

1. **请求到达与Prefill调度**: 用户的新请求（包含Prompt）到达系统。调度器识别出这是一个需要Prefill的任务，并将其分配给Prefill集群中的一个空闲节点。
2. **Prefill执行**: Prefill节点接收到Prompt后，利用其强大的并行计算能力，对Prompt中的所有Token进行一次批处理计算，生成初始的KV Cache和响应的第一个Token。
3. **KV Cache迁移 (核心步骤)**: Prefill任务完成后，生成的KV Cache（可能高达数GB）以及相关的请求状态信息，被迅速打包并通过高速传输层从Prefill节点发送出去。
4. **Decode调度与执行**: 与此同时，调度器将这个"已预处理"的请求（现在携带了KV Cache的引用或实体）分配给Decode集群中的一个可用节点。Decode节点加载这个KV Cache，然后进入自回归生成循环。在每一步，它只为新的一个Token进行计算，从显存中读取模型权重和完整的KV Cache，然后将新生成的(K,V)对追加到Cache中，并将生成的Token流式传输给用户。
5. **生成结束与资源释放**: 当生成过程完成（例如，模型输出了结束符`[EOS]`），结果被完整地返回给用户。Decode节点上为该请求分配的资源，特别是宝贵的KV Cache显存，被立即释放，以便服务于下一个等待中的Decode任务。

### 4 PD分离的优势

1. **极致的资源利用率与性价比**: 可以为Prefill配置少量昂贵的顶级算力卡，为Decode配置大量性价比更高的带宽型卡。硬件成本可以得到显著优化，避免了让昂贵的计算单元在Decode阶段"无所事事"。
2. **更高的系统吞吐量**: 解耦了Prefill和Decode的执行过程。Prefill集群可以持续不断地处理新涌入的请求（提高系统接纳新用户的能力），而Decode集群则专注于为大量并发用户快速生成后续Token。两者互不阻塞，系统整体的并发处理能力（Throughput）大幅提升。
3. **灵活的扩展性 (Scalability)**: 可以根据业务负载的实际情况独立扩展两个集群。如果业务场景多为长篇问答（长Prompt），可以增加Prefill集群的节点；如果多为简短的聊天（长对话历史），则可以增加Decode集群的节点。
4. **优化的延迟表现**:

   - **降低首字延迟 (TTFT)**: 专用的Prefill集群可以通过更大的批处理（Batching）规模，更高效地处理Prompt，从而加快第一个Token的生成速度。
   - **保障字间延迟**: Decode集群的专用性确保了正在生成中的任务不会被耗时长的Prefill任务抢占，从而获得稳定、快速的后续Token生成体验。

### 5 挑战与相应的解决方案

PD分离架构虽好，但也带来了新的技术挑战：

- **挑战1: KV Cache传输开销**

  - **问题**: KV Cache可能非常大，在不同物理节点间传输它会引入不可忽视的延迟，可能抵消掉分离带来的部分收益。
  - **解决方案**:
    - **硬件层面**: 采用支持RDMA（远程直接内存访问）的InfiniBand或RoCE等超低延迟网络。
    - **软件层面**: 使用**KV Cache量化**，例如将FP16的Cache压缩为INT8或INT4，显著减小其体积。
    - **调度层面**: 设计智能调度算法，尝试将同一个长对话的连续轮次的Prefill和Decode任务调度到物理位置相近的节点上。
- **挑战2: 复杂的调度系统**

  - **问题**: 调度器需要管理两个异构资源池，并处理任务在它们之间的状态交接，其设计和实现复杂度远高于传统调度器。
  - **解决方案**: 需要构建一个全局的、状态感知的调度系统。该系统不仅要监控节点负载，还要能够预测任务时长，并对KV Cache的传输进行协同调度，以实现全局最优。
- **挑战3: 资源孤岛与负载均衡**

  - **问题**: 如果流量模式剧烈变化，可能导致一个集群（如Prefill）过载，而另一个（Decode）处于空闲，形成暂时的资源孤岛。
  - **解决方案**: 引入**动态资源分配**机制，允许部分硬件根据需要灵活地在Prefill和Decode角色之间切换。或者，采用更精准的负载预测模型来提前调整资源池大小。

### 6 总结与展望

Prefill-Decode分离是LLM推理系统从"作坊式"走向"工业化"的重要一步。它体现了计算体系结构中的一个经典思想：**用专门化的组件处理专门化的任务**。通过将Prefill的计算密集型特性与Decode的访存密集型特性解耦，并为之匹配最优化的硬件，PD分离架构能够显著提升大型语言模型服务的吞吐量、降低成本，并优化延迟。

虽然实现上存在挑战，但随着Orca、Sarathi等研究系统的提出和业界实践的深入，PD分离正逐渐成为超大规模AI计算中心的主流架构范式。未来，它还将与投机性解码（Speculative Decoding）、模型混合（MoE）等更多先进技术融合，共同推动AI普惠化的进程。

---

**标签**：#人工智能 #深度学习 #语言模型