EMO：MoE 的专家原来在给「的」和「了」打工

MoE 是个特别合理的想法。模型太大？拆成一群小专家，每个 token 只叫两三个干活，省参数、省算力、省钱。DeepSeek-V3 671B 参数，每个 token 只激活 37B，比例 5.5%。Mixtral 8×7B，8 个专家选 2 个。GPT-4 据说也是 MoE。

听着很美好对吧？专数有专攻，数学专家管数学，代码专家管代码。你需要写代码的时候只加载代码那组专家，其他专家不用动——推理成本砍一大截。

但实际情况不是这样。

Allen AI 上个月发了一篇博客讲他们的新模型 EMO。他们做了个实验：把标准 MoE 模型的专家路由模式拿出来聚类分析。结果让我愣了半天。

标准 MoE 的专家聚类结果是：介词、专有名词、系动词、定冠词。

不是数学。不是编程。不是医学。

是”的""是""了""the""your”。

一群吃了几万亿 token 的专家，最后分工是判断这个词是不是介词。你花了几百万美元训练，他们学会了分辨”的”和”了”。

这感觉就像你雇了一支顶尖科学家团队，结果发现他们在分拣螺丝——按颜色。

「按词性分工」不是 bug，是训练方式的必然

这事乍一听像个笑话。但仔细想，它是训练目标的直接后果。

标准 MoE 怎么训练的？每个 token 独立选 top-k 专家。路由器的唯一目标是”选对专家能让下一个 token 预测 loss 最低”。没有跨 token 的约束，没有长期一致性，只管这一个 token。

在这个游戏规则下，按词性分工是最优解。

因为”区分介词和动词”比”区分数学文章和医学文章”在单 token 层面容易太多了。一个 token 是”的”还是”跑”——这是明牌。这篇文章讲微积分还是讲心脏搭桥——你要看上下文。

标准路由把专家困在了 token 级别的局部最优里。每个专家都成了语法分析器，没有一个是领域专家。

这意味着什么？意味着你没法只加载一部分专家来做特定任务。一个”数学问题”里，token 照样会用到”的""是""了”。你的”数学专家”根本不存在——所有专家都在管语法，不管语义。你只能全部加载。

MoE 最大的卖点——按需激活——在标准训练下是空的。

一篇文章的 token，大概率在讲同一件事

EMO 的做法简单到你会问”这也能发”——然后越想越觉得对。

核心观察：同一篇文档里的 token，大概率属于同一个领域。你写一篇医学论文，每一个 token——从”的”到”心肌梗死”——都服务于”医学”这个主题。

约束：训练时，同一篇文档的所有 token，只允许从同一个专家子集里选激活专家。这个子集是路由器自己选的——把整篇文档的 token 路由偏好取平均，选最活跃的那些专家作为”文档池”。

就这么一条约束。没了。

不需要标注领域。不需要人工设计模块边界。不需要告诉模型”数学和代码是不同领域”。让文档边界说话。

有一个工程细节值得提。标准 MoE 在 micro-batch 内做负载均衡——防止专家退化，让每个专家都有活干。但这跟 EMO 的目标直接冲突：micro-batch 通常只有几个文档，负载均衡会让同一文档的 token 被迫分散到不同专家。

EMO 的解法很干净：把负载均衡拉到全局范围。跨数百个文档做平衡——同一文档内 token 用一致的专家池，不同文档间集体覆盖所有专家。两者从冲突变互补。

训练后看效果：EMO 的专家聚类变成了健康医学、新闻报道、政治选举、电影音乐——是语义领域，不是词性。

同一篇健康文章：在标准 MoE 里，token 分散在所有聚类中，最大聚类是”所有格和定冠词”。在 EMO 里，几乎所有 token 归入”健康、医学与保健”一个聚类。

约束对，结构就自己长出来。不需要你画。

12.5% 的专家就够了

这个数字值得停顿一下。

