混合专家（MoE）架构近年成为大模型领域的主流选择，其核心价值在于打破了传统稠密模型“参数越多，计算越贵”的线性关系。以腾讯最新开源的 Hy4 preview 为例，总参数量达到 7700 亿，但每次推理仅激活 490 亿参数，这种“大而稀疏”的设计，正是 MoE 平衡容量与成本的典型实践。
理解这一平衡的关键在于 MoE 的“条件计算”机制。传统 Transformer 模型每一层都会调用全部参数，参数量与计算量直接绑定。而 MoE 模型在每一层中设置了多个“专家”子网络，并引入一个门控路由网络，由它根据输入 token 的特征，动态选择激活哪几个专家。这意味着，无论总参数量有多大，单次推理只计算被选中的那一小部分专家，计算成本几乎不随总参数规模增长。Hy4 preview 的 7700 亿参数分布在多个专家中，但激活参数仅占总量的约 6.4%，便是这种稀疏激活的直接体现。
不过，MoE 的容量与成本之间并非简单的“越大越好”。总参数规模决定了模型的知识存储上限，即“容量”；而激活参数规模决定了单次推理的计算负载，即“成本”。如果专家数量过多或路由策略设计不当，会出现两个典型问题：一是“专家坍缩”，即路由网络倾向于把大部分 token 分配给少数几个专家，导致其他专家未被充分利用，模型容量被浪费；二是通信瓶颈，在分布式训练和推理中，专家分布在不同的 GPU 上，token 需要跨设备路由，这部分通信开销会侵蚀稀疏激活带来的计算优势。Hy4 preview 采用 78 层骨干网络，第一层使用稠密前馈网络，其余层使用 MoE 结构，这种混合设计本身就是一种工程上的折中——在早期层保留稠密结构以稳定特征提取，在深层通过 MoE 扩展容量。
从成本控制角度看，MoE 的真正优势在于“按需分配计算”。对于简单查询，模型只需激活少量专家即可给出合理响应；对于复杂推理任务，则可以激活更多专家来获取更高精度。Hy4 preview 提供的“high”与“no_think”两种推理模式，本质上是利用 MoE 的灵活路由特性，让用户在推理质量与延迟之间做选择。这种弹性能力对于企业部署至关重要——在 API 调用场景中，用户无需为每次请求支付完整模型的计算成本，而是根据任务复杂度按需付费。
MoE 架构并非没有代价。模型总参数量的膨胀导致显存占用大幅增加，即使单次推理计算量不大，完整参数仍需要加载到内存中。这意味着部署 MoE 模型对显存带宽和容量有更高要求，推理服务器需要更谨慎地设计 expert placement 和缓存策略。此外，MoE 的训练难度也高于稠密模型，路由网络的收敛、负载均衡的维护、专家之间的协作，都需要额外的训练技巧。
当前头部大模型普遍选择 MoE，本质上是在做一个权衡：用更大的显存开销换取更优的计算效率，用更复杂的训练流程换取更高的容量天花板。对于企业技术选型而言，关注的重点不应只是总参数量这个数字，而应落在激活参数、专家数量、路由策略和推理模式等具体工程细节上，这些才是决定实际部署成本和效果的关键变量。