How PD Disaggregation Transfers KV

为什么值得回答

KV Cache 的跨节点传输路径会直接影响 PD 分离的首 token 延迟、吞吐与部署拓扑。

验证路径

  • 明确 KV Cache 的字节规模
  • 比较 GPU Direct、RDMA、主机中转等传输路径
  • 调研具体推理系统的传输与路由实现
  • 测量计算与传输能否重叠

机制假设

Prefill 节点生成一段 prompt 对应的 K/V，Decode 节点若不重新计算，就必须拿到相同层、头、位置和 dtype 的 cache，并完成路由与生命周期确认：

1
2
3
4
5
prefill KV
→ 序列化/布局转换
→ GPU Direct、RDMA 或 host staging
→ decode 端校验 request/version/offset
→ 接入本地 cache 并开始 decode

传输字节量约随层数、KV heads、head dimension、token 数和 dtype 线性增长。最小实验应记录 payload bytes、端到端传输时间、重叠比例、cache 命中/失效和跨节点失败恢复；不能只比较带宽峰值。

相关节点：Prefill-Decode Disaggregation、KV Cache、Multi-GPU and Multi-Node LLM Inference。

传输协议必须携带什么

KV 不是一段可以随意复制的字节数组。接收端至少要知道模型层数、KV head 数、head dimension、dtype、token 顺序、起始位置和张量布局；还要把 request/sequence id、generation 版本、分片编号和校验信息与 payload 绑定。若 prefill 和 decode 使用不同并行切分，发送的可能不是完整层，而是接收端所需的 TP 分片；这会把“传输”变成拓扑协商问题。

1
2
3
4
5
6
7
route decision
→ reserve decode slot
→ exchange metadata / layout contract
→ transfer KV chunks
→ checksum + sequence-position validation
→ install into local paged cache
→ release prefill ownership

任一步失败都不能让 decode 假装从错误 cache 继续。安全退化路径通常是丢弃已传 cache 并重新 prefill，代价是 TTFT 变差但结果仍可解释；更危险的是只丢一部分 chunk 后继续生成，这会把网络错误伪装成模型质量问题。

什么时候分离值得付出网络成本

设 prompt 很长、输出很短时，prefill GPU 可能被大矩阵计算占满，而 decode GPU 只承担少量逐 token 工作；分离可以分别扩容两类资源。反过来，如果请求短、输出长或网络带宽/拓扑不稳定，传输 KV 的时间和排队可能超过重新计算，PD 分离只增加故障面。决策应比较：重新 prefill 的计算时间、KV payload 的传输时间、传输与计算的重叠比例、跨节点尾延迟以及 cache 失败重试成本。

最小可证伪实验

固定同一模型、prompt 长度和输出长度，比较同节点复制、PCIe/host staging、RDMA/GPU-direct（若环境支持）和重新 prefill 四种路径。逐步增加 prompt token，记录 payload bytes、TTFT、TPOT、P99、decode slot 等待、校验失败与 fallback 次数。只有在长 prompt 和目标并发下，分离路径同时降低 TTFT 或提高有效吞吐，且 fallback 不超过预算，才说明网络成本被摊薄；单看链路峰值带宽不能得出结论。