算法工程 · MoE / Sparse Activation

MoE：大模型为什么能“总参很大，每次只算一小块”

Mixture of Experts（混合专家）不是把多个完整模型简单拼起来；在主流稀疏 Transformer MoE 中，它通常把部分 FFN 子层替换为“router + 多个专家”。每个 token 只运行少数专家，因此总参数可远大于单 token 激活参数；但实际 FLOPs、延迟和显存还包含 attention、共享层、router、通信与全部已部署专家权重。

MoE 总览：tokens 进入 router，被分配给少数 experts，再合并回 token 输出 — 一图看懂：MoE 的核心是稀疏激活。Router 给每个 token 选少数专家，不同 token 可走不同路径。若专家按 expert parallel 分片且目标专家在别的 rank，assignment 通常通过 all-to-all dispatch/combine；专家本地或有复制时则可少走跨卡路径。查看大图 ↗

00 · 先抓住

MoE 是“专家很多，但每次只请几个上场”

生活类比

一家医院有心内科、骨科、儿科、影像科。病人进来先分诊，不会每个科室都看一遍。MoE 也是这样：模型总专家很多，但每个 token 只被路由到少数专家。

小例子

一句“写 Python 函数解释牛顿法”里，不同 token 可能被送往不同专家。Router 不是给整句话贴标签，而是按每层当前 hidden state 给每个 token 选计算路径。这里的“代码/中文/数学专家”只是便于理解的类比；真实专家通常没有人工命名，分工也未必可直接解释。

最重要的区分	总参数代表医院拥有的医生规模；激活参数近似代表一次诊疗经过哪些医生，但不等于实测工时/FLOPs。
为什么难	分诊台如果总把病人送到一个专家，热门专家会排队，冷门专家浪费，训练和通信都会出问题。
工程关键	MoE 省 FFN 计算，但新增 router、dispatch、all-to-all 和专家负载均衡。

01 · 为什么 MoE

Dense FFN 复用同一套权重，MoE 则按 token 点名专家

在常见 Transformer block 里，attention 混合 token 间信息，FFN 对各位置独立做通道变换；在许多 LLM 配置中 FFN 占参数大头。主流 sparse MoE 的做法是：在部分层用多个 FFN 专家替代单个 dense FFN，每个 token 只激活其中 k 个（有些模型另有常开的 shared expert）。

Dense

稠密 FFN

Every token uses the same weights

\mathrm{FFN}(x)=W_2\,\sigma(W_1x)

每个 token 都经过同一套 FFN。上式是两层 MLP 的简化写法；现代 LLM 常用带门控的 SwiGLU/GeGLU，但“所有 token 复用同一组 FFN 权重”这一点不变。优点是简单、稳定、硬件友好；缺点是 FFN 变宽时，每个 token 都要付这套 FFN 的计算账。

MoE

稀疏专家 FFN

Each token uses a few experts

\mathrm{MoE}(x)=\sum_{i\in\mathrm{TopK}(g(x))} p_i(x)\,E_i(x)

Router 先看 token 表示，再选 Top-k 专家。只运行被选中的专家，把结果按权重合并。

一句话直觉

Dense 像一个全科医生每个病人都看；MoE 像分诊台把病人送去少数专科医生。医院总专家很多，但每个病人只占用几个专家的时间。

MoE 想换来什么	收益	代价
容量变大	更多专家参数提高条件化表示容量，但不自动转化为更强能力。	权重总量仍要存，部署时不一定省显存。
每 token 计算变少	相对“运行全部专家”的同总参 dense/全激活设计，只跑 Top-k 专家会减少专家 FFN FLOPs。	Attention/共享部分不随专家数等比例下降，router、dispatch、combine 和通信也会吃掉收益。
条件化容量	不同专家可能对不同 token 模式形成偏好。	专家未必对应人类可读的“代码/数学/语言”类别，也可能重复、塌缩或冷热不均。

02 · 核心公式

