一句话：MoE 把一个大 FFN 拆成很多个小专家，每个 token 只走其中几个。参数量可以做到十倍，单次推理算力只涨一点。
稠密模型的困境
常规 Transformer 的每一层都是全参数激活：不管输入是「你好」还是一段代码，所有参数都要参与计算。想提升能力就得加参数，加参数就等比增加算力。这条曲线到千亿级开始变得不经济。
MoE（Mixture of Experts）换了个思路：参数规模与计算量解耦。
结构：路由 + 专家
原来每个位置过一个 FFN，现在换成：
- 一个轻量路由网络（Router，通常就是一个线性层）给每个 token 打分；
- 选分数最高的 k 个专家（top-k，常见 k=2，DeepSeek-V3 是 8 选 2 加 1 个共享专家）；
- 只把这 k 个专家的输出按路由权重加权求和。
所以一个总参数 600B 的 MoE，单 token 实际激活可能只有 30～40B。显存要装下全部专家，算力只按激活部分付。
关键工程问题
负载均衡
路由是学出来的，天然会「扎堆」——热门专家被反复选中，冷门专家永远训不到。后果是有效容量下降、训练不稳定。常用手段是加负载均衡损失（auxiliary loss），惩罚专家使用率偏离均匀分布；DeepSeek 后续提出无辅助损失的偏置调整方案，避免辅助损失干扰主任务。
容量因子
每个专家能处理的 token 数有上限（capacity factor × 平均负载）。超出部分会被丢弃（token dropping），该 token 这一层就等于没算。容量因子设太小丢 token，设太大浪费显存，是个需要按业务分布调的参数。
通信开销
专家分散在不同卡上，token 要先 all-to-all 发到对应专家所在卡，算完再发回来。专家并行（EP）的通信量随专家数上升，在跨机场景下很容易成为瓶颈。这也是 MoE 训练对互联带宽要求极高的原因。
微调与部署
- 全参微调代价大，实践多用 LoRA 等参数高效方法，且要注意别把路由训崩；
- 推理时要按专家分布做切分，单机放不下就得专家并行，部署复杂度高于同规模稠密模型；
- 批处理能力对吞吐影响很大，小批量请求下 MoE 的性价比优势会被削弱。
代表工作
| 模型 | 总参数 | 激活参数 | 特点 |
|---|---|---|---|
| Mixtral 8x7B | 46.7B | ~12.9B | 8 专家 top-2，开源 MoE 的标志性工作 |
| DeepSeek-V2 | 236B | 21B | 引入 MLA 压缩 KV Cache，大幅降低推理成本 |
| DeepSeek-V3 | 671B | 37B | 无辅助损失负载均衡 + 多 token 预测，训练成本显著低于同规模稠密模型 |
| GPT-4 类闭源模型 | 未公开 | 未公开 | 业界普遍推测采用 MoE，但官方未确认 |
该不该选 MoE
- 选它：追求单位算力的能力上限、有大规模推理集群、请求批量足够大（to C 产品、API 服务）。
- 慎选：显存受限的边缘部署、请求稀疏的企业内部应用、团队缺少分布式推理运维能力。
一句话判断：MoE 省的是算力，不是显存，也不是运维复杂度。 它把成本从「每次计算」转移到了「常驻显存 + 通信带宽」上，这笔账要按自己的部署形态算。