PD 分离、DCP 与 KV Pool：计算分工、缓存分片和跨节点复用

整理日期：2026-09-14（晚间增量）。依据当天新增问题、可见对话摘录与一手资料整理，不是完整逐字稿。教学推导与用户反馈分别注明，未执行服务器操作。

三个问题应分别理解

PD 分离把 Prefill 与 Decode 放到不同引擎或资源组；DCP 把解码所需的历史 KV 分摊给多个 rank；KV Pool 把缓存作为可复用资源管理。它们可以组合，但分别解决不同问题。

同事说“四台、不加 DCP 和池化的 prefill 已起起来”，只能理解为某个 Prefill 部署阶段跑通；尚不能证明 Decode、缓存交接或完整服务已验证。“池化”在这段上下文很可能指 KV Pool，仍应看实际启动参数。

一次 P/D 请求如何走

请求到 Prefill 引擎，完成输入处理并生成 KV；KV 通过 connector 交接到 Decode 引擎，Decode 继续生成。首 token 由哪侧返回及代理如何串接取决于实现。

分离减少长 Prefill 干扰 Decode，并允许分别配置资源。它同时增加路由、排队、传输、失败处理与缓存布局适配。

是不是只有 Decode 需要 DCP

DCP 的主要收益发生在 Decode，但不能据此断言 Prefill 的配置无需关心 DCP。生产者与消费者必须对齐布局、block size、dtype 和 rank 映射，或由 connector 完成重排。

当前 Ascend 指南对 KV transfer 场景要求交错粒度与缓存 block size 对齐，并列出具体后端和功能组合限制。应按固定版本执行，不能混用任意 PCP/DCP/PD 参数。Ascend Context Parallel 指南

Pool 与 Prefix Cache 的关系

Prefix Cache 是复用相同前缀计算结果的机制；KV Pool 将可复用缓存扩展到外部存储或跨实例管理。正确命中需要模型、token 前缀、布局、量化及其他影响 KV 的因素兼容。

缓存池不是无限 HBM，也不保证每次请求命中。混合 KDA/MLA 模型还要正确保存状态组，不能只复制一块普通 GQA 缓存。

AscendStore 与 Mooncake 并非简单二选一

AscendStoreConnector 是框架与缓存池之间的集成接口；Mooncake 可提供传输及存储能力。官方 KV Pool 指南有 Mooncake 后端，也有通过 MultiConnector 组合池化与 P/D 传输的方案。Ascend KV Pool 指南

Mooncake Transfer Engine 与 Mooncake Store 也不是同一个职责。前者负责高效数据移动，后者管理分布式缓存；Store 可利用 DRAM、SSD/NVMe 等分层资源。活跃注意力计算通常仍需设备可访问的缓存，是否回载与分层由集成路径决定。Mooncake 项目

巨大传输会不会抵消收益

会有这种可能。教学估计：交接时间约为需传字节数除以有效带宽，再加调度、同步与布局转换；若按层流水或异步重叠，不能把所有时间简单串行相加。

例如传 20GB、有效带宽 25GB/s，仅数据移动下界约 0.8s。这是假设算例，不是你的实测。

衡量缓存命中收益时，比较“回载耗时”与“省掉的 Prefill 重算”；衡量 PD 时，还要看隔离带来的尾延迟和吞吐收益。短请求、低命中率或弱网络可能不划算。

实践顺序

先跑通无池化基线，再验证 PD 交接与输出，随后测试冷缓存和热缓存，最后引入所需 DCP/混合状态支持。每步记录 TTFT、TPOT、传输量、命中率和失败恢复。

延伸阅读：V4.1 让 PD Handoff 从 KV 复制升级为状态恢复

DeepSeek V4.1 的 P/D 边界需要考虑 compressed KV、sliding-window KV、indexer keys/scales、compressor state、cross-layer ownership 以及 Engram 相关历史，因此不能再把 handoff 简化成“把普通 KV Cache 搬到 Decode 节点”。模型结构背景见 DeepSeek V4.1-Flash 架构拆解：CED、CSA2、Engram、mHC 与 DSpark；完整 Infra 推导与测试矩阵见 DeepSeek V4.1 对推理 Infra 的挑战：从 KV 状态图到异构 Memory Runtime。

