MoE 混合专家架构：400B 参数的模型，为什么只用 17B 的成本？

400 亿。

这是 Meta Llama 4 Maverick 的总参数量——4000 亿个参数。但你猜，它每次处理一个 token 时实际激活了多少？

170 亿。不到总量的 5%。

这意味着什么？你用的是一个"知道 4000 亿件事"的模型，但它每次思考只动用 170 亿个脑细胞。它的性能跟 GPT-4o 打得有来有回，但推理成本只有 GPT-4o 的几分之一。

这不是什么黑科技，也不是偷工减料。这是一种叫做 MoE（Mixture of Experts，混合专家）的架构。2026 年最重要的大模型——Llama 4、DeepSeek V3、Qwen 3.5——全部采用了它。

如果你还在用"参数量越大模型越强"的旧认知理解大模型，这篇文章会帮你更新这个观念。

---

为什么"全员上岗"是一种浪费？

要理解 MoE 解决了什么问题，我们先看看它之前的架构——Dense（稠密）模型——是怎么工作的。

在 Dense 模型里（比如最初的 GPT-3、GPT-4），每一个 token 进来后，会经过模型的每一层、每一个神经元。不管这个 token 是"量子力学"还是"今天吃什么"，全部参数都得跑一遍。

打个比方：这就像一家公司开全体大会。不管讨论的是财务报告还是食堂菜单，从 CEO 到保安全部到场。每个人都得坐在那里"参与"。

问题来了——你觉得这合理吗？

显然不合理。大部分人在大部分会议里都是"陪坐"。但他们占着工位（GPU 内存），消耗着算力（计算资源），实际贡献几乎为零。

这就是 Dense 模型的核心矛盾：你想让模型"知道得更多"，就得加参数。参数一加，所有 token 的计算成本都跟着涨。即使 99% 的参数对当前 token 没什么帮助。

所以行业开始思考一个问题：能不能让模型"知道得多"，但每次只用"相关的那部分"？

这就是 MoE 的出发点。

不是所有神经元都需要上班。让该干活的干活，该休息的休息——这才是高效组织。

---

MoE 的核心魔法：路由器怎么分诊？

MoE 的原理其实只有一句话：把一个大的 FFN 层拆成 N 个小的"专家"，每次只激活其中 K 个。

但关键不在专家本身，而在——谁来决定激活哪些专家？

答案是一个叫 Router（路由器），也叫 Gating Network（门控网络）的小模块。

想象一家大型医院的前台分诊。你走进急诊大厅，前台护士不会把你同时送去骨科、眼科、心内科，而是根据你的症状，快速判断你该去哪个科室。

MoE 的 Router 干的就是这件事。

具体来说，Router 的工作分三步：

第一步，打分。对每个 token，Router 计算它和所有专家之间的"亲和度分数"（affinity score）。本质上就是一个矩阵乘法加 softmax——把 token 的向量和每个专家的"特征向量"做点积，得到一组概率。

第二步，选人。从所有专家中挑出分数最高的 K 个。这就是 Top-K 路由。K=1 就是只选一个专家（Switch Transformer 的做法），K=2 就是选两个（Mixtral 的做法），K=8 就是选八个（DeepSeek V3 的做法）。

第三步，加权输出。被选中的 K 个专家各自处理 token，然后按 Router 给出的概率权重加权求和，得到最终输出。

看一段伪代码，比文字更直观：

# MoE 前向传播核心逻辑
def moe_forward(token, experts, router, top_k=2):
    # 1. Router 给所有专家打分
    scores = softmax(router(token))  # shape: [num_experts]

    # 2. 选出 Top-K 个专家
    top_indices = top_k_select(scores, k=top_k)
    top_weights = scores[top_indices]

    # 3. 只让选中的专家干活，加权求和
    output = sum(w * experts[i](token)
                 for i, w in zip(top_indices, top_weights))
    return output

关键在第 6 行：top_k_select。没被选中的专家？它们对这个 token 来说根本不存在。不计算，不消耗，不费电。

