外观
MoE 与超大规模模型
MoE（Mixture of Experts，混合专家）是一种把网络中的前馈层替换为"多个专家 + 一个路由器"，让每个 token 只激活少数专家的稀疏架构。它打破了"模型能力 ≈ 参数量 × 计算量"的强绑定：总参数可以很大（记忆多），但每次推理只算一小部分（成本可控）。MoE 是 2024 年后几乎所有超大规模模型（DeepSeek-V3、Qwen3、Llama 4、Grok-1，甚至传闻中的 GPT-4）的共同选择。本页讲它的机制、里程碑与部署实践；机制层知识见 MoE 稀疏专家模型。
一、为什么需要 MoE：一个成本矛盾
稠密（dense）模型里，参数量与计算量成正比：要 1 万亿参数，就得为每个 token 算 1 万亿次乘加，训练和推理成本都不可承受。但大模型需要"很多知识"（对应总参数），而单个 token 通常只需要"一小部分能力"（翻译一个词不需要全部数学能力）。
MoE 的思路是：准备很多"专家"（各自是一组参数），让路由器为每个 token 挑 2~8 个最相关的专家来算。
稠密模型： token → [ 1 个巨型 FFN ] → 全部 175B 参数都参与计算
MoE 模型： token → 路由器(router) → 挑 Top-2 专家 → 只激活 ~20% 参数
↘ 其余专家被跳过（不计算）收益是"参数 × 计算"解耦：DeepSeek-V3 总参数 671B，但每个 token 只激活 37B——训练算力接近 37B 稠密模型，能力却接近 671B 的"知识容量"。
这里有一个容易被名字误导的口径问题：Mixtral 8x7B 并非"8 个 7B 模型的总和"。8x7B 表示每一层 FFN 有 8 个专家，每个专家约 7B 规模的 FFN 参数；由于注意力等共享部分，总参数是 46.7B 而非 56B。类似地，DeepSeek-V3 的"671B"是全部参数（含共享与路由），"37B"是每个 token 实际计算的量。看 MoE 型号时，一定要区分"总参数"与"激活参数"两个口径，否则对比会得出错误结论。
二、核心技术：路由器、Top-k 与负载均衡
1. 路由器（Router / Gating）
路由器是一个小的线性层，输入 token 表示，输出"该 token 与每个专家的亲和度"，取 softmax 得到分布，选择 Top-k 个专家：
h = router(token) # 得分向量，长度 = 专家数 E
p = softmax(h) # 归一化
top_k = argsort(p)[:k] # 选前 k 个专家
输出 = Σ p[i] * Expert_i(token) # 按权重加权求和2. Top-1 vs Top-2 vs Top-8
| 方案 | 代表模型 | 特点 |
|---|---|---|
| Top-1 | Switch Transformer（1.6T） | 最省算力，但负载不均衡更严重 |
| Top-2 | Mixtral 8x7B、Grok-1、GLaM | 更平滑，利用率更高，社区主流 |
| Top-8 + 共享专家 | DeepSeek-V3（256 路由专家 + 1 共享专家） | 细粒度专家、激活更灵活 |
| Top-1 + 2 个共享专家 | Qwen3-235B-A22B | 共享专家保底通用能力 |
3. 负载均衡：MoE 训练的生死线
路由器有"塌缩"风险：一旦几个专家总是被选中，其余专家被饿死，MoE 就退化成稠密模型。主流对策：
- 辅助负载均衡损失（auxiliary load balancing loss）：惩罚"路由分布偏离均匀"；
- 容量因子（capacity factor）：限制每个专家最多处理多少 token，超过的走残差直连（Switch 的做法）；
- 无辅助损失的负载均衡（DeepSeek-V3 的贡献之一）：给每个专家加偏置（bias），动态调整选中概率，省掉辅助损失带来的性能损耗。
负载均衡还存在"能力 vs 效率"的微妙权衡：强负载均衡约束会让路由"平均化"，抑制专家的专业化（每个专家都学到类似能力）；无约束则可能让少数专家垄断。理想状态是"专业化但不失衡"——DeepSeek 的无辅助损失均衡通过动态偏置近似实现了这一点。实际训练中，负载均衡损失的权重是需要反复实验的超参：太大损能力、太小训练崩。这也解释了为什么 MoE 训练对工程经验要求更高。
MoE 不是"白捡的参数"
总参数大不等于能力自动变强。若路由学得不好或专家冗余，MoE 可能只比同计算量的稠密模型略好；激活参数的效率、专家的多样性、负载均衡，才是 MoE 质量的真正决定因素。
三、里程碑时间线
| 时间 | 工作 | 关键点 |
|---|---|---|
| 2017 | Shazeer et al. 稀疏门控 MoE | 首次把 MoE 层用于 LSTM 语言模型（1024 专家），但工程上难推广 |
| 2020.06 | GShard | 把 MoE 引入 Transformer，Top-2 gating，条件计算 + 自动分片 |
| 2021.01 | Switch Transformer | Top-1 路由简化，最高 1.6T 总参数，预训练加速约 7 倍 |
| 2021.12 | GLaM | 1.2T 总 / 约 97B 激活（64 专家），训练成本约为 GPT-3 的 1/3，29 项基准与 GPT-3 相当 |
| 2023.12 | Mixtral 8x7B | 首个"能真正用起来"的开源 MoE：46.7B 总 / 12.9B 激活，Apache 2.0 |
| 2024.05 | DeepSeek-V2 | MLA + DeepSeekMoE，把 MoE 成本革命推向市场 |
| 2024.12 | DeepSeek-V3 | 671B 总 / 37B 激活，256 专家 + 1 共享，FP8 训练，约 2000 张 H800 训练，全球刷屏 |
| 2025.04 | Qwen3-235B-A22B | 235B 总 / 22B 激活，混合推理模式（思考/非思考） |
| 未证实 | GPT-4（传闻） | 业界广泛认为 GPT-4 采用 MoE（传闻 8 专家、约 1.8T 总参数），OpenAI 未公布 |
把时间线串起来看，MoE 的里程碑其实沿着两条线演进：一条是"路由机制"的简化与稳健（Top-2 → Top-1 → Top-8+共享 → 无辅助损失），另一条是"工程化"的推进（GShard 的并行、vLLM 的推理支持、FP8 的低精度训练）。机制创新降低训练门槛，工程创新降低部署门槛，两者合力才让 MoE 从论文走进生产。这也给从业者一个启示：当一种架构"看起来更好"却迟迟不普及，先怀疑工程配套而非架构本身——MoE 花了数年才等来它的 vLLM。
里程碑一：Switch Transformer——"1.6 万亿参数的省电方案"
先说一段失败史：MoE 并非一路顺利。2017 年 Shazeer 等人的稀疏门控 MoE 在工程上难以规模化，一度被认为"华而不实"；直到 GShard 与 Switch Transformer 解决了路由负载与并行问题，MoE 才重新崛起。这段历史提醒我们：架构创新的落地速度取决于工程配套——负载均衡、并行通信、推理框架的支持，缺一环就会让好架构夭折。今天 MoE 的成熟，是数年工程积累的结果，而非单一论文的功劳。
Switch Transformer 用 Top-1 路由把 MoE 做到 1.6T 参数，预训练速度提升约 7 倍。它的核心贡献是证明了 MoE 可以在不损失质量的前提下大幅降低单位能力成本——"稀疏激活"从学术玩具变成规模化的工程选项。
里程碑二：Mixtral 8x7B——开源 MoE 的引爆点
2023 年 12 月，Mistral 发布 Mixtral 8x7B：FFN 层换成 8 个专家、每 token 激活 2 个，46.7B 总参数只激活 12.9B，性能却匹敌当时 70B 级稠密模型（如 Llama 2 70B），且 Apache 2.0 完全开放。它让"用 70B 级能力、1/5 的推理成本"成为现实，开源社区由此全面转向 MoE。
里程碑三：DeepSeek-V3——MoE 的成本革命
DeepSeek-V3 在 2024 年 12 月把 MoE 推到新高度：
| 维度 | 数值 |
|---|---|
| 总参数 | 671B |
| 激活参数 | 37B（每个 token） |
| 专家配置 | 256 个细粒度路由专家 + 1 个共享专家，每 token 激活 8 个 |
| 注意力 | MLA（多头潜在注意力，显著压缩 KV cache） |
| 训练精度 | FP8 混合精度 |
| 训练数据 | 14.8T token |
| 训练成本 | 约 278.8 万 H800 GPU 小时（官方公开） |
它的创新是"细粒度专家 + 共享专家"：专家切得更小、激活更多（8 个），组合更灵活；共享专家专门承接通用知识（语法、常识），路由专家承载领域能力。配合 MLA 与 FP8，DeepSeek-V3 用远低于同行的算力达到旗舰级能力，把"MoE = 大厂专属"变成"创新者也能玩"。
里程碑四：Qwen3-MoE 与 Llama 4
- Qwen3-235B-A22B（2025.4）：235B 总 / 22B 激活，激活 2 个共享专家 + 1 个路由专家，支持"思考 / 非思考"混合推理模式，指令遵循与编程评测表现突出；
- Llama 4（2025.4）：Meta 首次转向 MoE——Scout（109B-A17B）与 Maverick（400B-A17B），激活约 17B。
四、各家方案对比
| 模型 | 总参数 | 激活参数 | 专家配置 | 路由 | 亮点 |
|---|---|---|---|---|---|
| Switch Transformer | 1.6T | ~几十 B | 每层 FFN 拆多个专家 | Top-1 | 首个超大规模 MoE 验证 |
| GLaM | 1.2T | ~97B | 64 专家 | Top-2 | 训练成本仅 GPT-3 的 1/3 |
| Mixtral 8x7B | 46.7B | 12.9B | 8 专家 | Top-2 | 开源 MoE 标杆 |
| Mixtral 8x22B | 141B | 39B | 8 专家 | Top-2 | 更大开源 MoE |
| DeepSeek-V3 | 671B | 37B | 256+1 专家 | Top-8 | 细粒度专家 + 无辅助损失均衡 |
| Qwen3-235B-A22B | 235B | 22B | 路由 + 2 共享 | Top-1+共享 | 混合推理、双语 |
| Grok-1 | 314B | 86B | 8 专家 | Top-2 | xAI 首个开源 |
| GPT-4（传闻） | ~1.8T | 未公开 | 8 专家（传闻） | 未公开 | 官方未证实 |
对比表中的参数都是"纸面数字"，真正的差异在"能力/成本"曲线：同样是 671B 总参数，不同实现的路由效率、数据质量、训练时长会带来巨大差距。评估 MoE 模型的正确姿势是：固定"激活参数预算"（如 20B 级），在同一组基准与同一套提示下横向对比不同模型，并测量实际吞吐与延迟。参数表只说明"有多少料"，评测与压测才说明"做多少事"。评测方法见 评测与基准。
五、MoE 的性价比：激活参数才是账单
| 视角 | 总参数（记忆容量） | 激活参数（单 token 计算量） |
|---|---|---|
| 训练成本 | 影响显存、通信 | 决定 FLOPs（≈ 激活参数 × token 数） |
| 推理延迟 | 影响模型加载、显存驻留 | 决定前向计算时间 |
| 能力上限 | 越大知识越多 | 越高单 token 处理越精细 |
结论：训练成本主要看"激活参数 × 数据量"，能力天花板主要看"总参数 + 数据质量"，推理延迟受两者共同影响。MoE 的价值是用"多放参数、少算参数"换取训练性价比；推理侧（下文）则面临"省了算力、费了显存"的新问题。
MoE 在训练侧与推理侧的性价比逻辑并不相同，很多人混淆了这两个阶段。训练侧，MoE 的收益来自"每个 token 只激活部分专家"——同样的 FLOPs 预算下可以容纳更大的知识容量，因此训练成本按激活参数计算，比同能力稠密模型低一个量级。推理侧，计算量同样由激活参数决定，但显存与带宽由总参数决定——如果你只有一块 GPU，671B 的 MoE 根本放不下，再"省算力"也无从谈起。这解释了为什么 MoE 特别适合"训练方预算受限 + 服务方资源充足"的格局（训练省钱、部署用大集群摊薄显存），也是 DeepSeek 这类"算力有限但工程极强"的团队能做出旗舰级 MoE 的原因。理解训练/推理两侧的账要分开算，是评估任何 MoE 方案的第一步。
再强调一遍："总参数大"是知识容量的指标，"激活参数小"是成本优势的指标——选型时把这两个数字连同你的显存与并发一起算，MoE 的账就清楚了。
对"MoE 是否值得"，实践界已有一个共识性答案：在训练侧，MoE 几乎总是赢——同样的算力可以训出更大的知识容量；在推理侧，结论取决于场景——高并发、大模型、长期运行的服务，MoE 的摊销成本更低；低并发、单卡、对延迟敏感的部署，稠密更简单可靠。另一个被低估的点是生态成熟度：2024 年后 vLLM 等框架对 MoE 的原生支持已经让部署复杂度大幅下降，"MoE 难部署"的旧印象正在改变，详见 框架与工具选型。
六、MoE 的部署实践与挑战
MoE 部署并不只是"省钱"，它有一组独特的工程问题（详见 部署与服务化）：
| 挑战 | 原因 | 常见解法 |
|---|---|---|
| 显存暴涨 | 所有专家权重必须常驻显存（不管是否被激活） | 多层量化、专家卸载到 CPU/SSD |
| 通信开销 | 专家分布在多卡，token 需跨卡转发（All-to-All） | 专家并行（EP）、拓扑感知调度 |
| 负载不均衡 | 路由热点导致部分 GPU 排队 | 负载均衡训练 + 动态批处理 |
| 批处理利用率 | 单请求只激活少量专家，GPU 算力浪费 | 连续批处理（continuous batching）堆吞吐 |
| KV cache | 长上下文下注意力缓存仍按总层数存 | MLA（DeepSeek 的解法） |
1. 专家并行（Expert Parallelism, EP）
把专家切分到不同 GPU，token 根据路由结果转发到对应卡计算后再聚合——这是 MoE 推理的标准并行策略。EP 的吞吐上限受"最热专家所在卡"的瓶颈约束。
2. 推理框架支持
vLLM、SGLang、TensorRT-LLM、llama.cpp 等主流引擎都已原生支持 MoE 权重加载与 EP 调度；本地 8x7B 类 MoE 在消费级显卡上也能跑（总权重 46.7B 需约 30GB 显存，量化后可降）。
关于 MoE 与量化还有一点要单独强调：MoE 模型对量化更敏感，原因是路由层的数值稳定性——路由打分决定了 token 去哪个专家，量化噪声可能改变路由决策，导致"派错专家"。因此 MoE 量化通常需要：保留路由层为高精度、逐专家校准、量化后验证路由分布是否漂移。这些细节让 MoE 的量化部署比稠密模型更讲究，相关工具见 部署与服务化。
3. 什么时候选 MoE
| 场景 | 建议 |
|---|---|
| 需要超大知识容量、预算有限 | MoE（训练省算力） |
| 单机小显存部署、对延迟敏感 | 稠密小模型 或 量化后的中型 MoE |
| 高并发 API 服务 | MoE + EP + 连续批处理（成本最优） |
| 研究/可控性优先 | 稠密模型更简单易调 |
MoE 服务上线后要盯的指标比稠密模型多：除了常规的延迟、吞吐、token 消耗，还要监控"路由分布"——如果某些专家长期低利用率，说明路由可能退化或负载不均衡加剧；同时关注显存占用（总参数驻留）与 KV cache 峰值。把这些指标接入告警，才能在"质量悄悄下降"前发现问题。监控体系的一般性方法见 部署与服务化。
七、MoE 的训练细节与工程要点
1. 路由训练的三大工程点
| 工程点 | 问题 | 常见做法 |
|---|---|---|
| 路由初始化 | 初始均匀随机导致专家能力不均 | 路由器用小随机 + 均匀初始化，避免早期崩溃 |
| 负载均衡 | 热点专家被过度选中 | 辅助负载均衡损失、容量因子、动态偏置 |
| 专家分工 | 专家冗余、知识重叠 | 细粒度专家、共享专家承接通用能力（DeepSeek 方案） |
负载均衡的机制细节见 MoE 稀疏专家模型。
2. 与稠密训练对比
| 维度 | 稠密模型 | MoE |
|---|---|---|
| 单 token 计算量 | 全部参数 | 仅激活部分（如 5%~20%） |
| 显存需求 | 权重小但计算重 | 所有权重常驻显存，显存反而更大 |
| 通信 | 常规张量/数据并行 | 需专家并行 + All-to-All |
| 收敛 | 稳定 | 需调负载均衡，稍不稳定 |
| 性价比 | 能力与成本线性 | 同成本下能力更高（激活参数决定） |
3. 代表模型的训练配置对比
| 模型 | 总/激活参数 | 训练数据 | 上下文 | 激活专家 |
|---|---|---|---|---|
| Mixtral 8x7B | 46.7B / 12.9B | 约 8T token 级 | 32K | 2 / 8 |
| Mixtral 8x22B | 141B / 39B | 多语增强 | 64K | 2 / 8 |
| DeepSeek-V3 | 671B / 37B | 14.8T token | 128K | 8 / 256 |
| Qwen3-235B-A22B | 235B / 22B | 大规模多语 | 32K~131K | 路由 + 2 共享 |
| Grok-1 | 314B / 86B | 未公开 | 8K | 2 / 8 |
表中数字以各官方发布为准；"上下文"指发布时主版本能力。
4. MoE 前向的伪代码
# 一个 MoE 层的简化前向（每 token）
def moe_forward(x, router, experts, k=2):
logits = router(x) # [E]
p = softmax(logits) # 归一化
top_k_idx = argsort(p)[-k:] # 选前 k 个专家
out = zeros_like(x)
for i in top_k_idx:
out += p[i] * experts[i](x) # 加权求和
return out八、MoE 与未来
- 推理时扩展：MoE 与 推理时扩展（test-time scaling） 可以叠加——大参数 + 稀疏激活 + 长思维链，正是 2025 年旗舰模型的组合拳；
- 更细的粒度：专家数量继续上升（DeepSeek-V3 已是 256+1），路由精度与知识分工越来越细；
- 与多模态结合：视觉专家、语言专家分域设置，让 MoE 成为多模态大模型（见 多模态大模型）的通用底座；
- MoE 与稠密之争：短期看 MoE 是超大规模的主流；但稠密模型在低显存、低延迟、可解释性场景仍有不可替代的位置。选型原则见 规模法则 与 主流模型档案。
一句话记住 MoE
MoE = 总参数（容量）与激活参数（成本）的解耦。它让"万亿参数"从噱头变成工程现实，也让开源模型第一次能在成本上与闭源旗舰正面竞争。
九、MoE 常见问题与选型清单
1. MoE 的常见误区
| 误区 | 真相 |
|---|---|
| "总参数大 = 更聪明" | 能力看激活参数效率、路由质量与数据 |
| "MoE 一定比稠密省显存" | 恰恰相反，所有权重都驻留显存 |
| "MoE 免费获得能力提升" | 训练要调负载均衡，工程复杂度更高 |
| "MoE 推理必然更快" | 单个请求可能更慢，靠批处理/并行提吞吐 |
| "专家越多越好" | 过多专家加剧负载不均衡与通信 |
2. 什么时候不该用 MoE
| 场景 | 原因 |
|---|---|
| 单卡/小显存部署 | 总权重太大，放不下 |
| 极低延迟单请求 | 稀疏路由不如稠密直接 |
| 团队无分布式经验 | 专家并行调试门槛高 |
| 需要极简可解释 | 稠密模型更易分析 |
| 原型验证阶段 | 先跑通再优化成本 |
3. 如何评估一个 MoE 模型
| 指标 | 问什么 | 看哪里 |
|---|---|---|
| 激活参数性价比 | 同成本下能力是否更高 | 激活参数 × token 数 vs 基准分 |
| 路由质量 | 专家是否各司其职 | 路由分布统计、专家利用率 |
| 批处理吞吐 | 高并发下能到多少 token/s | 压测报告、vLLM 实测 |
| 长上下文表现 | 128K 下是否掉点 | 大海捞针、LongBench 类评测 |
| 量化鲁棒性 | 4-bit 后掉多少点 | 量化前后对比 |
4. 从稠密迁移到 MoE 的检查清单
- [ ] 确认真实瓶颈是训练算力还是推理成本
- [ ] 对比同显存下 MoE 与稠密的吞吐
- [ ] 验证推理框架（vLLM/SGLang）对该 MoE 的支持
- [ ] 评估量化方案与精度损失
- [ ] 做成本模型：激活参数、KV cache、通信开销全计入
- [ ] 长期维护与升级路径是否清晰
5. 高频问题速答
| 问题 | 速答 |
|---|---|
| Mixtral 8x7B 是 56B 吗？ | 不是，总 46.7B、激活 12.9B |
| DeepSeek-V3 多少卡训的？ | 官方公开约 2000 张 H800（以官方为准） |
| 单卡能跑 MoE 吗？ | 中小 MoE 量化后可跑，但吞吐受限 |
| 共享专家是什么？ | 所有 token 都过的通用专家，承接语法/常识 |
| 负载均衡损失是什么？ | 惩罚路由偏科的辅助损失，保证专家都被利用 |
| GPT-4 是 MoE 吗？ | 业界广泛推测是，OpenAI 未证实 |
一句话记住 MoE 选型
MoE 买的是"训练性价比"，卖的是"显存与工程复杂度"。算清楚"激活参数 × 数据量"的账，再决定是否入局。
最后补一句：MoE 的"性价比"标签成立的前提是规模够大——小场景里稠密模型往往更省心。
十、MoE 深度专题：从论文到工程
1. 关键论文速览
| 论文 / 工作 | 年份 | 核心贡献 |
|---|---|---|
| Sparsely-Gated MoE Layer | 2017 | MoE 层开山，首次用于 LM |
| GShard | 2020 | MoE + Transformer，Top-2 路由 |
| Switch Transformer | 2021 | Top-1 路由，1.6T 参数 |
| GLaM | 2021 | 1.2T 总/97B 激活，训练成本约 1/3 |
| ST-MoE | 2022 | 路由负载均衡与专家多样性的系统研究 |
| Mixtral of Experts | 2024 | 开源 MoE 落地标杆 |
| DeepSeek-V2 / V3 | 2024 | MLA + 细粒度专家 + 无辅助损失均衡 |
2. 梯度怎么穿过路由器
MoE 训练的核心细节是"路由不连续"：专家选择是离散的（Top-k），无法直接求导。主流处理：
- 路由软权重直接反向传播：对选中专家的权重 p[i] 做梯度更新；
- 专家参数独立更新：只有被选中的专家收到梯度，其余保持；
- 负载均衡损失的梯度：惩罚路由分布偏离均匀，驱动专家分工。
这带来一个现象：专家利用率低时梯度稀疏、训练变慢，所以负载均衡既是稳定性问题，也是训练效率问题。
一个常被问的问题是：为什么"让每个 token 挑几个专家"就能学到不同的能力？直觉是这样的：路由器与专家是联合训练的，专家只在被选中时收到梯度，因此它只对"把它选中的那类 token"负责——路由器学会了把数学类 token 路由给数学专家，数学专家也相应地在数学上变强，形成正反馈。这有点类似社会分工：分工越明确，单点越专业，但也越依赖路由器的"调度"。若路由器失灵（负载失衡），分工就崩坏，这也是负载均衡如此重要的原因。理解这条"分工 + 调度"的隐喻，就能预测 MoE 的强项（领域多样的大容量）与软肋（路由错误与批量利用率）。
3. 专家多样性的实验观察
工程与研究社区观察到几个普遍现象：
- 专家之间并非完全分工，存在大量"通用专家"（几乎所有 token 都会用到）——这也是共享专家的设计动机；
- 层越高，专家专业化越明显（低层做词法，高层做语义）；
- 路由质量随训练改善，但可能过拟合到训练分布，推理时需监控路由分布漂移。
4. MoE 与稠密的实证对比要点
| 对比实验 | 关键结论 |
|---|---|
| 同 FLOPs | MoE 通常优于稠密（稀疏激活收益） |
| 同总参数 | 稠密更稳，MoE 性价比在"能力/成本" |
| 小 batch | MoE 优势缩小（批处理利用率低） |
| 长上下文 | MoE 的 KV cache 与稠密一致，优势仍在激活参数 |
| 量化后 | MoE 对量化更敏感，需针对性校准 |
5. 两个反直觉的事实
对 MoE 最常见的反直觉点有两个。其一，MoE 的"总参数"几乎不影响单 token 推理延迟（除非显存带宽受限），真正决定延迟的是激活参数与 KV cache——所以宣传"671B 总参数"其实主要在说明知识容量，而不是速度；其二，MoE 在"低并发"场景下优势不明显，因为稀疏路由让单个请求只用到少量专家，GPU 难以喂饱，而高并发批处理可以把不同请求的专家需求错开，把利用率拉满。因此，评估 MoE 一定要在"你实际的并发形态"下压测，而不是看单请求基准。这两点直接决定部署选型（见 部署与服务化）。
6. 用显存公式快速判断
快速估算一个 MoE 模型能不能部署：显存 ≈ 总参数 × 每参数字节 + KV cache + 激活。由于 MoE 的总参数远大于激活参数，显存瓶颈几乎总是"总参数"。举例：Mixtral 8x7B 总 46.7B，FP16 约需 93GB，4-bit 量化后约 25GB，单张 24GB 卡勉强可跑但要配合量化与卸载；DeepSeek-V3 总 671B，FP16 约 1.3TB，只有集群才能部署，量化后也要 300GB 以上。先算总参数的账，再看激活参数的效率——这两笔账分开算，是 MoE 部署入门的第一课。
十一、MoE 相关资源清单
| 资源 | 用途 |
|---|---|
| DeepSeek-V3 / R1 技术报告 | MoE + MLA + RL 的完整工程细节 |
| Mixtral 论文与 Mistral 博客 | 开源 MoE 实现参考 |
| vLLM / SGLang 文档 | MoE 部署与专家并行 |
| HF Open LLM Leaderboard | 开源 MoE 榜单对比 |
| nanoMoE 等社区复现项目 | 从零写 MoE 层入门 |
最后提醒：资源清单只是起点。真正理解 MoE，一定要亲手跑一次——用 vLLM 部署一个 Mixtral，观察路由分布与吞吐，再对比同显存稠密模型的性价比。纸上谈兵与动手验证之间的差距，在 MoE 上尤其大。
读 MoE 论文的顺序
先读 Switch Transformer 建立直觉 → 再读 Mixtral 看落地 → 最后读 DeepSeek-V3 看工程极限。三篇读完，MoE 的机制、工程、成本就全通了。
补充一个选型提示：如果你的团队还没有分布式训练经验，第一次接触 MoE 建议从"直接使用开源 MoE 模型"开始（Mixtral、Qwen3-235B 类），而不是从零训练——先体会它的部署与成本特性，再决定是否投入训练侧。训练侧的 MoE 优化（路由、负载均衡、FP8）是深水区，没有十亿级 token 的实验预算很难体会它的全部复杂性。
十二、延伸阅读
- MoE 稀疏专家模型——路由、负载均衡的机制详解
- 规模法则——MoE 打破的"参数-算力"幂律及其边界
- Llama 与开源生态——MoE 在开源模型中的落地
- 部署与服务化——专家并行、量化与批处理
- 主流模型档案——MoE 与稠密模型的选型对照
- 前沿进展——MoE 与推理时扩展的前沿趋势
参考资料
- Shazeer et al. Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer（2017）——MoE 开山之作（arXiv）
- Lepikhin et al. GShard: Scaling Giant Models with Conditional Computation and Automatic Sharding（2020）——GShard 论文（arXiv）
- Fedus et al. Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity（2021）——Switch Transformer 论文（arXiv）
- Du et al. GLaM: Efficient Scaling of Language Models with Mixture-of-Experts（2021）——GLaM 论文（arXiv）
- Jiang et al. Mixtral of Experts（2024）——Mixtral 8x7B 论文（arXiv）
- DeepSeek-AI. DeepSeek-V3 Technical Report（2024.12）——DeepSeek-V3 论文（arXiv）
- Qwen Team. Qwen3 Technical Report（2025）——Qwen3 技术报告（arXiv）
- xAI. Grok-1 开源仓库——Grok-1 权重与说明