PD分离

vLLM 团队 7 月 14 日发了与 TileRT 合作的博客，标题点出一个常被忽略的洞察：当 prefill 与 decode 分离之后，decode 侧其实是可以拔插的。 为什么 decode 侧值得单独做一个引擎？ prefill 是算力密集，堆矩阵乘优化就行；decode 是内存带宽密集，每吐一个 token 都要把整份权重从 HBM 读一遍。两类负载对引擎设计的要求完全不同。分离之后，prefill 池可以用一套优化，decode 池则可以换上为「低延迟流式输出」量身定做的引擎。 TileRT 就是这样一个面向延迟关键场景的专用 decode 后端。它把 decode 阶段的算子排布、访存模式重新组织，目标是把 token 间延迟压稳，而不是追求单批次最大吞吐。 可插拔 decode 带来什么架构启示？ 这件事的意义超出 vLLM 本身：它说明推理栈正在模块化。prefill、decode、路由、缓存各成一层，谁的实现更好就替换谁。对云厂商，这意味着可以针对自己的硬件做 decode 后端，而不必维护整套推理框架。 落地时该怎么选专用 decode 引擎？ 如果你的业务是对话式、对首 token 与流式延迟敏感，值得关注可插拔 decode 引擎；如果是批量离线处理，吞吐优先，专用 decode 带来的边际收益有限。 专用 decode 引擎是不是人人都该上？ 推理服务的「微服务化」已经开始。未来选推理栈，不再是选一个全家桶，而是像拼乐高一样选 prefill 池、decode 引擎、路由层各自最优的组合。 什么情况下反而不该追这个新引擎？ 可插拔 decode 引擎听上去很美，但它面向的是「延迟敏感、高并发流式」这一类特定负载。如果你的业务是离线批量生成、夜间跑批，吞吐与单位成本比毫秒级延迟更重要，那 decode 侧专用优化带来的收益有限，反而引入额外运维复杂度。判断标准很简单：打开你的线上 SLA，如果核心指标是「首 token 后多久出完一段」且用户在盯着屏幕等，那就值得上专用 decode；如果用户根本不看流式过程，提交后等结果就行，留在通用引擎上更划算。架构选择永远跟着负载走。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：TileRT解码 ...

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 通道吃网络，别让它成为新瓶颈。拆分后务必做全链路压测，单看单侧性能没有意义。 ...