压缩、重叠、复用、隔离：PD 状态交接优化的四条轴

本文的框架起点和部分引用来自壁仞科技研究院《深潜｜异构PD分离原理与探索》（2026-09-16）；其余信息来自 SGLang、Mooncake、LMCache、llm-d 的公开文档与源码，以及本 repo 已有文章。

一、为什么状态交接是真瓶颈

PD 分离把 Prefill 和 Decode 拆到不同实例上，中间必须传递一份有模型语义的状态：各层 KV、MLA 压缩态、稀疏注意力索引键、TP/PP 分片。这份状态缺一样、错一个格式，Decode 就无法开始生成。

本文把这件事称为状态交接（handoff）：它是整个移交过程，覆盖四层：KV 字节过线（传输）、元数据与提交顺序（时序）、D 侧预分配与就绪判定（状态生效）、缓存归属与故障后的责任（生命周期）。「传输」只是其中字节搬运的那一部分，本文讨论的是全部四层。

壁仞的文章把这笔账算了两道。容量侧：以 GLM-5.3（MLA+DSA，78 层）每 token 约 90.5 KB（BF16 口径）计，1000 用户 × 20 session × 32K 上下文 ≈ 55 TB，HBM 装不下，所以要多级存储。经济侧：单机月收入公式代入假设参数约 ¥8.3 万，Prefix Cache 命中率直接进乘积。

第三道账是传输，文中只给了框架没有给数。补上这一笔，瓶颈的形状就清楚了。55 TB 是池子的容量；对一个正在交接的请求，要过线的是它的全部前缀 KV。按上面的口径，一个 32K 上下文的请求约 2.8 GB；即使 200G RDMA 跑满理论带宽，纯传输也要 110 ms 上下，而这只是下限：真实路径上还有协议开销、与计算争抢带宽、跨进程的提交与可见性延迟。

PD 分离的成败更多取决于这条交接链路，而不是 P 或 D 各自算得多快。壁仞把这句话写在了文章开头，然后停在了框架上。本文把可以核对的业界实践逐轴填进去。

二、地图总览

状态交接的优化空间可以画成四条主轴加一条容错轴：

轴 问题 代表手段 证据成熟度
压缩 要传的字节数能不能变少 线上量化、稀疏感知传输 组件有实测，系统级落地缺
重叠 传输能不能躲进计算里 chunk-wise 流水线、元数据先行 有论文数字 + 引擎源码实现
复用 能不能干脆不传 cache-aware 路由、去重、混合路径 有多方实测，结论有争议
隔离 传输会不会伤到计算 流量规划、传输路径优化 公开材料最少
容错 已传输的成果能否在故障后保留 状态外置、副本与租约 仓库与业界均未覆盖

前两条轴优化「这一次传输」，第三条轴优化「要不要传」，第四条轴保证传输不干扰计算，容错轴保证已完成的成果不因故障损失。下面逐轴展开。

三、压缩：减少要传的字节

3.1 线上量化

KV 以 FP8 过线、Decode 侧按需反量化（或直接以 FP8 常驻），字节数直接减半；这和 KV Cache 常驻量化是同一套格式体系，仓库的 KV 量化文章已有完整的粒度与精度分析。

更激进的是专门的传输编码。LMCache 的 CacheGen（SIGCOMM 2024）针对 KV Cache 的流式传输设计压缩管线，论文口径体积缩小 4.3 倍、精度损失通常小于 2%，并支持边编码边传输。

但要注意现状：量化传输至今没有进入主流 PD 引擎的默认路径。本仓 PD 传输文章在梳理完整/增量维度时明确把它排除在外，理由是「量化传输是另一个正交维度」。原因不难理解：量化位置多一个选择（P 端算完后量化过线，还是 D 端收到后量化常驻），格式契约就多一个约束，而 PD 两侧的 KV dtype 一致性目前是靠约定保证的。这是一个工程上可行、生态上尚未统一实现的空白。

3.2 稀疏感知传输

