Prefill-Decode Disaggregation

一句话解释

PD 分离将 Prefill 与 Decode 放到不同资源池，使两种不同的负载特征可以分别调度和扩缩容。

关键挑战

How PD Disaggregation Transfers KV
请求路由与负载均衡
跨节点传输带来的延迟和带宽成本

请求路径与适用边界

1
2
3

client → router → prefill pool
→ KV transfer / handoff
→ decode pool → streaming response

分离后可以按到达率、prompt 长度和输出长度分别扩缩容，也能避免长 prompt 抢占所有 decode 请求的执行窗口。但 handoff 不只是传一个 ID：decode worker 必须获得与模型版本、tokenizer、RoPE、层布局和 block mapping 一致的 KV 状态。

它值得做的前提是 prefill 与 decode 的 SLO 冲突已经成为主要 P99 来源、长度分布足够分化、网络能承受 KV transfer，并且团队能维护两类 worker。流量小或 prompt 短时，新增路由跳数、传输和故障面可能超过收益。

关键验证包括 transfer latency/带宽、TTFT、TPOT P99、池间排队、handoff 失败重算和版本一致性。它向上连接 Serving and LLMOps，向下依赖 KV Cache，横向对照单池 Continuous Batching。

handoff 为什么可能把收益吃掉

Prefill 产生的 KV 大小近似随输入 token、层数、Hkv、head dimension 和 dtype 线性增长。若 KV 在节点间通过网络传输，收益条件可以粗略写成：

1 2	单池 decode 被 prefill 干扰的等待成本 > 路由 + KV 序列化/传输 + decode 重新接入成本

长 prompt、短输出时，传输的 KV 可能只换来很少的 decode 工作；网络拥塞时，handoff 甚至直接恶化 TTFT。反过来，在高并发、长输出且 prefill/decode 长期互相抢占的流量上，分池才可能用更多网络换来稳定 TPOT。

一次可靠交接需要验证什么

handoff 消息至少要绑定 request id、模型/权重版本、tokenizer/template 版本、token 数和位置编码配置、KV layout/dtype、block table 或等价映射，以及校验/超时信息。decode 端不能只收到“有缓存”，就假设它能解释这段状态；版本不一致时必须拒绝并重新 prefill，而不是产生静默错误。

故障注入应覆盖 transfer 超时、半包、decode worker 重启、prefill worker 在发送后退出和版本漂移，记录重算次数、用户可见 TTFT、KV 带宽、失败率与请求是否重复。若这些数据没有被单独观测，PD 分离就只是把单池排队换成了不可见的网络排队。