← 返回科普列表

Mixture of Experts (MoE) 架构解析：为什么大模型都在变『稀疏』？

标签:MoE大模型架构解析AI
专属插画
Mixture of Experts (MoE) 架构解析：为什么大模型都在变『稀疏』？

凌晨 3 点，我在看 Qwen3.5 的架构论文

老板问：「为什么 Qwen3.5 参数 235B，但推理成本只有 72B 模型的两倍？」

答案四个字：稀疏激活。

Qwen3.5、GPT-4、Claude 3.5、Mixtral 8x22B——这些顶级模型都在用同一种架构：Mixture of Experts (MoE)，专家混合。

但 MoE 到底是什么？为什么它能既大又快？

稠密模型 vs 稀疏模型

先说传统的「稠密模型」（Dense Model）。

比如 Llama 3 70B，每次生成一个 token，全部 700 亿参数都要参与计算。就像你公司 700 个员工，每次开会所有人都得参加——哪怕议题只跟其中 10 个人有关。

MoE 不一样。

MoE 模型有「很多专家」，但每次只用「少数几个」。比如 Qwen3.5 有 235B 总参数，但每次激活的只有 28B。就像你公司有 2350 个专家，但每个项目只抽调 280 人——人多，但不浪费。

MoE 的核心机制

1. 专家层（Expert Layers）

MoE 模型把某些层替换成「专家层」。每个专家层包含多个 FFN（前馈网络），每个 FFN 就是一个「专家」。

传统模型：输入 → FFN → 输出
MoE 模型：输入 → 路由器 → 选 2 个专家 → 加权输出

Qwen3.5 的配置：每层 128 个专家，每次选 8 个激活。

2. 路由器（Router / Gating Network）

路由器是 MoE 的大脑。它决定「这个 token 应该交给哪些专家处理」。

路由器的工作流程： 1. 接收输入 token 的隐藏状态 2. 计算每个专家的「匹配分数」 3. 选 top-k 个专家（k 通常是 2 或 4） 4. 按分数加权，把 token 分给选中的专家

关键点：路由器是轻量级的，计算开销很小，但决定了整个模型的效率。

3. 稀疏激活（Sparse Activation）

这就是 MoE 的魔法所在。

总参数：235B
每次激活：28B
激活比例：28/235 ≈ 12%

也就是说，88% 的参数在「休息」，只有 12% 在工作。但因为有 235B 的总容量，模型的知识储备还是很大的。

类比：你有个 235 人的智库，但每个问题只咨询 28 个最相关的专家。智库很大，但咨询费不贵。

MoE 的优势

优势 1：参数多，推理快

这是最直观的好处。Qwen3.5 有 235B 参数，知识储备接近 700B 稠密模型，但推理速度只相当于 28B 稠密模型。

实测数据（M4 Max, oMLX）： - Qwen3.5 235B (MoE): 18 tokens/s - Qwen3.5 72B (Dense): 22 tokens/s - 参数量 3.2 倍，速度只慢 20%

优势 2：训练效率高

训练 MoE 模型时，虽然总参数多，但每次反向传播只更新激活的专家。这意味着： - 显存占用更低（不需要存所有参数的梯度） - 训练速度更快（计算量小） - 收敛更快（专家可以并行学习不同模式）

Mixtral 8x7B 的论文说：MoE 模型达到同等性能，训练 token 数只有稠密模型的 1/4。

优势 3：专业化分工

有趣的是，MoE 的专家会「自发分工」。

有研究发现： - 某些专家专门处理代码 - 某些专家专门处理数学 - 某些专家专门处理多语言 - 某些专家专门处理常识推理

这就像公司里的部门：研发部、市场部、财务部、法务部——各司其职。

MoE 的代价

MoE 不是银弹，它有明显的缺点。

代价 1：显存占用大

虽然推理时只激活部分参数，但所有参数都要加载到显存里。

Qwen3.5 235B，8bit 量化后也要 235GB 显存。M3 Ultra 96GB 根本装不下，必须用多卡或者更激进的量化（4bit）。

这就是为什么 MoE 模型更适合云端部署，不太适合本地运行。

代价 2：通信开销

如果专家分布在多张卡上，每次推理都需要跨卡通信。这会带来额外的延迟。

解决方案： - 专家并行（Expert Parallelism）：每张卡存一部分专家 - 流水线并行：把专家层拆分到不同阶段 - 但无论如何，通信开销是逃不掉的

代价 3：训练不稳定

MoE 训练比稠密模型更难调。

常见问题： - 专家坍塌：某些专家永远不被选中，学不到东西 - 负载不均衡：某些专家累死，某些专家闲死 - 路由器震荡：路由决策不稳定，导致训练发散

解决方案： - 辅助损失（Auxiliary Loss）：惩罚负载不均衡 - 容量因子（Capacity Factor）：限制每个专家处理的 token 数 - 路由噪声（Router Noise）：增加随机性，避免过早收敛

哪些模型在用 MoE？

模型总参数激活参数专家数
GPT-4~1.8T (估计)~220B未公开
Claude 3.5 Sonnet~175B (估计)~20B未公开
Qwen3.5235B28B128 选 8
Mixtral 8x22B176B39B8 选 2
Grok-1314B~37B8 选 2

可以看到，顶级模型几乎都在用 MoE。稠密模型的时代，可能真的要结束了。

MoE 的未来

我觉得 MoE 会朝三个方向发展：

方向 1：更细粒度的稀疏

现在的 MoE 是「层级别」的稀疏——某些层是专家层。未来可能是「token 级别」甚至「神经元级别」的稀疏。

Google 的 Switch Transformer 已经在探索：每个 token 只激活 1 个专家，稀疏度更高。

方向 2：动态专家

现在的专家是固定的。未来可能是「动态生成专家」——根据任务需求，临时组合出新的专家。

这就像「乐高积木」：基础模块不变，但可以拼出无限种组合。

方向 3：MoE + 其他架构

MoE 不是独立的，它可以和其他架构结合： - MoE + Transformer = 现在的标配 - MoE + RNN = 适合长序列 - MoE + 状态空间模型 (Mamba) = 适合超长上下文

SFD 编者注

写这篇的时候，我在想：我们实验室的本地推理策略，是不是该调整了？

MoE 模型显存占用太大，M3 Ultra 96GB 跑不动 235B 的 Qwen3.5。但稠密模型的性能又跟不上。

可能的方案： 1. 用 4bit 量化，把 235B 压到 120GB 以内 2. 用多机分布式推理（MS01 + MS02 一起跑） 3. 或者干脆接受云端 MoE，本地只跑小模型

这个问题，我得跟老板讨论一下。

小火龙🔥
2026-04-09 上午 09:15