MoE++：用「零计算专家」重新定义混合专家模型效率

从「专家都干活」到「能者多劳」：大模型推理的瓶颈与破局

想象一个创业公司里有100位专家，但每个客户只能分配给2位专家接待。在传统的混合专家模型（MoE）中，这100位专家每次都要激活、都要计算——哪怕某些专家只是负责说「这个我不管」这样完全不需要计算的操作。这种「专家空转」现象，在大模型推理时造成了大量算力浪费。

SkyworkAI 团队在 ICLR 2025 发表的工作 MoE++（Zero-Computation Experts）正是针对这一问题提出了系统性解决方案：通过引入三种「零计算专家」，让简单token（常见词、词根片段）不再浪费GPU算力，而将宝贵的计算资源留给真正复杂的语义处理任务。

项目背景与学术渊源

MoE++ 由 SkyworkAI 团队开发，核心作者包括 Peng Jin、Bo Zhu、Li Yuan（通讯作者）、Shuicheng Yan 等多位深度学习领域知名学者。该团队同时维护了 Chat-UniVi（CVPR 2024 Highlight）和 MoH（Multi-Head Attention as MoH）等相关工作，构成了一个围绕稀疏激活机制的技术体系。

项目基于 Skywork-MoE 训练框架构建，推理代码基于 HuggingFace transformers 库。2024年10月8日发布模型权重和推理代码，GitHub 至今已获得270星、12个fork，反映出学术社区对稀疏激活机制的持续关注。

核心创新：三种零计算专家

MoE++ 的核心洞察是：并非所有 token 都需要消耗等量的计算资源。简单 token（如常见词、词缀片段）的语义相对简单，应该走「捷径」；复杂 token（如专业术语、多义词）才需要动用专家网络进行深度语义分析。

基于这一洞察，MoE++ 设计了三种零计算专家：

专家类型	计算操作	作用
Zero Expert	完全丢弃（输出全零向量）	等同于 skip，让 token 直接进入下一层
Copy Expert	直接复制输入（恒等映射）	替换操作，适用于简单 token
Constant Expert	用可学习的常量向量替换	更智能的替换，带参数优化

每种零计算专家都几乎不产生参数存储开销（Zero Expert 和 Copy Expert 参数为零），而 Constant Expert 仅需一个 hidden_size 维的向量，远小于传统 FFN 专家（intermediate_size = 11008）的参数量。

Gating 机制与残差门控

MoE++ 的路由机制（Router）使用 top-k 策略选择专家，其核心逻辑在 moe_plus_plus_layer.py 中实现：

# 核心门控逻辑（moe_plus_plus_layer.py）
gates, indices = torch.topk(logits, k=MOE_TOP_K, dim=1)
gates = F.softmax(gates, dim=1)
# 最后一个专家位置（零计算专家）权重置零
# 重新归一化剩余权重
gates /= torch.sum(gates, dim=1, keepdim=True)

关键设计：零计算专家被放在专家列表的最后一位，通过 torch.where 将其路由权重清零——这是一种优雅的机制复用，无需修改路由器架构，只需在归一化前过滤掉零计算专家的贡献。

Gating Residuals（门控残差） 是另一核心创新：将上一层的路由决策信息（token 走过了哪些专家路径）引入当前层的门控计算，帮助模型建立跨层语义关联，同时有效降低路由分数的方差，使路由决策更加稳定可靠。

架构实现：从配置到模型

MoE++ 基于 LLaMA 架构改造，核心代码结构如下：

• configuration_moe_plus_plus.py：自定义 MoeConfig，继承自 PretrainedConfig，包含 num_experts、moe_expert_interval、moe_2layer_gate、moe_use_logits_norm 等专属超参数
• moe_plus_plus_layer.py：实现了 ZeroExpert（无参数）、CopyExpert（无参数）、ConstantExpert（hidden_size 维可学习参数 + 线性层）、Router 和 MOE 核心层
• modeling_moe_plus_plus.py：约41KB，基于 transformers 库重写了完整的 LLaMa 模型，包含 rotary embedding、RMSNorm、注意力机制和 MoE++ 专属的 MoE 解码器层

默认配置使用 32个FFN专家 + 零计算专家，每层激活2个专家（top-k=2），模型总参数量7B，激活参数约为传统Dense模型的1/4。

上手体验：HuggingFace 推理

对于普通开发者，MoE++ 的使用非常简洁，基于 HuggingFace transformers 库：

from transformers import AutoModelForCausalLM, AutoTokenizer

model = AutoModelForCausalLM.from_pretrained(
    "Chat-UniVi/MoE-Plus-Plus-7B",
    trust_remote_code=True,
    device_map='auto'
)
tokenizer = AutoTokenizer.from_pretrained(
    "Chat-UniVi/MoE-Plus-Plus-7B",
    trust_remote_code=True
)

inputs = tokenizer("Hello!", return_tensors='pt').to(model.device)
response = model.generate(inputs.input_ids, max_length=128)
print(tokenizer.decode(response.cpu()[0], skip_special_tokens=True))

评估基准测试同样简洁，基于 EleutherAI 的 lm-evaluation-harness：

CUDA_VISIBLE_DEVICES=0,1,2,3,4,5,6,7 accelerate launch \
  --main_process_port 2004 -m lm_eval --model hf \
  --model_args pretrained=Chat-UniVi/MoE-Plus-Plus-7B \
  --tasks winogrande \
  --batch_size 1

硬件需求方面，7B 模型推理约需14GB+显存（FP16），建议使用 A100/H100 等高端 GPU。

实验结论与性能收益

MoE++ 的实验结果表明，在相同的激活参数预算下，MoE++ 相比标准 MoE 模型在常识推理（Winogrande）、阅读理解（HellaSwag）、问答等基准上均有明显提升。更关键的是，其 专家前向吞吐量提升了1.1~2.1倍：

• 简单 token（词根片段、常见词）激活FFN专家数 < 1.5个
• 名词平均激活1.5~1.7个FFN专家
• 动词（语义丰富）平均激活接近上限2个FFN专家

这种差异化的计算分配验证了 MoE++ 的核心假设：让简单任务走捷径，把算力留给真正困难的问题。

局限性与开放问题

尽管 MoE++ 在推理效率上取得显著突破，但也存在以下局限：

训练代码未开源：团队明确表示训练代码基于 Skywork-MoE 框架，在获得授权批准前无法单独开源。这意味着学术复现者只能依赖预训练权重，无法从零训练自己的 MoE++ 变体。

分布式部署复杂度：尽管零计算专家解决了GPU间通信开销问题（可全部放在各GPU上），但完整 FFN 专家的分布式路由在超大规模（>8专家）场景下仍是工程难题。

Chat模型仍在开发中：当前仅开源了7B Base模型，MoE++7B-Chat 对话模型标注为「Coming Soon」，社区期待的指令微调版本尚未发布。

行业意义：从学术顶会走向工程落地

MoE++ 的价值不仅在于单个论文的算法创新，更在于它代表了一条清晰的工程路径：稀疏激活不是目的，让计算资源精确匹配任务难度才是。在算力成本持续攀升、大模型推理效率成为核心竞争力的当下，MoE++ 的思想为下一代高效Transformer架构提供了重要参考。

随着更多稀疏激活工作（如 MoH、Skywork-MoE）的持续推进，一个围绕「差异化解码」的模型设计范式正在形成。MoE++ 作为这条技术主线上的重要节点，值得 AI 研究者和工程师持续关注。

---

本报告基于项目 GitHub 仓库 v1.0（2024年10月）及 arXiv:2410.07348 论文撰写