九月底挂出、近期在 serving 圈被讨论的 CascadeEP（arXiv 2609.33252），专治 MoE 在 prefill 阶段的一个隐蔽瓶颈：注意力副本之间的失衡。分布式 prefill 把一个大请求切给多个注意力副本并行算，问题是哪个副本恰好命中了一个热门前缀、谁就先算完，谁分到的内容长谁就拖后腿。传统做法是大家在一道全局屏障前等齐——快的副本干等慢的，算力白白空转。CascadeEP 的整套设计，就是拆掉这道屏障。

prefill 阶段的「注意力失衡」到底卡在哪？

prefill 是一次性吃进长上下文、把所有 KV 算出来的阶段，它是算力密集的，和 decode 阶段的访存密集完全两回事。在 MoE 上做 prefill，注意力那部分是并行切到多个副本的，可一旦某个副本的数据更长、或所在 GPU 更忙，它就成了拖全队的长尾。更麻烦的是，专家计算（EP）本来要等所有注意力副本把 token 都准备好才能开始，结果就是每个专家都得停下来，眼巴巴等最慢的那个注意力副本交卷。

三道门：异步 EP、streamFFN、机会式权重拉取，各管什么？

第一道是异步专家并行：别等所有注意力副本就绪，哪份 token 到了就让专家先算哪份，专家计算在注意力还在跑时就启动。第二道是 streamFFN：对这些陆陆续续到齐的 token，做流式批处理，在「尽早开始」和「攒够一批再算 FFN 的效率」之间找平衡，而不是来一个算一个把 kernel 启动开销打爆。第三道叫机会式专家权重拉取（OEWF）：那张跑得更快的副本，干脆主动去拉别人还没开始算的专家权重、把别人的活也接过来干。三招合起来，就是让快的别闲着、慢的别硬扛，把全局等待时间压下去。

这种「不等齐」会不会让结果出错？

异步执行最大的工程顾虑是正确性：token 顺序、专家路由、权重拉取，稍微乱一点结果就飘。CascadeEP 的赌注是在 prefill 这种「一次前向、无自回归依赖」的阶段，token 之间本来没有 decode 那种步步依赖，天然允许乱序完成再聚合。这也是为什么它盯着 prefill 做——decode 阶段因果链一环扣一环，就没这么好松绑。对把 prefill 单独拆出来、专门服务长上下文和高并发的团队，这类「拆掉全局屏障」的思路，正是榨干 GPU 利用率的下一个主战场。

去论坛讨论

前往 silicon-agi.com 论坛 参与讨论