Prefill-Decode 分离：别盲目跟风，先看你的请求分布
很多人在聊 vLLM 的 disaggregated prefill，觉得把 Prefill（预填充）和 Decode（解码）拆到不同节点上是性能银弹，但实际上这玩意儿对资源利用率的影响极其两极分化。
下一篇
分享一个关于LLM评测的反直觉结论：过度设计测试集纯属浪费时间 →
简单来说，Prefill 是计算密集型，吃算力；Decode 是访存密集型，吃带宽。如果你的业务场景里，用户输入的 Prompt 特别长（比如分析万字文档），但输出很短，那么 Prefill 阶段会直接把 GPU 显存撑爆，导致 Decode 阶段频繁出现 KV Cache 抖动，吞吐量掉得离谱。这时候做分离才有意义。
但如果你的场景是短输入、长输出（比如写代码或写小说），强行把两者拆开，反而会增加跨节点传输 KV Cache 的通信开销，延迟反而增加。
我在实操中发现，判断是否需要部署分离架构，得先看这个指标：
Prefill 时间 vs Decode 时间 的占比。
如果 Prefill 占据了绝大部分端到端延迟，且你发现 GPU 算力利用率在 Prefill 期间飙升，而 Decode 期间却在空转，那么建议尝试以下部署逻辑：
一、配置 Prefill 节点
专门分配高性能 GPU（如 H100），关闭部分不必要的优化，全力跑计算。
二、配置 Decode 节点
使用显存带宽更高、成本稍低的节点，专注于 KV Cache 的快速读取和 Token 生成。
三、同步机制
确保推理引擎（如 vLLM）的版本支持稳定版的 Disaggregated Prefill，否则在 KV Cache 迁移过程中极易出现内存碎片导致的 OOM。
说白了，这套架构是为了解决大模型推理中“计算”与“访存”打架的问题。如果你的并发量不高，或者请求长度很均匀，没必要把架构搞这么复杂。
