【AI工程师精讲】06：MoE：为什么"万亿参数"的模型，实际只用了很小一部分

有些模型的参数标注方式很特别：总参数 6710 亿，激活参数 370 亿。

第一次看到这个写法，多数人有两个疑问：

为什么要写两个数？
既然只激活 370 亿，那是不是意味着它只消耗一个 370 亿参数模型的算力？

第二个问题的答案需要拆成两半：

算力上确实接近，但显存上完全不是。

这个区别，直接决定了你那张卡能不能跑得起来。 而且它也是关于 MoE 最常见、代价最大的一个误解。

MoE，全称混合专家（Mixture of Experts），是目前扩大模型容量最主流的结构性手段。这篇文章讲清它的机制、它真正的代价，以及选型时怎么判断。

第一部分：结构------把一层网络拆成很多个"专家"

1.1 标准 Transformer 的做法

在标准 Transformer 里，每一层有个前馈网络（FFN），负责对每个 token 做一次非线性变换。

可以理解成：所有 token 都走同一条通道。

1.2 MoE 的做法

MoE 把这条通道拆成若干条并行的通道，每条叫一个"专家"（expert） 。然后加一个门控网络（router），它的任务是为每个 token 决定"该走哪几条通道"。

具体流程：

text 复制代码

① 一个 token 进来，门控网络算出它属于各个专家的"匹配分数"
② 取分数最高的前 k 个（比如 top-2）
③ 只让这 k 个专家处理这个 token
④ 把它们的输出按门控权重加权求和，作为最终结果

所以关键在于：每个 token 只走了模型中很小一部分的专家。

这就是"稀疏激活"：

参数是稠密的（都在那里），激活是稀疏的（每次只用一小部分）。

1.3 "专家"到底意味着什么

这里有一点值得澄清："专家"这个词有误导性。

它容易让人以为"每个专家负责一个领域"------比如有的专家管数学，有的管法律。

实际训练出来的路由分布通常不是这么规整的 。专家之间的分工往往是细粒度、难以人工解读的，更像是"从不同角度做特征变换"。

理解这一点很重要 ：它意味着你不能指望"加一个专家就能让它学会某个新领域"。MoE 带来的主要是"容量"，而不是"可插拔的专门能力"。

第二部分：稀疏激活究竟省了什么，又没省什么

这是全文最重要的一节。

2.1 省的是计算量

前向传播只需要计算被选中的那几个专家。

所以一个总参数 600B、激活 40B 的模型，每个 token 的计算量接近一个 40B 稠密模型。

这就是"参数量不等于计算量"这个说法的由来。

2.2 没省的是显存

原因在于：门控网络是动态选专家的------你无法提前知道这次请求会用到哪些专家。

后果很直接：

所有专家都必须装进显存（或至少能被快速调到）。

所以显存占用按总参数计算，不是按激活参数。

2.3 一张必须记住的对照表

对比项	稠密模型	MoE 模型
单 token 计算量	按全部参数	只按激活参数
显存占用	按参数总量	仍按参数总量
单卡能否装下	看参数量	看总参数，不是激活参数
吞吐（大 batch）	正常	通常更好（专家被充分利用）
吞吐（小 batch）	正常	可能变差（专家利用率低）

2.4 一句话概括它的本质

MoE 是"用显存换算力效率"。

由此直接推出两条判断：

如果你的瓶颈是显存不够 → MoE 帮不上你，反而更糟；
如果你的瓶颈是"算力不够但显存富裕" → MoE 就是好选择。

这个判断框架，能过滤掉大部分选型误判。

第三部分：代价一------负载均衡，比想象中难

3.1 一个自强化的问题

门控网络是学出来的，于是产生了一个自强化循环：

text 复制代码

某个专家在训练早期稍微强一点
  → 吸引更多 token
  → 被选择越多，它学得越好
  → 它越好，又被选择越多

3.2 两类后果

后果	表现	危害
专家被"饿死"	几乎不被选中	等于白白占用显存
专家过载	被过度选中	训练不稳定、容量浪费

注意第一类的讽刺之处 ：你为了让模型容量更大而增加了专家，结果一部分专家从来不被使用------参数量是虚的。

3.3 常见对策与它们的边界

负载均衡的辅助损失：惩罚不均衡的路由分布；
路由时施加容量限制：每个专家最多接收多少 token；
无辅助损失的均衡策略：从路由机制本身入手（如基于偏置项调整）。

但这些都是"减小问题"，不是"消除问题"。

