文档(金鹏): 2026-08-06 章节 48 篇文章摘要归档

- 46 篇原文+摘要双文件归档（按来源/作者分层，复用本地归档 20 篇+新抓取 26 篇） - 即梦生成 9 组主题配图（大图+列表缩略图）存入知识/金鹏/20260806/ - 章节重组为 9 个主题分组并挂接摘要引用
2026-08-06 18:00:50 +08:00
parent aa585542d1
commit c0ba3fb853
111 changed files with 13271 additions and 0 deletions
@@ -0,0 +1,197 @@
+# 大模型学习 | 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. ^一些关键延迟和量级见上面的表格（没搞明白怎么把表格插注释里只能这样……）