MoE 的两个上游创新：Routing-Free 与 OmniMoE

前一篇拆的七项工作，有一个共同前提：

Router 已经给出 token → Expert 的分配，我们优化后面的 dispatch / GEMM / A2A。

这两篇动的是这个前提本身。

工作	改的是哪一层
Routing-Free MoE	谁决定专家激活
OmniMoE	专家本身有多细（外加执行层）
FasterMoE / Tutel	专家怎么分布到 GPU
MegaBlocks	不规则专家 GEMM 怎么块化
ScatterMoE	怎么避免 routing 重排的 materialization
SonicMoE	routing/token 数怎么适配 GEMM tile
Mega MoE	分布式 MoE 整条链怎么 block-streaming 化

核验说明

本文机制描述经一手来源（arXiv 源码 + 官方代码库）核验。文中标出了五处与常见二手总结不一致的地方，以及两条未能证实的项。

---

一、Routing-Free MoE

Yilun Liu*, Jinru Han*, Sikuan Yan, Volker Tresp, Yunpu Ma（LMU Munich / UCLA / MCML） arXiv:2604.00801，2026-04-01。代码 liuyilun2000/RoutingFreeMoE

1.1 把「Router 替所有专家决策」拆掉

标准 MoE 是自上而下的竞争式路由：

$x \rightarrow \text{Router}(x) \rightarrow \text{Softmax} \rightarrow \text{TopK} \rightarrow E_i$

RFMoE 反过来问：为什么要一个中央模块替所有专家做决定？让每个专家自己判断这个 token 想不想接。

每个专家内部有自己的低秩投影：

$G_i(x) = \text{ReLU}\big(\|x A_{\text{gate},i}\|_2 - b_i\big)$

其中 $A_{\text{gate},i} \in \mathbb{R}^{D \times r}$（$r \ll D$）是专家私有的投影矩阵，$b_i$ 是可学的逐专家偏置（初始化 $10^{-6}$ 做 warm-up）。激活是个硬指示：

$f_i(x) = \mathbf{1}\big[G_i(x) \ge \theta\big]$

于是消失的是：外部 router、softmax、固定 Top-K。每个 token 激活几个专家自然可变，$\theta$ 控制整体稀疏度，而且调 $\theta$ 不需要重训。

它真正消灭的是「中心化的竞争式路由」，不是「系统里不再有 routing 这件事」——你依然得知道哪些专家最终激活了才能 dispatch。

1.2 去掉 router 之后，负载均衡成了新问题

这是最容易被漏掉、但对系统影响最大的一节。传统 MoE 的负载均衡损失作用在 router 的概率上；router 没了，出现两种正交的失败模式：

只用哪种损失	后果
仅 token-balancing（$\mu = 0$）	token 被规范到激活目标数量的专家，但专家侧不受约束——少数热门专家垄断，其余饿死
仅 expert-balancing（$\mu = 1$）	每个专家在 batch 内被均匀使用，但每 token 的计算量剧烈波动，对域漂移过敏

解法是联合辅助损失：

$\mathcal{L}_{\text{LB}} = \mu \mathcal{L}_{\text{EB}} + (1-\mu)\mathcal{L}_{\text{TB}}$

$\mathcal{L}_{\text{EB}} = |\mathcal{E}|\sum_{i \in \mathcal{E}} f_i \tilde g_i, \qquad \mathcal{L}_{\text{TB}} = |\mathcal{B}|\sum_{t \in \mathcal{B}} f_t \tilde g_t$

用阈值前的 $G_i(x)$ 作可微代理 $\tilde g$。实测 $\mu = 0.5$ 困惑度最低、吞吐最高。权重还有动态调度：

$\lambda_t = \lambda_{t-1}\exp\big(\eta(\rho_t - \rho_\infty)\big)$

当前密度 $\rho_t$ 超过目标就加压，否则放松。

还有一个值得记的发现：把逐层密度约束放松成全局密度，让首尾层多激活、中间层保持稀疏，Scale S 的验证困惑度从 39.44 降到 28.74。

1.3 执行策略与吞吐拐点

RFMoE 把标准的「Router 矩乘 → Softmax → Top-K → 阻塞式 All-to-All」换成：

1. 非阻塞 all-gather 把 token 广播到全部 $M$ 张卡
2. 每卡流水地为本地 $N/M$ 个专家打分
3. 对激活的 (token, expert) 对算 FFN，复用打分阶段算出的 $xA_{\text{gate},i}$
4. 异步点对点回传，无 barrier

修正一：它在单卡上比标准 MoE 慢

论文自己承认：$M=1$ 时要算全部 $N$ 个 rank-$r$ 门控投影，比中央 router 慢。$M \ge 2$ 才反超，$M=4$ 时 prefill 1.19×、decode 1.12×。

它不是「更快的 MoE」，是「在 EP 下才更快的 MoE」。

推理时把有效密度 $\rho_{\text{eff}}$ 从 100% 降到 4.3%（激活数降 20×，FLOP 降 31%），下游 benchmark 掉不到 2 个百分点。

