vLLM 文档里 Disaggregated Prefilling 仍标着 experimental，但已经是 2026 年大规模推理服务的主流方向之一。核心想法一句话：把 prefill 与 decode 拆到不同 GPU 池，分别优化。
prefill 与 decode 为什么是两种完全不同的瓶颈？
一次请求进来，prefill 阶段要并行读完整段提示，是算力密集型，瓶颈在矩阵乘；decode 阶段逐个吐 token，是内存带宽密集型，瓶颈在把权重从 HBM 搬到计算单元。混在同一个 GPU 上跑，两者互相抢资源：一个长 prefill 会堵住正在 decode 的请求，让 token 间延迟（ITL）抖动。
拆成两池后，prefill 池专心吃算力，decode 池专心吃带宽，首 token 延迟（TTFT）与 token 间延迟（ITL）可以独立调优，甚至配不同的并行策略。
到底什么时候才值得做 P/D 分离？
请求短、并发低的小服务，拆了反而多一次 KV 搬运的开销。当线上同时存在「大量长文档预填充」与「高并发流式输出」两类负载时，拆分的收益才压过搬运成本。vLLM 现在支持通过 connector 把 prefill 算好的 KV 块传到 decode 实例，靠 NIXL 这类高速通道做跨节点传输。
P/D 分离是不是抄大厂架构就行？
PD 分离不是银弹，而是一道容量规划题。先量出你线上 TTFT 与 ITL 哪个先触 SLA，再决定拆不拆、怎么配比两池 GPU。盲目抄大厂架构，常常是花钱买复杂度。
prefill 池与 decode 池该怎么配比？
做容量规划时，先分别统计 TTFT 与 ITL 的线上达标率。如果 TTFT 先顶不住，说明瓶颈在 prefill 池，该加 prefill 侧 GPU；如果 ITL 抖动，说明 decode 池挤，该加 decode 侧。一个常见错误是按 1 比 1 平均分配两池，实际长上下文场景里 prefill 算力需求常常远大于 decode。建议从 prefill 多配起步，再根据监控回调。还要预留 KV 跨节点传输的带宽预算——NIXL 通道吃网络，别让它成为新瓶颈。拆分后务必做全链路压测，单看单侧性能没有意义。
最后提醒一点：拆分后监控要跟着迁移。原来单实例看的 TTFT 与 ITL，现在要分别挂在 prefill 池与 decode 池上，再加上 KV 跨节点传输的耗时。三段指标一起看，才能定位抖动到底出在哪一段。缺了这块看板，拆完反而比不拆更难排查问题。