HKUST(GZ) · arXiv 2025

OmniMoE

An Efficient MoE by Orchestrating Atomic Experts at Scale

OmniMoE 通过系统-算法协同设计,将专家粒度推向极致,同时保持硬件级的执行效率。 10.9 倍推理加速,并在 7 个基准测试上取得了最优性能。

10.9×推理加速
50.9%平均准确率
O(√N)路由复杂度
核心问题

AI 大脑的"专家困境"

Mixture-of-Experts (MoE) 是当今大型语言模型的核心架构之一。它的核心思想是:不让所有参数同时工作,而是为每个输入选择最相关的"专家"来处理。但专家的"粒度"选择,一直是一个两难问题。

粗粒度 MoE

像大型综合科室

每个专家是一个完整的 FFN 网络。处理任何任务都会激活整个大型专家模块,其中大量参数与当前任务无关,造成严重的计算浪费。

优势

硬件友好,执行效率高

劣势

激活冗余,计算浪费严重

代表模型: DeepSeek-V3 (256 experts), KIMI-K2 (384 experts)

有效激活 冗余激活 未激活
创新 #1

Atomic Expert:最小可路由单元

OmniMoE 将专家粒度推向逻辑极限。每个 Atomic Expert 仅由一对向量参数化,是最小的可路由计算单元。通过 Dynamic Expert Assembly 机制,数千个 Atomic Expert 被动态组合为强大的 token 定制化专家。

全局参数矩阵 W ∈ ℝN×d — 每行 = 一个 Atomic Expert

Top-K 检索到的行 未激活

异构双分支架构

Shared Dense MLP

始终激活 · 处理通用语义推理

+

Routed Atomic Experts

Top-K 动态激活 · 负责长尾知识检索

y = (gx ⊙ σ(x·wx))·vx + MLP(x)
01

Atomic Expert 定义

每个 Atomic Expert Ei 由一个输入向量 win ∈ ℝd 和一个输出向量 wout ∈ ℝd 参数化。 对于输入 token x,其计算为:

Ei(x) = σ(x · wiin⊤) · wiout

其中 σ(·) 使用 SwiGLU 激活函数。每个专家仅 2d 个参数。

02

Dynamic Expert Assembly (DEA)

所有 N 个 Atomic Expert 的参数被整合到两个全局矩阵 W, V ∈ ℝN×d 中。对于每个 token,DEA 执行两步操作:

Retrieval从全局矩阵中检索 Top-K 相关专家的参数行
Assembly将检索到的参数行组合为紧凑的 K×d 计算块
03

为什么需要 Shared MLP?

Atomic Expert 的秩-1 结构表达力有限。Shared Dense MLP 作为"通才"处理通用语义推理, 而 Atomic Expert 作为"专科医生"负责长尾知识检索。两者互补,实现了 容量 + 效率 的最佳平衡。

创新 #2

笛卡尔积路由器

当专家数量达到百万级时,标准路由器需要逐一评估每个专家的得分,计算和存储成本都不可承受。OmniMoE 的笛卡尔积路由器将一维的专家索引空间分解为二维网格,将路由复杂度从 O(N) 降至 O(√N)。

核心思想

1D

标准路由:一维搜索

逐一评估 N 个专家的得分 → O(N) 复杂度

... × N
2D

笛卡尔积路由:二维网格

分别在行和列方向搜索 → O(√N) 复杂度

×
= √N × √N
Row (√N)
Column (√N)
Row Column Target

交互式复杂度对比

拖动滑块调整专家数量,观察标准路由与笛卡尔积路由的计算成本差异。

专家数量 (N)16K
1K32K1M
标准路由器O(N)
路由 FLOPs33.6M
参数存储16.8M
笛卡尔积路由器O(√N)
路由 FLOPs524K
参数存储262K
路由计算加速比
64.0×

当 N = 16K 时,笛卡尔积路由器的计算量仅为标准路由器的 1.56%

工作原理

1

二维网格分解

将 N 个专家视为 √N × √N 的二维网格上的坐标 (i, j)。每个专家不再用一个编号标识,而是用"行号 + 列号"定位。