1.4 规模限定

修正二：专家数只到 24

三档模型是 95.3M / 307.3M / 870.6M（Scale L 总参 870.6M、FLOPs 613.2M），OpenWebText 上从头训 1 epoch。

但更要命的限定是专家数：测过的 $N \in \{12, 16, 24\}$，Scale L 的配置是 Top-6/24。

这让它的开放问题变得尖锐：门控成本是

$O(N \cdot D \cdot r)$

而中央线性 router 是 $O(N \cdot D)$——RFMoE 的每专家门控比中央 router 还贵一个秩 $r$ 的因子。它在 24 个专家上证明了架构可行，但代价函数在 $N$ 增大时是往坏方向走的。论文把这列为已知局限。

---

二、OmniMoE

Jingze Shi, Zhangyang Peng, Yizhang Zhu, Yifan Wu, Guang Liu, Yuyu Luo（HKUST 广州 / BAAI） arXiv:2602.05711，ICML 2026。代码 flash-algo/omni-moe

2.1 把专家粒度推到一个向量

普通专家是一整个 FFN：$d \rightarrow d_{ff} \rightarrow d$。OmniMoE 继续拆，拆到一个 atomic expert 只剩两条向量 $w_i^{in}, w_i^{out} \in \mathbb{R}^d$：

$E_i(x) = \sigma\big(x\,{w_i^{in}}^\top\big)\, w_i^{out}$

本质是一个 rank-1 的 FFN 分量。$\sigma$ 实例化为 SwiGLU。大量 atomic expert 堆成 $W, V \in \mathbb{R}^{N \times d}$——官方实现里就是两张 $(N, d)$ 的 embedding 表 up_embed / down_embed。

和 MegaBlocks 的「细粒度」完全不是一回事：

MegaBlocks:  一个 Expert 仍是一个 FFN，只是执行时切 block
OmniMoE:     模型语义上 Expert 本身就细到 vector

2.2 Cartesian Product Router

$N = 10^6$ 时最朴素的 router $xW_r$（$W_r \in \mathbb{R}^{d\times N}$）成本 $O(Nd)$，光 router 就撑不住。

OmniMoE 把专家 ID $i \in [0, N)$ 拆成二维 $(i_r, i_c)$，$N_r N_c = N$，$N_r \approx N_c \approx \sqrt N$。分别投影：

$p_r = x W_r,\quad W_r \in \mathbb{R}^{d\times N_r}; \qquad p_c = x W_c,\quad W_c \in \mathbb{R}^{d\times N_c}$

隐式分数由 $\operatorname{LogSoftmax}$ 后相加得到：$\mathcal{S}_{ij} = p_r[i] + p_c[j]$。投影复杂度：

$\boxed{O(Nd) \longrightarrow O(\sqrt N\, d)}$

修正三：实际代码还做了候选剪枝，正文没说

论文正文描述的是在 $N_r \times N_c$ 网格上做 tiled 并行搜索。但官方 Triton 实现（omni_router.py:170-200）是先沿每个轴独立做一维 torch.topk，$k_0 = \min(\sqrt N, K)$，再在 $k_0 \times k_0$ 的候选子空间里找 Top-K。

所以省的不只是投影，搜索也被剪到了 $k_0^2$。这一步是否带来召回损失，论文没有讨论。

2.3 Expert-Centric Scheduling

Router 照常给出 token → experts。执行时把 $M = L \times K$ 个 (token, expert) 任务摊平、按 (Expert Group ID, Token ID) 排序、分组批量执行，输出用 scatter-add 写回：

token0 -> E17 E853 E10028          E17:   token0 token1 token2
token1 -> E392 E17  E771     ⟹     E853:  token0 token2
token2 -> E853 E17  E6             E392:  token1

即把计算 DAG 从 for token: visit experts 转置成 for expert: process tokens。

为什么值得转置：atomic expert 只有两条 $d$-向量，token-centric 遍历意味着 $L\times K$ 次分散的小向量查表，严重访存受限，根本没有足够大的 GEMM 去摊薄访存延迟。按专家重聚合之后，每个活跃专家的参数从 HBM 载入 SRAM 一次，被所有需要它的 token 共用，参数复用率

$\eta = \frac{L \cdot K}{|\mathbb{E}_{\text{active}}|}$

于是「随机查表」重新变回「grouped GEMM」。

---

三、三个必须澄清的混淆

3.1 Expert-Centric Scheduling ≠ Expert-Choice Routing

这是最容易搞混的一处。

	Expert-Choice Routing（Zhou et al. 2022）	OmniMoE 的 Expert-Centric Scheduling
层次	模型语义	执行顺序
内容	专家自己选 Top-K token，$E_i \rightarrow \text{TopK}(\text{tokens})$	token 照常选 Top-K 专家
影响	改变归纳偏置和 token 容量	路由语义完全不变

OmniMoE 是标准的 token-choice 路由，只是把执行顺序转置了。

3.2 它不是从 ScatterMoE「倒退」回显式排序

