混合专家（MoE，Mixture of Experts）是一种“不是每次都让整套模型一起上”的模型架构。它最关键的特点，是把模型里的某些层拆成多个专家模块，再由一个路由器决定当前 token 该走哪些专家。这样模型总参数可以做得很大，但一次真正参与计算的参数没那么大，所以你才会看到很多热门模型写着几十 B、上百 B 参数，实际激活参数却小得多。
如果把普通稠密模型想成一家每次全员开会的公司，MoE 更像“先看问题属于哪个部门，再叫相关专家进会议室”。并不是所有专家都处理每个输入。对模型来说，这意味着容量可以扩张，但单次推理的计算不一定线性暴涨。
这也是 MoE 这两年一直热的根本原因。大家既想把模型做大，提升知识容量和任务上限，又不想让推理成本跟着失控。MoE 提供了一条中间路线：参数规模上去，激活计算尽量收着。像 Mixtral 一类模型之所以能带动 MoE 讨论，就是因为它让更多人直观看到了“总参数”和“活跃参数”并不是一回事。
不过，MoE 不等于白送性能。它的关键难点在路由。路由器要决定每个 token 去找哪个专家，既要让专家各自形成专长，又不能出现某几个专家天天爆满、其他专家闲着的情况。为了避免这种失衡，训练时通常还要加负载均衡相关设计。很多 MoE 模型真正难的地方，不在概念，而在把训练稳定性和工程效率做好。
MoE 还有一个很容易被误解的点：它省的主要是“每次激活的计算”，不是把部署难度也一起省掉。专家多了以后，显存占用、分布式通信、推理调度都会更复杂。尤其在多卡环境下，专家怎么切、怎么同步、怎么减少通信开销，往往决定了 MoE 到底是提效还是添堵。
所以看见一个模型写自己是 MoE，不要只盯着参数数字。更值得问的是三件事：每个 token 会激活几个专家；训练和推理是不是稳定；团队有没有对应的基础设施去跑。没有这些条件，MoE 的账不一定算得过来。
MoE 也不适合被神化。它不是“比 Transformer 更先进”的单向替代，而是 Transformer 体系里的一个扩容策略。很多模型会在一部分层用 MoE，其他部分仍然是常规结构。换句话说，它更像是在大模型时代解决扩展性和成本矛盾的一种工程化答案。
今天 MoE 之所以仍然是热门词，不只是因为论文多，而是因为大家终于开始认真算推理成本和部署收益了。当模型越来越大、算力越来越贵时，“让哪些参数真正参与这次计算”本身，就成了最现实的问题。
