去年有个朋友问我为什么同样是百亿参数的大模型DeepSeek跑起来就是比别人快。我当时正在吃饭筷子夹着一块回锅肉想了半天说了句“你家里请了八个保姆但同时干活的只有两个剩下六个在旁边喝茶。”这个比喻不太尊重保姆这个职业但它确实是我能想到的最直观的解释DeepSeek MoE架构的方式。MoEMixture of Experts混合专家模型。这名字取得挺唬人听着像是某个跨国咨询公司的组织架构。实际上它的核心逻辑朴素到让人怀疑为什么直到最近几年才被广泛采用与其让整个模型处理每一个token不如训练一堆“小专家”每次只激活其中几个。DeepSeek-V2把这个思路做到了极致。总参数量236B但每次推理只激活21B。这个比例在业内算是相当激进的。作为对比Mixtral 8x7B总参数46.7B激活12.9B差不多激活四分之一强。DeepSeek把激活比例压到了不到十分之一。这意味着什么意味着你看到的那个236B的庞大数字大部分时候只是在硬盘上安静地躺着。真正的计算发生在那一小撮被选中的专家身上。那问题来了怎么选专家这就是DeepSeek论文里让我盯着看了二十分钟的那部分门控机制。传统的MoE门控说白了就是个分类器看哪个专家顺眼就发给谁。DeepSeek在此基础上做了几件事。第一件他们引入了共享专家。所有token无论如何都会经过这部分。你可以理解为通识教育不管你是学物理的还是学历史的数学总得会一点。这部分参数不多但能保证模型在基础能力上不翻车。第二件细粒度专家分割。传统MoE可能就8个专家DeepSeek-V2把这个数字拉到了160个。每个专家更小更专。好处是组合方式更多样泛化能力更强坏处是门控网络的压力暴增——你得从160个候选里挑出最合适的几个还不能挑错了。第三件也是我觉得最有意思的是他们设计了一种负载均衡损失让专家们尽量“均匀地忙”。做过分布式系统的都知道负载均衡说起来容易做起来难。有的专家天生就是热门——比如处理“the”“a”这种高频词的专家请求量大到爆炸有些专家可能冷冷清清。如果不加干预训练到最后你会发现有几个专家累死了其他专家在那儿打麻将。DeepSeek的解决方案不是强制分配而是通过辅助损失函数温柔地引导。训练过程中模型被鼓励把token分给相对冷门的专家同时又不至于为了均衡而均衡导致路由质量下降。这个平衡点找得相当有水平。我个人猜测DeepSeek团队在这个门控机制上花了大量时间调参。因为MoE的训练稳定性一直是个大问题。你训着训着突然发现某个专家的梯度爆炸了或者某个专家完全不更新了。这种情况在单卡训练大模型的时候很少遇到但在MoE架构里简直是家常便饭。他们应该还有一个没有在论文里详细展开的技巧专家权重的初始化策略。MoE对初始化极其敏感稍有不慎就会导致专家坍缩——所有token都往一两个专家那里挤剩下的一百多个专家形同虚设。从最终效果来看DeepSeek的初始化策略相当成功。说到实际体验我拿DeepSeek-V2跑过一些需要复杂推理的任务。最直观的感受是它的“犹豫”时间很短。传统的大模型在生成复杂回答前会有一段微妙的停顿那是整个模型在处理上下文。DeepSeek的响应曲线更平滑我猜这跟激活参数少、计算路径短有直接关系。但MoE也不是没有代价。最大的问题是显存占用。虽然每次只激活21B参数但236B参数都得在显存里待着因为你不知道下一秒会激活哪个专家。这意味着部署门槛其实没怎么降——你依然需要能装下236B参数的硬件。DeepSeek在这件事上做了模型量化方面的优化但物理定律摆在那里该花的钱还是得花。另一个隐忧是微调。MoE模型的微调难度比稠密模型高一个量级。全量微调236B参数不现实LoRA微调又要面临“微调哪些专家”的选择题。我见过一些社区尝试用LoRA微调MoE模型然后踩坑的帖子最常见的问题就是微调完后发现模型在特定任务上反而退化了因为微调破坏了专家之间的协作平衡。不过这些问题跟MoE带来的效率提升相比我觉得是值得的。尤其是在推理成本越来越成为瓶颈的当下MoE几乎是目前性价比最高的方案。DeepSeek在这条路上走得相当靠前而且从V1到V2的迭代速度来看他们对这套架构的理解已经相当深入。最近听说他们在研究进一步稀疏化MoE让激活参数占比更低。如果真的能做到总参数的二十分之一甚至三十分之一激活那算力成本的账就要重新算了。当然这是后话等真有成果出来再聊。