Router 不是“分类器标签”，而是每个 token 的动态计算路径

MoE 的输入仍是 token hidden state。常见 router 对每个 token 产生专家分数，选 Top-k 后把 token 发给对应专家，并按 gate 权重合并输出。下面 softmax + Top-k 后重归一化是常见形式，不是唯一形式：例如 DeepSeek-V3 的选择分数与 bias 机制就不同。

g(x)=\mathrm{softmax}(W_r x),\quad p_i(x)=\frac{g_i(x)}{\sum_{j\in \mathrm{TopK}}g_j(x)}

W_r 是 router 权重，E_i 是第 i 个专家，p_i 是这个 token 交给该专家时的合并权重。

重点：Router 的目标不是给句子打标签，而是给每个 token选一条计算路径。句子里“函数名”“中文解释”“数学符号”可能会去不同专家。

Top-1 Switch

每个 token 只去 1 个专家，专家 FFN 计算和 assignment 数较少；但没有多专家输出冗余，负载策略仍需单独设计。

Top-2 / Top-k GShard / Mixtral / DeepSeek

每个 token 组合多个专家输出，增加路径容量与冗余，同时增加专家计算、dispatch 和合并成本；质量是否更好不是仅由 k 保证的。

账

激活参数，不等于总参数

Active parameters vs total parameters

P_\mathrm{active\ path}\approx P_\mathrm{shared}+kP_\mathrm{expert}

“671B 总参 / 37B 激活”这类说法的意思是：模型拥有 671B 参数容量，但一个 token 前向时只经过其中约 37B 的计算路径。它不是一个 37B 模型，也不是部署时只需要装 37B 权重。

可手算：Top-2 怎么合并

某 token 对 4 个专家的 logits 是 [2,1,0,-1]，softmax 约为 [0.644,0.237,0.087,0.032]。取 Top-2 后再归一化，权重为 [0.731,0.269]。若两个专家在某一简化标量维度输出 10 和 4，合并结果就是 0.731×10+0.269×4≈8.39。真实模型对整条 hidden vector 做同样的加权。

可手算：总参与激活参

假设共享的 attention/embedding 等参数共 5B，另有 8 个、每个 2B 的专家，每 token 选 2 个。忽略小 router 后，总参约 5+8×2=21B；单 token 路径涉及约 5+2×2=9B 参数。权重存储仍按约 21B 付费，专家 FFN 计算则只走 2/8；“9B 激活”也不表示它等价于某个 9B dense 模型。

03 · Router 怎么工作

MoE 难点不在“有很多专家”，而在“怎么把 token 分过去”

Router 一旦学坏，MoE 就会变成灾难：热门专家被挤爆，冷门专家没人用；或者所有专家学成一模一样，容量浪费。好的 MoE 训练，本质是在“模型质量、负载均衡、通信效率”之间找平衡。

MoE Router 完整数据流：token hidden state 经线性投影得到所有专家的 router logits，Top-k 选择 expert ids 并归一化 gate weights，dispatch 按专家重排 assignments，选中的 experts 分别执行 FFN，最后以 gate weights 对专家输出做加权合并并恢复 token 顺序 — Router 不只是“选专家”：它先产生全量 logits，再保留 Top-k 和 gate weights；专家算完以后，输出还必须按 gate weight 加权合并。

组件	做什么	如果没做好
Router logits	给每个 token 对每个专家打分。	高频 token 可能挤向同一专家。
Top-k selection	只保留少数专家，让专家计算稀疏。	k 小路径更窄，k 大则专家 FLOPs 与 assignment 数增加；质量取舍需训练验证。
Gate weight	多个专家输出按权重合并。	过尖可能让第二专家贡献很小；过平可能削弱路由选择性，但固定 k 下并不会因此自动多算专家。
Shared expert	常开专家的设计意图是承接通用模式、减少 routed experts 的知识冗余。	是否真形成这种分工要靠训练分析；共享容量也会增加每 token 固定计算。

