tech/知识/阿里云开发者社区/2025-09-09_LLM推理成本直降60%_PD分离在大模型商业化中的关键价值.md

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 共享、以及硬件级优化（如零拷贝传输）。建议各位需根据场景需求（序列长度、请求频率）选择融合或分离部署，好了，今天的分享就到这里，点个小红心，我们下期见。