在 2.1 节讨论模型规模时，我们埋下了一个关键伏笔：MoE 架构打破了“总参数量 = 激活参数量”的等式。以 Mixtral 8×7B 为例，它的总参数量约 47B，但每次前向传播实际参与计算的参数（激活参数量）仅约 13B。这种“看着很大，用着很省”的特性，让 MoE（Mixture of Experts）成为当前突破 Dense 模型算力瓶颈的重要方向。本节从架构原理到工程现实，把这套机制彻底拆透。
一、动机：Dense 模型的天花板与 MoE 的破局点
标准 Transformer 是稠密（Dense）架构：每一层只有一个前馈网络（FFN），每个 Token 都必须与所有参数交互。这意味着模型容量（参数量）与计算成本（FLOPs）被强行绑定——你想让模型更聪明，就必须承受推理时更重的计算负担。
MoE 的核心思想来自认知科学的一个直觉：不同 Token 应该由不同的“专家”处理。例如，代码 Token 交给擅长语法的专家，数学 Token 交给擅长计算的专家，文学 Token 交给擅长修辞的专家。由此，MoE 将 FFN 层拆分为多个并行的“专家网络”，并通过一个“路由”机制动态调度，从而实现了：
用更多的总参数量提升模型容量，却用更少的激活参数量控制单次推理成本。
二、核心架构：FFN 层的“分身术”
在 Decoder-only 架构中（3.7 节），MoE 的改造通常只针对 Transformer Block 中的 FFN 子层（3.6 节），而自注意力层（Attention）保持不变。具体结构如下：
1. 专家组（Experts）
将原来单一的 FFN 替换为 $N$ 个结构相同、参数独立的专家 FFN（常见 $N=8, 16, 64$）。每个专家本质上就是一个标准 FFN（两个线性变换夹一个激活函数）。
2. 路由网络（Router / Gating Network）
这是一个轻量的可学习线性层。输入是当前 Token 的隐状态向量 $h$，输出 $N$ 个 logits，经过 Softmax 后得到该 Token 对每个专家的亲和度分布 $G(h)$。
3. Top-K 选择与加权融合
模型并不让所有专家都参与计算，而是只选择亲和度最高的 Top-K 个专家（实践中 $K=1$ 或 $2$）：
- Token 只进入这 $K$ 个专家做前向计算；
- 最终结果按路由权重加权求和：$y = \sum_{i \in \text{TopK}} G(h)_i \cdot \text{Expert}_i(h)$；
- 未被选中的 $N-K$ 个专家，对该 Token 的计算量为零。
这就是“稀疏激活”的物理含义：虽然总参数量膨胀了 $N$ 倍，但单次推理的计算量只膨胀了 $K$ 倍（通常 $K \ll N$）。
三、稀疏激活的关键：路由机制与负载均衡
稀疏激活不是简单的“选前几名”，它面临一个致命的工程问题：负载崩塌（Load Imbalance）。
如果路由网络很快学到“专家 3 最靠谱”，它可能会把 90% 的 Token 都塞给专家 3，导致：
- 专家 3 过载，其他专家沦为摆设，模型容量严重浪费；
- 分布式训练中某些 GPU 爆满，某些 GPU 空转；
- 最终训练崩溃或收敛到局部最优。
因此，MoE 训练必须引入负载均衡机制：
| 机制 | 原理 | 作用 |
|------|------|------|
| 辅助损失（Auxiliary Loss） | 在总损失中加入一项，惩罚路由分布的不均衡，鼓励各专家被均匀调用 | 防止“马太效应” |
| 专家容量（Expert Capacity） | 设定每个专家在一个 batch 中最多处理 $C$ 个 Token，超出的 Token 被标记为溢出，送至下一优先专家或旁路 | 硬性兜底，避免单专家爆炸 |
| Noisy Top-K Gating | 在路由得分中加入少量随机噪声，打破训练初期的对称性 | 防止所有专家从一开始就被差异化淘汰 |
以 Mixtral 8×7B 为例，它采用 Top-2 路由 + 负载均衡辅助损失，确保 8 个专家都能被充分训练；而 Google 的 Switch Transformer 则激进地采用 Top-1 路由（每个 Token 只选一个专家），把稀疏性推到极致，以此验证万亿参数稀疏模型的可行性。
四、训练与推理的工程现实
MoE 的“省计算”是理论上的，工程落地却充满了权衡。
1. 训练侧：专家并行（EP）与 All-to-All 通信
- 由于专家数量多，单卡显存放不下所有专家，必须采用专家并行（Expert Parallelism）：不同专家放在不同 GPU/节点上。
- 每个训练 step 中，Token 需要根据路由结果被分发到目标 GPU，计算完成后再汇总回来。这会产生大量的 All-to-All 通信。
- 真相：MoE 训练往往不是被计算卡脖子，而是被网络带宽和通信延迟卡脖子。如果你的集群节点间互联带宽不足（如普通以太网），MoE 的训练效率会断崖式下跌。
2. 推理侧：显存墙与延迟悖论
- 显存是刚性的：服务一个 47B 总参数量的 MoE 模型，需要加载全部 47B 权重到显存（或做极致的 CPU/GPU 分层卸载）。你无法像 Dense 模型那样按“激活 13B”来准备显存。这是 2.1 节强调“下载和加载时需要 47B 的磁盘/显存”的根本原因。
- 延迟不一定更低：虽然计算 FLOPs 减少了，但内存带宽（把大权重从显存搬进计算单元）和路由开销（Top-K 选择、索引跳转）可能成为新瓶颈。在小批量（batch size = 1）生成场景中，MoE 的 token-by-token 解码延迟相比同激活规模的 Dense 模型可能没有明显优势，甚至因为显存带宽压力更大而略慢。
- 甜区在大批量高吞吐：当 batch size 较大时，MoE 的计算节省效应才能充分显现，单位算力产出的吞吐量显著优于 Dense 模型。
五、MoE 不是银弹：四个实用认知
结合 1.4 节的五层架构视角，MoE 的落地需要清醒的判断：
认知 1：MoE 省的是计算，不是显存
如果你连加载全量权重的显存/内存都凑不齐，MoE 对你毫无意义。端侧部署（手机、嵌入式）目前仍是 Dense 小模型的天下。
认知 2：MoE 微调比 Dense 模型更脆弱
在 SFT（5.1 节）和 RLHF/DPO（5.2、5.3 节）阶段，领域数据的分布可能极度偏斜（例如全是法律条文），导致路由网络“偷懒”——把所有 Token 塞给一两个通用专家。此时需要更小的学习率、更强的正则化，甚至冻结部分路由参数。
认知 3：通信拓扑决定 MoE 生死
单机 8 卡 A100 用 NVLink 跑 MoE 和跨机房以太网跑 MoE，完全是两个体验。工程层（1.4 节第四层）的集群网络设计，往往比算法层的路由改进更能决定训练效率。
认知 4：Dense 与 MoE 正在融合
最新趋势并非“非此即彼”。例如 DeepSeek-MoE 引入了“共享专家 + 路由专家”的细粒度设计：少量专家对所有 Token 可见（共享），其余专家按需激活（路由）。这缓解了纯 MoE 的负载均衡压力，也提升了小样本场景下的稳定性。
六、小结
MoE 架构通过在 Transformer 的 FFN 层植入多专家并行 + Top-K 稀疏路由，实现了模型容量与计算成本的解耦。它是 Scaling Laws 在算力与显存约束下的自然进化。
记住三个关键数字和一个核心约束：
- $N$：专家总数，决定总参数量与理论容量上限；
- $K$：激活专家数（通常 1 或 2），决定单次推理的实际计算量；
- All-to-All 通信：决定分布式训练效率的天花板；
- 核心约束：显存按 $N$ 准备，计算按 $K$ 估算，两者不可混淆。
当你再看到“总参数量 100B+，激活仅 10B”的模型宣传时，你就知道该问什么了：单卡显存够不够装下那 100B？集群网络能不能扛住专家并行的通信？路由策略在领域微调时会不会崩溃？这些问题，比参数数字本身更能决定 MoE 在你手里的真实价值。