MoM开源：不做MoE，直接混合模型

截至 2026 年 8 月 31 日，GitHub 上出现了一个名为 MoM-AI 的开源项目，作者将其称为 Mixture of Models，即“模型混合”。它尝试用多个独立 AI 模型协同工作的方式，替代大语言模型中更常见的 MoE（Mixture of Experts，混合专家） 架构。

这不是又一个把模型参数做大的版本，而是一次对“一个模型如何组织能力”的重新拆解：传统 MoE 把多个专家放进同一个模型内部，由路由器选择少数专家参与计算；MoM 则把多个模型本身作为可组合单元，再让它们以类似 MoE 的方式协作。从工程角度看，前者是在模型内部做稀疏激活，后者更接近模型级编排。

目前 MoM-AI 仍处在较早期的社区开源阶段，公开资料还不足以证明它已经在准确率、推理速度或单位成本上击败成熟 MoE 模型。因此，比较准确的判断是：MoM 的想法值得关注，但现阶段应被看作架构原型，而不是已经完成产品化验证的新一代 LLM。

MoE 和 MoM，到底差在哪里？

MoE 是一种在单个神经网络内部稀疏调用专家模块的架构。 在典型 MoE 模型中，模型会包含多个 Transformer 专家层，同一个输入经过路由器后，只激活其中一部分专家，而不是让所有参数同时参与计算。

可以把 MoE 理解成一家公司内部的专家团队。用户的问题先交给前台分流，数学问题交给数学专家，代码问题交给编程专家，但这些专家共享同一套公司的基础设施、训练体系和参数空间。模型总参数量可以很大，单次推理实际使用的参数量却相对较小。

MoM 是把多个相对独立的模型当成可组合组件，通过额外的路由或协作机制完成一次任务。 它的“专家”不再是模型内部的一个前馈网络或 Transformer 分支，而可以是一个完整模型，例如代码模型、推理模型、通用对话模型或特定领域模型。

两者的核心差别可以概括为：MoE 的组合发生在参数和网络层内部，MoM 的组合发生在模型与模型之间。前者更像“一个大脑里的多个脑区协同”，后者更像“多个已经独立训练的大脑组成一个工作团队”。

| 对比维度 | 传统 MoE | MoM（Mixture of Models） | |---|---|---| | 组合单位 | 专家层、前馈网络或网络分支 | 一个或多个完整模型 | | 路由位置 | 通常位于 Transformer 层内部 | 位于模型级或任务级调度层 | | 训练方式 | 往往需要联合训练或大规模继续训练 | 可以先复用已有模型，再训练协作机制 | | 参数共享 | 通常共享主干网络、词表或部分参数 | 模型之间可以完全独立 | | 单次计算 | 激活少量内部专家 | 调用一个或多个完整模型 | | 优势 | 推理效率和参数规模之间取得平衡 | 复用现有模型能力，组合灵活 | | 主要风险 | 路由负载不均、专家坍缩、训练复杂 | 延迟叠加、输出不一致、调度成本高 |

MoM 为什么值得讨论？

MoM 最直接的吸引力，是它允许开发者复用已有模型，而不必从头训练一个巨型统一模型。 过去，模型能力通常被封装在一个权重文件里，模型做什么、不做什么，主要取决于训练数据和微调过程。MoM 则提供了另一种思路：先保留不同模型的专长，再在上层把这些能力组织起来。

例如，一个模型擅长代码补全，另一个模型擅长长链路推理，第三个模型擅长中文写作。传统做法可能是把数据混合后继续训练一个统一模型，或者使用多个独立模型做人工选择。MoM 的目标则是把这种选择机制系统化，让系统根据输入自动决定使用哪个模型、使用多少模型，以及是否需要让模型之间互相校验。

MoM 的第二个价值，是降低“能力合并”对统一训练的依赖。 不同模型往往使用不同数据集、不同 tokenizer、不同上下文长度和不同训练目标。它们并不天然适合直接合并权重，但在模型级别进行协作时，理论上可以绕开部分参数兼容问题。