但这里就引出了一个关键问题：Router 怎么知道该选谁？如果它每次都选同一批专家，那其他专家不就成了摆设？

MoE 的灵魂不在专家，在 Router。路由选得好，四两拨千斤；路由选得烂，千亿参数也是摆设。

---

2026 年的 MoE 实战：三大模型解剖

理论讲完了，我们来看看 2026 年三款最重要的 MoE 模型到底是怎么设计的。你会发现，同样是 MoE，细节差异巨大。

模型	总参数	激活参数	专家数	每 token 激活	上下文窗口
Llama 4 Scout	109B	17B	16	1 路由 + 1 共享	1000 万
Llama 4 Maverick	400B	17B	128	1 路由 + 1 共享	100 万
DeepSeek V3	671B	37B	256	8 路由 + 1 共享	128K

几个有意思的发现：

Llama 4：用 128 个专家，但只激活 1 个

Maverick 是 Meta 第一次做 MoE。他们选了一个相当激进的策略：128 个专家里只激活 1 个，再加上一个"共享专家"（对所有 token 都激活的通用专家）。

这意味着每个 token 只走两条路：一条固定路（共享专家），一条动态路（Router 选出的 1 个专家）。极致稀疏。

更有趣的是，Maverick 不是每一层都用 MoE。它的 MoE 层和 Dense 层是交替排列的——一半的层用 MoE，一半还是传统 Dense。这像是 Meta 给自己留了条后路：不全赌 MoE，掺着来。

DeepSeek V3：256 个专家，激活 8 个

DeepSeek 的玩法更"重"。256 个路由专家里选 8 个，加上 1 个共享专家，每次总共 9 个专家在干活。

但 DeepSeek 最大的贡献不在数量，而在它解决了一个困扰 MoE 领域多年的难题——负载均衡。这个我们下一节细聊。

这里有一段关于 MoE 的历史花絮值得一提。混合专家这个概念其实不新——它最早由 Michael Jordan（不是打篮球那个）和 Robert Jacobs 在 1991 年提出。但三十多年来它一直是个"好想法但没法落地"的东西。直到 2017 年 Google 的 Shazeer 等人把它和 Transformer 结合，发表了 Sparsely-Gated MoE 论文，MoE 才真正找到了它的舞台。从学术论文到 Llama 4，这条路走了 35 年。

数字会说话：同样的激活参数，MoE 能调动数倍的总知识量。这不是魔法，这是架构的胜利。

---

训练 MoE 的暗礁：专家坍缩问题

如果 MoE 这么好，为什么不是所有模型都用它？

因为训练 MoE 有一个极其凶险的暗礁：专家坍缩（Expert Collapse）。

想象一个美食城，里面有 128 个摊位。刚开业时，顾客随机分散。但很快，有几家摊位因为味道好、位置好，开始排长队。排长队意味着更多营收、更多优化投入、味道更好、队更长……

而那些冷门摊位呢？没客人→没反馈→厨师手艺退步→更没客人。

最后的结局：128 个摊位里只有 10 个在运转，其余 118 个名存实亡。

这就是 MoE 的专家坍缩。在训练过程中，Router 会倾向于把 token 越来越集中地发给少数几个"热门"专家。这些专家因为获得了更多训练数据，表现越来越好，进一步吸引更多 token——形成马太效应。

更糟糕的是：一旦坍缩发生，几乎不可逆。那些被冷落的专家权重要么停留在初始值，要么随机漂移，Router 学会了回避它们，它们永远没有翻身的机会。

业界怎么解决？

传统方案：辅助损失（Auxiliary Loss）。在训练损失函数里额外加一项，惩罚"负载不均衡"。简单说就是：如果某些专家太忙而另一些太闲，就扣分。

但这个方案有个致命的副作用——辅助损失的系数（α）很难调。设大了，模型为了"负载均衡"牺牲了学习效果，相当于为了让每个摊位都有客人，强制给差摊位引流；设小了，坍缩照样发生。

DeepSeek V3 的突破：无辅助损失负载均衡。这是 DeepSeek V3 最重要的技术贡献。它完全抛弃了辅助损失，转而用一个极其简洁的机制：给每个专家一个动态偏置项（bias）。

