MoE 已经不是少数模型的专属标签，但“都是 MoE”并不意味着“都差不多”。MarkTechPost 做了一件看似基础、实则少有人系统整理的事：基于各模型公开的配置文件，逐一核对 10 款开源 MoE 模型究竟怎样把 token 分配给专家。
发生了什么
这篇对比覆盖 DeepSeek、Qwen、Mixtral、Llama 4、gpt-oss 等模型家族，逐项列出它们的总参数量与激活参数量、专家总数、每 token 选中的专家数（top-k）、是否设置共享专家、门控函数形式，以及采用的负载均衡方法。所有结论以配置文件为准，而非二手转述或论文描述，这一点让对比具备了可复核性。
为什么重要
MoE 的核心承诺是“用更大的总参数换取更低的单次推理成本”，但这一承诺能否兑现，几乎完全取决于路由设计。top-k 决定每个 token 要激活多少计算；共享专家承担通用能力，让路由不必把所有知识都压在稀疏专家上；门控函数决定分配是软是硬；负载均衡则直接关系到训练能否稳定、专家是否被浪费。
这些选择叠加起来，塑造了模型的能力分布和部署成本。两个总参数相同的 MoE 模型，如果 top-k 和共享专家策略不同，实际算力开销和显存占用可能相差明显。对使用者而言，只看“总参数”和“激活参数”两个数字，很容易对模型的真实运行成本产生误判。
影响与看点
对开发者来说，这份对比的价值在于把选型依据从营销数字拉回到工程细节：部署时该按激活参数估算吞吐，还是按总参数估算显存，答案藏在 top-k 和专家粒度里；微调时共享专家与稀疏专家的处理方式，也会影响训练策略。
对行业而言，各家在路由上的分歧说明 MoE 远未收敛为标准化方案，负载均衡这类工程问题仍是拉开差距的地方。值得关注的是，随着 gpt-oss 这类模型加入开源阵营，路由设计是否会像注意力机制一样逐步趋同。我的判断是：短期内不会，因为路由选择本质上是在成本、稳定性与能力之间做取舍，而各家对这三者的优先级并不一致。
