如果你做大模型推理服务，这篇可能戳到一个你每天都在和它较劲的瓶颈。MoE（混合专家）已经是把模型做大的事实标准：参数堆得很高，但每次推理只激活其中一小部分专家，算力开销远小于参数规模看上去的样子。问题出在「怎么把它高效地服务出去」。 现在工业界跑 MoE 的常规姿势是混合并行：注意力阶段用数据并行（DP），把不同请求分到不同 DP 组上各算各的；专家阶段用专家并行（EP），把不同专家分摊到不同设备上。两种并行方式拼在一起，代价是每一层里注意力 DP 组和专家之间都要做一次全局同步——所有人算到这一步必须互相等齐了才能往下走。 这个同步在离线、负载均匀的场景里还算可以接受，但在线服务恰恰最不均匀。真实流量里请求到达速率忽高忽低，每条请求的序列长度也参差不齐，于是不同 DP 组的工作量天然失衡。一旦失衡，快的就得停下来等慢的，论文把这种现象叫 DP imbalance（数据并行失衡），它直接导致严重的同步停顿（synchronization stalls），把首 token 延迟（TTFT）和系统吞吐一起拉下去。换句话说，瓶颈不在算得快不快，而在大家被迫一起等。 ASAP 的思路是把「等」这件事从根上拆掉。它做了两层动作：第一层是 disaggregation（解耦），把注意力阶段和 MoE 阶段分开部署、分开调度，不再绑在同一条同步链路上；第二层是在解耦之上实现完全异步的执行流水线（fully asynchronous execution pipeline），让两个阶段各自按自己的节奏推进，而不是卡在统一的同步屏障前。 支撑这套异步流水线的，是一组专门设计的异步通信原语，再加上跨请求调度（request scheduling）和模型执行（model execution）两个层面的四项协同优化，论文说它们共同把全局同步屏障拆解掉。具体这四项优化分别是什么、各自怎么配合，原文摘要没有逐条展开，这里不替它脑补。 价值聚焦在 prefill（预填充）阶段——也就是模型一次性吞下完整输入提示、把 KV cache 建起来的那一段，它是决定 TTFT 的关键环节，对长上下文、首响应敏感的应用尤其要紧。论文在华为昇腾的 CloudMatrix384 超节点上做了实现和评测，报告相比此前最好的同步服务方案，满足 SLO 的 prefill 吞吐提升约 90%。 要客观看几点保留：这是一篇系统论文，提升数字来自论文自身在 CloudMatrix384 这一特定硬件平台上的评测，能不能迁移到 GPU 集群、不同并行配置或解码（decode）阶段，原文未给出更多结论；它针对的是 prefill 而非端到端全链路，对话类负载里 decode 才是大头。即便如此，把注意力和 MoE 解耦、用异步拆掉全局同步屏障，是 MoE serving 里一个清晰且值得跟进的方向，对正在和同步停顿、DP 失衡死磕的服务团队，这条路线提供了一个具体参照。