[FIXME] [EP07] 聊聊MoE+闲谈学术品味

直播回看链接：https://www.youtube.com/watch?v=mHUBwzlsWjg

特别鸣谢：组织者@月球大叔, 主讲人@Du Kuntai, @Cheng Yihua

飞行嘉宾是Google Deepmind高级研究科学家、OpenMoE的作者Xue Fuzhao

主要方向：Gemini Pretraining、Model Architecture和Multi-Modal LLM
主要工作：OpenMoE, Token-Crisis, AdaTape, Sequence Parallelism和LongVILA.

💥 开场

Fuzhao: 我的PhD七个收获

工程能力是研究的基础。
与有才华的人合作对提升研究品味非常有帮助。
目标是一个简洁且有洞察力的45分钟演讲，而不是整个PhD期间的长篇论文列表。
专注于少量关键论文并深入理解，而不是快速浏览大量论文。
当接触一个新主题时，沿着时间线阅读论文，以研究趋势的演变。
- “监督式练习”：基于当前论文，我接下来会做什么？
换位思考是提升写作和演讲的高效方法。
PhD学位是有帮助的，但不是从事LLM研究的必要条件。

OpenMoE

The original MoE

常见误解：MoE是许多模型的混合。

实际上，它是一个单一模型，在FFN层中有多个专家。

Router决定激活哪些专家。

Router是一个简单的线性层，通过点积运算。

图示来自Switch Transformers (2022)

https://arxiv.org/abs/2101.03961

History of MoEs

2017: LSTM + MoE

Gating network

Naive hard selection不可微分。
这项工作使用了一些技巧使其可微分。

2021: Gshard from Google (MLSys)

MoE：增加参数数量而不增加FLOPs → 更稀疏 → 更节省内存。

Expert parallelism：不同的专家分布在不同的GPU上。

引入了额外的all-to-all通信开销。

2021: Switch Transformer

第一个开源的MoE，非常重要的工作。

基于T5构建。由于T5太大，使用它的人不多。

后续工作：GLaM, ST-MoE…

Awesome-mix-of-experts: 10篇必读论文 https://github.com/XueFuzhao/awesome-mixture-of-experts

Google当时做了很多相关工作。

2023: OpenMoE → 一系列开源MoE模型

GPT4使用了MoE

Fuzhao当时为什么选择MoE：在扩展规模时，MoE依然表现良好

在TPU上训练了一年。

现在性能一般。主要贡献是可视化带来的insights。

Kuntai：MoE会越来越流行，因为它性价比高。vLLM正在尝试更高效地支持MoE

总结

2017: LSTM + MoE
2021: Gshard (MoE MLSys)
2021: Switch Transformer (MoE)
GLaM, ST-MoE
2023: OpenMoE, Mixtral
2024: DeepSeek-MoE, OLMoE https://github.com/allenai/OLMoE?tab=readme-ov-file
2025: LLaMA-4

MoE曾经很难训练

📌 Formal definiton

给定E个专家：

$$
MoE(x) = \sum_{i=1}^{E} g(x)_i e_i(x)
$$

其中e_i()是第i个专家的非线性变换，g()_i是可训练的router g()输出的第i个元素。

通常，e()和g()都由神经网络参数化。

g()扩展实验：没有明显收益

TopK selection

为了保证g()的稀疏路由，使用TopK()选择排名靠前的专家。

公式如下：

$$
\text{g(x) =TopK(softmax(f(x) + ε))}
$$

其中f()是路由线性层，ε是用于探索专家路由的高斯噪声。

Balanced loading

EP：如果4个专家中有一个很热门，3个GPU经常空闲 → 3个E的权重被浪费

不均衡的token分配会降低MoE模型的吞吐量和性能。

为防止这种情况，需要避免两个问题：

太多token被发送到某一个专家
太少token被分配给某一个专家

1. 太多token被发送

为了解决第一个问题，定义了buffer capacity B：B = CKNL

其中：

C: capacity ratio
K: 每个token选择的专家数
N: 每个设备上的batch size
L: 序列长度

对于每个专家，无论分配多少token，最多只保留B个token。

2. 太少token被分配

为了解决第二个问题，在训练时在总损失中加入了如下辅助损失：

$$
l_{balance} = E \cdot \sum_{i=1}^{E} m_i \cdot P_i
$$

m_i：分配给专家i的token比例
P_i：router内部第i个专家的softmax输出（即概率值）。

$$
m_i = \frac{1}{L} \sum_{j=1}^{L} h(x_j)_i
$$

L：token总数（batch size × 序列长度）。
h(x_j)_i：对于第j个token，表示是否分配给专家（是为1，否则为0）。

所以m_i是：

统计有多少token被路由到专家iii，
然后除以token总数，得到专家iii的负载比例。

m是不可微的。因此，定义可微的P_i：

$$
P_i = \text{softmax}(f(x) + \epsilon)_i
$$

当我们最小化l_{balance}时，可以看到m和P都会趋于均匀分布。

注意：P_i是router中Top K的输入

$$
g(x) = \text{TopK}(\text{softmax}(f(x) + \epsilon))
$$

当时，MoE可以节省50% FLOPs。现在可能会更好。

Training on MoE: multi-turn is worse?

MTBench：早期的多轮对话评测基准。

多轮结果比单轮差。类似地，few shot比zero shot差。原因后面会讨论。

MoE会专门化吗？