更贴合架构演进的方向来自稀疏注意力这一侧。DeepSeek-V3.2 引入 DSA 之后，稀疏注意力的选择结果决定了 Decode 实际要访问哪些 KV。壁仞那笔 90.5 KB/token 的账里，78 层 MLA 只有 21 层独立生成并保存 DSA 索引，其余层复用索引选择结果。传输量和访问量天然不对等：全量传输的 KV 里，有一部分 Decode 根本不会读。

稀疏选择搬到传输路径上还没有现成实现，但同款思路 SGLang 的 HiSparse 已经在加载路径上走通：它的稀疏选择发生在 KV cache 的加载路径上，省的是数据搬运，未被选中的 page 被排除在加载之外，操作粒度是 swap_in_selected_pages 的 page 级选择。这条经验与「传输也是加载」的视角结合，就是稀疏感知 PD 传输的雏形：P 端按索引只传将被访问的部分，索引键本身很小（壁仞口径每层 132 B）单独传。

代价也明确：稀疏选择和传输耦合后，选择质量决定正确性边界，且跨 P/D 的索引语义要对齐。仓库的稀疏注意力 × 卸载文章枚举的八个决策点（信号质量、信号翻译、系统副作用、经济性）几乎可以原样迁移到传输场景，那里给的结论同样适用：问题框架已备好，设计方案还没有。

四、重叠：让传输躲进计算里

4.1 chunk-wise 流水线

最直接的重叠：Prefill 不要等全部算完再一次性传，每算完一个 chunk 就发一个 chunk，Decode 侧收到即装载，传输时长可与 prefill 计算时长重叠。

这不是设想。SGLang 的 PD 实现默认就是这么做的：enable_overlap 开启时（默认开），每完成一个 prefill chunk 即调用 send_kv_chunk 增量发送（本地检出 python/sglang/srt/disaggregation/prefill.py:888-892），最后一个 chunk 带 last_chunk=True 收尾。vLLM 的 Chunked Prefill 与 KV 分配的交互约束在仓库已有专文。

学术侧，DualPath 的层间流水线给出了量化口径：转述论文数字，JCT 减少约 17.21%，吞吐最高 1.87×（离线）/ 1.96×（在线）。仓库的层级流水线文章对此有完整拆解。

传输策略的三分法（仓库 PD 传输文章的框架）给出了判据：Eager 边算边传、Lazy 算完再传、Pipelined 分块流水。重叠的收益上限由「传输时长与计算时长中较短的那一个」决定：长上下文下 prefill 计算远长于传输，重叠几乎免费；短上下文下两者同量级，收益随之缩水。

4.2 元数据先行

壁仞的文章在 Store 路径上指出：除了搬运字节，还有「提交、查询和对象可见性时间」。这提示了第二个重叠位：字节还在路上时，元数据可以先行到位，目标页已预分配、内容键已注册、提交标记先于最后一批字节。SGLang PD 的控制面（bootstrap + ZMQ 元数据通道）与数据面完全分离的设计，以及 Decode 侧的预分配队列（DecodePreallocQueue 先占页再等数据），就是这个思路的落地形态。

五、复用：把传输变成命中

最好的一次传输是不传。这条轴有三层。

5.1 cache-aware 路由

把「哪个实例已持有这段前缀」纳入路由决策。llm-d 的实测量化了这条轴的收益：8 个 vLLM pod、150 个共享 6000-token 前缀的 B2B 客户场景下，precise-scheduling（精确前缀感知）输出 8730 tok/s、TTFT p90 0.542 s；load-based 调度 4429 tok/s、TTFT p90 94.9 s。差一倍的吞吐、差两个量级的尾延迟，差别只在路由是否看缓存。

Mooncake 的 Conductor 把同一思路落成了算法（论文 Algorithm 1）：对每个 prefill 实例估计「缓存传输 + 排队 + prefill 执行」三段时间之和，选总 TTFT 最小的实例；前缀匹配长度直接决定 prefill 执行时间的估计值。

