arno
c0ba3fb853
- 46 篇原文+摘要双文件归档（按 来源/作者 分层，复用本地归档 20 篇+新抓取 26 篇） - 即梦生成 9 组主题配图（大图+列表缩略图）存入 知识/金鹏/20260806/ - 章节重组为 9 个主题分组并挂接摘要引用
198 lines
10 KiB
Markdown
198 lines
10 KiB
Markdown
# 大模型学习 | PD分离详解
|
||
|
||
> **来源**：知乎专栏
|
||
> **作者**：秋月如珪
|
||
> **发布日期**：2026-02-02
|
||
> **原文链接**：https://zhuanlan.zhihu.com/p/2001354095441757984
|
||
|
||
---
|
||
|
||
## 一、什么是PD分离？
|
||
|
||
**PD分离**（Prefill-Decode Disaggregation）是一种将LLM推理过程中的**预填充（Prefill）阶段**与**解码（Decode）阶段**拆分到不同GPU/AI加速器实例上独立执行的架构设计。
|
||
|
||
在大模型推理中，一个完整的生成过程天然分为两个特征迥异的阶段：
|
||
|
||
**Prefill阶段（计算密集型）**
|
||
|
||
- **任务**：并行处理用户输入的整个Prompt（可能长达数千甚至数万token），计算所有token之间的注意力关系，生成**KV Cache**（键值缓存），并输出**第一个token**。
|
||
- **特征**：计算量大、显存带宽压力相对较小、延迟指标为**TTFT**（Time To First Token，首token延迟，通常要求50-400ms）[1]。
|
||
- **资源需求**：需要强大的计算能力（FLOPS），适合使用**张量并行（Tensor Parallelism）**加速。
|
||
|
||
**Decode阶段（内存密集型）**
|
||
|
||
- **任务**：基于Prefill生成的KV Cache，以**自回归方式**逐个生成后续token（每步只生成一个新token，并将其加入KV Cache继续下一步）。
|
||
- **特征**：计算量小，但**显存带宽消耗极高**（频繁读取完整的KV Cache），延迟指标为**TPOT/TBT**（Time Per Output Token/Token Between Token，通常要求25-55ms）。
|
||
- **资源需求**：需要高显存带宽和大容量显存，适合使用**数据并行（Data Parallelism）**提升吞吐。
|
||
|
||
传统的**Continuous Batching**将两个阶段混合在同一GPU上处理，导致资源竞争和相互干扰。PD分离通过**硬件解耦**，让两个阶段各自运行在最适合的硬件配置和优化策略下。
|
||
|
||
---
|
||
|
||
## 二、为什么需要PD分离？
|
||
|
||
### 1. 混合部署的资源冲突
|
||
|
||
当Prefill和Decode在同一个GPU上混合执行时会发生：
|
||
|
||
- **计算资源争抢**：Prefill的高计算需求会抢占Decode的执行时间，导致TPOT（token间延迟）抖动。
|
||
- **显存压力叠加**：Prefill需要临时缓存大量中间结果，Decode需要常驻整个KV Cache，两者叠加容易导致OOM（显存溢出）。
|
||
- **Batching策略冲突**：Prefill适合**小batch**（计算饱和后增加batch只会延长延迟），而Decode适合**大batch**（提升显存带宽利用率）。混合部署无法在两种策略间取得最优平衡。
|
||
|
||
### 2. SLO（服务等级目标）难以同时满足
|
||
|
||
实验数据显示：在单张A100上运行13B参数模型，当请求速率增加时：
|
||
|
||
- TTFT约束（0.4秒）可支持约**3 RPS**（每秒请求数）
|
||
- TPOT约束（0.04秒）仅能支持约**1.6 RPS**
|
||
|
||
系统的**Goodput**（有效吞吐）由两者最小值决定，即**1.6 RPS/GPU**。混合部署存在明显的性能天花板。
|
||
|
||
### 3. 硬件资源浪费
|
||
|
||
Prefill阶段GPU计算单元满载但显存带宽闲置；Decode阶段显存带宽饱和但计算单元空闲。混合部署导致两种资源都无法充分利用。
|
||
|
||
---
|
||
|
||
## 三、PD分离的核心架构
|
||
|
||
### 基础工作流程
|
||
|
||
```
|
||
请求 → [Prefill Worker: GPU集群A] → KV Cache传输 → [Decode Worker: GPU集群B] → 流式输出
|
||
```
|
||
|
||
1. **请求路由**：新请求首先被路由到Prefill Worker，执行完整的Prompt计算，生成KV Cache和首个token。
|
||
2. **状态迁移**：系统将KV Cache从Prefill Worker传输到Decode Worker（这是PD分离的核心技术挑战）。
|
||
3. **解码生成**：Decode Worker加载KV Cache，持续执行自回归解码，直到生成结束符（EOS）或达到最大长度。
|
||
|
||
### 资源分配优势
|
||
|
||
通过分离，系统可以独立优化两个阶段：
|
||
|
||
- **Prefill集群**：配置高算力GPU（如A100/H100），采用张量并行降低TTFT。
|
||
- **Decode集群**：配置高显存带宽GPU，采用大batch和数据并行提升吞吐。
|
||
|
||
实验表明，简单的**2P1D配置**（2个Prefill GPU + 1个Decode GPU）即可将Goodput提升至**3.3 RPS/GPU**，相比混合部署提升约**2倍**。
|
||
|
||
---
|
||
|
||
## 四、关键技术挑战与优化
|
||
|
||
### 1. KV Cache传输机制
|
||
|
||
Prefill完成后，需要将庞大的KV Cache（可能达数十GB）传输到Decode节点。传输粒度分为三级：
|
||
|
||
| 粒度 | 机制 | 优点 | 缺点 |
|
||
| --- | --- | --- | --- |
|
||
| 请求级 | Prefill完成后一次性传输全部KV Cache | 传输次数少，开销低 | 大Prompt时传输延迟高，影响TTFT |
|
||
| 层级 | 每计算完一层Transformer，立即异步传输该层KV Cache，同时计算下一层 | 传输与计算重叠，延迟隐藏效果好；可提前启动Decode | 小Prompt场景下同步开销可能超过收益（Splitwise方案） |
|
||
| 块级 | 将Prompt分块处理，逐块传输 | 保持GPU计算饱和状态 | 实现复杂度高（TetriInfer方案） |
|
||
|
||
### 2. 高性能传输协议
|
||
|
||
为降低KV Cache传输延迟，业界开发了多种专用Connector：
|
||
|
||
- **SharedStorageConnector**：通过共享文件系统（NFS/本地磁盘）传递，实现简单但延迟高（毫秒级），适合测试环境。
|
||
- **P2pNcclConnector**：基于NVIDIA NCCL实现GPU间点对点直接传输，绕过CPU内存，延迟最低。
|
||
- **NixlConnector**：使用NVIDIA NIXL（Inference Xfer Library）库，支持GPU与异构内存（CPU DRAM、SSD）间的高速传输，实现分层KV缓存。
|
||
- **LMCacheConnector**：支持将KV Cache卸载到远程存储（Redis、InfiniStore），实现跨请求、跨会话的KV Cache复用。
|
||
|
||
### 3. 独立Batching策略
|
||
|
||
- **Prefill侧**：保持**小batch size**（通常1-4个请求）。因为Prompt较长时，GPU计算已饱和，增加batch只会线性增加TTFT而不提升吞吐。
|
||
- **Decode侧**：采用**大batch size**（可达64-128个请求）。因为Decode是显存带宽瓶颈，增大batch能提升计算强度（arithmetic intensity），显著提高吞吐。
|
||
|
||
### 4. 差异化并行策略
|
||
|
||
- **Prefill**：采用**张量并行（TP）**将模型层内部分割到多GPU，降低单层计算延迟，满足严格TTFT要求。
|
||
- **Decode**：采用**流水线并行（PP）**或**数据并行（DP）**，因为Decode对延迟相对不敏感，更适合通过并行提升整体吞吐。
|
||
|
||
---
|
||
|
||
## 五、工业界实践案例
|
||
|
||
### 1. NVIDIA Dynamo
|
||
|
||
Dynamo是NVIDIA开源的推理框架，提供完整的PD分离解决方案：
|
||
|
||
- **Dynamo Planner**：智能监控TTFT和TPOT，动态决策是否启用PD分离及资源配比。
|
||
- **Smart Router**：KV Cache感知的请求路由，最大化缓存命中率。
|
||
- **NIXL库**：专为大模型推理设计的高性能传输库，支持毫秒级大批量KV Cache跨节点传输。
|
||
|
||
部署示例（Kubernetes）：
|
||
|
||
```yaml
|
||
apiVersion: nvidia.com/v1alpha1
|
||
kind: DynamoGraphDeployment
|
||
spec:
|
||
services:
|
||
VllmPrefillWorker:
|
||
replicas: 2 # 2个Prefill实例
|
||
VllmDecodeWorker:
|
||
replicas: 1 # 1个Decode实例
|
||
```
|
||
|
||
### 2. vLLM开源实现
|
||
|
||
vLLM在V1版本中引入了**KVConnector**抽象层，统一支持多种传输后端：
|
||
|
||
- **MultiConnector**：可同时向多个存储后端（本地+远程）写入KV Cache，提供数据冗余。
|
||
- **Disaggregated Serving**：与Mooncake Store、LMCache集成，支持生产级PD分离部署。
|
||
|
||
### 3. llm-d（Kubernetes原生方案）
|
||
|
||
由IBM等贡献的llm-d项目，将PD分离与K8s深度集成：
|
||
|
||
- 基于**Inference Gateway**实现智能负载均衡。
|
||
- 支持通过**NIXL**进行P/D实例通信。
|
||
- 提供声明式API定义PD分离拓扑。
|
||
|
||
### 4. Mooncake（Kimi的推理平台）
|
||
|
||
Mooncake是最早大规模应用PD分离的工业级系统之一：
|
||
|
||
- **架构**：以KV Cache为中心的解耦架构，独立部署Prefill集群与Decode集群。
|
||
- **创新**：利用集群空闲的CPU、DRAM和SSD资源，构建**分层KV Cache缓存池**。
|
||
- **效果**：在长上下文场景中，吞吐量相比基线提升最高达**525%**；真实负载下可多处理**75%**的请求。
|
||
|
||
---
|
||
|
||
## 六、PD分离的适用场景与局限
|
||
|
||
### 最佳适用场景
|
||
|
||
1. **高并发在线服务**：当需要同时满足严格TTFT（用户体验）和TPOT（流式输出流畅度）时，PD分离几乎是目前唯一选择。
|
||
2. **长上下文处理**：Prompt长度差异大（如RAG场景），PD分离可避免长Prefill阻塞短Decode。
|
||
3. **成本敏感场景**：通过为不同阶段配置不同规格GPU（如Prefill用H100，Decode用L40S），显著降低推理成本。
|
||
|
||
### 局限与替代方案
|
||
|
||
- **overhead**：KV Cache传输引入额外延迟（虽然可通过层级传输隐藏）。
|
||
- **系统复杂度**：需要维护两套集群、处理状态同步和故障恢复。
|
||
- **替代方案**：对于延迟要求不极端的场景，**Chunked-Prefills**（将长Prompt分块与Decode交替执行）是更简单的折中方案。
|
||
|
||
---
|
||
|
||
## 七、总结
|
||
|
||
PD分离代表了LLM推理架构从**统一处理**向**阶段特化**演进的重要趋势。通过识别Prefill（计算密集）和Decode（内存密集）的本质差异，该架构打破了传统部署的性能瓶颈，实现了：
|
||
|
||
- **干扰隔离**：两个阶段独立运行，互不影响。
|
||
- **资源最优**：针对不同阶段配置最适合的硬件和并行策略。
|
||
- **吞吐飞跃**：Goodput可提升2-5倍，同时满足延迟SLO。
|
||
|
||
随着长文本（128K+）和多模态大模型的普及，推理负载的异构性将进一步加剧。PD分离不仅是当前的技术热点，更可能成为下一代大模型服务（如GPT-5、Claude 4）的**默认部署范式**。对于需要构建高性能LLM服务的企业和开发者，深入理解并应用PD分离架构已成为必备技能。
|
||
|
||
---
|
||
|
||
| 指标类型 | 测量对象 | 量级 | 典型场景 |
|
||
| --- | --- | --- | --- |
|
||
| 数据中心网络延迟 | 节点间数据包传输时间 | 微秒级 (μs) | GPU间RDMA通信、NVLink传输 |
|
||
| TTFT (Time To First Token)，首token延迟 | 从请求发起到首个token生成的完整时间 | 毫秒级 (ms) | 用户感知的首字响应时间 |
|
||
| TPOT (Time Per Output Token)或TBT（Token Between Token），token间延迟 | 每生成一个token的完整计算时间 | 毫秒级 (ms) | 用户感知的流式输出速度 |
|
||
|
||
## 参考
|
||
|
||
1. ^一些关键延迟和量级见上面的表格（没搞明白怎么把表格插注释里只能这样……）
|