22. MoE Parameter and Compute | MoE 模型参数量计算 (Mixture of Experts)
难度： Medium-Hard | 标签： MoE, 参数量, 路由 | 目标人群： 想理解“大模型为什么能又大又省算”的学习者
MoE 的核心不是“参数越多越好”，而是把模型容量和每次推理/训练时真正激活的计算量分开。它是一个非常典型的“总参数大，但激活参数不一定大”的设计。
这一页要先回答的事
- MoE 为什么能让总参数量上去，但活跃计算量不一定同比上去
- Router / Gate 为什么是 MoE 的关键部分
- 训练和推理时，MoE 的瓶颈不只在算力，还在路由、负载均衡和通信
Q1：MoE 和普通 dense Transformer 的参数量差别在哪里？
点击展开查看解析
普通 dense Transformer 的每层参数主要来自：
- Attention
- FFN / MLP
而 MoE 会把原本的 FFN / MLP 替换成多个专家（experts）。粗略地说：
- 一个 dense FFN 的参数量约为
2 d d_ff - 如果有
E个专家，那么专家总参数量约为E × 2 d d_ff - 但每个 token 通常只会激活
k个专家，而不是全部E个
所以 MoE 的特点是：
- 总参数量：很大
- 单 token 激活参数量：相对没那么大
- 单 token 计算量：通常按
k而不是按E增长
这就是为什么 MoE 常被用来扩大模型容量，但不把每次计算都线性放大。
一个最常见的直觉例子是 Mixtral 8x7B：
| 维度 | 量级直觉 |
|---|---|
隐藏维度 d | 4096 |
专家数 E | 8 |
激活专家数 k | 2 |
d_ff | 约 4d = 16384 |
如果只看专家 FFN，单个专家参数量大约是 2 × d × d_ff ≈ 134M，8 个专家加起来大约 1.07B 级别。加上 Attention、Embedding 和其他层之后，模型总参数可以到 47B 左右，但每个 token 实际只激活其中一小部分，常见说法是“活跃参数”大约在 13B 量级。
Q2：Router / Gate 为什么重要？
点击展开查看解析
Router 的作用是决定 token 该去哪些专家。
这里有三个工程问题最关键：
- 路由质量：token 是否被分到“合适”的专家
- 负载均衡：某些专家会不会被过度使用
- 容量限制：每个专家能接收多少 token
如果路由不稳定，就会出现：
- 部分专家很忙，部分专家很闲
- token 被丢弃或回退
- 训练和推理吞吐波动
工程上还常常会看到“容量因子”这个概念：如果每个专家可接收的 token 超过其预算，就可能触发溢出或丢弃。换句话说，Router 不只是决定“去哪里”，还决定“会不会塞爆”。
因此 MoE 不是“加几个专家就完事了”，真正难的是让 Router 在训练中保持稳定、让专家使用尽量均匀、并让通信成本可控。
Q3：为什么 MoE 的“省算力”不等于“省系统复杂度”？
点击展开查看解析
MoE 往往会把一部分复杂度从“算术计算”转移到“调度与通信”：
- token 需要被路由到不同专家
- 专家可能分布在不同设备上
- 聚合结果时可能需要额外通信
- 训练时还要处理负载不均和溢出 token
如果采用专家并行（Expert Parallelism），token 往往要先做 All-to-All 分发到专家所在设备，再把结果汇回。粗略地看，通信量会随着 batch × seq_len × d 线性增长，而专家数和设备切分方式会进一步影响通信压力。
所以 MoE 的典型工程判断是：
- 如果你只看总参数量，MoE 很容易看起来很大
- 如果你只看每 token 的活跃专家数，MoE 又可能看起来很省
- 但真正的系统成本，要把路由、通信、负载均衡和容错一起算进去
这也是为什么 MoE 常常不是“简单替换 FFN”这么简单，而是一个系统级设计。
Q4：训练和推理时，MoE 的关注点一样吗？
点击展开查看解析
不一样，训练和推理的重点差别很大：
- 训练时：所有专家都可能参与梯度更新，负载均衡尤其重要；如果路由长期偏斜，会影响收敛和吞吐
- 推理时：通常只激活 top-k 个专家，未被路由到的专家不参与当前 token 的计算
这意味着：
- 训练更关心稳定性、均衡性和通信开销
- 推理更关心专家加载、显存占用和路由开销
如果做极端优化，还可以把热门专家常驻显存，把冷门专家按需加载，但这会把系统复杂度继续抬高。
Q5：MoE 的常见误区是什么？
点击展开查看解析
“MoE 就是把模型无脑做大”
不对。MoE 的关键是稀疏激活，不是单纯增大总参数。“MoE 训练时计算一定更省”
不完全对。专家总数多，路由和通信可能带来额外成本。“MoE 参数多，所以一定更强”
也不对。训练数据、路由稳定性和专家利用率都很重要。“MoE 和 dense 模型的优化方式完全一样”
不对。MoE 对并行策略和调度的依赖更强。
小结
MoE 的核心判断方式可以记成一句话：
总容量可以很大，但每次真正激活的计算量不一定大。
理解这句话，就已经抓住了 MoE 最重要的工程价值。
关联阅读
MoE 的工程落地和 1C 的分布式通信章节强相关，建议后面接着看：
1C-01通信拓扑与互连技术1C-03并行策略决策框架1C-04通信调度优化
这些内容会帮助你把“MoE 为什么省算”进一步连到“MoE 为什么更依赖调度和通信”。
配合练习
这一页建议和后面的 22_MoE_Parameter_and_Compute_Practice.md 一起看。先把下面三个问题做出来，最容易建立 MoE 的工程直觉：
- 先用一个简化公式算 Mixtral 8x7B 的总参数和活跃参数
- 再模拟 router 的负载均衡，看看 token 分配不均会带来什么后果
- 最后把专家并行的 All-to-All 通信量估出来，建立通信成本直觉
把这三件事做顺手之后，再看更复杂的 MoE 变体会更容易。