一、引言：参数想涨，钱扛不住，于是有了 MoE#

论文开头的背景很简单：大语言模型喂的数据够多时，参数越多、算力烧得越狠，模型越强，这条 scaling law 被反复验证过。但难处也在明面上，把模型推到极大规模，算力账单吓人。MoE 就是在这个节骨眼上出场的。

MoE，全称 Mixture-of-Experts（混合专家）。核心思路是”有条件地计算”：账面上总参数很多，但每个 token（词元）只激活一小部分。打个比方，一个大公司，部门挂了很多牌，但一份活儿只叫两三个部门来干，其余部门闲着。这样员工名单很长，实际发工资的人少，成本就压下来了。

但老办法有毛病。主流 MoE 架构（典型就是 GShard）用 top-K routing（路由），每个 token 挑亲和得分最高的 K 个专家。这条路带出两个问题，论文各给了一个名字：

一是 knowledge hybridity（知识混杂）。专家数量少时，分到同一个专家的 token 七零八落、什么知识都有，专家被迫把一堆不搭界的东西塞进同一组参数，用起来互相打架。

二是 knowledge redundancy（知识冗余）。分到不同专家的 token，往往要的是同一类公共知识，结果好几个专家各存了一份，参数白白重复。

两个毛病叠一起，就是专家不专。每个专家没攒下自己独有的东西，MoE 的水平就上不去。DeepSeek 的回应是两招：把专家切细，再把一部分专家划成公共的。

二、预备知识：MoE 那套公式，其实就一句话#

第二章很短，讲的是标准做法：把 Transformer 每一层的 FFN（Feed-Forward Network，前馈网络）换成 MoE layer。每个 token 对每个专家算一个亲和分数，softmax 归一化，取 top-K，只有这 K 个专家的输出参与加权求和。这个门控（gating）是稀疏的，K 远小于专家总数，算力就是这么省的。公式不用背，记住”每个 token 只走 K 个专家”就够了。

三、核心架构：两招，外加一个平衡#

第三章是论文的心脏，讲 DeepSeekMoE 自己那套。

第一招，细粒度专家切分（fine-grained expert segmentation）。 做法很朴素：把每个专家 FFN 的中间隐层维度砍到原来的 1/m，一个专家就变成 m 个小专家。算力要保持不变，那激活的专家数就跟着乘以 m，原来激活 2 个，现在激活 2m 个。

论文给了一个特别直观的数字。假设总共 16 个专家，用传统 top-2 路由，能组合出 C(16, 2) = 120 种组合。把每个专家切成 4 份，变成 64 个小专家、激活 8 个，组合数一下子成了 C(64, 8)，等于 4,426,165,368，44 亿多种。同一个 token 能撞上的专家组合多了几个数量级，路由就能给每个 token 配一组更精准的人。知识被拆得越细，各自落进更小的专家，每个专家只装一类东西，专业度自然就上去。

第二招，共享专家隔离（shared expert isolation）。 思路是，既然很多 token 都需要公共知识，与其让每个专家各存一份，不如单独划出 Ks 个共享专家，所有 token 无条件下发，专门吃公共知识。剩下的 routed experts（路由专家）只管各自的专长，不用再重复存公共货。参数效率上来，冗余下去。论文也老实交代，这个想法原型出自 DeepSpeed 那边 Rajbhandari 等人的工作，只是人家从工程角度做，DeepSeek 从算法角度重新做了一遍。

第三小节是负载均衡（load balance）。学出来的路由有个坑，叫 routing collapse（路由崩溃）：模型偷懒，总选那几个顺手的专家，别的专家喂不到训练，慢慢废掉。所以论文加了 expert-level balance loss（专家级均衡损失），防少数专家霸榜。到大规模多卡时，又加一个 device-level balance loss（设备级均衡损失），只管设备之间算得匀，不强求专家之间绝对平均，因为专家级管得太死会伤性能。

四、2B 验证：小模型，大结论#

第四章在小模型上验证。先训一个 2B 的 DeepSeekMoE：1 个共享专家加 63 个路由专家，激活其中 7 个。拿 100B tokens 训，在 12 个 benchmark 上测（摘要口径，正文实验列表实为 11 个）。

结果很能说明问题。同样 2B 总参数，DeepSeekMoE 把 GShard 2B 甩开一大截；甚至追平了 GShard 2.9B，那可是专家参数和算力都多 1.5 倍的大家伙。同一笔算力，换套架构，白赚一截性能。

更狠的是跟稠密模型比。MoE 总参数再多，能力也有个理论上限，就是同规模、不稀疏的稠密模型（dense model）。论文拉出 Dense×16，专家部分相当于 16 个标准 FFN 的稠密模型，DeepSeekMoE 2B 几乎追平了它。等于说，至少在 2B 这个规模、100B tokens 这个数据量下，MoE 的性能天花板快被摸到了。

消融实验（ablation）把两招分别拿掉验证：共享专家确实有用；专家切得越细越好，从 16 个（GShard 基线）到 32 个到 64 个专家，性能一路在涨。共享和路由专家的比例也做了消融：在 64 个总专家里分别隔离 1、2、4 个共享专家（对应激活比例 1<7>、1<3>、1<1>），差别不大，其中 1<3> 的 Pile loss 最优（1.806），放大时采用 1<3>。往更大规模推，把总参数加到 13.3B 时，DeepSeekMoE 甚至能明显反超专家参数和算力都多 1.5 倍的 GShard×1.5，说明”细粒度+共享”这套设计的优势在大规模下同样成立。