04 · 负载均衡

MoE 最怕“热门专家排长队，冷门专家晒太阳”

训练时一个 routing group 里有 T 个 token，每个 token 选 k 个专家。如果分配高度不均，某些专家会收到过多 token，造成 straggler、临时 buffer 压力或容量溢出。早期 capacity-based 实现可能丢弃超额 assignment；dropless 实现则保留 token，但仍要承担不均衡带来的执行代价。

C=\left\lceil \frac{T \times k}{N_\mathrm{experts}}\times \text{capacity factor}\right\rceil

这是均匀分配期望值乘安全系数的常见简化式。capacity factor 越高，capacity-based 实现越不容易溢出，但可能预留更多 buffer 或 padding；越低则更容易 drop/fallback。具体语义取决于框架。

例：T=1024、k=2、8 个专家、capacity factor=1.25，则每个专家容量 ceil(1024×2÷8×1.25)=320 个 assignment。总槽位 2560，相对 2048 个实际 assignment 留出 25% 峰值余量；是否真的产生 25% 空算，要看 kernel 是否按定长 padding 执行。

总余量够，不代表热点不溢出

仍用上面的 2048 个 assignment。若 8 个专家实际收到 [512,256,256,256,256,256,128,128]，平均仍是 256，但最热专家是平均值的 2 倍。容量上限 320 时，它会溢出 512−320=192 个 assignment；其他专家没用完的槽位不能自动借给它。真正要看的是每专家分布，而不只是总槽位。

Switch 的经典均衡损失

\mathcal{L}_\mathrm{aux}=\alpha N\sum_{i=1}^{N} f_iP_i

f_i 是硬路由后发给专家 i 的 token 比例，P_i 是该专家在 batch 中的平均 router 概率。二者都接近 1/N 时损失较小。这个式子来自 Top-1 Switch；Top-k、sequence-wise 和 global-batch 实现会有不同口径。

Auxiliary loss

给 router 加额外均衡损失，鼓励专家使用率接近。Switch/GShard 类路线常用。

Dropless MoE

不丢 token，用 block-sparse / grouped GEMM 等方式处理不均匀 token 分布。MegaBlocks 是代表路线。

Aux-loss-free expert balance

DeepSeek-V3 用每专家动态 bias 调整 top-k 选择，专家级均衡不靠可反传的辅助损失；但报告仍保留权重很小的 sequence-wise balance loss，因此不是“完全零辅助损失”。

均衡策略	优点	代价
容量限制 + token drop	实现简单，单专家工作量有上限。	被丢 assignment 跳过专家计算，可能伤训练/输出质量；影响大小取决于 residual/fallback 与 drop 比例。
Aux loss	明确约束专家使用率，容易调度。	均衡目标可能和语言建模目标冲突。
Expert-choice routing	每个专家从 token 中选固定 bucket，因此专家负载可直接控住。	单个 token 会被可变数量的专家选中；它改变了 token-choice Top-k 的语义，实现与训练动态也不同。
Router z-loss	ST-MoE 用它惩罚过大的 router logits，提升数值稳定性。	它不是占用率均衡损失，不能代替对每专家负载的监控。
动态 bias	通过不参与 gate 合并权重的选择 bias 引导负载，避免专家级均衡 loss 的梯度干扰。	需要稳定的在线负载统计与 bias 更新步长；DeepSeek-V3 还额外保留很小的 sequence-wise 均衡损失，但这不是所有动态-bias 实现的必备项。

05 · 专家并行

MoE 省的是计算，新增的是通信和调度

当全部专家权重无法或不值得在每张 GPU 上复制时，常用 Expert Parallelism（专家并行）：不同 rank 持有不同专家。Router 选完专家后，跨 rank 的 token assignment 被发送到对应设备，专家算完后再把结果送回原 token 所在 rank；若专家本地或有复制，则不一定发生跨卡传输。

