Prefill / Decode 分离，我目前理解到了哪一步

第一次接触 Prefill / Decode 分离时，我把它理解成一种简单的资源拆分：两种阶段计算特征不同，所以分别部署。后来才发现，真正困难的并不是“拆开”，而是拆开之后如何继续把请求、KV Cache、调度和故障边界连成一个系统。

问题从哪里开始

Prefill 更接近计算密集型任务，Decode 则更容易受到显存带宽与逐 Token 调度影响。如果让它们共享相同资源池，两种负载会互相干扰；但如果完全拆开，KV Cache 的传输和跨节点协调又会成为新的成本。

拆分不是答案，拆分后新增的边界才是系统设计真正开始的地方。

我现在的理解模型

目前我会从四层观察一套分离式推理系统：请求入口如何判断路由，Prefill 如何选择实例，KV 如何交给 Decode，以及资源层如何分别扩缩。

这个模型暂时足以帮助我阅读框架实现，但还不足以解释所有性能差异。尤其在跨节点部署时，拓扑、传输协议和批处理策略会让问题迅速变复杂。

仍未解决的问题

• 什么规模和负载分布下，分离带来的收益才能覆盖 KV 传输成本？
• 路由器应该感知到请求、Cache、拓扑中的哪些状态？
• 性能收益、系统复杂度和故障恢复能力之间应当如何取舍？

先把问题留在这里。下一次理解发生变化时，再补一篇新的记录。