arno
c0ba3fb853
- 46 篇原文+摘要双文件归档（按 来源/作者 分层，复用本地归档 20 篇+新抓取 26 篇） - 即梦生成 9 组主题配图（大图+列表缩略图）存入 知识/金鹏/20260806/ - 章节重组为 9 个主题分组并挂接摘要引用
218 lines
11 KiB
Markdown
218 lines
11 KiB
Markdown
# 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 缓存生成输出。
|
||
|
||
|
||
|
||
## 2. vLLM 框架中的 PD 分离实现现状
|
||
|
||
vLLM 作为主流推理框架，其 0.8.x 版本通过 **KV Transfer 机制**支持 PD 分离（1P1D 场景）。核心设计如下：
|
||
|
||
**工作流程**：
|
||
|
||
- P 实例以非阻塞方式将生成的 KV 缓存插入缓冲区（LookupBuffer）。
|
||
- D 实例以阻塞方式从缓冲区获取 KV 缓存。
|
||
- 数据传递通过管道（pipe）实现，支持 PyNCCL 或 Mooncake Store 等通信后端。
|
||
|
||
|
||
|
||
|
||
|
||
**代码实现简化**：
|
||
|
||
- 通过 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 传输操作。
|
||
|
||
|
||
|
||
**异步传输流程**：
|
||
|
||
1. Router 发送 Prefill 请求至 Prefiller。
|
||
2. Prefiller_connector 通知目标 Decoder。
|
||
3. Prefiller 计算 P 结果并存入 Buffer。
|
||
4. Prefiller 推送 KV Cache 至 Decoder_connector（与 Step 3 并行）。
|
||
5. Decoder 确认接收后，Router 触发 Decode 请求。
|
||
|
||
|
||
|
||
**代码修改重点**：
|
||
|
||
- 调度侧：get_computed_blocks 集成 Connector 状态管理。
|
||
- Worker 侧：模型执行前后异步加载/保存 KV。
|
||
|
||
**V1 适配方案**：分离 Prefill 与 Decode 调度器，支持 Chunk Prefill 优化，但维护复杂度较高。
|
||
|
||
|
||
|
||
### 4.2 英伟达 Dynamo 方案
|
||
|
||
**架构**：分内外两层：
|
||
|
||
- **外层**：全局资源管理（Frontend、Router、Workers）。
|
||
- **内层**：PD 分离实例，通过 KV Block 交互。
|
||
|
||
|
||
|
||
**运行逻辑**：
|
||
|
||
1. Router 分配请求至 Worker。
|
||
2. Prefill Worker 计算 KV 并写入 Block。
|
||
3. Decode Worker 消费 Block 生成输出。
|
||
4. 使用 NVLINK 实现非阻塞 KV 传输。
|
||
|
||
|
||
|
||
|
||
|
||
**负载均衡优化**：通过队列（PrefillQueue）协调远程请求：
|
||
|
||
- Worker 决策本地/远程 Prefill，推送请求至队列。
|
||
- Prefill Worker 拉取请求并回写 Block。
|
||
|
||
|
||
|
||
### 4.3 Mooncake 集成方案
|
||
|
||
**核心组件**：
|
||
|
||
- **Transfer Engine**：统一接口支持 TCP/RDMA/NVMe-of 协议，实现跨介质数据传输。
|
||
- **Mooncake Store**：分布式 KV Cache 引擎，提供 Put/Get/Remove API。
|
||
|
||
|
||
|
||
**工作流程**：
|
||
|
||
1. Put()：KV 缓存从 GPU 分页缓存传输至本地 DRAM。
|
||
2. Get()：异步拉取 KV 至 DRAM，再传输至 GPU 分页缓存。
|
||
3. 调度层分离控制流与数据流，提升健壮性。
|
||
|
||
|
||
|
||
|
||
|
||
**优化方向**：
|
||
|
||
- **零拷贝传输**：减少 DRAM 中间复制（当前方案存在性能瓶颈）。
|
||
- **全局 Cache 复用**：跨请求共享 Prefix 缓存。
|
||
|
||
|
||
|
||
### 4.4 SGLang 方案
|
||
|
||
**事件循环机制**：通过队列分阶段处理请求：
|
||
|
||
**Prefill 实例**：
|
||
|
||
- BootstrapQueue：创建 Sender 并与 Decoder 握手。
|
||
- WaitingQueue：等待资源执行 P 计算。
|
||
- InfightQueue：非阻塞查询 KV 传输状态。
|
||
|
||
**Decode 实例**：
|
||
|
||
- PreallocQueue：创建 Receiver 并分配 KV 存储。
|
||
- TransferQueue：获取 Prefill 的 KV 值。
|
||
- WaitingQueue：凑批后执行 D 计算。
|
||
|
||
|
||
|
||
**KV 传输设计**：
|
||
|
||
- 非阻塞后端进程处理（KVSender/KVReceiver）。
|
||
- 支持逐层或 Chunk 为单位传输。
|
||
|
||
|
||
|
||
- **使用方式**：通过命令行参数指定角色（prefill/decode）和 Bootstrap 端口。
|
||
- **未来计划**：扩展多实例支持与高级调度（路标见下图）。
|
||
|
||
|
||
|
||
## 5. 作者总结
|
||
|
||
PD 分离是优化 LLM 推理资源效率的关键路径，vLLM、Dynamo、Mooncake 和 SGLang 等方案各具优势：
|
||
|
||
- **vLLM**：简洁易用，适合快速部署 1P1D 场景。
|
||
- **Dynamo**：分层架构支持大规模集群。
|
||
- **Mooncake**：专注高性能 KV 存储与传输。
|
||
- **SGLang**：事件循环机制提升灵活性。
|
||
- ps：由于文章篇幅有限，关于 LLM 推理框架的全面分析和选型，我之前整理了一个详细的技术文档，粉丝朋友自行领取：《大型语言模型（LLM）推理框架的全面分析与选型指南（2025 年版）》
|
||
|
||
未来方向包括：多实例负载均衡、动态扩缩容、全局 Cache 共享、以及硬件级优化（如零拷贝传输）。建议各位需根据场景需求（序列长度、请求频率）选择融合或分离部署，好了，今天的分享就到这里，点个小红心，我们下期见。
|