混合专家模型（MoE）已经是当前大模型的主流架构。Qwen3、DeepSeek V3、Mixtral这些名字，背后都是MoE。它的设计逻辑很清楚：把模型拆成多个"专家"子网络，每次只激活其中一部分，用更少的计算量维持更大的模型容量。

但这个设计有一个长期被忽略的问题：模型在预训练阶段学到的专家分布，在迁移到特定领域时，效率会明显下降。

预训练的专家，在专业场景下可能有一半是闲着的

最近一篇来自arXiv的论文提出了一个直观但一直没被系统验证的观察：MoE模型中的专家并不是每个领域都能均衡使用。在通用预训练阶段，模型接触的数据范围极广，各个专家都有用武之地。但当模型被用于某个特定领域——比如数学推理或代码生成——部分专家几乎不贡献有意义的信息。

论文给出了一组具体数据：在用Qwen3-30B-A3B和Qwen3.5-35B-A3B两个MoE架构进行测试时，标准的监督微调（SFT）不会改变专家的组成结构。那些在目标领域贡献低的专家，微调之后依然贡献低。模型的计算资源被浪费了。

这个问题的影响比看起来要大。MoE的优势在于"用更少的计算做更多的事"，如果一部分专家实际处于半闲置状态，那这个优势就在打折。而且这种情况随着模型规模的增大可能更严重——专家越多，无效路由的概率越高。

UMoE的思路：剪掉不用的专家，再重新生长

论文提出的方法叫UMoE，逻辑很直接。在领域微调之前，先对专家池做一次"整理"：

第一步，评估每个专家在目标领域的重要性。用领域数据的激活特征作为信号，给每个专家打分，分低的标记为不相关。

第二步，剪掉打分最低的那些专家。这一步不是为了减小模型——模型参数总量会恢复——而是为了清理出空间。

第三步，用扰动式扩展重新生长被剪掉的专家。通过引入少量随机扰动，生成一批新的专家参数，替换掉那些低价值的专家。然后在新的专家池上做标准的监督微调。

整个过程不需要针对每个领域调超参数，一套流程跑通所有场景。更重要的是，推理时的计算成本和原始模型完全一致——参数量没变，激活的专家数也没变。

实验数据上，这个方法在数学任务上平均提升3.4个百分点，在SWE-bench Verified上提升了6.0个百分点。在团队内部构造的强数学训练集上，直接微调已经超过了Qwen3-30B-A3B的思考版本（82.81对比81.06），而UMoE进一步将平均分提高到84.17。

一个值得关注的细节

数据扩展实验显示，UMoE的提升并不会随着训练数据的增加而消失。这意味着它解决的不是数据不足的问题，而是专家分配的固有问题。即使训练数据继续增多，原始模型中被浪费的专家容量仍然存在，UMoE通过将这部分冗余容量转化为有效的领域容量，持续产生价值。

对开发者而言，这个工作的实际意义在于：如果你正在基于某个MoE模型做领域微调，默认的微调方式很可能没有充分利用模型的计算资源。不是模型不够大，而是模型的计算没有分配到最需要它的地方。在部署成本越来越敏感的今天，这种资源利用效率的优化，可能比追求更大的模型有意义得多。

关于维基框架

维基框架关注企业应用开发中的长期维护问题。在实际项目中，业务系统往往同时涉及权限、微服务、接口协议、部署环境等复杂因素，因此我们希望提供一套更容易扩展和维护的基础框架。

官网：framewiki.com

Gitee：gitee.com/wiki-framework

GitHub：github.com/wiki-framework

示例项目：gitee.com/cdkjframework/framewiki-example

📄 许可证：MulanPSL-2.0（木兰宽松许可证，第2版）