你在餐厅见过这种场面：点单区排起长队，出餐区却暂时空着。最自然的办法，是让空闲员工临时帮忙点单，客人一多再立即回到原位。大模型服务也有类似问题。它先集中读完输入，再逐字生成回答；Agent还会不断调用工具、带回结果，让“读多少”和“写多少”的比例频繁变化。服务器若固定分工，就容易一边排队、一边闲置。
Crossflow要做的，正是一次受约束的临时支援。它没有让两组服务器真正互换身份，而是允许Decode节点在有余力时承担有限的Prefill工作，并在生成压力上升时撤回容量。论文的全部效果数字均来自作者自己的公开及内部trace回放；内部数据无法独立复核，峰值结果也不能代替平均表现。
固定分工，撞上了会变的流量
一次LLM请求通常分成两个阶段。Prefill（预填充）是先读完提示词、对话历史和工具返回结果，并建立内部状态，像答题前通读材料。Decode（解码）则利用这些状态逐个生成token——可粗略理解为字词片段——直到回答结束。
Prefill-Decode Disaggregation（预填充与解码分离）把两项工作交给不同服务器池。这样可以分别优化，也能避免较重的Prefill任务干扰Decode逐字输出。不过，它通常依赖静态划分：多少机器负责读，多少机器负责写，提前定好。
Agent流量恰好不服从这种稳定比例。论文对一个大型LLM集群的测量显示，未缓存输入token与输出token之比，在分钟尺度上的峰均比最高达到4.7。这里强调“未缓存”，是因为已经保存的对话前缀不用重新计算。另一份公开Agent trace覆盖134个完整日，输入输出比的小时级单日最大值与最小值之比，中位数为24.5，而且按时段预测的规律很弱。
机器分工却没法同速变化。作者的测试中，启动单个worker需要4分02秒或7分49秒，整个2P4D服务池从启动到可服务需11分02秒或17分31秒，具体时间随模型而异。也就是说，流量比例可能一分钟内已变，重新分配服务器却要十几分钟。若两池都按各自需求的第95百分位准备容量，论文估算四类场景会闲置10.8%至17.5%的均衡集群容量；若少配机器，闲置就会变成排队。
不换岗位，只借一小段余力
Crossflow的关键不是把Decode节点改造成Prefill节点。节点角色、专用配置和默认请求路径都保持不变。只有当Prefill池开始拥堵，而某个Decode节点仍有满足服务目标的余量时，系统才把选中的Prefill任务临时放到该节点本地执行。Decode始终优先；一旦生成负载升高，借出的容量便缩小到零。
这种安排依靠lease（租约）：Decode节点发布一份短期、可撤销的容量承诺。它不只写“我现在有空”，还同时限制本地Prefill计算量、KV Cache容量、数据传输量、预计输出工作以及可接纳的临时任务数。KV Cache是模型读完输入后留下的中间状态，作用像草稿纸，可以避免后续生成时反复重算。
为什么要管得这么细？因为GPU利用率低，不代表它一定适合接Prefill。论文的受控实验显示，在总Decode负载相同的情况下，仅改变任务在四个节点间的分布，能够安全承接的Prefill吞吐量就相差11.3%至34.0%；不同长度的请求偏好的分布方式也不同。批量大小、上下文长度、剩余输出量和KV占用会共同决定干扰，单看一个利用率数字不够。
因此，Crossflow采用两层控制。节点根据实时状态发布租约；集群调度器再判断哪个请求值得借道。它会比较正常路径与临时路径谁更快，也会考虑缓存在哪里、请求需要新算多少输入、未来可能带来多少Decode工作。预留必须原子完成，避免多个请求同时花掉同一份余量。任务到达节点后还要再次检查本地状态；若条件恶化，尚未执行的Prefill会暂停。首个token生成前若失败，请求可退回正常Prefill路径。
提升来自少排队，而不是强行塞活
作者在SGLang中实现了Crossflow，并用GPT-OSS-120B和GLM-5.2在NVIDIA GB300服务器上测试。实验回放保留了请求时间戳、对话顺序、前缀关系和token工作量，并让Crossflow与相同机器数、相同P/D划分的静态方案比较。
在两个模型及公开、内部两类trace的16个匹配负载点上，Crossflow的输入token吞吐量几何平均提高17.4%，输出token吞吐量提高16.2%；最高增幅分别为42.7%和43.4%。几何平均更能代表跨场景的总体表现，43.4%则是高负载下的峰值，不宜单独当作常态收益。
用户更容易感知的是TTFT（Time to First Token，从提交请求到看到第一个token的时间）。论文称，Crossflow在全部评测点都降低了平均TTFT；不同模型和trace组合的降幅区间约为10.0%至57.4%，主要因为Prefill少排了一段队。
代价并非消失。ITL（Inter-Token Latency，相邻两个输出token之间的等待）在部分设置中改善，在另一些设置中恶化。例如GLM-5.2配合公开TraceLab时，平均ITL上升20.9%至34.3%；作者将其归因于本地Prefill对活跃Decode的干扰。这说明“吞吐更高、首字更快”不等于生成过程在所有场景下都更流畅。
为什么值得关注
Crossflow真正重要的地方，不只是一次两位数吞吐提升，而是它改变了弹性的单位。传统方案以整台replica为单位重新分工，动作重、反应慢；Crossflow保留原有拓扑，把短期可借容量变成随时更新的租约。调度系统由此可以追着分钟级流量变化走，而不用预测下一小时究竟更缺Prefill还是Decode。
这也修正了标题中容易产生的误解：“弹性换位”不是两类节点交换岗位，而是Decode节点在明确边界内短暂处理部分Prefill。它更像留在原岗位上的临时支援。对于输入输出比例剧烈摆动的Agent服务，这种细粒度边界可能比频繁重建资源池更实用。
局限与未知
- 结果依赖论文作者的单一信源，其中包含无法公开复核的内部trace；大型LLM集群的所属机构和规模也未披露。
- 论文显示平均TTFT全面改善，但不能据此推断尾延迟同样改善。ITL在部分配置中明显上升，实际部署仍需按服务目标权衡。
- Crossflow在极端静态划分下并非总有收益：公开trace的4P2D配置中，输入吞吐下降2.8%，平均TTFT上升33.3%。可借的Decode节点太少时，弹性边界本身也会受限。