MoE 模型的训练和微调与传统 Dense 模型存在本质差异，其难点主要体现在三个方面：

• 专家路由的稳定性
• 稀疏激活下的数据分布偏移
• 微调过程中的专家坍塌（expert collapse）风险。

首先，路由机制在微调阶段极易失稳。
MoE 模型依赖一个可学习的 router 来决定每个 token 应该分配给哪些 expert。
在预训练阶段，模型通过海量数据学习到一个相对均衡的专家激活分布。
但一旦进入 Post-Training 阶段，训练数据量锐减、任务目标高度聚焦（如指令微调、工具调用、安全对齐等），router 很容易陷入“马太效应”——少数专家被频繁激活，而其他专家逐渐“失活”。
这种失衡不仅导致模型容量浪费，还会显著降低泛化能力。

其次，Post-Training 数据的稀疏性和任务特异性加剧了专家激活的偏态分布。
例如，在安全对齐任务中，模型可能反复面对相似的对抗性 prompt，router 会迅速收敛到某几个“安全专家”上，而忽略其他专家的能力。这种现象在量化、蒸馏等压缩场景中尤为严重。
已有研究表明，现有的 Post-Training Quantization（PTQ）方法在 MoE 模型上效果不佳，主要原因正是 calibration 数据无法覆盖所有专家的激活范围，导致部分 expert 的权重被错误量化。

第三，专家坍塌问题在微调中更容易发生。所谓专家坍塌，是指多个 expert 在参数空间中趋同，最终表现得像同一个模型。
这在预训练中可以通过大规模数据和正则化手段缓解，但在 Post-Training 阶段，由于数据量有限、优化目标单一，模型缺乏足够的信号来维持专家多样性。
一旦发生坍塌，MoE 的“稀疏增益”就名存实亡——你花了一万亿参数的存储成本，却只得到了一个 Dense 模型的效果。
为应对这些问题，一些团队开始尝试两阶段 Post-Training 策略：

• 第一阶段维持高多样性激活，防止专家失活；
• 第二阶段再聚焦任务目标进行精细化微调。

但这种策略对训练框架和调度逻辑提出了更高要求，尚未形成通用范式。

为什么 MoE 模型普遍只激活约 10% 的参数？

当前主流 MoE 模型（如 DeepSeek-V3、Qwen3-MoE、LongCat-Flash 等）的激活参数比例大多落在 6%–15% 区间，这并非偶然，而是由硬件约束、通信开销与模型性能之间的平衡所决定的。

• 从计算角度看，MoE 的核心优势在于“用空间换时间”：
  通过增加总参数量来提升模型容量，但每次推理只激活一小部分，从而控制计算量。
  然而，激活比例过低会带来严重问题。
  一方面，router 的决策误差会被放大——如果每个 token 只选 1–2 个 expert，而 router 判断错误，模型性能会断崖式下降；
  另一方面，极低的激活率会导致 expert 利用率极不均衡，大量 expert 长期闲置，造成存储和内存带宽的浪费。
• 从硬件角度看，现代 GPU/TPU 的计算单元需要足够的并行负载才能达到高利用率。
  如果每次只激活 1% 的参数（例如 1T 模型只激活 10B），计算密度太低，无法填满计算单元，反而导致吞吐下降。
  因此，10% 左右的激活比例是一个经验上的“甜点”：既能显著降低计算量（相比 Dense 模型），又能维持足够的并行度和 expert 多样性。
• 此外，通信开销也是关键制约因素。
  MoE 模型在分布式训练/推理时，expert 通常分布在不同设备上，router 决策后需要跨设备 gather 激活的 expert 输出。激活专家越多，通信量越大。但激活太少又会导致负载不均。
  因此，大多数系统设计会选择 top-2 routing（每个 token 激活 2 个 expert），配合总专家数在 64–128 之间，自然就落在了 10% 左右的激活比例。

为什么没有比 “30B 总参数、3B 激活” 更轻量的 MoE 模型？

不同总参数规模下 MoE 与 Dense 模型的推理吞吐对比曲线这个问题其实触及了 MoE 架构的“规模下限”问题。
表面上看，Qwen3-30B-A3B（30B 总参数，3B 激活）已经是一个相对轻量的 MoE 模型，但为何没有出现 10B 总参数、1B 激活的 MoE？
原因有三：

• 第一，MoE 的 overhead 在小模型上得不偿失。MoE 引入了 router、expert dispatch、all-to-all 通信等额外模块。在总参数量较小时（如 <20B），这些 overhead 占比过高，反而拖累性能。相比之下，一个 7B–13B 的 Dense 模型在同等硬件上推理更快、显存占用更低。
• 第二，expert 数量太少会导致路由失效。MoE 的优势依赖于“多个专家各有所长”。如果总参数只有 10B，假设用 8 个 expert，每个 expert 仅 1.25B，其表达能力远不如一个 3B 的 Dense 模块。此时 router 很难做出有意义的区分，模型退化为“带噪声的 Dense 模型”。
• 第三，训练稳定性难以保证。小规模 MoE 模型更容易出现 expert collapse 或负载不均。已有研究指出，当 expert 数量低于 16 时，模型性能对初始化和超参极度敏感。而 Qwen3-30B-A3B 之所以可行，是因为它在 30B 总参数下仍能配置足够多的 expert（例如 64 个，每个约 470M），从而维持路由的有效性。因此，MoE 并非“越小越好”，而是存在一个经济规模阈值。目前来看，30B 总参数、3B 激活可能是当前硬件和算法条件下 MoE 轻量化的下限。再往下走，不如直接用 Dense 模型 + 知识蒸馏或量化。

总而言之MoE 架构是大模型走向高效推理的关键路径，但其 Post-Training 阶段的稳定性、稀疏性与轻量化之间存在复杂的权衡。当前 10% 的激活比例是硬件、算法与工程实践共同作用的结果，而更轻量的 MoE 模型受限于架构 overhead 与 expert 多样性门槛，短期内难以突破。未来或许可以通过动态 expert 数量调整、跨层 expert 共享、或 hybrid Dense-MoE 混合架构来进一步优化这一平衡，但这需要底层框架和训练范式的协同创新。