3.4 工程上的实际表现

MoE 模型对训练细节更敏感；
不同批次之间的专家利用率波动更大；
训练调参经验比稠密模型更稀缺（因为做的人少、问题更隐蔽）。

这条代价通常不会体现在"模型能力"上，但会体现在"你能不能训出一个好模型"上。

第四部分：代价二------通信开销

4.1 问题从哪来

MoE 有一个稠密模型不存在的成本：

专家通常分布在不同的设备上。

流程是这样的：

text 复制代码

一个 token 被路由到某个专家
  → 那个专家在另一张卡上
  → 数据必须跨设备搬运过去
  → 算完再搬回来

这个操作常被称为 all-to-all 通信 ，而且在每一层、每一批次都要发生。

4.2 后果：性能对网络拓扑高度敏感

部署形态	通信代价
单机多卡（NVLink 等高带宽互联）	可接受
跨节点（以太网 / InfiniBand）	明显受限

这就解释了一个实践现象：

同样的 MoE 模型，在不同部署环境下性能差异可能很大------不是模型的问题，是通信的问题。

4.3 一个常被忽略的推论

MoE 的吞吐不是只由 GPU 数量决定的，还由"卡之间怎么连"决定。

所以在做容量规划时，网络拓扑是一个必须提前确认的约束。如果只有普通的跨节点互联，MoE 的很多理论收益根本兑现不了。

第五部分：代价三------小批量时效率反而低

这是最容易被忽略、也最容易踩坑的一点。

5.1 收益的前提是"专家被填满"

MoE 的算力收益，前提是每个专家的矩阵乘法都有足够的 token 参与。

并发请求多 → 每个专家都收到足够多的 token → 矩阵乘法效率高 → 收益拉满；
单请求、低并发 → 每个 token 只激活两三个专家 → 矩阵乘得很小 → GPU 算力利用率很低。

5.2 结果可能比稠密模型还慢

具体来说，低并发场景下 MoE 面临三重不利：

矩阵乘太小：算力用不满；
路由开销照付：门控计算、排序、分发都要做；
通信开销照付：即使专家在同一张卡上，也有额外的调度成本。

所以：MoE 天然适合"高吞吐服务端"，不适合"低并发个人使用"。

5.3 这条结论对选型非常关键

场景	判断
高并发 API 服务	MoE 有优势
本地单机跑	稠密模型更合适
批处理离线任务	MoE 有优势（可以攒大批）
实时单请求交互	需实测，可能不如稠密

如果你是在本地跑一个 MoE 模型问问题，然后觉得"怎么比同规模稠密模型还慢"------那不是模型的问题，是场景不匹配。

第六部分：为什么 MoE 在最近两年变得重要

既然有这么多代价，为什么大家还在做？

因为有三件事同时变了。

6.1 第一，容量比参数更值钱

实验表明，在同等计算预算下，增加参数量（而不是训练更多 token）能带来更好的效果。

MoE 让你"参数很多但计算不变"，正好对上这个需求。

6.2 第二，推理从"单用户"变成了"服务化"

当模型以高并发 API 形式提供时，MoE 的专家利用率问题被批处理掩盖了，收益被放大。

这是一个非常关键的转变：MoE 的缺点（小批量效率低）在服务端根本不出现，而它的优点（大容量 + 低算力）被充分发挥。

6.3 第三，通信与显存技术同步进步

高带宽互联（NVLink、更快的跨节点网络）；
大显存卡（能装下总参数）；
更成熟的专家并行实现（框架层面的支持）。

这些把 MoE 的工程门槛降下来了。

6.4 一句话总结

MoE 不是新技术，是"环境成熟之后才真正划算的技术"。

它的原理十多年前就有了。真正让它变主流的，是部署形态和硬件条件的改变。

第七部分：选型判断标准

7.1 优先选 MoE 的情况

条件	为什么
多卡，且卡间互联好	这是 MoE 发挥收益的物理前提
服务形态是高并发	批处理能填满专家，算力效率优势才兑现
显存不是瓶颈、算力是瓶颈	MoE 正是治这个病
要的是"更大的知识容量"，而非"更强的单步推理"	容量是 MoE 的直接收益

7.2 优先选稠密的情况

条件	为什么
单卡或低并发	专家利用率低，MoE 反而更慢
显存紧张	MoE 的显存按总参数算，装不下就是装不下
要端侧部署或本地运行	稠密小模型更合适
追求部署简单	MoE 的并行、调度、通信都是额外复杂度
需要稳定的推理延迟	MoE 的路由动态性会让延迟分布更分散

