长输入与持续出字，可以分开组织

现在有一批请求正在稳定出字，另一个人突然送来很长的材料。它的 prefill 需要一段密集工作，如果和已有 decode 争同一资源，可能让后续 token 间隔变长。我们先说“可能”，因为实际调度能分块、交错，也可能已经有足够余量。但这确实给出一个系统问题：首 token 和持续出字的需求不同，是否应该让它们使用不同的资源组织？

一种办法是把 prefill 放到一组资源，decode 放到另一组资源，让它们分别选择合适的批量和容量。现在请看新增的箭头：prefill 已经为这份输入算好 K/V，decode 要接着用，状态就必须被传过去。它不是只传一句“请继续生成”就能开始工作。网络传输、排队和缓存放在哪里，都进入成本。若传输太贵，或者负载很轻，拆分未必划算。这个例子说明，减少一种干扰以后，往往需要认真处理另一项资源限制。所以判断拆分是否有效，要比较整条请求的代价，而不是只看其中一个阶段更忙或更快。

在这张图上，Dynamo 可以作为分布式运行时的例子，帮助路由请求、协调不同工作者和资源。KV 暂时不在 GPU 上时，LMCache 所处理的保存、恢复和复用就出现在这一位置；需要更大的 KV 池和传输能力时，可以理解 Mooncake 对应的职责。它们不是三个必须依次安装的关卡，每个部署要按自己的瓶颈选择组合。把状态放到 GPU 外可以扩大可用容量，但取回来也有延迟。我们这三分钟只走完整一条链：长输入干扰持续生成，分开计算，再把状态可靠交接。更细的组件、缓存依赖和网络条件已经放进主题正文。最后再把这套服务能力接回前面讲过的训练。