2026-09-16 补录：DCP、Offload 与 GLM PD 支持边界

依据 9 月 15 日关于 DCP/KV Offload 是否互斥，以及 GLM-5.3-Flash 在 910C 上能否 PD 部署的提问。

DCP 与 KV Offload 在概念上不互斥

DCP 解决如何跨 rank 分摊 KV；Offload 解决 KV 是否留在设备内存，还是放到 Host 等存储层级。可以设计为每个 rank 的分片再分层存放。但软件是否支持组合，取决于 block/rank 映射、connector、异步搬运和状态恢复。

不能把“概念可组合”写成“任意版本两项配置一起打开就行”。官方提供独立 CPU offload 与 context parallel 指南，需核对具体组合限制。CPU offload 指南；上下文并行指南

LRU 与 D2H 分别是什么

LRU 是优先淘汰较久未使用对象的策略；D2H 是 Device-to-Host 数据搬运方向。所谓“LRU D2H 优化”可能涉及选择哪些块回迁、合并拷贝、异步重叠及减少重复搬运；缺少原始 PR/日志，不能确认你看到的词具体指哪项实现。

被淘汰块需区分直接丢弃后重算、已有 Host 副本，以及首次回迁保存。搬运优化需记录字节数、队列、拷贝次数和暴露在关键路径上的等待，而非仅看拷贝函数更快。

当前 GLM 支持证据：避免把三个层次混成结论

截至本次核查，官方支持矩阵将 GLM-5.3-Flash 总体标为实验性支持，硬件含 A2/A3/Ascend950，PD 列标为支持。这是当前文档声明。官方支持矩阵

同时，适配 RFC 仍列有混合状态恢复验证、运行时和长上下文问题，量化组合也有待验证项。这说明模型功能标签不能替代具体版本、格式和特性组合验收。官方适配 RFC

你此前反馈 PD 仅能拉起、尚不能正常推理，是个人环境的历史实验状态；本次没有登录机器复测，也没有取得与你权重和镜像完全匹配的成功配置，不能宣布它已修好。

单机或双机学习 PD 的可复现起点

官方单节点 Mooncake 教程给出 Qwen2.5-VL-7B-Instruct、P/D 各 TP1、不同设备与端口、MooncakeConnectorV1 和代理的配置。它可作为已公开的基础路径；不是“最新模型排行榜”，也不自动证明 GLM 混合状态受支持。单节点官方教程

先按固定版本核对设备编号、P/D 权重与模板一致、网络端口及 KV 布局，验证短请求与混部基线输出，再逐步增加长度、并发和缓存特性。8 个物理模组与运行时设备编号的映射，仍需按你的双 Die 环境检查。

相关架构：NoPE、DSA 与 KDA 补充。

2026-09-16 增量：PD、AFD 与 Mooncake 调用时序

今天追问从单机 8 卡学习模型选择，延伸到 PD 双引擎、Attention–FFN 分离及 Mooncake 的职责。既有单节点入门路径仍采用官方 Qwen2.5-VL-7B-Instruct 示例；该教程给出 P/D 各 TP1 的基础配置。官方单节点教程

先前回答还建议 Qwen3.5-27B-W8A8、P/D 各 TP2。本次未完成这一具体量化、模型、图模式和状态传输组合的核查，因此将其留作候选，不写成已验证启动方案。单机有 8 卡不意味着学习实验必须用满 8 卡。

分离发生在不同边界

PD 沿请求执行阶段切开：Prefill 完成输入处理后，把继续解码所需状态交接给 Decode。常见双引擎部署各自加载所需模型权重，需要独立计算权重、KV 与 workspace 容量。

AFD 沿模型层内部的 Attention 和 FFN/MoE 计算切开，可能在多层、多步之间反复交换中间激活。它可以让两类计算分别配置资源，也增加频繁通信和调度。此处是架构推导，不代表当前 vLLM-Ascend 任意模型已经支持 AFD。

