先建立直觉：MoE 不是“多个 AI 开会”
如果只记一个画面：把 Transformer 里原本固定的一大块 FFN，换成“很多个可选 FFN + 一个 Router”。每个 token 来时，Router 决定它应该送给哪些专家计算。
为专家打分
继续下一层
Dense 模型的直觉是：“同一层里的参数，对所有 token 都被使用。”MoE 则变成：“不同 token 可以激活不同的参数子集。”因此，一个模型可以拥有庞大的总容量，却不必在每个 token 上把所有专家都跑一遍。
MoE 到底替换了 Transformer 的哪一块？
经典 Transformer block 可以先粗略拆成：
很多现代 MoE 模型主要把原来的 FFN / MLP 子层改造成 MoE：
Dense FFN
每个 token 基本都会经过同一组 FFN 参数。
MoE FFN
每个 token 只经过被选中的少数专家。
所以先把 MoE 看成“FFN 的稀疏化 / 条件化版本”，会比“几个不同人格的 AI 专家”准确得多。
跟着一个 token 走完 MoE
Step 1：拿到 token 的隐藏表示
经过前面的 Attention 等计算后，当前 token 有一个向量表示 h。Router 读取的是这个表示，而不是人为写好的“数学/代码/英语”标签。
Step 2：Router 给专家打分
# 得到对 N 个专家的 routing scores
Step 3：选择 Top-K 专家
# 例如 128 个专家里只激活 8 个
Step 4：只计算被选中的专家
Step 5：按路由权重合并
Router 为什么是 MoE 的灵魂？
如果 Router 选得差，专家再多也没意义。它同时决定模型能力与系统效率：
谁处理这个 token？
不同专家逐渐承担不同模式，形成 specialization。
一次激活多少专家？
越稀疏越省算力，但也会改变容量与表达灵活性。
负载是否均衡？
大量 token 挤到少数专家上，会伤害训练和系统吞吐。
token 被送到哪张 GPU？
专家常分布在不同设备上，routing 会直接触发跨卡通信。
因此 Router 不是一个无关紧要的小分类器，而是模型学习机制与分布式系统之间的接口。
Expert 到底是什么？
“专家”这个名字很容易让人脑补成数学 Agent、编程 Agent、法律 Agent。实际上在经典 Transformer MoE 里，Expert 通常就是一个拥有独立参数的前馈网络模块（FFN / MLP）。
它不会拿着“我是数学专家”的显式标签。所谓专家分工，是训练过程中由数据、梯度与 Router 共同形成的；有时能观察到偏好，但不应把它过度拟人化。
为什么不能让几个“强专家”一直包办？
假设一个 MoE 有 64 个专家，但 Router 逐渐变成：
E2: 31% tokens
E3: 19% tokens
E4–E64: 合计 15%
这会出现典型的负载不均衡 / routing collapse：
- 学习不均衡：热门专家得到大量梯度，冷门专家几乎学不到东西。
- 容量浪费：存了很多专家参数，却长期不使用。
- 设备拖尾：部分 GPU 被塞爆，其他 GPU 算完只能等待。
- 吞吐下降：理论 FLOPs 很漂亮，真实 wall-clock 却可能不好看。
- 正反馈：热门专家越常被选，可能越容易继续被选。
DeepSeekMoE：细粒度专家 + Shared Expert
2024 年 DeepSeekMoE 的核心目标之一，是让专家分工更细、更专门。最值得记住两个设计。
① Fine-Grained Expert Segmentation
传统设计可想成：N 个较大的 routed experts，每 token 选 K 个。DeepSeekMoE 进一步把专家拆成更多、更小的模块，同时激活更多个小专家，让组合方式更加灵活。
粗粒度
单个专家承担的功能跨度更大。
细粒度
同等计算预算下，可形成更灵活的专家组合。
② Shared Experts
如果所有 routed experts 都重复学习公共能力，会浪费参数容量。Shared Expert 负责更通用的知识，让 routed experts 更有空间形成差异化。
从辅助损失到 Loss-Free Balancing
传统：给“负载均衡”单独加一个 loss
语言建模 loss 负责“预测得准”，balance loss 负责“别把 token 全塞给少数专家”。问题是辅助 loss 会产生自己的梯度，可能干扰主任务优化。
Loss-Free：用动态 bias 调节选择概率
2024 年的 Auxiliary-Loss-Free Load Balancing 工作提出：做 Top-K 路由前，对每个专家的 routing score 加一个动态 expert-wise bias。
if expert_i 近期太忙 → bias_i 下调
if expert_i 近期太闲 → bias_i 上调
这样通过偏置影响专家被选择的概率，而不是让一个额外 loss 持续对主模型产生干扰梯度。DeepSeek-V3 的技术报告明确采用了 auxiliary-loss-free load balancing。
MoE 真正昂贵的地方：显存、通信与等待
“671B 总参数、37B 激活”很容易给人错觉：那不就等价于一个 37B Dense？并不是。
1. 不参与计算 ≠ 不需要存储
没激活的专家这一次不做矩阵乘，但其权重仍需驻留在 GPU、CPU 或其他存储层级。激活参数下降 10 倍，不等于权重存储下降 10 倍。
2. Expert Parallelism 带来 All-to-All 通信
不同专家分布在不同 GPU 时，一个 batch 的 token 会按 Router 结果被重新分发：
↓ dispatch by routing
experts on GPU A/B/C/D
↓ expert computation
send outputs back
↓ combine
因此高速互联、通信库、token dispatch、batching 和容量控制都会影响真实效率。
3. 最慢的专家制造等待
如果某张卡收到的 token 显著更多，其他卡即使先算完也可能需要等它。这就是负载均衡直接影响吞吐和延迟的原因。
| 指标 | 能否按激活参数同比例下降？ | 原因 |
|---|---|---|
| 矩阵计算 FLOPs | 通常显著下降 | 只计算被选中的专家 |
| 权重存储 | 不会同比下降 | 全部专家参数仍需保存 |
| 显存需求 | 复杂 | 取决于分片、量化、offload、并行策略 |
| 端到端延迟 | 不一定同比下降 | Router、通信、同步和内存带宽都有成本 |
| 模型容量 | 可大幅增加 | MoE 最核心的扩展优势 |
MoE 现在还在用吗？——仍是核心扩展路线之一
MoE 不是 2026 才出现的新技术；但截至 2026 年 9 月，大量前沿公开模型仍明确采用 MoE。新的重点已经从“要不要用 MoE”，转向“如何让路由、专家粒度、注意力和系统实现更高效”。
采用 DeepSeekMoE，并引入 auxiliary-loss-free load balancing。
Qwen 同时发布 Dense 与 MoE 型号，展示不同规模与部署场景的取舍。
Meta 首批采用 MoE 的 Llama 系列之一；每 token 经过 shared expert 和一个 routed expert。
继续保留 DeepSeekMoE，同时进一步优化 Attention 与长上下文效率。
新的 Causal Encoder–Decoder 非对称结构，让输入与输出阶段使用不同激活规模。
MoE 不只用于纯文本 LLM，也继续进入多模态视觉语言模型。
更大的趋势：从“稠密计算”走向“选择性计算”
所有 token 基本经过同一套大参数块
结构简单、部署成熟，但模型越大，单 token 计算通常也一起上涨。
FFN 开始选择性激活
总容量可以快速增大，但每 token 只支付少量专家计算成本。
Attention、KV Cache、甚至输入/输出路径也在继续结构化压缩
目标越来越明确：让“总能力容量”增长得比“每 token 实际计算成本”更快。
Dense 会被 MoE 淘汰吗？不会
MoE 是重要路线，但不是“所有模型都应该 MoE”。在较小模型、本地部署、极低延迟服务和硬件互联较弱的环境里，Dense 依然非常有吸引力。
| 维度 | Dense | MoE |
|---|---|---|
| 结构复杂度 | 较低 | 较高，需要 Router / dispatch / balance |
| 每 token 参数使用 | 基本使用整层 | 只激活部分专家 |
| 扩大总容量 | 通常同步增加计算 | 可以更快扩大容量而保持稀疏计算 |
| 多 GPU 通信 | 相对直接 | Expert Parallelism 更复杂 |
| 消费级硬件 | 通常更友好 | 总权重很大时更难装下 |
| 超大规模训练 | 稳定成熟 | 容量 / 计算比很有吸引力 |
最容易理解错的 8 件事
专家 = 几个聊天机器人
错。经典 MoE expert 是网络内部的 FFN/MLP 模块，不是 Agent 投票。
一个问题只选一次专家
错。典型 token-level routing 会对不同 token 动态选择不同专家。
总参数 = 单 token 计算量
错。MoE 的关键正是 total 与 active parameters 的分离。
37B active = 37B Dense
错。Attention、共享模块、通信、内存访问与总权重存储都不同。
专家越多一定越强
错。路由、数据、专家粒度、通信与训练稳定性都会限制收益。
没激活的参数不占显存
错。它们这次不计算，但权重仍需被存储在某个层级。
负载均衡只是训练技巧
错。它同时是系统问题，直接影响 GPU 等待、吞吐和成本。
MoE 已经过气
错。2026 年最新公开前沿模型仍在持续使用和改造 MoE。
最后压缩成一张速查表
| 术语 | 你应该立刻想到什么 |
|---|---|
| MoE | 很多专家 + 稀疏选择；用条件计算扩大模型容量 |
| Expert | 通常是独立参数的 FFN / MLP 子网络 |
| Router / Gate | 根据 hidden state 给专家打分并决定计算路径 |
| Top-K | 每个 token 只选择 K 个专家参与计算 |
| Active Parameters | 一次 token 前向传播实际参与的参数规模，不等于总参数 |
| Load Balancing | 防止 token 过度集中到少数专家 |
| Shared Expert | 承担通用能力，减少 routed experts 的知识冗余 |
| Fine-Grained Experts | 把专家进一步拆细，让组合与 specialization 更灵活 |
| Expert Parallelism | 专家分散在不同设备，引入 token dispatch 与 All-to-All |
| Loss-Free Balancing | 动态 routing bias 控制负载，减少额外 balance loss 的梯度干扰 |
5 分钟自测：你是不是真的懂了？
先自己回答，再展开答案。能顺畅说清这些问题，就已经不只是“看过 MoE 视频”。
671B 总参数、37B 激活到底意味着什么？
模型总共拥有约 671B 参数容量，但单个 token 的一次前向传播不会把所有专家参数都计算一遍。不能简单等价成“37B Dense”。
Router 在训练和系统层面分别决定什么？
训练层面决定不同 token 流向哪些专家、专家如何形成 specialization；系统层面决定 token 被 dispatch 到哪些设备，影响通信与负载均衡。
为什么没被选中的专家仍然可能很贵？
因为不参与当前 token 计算不意味着权重不存在。大量专家权重仍需存储、分片、加载和调度。
Shared Expert 在解决什么问题？
把广泛共享的通用模式集中给共享专家承担，减少 routed experts 重复学习相同知识。
Loss-Free Balancing 为什么有吸引力？
传统 balance auxiliary loss 会额外产生梯度。Loss-Free 方法根据近期负载动态调整专家 routing bias，尽量将负载控制与主任务梯度解耦。
为什么理论 FLOPs 低，实际速度却不一定同比提高？
真实系统还要支付 token routing、All-to-All 通信、内存带宽、同步等待、负载不均衡和非 MoE 模块计算等成本。
参考资料与继续阅读
优先放论文与官方模型页面。视频适合建立直觉，论文/官方报告负责校准细节。