MoE 与主流架构对比 MoE & Architecture Variants
所属：01-fundamentals / 01-llm-core
面试权重：★★
来源：通用领域知识；未做一手考证
一句话#
MoE（Mixture-of-Experts） 把每层的 FFN 换成 N 个专家网络，用 router 为每个 token 只激活其中少数几个，从而做到总参数量很大、单 token 计算量很小；而当前主流架构的差异，基本可以归结为在归一化、激活、注意力、位置编码、稀疏化这五个位置上做的不同选择。
为什么重要（面试角度）#
MoE 是训练成本与推理成本解耦的主要手段，也是几乎所有前沿开源模型的默认选择。面试官想听的是：
- total params 与 active params 的区别，以及 MoE 到底省了什么、没省什么
- 负载均衡为什么必需、aux loss 与"无辅助损失"的平衡法有什么区别
- MoE 不省显存（所有专家都要常驻）这个常被误解的点
- 能横向对比主流架构在几个组件上的取舍，而不是背单个模型
同时这题和推理部署强相关（专家并行、all-to-all 通信、batch size 敏感性），能接上你 vLLM / 网关的经验。
核心内容#
MoE 的结构#
把 Transformer 层里的 FFN 替换为：
x → Router（一个小线性层 + softmax/sigmoid）→ 选出 top-k 专家
→ 只有这 k 个专家的 FFN 参与计算 → 按 router 权重加权求和- Sparse 激活：每个 token 只走 个专家（常见 ，也有 或更多）。
- Total vs Active：总参数量是所有专家之和，但每个 token 的实际计算量只对应 个专家的参数。这是 MoE 的核心收益——用参数换容量，而不等比例换 FLOPs。
- 一个常被引用的公开例子：Mixtral 8x7B 官方报告为每层 8 个专家、top-2 路由，总参数约 46.7B 而每 token 激活约 12.9B（具体数字以官方发布为准）。注意它不是"8 个 7B 模型拼起来"，专家是层内的 FFN 替换，注意力与 embedding 是共享的。
MoE 省了什么、没省什么#
| 维度 | 影响 |
|---|---|
| 训练算力 / 推理算力 | 省：每 token 只走 的专家 |
| 模型表达能力 | 增强：同样的 FLOPs 下拥有远多的参数容量 |
| 显存 | 不省：所有专家参数都必须在显存里（或用专家卸载换取延迟） |
| 通信 | 变贵：专家并行（EP）需要 all-to-all 交换 token，跨节点时开销显著 |
| 训练稳定性 | 更差：router 容易塌缩、需要负载均衡、对学习率与初始化更敏感 |
| 服务特性 | batch 敏感：batch 小的时候专家利用率低，吞吐优势发挥不出来 |
记住一句话：MoE 是"省算力不省显存"。这决定了它适合训练与高并发推理，对单机小显存部署反而不友好。
负载均衡：MoE 最核心的工程问题#
如果 router 总是把 token 送给少数专家，会出现两种病态：
- 赢者通吃（expert collapse）：热门专家被训得越来越好、越来越被选中，其余专家永远得不到训练，等于白占显存。
- 负载倾斜：某些专家过载，计算必须在最慢的专家上同步，吞吐掉下来。
常见对策：
| 手段 | 思路 |
|---|---|
| 辅助负载均衡损失（aux loss） | 在总损失里加一项，惩罚"路由概率之和"与"实际分配比例"的不均衡。简单有效，但权重难调：太大干扰语言建模目标、太小不起作用 |
| router z-loss | 惩罚 router logits 的幅度，抑制数值不稳定与极端路由 |
| 容量因子 + token dropping | 给每个专家设容量上限，超出的 token 被丢弃（走残差或送次优专家）。实现简单但会丢信息 |
| 无辅助损失的平衡（aux-loss-free） | 不用额外的损失项，而是给每个专家维护一个可调的偏置，按负载情况动态增减，从而在不污染主损失的情况下实现均衡。DeepSeek-V3 报告采用这一类做法并配合 shared expert 使用 |
| Shared expert | 保留少量"人人可用"的共享专家（如 DeepSeekMoE），承担通用知识，让路由专家更专注于特化，同时缓解均衡压力 |
另一个重要设计取向是 fine-grained experts：不用少数几个大专家，而是用更多更小的专家、激活更多个（例如激活 top-8 个细粒度专家而非 top-2 个大专家）。组合空间更大，路由更灵活，代价是通信与调度复杂度上升。DeepSeek 系列是这一路线的代表。
主流架构对比：五个组件的取舍#
现代 decoder-only LLM 的差异基本落在下面这张表上：
| 组件 | 主流选择 | 变体与例外 |
|---|---|---|
| 归一化 | Pre-LN + RMSNorm（不减均值、无 bias） | 少数模型在 Q/K 上额外加 QK-Norm 以稳定训练；个别模型对 logits 做 soft-cap 抑制极端值 |
| FFN 激活 | SwiGLU / GeGLU 门控激活，中间维度按约 配平参数 | 早期模型用 ReLU/GELU + ；有的用 GLU 变体 |
| 注意力 | GQA（多 query 头共享 KV 头） | MHA（小模型）、MLA（DeepSeek 系）；局部注意力的变体见下 |
| 位置编码 | RoPE | ALiBi（BLOOM/MPT 等）；可学习绝对位置（GPT-2/BERT）已非主流 |
| 稀疏化 | 稠密 FFN | MoE：Mixtral、DeepSeek、Qwen 的 MoE 版本等；也有"同系列稠密 + MoE 双版本"的产品策略 |
| 偏置项 | 线性层无 bias | 早期模型保留 bias |
| 注意力窗口 | 全注意力 | 滑动窗口注意力（sliding window）降低长序列成本；有的模型让局部注意力与全局注意力逐层交替（Gemma 2 一类做法），兼顾局部效率与全局信息 |
Encoder-only / Encoder-Decoder / Decoder-only：BERT 式 encoder-only 适合理解类任务；T5 式 encoder-decoder 在翻译、摘要等"输入到输出形态差异大"的任务上有结构优势；但纯 decoder-only 胜出了，原因是：① 单一目标（下一 token 预测）最利于规模化；② 训练时可对整序列并行、推理时 KV Cache 复用同一套结构；③ 一套模型统一处理所有任务，工程栈最简。这个结论是历史与工程共同作用的结果，不是"encoder-decoder 做不到"。
其他值得知道的结构演进#
- MTP（Multi-Token Prediction）：训练时让模型同时预测未来多个 token（额外的轻量预测头），据说能提升数据效率并可作为推测解码的草稿；DeepSeek-V3 报告采用了这一设计。属于较新的做法，是否值得引入取决于训练框架支持程度。
- 注意力 sink：保留少量"汇聚"位置的 KV（或在序列开头放显式 sink token），可显著改善超长序列的稳定性，是 StreamingLLM 一类方法的机制基础；部分新模型引入了显式 sink token（较新做法，配置随版本变化）。
- 层间结构差异：多数模型各层同构，但也有在首尾层或中间层做差异化设计的方案（如去掉某些层的注意力）。属于局部优化，不是主流。
引用具体模型配置时务必对照其官方 config/model card——同名模型的不同版本（甚至不同尺寸）在 KV 头数、注意力窗口、激活函数上都可能不同，用错版本是这类题目最常见的翻车原因。
常见面试问法#
Q：MoE 是什么？为什么能"参数多但计算少"？ A：把每层的 FFN 换成多个专家，router 为每个 token 只选择 top-k 个专家计算。总参数量是所有专家之和，但每 token 只激活 个，因此 FLOPs 只与激活参数成正比，而模型容量由总参数决定。注意它不省显存，所有专家都必须常驻。
Q：MoE 的负载均衡为什么必要？怎么解决？ A：不均衡会导致专家塌缩（少数专家垄断流量，其余永远训不到）和计算倾斜（吞吐受最慢专家拖累）。手段有辅助负载均衡损失、router z-loss、容量因子与 token dropping、以及用可调偏置代替辅助损失的无损均衡方案；配合 shared expert 和细粒度专家能进一步缓解。
Q：MoE 和稠密模型各自的取舍？ A：MoE 在同等 FLOPs 下容量更大、训练与高并发推理更划算，但显存占用高（总参数常驻）、通信开销大（EP all-to-all）、训练更不稳定、对小 batch 不友好、微调也更难。稠密模型结构简单、显存与计算匹配、部署门槛低。选择依据是：是否有足够大的 batch 与多卡集群，以及是否需要单机部署。
Q：为什么最后是 decoder-only 赢了？ A：① 单一下一 token 目标最容易规模化；② 训练可整序列并行、推理有 KV Cache，同一套结构吃满两端；③ 所有任务统一成生成，工程栈最简、迁移成本最低。encoder-decoder 在特定任务上仍有结构优势（如翻译），只是没有成为通用基座的主流。
Q：现代 LLM 架构的公约数是什么？ A：Pre-LN + RMSNorm、SwiGLU 门控 FFN、RoPE、因果掩码的 decoder-only、GQA、无 bias 线性层，代价可控地叠加 FlashAttention 与 MoE。差异主要在注意力稀疏形式（滑动窗口/交替）、是否 MoE、以及稳定性增强（QK-Norm、logit soft-cap）。
易错点#
- ❌ 说"MoE 省显存"——恰恰相反，它与同激活量的稠密模型相比显存更贵，因为总参数必须常驻。
- ❌ 把"8x7B"理解成 8 个 7B 模型——专家是层内 FFN 替换，注意力/embedding 共享。
- ❌ 混淆 total params 与 active params，用总参数去估算推理 FLOPs。
- ❌ 认为 MoE 可以随便小 batch 部署——batch 小时专家利用率低，吞吐优势基本消失。
- ❌ 忽略负载均衡，认为 router 会自然均匀。
- ❌ 背模型配置时不看版本（同一模型不同尺寸/版本在 KV 头数、窗口、激活上可能不同）。
- ❌ 断言"encoder-decoder 已经不行了"——准确说法是 decoder-only 在通用基座上胜出，特定任务上 encoder-decoder 仍有结构优势。
- ❌ 把 MoE 的训练不稳定性当成实现 bug 去调——它是稀疏路由的固有属性，需要在损失设计、初始化、容量策略上系统处理。
自测#
1. MoE 的"总参数量大、计算量小"是怎么实现的？它省了显存吗？
答案
每层的 FFN 被替换为 N 个专家，router 对每个 token 选 top-k 个专家，只计算这 k 个专家的前向并按路由权重加权求和。因此每 token 的 FLOPs 只与"激活参数"（≈ k/N 的专家参数 + 共享部分）成正比，而模型容量由"总参数"（全部专家之和）决定，实现了参数与计算的解耦。显存不省：所有专家权重都必须常驻显存（除非做专家卸载，代价是延迟），所以 MoE 模型的显存需求高于同激活量的稠密模型。
2. router 出现专家塌缩，你会怎么诊断和处理？
答案
诊断：统计各专家的 token 分配比例与路由概率分布，看是否长期高度倾斜（少数专家占绝大多数流量），并检查这些专家的 loss/梯度是否几乎为零（说明未被训练）。处理：① 加辅助负载均衡损失，调权重使其只起均衡作用而不干扰语言建模目标；② 加 router z-loss 抑制 logits 极端值；③ 设容量因子与 token dropping 控制单专家负载；④ 改用无辅助损失的可调偏置方案，避免污染主损失；⑤ 引入 shared expert 吸收通用知识、给专家减负；⑥ 检查初始化与学习率，过大的学习率会放大路由震荡。
3. 你把 llama 架构的五六个组件说出来，并说明各自解决什么问题。
答案
① Pre-LN + RMSNorm：稳定深层训练、降低对 warmup 的依赖、比 LayerNorm 更省算力；② SwiGLU 门控 FFN：同等参数量下表达力更好（中间维度按 8/3·d 配平）；③ RoPE：注入相对位置信息并支持后续的长上下文扩展；④ 因果掩码的 decoder-only self-attention：自回归生成、可并行训练；⑤ GQA：多个 query 头共享 KV 头，压缩 KV Cache 显存与解码带宽；⑥ 线性层无 bias：省参数、便于推理融合；⑦ 配合 FlashAttention 实现注意力：省显存且更快。
4. 一个团队要把 MoE 模型部署到单张 80GB 卡上，你会提醒他们什么？
答案
① 显存：MoE 的总参数必须常驻（或做专家卸载到 CPU/NVMe，会显著增加延迟），不能按激活参数量估算显存；② 量化：常需要 INT8/INT4 才能放下；③ batch：MoE 的优势依赖较大的 batch 让专家被充分利用，单请求低并发下吞吐优势消失甚至更差；④ 通信：若跨卡专家并行会有 all-to-all 开销，单卡则退化为本地路由计算，需实测；⑤ 服务框架：需要确认推理引擎对该 MoE 结构（路由器实现、专家排布）的支持程度与实测吞吐，别只看模型大小。
5. "既然 MoE 更省算力，那所有模型都应该用 MoE"——你怎么反驳？
答案
省算力不等于省成本。MoE 的代价包括：所有专家参数常驻显存（显存成本更高）、专家并行的 all-to-all 通信开销、训练不稳定需要额外的均衡与稳定性设计、对小 batch 部署不友好、微调与生态工具支持更复杂、以及路由带来的不可预测性。因此是否用 MoE 取决于场景：有大规模多卡集群、高并发推理、追求训练效率时 MoE 优势明显；单机部署、小 batch、显存受限的场景，稠密模型更合适。实践中不少产品线是密集 + MoE 双版本并存的。