普通 Transformer 的每一层通常由两部分组成：
自注意力层（Self-Attention）+ 前馈网络（FFN）
MoE（Mixture of Experts，混合专家）并没有改变 Transformer 的整体框架，而是将部分 Transformer 层中的单个 FFN，替换为多个并行的 FFN 专家。
普通 Transformer 的计算流程是：
Self-Attention → 单个 FFN
MoE 的计算流程则是：
Self-Attention → Router → Top-K 专家 → 加权融合
其中，Router 通常是一个较小的线性网络。它会针对每个 Token 计算专家得分，并选择少数几个最合适的专家参与计算，最后按照路由权重合并专家输出。
需要注意的是，MoE 中的“专家”通常只是参数相互独立的 FFN 子模块，并不是多个完整的大模型。典型 MoE 模型仍然共享：
- Embedding；
- Attention；
- LayerNorm；
- Transformer 主干中的其他模块。
因此，更准确地说：
MoE 是一个共享的 Transformer 主干，加上一组可按需选择的 FFN 专家。
“专家”不一定对应具体领域
MoE 中的专家并不一定明确对应数学、代码、通信或医学等领域。
这些专家通常在训练过程中自动形成不同的特征分工，可能分别擅长处理某些语言模式、语义结构或隐空间特征，但这种分工往往是隐式的，未必具有清晰、可解释的语义标签。
因此，不能简单地把 MoE 理解为“一个数学专家加一个代码专家”，它更接近于模型内部自动形成的参数分工机制。
MoE 为什么能够用更少计算承载更多参数
MoE 的核心特点是：
总参数量很大，但每次推理只激活其中一小部分参数。
例如，标注为“35B-A3B”的 MoE 模型，通常表示模型总参数量约为 35B，但每个 Token 实际激活的参数量约为 3B。
这使 MoE 同时具有三种特征：
- 单次计算量更接近小型模型；
- 模型容量更接近总参数规模；
- 存储和显存需求仍主要取决于总参数量。
因此，MoE 的 FLOPs 较低，并不意味着模型本身很小，也不意味着它容易在单卡上部署。
MoE 为什么不适合初学者直接微调
MoE 可以提高参数规模与计算效率，但其训练和微调明显比稠密模型复杂。
1. 专家负载容易失衡
Router 可能将大量 Token 分配给少数专家，导致：
- 部分专家过载；
- 部分专家几乎得不到训练；
- 计算资源利用率下降；
- Token 出现丢弃或排队。
因此，MoE 训练通常需要额外设计负载均衡损失和专家容量限制。
2. 多卡通信开销较大
不同专家通常分布在不同 GPU 上。Token 经过路由后，需要被发送到对应 GPU 完成计算，再将结果传回。
这种 All-to-All 通信很容易成为训练和推理的性能瓶颈，对硬件互联和并行框架要求较高。
3. 激活参数少，不等于显存占用低
虽然每个 Token 只经过少数专家，但完整模型的专家参数仍然需要被存储或分布到多张 GPU 上。
因此，MoE 主要节省的是计算量，而不是按相同比例降低模型权重的存储需求。
4. 路由机制增加了训练难度
MoE 不仅需要训练各个专家内部的参数，还需要学习 Token 应该被分配给哪些专家。
如果路由训练不充分，可能出现：
- 多个专家学习到相似能力；
- 少数专家垄断大部分 Token；
- 部分专家失效或塌缩；
- 微调后路由分布发生剧烈变化。
这也是 MoE 微调比稠密模型更难稳定的重要原因。
总结
MoE 并不是把多个完整大模型简单拼接在一起，而是：
在共享 Transformer 主干的基础上，用 Router 为每个 Token 选择少数 FFN 专家参与计算。
它通过“总参数多、激活参数少”的方式，在控制计算成本的同时扩大模型容量。但作为代价，MoE 对显存、通信、负载均衡和路由稳定性提出了更高要求。
因此，对于刚开始接触大模型微调的开发者，通常更适合先使用结构简单、训练稳定的稠密模型，再进一步尝试 MoE 模型。