但这条轴有明确的反方。Anyscale（作者含 NVIDIA 人员）的实测结论是：平衡缓存复用与负载比最大化复用更好，并给出两个具名失效模式：request herding（同类请求被缓存亲和性吸到同一实例，热点集中）与 session-level imbalance。复用和均衡是一个双目标问题，llm-d 的高分场景（高共享前缀）恰是亲和性收益最大、也最不容易踩 herding 的场景；前缀分散的负载下结论会反过来。

5.2 去重与增量

第二层是传输内部的复用。同一前缀已在 Store 中时，P 端只需补写新增块：壁仞以 KV_bytes_put 与 KV_bytes_get 的差值刻画这一关系（Store 已持有历史块时 put < get）。LMCache 的 PD backend 用 already_sent_indexes 记录已发送块做会话内去重；Mooncake Store 以内容寻址支持跨请求复用，全局缓存命中率最高达本地方案的 2.36 倍，prefill 计算时间节省最高 48%（FAST 25 口径）。仓库的 Mooncake 架构文章对此有完整分析。

5.3 混合路径

第三层把前两条组合起来：历史块从 Store 异步拉取，新增块走直连等 P 算完，两路并行。壁仞给出了这条路径的计时框架（Store 侧「写入+读取」两段串行，或 block 级提交后的流水线关键路径）。SGLang 已有对应的工程形态：decode 侧的 HiCache 恢复接收器把 KV 传输完成信号门控在 L2/L3 回拷就绪之后——即 Decode 的数据来源可以是「P 直推」与「分层存储回拷」两条路径的组合，由门控保证顺序正确。

六、隔离：传输不干扰计算

这一轴的公开材料最少，如实标注。

干扰有两种形态。网络侧：KV 过线走 RDMA，而 P/D 各自的 TP 集合通信也走网络，传输突发与 all-reduce 争抢带宽和队列。CPU 侧：传输的打包、注册、拷贝消耗 CPU 与内存带宽，SGLang 的 PD 部署文档专门给出 NUMA 亲和与调度参数调优（如 sched_migration_cost_ns），说明 CPU 侧干扰是工程上真实面对的问题。

一个侧证是传输路径本身的优化活跃度：SGLang 为异构 TP 场景引入 GPU staging buffer（prefill 侧把 KV head 切片聚成连续缓冲、bulk RDMA、decode 侧再散开），公开口径高并发下吞吐较逐 token 切片提升 2–5 倍，接近同构 TP 基线。这说明「传输怎么做」本身就是一条活跃的优化线，而「传输与计算怎么互不打架」的系统性方案——流量整形、带宽预留、拥塞隔离——公开文献里还没有成体系的回答。壁仞在跨机房边界一段提了「带宽预留、流量治理」，算是提前指出了同一空白。

七、容错：故障恢复与会话迁移

前四条轴优化的都是成功传输；这一条问的是失败之后。

这是仓库与业界公开材料均未覆盖的方向：本仓 PD 相关文章没有讨论过 D 实例故障后的会话恢复；业界公开材料里也只有组件级语义，没有端到端方案。

组件语义已经齐了一半。存储侧，Mooncake Store 具备多副本（best-effort）、对象租约与 gc_ttl_ms 回收、soft-pin 驱逐保护。「KV 外置一份、实例无状态化」的存储语义是现成的。引擎侧，SGLang 用 SGLANG_DISAGGREGATION_WAITING_TIMEOUT（默认 300 秒）防止跨节点拉取期间 Decode 侧显存被提前回收引发数据竞争；SGLang Router 与 llm-d 都把 fault tolerance 列为路由器目标。

缺的是把它们连起来的最后一环：D 实例故障时，把会话迁到另一个 D、从共享 Store 重新装载 KV 而不是重新 prefill。能力要素（外置 KV、内容寻址、租约）都在，公开材料里没有谁把这最后一环走通并给出数据。对一个把状态外置做进架构前提的部署（比如以 KV Store 为中心的 Mooncake 形态），这一环的缺失意味着前四条轴节省的成本，在每次故障时都要重新投入。

