大模型架构

混合专家架构是过去两年大模型效率竞赛的主角：总参数量做到几千亿甚至上万亿，但每次推理只激活其中一小部分，于是推理成本接近小模型，能力却接近大模型。这笔账在纸面上非常漂亮，落地之后才发现，路由、负载均衡、显存占用这些隐性代价正在吃掉理论效率。 稀疏激活的效率账到底怎么算？ 稠密模型每生成一个 token，所有参数都参与计算；MoE 模型每次只激活两到四个专家，于是单次前向的计算量大幅下降。但总参数量膨胀带来的是显存占用——你必须把所有专家都装在显存里，哪怕每次只用其中几个。结果是推理卡的显存墙先于算力墙成为瓶颈。很多 MoE 模型理论上更便宜，但实际部署需要更大显存的卡，单位 token 成本并没有纸面那么低。 路由质量为什么决定了模型上限？ Router 负责把每个 token 分配给最合适的专家。如果路由错了——把数学 token 分给了写故事的专家——这个 token 的处理质量就会下降，误差会累积。更隐蔽的问题是路由坍缩：某些专家被过度使用，另一些被冷落，模型多样性丧失。为了对抗这个，训练时要加负载均衡损失，强迫专家被均匀使用。但这个损失又会和主任务损失打架，调起来非常敏感。论坛里 架构讨论 的高频话题，就是各家怎么调这个平衡。 MoE 会取代稠密模型吗？ 短期不会全取代。MoE 在训练大模型、追求参数容量时优势明显，但在小模型、边缘部署、低延迟场景下，稠密模型因为结构简单、无路由开销、易量化，仍然更划算。一个合理的未来是：云端旗舰用 MoE 榨干规模红利，端侧用蒸馏出的稠密小模型。两条路线不是替代关系，而是分工关系。 MoE 的教训是，「总参数量」这个数字本身具有误导性。真正决定成本和能力的，是激活参数、路由质量、以及你愿为这些专家付出多少显存。 MoE 的合并部署为什么这么难？ 理论上 MoE 每次只激活几个专家，应该比稠密模型省算力，但工程上它的显存和通信开销被长期低估。所有专家都要常驻显存，路由还要在专家之间动态调度，跨卡通信量巨大。为了压成本，研究者尝试把多个专家合并蒸馏成一个稠密小模型，结果往往是部署简化了，但也丢掉了 MoE 的容量优势。MoE 的真正出路，可能不是继续扩大专家数量，而是在路由效率和显存分层上做精细化工程。 说到底，MoE 不是免费的午餐，它把成本从推理时转移到了显存和通信侧，又把复杂度从模型本身转移到了路由工程。谁能把这笔账算细，谁才能真正吃到稀疏激活的红利。 去论坛讨论 前往 silicon-agi.com 论坛 参与讨论。