领域层面？没有专门化。token被均匀分配到不同E。

编程语言？没有

自然语言？有一定程度。相似语言会分到相似E。

Yihua：为什么有些E擅长很多任务。

Fuzhao：一种可能是E处理system prompt。

MoE只是懒得按位置分配吗？没有明显规律。

Context-independent specialization

Token ID专门化？是的

Router只是线性层。没有学到高层语义，只是按token ID路由。

Deepseek V2也是这样。Deepseek V3还没测。

观众：Deepseek R1没有token专门化

专家会聚类相似token吗？

会

E21喜欢编程token

E31喜欢情态动词

E0和E1喜欢’\n’

为什么Context-independent？早期路由学习

路由决策在高层语义还没学好时就已经学会了。

QA: MoE在消费级GPU上

E经常在CPU内存/磁盘中换进换出
如何减少I/O？
基于相关性预取E。例如，如果Ex在第i层被激活，那么Ey很可能在第i+1层被激活。

任务专门化其实就是token专门化：

编程专家：喜欢编程token
数学专家：喜欢数字token
…

https://arxiv.org/abs/2412.14219

末端token丢失

为什么多轮更差？为什么few shot更差？看起来context越长越差。

回忆一下capacity ratio：如果E收到太多token，会丢弃后面的token。

即使有负载均衡，分配到某个E的token还是可能太多。

推理分布和训练分布可能差异很大。例如，短时间内可能有大量编程任务。

context越长，负载越不均衡。

SFT阶段能解决吗？尝试过但失败了。

Kuntai：P/D解耦能解决吗？

Yihua：chunked prefill能解决吗？

Fuzhao：最近Megablock工作没有C

近期进展：Megablock

最近的MoE去掉了capacity ratio C → dropless-MoE (dMoE) → 负载不均衡

→ 降低EP。例如每个GPU 8或16个专家
→ MegaBlocks：将稠密批量matmul转为稀疏matmul

https://github.com/databricks/megablocks

https://arxiv.org/abs/2211.15841

图3. MoE层中的专家计算。以num expert=3为例。

(A) 目前最先进的MoE实现使用批量矩阵乘法并行计算所有专家。这要求所有专家分配相同数量的token且形状一致。

(B) 专家计算也可以用块对角矩阵乘法（块大小相同）来表示。

(C) 为了放宽这些约束，可以构造由许多小块组成的变尺寸块对角矩阵。可以用block-sparse matrix multiplication高效计算。

有很多方法可以高效实现block-sparse matmul。

新趋势：attention-MoE解耦

DeepSeek MoE

更多E，每个E更小：路由更平滑
激活更多E
Shared E：始终开启
- 有EP时，至少有一个GPU不会空闲（可以做shared E计算）

KTransformers：attention在GPU上，MoE在CPU上

https://kvcache-ai.github.io/ktransformers/en/deepseek-v2-injection.html

https://github.com/kvcache-ai/ktransformers

当时的Takeaways

优点
- MoE能节省约50%训练成本（现在甚至更多）
- MoE推理成本节省不到50%
缺点
- MoE训练棘手（负载均衡、训练稳定性）
- MoE更需要大量数据
- MoE对数据多样性更敏感
- MoE通信开销大（EP，不太友好硬件）

什么时候用MoE？

知识很重要 → 用更多参数存储知识
有大量并发请求 → 可以高效利用更多专家
有足够数据时
有更多时间debug时（至少目前阶段）😊

🔔 vLLM MoE支持

核心：处理EP

Route → MoE → Route back

(这次主要是闲聊，vllm源码就不讲啦~)

⚡ Kuntai: 什么是好/坏研究

Insight 1: 人们对什么是糟糕的研究有广泛共识，但对什么是好的研究没有共识。

一篇USENIX Security论文的研究结果：
- 科学的科学：科学研究背后的规则或趋势。
糟糕研究的例子（主要是技术问题）：
- 不一致。
- 不遵循逻辑 → 含糊其辞。
- 图表不对齐 → 表明不一致。
- 没有动机。
- 没有说明为什么它有价值（这不仅仅是研究中的普遍收获）。
PhD培训的目标 → 你知道什么是糟糕的研究，并知道如何避免它。

但人们不知道什么是好的研究（远超技术问题）。

为什么：好的研究与人们的价值体系紧密相关。
- 研究者A：我喜欢有扎实测量的论文。（例如，工业研究者）
- 研究者B：我喜欢有清晰抽象的论文。（例如，欧洲系统社区）
- 研究者C：我喜欢有硬件数据的论文。（例如，移动社区）
- 研究者D：我喜欢实现SoTA的论文。（例如，ML社区）
即使人们对好的研究有价值体系，在短期内做好的研究并不一定有回报。

Insight 2: 区分最优秀的工程师/最优秀的人不是他们的技能/能力，而是他们的选择。

关键：尝试做出一个好的选择，然后全力以赴。
如何做出好的选择：沟通是关键。广泛与他人沟通，然后做出自己的选择。
（个人观点）趋势/未来非常难以预测，充满巧合 → 我们最好领先他人半步 → 做开源研究，贴近工业。

系统社区： 应用非常流行 → 但我们在实践中难以扩展它们 → 我们需要更好的系统。

关键词：非常务实，在大规模上评估，与流行应用紧密结合。

为什么一些教授不希望学生进入工业界：

因为研究的风险远小于在现实世界中做事情。

EP07-MoE+闲谈学术品味