# 📊 文章摘要：vLLM PD 分离

> **原文**：[2026-08-05_vLLM_PD分离_源码级机制_marcus.md](./2026-08-05_vLLM_PD分离_源码级机制_marcus.md)
> **原文链接**：https://mp.weixin.qq.com/s/p6gh4hK25PujQ1UJzFTbLg
> **来源**：微信公众平台（marcus）
> **作者**：marcus
> **发布日期**：2026-08-05（原文未标注日期，按下载日占位）
> **摘要日期**：2026-08-06
> **价值评级**：⭐⭐⭐ 高

---

## 核心命题

> **源码级解构** — 把 PD 分离从概念论述落到 vLLM + Mooncake Connector 的代码行号级机制，是本批 PD 分离文章中唯一触及实现细节的第一手资料。

---

## 文章概要

本文逐层拆解 vLLM 基于 Mooncake Connector 实现 PD 分离的完整代码路径：Proxy 将同一 prompt 双发至 P/D 节点并携带不同标志、Scheduler 通过 `WAITING_FOR_REMOTE_KVS` 状态机暂停等待远端 KV、Worker 层经 ZMQ 握手后以 RDMA 将 KV Cache 直写 D 侧 GPU 显存、传输完成后请求恢复调度。其价值在于回答了其他文章不回答的"怎么实现"问题——`transfer_id` 如何关联 P/D、D 侧 block 物理地址如何成为传输基础、为何要"少算 1 个 token 本地重算"。局限在于只覆盖 Mooncake Connector 一种实现，无性能数据，不讨论 P:D 配比与传输延迟等工程参数。

---

## 关键要点

1. **Proxy 双发请求** — 同一 prompt 同时发给 P 和 D，靠 `kv_transfer_params` 标志区分角色：P 侧 `do_remote_decode=True` 且 `max_tokens=1` fire-and-forget，D 侧 `do_remote_prefill=True` 流式等待返回。 `[分类: 共识]`
2. **`transfer_id` 关联机制** — Proxy 生成 UUID 同时发给两端，P 侧以 `reqs_need_send[transfer_id]` 等待 D 侧经 ZMQ 发来的拉取请求，是 P/D 匹配同一请求的唯一纽带。 `[分类: 共识]`
3. **D 侧调度暂停态** — `WAITING_FOR_REMOTE_KVS` 状态下请求不进入 running 队列、不占 GPU 计算资源，并跳过 zeroing 以避免与异步写入竞态；`reserved_blocks` 预留空间防死锁。 `[分类: 共识]`
4. **RDMA 直写远端显存** — D 侧将自己的 `kv_caches_base_addr`/`block_lens`/`block_ids` 经 ZMQ 发给 P，P 用 `batch_transfer_sync_write` 直接写入 D 的 GPU 内存，D 侧零计算加载；`remote_engine_id` 的 DP rank 后缀用于定位不同数据并行分区的 KV。 `[分类: 共识]`
5. **传输后恢复执行** — 完成后 KV 写入 prefix cache，并故意减少 1 个 computed token 让最后 1 个 prompt token 本地重算以生成首个输出 token；P 侧发送走后台线程池，不阻塞 forward pass。 `[分类: 共识]`
6. **机制层面未触及的性能问题** — 全文只讲"如何实现"不讲"收益几何"，P:D 比例、传输延迟、SLO 达成等维度完全缺席，需与性能类文章（如 DistServe 解读）互补阅读。 `[分类: 未探索]`

---

## 批判性分析

### 假设前提

作者立论建立在三个前提上：读者熟悉 vLLM v1 架构与 Mooncake 生态；该实现路径是 PD 分离的"典型范式"——但 SGLang、TensorRT-LLM 等引擎的实现机制并不相同；RDMA/NVLink 高速互联为默认可用资源。

### 论据与逻辑

论据为具体源码行号（`scheduler.py` 712-755 行、`MooncakeConnectorWorker` 2028-2039 行等），证据直接、链条完整，从请求进入、调度、传输到恢复执行全程无逻辑跳跃，可信度高。但全文无任何运行数据或基准测试，无法证明"这套机制实际有效、开销几何"——机制正确性与性能有效性是两回事。

### 边界与局限

结论仅适用于 vLLM + Mooncake Connector 这一特定组合；文中机制（如延迟释放 block、传输后减少 1 个 computed token）属于工程实现细节而非普适原理；不适用于评估 PD 分离的收益/代价，也不覆盖 D 节点等待期间的整体调度吞吐影响。对只想了解 PD 分离概念与价值的读者，本文过于深入。

---

## 可引用金句

> "每个请求都有唯一的 `transfer_id`（UUID）——这是 P 和 D 两端关联同一次 KV Cache 传输的关键标识。"

> "P 和 D 收到的 prompt 完全一致，但通过 `kv_transfer_params` 标志区分行为。"

---

## 总体评价

**亮点**：
- 全链路（Proxy→Scheduler→Worker→恢复执行）代码级剖析，行号精确，是稀缺的一手工程资料
- 清晰回答了"KV 如何从 P 到 D、请求如何暂停与恢复"这一概念文章普遍回避的实现问题
- 时序图（完整时序总结）直观完整，可作为机制速查图

**不足**：
- 无任何性能数据，机制正确性与性能收益之间留白
- 未讨论 P:D 配置、传输延迟、失败处理等工程参数
- 依赖 Mooncake Connector 特定实现，通用性未说明

**适用场景**：推理系统工程师、vLLM 二次开发者、想从"知道 PD 分离"进阶到"读懂 PD 分离代码"的读者；面试中需要讲解 PD 分离实现细节时的高价值素材。

**关联建议**：搭配本文同批的 DistServe 解读（原理与收益）与丁师兄文章（落地代价）构成"原理—机制—代价"完整链条；可进一步阅读 vLLM `v1/core/sched/scheduler.py` 中 `MooncakeConnectorScheduler` 与 `MooncakeConnectorWorker` 的完整源码，以及 Mooncake 项目关于 KVCache 传输的官方文档。

---

## 配图

![-](../../金鹏/20260806/20260806-003.png)