\text{MoE step}:\quad \text{route} \rightarrow \text{all-to-all} \rightarrow \text{expert FFN} \rightarrow \text{all-to-all} \rightarrow \text{combine}

这就是为什么 MoE 系统报告反复强调 all-to-all。Dense 训练本来也可能有 DP、TP、PP 等 collective；启用 expert parallel 后，每个 MoE 层还会增加按路由结果 dispatch/combine token 的通信。其消息大小与不均衡程度取决于 token assignment、EP 组大小和是否复制专家。

MoE Expert Parallel 双 All-to-All 数据流：各 token-origin ranks 先输出带 expert id 和 gate 的 assignments，第一次 All-to-All 把 token activations 发送到专家 owner ranks，本地 experts 执行 grouped GEMM；第二次 All-to-All 把 expert outputs 送回 token-origin ranks，再解除重排并按 gate weights 加权合并 — Expert Parallel 通常有两段通信：dispatch 去程把 token activation 送到专家 owner；combine 回程把 expert output 送回 token 原 rank。跨卡搬的是激活与路由元数据，不是每层来回搬专家权重。

通信账

先估算 activation 搬运量，再谈“MoE 更快”

Logical dispatch + combine payload

B_\mathrm{network}\approx 2\,T\,k\,H\,b\,r_\mathrm{remote}

T 是一个 EP 通信组本轮通过该 MoE 层的 origin token 总数，k 是每 token assignment 数，H 是 hidden size，b 是实际传输 dtype 每个元素的字节数，r_remote 是 assignment 需要跨 rank 的比例；前面的 2 表示 dispatch 去程与 combine 回程。

例：T=4096、k=2、H=4096、BF16（2 bytes）。若所有 assignment 都远端，该 EP 组单个 MoE 层两程的 assignment payload 合计约 128 MiB；若只有 3/4 远端，则约 96 MiB。这是排查数量级的逻辑数据量，不是某条链路的线速计数：路由元数据、padding、网络多跳、协议开销、TP/EP 布局和 fused kernel 都会改变实测字节与时间。

并行方式	在 MoE 里的角色	通信模式
Data Parallel	复制模型或局部专家，切 batch。	梯度 all-reduce / reduce-scatter。
Tensor Parallel	把单个大矩阵切到多卡。	层内 all-reduce / all-gather。
Pipeline Parallel	把层切到不同 stage。	stage 间激活传递。
Expert Parallel	把不同专家放到不同 GPU。	token dispatch / combine 的 all-to-all。
ZeRO / FSDP	切分参数、梯度、优化器状态。	按需 all-gather / reduce-scatter。

和显存/带宽页怎么连

MoE 把 dense FFN 的“每 token 计算量”换成了“专家权重容量 + 跨卡通信”。所以它和显存与带宽是同一件事的另一面：不是只看 FLOPs，而是看权重放哪、token 怎么搬、通信能不能和计算重叠。

06 · 推理落地

Prefill 容易攒出专家批次，Decode 更怕“小矩阵 + 高频通信”

训练能跑通，不等于在线推理就快。Prefill（提示词批量前向）一次产生较多 token assignment，通常更容易把同一专家的 token 聚成较大的 grouped GEMM；Decode（逐步生成）每条请求每步通常只新增一个 token，若并发不足，专家批次会很小，router、重排和 all-to-all 的固定成本更显眼。

吞吐路径：把零散 token 聚起来

跨请求 continuous batching 增大每步 token 数，再按 expert id 重排。
Grouped GEMM 把多个大小不同的专家矩阵乘集中发射，减少小 kernel 开销。
通信与专家计算重叠是否有效，要在目标网络拓扑与真实路由分布上测。

延迟路径：别只看平均吞吐

热点专家会让少数 rank 成为尾延迟 straggler，即使全局 token 数看起来均匀。
专家复制/重映射可以改善热点，但会消耗额外权重显存并引入迁移成本。
高吞吐与低延迟通信 kernel 面向的 batch 形态不同，不能只凭单一 microbenchmark 选型。