7.3 一个务实的经验

如果团队里没有人熟悉专家并行和通信调优，先别碰 MoE 自建------用 API 或者选稠密模型。

这条建议的价值在于承认"能力边界"。MoE 的工程门槛真实存在，而踩坑的成本（时间、算力、反复调优）往往远高于省下的推理成本。

第八部分：成本测算时容易漏掉的三个变量

MoE 模型的"激活参数量"能用来估算成本吗？能，但只能估算其中一部分。

8.1 三个变量

① 显存成本按总参数算。

这是最容易犯的错误。按激活参数买卡，会直接跑不起来。

text 复制代码

显存需求 ≈ 总参数 × 每参数字节数 + KV Cache + 框架开销
          ↑
          注意是总参数，不是激活参数

② 通信成本不体现在激活参数里。

激活参数只反映"算了多少"，不反映"搬了多少"。而 MoE 的通信量与总参数量、专家分布方式直接相关。

③ 低并发时有效利用率低于理论值。

理论上"激活 40B 就等于 40B 的算力"，但实际利用率取决于批大小。低并发时可能只能发挥出理论值的一半甚至更低。

8.2 一个实用的测算框架

text 复制代码

第 1 步：显存 = 总参数 × 字节数 + 并发数 × 单请求 KV Cache + 开销
第 2 步：算力成本 ≈ 激活参数 × token 数 × 单位算力价格 ÷ 实际利用率
第 3 步：通信成本 → 需要实测（取决于网络拓扑与专家分布）
第 4 步：把三项加起来，再和稠密方案对比

关键结论是：MoE 的真实成本必须实测，不能只看参数标注。

而且测的时候要测两种负载：低并发和高并发。因为两者的表现可能完全相反。

常见误区

误区一："总参数 600B、激活 40B，那我按 40B 的显存准备就行。"

这是最常见的致命误解。

所有专家都要驻留，显存按总参数准备。 按激活参数量买卡，会直接跑不起来。

而且这个错误在采购阶段代价最大------卡买了才发现装不下，或者只能装下但无法留出 KV Cache 空间。

误区二："MoE 一定比稠密模型强。"

要看比较的前提。

同等算力预算下：MoE 往往能带来更好的效果（因为容量更大）；
同等显存条件下：稠密模型可能更有优势。

"比较的前提要对齐"这一条，在技术选型里永远成立。

误区三："MoE 只是训练技巧，推理没影响。"

恰恰相反。

MoE 的收益主要在推理侧兑现 （高并发时的算力效率），而它的代价（通信、调度、小批量效率）也主要在推理侧暴露。

误区四："MoE 模型更好微调，因为只训练部分专家。"

实际常常相反。

微调时路由分布会发生变化 ，容易出现专家负载进一步失衡。微调 MoE 通常比微调同规模稠密模型更需要经验。

具体要注意三件事：

监控专家利用率（微调后分布可能更失衡）；
从小学习率、小 rank 开始（路由对参数变化更敏感）；
评测时看延迟分布，不能只看平均延迟。

第三条常被忽略，但线上体验往往由长尾决定。

误区五："专家的分工是清晰可解释的。"

实际训练出来的路由分布通常难以人工解读。

这意味着两件事：

你不能靠"加专家"来定向增强某个领域的能力；
专家利用率图表不能直接当作"模型在学什么"的解读依据。

误区六："MoE 是新技术，所以还不成熟。"

它的原理很早就有。真正让它变主流的是部署形态和硬件条件的改变------服务化、高并发、高带宽互联。

所以判断它是否成熟，要看的是"你的环境是否匹配"，而不是"它出现了多久"。

实战问答

Q1：面试问"MoE 省显存吗"，怎么答？

A：直接给判断：

不省显存，省算力。

理由：

所有专家都必须可被路由到，因此都要驻留显存；
每个 token 只走少数几个专家，所以计算量按激活参数算。

再补一句工程含义：

"MoE 是拿显存换算力效率"------这决定了它适合多卡高并发服务，不适合显存紧张或单卡场景。

这个"给判断 + 说理由 + 讲推论"的结构，比只答"省算力不省显存"更有层次。

Q2：为什么我本地跑 MoE 模型，感觉比同规模的稠密模型还慢？

A ：因为你是低并发。

具体来说，你面临三重不利：

