MoE 架构深度剖析
用"专科医院"的直觉理解为什么 MoE 能让万亿参数模型跑在消费级显卡上 | 预计阅读时间：30 分钟
一、引言
2026 年 4 月 24 日，DeepSeek V4 发布。两个版本的技术规格让整个开源社区沸腾：
- V4-Pro：1.6T 总参数 / 49B 激活参数 / 61 层
- V4-Flash：284B 总参数 / 13B 激活参数 / 43 层
1.6 万亿参数，但每次推理只激活 490 亿——激活比例仅 3%。这意味着什么？意味着你手上那块 RTX 4090（24GB 显存），理论上可以运行一个总参数量是 GPT-3 十倍以上的模型。只要它有 MoE。
MoE（Mixture of Experts，混合专家）不是什么新概念。2017 年 Google 就在《Outrageously Large Neural Networks》中提出了这个架构。但真正把它做到极致、让万亿参数模型变得实用甚至便宜的，是 DeepSeek。
从 V2 首次引入 MoE，到 V3 的 DeepSeekMoE 细粒度专家分割，再到 V4 的超级 MoE 升级——DeepSeek 在这条路线上走了三年。V4 发布时，社区的一个评价很到位："MoE 是 DeepSeek 的基因，不是贴上去的标签。"
本文从零开始拆解 MoE：先搞清楚它为什么有效，再看 DeepSeek 如何一步步把它推到极致，最后审视工程化落地中的真实挑战。
二、MoE 基本原理与直觉
2.1 一个类比：综合医院 vs 专科医院
想象一下你走进一家综合医院。医院很大，什么科室都有——内科、外科、儿科、眼科、耳鼻喉科。但问题是，无论你是什么病，都得先经过同一个全科医生。
全科医生懂很多，但什么都不精。他需要记住所有科室的所有知识，工作量巨大，容易疲劳出错。这就是传统稠密模型（Dense Model）的问题——一个巨大的神经网络要处理所有类型的输入，每个 token 都要激活全部参数。
现在换一种模式：专科医院。
你走进大门，先到分诊台（路由器 / Router）。护士问了你几个问题，判断你的症状属于哪个科室，然后把你分配到对应的专科医生那里。你只看一个医生，其他医生在休息。医院的专科医生数量可以很多——心内科、呼吸科、骨科、神经科、皮肤科……但每次只调用最相关的那个。
这就是 MoE 的核心思想：把大模型拆成多个"专家"子网络，每次推理只激活一小部分专家，由路由器动态决定哪些专家最合适。
2.2 MoE 的组件
一个标准的 MoE 层由三个核心组件构成：
路由器（Router / Gate Network）：一个轻量级的门控网络，接收 token 的隐藏状态，输出每个专家的"亲和度分数"（affinity score）。分数越高，说明这个 token 和该专家越匹配。
专家网络（Expert Networks）：一组前馈神经网络（FFN），每个专家是一个独立的 MLP（多层感知机）。专家之间参数不共享，各自学习不同的知识模式。
聚合器（Combiner）：将多个专家的输出按权重组合成最终输出。
MoE 层工作流程示意图
输入 Token
│
▼
┌──────────┐
│ Router │ ──── 计算每个专家的亲和度分数
│ 门控网络 │
└────┬─────┘
│
选择 Top-K 专家
│
┌────┼────┬────┬────┐
▼ ▼ ▼ ▼ ▼
E1 E2 E3 ... En ← n 个专家子网络（FFN）
│ │ │
└────┴────┬─────────┘
▼
┌───────────────┐
│ 加权聚合输出 │
└───────────────┘2.3 稀疏激活的核心直觉
传统稠密模型的工作方式是：一个输入来了，所有参数都参与计算。这就像是全科医生看病——不管你是感冒还是骨折，医生都要调用他所有的知识。
MoE 的工作方式是：输入来了，路由器判断最相关的是哪几个专家，只激活它们。其他专家保持休眠。
这里有一个反直觉的关键点：MoE 模型的总参数很大，但每次推理的计算量只和激活参数相关。
一个极端的例子：
- 稠密模型 BERT-Large：3.4 亿参数，100% 激活
- DeepSeek V4-Pro：1.6 万亿参数，3% 激活
后者虽然有前者的 470 倍总参数，但每次推理的计算量只相当于一个约 49B 参数的稠密模型。这就是 MoE 的魔力——用参数量换知识容量，用稀疏激活保推理速度。
2.4 为什么 MoE 有效？
两个核心原因：
第一，知识专业化（Specialization）。不同的专家可以学习不同的知识模式。有些专家擅长语法和句法，有些擅长数学推理，有些擅长代码生成，有些擅长跨语言的语义映射。路由器负责把不同的问题分给最合适的人。这比一个网络硬学所有东西要高效。
第二，参数复用（Parameter Efficiency）。一个 1.6T 参数的稠密模型，几乎不可能被训练好——数据不够、算力不够、优化困难。但 MoE 版本下，1.6T 参数被分散到 384 个专家中，每个专家只需处理自己擅长的子任务，训练起来反而更容易收敛。
DeepSeek 的技术报告里有一句话很关键："稀疏性是 MoE 的核心优势，也是 MoE 的核心挑战。" 稀疏性带来效率，但也带来路由不稳定、负载不均衡、通信开销大等一系列工程问题。
三、MoE vs 稠密模型
3.1 全面对比
| 维度 | 稠密模型 (Dense) | MoE 模型 |
|---|---|---|
| 参数利用率 | 100% 参数被激活，但大量参数对特定输入是冗余的 | 仅 3%-10% 被激活，但激活的参数高度相关 |
| 推理计算量 | 与总参数量成正比 | 与激活参数量成正比，通常只有稠密模型的 10%-30% |
| 训练稳定性 | 相对稳定，优化器成熟（AdamW 是标配） | 容易路由崩塌，需要专门的负载均衡策略 |
| 内存需求 | 需要加载全部参数，训练时还需额外显存 | 需要加载全部参数，但推理时一次只激活部分 |
| 并行策略 | 数据并行 + 张量并行 + 流水线并行 | 额外需要专家并行（Expert Parallelism） |
| 通信开销 | 相对可控，以 all-reduce 为主 | 高，每层 MoE 都需要 all-to-all 通信 |
| 知识容量上限 | 受限于训练成本和推理成本 | 极高，总参数量可以远超稠密模型 |
| 硬件友好度 | 高，标准矩阵乘法 | 低，需要算子和通信库的特殊优化 |
| 典型代表 | GPT-4（部分层）、Claude Opus、混元 Hy3 | DeepSeek V3/V4、Gemini、Mixtral |
3.2 参数效率：一个量化例子
假设我们要训练一个具备 GPT-4 级别知识的模型。有两种选择：
- 选择 A：训练一个 1.8T 参数的稠密模型。每次推理需要 1.8T 的 FLOPs，训练需要上万张 GPU 跑几个月。
- 选择 B：训练一个 MoE 模型，总参数 1.6T，激活参数 49B。每次推理只需 49B 对应的 FLOPs，训练成本大幅降低。
DeepSeek 选了 B。不是因为他们做不出稠密模型，而是因为在同等知识容量下，MoE 的成本结构好太多了。
3.3 什么时候 MoE 不如稠密模型？
MoE 不是银弹。以下几个场景中稠密模型可能更优：
短序列、低并发推理场景。MoE 的 all-to-all 通信开销在 batch size 很小时是瓶颈。如果你只需要单条短文本推理，一个同等激活参数的稠密模型可能更快。这就是为什么很多轻量模型（如 Qwen 3.6 的 3B 激活版本）坚持用稠密架构——通信开销在小型推理中占比太大。
训练资源极度受限的场景。MoE 的负载均衡和路由不稳定问题增加了训练的调参难度。如果 GPU 数量不多（比如 64 块以下），训练 MoE 的效率可能不如训练同样激活参数的稠密模型。
对延迟极度敏感的场景。MoE 的路由决策和专家结果聚合引入额外延迟。对于实时对话等毫秒级场景，稠密模型的确定性延迟特性更占优。
3.4 行业路线分歧
2026 年的大模型市场，MoE 和稠密两条路线并行：
MoE 阵营：DeepSeek（V2 到 V4）、Google（Gemini）、Mistral（Mixtral）、阿里（Qwen MoE 版本）
稠密阵营：OpenAI（GPT 系列）、腾讯混元（Hy3，明确走稠密路线）、Anthropic（Claude 早期，后期引入 MoE 类似设计）
两条路线没有绝对优劣。DeepSeek V4 用 MoE 在开源社区证明了万亿参数模型的可行性，但 GPT-5.5 用稠密架构依然拿下了多项基准最优。关键还是看场景和成本约束。
从行业趋势看，MoE 在超大模型中的主导地位在加强。2026 年的共识是：模型超过 1T 参数时，MoE 几乎是唯一现实的选择。 参数规模越大，稀疏激活带来的成本优势越突出。
四、DeepSeek MoE 演进
4.1 从 V2 到 V4 的三代 MoE
DeepSeek 的 MoE 路线经历了三次跨越。这不是简单的"加专家、扩参数"，而是每一代都在路由策略、专家组织和训练稳定性上做了重大创新。
4.2 V2（2024.05）：MoE 试水
V2 是 DeepSeek 第一次引入 MoE。当时的配置比较"标准"——每个 MoE 层有 64 个专家，每次激活 6 个专家，配合 MLA（Multi-head Latent Attention）压缩 KV Cache。
V2 的 MoE 和当时主流方案（如 Mixtral 8x7B）差别不大。它的真正创新在于 MLA，MoE 只是一个"能让模型做大"的工具。但正是在 V2 上，DeepSeek 积累了 MoE 的训练和推理经验——包括路由网络的稳定性、负载均衡的调参技巧、以及专家并行在分布式训练中的通信优化。
一个重要的经验来自 V2 的训练过程：DeepSeek 发现传统的 MoE 辅助损失（auxiliary loss）会显著损害模型质量。当辅助损失的系数设置较大时，负载均衡效果好了，但模型的推理和代码能力下降了。这个发现直接推动了 V3 中"辅助损失无关负载均衡"的发明。
4.3 V3（2024.12）：DeepSeekMoE——细粒度专家革命
V3 将 MoE 的配置推向极致：每个 MoE 层 256 个路由专家 + 1 个共享专家，每次激活 8 个路由专家。总参数 671B，激活参数 37B（5.5%）。
V3 的 MoE 有三个核心创新，构成了 DeepSeekMoE 的完整体系：
细粒度专家分割（Fine-grained Expert Segmentation）。传统 MoE（如 Mixtral 8x7B）把 FFN 层拆成少数几个中型专家（比如 8 个），每个专家包含完整的 FFN 维度。DeepSeek 的做法是把专家数量大幅增加（256 个），每个专家的中间维度缩小。这样做的好处是：路由器的选择空间更大，细粒度的知识分配更精确。类比一下，8 个大型专家像是 8 个包罗万象的全科医生，256 个小型专家像是 256 个高度专注的专科医生——后者的组合更灵活。
共享专家隔离（Shared Expert Isolation）。V3 在每个 MoE 层中设置了一个"共享专家"，它不参与路由选择，而是处理所有 token。共享专家负责捕获所有 token 共享的通用知识——比如基础的语法结构、常见的语义模式。路由专家则专注于差异化的知识。这种分离设计将路由熵降低了 40% 以上，因为路由专家不再需要纠结于那些所有 token 都需要的"常识性"知识，可以更纯粹地专注于差异化模式。
技术报告中的公式表达了这种分离：
h_t^l = FFN_shared(u_t^l) + Σ(g_i,t × FFN_i(u_t^l)) + u_t^l其中 FFN_shared 是共享专家，FFN_i 是第 i 个路由专家，g_i,t 是路由权重。
辅助损失无关负载均衡（Auxiliary-Loss-Free Load Balancing）。这是 V3 最重要的工程创新。传统 MoE 通过辅助损失来惩罚不平衡的路由，但辅助损失会干扰主任务的学习，损害模型质量。DeepSeek 的方案是：为每个专家增加一个可学习的偏置项 b_i。在训练过程中，动态调节这个偏置——过载的专家（被选中的次数过多）降低偏置，欠载的专家提高偏置。
关键细节：偏置只用于影响路由选择，不影响专家的输出权重。 也就是说，一个专家即使因为偏置被调低了而没有被选中，但如果它被选中的话，它的门控值（gating value）仍然基于原始的亲和度分数计算，不受偏置影响。这确保了路由均衡不会干扰模型对专家输出质量的判断。
4.4 V4（2026.04）：超级 MoE——三个关键升级
V4 在 V3 的 DeepSeekMoE 基础上做了三个关键升级：
Hash-MoE 引导启动。V4 的前 3 层使用 Hash-MoE：不通过门控网络，而是直接根据输入 token ID 的哈希值分配专家。这是一种静态路由策略——token 和专家的映射关系在训练开始前就被固定，不会随着梯度更新而改变。
为什么要在前 3 层这么做？因为浅层网络学习的是基础的 token 表示，此时让路由网络自由学习反而容易不稳定。Hash 路由相当于给模型一个"热身期"——先让浅层网络稳定下来，把路由器的"纠结"留给深层。这和人类的认知是一致的：初级处理（如视觉皮层 V1）用固定的通路，高级处理才做动态选择。
技术层面，V4 的实现是：Hash-MoE 层仍然有一个门控网络，它产生亲和度分数用于权重聚合，但"选择哪些专家"是由哈希表决定的，不受门控网络影响。这降低了早期层的训练难度。
Sqrt(Softplus) 亲和度函数。V3 使用 Sigmoid 函数计算 token 和专家之间的亲和度分数，V4 改为 Sqrt(Softplus(·))。为什么？
Sigmoid 的输出范围是 (0, 1)，在输入很大时会饱和。Sqrt(Softplus) 的输出范围是 (0, +∞)，不会饱和。这意味着亲和度分数可以更大，路由器对不同专家的区分度更高。简单说，Sqrt(Softplus) 让路由器在"选谁"这件事上做出更明确的判断，而不是模棱两可。
同时，V4 移除了 V3 中的分组限制（n_group / topk_group）。V3 中，256 个专家被分成若干组，每个 token 必须从每个组中选一定数量的专家。这个约束是为了保证负载均衡而加的，但它限制了路由器的自由度。V4 通过辅助损失无关负载均衡的改进，不再需要这个约束。
FP4 量化专家权重。V4 将路由专家的权重从 FP8 降到 FP4。这直接把专家权重的存储大小减半。V4-Pro 的 1.6T 参数中，绝大部分是 MoE 专家权重。FP4 量化意味着这些专家权重的加载和计算都更快。
FP4 的实现关键是无损反量化：FP4 (E2M1) 到 FP8 (E4M3) 反量化时，只要 FP4 子块的 scale factor 比例不超过阈值，尺度信息能完全塞进 FP8 动态范围。训练时模拟 FP4→FP8 反量化，推理时直接用 FP4 权重。这等于"零改动复用原有 FP8 训练框架"。
4.5 演进对比表
| 维度 | V2 | V3 | V4-Pro |
|---|---|---|---|
| 路由专家数 | 64 | 256 | 384 |
| 共享专家 | 无 | 1 | 1 |
| 每 token 激活专家数 | 6 | 8 | 6 |
| 激活比例 | — | ~5.5% | ~3% |
| 路由策略 | Top-K 门控 | Top-K 门控 + 分组限制 | Hash-MoE(前3层) + Top-K 门控(无分组限制) |
| 亲和度函数 | Sigmoid | Sigmoid | Sqrt(Softplus) |
| 负载均衡 | 辅助损失 | 辅助损失无关 | 辅助损失无关 + 序列级平衡损失 |
| 专家量化 | FP8 | FP8 | FP4 |
| 并行策略 | 数据并行 + 专家并行 | EP320 (256 专家 × 320 节点) | EP + 优化通信 |
| 训练稳定性 | 基本 | 辅助损失无关均衡 | Anticipatory Routing + SwiGLU Clamping |
五、V4 专家路由机制
5.1 路由的完整流程
V4 中，一个 token 从进入 MoE 层到产出的完整流程如下：
Token 输入（隐藏状态 h）
│
▼
步骤 1：计算亲和度分数
s_i = Sqrt(Softplus(h^T · e_i)) ← 对每个专家 e_i 计算
│
▼
步骤 2：应用偏置校正
s'_i = s_i + b_i ← b_i 是动态偏置，只影响选择，不影响权重
│
▼
步骤 3：Top-K 选择
top_k_indices = argmax(s'_i, k=6) ← 选出亲和度最高的 6 个专家
│
▼
步骤 4：计算门控权重
g_i = Softmax(s_i) for i in top-k ← 使用原始 s_i（不含偏置）归一化
│
▼
步骤 5：专家前向传播 + 加权聚合
output = FFN_shared(h) + Σ(g_i × FFN_i(h)) + h注意步骤 2 和步骤 4 的分离：偏置 b_i 影响"选谁"，但不影响"选中的专家输出权重是多少"。 这是一个精妙的设计——负载均衡的调整不影响模型对专家质量的判断。
5.2 Hash-MoE：前 3 层的静态路由
前 3 层的情况有所不同。V4 为这 3 层配置了 mlp_layer_types = "hash_moe"，路由逻辑变为：
Token ID → tid2eid[token_id] 查找 → 得到固定专家索引
门控网络 → 计算输出权重（和普通 MoE 一致）这里的 tid2eid 是一个预计算的查找表，在训练开始前根据 token ID 的哈希函数初始化。训练过程中，这个表不被更新——它始终保持静态。
但 Hash-MoE 层的门控网络仍然被训练。它的作用是学习如何正确地给这些固定分配的专家分配权重。所以即便路由是静态的，模型仍然能学会"这个 token 虽然被固定分给专家 X，但专家 Y 的辅助处理也有用"——门控网络给不同专家的权重就是这种灵活性的体现。
V4 的默认配置是前 3 层使用 Hash-MoE，后面所有 MoE 层使用标准 Top-K 路由。这个 3 层的经验值来自 DeepSeek 在 V3 训练中的观察——浅层网络的自由路由往往在训练早期产生不稳定性，而 3 层固定路由就足以稳定后续的训练。
5.3 门控网络的训练
门控网络是一个轻量级的线性层，将输入隐藏状态投影到专家数量的维度上。以 V4-Pro 为例，门控网络将隐藏状态（维度 d=7168）投影到 384 维的分数向量。
门控网络的训练遵循以下原则：
梯度只来自被选中的专家。在反向传播中，未被选中的专家不贡献梯度。这意味着门控网络只根据"实际选用的专家"的反馈来调整选择策略。
偏置不参与梯度更新。偏置 b_i 的更新方式是规则驱动而非梯度驱动：在每个训练步结束时，统计每个专家的负载。如果专家过载（被选中次数超过理想值的 1.25 倍），偏置减少 γ；如果欠载（低于理想值的 0.75 倍），偏置增加 γ。γ 是一个超参数，控制调整速度。
辅助损失的兜底。虽然 V4 主要使用辅助损失无关策略，但仍保留了一个轻量的序列级平衡损失——目的是防止单条序列内部出现极端的专家负载不均衡。这个损失的系数很小（0.001），主要起到"兜底"作用，不影响模型的正常学习。
5.4 路由的代价
路由机制是有代价的，主要体现在三个方面：
前向传播的额外计算。门控网络虽然轻量，但需要计算所有专家的亲和度分数。以 V4-Pro 为例，384 个专家的亲和度分数计算需要一次 7168×384 的矩阵乘法。这个计算量相比专家前向传播本身是小的（约 1%-2%），但对于延迟敏感的低 batch size 场景不可忽略。
路由的不确定性。不同 token 可能被路由到不同的专家组合。这意味着在同一 batch 中，每个专家处理的 token 数量不同。如果某个专家被特别多 token 选中，它就成为计算瓶颈。V4 通过偏置调整和序列级平衡损失来缓解这个问题，但不能完全消除。
路由结果的不可解释性。目前还没有可靠的理论解释为什么某个 token 被路由到某些专家而非其他专家。最近一篇 arXiv 论文（《The Myth of Expert Specialization in MoEs》，2026.04）指出，MoE 的路由模式更多反映的是隐藏状态的几何结构，而非真正的"领域专业化"。这意味着路由器很可能不是在按语义分类——数字相关的 token 不一定会路由到"数学专家"。路由器的决策逻辑可能比我们以为的更随机、更依赖具体的训练状态。
这一点对理解 MoE 模型的能力边界很重要：路由器的"智能"是有限的，我们不应过度解释专家专业化。
六、Pro vs Flash 架构对比
6.1 核心参数对比
V4-Pro 和 V4-Flash 共享同一个架构设计，但在规模上做了差异化配置。
| 规格项 | V4-Pro | V4-Flash |
|---|---|---|
| 总参数量 | 1.6T | 284B |
| 激活参数 | 49B | 13B |
| 激活比例 | ~3% | ~4.6% |
| 层数 | 61 | 43 |
| 隐藏维度 | 7168 | 4096 |
| 路由专家数 | 384 | 256 |
| 共享专家数 | 1 | 1 |
| 每 token 激活专家 | 6 | 6 |
| Hash-MoE 层数 | 3 | 3 |
| 专家中间维度 | 2048 | 1024 |
| 上下文 | 1M | 1M |
| 词表 | 128K | 128K |
| 训练数据 | 33T tokens | 32T tokens |
| 注意力架构 | CSA + HCA | CSA + HCA |
| 路由策略 | Hash前3层 + Top-K | Hash前3层 + Top-K |
| 量化精度 | 专家 FP4，其余 FP8 | 专家 FP4，其余 FP8 |
| 单个 80GB GPU 支持 | 否（需要多卡） | 是（FP8 量化后） |
6.2 专家数量的差异：384 vs 256
一个值得展开的点：为什么 Pro 用 384 个专家而 Flash 用 256 个？
答案和模型的知识容量目标有关。Pro 的目标是逼近闭源旗舰的性能，所以需要更大的总参数容量来支撑更广泛的知识覆盖。384 个专家 × 每个专家约 4B 参数 ≈ 1.5T，加上共享专家、嵌入层和注意力层参数，构成了 1.6T 的总参数。
Flash 面向高频低成本场景，256 个专家已经足够覆盖大部分通用知识。284B 的总参数中，专家权重约占 200B+，其余是共享层和注意力层。
但有一个重要的对称性：两个版本激活的专家数量相同（都是 6 个）。这意味着无论 Pro 还是 Flash，每次推理的"专家计算量"是同一量级的——差异主要在注意力层的计算量（Pro 的隐藏维度 7168 大于 Flash 的 4096）。
这也解释了为什么 Flash 能以更低的成本提供接近 Pro 的日常使用体验：简单任务不挑专家，6 个专家足以应对；复杂任务需要更大知识池子，才需要 Pro 的 384 个专家提供更多选择。
6.3 层数差异：61 vs 43
61 层和 43 层的差异不仅仅在层数本身，还在于注意力计算量的差异。每增加一层，意味着增加一个 CSA 或 HCA 注意力计算，以及一个 MoE 前向传播。
从工程角度看，61 层的 Pro 在训练时需要更多的流水线并行切分，GPU 之间的同步成本更高。43 层的 Flash 则可以更灵活地适配不同的并行策略。
另一个值得注意的点：V4 的 61 层对比 V3 的 67 层反而减少了。这是因为 V4 用更深的单层计算替代了 V3 的多层堆叠——mHC 让每层的表达能力更强，从而可以用更少的层数达到同等甚至更好的效果。
6.4 同样是 6 个专家，差别在哪？
V4-Pro 和 V4-Flash 的"每 token 激活 6 个专家"看似一样，但实际体验差别不小：
专家质量不同。Pro 的 384 个专家池子中选 6 个，Flash 的 256 个专家池子中选 6 个。更大的池子意味着更高的"匹配精度"——就像在一个大医院（384 个专科医生）比在小诊所（256 个医生）更容易找到对的专家。
共享专家的容量不同。共享专家处理所有 token 的通用知识。Pro 的共享专家（中间维度 2048）比 Flash（中间维度 1024）更大，承载的通用知识更多。
隐藏状态的维度不同。Pro 的隐藏维度 7168 比 Flash 的 4096 高了 75%。这意味着 Pro 中每个专家处理的信息量更大，专家的"表达能力"更强。这也是为什么 Pro 在复杂推理任务上显著优于 Flash——更大的隐藏维度让信息在层之间传递时丢失更少。
6.5 价格对比中的 MoE 因素
V4 的定价体系中，Pro 和 Flash 的价格差异（$1.74 vs $0.14 每百万 token 输入）主要来自 MoE 架构的差异。
从 MoE 角度看，Pro 比 Flash 贵其实很合理：
- 专家数量多 50%（384 vs 256），虽然每次激活都是 6 个，但更大的专家池子需要更多 GPU 显存来加载
- 隐藏维度大 75%（7168 vs 4096），注意力计算量更大
- 层数多 42%（61 vs 43），整体计算量更大
但因为两者都是 MoE，每次推理的实际计算量远小于稠密模型在同等参数规模下的计算量。Flash 能以 $0.14/M token 的价格运行，很大程度上就是 MoE 的功劳——284B 总参数，只要加载 13B 激活参数对应的计算图。
七、MoE 工程挑战
MoE 的好处说完了，来看真实工程中的硬骨头。
7.1 负载均衡
问题：如果所有 token 都往少数几个专家那里跑，其他专家几乎不被用到，MoE 就失去了意义。
这是 MoE 最经典的病。直观上可以理解：如果 384 个专家中只有 30 个被频繁使用，剩下的 354 个相当于"白训练了"。
V4 的负载均衡方案有三层：
第一层：辅助损失无关的偏置调整。每个专家有一个可学习的偏置 b_i，只在 Top-K 选择时生效。训练步结束时，过载专家偏置下调，欠载专家偏置上调。这是 V3 的成熟方案，V4 完整继承。
第二层：序列级平衡损失。V4 新增了一个轻量级的辅助损失，但不是全局的，而是在单条序列范围内。目的是防止一条序列中的 token 全部跑到同一个专家。这个损失的系数只有 0.001，远小于传统 MoE 辅助损失的系数（通常 0.01-0.1）。
第三层：Anticipatory Routing（预见路由）。这是 V4 在训练稳定性上的创新。当检测到 loss 异常升高时（通常是路由崩塌的前兆），系统会将路由更新与主干网络的更新解耦一步——先固定路由，让主干网络单独调整一步，再恢复同步更新。
Anticipatory Routing 触发流程
检测到 loss 异常升高
│
▼
冻结路由参数更新（停止调整专家偏置）
│
▼
运行一步主干网络更新（让模型先"喘口气"）
│
▼
恢复路由参数更新
│
▼
继续正常训练这种方法本质上是一个"安全阀"：当路由崩塌即将发生时，先让模型的主干部分稳定下来，再恢复路由调整。
7.2 通信开销
问题：MoE 的专家并行需要在 GPU 之间频繁传输 token 数据。
在一个 MoE 层中：
- Router 决定每个 token 分配给哪些专家
- Token 被发送到对应专家所在的 GPU（all-to-all 通信）
- 专家计算前向传播
- 结果被发送回原始 GPU（第二次 all-to-all 通信）
每层 MoE 都涉及两次全互联通信。V4-Pro 有 61 层，意味着 122 次 all-to-all。如果通信延迟不能很好地被计算延迟掩盖，模型就会"算一会、等一会"，吞吐量大幅下降。
V4 的解决方案有多个层面：
优化通信模式。DeepGEMM 库中的 MegaMoE 内核（下一节展开）将通信和计算完全重叠——在 token 被发送到其他 GPU 的同时，本地 GPU 已经开始计算自己负责的专家。通信和计算像是在"执行两个线程"。
减少通信数据量。FP4 量化使专家权重大小减半，同样减少了需要传输的中间表示大小。
硬件层面的优化。在 NVLink 连接的 GPU 集群上，all-to-all 通信带宽远高于 Ethernet。V4 在设计并行策略时优先利用同一节点内的 NVLink，减少跨节点的慢速通信。
V4 技术报告披露了一个数据：在 2048+ GPU 的集群上，MoE 通信开销占总训练时间的比例控制在 15% 以内。这个数字在万亿参数 MoE 模型中属于工程前沿水平。
7.3 专家坍缩（Expert Collapse）
问题：某些专家在训练过程中逐渐变得"懒惰"——它们被路由器选中的概率越来越低，最终几乎没有 token 经过它们。
专家坍缩比负载不均衡更严重：负载不均衡可以通过偏置调整来修复，专家坍缩意味着某些专家彻底"废了"——它们的参数不再被有效更新，因为梯度几乎为 0。
V4 应对专家坍缩的手段：
Hash-MoE 的前 3 层引导。浅层用固定路由确保所有专家都被使用到。虽然这些层的路由不直接影响深层，但好的底层表示降低了深层路由崩塌的概率。
SwiGLU Clamping。V4 对 SwiGLU 激活函数的输出做了钳位（clamping），限制 gate 分支的输出上限和 up 分支的下限。这个约束防止了某些专家因为偶然的激活值过大而被路由器"冷落"。
SwiGLU Clamping 的实现
gate_output = gate_proj(h)
gate_output = gate_output.clamp(max=swiglu_limit) ← 上限钳位
up_output = up_proj(h)
up_output = up_output.clamp(min=-swiglu_limit) ← 下限钳位
result = SiLU(gate_output) * up_outputswiglu_limit 是一个可调的超参数，V4 中默认设为 10。
偏置调整的兜底。如果某个专家的负载持续偏低，辅助损失无关策略会自动上调它的偏置，增加它被选中的概率。这在专家坍缩的早期阶段提供一个"重新激活"的机会窗口。
7.4 显存管理
问题：MoE 模型的总参数很大，在推理时需要加载全部参数到显存中，但一次只激活一部分。
V4-Pro 的 1.6T 参数，即使是 FP4 量化后的权重 + FP8 注意力参数的混合精度存储，也需要大约 800GB+ 的显存。这在单张显卡上是不可能的。
解决方案是多卡推断 + 专家并行：
把专家均匀分配到多张 GPU 上，每张显卡只需要加载自己负责的专家权重 + 所有注意力层权重（注意力层不做专家并行，因为其参数量相对较小）。在 8 张 H100 80GB 上跑 V4-Pro 推理时，每张显卡的显存分配大致是：
| 组件 | 显存占用 |
|---|---|
| 专家权重（FP4，本地 48 个专家） | ~200 GB → 分摊到 8 卡 ≈ 25 GB/卡 |
| 共享专家权重 | ~2 GB（全复制） |
| 注意力层 + 嵌入层 | ~15 GB |
| KV Cache（1M 上下文） | ~10 GB |
| 激活值（Activation Memory） | ~8 GB |
| 合计 | ~60 GB/卡 |
这是为什么 V4-Pro 需要在 8× H100 上跑，而 V4-Flash 可以在单张 80GB GPU 上运行——Flash 的 256 个专家更少、参数更小，单卡刚好装得下。
7.5 KV Cache 在 MoE 中的特殊处理
KV Cache 是推理时存储 Key 和 Value 的缓存，目的是避免重复计算。在 MoE 中，KV Cache 的处理更复杂：
KV Cache 和专家无关。KV Cache 存储的是注意力层的中间结果，专家层并不产生 KV Cache。所以从 KV Cache 的角度，MoE 和稠密模型的差别不大。
但专家并行影响 KV Cache 的访问模式。在专家并行的推理场景中，不同的 GPU 处理不同的专家，但注意力层是每张 GPU 完整的。这意味着 KV Cache 是全复制的——每张 GPU 都有一份完整的 KV Cache。在 1M 上下文场景下，这个复制带来的显存开销不可忽视。
V4 通过 CSA+HCA 来解决这个问题（下篇文章详细展开）。简单说，CSA 把 KV Cache 压缩到了原来的 1/4 到 1/128，大大减少了每张 GPU 上 KV Cache 的复制开销。V4-Pro 在 1M 上下文下的 KV Cache 只有 V3.2 的 10%。
八、MegaMoE 超级内核
8.1 问题的起源
MoE 的推理效率瓶颈往往不在计算本身，而在通信和计算的交织。
传统 MoE 推理的时序是这样：
步骤 1: 计算亲和度分数并选择 Top-K 专家
步骤 2: 将 token 分发到专家所在 GPU（all-to-all 通信）
→ GPU 等数据到达，空转
步骤 3: 专家前向传播：Linear 1 → SwiGLU → Linear 2
步骤 4: 将专家结果收集回原始 GPU（第二次 all-to-all）
→ GPU 再次等数据
步骤 5: 加权聚合输出这里有两个"空等"阶段——GPU 在等待通信完成。对于大型 MoE 模型，通信时间和计算时间可能相当，导致 GPU 利用率只有 50% 左右。
8.2 MegaMoE 的设计
DeepSeek 的 MegaMoE 内核（开源在 DeepGEMM 库中）解决这个问题的思路是：把通信和计算完全重叠起来。
具体来说，MegaMoE 将以下操作融合到一个"超级内核"中：
- Expert Parallelism 分发调度
- Linear 1（FP8 × FP4）
- SwiGLU 激活
- Linear 2（FP8 × FP4）
- Expert Parallelism 结果收集
传统方式（顺序执行）：
通信 → 计算 → 通信 → 计算
(分发token) (专家前向) (收集结果) (聚合输出)
▲ GPU 等 ▲ GPU 忙 ▲ GPU 等 ▲ GPU 忙
MegaMoE（重叠执行）：
通信 ────────┐
├── 同步计算 ────────┐
├── 同步计算
└──── 通信 ┘ └── 通信
▲ GPU 一直忙（通信在后台进行）在 MegaMoE 中，当一批 token 正在被发送到远程 GPU 时，本地 GPU 已经在计算本地专家需要处理的上一个 batch 的 token。NVLink 通信和 Tensor Core 计算在硬件层面并行执行。
8.3 性能数据
根据 DeepGEMM 的公开 Benchmark（PR #316），MegaMoE 在不同 batch size 下的加速比：
V4-Flash（256 专家，8 路专家并行）：
| Batch Size (token/rank) | 延迟 (us) | 计算吞吐 (TFLOPS) | 加速比 |
|---|---|---|---|
| 1 | 56.5 | 5 | 1.96x |
| 512 | 146.5 | 1056 | 1.73x |
| 8192 | 1283.1 | 1928 | 1.56x |
| 32768 | 4855.5 | 2038 | 1.62x |
V4-Pro（384 专家，8 路专家并行）：
| Batch Size (token/rank) | 延迟 (us) | 计算吞吐 (TFLOPS) | 加速比 |
|---|---|---|---|
| 1 | 108.1 | 7 | 1.61x |
| 512 | 369.6 | 1098 | 1.54x |
| 8192 | 2818.5 | 2304 | 1.50x |
| 32768 | 10655.2 | 2438 | 1.54x |
关键观察：
- 小 batch 场景加速比最大。单 token 推理时，通信开销占主导，MegaMoE 的重叠效果最明显（Flash 达 1.96x）。
- 随 batch size 增加，加速比略有下降。大 batch 时计算时间占比增加，通信重叠的空间缩小，但仍有 1.5x 以上的加速。
- 大 batch 时计算吞吐接近 2.4 TFLOPS。这是 8 卡 H100 的 FP8 矩阵乘法理论峰值的一个很高比例，说明 MegaMoE 的计算效率也非常出色。
8.4 工程实现细节
MegaMoE 的实现需要几个前提条件：
对称显存分配（Symmetric Memory）。MegaMoE 需要在所有参与的 GPU 上分配一个对称的缓冲区，用于存放待分发的 token 数据、专家索引和亲和度权重。API 调用示例如下：
# 分配对称显存缓冲区
buffer = deep_gemm.get_symm_buffer_for_mega_moe(
group, # GPU 通信组
num_experts, # 专家数
num_max_tokens_per_rank, # 每 rank 最大 token 数
num_topk, # 每 token 激活专家数
hidden, # 隐藏维度
intermediate_hidden # 专家中间维度
)
# 权重变换（FP4 → 特定布局）
transformed_l1 = deep_gemm.transform_weights_for_mega_moe(l1_weights)
transformed_l2 = deep_gemm.transform_weights_for_mega_moe(l2_weights)多进程启动。MegaMoE 需要多进程（multi-process）启动模式，因为通信和计算的重叠需要在不同的 CUDA stream 上执行。每个进程管理一个 GPU，通过 NCCL 进行跨进程通信。
FP8 × FP4 混合精度。MegaMoE 的线性层使用 FP8 激活输入 × FP4 专家权重的混合精度计算。这种非对称精度利用了 MoE 的特性：权重可以更激进地量化，因为每个专家只处理特定类型的输入，精度损失较小。
MegaMoE 已经在 vLLM 和 SGLang 两个主流推理框架中得到支持。vLLM 在 V4 发布首日就提供了 MegaMoE 的支持，SGLang 也紧随其后。
九、MoE 的未来方向
9.1 动态路由
当前的 MoE 路由是静态的——路由器的参数在训练完成后就固定了。这意味着推理时路由策略不会根据任务类型或用户行为做调整。
未来的方向是动态路由：
任务感知路由。根据任务类型（数学、编程、写作）动态调整路由策略。比如，在数学任务中优先调用"数学专家"，在编程任务中优先调用"代码专家"。这需要路由器在推理时接受任务标识作为额外输入。
在线负载自适应路由。根据当前 GPU 的负载情况动态调整路由策略——负载高时减少激活专家数，负载低时增加激活专家数。这在生产环境中非常实用，可以让服务在高峰期保持低延迟。
用户个性化路由。不同用户的使用模式不同。动态路由可以让模型为高频用户"定制"一组专家组合，从而改善体验。
这些方向的挑战在于：动态路由意味着模型在推理时的行为不确定，如何保证路由调整不会导致输出质量下降，是一个需要解决的问题。
9.2 专家复用
当前每个 token 独立选择专家。不同 token 可能选择完全不同的专家组合，即使它们在语义上高度相关。
未来的方向：
跨 token 专家共享。一个 batch 中相关 token 共享部分专家的计算结果。比如，在同一段对话上下文中，所有 token 共享"主题理解"专家的输出，只在"回复生成"阶段各自独立。
跨 batch 专家缓存。在连续推理请求中，缓存某些专家的输出状态，减少重复计算。这类似于 KV Cache 的思路，但推广到了专家层。
专家内存（Expert Memory）。最近的研究提出了一种"Engram Memory"概念——将专家的计算状态作为长期记忆保存下来，在后续推理中直接复用。这类似于给 MoE 模型加了一个"经验积累"的能力。
9.3 更极致的稀疏化
V4 的激活比例已经到了 3%（49B / 1.6T）。未来可能更低。
激活比例能降到多低？ 理论上，如果每个 token 只需要 1 个专家（Top-1），激活比例可以降到 0.26%（4B / 1.6T）。但 Top-1 路由会显著增加路由不稳定的风险——选错一个专家，整个 token 的处理质量都会下降。
中间方案是条件式稀疏化：简单 token 只激活 1-2 个专家，复杂 token 激活 6-8 个。这需要路由器能够评估输入本身的复杂度，动态调整激活数量。DeepSeek 的技术报告提到这一方向作为探索之一。
稀疏化在注意力层。MoE 已经让 FFN 层实现了稀疏激活。下一步是在注意力层实现类似的稀疏逻辑——CSA 的 Top-K 选择已经是一种初步的尝试。未来可能每个注意力头也是"按需激活"的，进一步降低注意力计算量。
9.4 硬件-架构协同设计
MoE 的进一步发展离不开硬件的配合。当前最明显的矛盾是：
通信带宽 VS 计算能力。MoE 的 all-to-all 通信要求 GPU 之间有高带宽连接。NVLink 的带宽增长已经放缓，而 GPU 的计算能力还在快速提升。这意味着 MoE 的通信瓶颈可能越来越严重。
几种可能的缓解方案：
更高效的通信模式。比如，层级化的 all-to-all 策略——节点内用 NVLink（高带宽），节点间用 InfiniBand（中等带宽），只在必要时跨节点通信。
计算-通信融合架构。MoE 和稠密模型的混合设计——某些层用 MoE，某些层用稠密，减少总体通信量。
硬件支持的稀疏计算。专门的硬件单元来处理稀疏激活的矩阵计算。NVIDIA 的 Hopper 架构已经引入了一些稀疏计算支持，但还不够完善。
小结
MoE 是 DeepSeek 从 V2 到 V4 一以贯之的核心架构选择。它让万亿参数模型变得可训练、可部署、可负担。
MoE 的精髓可以归结为一句话：不是让模型更大，而是让模型的"有效容量"更大。通过稀疏激活，模型总参数可以膨胀到 1.6T，但每次推理的计算成本只和 49B 激活参数相关。
DeepSeek 团队在 MoE 路线上做了三个关键贡献：
- 细粒度专家 + 共享专家隔离（V3）——让更多专家的组合更灵活，同时分离通用知识和专用知识
- 辅助损失无关负载均衡（V3）——解决了传统 MoE 辅助损失损害模型质量的问题
- Hash-MoE + Sqrt(Softplus) + FP4 量化（V4）——进一步降低了训练门槛、提高了路由质量、压缩了权重体积
V4-Pro 的 384 个专家、每 token 激活 6 个的设计，在当前的大模型格局下是一个平衡点：专家太少，知识容量不够；专家太多，通信开销和负载均衡难度急剧上升。实践证明，这个平衡选得很准。
如果你只能记住本文的三个要点，我希望是：
- MoE 的核心优势是参数量大但计算量小——1.6T 总参数的模型，推理成本只相当于 49B 稠密模型
- 路由器是 MoE 的灵魂，也是最脆弱的部分——路由不稳定会导致专家坍缩、负载不均衡等一系列问题
- V4 的 MoE 已经进化到第三代：从 V2 的试水，到 V3 的细粒度革命，再到 V4 的工程极致化——不是简单的堆专家数，而是路由策略、负载均衡、量化精度、计算通信重叠的全链路优化
检验标准
- [ ] 能用"专科医院"的类比向非技术朋友解释 MoE 的工作原理
- [ ] 能说出稠密模型和 MoE 模型在计算成本、通信开销、训练稳定性三个维度上的核心差异
- [ ] 能描述 DeepSeek V3 和 V4 在 MoE 层面的三个关键升级（路由策略、亲和度函数、量化精度）
- [ ] 能解释 Hash-MoE 为什么用于前 3 层，以及辅助损失无关负载均衡的基本原理
- [ ] 能理解 MegaMoE 超级内核的设计思路（通信-计算重叠）及其在什么场景下加速最明显
- [ ] 能说出 MoE 工程化的四个主要挑战（负载均衡、通信开销、专家坍缩、显存管理）及对应的 V4 解决方案