架构·密集型与 MoE：一对亲兄弟 ​

上篇说了 Transformer 是个"越大越烧钱"的主。你有没有想过：有没有办法，让模型"名义上很强、实际算起来很省"？

这就是 MoE 要回答的事。而它要对比的，就是我们天天在用的密集模型。这一篇，把这俩亲兄弟掰开揉碎讲清楚。

哥哥"密集型"（Dense）：老老实实，全员下场 ​

先看我们最熟悉的一类——密集模型（Dense）。GPT、Claude、Llama……基本都是这个路数。

它的工作方式特别朴素：模型里通常有一个巨大的"神经网络"，由几十亿、几百亿、甚至上千亿个"参数"组成。当它处理任何一句话时，这整个网络的每一个参数，几乎都要参与运算。

打个比方：

密集模型像一家公司，每次接到任务，全员几千号人一起上。 无论案子是大是小、是不是自己的专业，所有员工都得动起来。

这个"全员下场"的做法，带来两个直接结果：

优点：

• 效果稳定，实现简单，纯靠"量大"堆出智慧；
• 技术成熟，被全世界反复验证过最靠谱。

缺点：

• 又大又贵。模型越大，每次回答要算的东西越多，算力成本跟着飙涨；
• 想靠"继续加码"变大，成本是指数级往上走，很快就烧不起。

这就是为什么，当大家都想造"几万亿参数"的超级模型时，密集路线撞上了天花板——不是做不出来，是养不起。

弟弟"MoE"（混合专家）：按需叫人的公司 ​

MoE，全称 Mixture of Experts，翻译过来叫**"混合专家"**。它想得很务实——既然不是每次都需要全员，那我干嘛非要全员上场？

MoE 的结构，是把原本那个"铁板一块"的大网络，拆分成很多个相对独立的小"专家"模块，同时配备一个"路由器"（Router 也叫 Gating，门控）。

它工作时是这样的：

1. 收到一句话，路由器先快速判断：这句话大概是哪类问题，哪些专家最有发言权。
2. 只叫出最相关的两三个专家来真正算上一顿。
3. 其他专家，原地待命、不干活。

举例说明：

有个任务是"写一首关于夏天的诗"，路由器一看，"写诗"——就把"诗词方向的专家"叫来，其他人就在旁边围观。

关键点在于：这个模型虽然参数总量极大（可能几万亿），但每次推理，真正被激活、真正运行的只有一小部分。这就是它最迷人的地方——个头巨大，却只按需用力。

MoE 的"又大又省"到底怎么回事 ​

把参数总量和实际运行量分开想，就豁然开朗了：

• 总参数量大 → 它学的东西多，知识储备足，深度够；
• 运行时只激活一小部分 → 每次算的不多，成本就降下来了。

这就好比你一个机构编制名额很多、养了很多专家，但平时每个案子只点最对口的几名专家上场。论"规模"它是庞然大物，论"每次办事开销"它却不高。

于是，MoE 能用一个相对适中的成本，跑一个"名义上和顶级大模型一样大"的家伙。 这就是现在很多大厂新模型（像 DeepSeek、Mixtral、Qwen 的某些版本）爱用 MoE 的原因。

亲兄弟优缺点对照表 ​

MoE 的两个"藏得比较深"的坑 ​

MoE 看着完美，但它不是没烦恼。两个常见的毛病：

坑一：专家会不会"撞车"或"偷懒"？ 如果路由器不够聪明，可能老是把活儿派给同一个专家，其他人闲着——这叫负载不均衡。要么某些专家被累死，要么有的专家根本练不出来。所以 MoE 要花很多心思去调这个"路由器"。

坑二：得用专门的硬件/软件去伺候。 因为每次只激活一部分，常规的并行方式会"浪费"（要按最大激活量去预留资源），需要专门优化才划算。不在架构上花心思，MoE 的好处也显不出来。

小结 ​

• 密集模型：全家出动的老实人，效果稳但越大越贵。
• MoE：按需叫人的花架子高手，用拆专家+门控的办法，实现"又大又省"。
• 它们是 Transformer 底子上的两种"组织员工的方式"，不是两套完全不同的东西。

接下来还有一脉"狠人"——线性架构 不满足 Transformer 的底子，想从根上换掉它。去看看后浪们凭什么敢叫板祖师爷。