# LLM推理成本直降60%：PD分离在大模型商业化中的关键价值

> **来源**：阿里云开发者社区  
> **作者**：阿里云开发者社区用户（cppkm32z5byce）  
> **发布日期**：2025-09-09  
> **原文链接**：https://developer.aliyun.com/article/1681023

---

> 本文较长，建议点赞收藏，以免遗失。

在 LLM 推理计算中 Prefill 和 Decode 两个阶段的计算/显存/带宽需求不一样，通常 Prefill 是算力密集，Decode 是访存密集。一些场景中 P 和 D 两者分开计算可提升性能。vLLM 是一种主流的推理框架，今天我将主要围绕其 PD 分离场景做讨论，欢迎交流指正！

## 1. Prefill 与 Decode 分离的背景与必要性

在 LLM 推理中，Transformer 架构的自回归特性导致计算过程分为两个阶段：

- **Prefill 阶段**：处理输入提示（prompt），一次性生成所有 Token 的 Key-Value（KV）缓存。该阶段**计算密集**，消耗大量算力。
- **Decode 阶段**：基于 KV 缓存进行自回归迭代生成输出 Token，**访存密集**，对显存带宽要求高。

传统部署方案将 P 和 D 整合在单一实例中，但存在显著缺陷：

- P 阶段显存利用率低（算力需求高但显存闲置）。
- D 阶段算力利用率低（显存需求高但算力闲置）。
- 固定硬件资源下，无法灵活适应动态负载，尤其当输入长度变化或 batch size 增大时效率下降。

为提升资源效率，业界提出 **KV 缓存（KV Cache）机制**，避免重复计算，并衍生出 **P 与 D 分离部署方案**：

- P 实例专注高算力任务，生成 KV 缓存。
- D 实例专注高带宽任务，消费 KV 缓存生成输出。

![Image 1: 48cbd201f4a44fa2f30e4ee862eec1c7.png](https://ucc.alicdn.com/pic/developer-ecology/cppkm32z5byce_7c7397ef1290467da6f162ae73621df1.png?x-oss-process=image/resize,w_1400/format,webp)

## 2. vLLM 框架中的 PD 分离实现现状

vLLM 作为主流推理框架，其 0.8.x 版本通过 **KV Transfer 机制**支持 PD 分离（1P1D 场景）。核心设计如下：

**工作流程**：

- P 实例以非阻塞方式将生成的 KV 缓存插入缓冲区（LookupBuffer）。
- D 实例以阻塞方式从缓冲区获取 KV 缓存。
- 数据传递通过管道（pipe）实现，支持 PyNCCL 或 Mooncake Store 等通信后端。

![Image 2: image.png](https://ucc.alicdn.com/pic/developer-ecology/cppkm32z5byce_95fc6b9f10914a81bb46b9e62cbe5e24.png?x-oss-process=image/resize,w_1400/format,webp)

![Image 3: da3e4b5df10e74477e783893f3353ad1.png](https://ucc.alicdn.com/pic/developer-ecology/cppkm32z5byce_82e08fe5091541d8a8d2043405c09cba.png?x-oss-process=image/resize,w_1400/format,webp)

**代码实现简化**：

- 通过 KVTransferConfig 配置角色（producer/consumer）和通信参数。
- 示例代码展示 P 和 D 实例的初始化与协同：

```
# Prefill节点配置
ktc = KVTransferConfig.from_cli('{"kv_connector":"PyNcclConnector", "kv_role":"kv_producer", "kv_rank":0, "kv_parallel_size":2}')
llm = LLM(model="meta-llama/Meta-Llama-3.1-8B-Instruct", kv_transfer_config=ktc)
llm.generate(prompts, sampling_params)

# Decode节点配置
ktc = KVTransferConfig.from_cli('{"kv_connector":"PyNcclConnector", "kv_role":"kv_consumer", "kv_rank":1, "kv_parallel_size":2}')
llm = LLM(model="meta-llama/Meta-Llama-3.1-8B-Instruct", kv_transfer_config=ktc)
outputs = llm.generate(prompts, sampling_params)
```

**当前局限**：

- 仅支持 1P1D，缺乏多实例（如 xPyD）和分布式（TP/PP）扩展。
- 未集成负载均衡、自动扩缩容等高级调度功能。
- Chunk Prefill 等优化未适配，需 V1 版本进一步迭代。

## 3. PD 分离设计的关键问题

实现高效 PD 分离需解决以下核心问题：

| **关键点** | **内容** | **说明** |
| --- | --- | --- |
| **a) PD 配比与数量** | a1) 分离与融合的选择 | 短序列/低频请求场景下，融合部署可能更优。 |
|  | a2) P/D 实例初始配比 | 需根据负载动态调整 P 和 D 比例。 |
|  | a3) 实例扩缩容支持 | 集群管理需支持弹性伸缩以提升资源利用率。 |
|  | a4) 角色互换可行性 | 闲置 P 实例可转为 D 实例（反之亦然），实现资源复用。 |
| **b) 请求调度** | b1) 调度亲和性 | 减少 P 与 D 间通信延迟，例如就近部署实例。 |
|  | b2) 负载均衡 | 多 P 多 D 时需均衡实例负载。 |
|  | b3) 网络均衡 | 避免 KV 传输导致网络阻塞，需平衡计算与带宽。 |
|  | b4) Batch 分配策略 | P 阶段适合小 batch，D 阶段适合大 batch。 |
| **c) KV 存储设计** | c1) 存储介质 | 显存（HBM）、内存、SSD 或远端存储（如 S3），需权衡速度与容量。 |
|  | c2) 传输方式 | RDMA（NCCL/HCCL）、TCP/RPC 等，影响传输效率。 |
| **d) Cache 复用** | d1) 存储位置 | 显存速度快但容量小，内存/SSD 容量大但延迟高。 |
|  | d2) 保存/加载策略 | P 阶段生成 KV 后保存，D 阶段直接加载，减少重复计算。 |
|  | d3) 共享范围 | 是否支持跨节点全局共享 Cache。 |
|  | d4) 淘汰机制 | LRU 等策略处理 Cache 溢出。 |
| **e) 可靠性** | e1) 实例故障恢复 | P/D 实例故障时需保证服务连续性。 |
|  | e2) 网络健壮性 | 增强控制链路容错能力。 |

