文档(金鹏): 2026-08-06 章节 48 篇文章摘要归档
- 46 篇原文+摘要双文件归档（按 来源/作者 分层，复用本地归档 20 篇+新抓取 26 篇） - 即梦生成 9 组主题配图（大图+列表缩略图）存入 知识/金鹏/20260806/ - 章节重组为 9 个主题分组并挂接摘要引用
This commit is contained in:
@@ -0,0 +1,217 @@
|
||||
# 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 共享、以及硬件级优化（如零拷贝传输）。建议各位需根据场景需求（序列长度、请求频率）选择融合或分离部署，好了，今天的分享就到这里，点个小红心，我们下期见。
|
||||
@@ -0,0 +1,82 @@
|
||||
# 📊 文章摘要：LLM推理成本直降60%：PD分离在大模型商业化中的关键价值
|
||||
|
||||
> **原文**：[2025-09-09_LLM推理成本直降60%_PD分离在大模型商业化中的关键价值.md](./2025-09-09_LLM推理成本直降60%_PD分离在大模型商业化中的关键价值.md)
|
||||
> **原文链接**：https://developer.aliyun.com/article/1681023
|
||||
> **来源**：阿里云开发者社区
|
||||
> **作者**：阿里云开发者社区用户（cppkm32z5byce）
|
||||
> **发布日期**：2025-09-09
|
||||
> **摘要日期**：2026-08-06
|
||||
> **价值评级**：⭐⭐⭐ 高
|
||||
|
||||
---
|
||||
|
||||
## 核心命题
|
||||
|
||||
> **PD分离选型框架** — 系统梳理 PD 分离实现的五大关键设计问题与 vLLM/Dynamo/Mooncake/SGLang 四种主流方案对比，为"何时分离、如何分离"提供可迁移的决策框架。
|
||||
|
||||
---
|
||||
|
||||
## 文章概要
|
||||
|
||||
本文围绕 vLLM 框架系统拆解 PD 分离（Prefill/Decode 分离）从背景到实现的全貌：传统一体化部署导致 P 阶段显存闲置、D 阶段算力闲置，分离部署让 P 实例专注高算力生成 KV 缓存、D 实例专注高带宽消费 KV。文章给出 vLLM 0.8.x KV Transfer 机制（1P1D 场景）的代码级实现，提炼出 PD 配比、请求调度、KV 存储、Cache 复用、可靠性五大类关键设计问题，并对比 Connector-Base、英伟达 Dynamo、Mooncake、SGLang 四种方案的架构与取舍。其价值在于把分散的工程知识整理为可操作的选型决策框架，并明确提示短序列/低频场景下融合部署可能更优；但标题宣称的"成本直降60%"在正文中并无对应实测数据支撑。
|
||||
|
||||
---
|
||||
|
||||
## 关键要点
|
||||
|
||||
1. **分离的前提是资源错配** — Prefill 计算密集、Decode 访存密集，一体化部署使 P 阶段显存利用率低、D 阶段算力利用率低，这是 PD 分离立论的根本依据。`[分类: 共识]`
|
||||
2. **五大设计问题清单** — PD 配比与数量（融合/分离选择、动态配比、弹性扩缩容、角色互换）、请求调度（亲和性、负载均衡、网络均衡、batch 分配）、KV 存储设计（介质与传输方式）、Cache 复用（位置、保存策略、共享范围、淘汰机制）、可靠性（故障恢复、网络健壮性）——是可迁移的工程检查单。`[分类: 共识]`
|
||||
3. **vLLM KV Transfer 现状与局限** — 0.8.x 通过 LookupBuffer 非阻塞写入/阻塞读取实现 1P1D，支持 PyNCCL/Mooncake 后端；仅支持 1P1D、缺负载均衡与自动扩缩容、Chunk Prefill 未适配，需 V1 迭代。`[分类: 共识]`
|
||||
4. **四种方案路线对比** — vLLM Connector-Base 简洁易用适合快速部署；Dynamo 分层架构（Router/Workers）支持大规模集群与队列化负载均衡；Mooncake 以 Transfer Engine+分布式 Store 专注 KV 存储传输；SGLang 用事件循环队列机制提升灵活性。`[分类: 共识]`
|
||||
5. **场景化选型原则** — "短序列/低频请求场景下，融合部署可能更优"，分离与融合并非后者一定胜出，需按序列长度与请求频率决策。`[分类: 争议]`（业界对适用边界仍在探索）
|
||||
6. **成本数字存疑** — 标题"成本直降60%"与正文论证（资源效率提升）之间缺乏可核查的成本核算数据，量化收益被高估风险。`[分类: 争议]`
|
||||
|
||||
---
|
||||
|
||||
## 批判性分析
|
||||
|
||||
### 假设前提
|
||||
|
||||
作者假设 PD 分离带来的资源效率提升最终能转化为成本下降（60%），且 vLLM 的 KV Transfer 机制在异构后端（PyNCCL/Mooncake）下性能一致；同时假设读者场景中存在足够多"长序列、高并发"请求使分离收益显著。
|
||||
|
||||
### 论据与逻辑
|
||||
|
||||
正文以架构描述与代码示例支撑论点，逻辑链条在"实现层面"完整，但在"价值层面"断裂——标题与第一节声称的成本收益没有对应测量或核算数据，属于推断而非实证；方案对比（第四部分）以定性架构分析为主，缺少同场景下的 benchmark 横向对比，读者无法据此做量化选型。
|
||||
|
||||
### 边界与局限
|
||||
|
||||
内容基于 2025 年 9 月的 vLLM 0.8.x 快照，框架迭代快（V1、Dynamo 版本演进），部分细节可能已过时；1P1D 到 xPyD 的多实例场景、跨机房 KV 传输等分布式扩展均未覆盖；成本收益结论适用于"长序列、高并发、可弹性扩缩容"场景，短序列低频业务与固定资源池场景不适用。
|
||||
|
||||
---
|
||||
|
||||
## 可引用金句
|
||||
|
||||
> "PD 分离是优化 LLM 推理资源效率的关键路径，vLLM、Dynamo、Mooncake 和 SGLang 等方案各具优势：vLLM：简洁易用，适合快速部署 1P1D 场景。Dynamo：分层架构支持大规模集群。Mooncake：专注高性能 KV 存储与传输。SGLang：事件循环机制提升灵活性。"
|
||||
|
||||
> "短序列/低频请求场景下，融合部署可能更优。"
|
||||
|
||||
> "建议各位需根据场景需求（序列长度、请求频率）选择融合或分离部署。"
|
||||
|
||||
---
|
||||
|
||||
## 总体评价
|
||||
|
||||
**亮点**：
|
||||
- 五大设计问题清单（a-e 结构）是全文最可迁移的产出，可直接作为 PD 分离系统设计的评审检查单
|
||||
- 四种方案横向对比覆盖主流路线，架构图示清晰，适合快速建立选型认知
|
||||
- 明确提示融合/分离的适用边界，边界意识强于同类技术博客
|
||||
|
||||
**不足**：
|
||||
- 标题"成本直降60%"无实测支撑，有营销化倾向，与正文严谨度不匹配
|
||||
- 方案对比缺 benchmark 数据，选型判断停留在定性层面
|
||||
- 时效性风险：基于 2025 年 vLLM 0.8.x 状态，需对照最新版本校验
|
||||
|
||||
**适用场景**：正在规划推理集群架构、评估是否引入 PD 分离的平台工程师与架构师；需要快速了解 vLLM/Dynamo/Mooncake/SGLang 方案差异的技术决策者。
|
||||
|
||||
**关联建议**：结合《1.5x提升：PD分离KV cache传输的实践经验》看 vLLM 传输层的一线调优；结合《下一代推理优化技术……测试（上）》看 PD 分离与 KV Cache Offload 的联合验证设计；关注 vLLM V1 与 Dynamo 的最新多实例能力以更新选型结论。
|
||||
|
||||
---
|
||||
|
||||
## 配图
|
||||
|
||||
|
||||
Reference in New Issue
Block a user