2

独立边际分布

用两个小矩阵 Wr 和 Wc 分别计算行和列的概率分布。核心假设:p(i,j|x) ≈ pr(i|x) · pc(j|x)。

3

隐式评分 + 并行 Top-K

在 log 空间中,联合得分变为加法:Sij = pr[i] + pc[j]。无需物化完整的 N 维得分矩阵。

创新 #3

专家中心调度

路由问题解决后,新的瓶颈出现在执行层面。传统的 Token-Centric 方式中,每个 token 独立获取其专家参数,导致大量随机内存访问。OmniMoE 的 Expert-Centric Scheduling 反转了执行顺序,将散乱的内存操作转化为高效的批处理。

调度流程对比

Token-Centric(传统方式)

Tokens
T0
T1
T2
T3
T4
T5
Memory
E0
E1
E2

Expert-Centric(OmniMoE)

E0
T0
T1
T3
T4
GEMM
E1
T1
T2
T3
T5
GEMM
E2
T0
T2
T4
T5
GEMM
1

任务收集

将所有 (token, expert, weight) 三元组展平为 M = L × K 个任务

2

专家压缩

收集唯一活跃专家,按 ID 排序,每 B 个分为一组

3

层次排序

主键 = Group ID,次键 = Token ID,优化内存局部性

4

Grouped GEMM

每组加载一次专家参数,复用于所有分配到该组的 token

核心洞察:内存流量大幅降低

Token-Centric 的内存流量为 D = 2d·L·K(每个 token 独立加载专家参数),而 Expert-Centric 仅为 D = 2d·|Eactive|(每个活跃专家只加载一次)。 当 L·K 远大于 |Eactive| 时,内存 I/O 减少数个数量级,将执行瓶颈从 memory-bound 转为 compute-bound。

实验结果

又快又准的惊人表现

OmniMoE 在 6.4B 总参数(1.7B 激活参数)的配置下,在 7 个基准测试上取得了最优的 zero-shot 准确率,同时实现了比 PEER 快 10.9 倍、比 DeepSeekMoE 快 15.2 倍的推理速度。

10.9×
推理加速
vs PEER (73ms → 6.7ms/step)
50.9%
平均准确率
7 个 benchmark 最优
15.2×
vs DeepSeekMoE
推理延迟降低

推理延迟对比

单步推理延迟(ms/step),越短越好

OmniMoE
6.7ms
DeepSeekMoE
102ms
PEER
73ms
Dense
6.3ms

关键发现:OmniMoE 的推理延迟(6.7ms)接近 Dense 模型(6.3ms),但拥有远超 Dense 的模型容量和准确率。相比同为细粒度 MoE 的 PEER,OmniMoE 快了 10.9 倍。

下游任务性能对比

6.4B-A1.7B 模型在 7 个 benchmark 上的 zero-shot 准确率

MMLU
37.5
37.1
37.4
TriviaQA
18.5
17.4
16.9
ARC-E
61
60.7
57.4
PIQA
78.7
77.2
75.9
HellaSwag
60.9
61.2
56.3
OBQA
40.3
38.9
39.1
Winogrande
59.7
59.1
59.4
OmniMoE DeepSeekMoE PEER

消融实验:每个组件都不可或缺

移除任何一个核心组件都会导致显著的性能或效率退化,验证了系统-算法协同设计的必要性。

配置延迟内存PPLExpert 使用率
Full OmniMoE
1.0×1.0×1.0×100%
w/o Shared MLP
0.86×0.98×1.2×100%
w/o Cartesian Router
30.6×337.5×1.4×4%
w/o Expert Scheduling
24.8×417.7×1.0×100%

关键发现:移除笛卡尔积路由器后,延迟暴增 30.6 倍,Expert 使用率从 100% 暴跌至 4%。这说明标准路由器在百万级专家空间中无法学到有效的专家分工,会退化为只使用极少数专家。移除 Expert-Centric Scheduling 后,延迟暴增 24.8 倍,内存增加 417.7 倍,但模型质量不变,验证了这是一个纯系统层面的优化。