判断是否有价值，需要比较隔离和资源利用收益，与新增通信、同步及排队成本。PD 和 AFD 都不保证比混部快：短请求、低负载或通信占比较高时，简单混部可能更合适。

vLLM 决定何时需要状态，Connector 接合数据通道

一条概念时序：启动时注册缓存内存；调度阶段构造请求及块映射元数据；执行前发起加载或等待所需数据；计算中或完成后保存/传输；确认完成后再安全复用缓存块。并非每个 token 都重新注册整片内存，也不能只搬完字节就忽略生命周期。

vLLM KVConnector 基类提供 register_kv_caches、build_connector_meta、start_load_kv 等不同阶段钩子；具体传输完成接口随版本演进，不能把某次对话列出的函数名当作永久 ABI。KVConnector 源码文档

Mooncake Transfer Engine 提供数据传输能力；Store 另负责缓存对象存储与管理。仅部署 P→D 传输不必然等于已经部署分布式 KV Pool。Mooncake 项目（核查：2026-09-16）

实验记录应能定位额外代价

固定模型与请求，比较混部和分离的 TTFT、TPOT、P/D 排队、实际传输字节及耗时，测试短/长输入、冷/热缓存、不同并发。另验证请求取消、传输失败和缓存块复用，不以“两个服务启动成功”代替完整推理验收。

2026-09-17 增量：PD 共置不等于专用 P/D 分离

核查于 2026-09-18。你引用的官方教程在两台 A2 上各部署一个完整 vLLM 实例，采用 MooncakeConnectorStoreV1 与 kv_both，测试本地及跨节点缓存复用。这里的共置指实例仍能承担 Prefill 和 Decode，不是把一个实例固定为 P、另一个固定为 D。官方 PD 共置教程

判断部署结构，应看每个实例承担哪些计算、是否独立路由 P/D，以及 KV 从哪里到哪里；不要只按教程标题的 PD 两字判定。多个完整实例共享缓存，可以减少重复 Prefill，但并不自动带来专用 P/D 的资源隔离。

你提出 MMC 后端与 store_only 的排查方向，已整理为MemCache 与实际传输路径。这是待验证方案，尚未取得完整代码和成功日志；本次不宣称原 PD 故障已修复。

2026-10-07 增量：长Prefill优化与异构P/D分片

来源：9月28日Prefill低精度及加速追问，近期P/D与不同TP摘录。以下是机制分析，不是已完成优化。

先拆TTFT为排队、输入处理、prefill计算/通信与首输出；长输入不意味着其中只有GEMM。低精度减少相应计算/流量，FlashAttention减少标准attention IO，Prefix Cache命中可复用部分前缀；三者改变不同成本。

Chunked Prefill把大请求分段调度，可改善与decode竞争时的延迟/资源使用，但不自动减少该请求的总数学工作。P/D分离改变资源与队列组织，增加KV交接；PCP/CP分摊工作，也引入通信。它们不能统一概括为“打开后长prefill必然迅速完成”。

Sparse/线性Attention属于模型/算法路径，必须由模型和后端支持，不能把任意全注意力checkpoint直接换成稀疏/线性算子并称无损。KV低位不仅改变容量，也可能影响读取/转换成本；是否帮助prefill看具体内核，不给绝对“不是核心/一定加速”结论。

异构P/D并行度不同，KV必须匹配head/latent/state、rank ownership、dtype、page/块布局与位置元数据。可通过connector重分片/转换，并不保证直接一对一搬运；线性递归层和卷积层还要传对应状态。原记录里“TP不同也能直接传”须加这些条件。

实验固定总设备数、模型质量门槛和负载，分别改变低精度、prefix命中、chunk、P/D与上下文分片；记录TTFT/ITL、KV字节、传输、排队与失败恢复。真实参数与收益尚未取得。

联系：量化见W8A8C8 与 GPQA：把量化位宽、数值误差和模型能力分开看，片上数据复用见GEMM、Triton 与 TileLang：从分块代码到 Roofline 性能账本。