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；如果用户根本不看流式过程，提交后等结果就行，留在通用引擎上更划算。架构选择永远跟着负载走。