每个 token 只激活两三个专家，矩阵乘规模很小，GPU 算力用不满；
路由开销照付（门控计算、排序）；
额外的调度与通信成本。

MoE 的优势要靠批处理来兑现。 在单请求场景下，你付出了 MoE 的所有代价，却拿不到它的收益。

Q3：MoE 模型的"激活参数量"能用来估算成本吗？

A ：用来估算算力成本大体合理，但要注意三件事：

变量	说明
① 显存成本按总参数算	不是激活参数
② 通信成本不体现在激活参数里	取决于网络拓扑与专家分布
③ 低并发时有效利用率低于理论值	可能只有理论的一半甚至更低

所以真实成本要实测，不能只看标注。

建议的实测方式：用你的真实负载（真实的并发数、真实的长短分布）跑一遍，记录吞吐、延迟分布和各阶段耗时。

Q4：微调 MoE 模型有什么特别要注意的？

A：三件事。

① 监控专家利用率 ------微调后路由分布可能更失衡。如果发现某些专家完全不被激活，说明容量在浪费。

② 从小学习率、小 rank 开始 ------路由对参数变化比稠密层更敏感，大的改动可能把原本均衡的路由分布打乱。

③ 评测时要看延迟分布，不能只看平均延迟。

第三点最容易被忽略，但线上体验往往由长尾决定：平均延迟 200ms 但 P99 达到 5s 的系统，用户体验是"会卡"。

Q5：什么情况下应该放弃 MoE 改用稠密模型？

A：出现下面任一情况就该重新考虑：

信号	说明
显存装不下总参数	最硬的门槛，绕不过去
并发上不去（低频或单条使用）	专家填不满，收益兑现不了
跨节点通信成为瓶颈	通信开销吃掉了算力收益
团队没有并行调优经验	踩坑成本高于省下的成本
对延迟稳定性要求高	路由动态性带来延迟波动

一个实操建议 ：先做一次小规模压测------用真实负载在目标硬件上跑一遍，看吞吐和延迟分布。

很多"该不该用 MoE"的问题，压测一次就有答案，比反复讨论高效得多。

Q6：MoE 的专家数量是越多越好吗？

A：不是，存在几个明确的边界。

增加专家的收益	增加专家的代价
总容量变大	显存线性增长
稀疏度提高，单 token 算力占比更小	通信开销变大（专家分布更散）
理论上表达更丰富	负载均衡更难（更容易出现饿死）

实践上存在一个"性价比区间" ，而且这个区间强烈依赖你的硬件条件（特别是卡间带宽）和负载形态（并发数）。

判断方法：不是看"专家数多少"，而是看**"每个专家平均被激活的频率"**。如果有些专家长期不被激活，那就是多了。

术语表

术语	含义
MoE（混合专家）	把前馈层拆成多个并行专家，每 token 只激活其中一部分的结构
门控网络（Router）	为每个 token 选择专家的可学习模块
稀疏激活	每次前向只用一部分参数，参数量与计算量解耦
总参数 / 激活参数	前者决定显存，后者决定单 token 计算量
负载均衡	让各专家被使用的频率尽量均匀，避免饿死与过载
专家并行	把不同专家放在不同设备上，代价是跨设备通信
All-to-All 通信	MoE 中把 token 按路由结果分发、再收回结果的通信模式
专家利用率	各专家实际被激活的频率分布，是判断 MoE 是否健康的核心指标

结语

把这篇压缩成三句话：

第一，MoE 用"稀疏激活"把参数量和计算量拆开了：省算力、不省显存。 这一条是选型的第一道门------显存按总参数算，按激活参数买卡会直接跑不起来。

第二，它还额外付出两类代价 ：负载均衡难（专家可能被饿死）、通信开销大（专家分布在不同设备上）。这两类代价不会体现在模型能力上，但会体现在"你能不能部署好"上。

第三，它真正的适用条件是：显存富裕、算力紧张、多卡互联好、高并发服务。 缺任何一条，收益都可能兑现不了。

所以 MoE 不是"更先进的架构"，而是"特定条件下划算的选择"。

而如果只允许带走一个判断，那就是：问自己"我的瓶颈是显存还是算力" ------ 答案在显存，选稠密；答案在算力且显存富裕，才考虑 MoE。

顺着架构这条线，还有一个更基础、也更直接决定成本的话题：从 MHA 到 MQA、GQA 再到 MLA------注意力结构到底在优化什么？ 搞清这条线，你就能看懂几乎所有现代模型的推理成本差异。