4.5 节那个”专家专业化分析”是整篇论文里很有代表性的地方，它把”专家到底专不专”做成了实验。做法是把路由得分最高的那些专家屏蔽掉，看 loss 怎么变。DeepSeekMoE 对屏蔽 top routed experts 非常敏感，loss 掉得飞快。这恰恰说明它的专家不可替代、冗余低。反过来 GShard 不敏感，屏蔽几个还能扛住，因为它的专家之间知识重叠多，换谁上都能顶一阵。

还有一个数字能看出共享专家的分量：把那个共享专家拿掉，改成多激活一个路由专家，算力不变，Pile 的 loss 从 1.808 直接跳到 2.414。一个专家，顶半边天。它装的是基础性的公共知识，路由专家替代不了。

最后一击：从零训练一个只激活 3 个路由专家的模型，激活参数只有 GShard 的一半，照样赢 GShard。这说明 DeepSeekMoE 激活出来的那部分参数，有效占比远高于 GShard。

五、放大到 16B#

有了 2B 的底，第五章放大。16B 总参数，2T tokens 训练，2 个共享专家加 64 个路由专家，每个 token 走 2 个共享、6 个路由。

结果：DeepSeekMoE 16B 用大约 40% 的算力追平自家稠密的 DeepSeek 7B；对 LLaMA2 7B 更漂亮，算力只有对方的 39.6%，多数 benchmark 反而赢。数学和代码更强，中文 benchmark 大幅领先，毕竟训练语料里中文占了不小分量。

论文也坦诚讲了个短板：多选题任务（MMLU、CEval、CMMLU 这类）偏弱。原因是 MoE 里 FFN 占了参数大头，attention 被压得厉害，DeepSeekMoE 16B 的 attention 参数只有约 0.5B，DeepSeek 7B 有 2.5B，而多选题恰恰吃 attention 的能力。这个短板到后面 145B 上还是一样出现。

工程上有个亮点值得一提：16B 激活参数只有 2.8B，一块 40GB 显存的 GPU 就能跑，不用量化。配上算子优化，推理速度能到稠密 7B 的将近 2.5 倍。这对部署很重要，一个 16B 的模型塞进单卡，还跑得比 7B 快。

六、对齐：MoE 也能微调#

第六章做 SFT（supervised fine-tuning，监督微调）做对齐，把 16B 变成一个能聊天的模型。背景是，圈里一度认为 MoE 模型微调收益不大，但 Flan-MoE 那篇又说 instruction tuning 有用。DeepSeek 用 1.4M 条自建数据微调，结论是：DeepSeekMoE Chat 16B 用 40% 算力追平 LLaMA2 SFT 7B 和 DeepSeek Chat 7B，代码任务反超，中文任务全面领先。SFT 之后，跟稠密模型在多选题上的差距也缩小了。至少能说明，MoE 不是”不能微调”的体质。

七、145B：进行中的放大#

第七章标题就叫 “Ongoing”，进行中。DeepSeekMoE 145B，4 个共享专家加 128 个路由专家，激活 4 加 12 个，训练 245B tokens。注意这不是完整训练，是初步结果。

两件事值得说。一是跟同规模的 GShard 137B 比，总参数、算力都差不多，DeepSeekMoE 145B 明显赢。二是对上自家稠密 DeepSeek 67B，只用 28.5% 的算力就追平。更有意思的是那个 DeepSeekMoE 142B（Half Activated），只激活 2 加 6 个专家，激活参数砍半，算力只占 18.2%，照样追平 DeepSeek 67B、赢过 GShard 137B。激活得更少，能力不掉，这就是专家专业化到位的样子。

八、相关工作与结论#

相关工作把 MoE 的谱系捋了一遍：GShard、Switch Transformer 开创了可学习的 top-1/top-2 路由；Hash Layer、StableMoE 走固定路由路线求稳；后面还有 expert choice routing、ST-MoE。论文的意思很直白：过去绝大多数工作都困在 top-1/top-2 的框子里，专家专业化没被认真对待，这就是 DeepSeekMoE 的切入点。

结论就把故事收个尾：细粒度切分加共享专家隔离，从 2B 到 16B 到 145B 一路验证，同样的算力拿更高的性能，16B 的 checkpoint 开源、单卡可部署。

收尾：我的一点看法#

说几句我自己的理解。这篇论文的价值不在发明新原理，MoE、路由、共享专家这些零件没一个是它造的，GShard 之前那一串工作早就把地基打了。它真正做成的有两件事。

一是把”专家要专”从口号变成了可量化的设计。细粒度切分压缩知识混杂，共享专家隔离压缩冗余，4.5 节的敏感性分析又把”专不专”变成了能测的实验数字，这套闭环在同期的 MoE 论文里少见。

二是给出一条很实际的路线：同样的算力预算，MoE 能买到的性能明显更多，而 16B 这个量级单卡就能部署。放到 2024 年初那个时间点，这个”性价比”信号是很强的。

当然局限也有，论文自己都写了：多选题偏弱，attention 被挤得厉害；145B 那章还挂着 Ongoing，严格讲是不完整的。但这不妨碍它成为 MoE 路线上绕不开的一篇。

---

附：核心数据速查#