这也是 MoM 与传统模型合并技术的区别。模型合并通常尝试在权重层面把多个微调模型融合成一个模型，常见做法包括参数插值、任务向量合并或层级替换。MoM 不一定要把权重揉成一份，而是保留模型边界，用调度、投票、蒸馏或多轮交互来获得组合效果。

MoM 的第三个价值，是让模型架构具备更强的可替换性。 如果某个代码模型更新了，理论上可以只替换代码能力模块，而不必重新训练整个系统；如果某个模型在数学任务上退化，也可以把它从组合中移除。这种模块化更接近软件工程中的组件设计，而不是传统单体模型的整体升级。

但它并不是“免费获得多个模型的全部能力”

MoM 最大的现实挑战，是模型级组合会把计算和延迟问题从网络内部搬到系统层面。 MoE 的优势在于多个专家共享大量底层计算，路由后只激活少数分支；MoM 调用的是完整模型，即使每次只选择一个模型，也可能要承担完整的加载、预填充和解码成本。

假设一个系统中有三个模型，每个模型都需要 1 秒完成一次推理。如果 MoM 采用串行协作，先让模型 A 生成草稿，再由模型 B 修正，最后由模型 C 审核，端到端延迟可能接近 3 秒，还不包括调度和数据传输时间。即使三个模型并行运行，显存占用、并发管理和结果汇总也会成为新的瓶颈。

MoM 的第二个挑战，是不同模型之间缺少天然的“共同语言”。 两个模型可能使用不同 tokenizer、不同对话模板和不同特殊 token。即便它们都能处理自然语言，也不意味着它们能无损交换隐藏状态或中间推理结果。

因此，MoM 通常更容易从文本级协作开始，而不是直接交换 hidden states。文本级协作实现简单、模型兼容性高，但信息损失更大；隐藏状态级融合效率可能更高，却要求模型结构、词表、维度和训练方式高度兼容。MoM-AI 后续究竟采用哪一种路径，将直接影响它更像“模型集成框架”，还是更接近一种新型神经网络架构。

MoM 的第三个挑战，是路由器可能成为新的单点瓶颈。 路由器需要判断当前任务适合哪个模型，甚至需要决定是否同时调用多个模型。这个判断如果只依赖关键词，容易被复杂问题误导；如果依赖一个额外的大模型，又会增加成本和延迟，甚至出现“用一个模型判断该用哪个模型”的递归问题。

在 MoE 训练中，研究者需要处理专家负载均衡、路由抖动和专家坍缩等问题。MoM 也会遇到类似现象，只是问题从 token 级别转移到了请求级别：某个模型可能被大量请求挤压，另一些模型则很少被调用；某个强模型可能成为“万能后备”，导致其他模型失去训练和使用价值。

MoM 与模型路由、集成学习有什么区别？

模型路由是根据输入选择模型，模型集成是组合多个模型的输出，而 MoM 试图把两者放进一个更统一的架构中。 这三者容易被混为一谈，但实际侧重点不同。

传统模型路由通常是“一个请求选择一个模型”。比如先用轻量模型处理简单问答，遇到复杂推理再转给更强模型。这种方式已经在许多实际系统中使用，优点是简单、可控，缺点是模型之间没有真正协作。

集成学习则更像“多个模型分别作答，再投票或加权”。它在分类任务中非常成熟，但对开放式文本生成而言，简单投票并不容易，因为不同答案可能都合理，且文本无法像分类标签一样直接比较。

MoM 如果要体现架构创新，需要进一步回答三个问题：第一，模型是如何被选择的；第二，多个模型之间是如何交换信息的；第三，最终结果是由谁生成、谁负责纠错。仅仅把多个模型放在同一个程序里，并不能自动构成新的 LLM 架构。

现阶段最值得观察的技术指标

判断 MoM 是否成立，不能只看项目能否运行，而要看它在相同质量下是否降低了训练或推理成本。 对这个项目，后续最重要的不是宣传性描述，而是可复现实验数据。

建议重点关注以下指标：