当前官方实现（截至 2026-07-14）	已经解决什么	边界
Megatron Core MoE	支持 softmax/sigmoid Top-k、多种 aux/sequence/global/Sinkhorn/动态 bias 均衡、dropless、all-to-all/Flex dispatcher、GroupedGEMM 与 DeepEP。	组合能力是框架口径，不代表每个模型/拓扑都最优；其文档明确要求 TP 与 EP 同用时开启 Sequence Parallelism（序列并行）。
DeepEP V2	用统一 `ElasticBuffer` 提供高吞吐/低延迟 dispatch 与 combine，支持低精度传输（含 FP8），V2 后端采用 NCCL Gin。	官方说明 V2 buffer 占用高于 V1；具体 kernel 仍需按 prefill/decode、节点内/跨节点分别测。
vLLM EP / EPLB	EP 切分专家；EPLB 采集负载统计并周期性重排专家映射，还可增加 redundant experts 缓解热点。	稳定版文档仍将 EP 标为 experimental；冗余专家会挤占 GPU 显存，参数名和默认值也可能变化。

线上至少监控	为什么
每层每专家 token 直方图、avg/max、drop/fallback	平均值会掩盖热点；capacity overflow 与尾部专家决定 straggler。
dispatch/combine bytes、耗时与重叠率	区分“网络慢”与“通信没有被计算遮住”。
每专家 GEMM token 数分布	确认 grouped GEMM 是否真的得到足够大的有效矩阵。
TTFT、TPOT、吞吐与 P95/P99	Time to First Token（首 token 延迟）和 Time per Output Token（后续 token 间隔）对应不同瓶颈，不能只报 tokens/s。

07 · 真实模型案例

从 GShard、Switch 到新一代稀疏模型

现代 Transformer MoE 在 2020 年前后已进入超大规模语言模型。后续方案探索了 Top-1/Top-k、shared expert、细粒度专家、dropless 训练、动态 bias 均衡和通信重叠等不同取舍；这不是一条所有模型都按同样顺序演进的单一路线。

系统 / 模型	关键做法	该记住什么
GShard	Top-2 gating，自动分片，早期大规模 MoE 训练代表。	MoE 不只是模型结构，也是分布式系统问题。
Switch Transformer	Top-1 router，把路由简化到每 token 一个专家。	极简路由能把稀疏模型扩到万亿参数级，但负载均衡很关键。
GLaM	论文最大模型 1.2T 总参、每 token 激活约 97B，并报告相对 GPT-3 约一半 inference FLOPs。	这是论文特定比较，不是所有 1.2T MoE 的通用比例。
Mixtral 8x7B	8 个 FFN 专家，每 token 每层选 2 个；论文按约 47B 可访问参数 / 13B 激活参数表述。	“8×7B”不是 56B 总参，因为 attention、embedding 等共享。
OpenAI gpt-oss-120b	官方列 117B 总参 / 5.1B 激活、128 个专家中每 token 激活 4 个；MoE 权重使用 MXFP4。	模型卡说明 active 口径计入 unembedding、但不计 embedding，说明不同发布方的“激活参数”不能盲目横比。
DeepSeek-V3	671B 总参 / 37B 激活；每个 MoE 层 256 个 routed experts 中选 8，另有 shared expert；动态 bias 做专家级均衡。	报告仍有极小权重的 sequence-wise auxiliary loss，别把 aux-loss-free 读成零辅助项。
Qwen3-Next-80B-A3B	官方模型卡列 512 个专家、激活 10 个、1 个 shared expert；80B 总参 / 3B 激活。	同时使用 Gated DeltaNet/Gated Attention 与 MTP，是多种效率技术组合的案例。
GLM-5	官方模型卡列 744B 总参 / 40B 激活，并结合 DeepSeek Sparse Attention。	总参与激活参仍不能直接推出端到端延迟，注意力和系统实现同样关键。
MiniMax-M3	官方模型卡约 428B 总参 / 23B 激活，结合 MSA 稀疏注意力并标称 1M context。	这是“稀疏 FFN + 稀疏 attention”叠加的近期案例。