EMO 总共有 128 个专家，每个 token 激活 8 个。推理时，你可以只保留 16 个专家（12.5%），性能整体只掉 3%。只保留 32 个（25%），掉 1%。

对比标准 MoE：同样架构、同样数据训练，专家子集缩小后性能直接雪崩，最小设置下甚至不如随机。

12.5% 意味着什么？意味着这个模型训出来的专家模块，确实捕获了语义能力，不是表面特征。你可以真的只加载”代码”相关的专家来写代码，卸载”医学”专家来省显存。

而且选专家的成本极低。不用跑完整验证集——给一个 few-shot 示例就够了。一个例子就能告诉你哪些专家是管这事的。

对实际部署来说，这是个硬货。14B 的模型，用 12.5% 的专家，活跃参数降到约 1.75B，性能几乎没掉。你现在可以在消费级 GPU 上跑一个本该需要数据中心才能部署的模型。

AI2 在下一盘什么棋

EMO 背后是 Allen Institute for AI（AI2），保罗·艾伦 2014 年创立的非营利研究机构。

这家的路数跟 OpenAI、Anthropic 完全不一样。他们不追求最大最强，追求的是全栈可复现。从 OLMo 开始就是这条线：训练数据公开、代码公开、中间 checkpoint 公开、评估工具公开。不是”发个权重叫开源”，是你能从零复现整个训练过程。

OLMo → OLMoE → Molmo → EMO，四个项目连在一起看，脉络很清楚：

OLMo：证明全开源能做到接近 Llama 2 的水平
OLMoE：把 MoE 引入全开源体系
Molmo：在多模态上不靠 GPT-4V 蒸馏数据，也能追平专有模型
EMO：在 MoE 架构层，解决最根本的组织问题——模型能不能自己学会怎么组织自己

BTX 和 FlexOlmo 是中间探索——试过预设领域路由，效果有限。预定义领域需要标签、带偏见、不灵活。EMO 是这一脉的”去预设”升级：不给领域名，只给结构约束，让数据自己长。

结构会自己长出来

最后说个大一点的。

EMO 最打动我的不是 12.5% 这个数字，不是文档池约束这个技巧，而是它回答了一个更根本的问题：模型能不能自己学会如何组织自己？

过去我们设计 AI 架构，一直在替模型做决定。注意力层负责上下文，FFN 层负责知识存储，MoE 的专家划分我们预设好。每一层分工都是人类画的框。

EMO 说：不对。给正确的约束，结构可以涌现，不需要你画。

文档边界是约束——同一文档共享专家池。这个约束本身不包含任何”领域”概念。它只说”同一文档内的 token 应该用相似的专家”。然后数学、医学、政治、电影——这些概念是自己从数据中长出来的。

这让我想到大脑。大脑皮层没有一块写着”语言区”的出厂标签——是输入信号的结构塑造了功能区的分化。

布罗卡区不是因为基因标注了”管语言”，而是语言处理任务的结构让它自然承担了这个功能。

EMO 在 MoE 上做了一件类似的事：不标注功能，不预设分区，只给一个结构约束。剩下的交给数据。

少画框，多给约束。让组织从任务结构中自然涌现，而不是从设计者的先验中强加。

MoE 模型不用再给介词打工了。下一步是什么，我也不知道。但这条路有意思。

你用过 MoE 模型吗？有没有遇到过”明明只激活一部分专家，但性能还是掉很多”的情况？或者你对模块化架构有什么想法——留言聊聊。

原文参考

Ai2 Team. EMO: Pretraining mixture of experts for emergent modularity. Hugging Face Blog, 2026-05-08. https://huggingface.co/blog/allenai/emo

EMO 技术报告：https://allenai.org/papers/emo | 代码：https://github.com/allenai/EMO | 可视化：https://emovisualization.netlify.app/ | 模型：https://huggingface.co/collections/allenai/emo