1. 单任务准确率：在代码、数学、知识问答、长文本理解和中文生成等任务上，MoM 是否超过组合中的最佳单模型。
2. 增益是否稳定：如果三个模型组合后只在少数测试集上提升，可能只是数据集适配，而非通用架构收益。
3. 端到端延迟：需要同时报告首 token 延迟、每秒生成 token 数和完整请求耗时，不能只公布离线准确率。
4. 显存与并发成本：模型是否需要同时常驻显存，还是可以按需加载；多个模型并行时，吞吐量如何变化。
5. 路由准确性：路由器选中的模型是否真的适合任务，错误路由会带来额外调用和质量下降。
6. 组合规模扩展性：从 2 个模型扩展到 4 个、8 个模型后，收益是否继续增长，还是出现管理成本和噪声快速上升。
7. 故障隔离能力：某个模型输出错误、超时或不可用时，系统能否自动降级，而不是让整个链路失败。

在缺少这些数据之前，不能直接把 MoM 描述成“比 MoE 更高效”或“取代 MoE”。更准确的说法是，它探索了另一种模型稀疏化和能力组合路径。

对开发者意味着什么？

MoM 更适合被看作一种模型系统设计范式，而不是立刻替代现有基础模型的训练方案。 对开发者而言，它的启发主要有三点。

第一，模型不一定要被当成不可拆分的黑盒。未来的 AI 应用可能不再绑定一个固定模型，而是维护一组具有不同能力、成本和延迟特征的模型，根据任务动态编排。

第二，评测对象可能从“模型分数”变成“系统分数”。一个单模型在基准测试上得分更高，不代表它在真实生产环境中更好。真实系统还要考虑失败率、调用成本、上下文长度、并发量和响应稳定性。MoM 的价值如果成立，应该体现在复杂任务的整体完成率和单位成本上。

第三，开放模型生态会因此更依赖标准化接口。不同模型如果拥有统一的输入输出格式、工具调用协议、上下文传递方式和质量评估方法，模型组合才有可能从手工拼装变成可复用基础设施。

不过，开发者也不应忽略维护成本。多个模型意味着多个权重版本、多个运行时依赖、不同的量化方案和更复杂的监控体系。一个模型升级后，原本有效的路由策略可能失效；一个模型改变输出格式，也可能影响后续模型的判断。MoM 的灵活性，往往是用系统复杂度换来的。

我们的判断：方向有意思，证据还不够

MoM-AI 的真正新意不在于“多个模型一起回答”，而在于它试图把模型本身提升为可路由、可组合的架构单元。 这是一个合理且有潜力的研究方向，因为当前开源模型生态已经足够丰富，很多能力并不需要重新训练，只是缺少更好的组织方式。

但从 2026 年 8 月 31 日能看到的公开信息来看，MoM-AI 仍缺少足够完整的基准测试、训练细节和生产级成本数据。它暂时不能证明模型级混合比成熟 MoE 更快、更省显存，也不能证明简单组合就能稳定获得“能力相加”的效果。

更现实的落地路径可能是从混合推理系统开始：轻量模型处理常规请求，专业模型处理困难任务，多个模型在高风险场景中互相审查，再由一个最终模型负责统一输出。等路由策略、信息交换和联合训练逐渐成熟后，MoM 才可能进一步演化为真正意义上的模型级神经架构。

对研究者来说，值得继续看它是否公开路由器设计、模型协作机制和消融实验；对应用开发者来说，可以关注它是否能在相同硬件和相同质量目标下减少成本；对普通用户来说，现阶段不必把它当成已经击败 MoE 的新范式。

结论很简单：MoE 在模型内部做稀疏化，MoM 在模型之间做组合；前者已经经过大规模验证，后者刚开始接受工程现实的检验。 MoM-AI 值得加入观察名单，但它下一步需要的不是更响亮的概念，而是可复现的数字：质量提升多少、延迟增加多少、显存占用多少，以及这些代价是否值得。

参考来源

• MoM-AI GitHub 仓库：项目代码与开源说明，介绍 Mixture of Models 的基本思路。
• Reddit：Created a new architecture for Large Language Models：项目作者或社区用户发布的背景介绍与讨论入口。