八、取舍与开放问题

各方向的证据等级与未决问题汇总：

方向 最强证据 证据等级 开放问题
chunk-wise 流水线 SGLang 源码默认行为；DualPath 数字 源码 + 论文数字 短上下文下收益缩水的量化
cache-aware 路由 llm-d 实测（8730 vs 4429 tok/s） 第三方实测 与负载均衡的双目标权衡（herding 失效模式）
去重/增量 Mooncake 全局命中率 2.36× 于本地 论文口径（FAST 25） 去重命中率的负载依赖性
混合路径 SGLang 门控接收器实现 源码 + 设计文档 直连与 Store 的切换开销量化
线上量化 CacheGen 4.3×（精度损失 <2%） 论文数字 无主流引擎默认集成；dtype 契约如何统一
稀疏感知传输 HiSparse 在加载路径落地 源码级分析 传输路径上的端到端实现与精度边界
传输隔离 GPU staging buffer 2–5× 厂商文档（目标是吞吐非隔离） 隔离本身的系统性方案缺失
故障恢复 Mooncake 租约/副本语义 设计文档 端到端会话迁移无公开实现与数据

三点提醒。第一，本文所有厂商口径数字（Mooncake 复用率、staging buffer 加速比）未经独立复现。Mooncake 的吞吐提升数字存在两个口径：arXiv 早期版本报告模拟场景最高 525%，FAST 25 正式版改为真实 trace 的 59%–498%，建议引用时用 FAST 25版本。第二，壁仞的 90.5 KB/token 与 55 TB 是 BF16 口径的说明性推演，FP8 常驻的部署按更小数值估算。第三，压缩与重叠两轴的收益会互相挤压：字节数降下来之后，重叠的窗口也随之变小——两轴不是独立的加法。

相关阅读

参考资料

  1. 壁仞科技研究院《深潜｜异构PD分离原理与探索》，2026-09-16

    本文框架起点：Roofline 分工、三类数据路径计时框架、GLM-5.3 容量账（BF16 口径 90.5 KB/token、55 TB）、Token 经济公式、跨机房与存储解耦边界。文中 KV_bytes_put/KV_bytes_get 关系、block 级提交流水线、「带宽预留、流量治理」等表述引自该文。原文声明其公式与计价参数为理论说明、非实测。

  2. SGLang 公开文档与源码（advanced_features/pd_disaggregation.mdx、disaggregation/prefill.py 等）

    chunk-wise 发送（prefill.py:888-892，enable_overlap 默认开）、控制面/数据面分离、DecodePreallocQueue 预分配、HiCache 门控恢复接收器、GPU staging buffer（2–5×）、CPU 调优参数、SGLANG_DISAGGREGATION_WAITING_TIMEOUT。

  3. Mooncake Store 设计文档（docs/source/design/）

    多副本 best-effort、租约与 gc_ttl_ms、soft-pin 驱逐（设计文档）；全局命中率 2.36×、prefill 计算节省 48%、Conductor 调度机制引自 FAST 25 正式版论文（经本仓 Mooncake 架构文章核对）。

  4. llm-d 项目提案（docs/proposals/llm-d.md）与路由实测

    prefix-cache aware routing 与 fault tolerance 的架构目标；8730 vs 4429 tok/s 实测数据经本仓 B300 部署篇核对转引（原出处为 llm-d 公开基准）。

  5. CacheGen（SIGCOMM 2024）与 DualPath

    传输压缩编码 4.3×（精度损失 <2%）；层间流水线 JCT −17.21%、吞吐 1.87×/1.96×。两者均为论文口径，经本仓文章转引，未独立复现。

  6. Anyscale 缓存亲和性反方观点

    「平衡复用与负载优于最大化复用」及 request herding / session-level imbalance 失效模式，经本仓 B300 部署篇转引（作者含 NVIDIA 人员）。