MoE 在训练端的价值

在相同训练 FLOPs 下扩大参数容量。
提供条件化参数容量；专家是否形成可解释分工需要分析，不能由架构自动推出。
可与低精度、ZeRO/FSDP 和多种并行策略组合，但收益取决于通信与 kernel。

MoE 在推理端的现实

每 token FLOPs 低，但专家权重仍可能需要常驻显存。
高并发时 router、expert batch、all-to-all、KV Cache 会互相影响。
消费级/异构推理需要专家卸载、缓存、路由 locality 等额外工程。

08 · 常见误区

别把“稀疏激活”误解成“免费变大”

误区 1：MoE 一定省显存

不一定。MoE 省每 token 计算；专家权重如果都要常驻，显存容量账仍然要付。

误区 2：专家天然会分工

不保证。没有好的路由、均衡和训练数据，专家可能塌缩、重复或冷热不均。

误区 3：总参越大越强

MoE 的总参提供容量上限，但效果还取决于激活参数、训练 token、路由质量和系统效率。

误区 4：Top-k 越大越好

k 大提供更多专家路径，但不保证质量单调提高；专家计算、assignment 数和通信通常会上升，最终要联合训练与系统实测。

误区 5：MoE 和量化互斥

不互斥。MoE 省计算，量化省容量/带宽；现代系统常把两者叠加。

误区 6：MoE 只是算法问题

错。专家并行、all-to-all、kernel、调度、显存管理共同决定 MoE 能否落地。

速查

一句话总结

Cheat sheet

MoE 是什么	把 Transformer FFN 换成 router + 多个专家，每 token 只激活少数专家。
省什么	主要省每 token 计算量，让总参数容量远大于激活计算量。
不一定省什么	不一定省显存；专家权重、KV Cache、通信 buffer 都要算。
训练难点	路由稳定、负载均衡、token overflow、专家塌缩、通信计算重叠。
系统难点	Expert Parallelism 带来的 all-to-all，常成为 MoE 扩展瓶颈。
下一层专题	量化会讲低比特怎么省容量/带宽；分布式训练会讲 DP/TP/PP/EP/ZeRO 怎么组合。

资料来源

主要参考

稀疏门控 MoE	Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer
GShard	GShard: Scaling Giant Models with Conditional Computation and Automatic Sharding
Switch Transformer	Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity
ST-MoE	ST-MoE: Designing Stable and Transferable Sparse Expert Models
GLaM	GLaM: Efficient Scaling of Language Models with Mixture-of-Experts
MegaBlocks	MegaBlocks: Efficient Sparse Training with Mixture-of-Experts
Expert Choice	Mixture-of-Experts with Expert Choice Routing
DeepSpeed-MoE	DeepSpeed-MoE: Advancing Mixture-of-Experts Inference and Training
Mixtral	Mixtral of Experts
DeepSeekMoE	DeepSeekMoE: Towards Ultimate Expert Specialization in Mixture-of-Experts Language Models
DeepSeek-V3	DeepSeek-V3 Technical Report
当前系统实现	Megatron Core MoE · DeepEP V2 · vLLM Expert Parallel Deployment
近期模型口径	OpenAI gpt-oss 介绍 / 模型卡 · Qwen3-Next 官方模型卡 · GLM-5 官方模型卡 / 论文 · MiniMax-M3 官方模型卡

核查日期：2026-07-14。参数口径按论文或官方模型卡；“active parameters”通常表示单 token 前向路径涉及的参数量估计，不等于实测 FLOPs、显存或延迟。不同发布方的统计是否包含 embedding、unembedding、router、shared expert，也可能不同。