训练时，每一步结束后检查各专家的负载情况：

• 某个专家太忙？把它的 bias 减小 γ，让 Router 下次少选它一点
• 某个专家太闲？把它的 bias 增大 γ，让 Router 下次多选它一点

这个 bias 只影响路由决策，不影响专家的实际权重。相当于在分诊台上调整排队指示牌，而不是干预医生的治疗方案。

效果怎么样？DeepSeek V3 在整个训练过程中实现了良好的负载均衡，没有丢弃任何一个 token。在推理部署时也是零丢弃。

让每个专家都有活干，比训练模型本身更难。MoE 的工程挑战，一半藏在"路由"二字里。

---

MoE vs Dense：到底该选谁？

看到这里，你可能觉得 MoE 全是优点。但如果真是这样，Dense 模型早就该消失了。

现实是：Claude Opus 4.6、GPT-5.4 的核心版本仍然是 Dense 架构。

这说明 MoE 并不是银弹。我们来做一个诚实的对比。

MoE 的优势

1. 推理效率碾压。同等智力水平下，MoE 的推理速度更快、成本更低。Llama 4 Maverick 400B 总参数，但推理时只跑 17B，速度接近一个小模型。

2. 训练效率更高。研究表明，MoE 模型的预训练速度比同等能力的 Dense 模型快 2-4 倍。因为每个 token 只需要计算一小部分参数的梯度。

3. 知识容量大。总参数量决定了模型能存储多少"知识"。MoE 允许你在不增加推理成本的前提下，给模型"塞"更多知识。

MoE 的劣势

1. 显存占用巨大。这是 MoE 最大的痛点。Maverick 虽然只激活 17B 参数，但你需要把全部 400B 参数加载到显存里。激活参数像"工资单上的人数"，总参数像"办公室的工位数"——你得为所有人准备工位，即使大部分人在远程办公。

2. 微调困难。Dense 模型微调是一个成熟的流程，LoRA 等技术直接适用。但 MoE 的微调更复杂——你要不要冻结 Router？要不要让所有专家都参与微调？这些问题目前还没有标准答案。

3. 通信开销。在多 GPU 部署时，MoE 的 All-to-All 通信（把 token 发给分布在不同 GPU 上的专家，再收集结果）会成为瓶颈。计算省了，但通信可能吃回去。

那到底怎么选？我的建议很简单：

• API 服务、高并发场景：选 MoE，成本优势巨大
• 本地部署、资源有限：选 Dense 小模型，显存友好
• 需要频繁微调：目前 Dense 模型的微调生态更成熟
• 追求极致能力上限：看具体 benchmark，不要被总参数量迷惑

MoE 是答案，但不是唯一的答案。选架构跟选工具一样——没有最好的，只有最合适的。

---

总结与挑战

MoE 的核心洞察可以浓缩成一句话：让模型"知道得多"和"想得快"不再是一道二选一题。

从 1991 年 Michael Jordan 的论文到 2026 年 Llama 4 Maverick 的 128 个专家，MoE 花了 35 年从理论走进了每一个开发者的 API 调用里。它不是什么高深的数学魔法——拆开来看，不过是"分工"和"路由"两个朴素的概念。

但正是这两个概念，让大模型的成本曲线第一次出现了"参数涨、成本不涨"的拐点。

今天回去试一件事：

打开你常用的 AI API 平台，对比一下同等智力水平的 MoE 模型和 Dense 模型的价格。算一笔账：如果你的应用日均处理 100 万个 token，两种架构的月成本差多少？

如果差距让你吃惊——恭喜，你刚刚理解了为什么 2026 年的 AI 行业在集体"转 MoE"。

如果差距不大——记录下是哪两个模型，因为这意味着 Dense 模型在该能力区间仍有竞争力，而这个边界本身就很有价值。

参数量的军备竞赛正在结束。下一轮竞争的焦点，不是谁的模型更大，而是谁的模型更"聪明地偷懒"。