看完 ScatterMoE 的「别 reorder token、让 routing index 直接驱动 GEMM」，再看 OmniMoE 说「按专家重排任务」，容易觉得是退步。

修正四：expert-centric 和 materialize 是正交的两个维度

一手代码（omni_expert.py:930-990）显示：OmniMoE 同样不 materialize 置换后的 token 激活张量，它在 kernel 内部直接用 token_ids 读。只 materialize 一个 1D 标量张量 tail_expert_weights（$L\cdot K \times 1$）。排序开销 $O(M\log M)$，实测占总时间 < 5%。

OmniMoE 排的是任务列表（索引），不是 token 数据——这跟 ScatterMoE「只排索引不排数据」是同一个做法。 两者的差别在遍历序，不在是否落盘。

真正的道理是：最优 layout 策略取决于专家粒度。

	ScatterMoE	OmniMoE
一个专家是	大 FFN	两条 $d$-向量
找到专家后	后面有足够大的 GEMM 摊薄	几乎全是随机读权重
于是	值得接受 indexed load，少一次 copy	值得先重组任务，换回参数复用

3.3 CSR ↔ CSC 的类比成立

token-expert 分配是一张二部图。token-centric 是按行遍历（CSR），expert-centric 是按列遍历（CSC）——同一张图，只是遍历序不同。这正是论文的结构：按列分组成大小 $B$ 的块，块内按行（token）索引排序以获得访存合并。

---

四、消融数据：粒度决定 layout 不是观点，是 24.8 倍

OmniMoE 的组件消融（论文 Table 2）：

替换	延迟	峰值显存	其他
Expert-centric → token-centric	24.8×	417.7×	分散 HBM 查表、访存不合并
Cartesian router → dense router	30.6×	337.5×	专家利用率塌到 4%，不均度 0.24 → 0.77
去掉共享稠密 MLP	—	—	知识 −9%，推理 −21%

最后一行值得单说：纯 atomic expert 撑不起通用语法和推理，必须配一个稠密基底。 这和 DeepSpeed-MoE 的 Residual-MoE（固定稠密 MLP + Top-1 稀疏专家作误差修正）是同一个直觉，隔了四年又被验证一次。

性能与规模

• 基线：Dense、GShard（NVIDIA CuTile kernel）、DeepSeekMoE（CuTile kernel）、PKM（Triton）、PEER（Triton）
• 相对 PEER 10.9×、相对 DeepSeekMoE 15.2×（4096 token、200M FFN 层：73ms / 102ms → 6.7ms）
• 端到端 8×A100 约 14.2k tok/s（PEER 11.6k，PKM 7.9k）
• 6.4B-A1.7B 零样本平均 50.9%（DeepSeekMoE 50.2%，PEER 48.9%，Dense 45.9%）

修正五：$10^6$ 是示意数字

1M 专家出现在第 2.2 节和附录 A，用来说明 router FLOP 的理论降幅（$N_r = N_c = 1000$ 时 500×）。

真实 benchmark 是 $N = 102{,}400$/层（$N_r = N_c = 320$，$K \in [512, 4096]$）；合成的 EP 通信测试做到 $N = 2\text{M}$，用来说明反向通信量在 $N > L\cdot K$ 后饱和在约 80MB。6.4B 模型（28 层，$d = 2048$）每层约 4–5 万个 atomic expert。

---

五、两篇都没有和 MegaBlocks / ScatterMoE 做实证对比

被引用的工作	RFMoE	OmniMoE	有实证对比吗
MegaBlocks	引用	引用	都没有
ScatterMoE	未引用	第 4 节引用	都没有
DeepSpeed-MoE	引用	引用	都没有
Tutel / FasterMoE	—	在 bib 里	没有
DeepSeekMoE	引用	引用	OmniMoE 有（用 CuTile kernel 实现的架构对比）
vLLM / Megatron	未引用	未引用	—

需要注意 OmniMoE 对 DeepSeekMoE 的对比是架构层面的（用 NVIDIA CuTile kernel 重实现），不是和 DeepSeek 自己那套手写 PTX/CUDA 融合 kernel 比。

---

六、存疑

未能证实

1. RFMoE 的接收状态：使用 neurips_2026.sty 预印模板，但是否已被 NeurIPS 2026 正式接收，仅从 arXiv 元数据无法确认。

2. Cartesian router 剪枝的召回代价：代码里 $k_0 = \min(\sqrt N, K)$ 的一维预剪枝在 $K$ 较大时是否损失路由召回，论文未讨论，也未能从实验数据反推。

3. OmniMoE 的多节点表现：6.4B 模型的端到端预训练严格在单节点 8×A100 上完成，跨节点带真实梯度同步的扩展未做实测（附录 C 是合成通信测量）。

4. 非 NVIDIA 硬件：两篇都只有 NVIDIA 实现，可移植性列为公开局限。

---

系列

TileKernels 与 DeepGEMM 的分界线 · MegaMoE 在 MoE 系统谱系中的位置 · MoE 系统七篇精读