## 4. 主流 PD 分离方案分析

### 4.1 Connector-Base 方案

**架构**：每个 vLLM 进程部署两类连接器（Connector）：

- **Scheduler Connector**：与调度器同进程，决定 KV 缓存传输逻辑。
- **Worker Connector**：与 Worker 同进程，执行 KV 传输操作。

![Image 4: image.png](https://ucc.alicdn.com/pic/developer-ecology/cppkm32z5byce_d68524542e9c4dbba5ff871affbb91d7.png?x-oss-process=image/resize,w_1400/format,webp)

**异步传输流程**：

1. Router 发送 Prefill 请求至 Prefiller。
2. Prefiller_connector 通知目标 Decoder。
3. Prefiller 计算 P 结果并存入 Buffer。
4. Prefiller 推送 KV Cache 至 Decoder_connector（与 Step 3 并行）。
5. Decoder 确认接收后，Router 触发 Decode 请求。

![Image 5: image.png](https://ucc.alicdn.com/pic/developer-ecology/cppkm32z5byce_4deaae796dc641779c9364f5e367c066.png?x-oss-process=image/resize,w_1400/format,webp)

**代码修改重点**：

- 调度侧：get_computed_blocks 集成 Connector 状态管理。
- Worker 侧：模型执行前后异步加载/保存 KV。

**V1 适配方案**：分离 Prefill 与 Decode 调度器，支持 Chunk Prefill 优化，但维护复杂度较高。

![Image 6: image.png](https://ucc.alicdn.com/pic/developer-ecology/cppkm32z5byce_8c9e7fd0695542268f72f2458ef77c15.png?x-oss-process=image/resize,w_1400/format,webp)

### 4.2 英伟达 Dynamo 方案

**架构**：分内外两层：

- **外层**：全局资源管理（Frontend、Router、Workers）。
- **内层**：PD 分离实例，通过 KV Block 交互。

![Image 7: image.png](https://ucc.alicdn.com/pic/developer-ecology/cppkm32z5byce_201d237e4a4d4cc5a94d0d055f4dfb68.png?x-oss-process=image/resize,w_1400/format,webp)

**运行逻辑**：

1. Router 分配请求至 Worker。
2. Prefill Worker 计算 KV 并写入 Block。
3. Decode Worker 消费 Block 生成输出。
4. 使用 NVLINK 实现非阻塞 KV 传输。

![Image 8: image.png](https://ucc.alicdn.com/pic/developer-ecology/cppkm32z5byce_cppkm32z5byce_affb36a5070a4212a47a26007687d73e.png?x-oss-process=image/resize,w_1400/format,webp)

![Image 9: image.png](https://ucc.alicdn.com/pic/developer-ecology/cppkm32z5byce_476074d55368483d88689fc09c8de25d.png?x-oss-process=image/resize,w_1400/format,webp)

**负载均衡优化**：通过队列（PrefillQueue）协调远程请求：

- Worker 决策本地/远程 Prefill，推送请求至队列。
- Prefill Worker 拉取请求并回写 Block。

![Image 10: image.png](https://ucc.alicdn.com/pic/developer-ecology/cppkm32z5byce_83fca0b584c74f9789ce5e79603233bc.png?x-oss-process=image/resize,w_1400/format,webp)

### 4.3 Mooncake 集成方案

**核心组件**：

- **Transfer Engine**：统一接口支持 TCP/RDMA/NVMe-of 协议，实现跨介质数据传输。
- **Mooncake Store**：分布式 KV Cache 引擎，提供 Put/Get/Remove API。

![Image 11: image.png](https://ucc.alicdn.com/pic/developer-ecology/cppkm32z5byce_2442b1b7deb74f0bac1b0bfea430e207.png?x-oss-process=image/resize,w_1400/format,webp)

**工作流程**：

1. Put()：KV 缓存从 GPU 分页缓存传输至本地 DRAM。
2. Get()：异步拉取 KV 至 DRAM，再传输至 GPU 分页缓存。
3. 调度层分离控制流与数据流，提升健壮性。

![Image 12: image.png](https://ucc.alicdn.com/pic/developer-ecology/cppkm32z5byce_de007c3be6834754899efb7d9ebba4a4.png?x-oss-process=image/resize,w_1400/format,webp)

![Image 13: image.png](https://ucc.alicdn.com/pic/developer-ecology/cppkm32z5byce_343e3195ea694226bf258bbe20bbb57e.png?x-oss-process=image/resize,w_1400/format,webp)

**优化方向**：

- **零拷贝传输**：减少 DRAM 中间复制（当前方案存在性能瓶颈）。
- **全局 Cache 复用**：跨请求共享 Prefix 缓存。

![Image 14: image.png](https://ucc.alicdn.com/pic/developer-ecology/cppkm32z5byce_babaa89fa79c476ebd2fc775e691fada.png?x-oss-process=image/resize,w_1400/format,webp)

### 4.4 SGLang 方案

**事件循环机制**：通过队列分阶段处理请求：

**Prefill 实例**：

- BootstrapQueue：创建 Sender 并与 Decoder 握手。
- WaitingQueue：等待资源执行 P 计算。
- InfightQueue：非阻塞查询 KV 传输状态。

**Decode 实例**：

- PreallocQueue：创建 Receiver 并分配 KV 存储。
- TransferQueue：获取 Prefill 的 KV 值。
- WaitingQueue：凑批后执行 D 计算。

![Image 15: f639475068f02d1ca2febfe8b0718685.png](https://ucc.alicdn.com/pic/developer-ecology/cppkm32z5byce_9e5549dee9494c649a3d1ed26e3fc68e.png?x-oss-process=image/resize,w_1400/format,webp)

**KV 传输设计**：

- 非阻塞后端进程处理（KVSender/KVReceiver）。
- 支持逐层或 Chunk 为单位传输。

![Image 16: image.png](https://ucc.alicdn.com/pic/developer-ecology/cppkm32z5byce_793cf3de6641478c91dd84bc9ccba5e1.png?x-oss-process=image/resize,w_1400/format,webp)

- **使用方式**：通过命令行参数指定角色（prefill/decode）和 Bootstrap 端口。
- **未来计划**：扩展多实例支持与高级调度（路标见下图）。

![Image 17: image.png](https://ucc.alicdn.com/pic/developer-ecology/cppkm32z5byce_94b7f69c3b4c4816940370045fb7bceb.png?x-oss-process=image/resize,w_1400/format,webp)

## 5. 作者总结

PD 分离是优化 LLM 推理资源效率的关键路径，vLLM、Dynamo、Mooncake 和 SGLang 等方案各具优势：

- **vLLM**：简洁易用，适合快速部署 1P1D 场景。
- **Dynamo**：分层架构支持大规模集群。
- **Mooncake**：专注高性能 KV 存储与传输。
- **SGLang**：事件循环机制提升灵活性。
- ps：由于文章篇幅有限，关于 LLM 推理框架的全面分析和选型，我之前整理了一个详细的技术文档，粉丝朋友自行领取：《大型语言模型（LLM）推理框架的全面分析与选型指南（2025 年版）》

未来方向包括：多实例负载均衡、动态扩缩容、全局 Cache 共享、以及硬件级优化（如零拷贝传输）。建议各位需根据场景需求（序列长度、请求频率）选择融合或分离部署，好了，今天的分享就到这里，点个小红心，我们下期见。