> 读完这篇论文，我脑子里冒出的第一个画面是：有人把一台 14B 参数的巨兽，拆成了 128 块乐高。每一块都不是装饰件——数学、代码、生物医学、电影评论……各归其位。更离谱的是，你只需要拿出其中的 16 块，就能干原来 90% 的活儿。
这不是科幻。这是 Ryan Wang、Akshita Bhagia 和 Sewon Min 今天在 arXiv 上放出来的 EMO（Emergent Modularity via pretraining MoE），来自 UC Berkeley 和 Allen Institute for AI。
---
1. MoE 的"皇帝新衣"
先泼一盆冷水。🥶
Mixture-of-Experts（混合专家模型，MoE）已经被吹了太久了。DeepSeek-V3、Qwen3、Grok……这些万亿参数怪兽的底层都是 MoE。宣传口径永远是："我们只激活一小部分专家，所以稀疏、高效、省内存。"
> Annotation: MoE（混合专家模型） > > 把 Transformer 里每个 FFN 层替换成 $N$ 个小型神经网络（"专家"），再通过一个"路由器"（Router）为每个输入 token 挑选 $k$ 个最相关的专家参与计算。形式上： > $$\text{MoE}(x) = \sum_{i \in \text{TopK}(k)} g_i(x) \cdot E_i(x)$$ > 其中 $g_i(x)$ 是路由器给出的门控权重，$E_i(x)$ 是第 $i$ 个专家的输出。 > > 为什么重要：理论上只算 $k$ 个专家，比算一个巨型 Dense FFN 便宜得多。
问题是——你还得把整个模型塞进显存。
这篇论文用了一个特别扎心的例子：哪怕你的任务只是"算算数学题"，标准 MoE 的 128 个专家里，最后 120 多个都会被不同程度地激活一遍。为什么？因为专家根本没按"数学/代码/医学"来分工。它们按介词、标点符号、冠词来分工。😅
> 标准 MoE 的 top cluster 长这样："Word-internal subword fragments"（6.0%）、"Prepositions of/in/for/to/on/with"（5.1%）、"Copula verbs is/are/was/be"（3.8%）……
这就好比一个公司号称"按需调人"，结果你请个会计做账，财务部来了一两个人，但前台、保洁、保安也都被叫来了——因为他们负责"填表格"和"开门"这两个动作，而做账碰巧也需要填表格和开门。
这不叫稀疏，这叫精神分裂式的稠密。
---
2. EMO 的破局点：文档边界
Ryan Wang 团队的洞察漂亮得让我想拍桌子。
他们没有搞什么花哨的 domain classifier，也没有人工标注"这是数学数据那是代码数据"。他们就做了一件事：
> 同一篇文档里的所有 token，必须从同一个专家池里挑专家。
就这么简单。
> Annotation: 文档级专家池约束 > > 标准 MoE 中，每个 token $t$ 独立选择自己的 Top-$k$ 专家： > $$p_t = \text{softmax}(r(x_t)) \in \mathbb{R}^{n_r}$$ > $$R_t = \text{TopK}(p_t, k)$$ > > EMO 的做法是：先对整个文档的 $T$ 个 token 取平均路由分布，选出 Top-$d$ 专家组成文档专家池 $D$： > $$D = \text{TopK}\left(\frac{1}{T}\sum_{t=1}^T p_t, \; d\right)$$ > > 然后文档内所有 token 只能从这个池 $D$ 里选自己的 $k$ 个活跃专家。池大小 $d$ 在训练时随机采样： > $$d \sim \mathcal{U}\{k, k+1, \ldots, n_r\}$$ > > 这样一来，模型从小到大的各种子集规模都见过，推理时可以灵活裁剪。
为什么文档边界就够了？因为 同一篇文档里的 token，大概率来自同一个领域。一篇数学论文不会突然插进一段菜谱（除非它讲的是"最优烹饪温度"，那也算数学了 🍳）。
这个约束的妙处在于它是自监督的——你不需要任何人工标注，预训练语料天然就有文档边界。不需要 domain label，不需要分类器，不需要人类先验。
---
3. 数字不会撒谎
EMO 的模型规模是 1B 活跃参数 / 14B 总参数，128 个专家（127 路由 + 1 共享），每个 token 激活 8 个。在 1T tokens 的 OLMoE 语料上从头预训练，外加 50B 的 linear annealing。
先给核心结论一张表：
| 部署方式 | EMO | 标准 MoE | 差距 |
|---|---|---|---|
| 全模型 (128 专家) | 42.8 MMLU | 42.4 MMLU | ≈ 持平 |
| 保留 25% 专家 (32 个) | 41.4 | 31.1 | +10.3 |
| 保留 12.5% 专家 (16 个) | 39.9 | 24.6 | +15.3 |
| 保留 6.25% 专家 (8 个) | 36.1 | ~10 (random) | +26 |
注意这个对比的残酷性：
- EMO 在只留 32 个专家 时，MMLU 只掉 1%（从 42.8 到 41.4）。
- 标准 MoE 在同样条件下，掉了 11.3%（从 42.4 到 31.1）。
- 更狠的是：EMO 的 32 专家子集，outperform 了一个从头训练的标准 32 专家 MoE。
在 GSM8K（数学推理）上更夸张：EMO 的 8 专家子集经过 fine-tuning 后，完全恢复了全模型的性能。而标准 MoE 的 8 专家子集输出的是这样：
> Reg. MoE, 8-expert subset: "Olivia $2005 2005 2005 2005 2005 2005 2005 ... [+162 more] 200"
对，就是乱码。🤯 而 EMO 的 8 专家子集：
> EMO, 8-expert subset: "Harry slept 9 hours. James slept 2/3 of 9 = 6. 9 - 6 = 3. The answer is 3." ✅
---
4. 专家学的是"领域"，不是"语法"
论文 Figure 5 的可视化堪称神来之笔。他们用 PCA + spherical k-means 把预训练 token 按路由行为聚成 32 类，然后让 Claude Code 给每个类起名字。
标准 MoE 的聚类长这样：
- "Word-internal subword fragments"（6.0%）
- "Prepositions"（5.1%）
- "Abstract nouns & domain topics"（4.8%）
- "Section breaks & boilerplate punctuation"（4.6%）
- "Film, music, TV & book reviews"（5.1%）
- "Health, medical & wellness"（4.1%）
- "Tech support, IT ops & web dev"（4.1%）
- "Source code"（3.4%）
- "U.S. politics & elections"（3.2%）
- "Biomedical & life-sciences research"（3.1%）
标准 MoE 的专家是在学语法成分——介词、动词、标点。这是因为每个 token 独立选专家，模型发现"所有介词都差不多"，就把它们路由到同一组专家。结果是：一篇文档里的 token 被拆得七零八落，每个 token 去找自己的"语法专家"。
EMO 的专家是在学语义领域——数学、代码、医学、政治。因为文档级约束强迫同一文档共享专家池，模型必须学会"这篇是医学文章，那我们用医学专家吧"。
论文还验证了这一点：用 WebOrganizer 的 24 个人工标注 domain，计算 domain 间的专家激活相似度。EMO 的相似度矩阵清晰地把相关领域聚在了一起（software_development 和 electronics_and_hardware 高度相关），而标准 MoE 的矩阵是一片混沌（所有 domain 相似度 > 0.6）。
---
5. 但别急着开香槟
我得说几句不中听的。😐
第一，EMO 的"other"类别表现很差。在 MMLU 和 MMLU-Pro 的 catch-all "other" category 上，EMO 的 32 专家子集打不过从头训练的 Dense@8 模型。这说明模块化是有代价的：通用能力被稀释了。如果你要一个什么都能干的"万金油"小模型，EMO 的子集不一定是最优选择。
> 这个限制作者自己也很诚实——他们在报告 aggregate MMLU 时刻意排除了 "other" category。
第二，专家选择需要 validation data。虽然论文说"一个 few-shot example 就够了"，但这仍然意味着你需要先知道自己在干什么任务。如果突然丢给它一个从没见过的 domain，它可能不知道该拔哪块乐高。
第三，这篇论文只做了预训练。Instruction tuning、RLHF、tool use……这些下游工序会不会破坏模块化结构？作者没说，但直觉上，SFT 阶段如果混了太多跨 domain 的数据，可能会模糊文档边界学到的那种清晰分工。
第四，也是最让我纠结的一点：文档边界真的足够好吗？互联网上的文档并不总是"单一领域"。一篇博客可能前一半讲技术后一半讲个人感悟。EMO 的处理方式是"整篇文档共享一个池"，这种粗粒度约束在面对高度混杂的内容时，可能会强迫不同领域的 token 挤进同一个池，反而损害性能。作者没有深入讨论这个问题。
---
6. 这到底意味着什么？
好，让我把赌注摆上台面。💰
我的判断是：EMO 不是又一个 MoE 变种。它是第一个把"模块化"当成预训练 first-class 目标来优化的模型。 而且它的方法简单到令人发指——只需要改一行路由逻辑，不需要额外数据，不需要额外标注。
这让我想到一个类比：
> 标准 MoE 像是一栋公寓楼，128 个住户。你每次按门铃，8 个人下来帮忙。问题是，不同的任务需要不同的专业技能，但住户们按"谁擅长开门""谁擅长填表"来组队——而不是按"谁是会计""谁是医生"。结果你请会计做账，门卫和保洁也都来了。 > > EMO 像是一个按楼层分职能的办公楼：3 楼是财务，5 楼是医疗，7 楼是 IT。你只需要知道自己要办什么事，直接去对应楼层找 8 个人就行。整栋楼不用全亮灯。
这个类比在哪里失效？在边界模糊的任务上。如果你的任务横跨"财务+医疗+IT"（比如给医院做数字化财务系统），那你可能还是得多跑几层楼。这就是为什么 EMO 的 "other" category 表现不佳——因为 "other" 本质上就是"难以归类"的任务。
但即便如此，EMO 的潜在影响是巨大的：
| 应用场景 | 可能性 |
|---|---|
| 📱 端侧部署 | 只加载 16 个专家，手机就能跑 14B 级模型 |
| 🧒 内容过滤 | 直接关闭 "spam/gambling/adult" 相关专家集群 |
| 🏥 领域特化 | 只加载生物医学专家，做医学问答 |
| 🔧 模块化更新 | 单独 fine-tune 一组专家，插回全模型 |
| 🔍 可解释性 | 看专家激活就知道模型在"想什么领域" |
---
7. 结语
EMO 给我的最大冲击不是那些数字（虽然数字真的很漂亮）。而是它证明了一件事：模型的结构不必是铁板一块。 我们一直被"一个模型、一套权重、一次性加载"的范式困住了，而 EMO 用几乎零成本的约束，撬开了这扇门的锁。
Ryan Wang 他们在论文结尾说了一句话，我抄下来：
> *"Large language models need not remain monolithic systems. Modularity can be built into pretraining itself."*
翻译成大白话：巨兽不必永远以巨兽的形态存在。它可以是一群随时可以拆散重组的狼。 🐺
这句话的代价是：如果未来半年内没有任何人复现出类似的结果，或者发现文档级约束在其他语料/规模上不 work，那 EMO 就只是一篇漂亮的概念验证。但鉴于作者已经开源了模型、代码、可视化工具，而且方法本身几乎没有工程门槛——
我赌它会 work。
而且我赌，DeepSeek 和 Qwen 的下一代 MoE，已经在偷偷试这个了。👀
---
📚 论文详细信息
| 项目 | 内容 |
|---|---|
| 标题 | EMO: Pretraining Mixture of Experts for Emergent Modularity |
| 作者 | Ryan Wang (UC Berkeley), Akshita Bhagia (Allen Institute for AI), Sewon Min (UC Berkeley & Ai2) |
| 机构 | UC Berkeley, Allen Institute for AI |
| arXiv ID | 2605.06663 |
| 发布日期 | 2026-05-07 |
| 分类 | cs.CL (Computation and Language), cs.AI (Artificial Intelligence) |
| 核心论点 | 通过文档级专家池约束，让 MoE 在预训练中自发涌现语义级别的模块化结构，实现专家子集的独立部署与组合，不损失全模型性能 |
| 模型规模 | 1B 活跃参数 / 14B 总参数，128 专家（127 路由 + 1 共享），每 token 激活 8 专家 |
| 训练数据 | 1T tokens (OLMoE 语料) + 50B linear annealing |
| 关键结果 | 保留 25% 专家仅降 1%，保留 12.5% 仅降 3%；标准 MoE 同等条件分别降 10% 和 15% |
| 论文链接 | https://arxiv.org/abs/2605.06663 |
| 代码 | https://github.com/allenai/EMO |
| 模型 | https://huggingface.co/allenai/EMO |
| 可视化 | https://emovisualization.netlify.app |