DeepSeek 模型架构的特殊选择

一、背景

DeepSeek V3/R1 模型的发布，以及 AI Infra 相关代码库的开源，对大模型从业者产生了不容忽视的影响。从短期来看，这些工作确实推动了业界对 AI Infra 建设的关注，至少促使人们开始重视算法与 Infra 的协同设计。这一变化也看似提升了 Infra 团队在整个大模型生成链路的话语权，但也为相关从业者带来了更大的学习压力与追赶挑战，甚至看到一些公司或团队因而重新审视了原有的发展规划。

近期，我依然保持阅读了一些相关文章，但由于比较忙，一直没来得及整理成文。在这些问题中，有一个我之前就有所关注，最近再次想起，然而看到相关讨论很少，因此这里对其进行简要梳理。这一问题聚焦于 DeepSeek 的模型设计选型，包括以下两个方面：

• 问题一：为什么 DeepSeek V3 模型在预训练中使用了 16 路 PP（Pipeline Parallelism），而其层数是 61，并不能被 16 整除，这一设计有何考量？
• 问题二：DeepSeek V3 模型的前 3 层为 Dense Layer，之后 58 层是 MoE Layer，这样的混合结构有何特殊的意义？

值得注意的是，DeepSeek 之前的模型也出现了类似的设计范式，比如：

• DeepSeek V2 包含 60 层，其中第 1 层是 Dense Layer，后续 59 层为 MoE Layer。
• DeepSeek MoE 包含 28 层，第 1 层是 Dense Layer，后续 27 层为 MoE Layer。

针对上述问题，笔者也有一些初步的个人猜测，比如：

• 关于层数与 PP 的关系：一种可能的解释是，通过非均匀分配层数，可以优化负载开销，比如降低首尾 Stage 的内存需求。
• 关于前几层采用 Dense Layer：一个合理的假设是，前几层更多关注低级且通用的特征，这些特征不太需要复杂的 MoE 机制，或者 MoE 中很难保持负载均衡。然而，这一推测尚缺乏实证支持，并且很多开源的 MoE 模型也并没有采取类似策略。

在这个过程中，也发现了一些很有意思的现象：无论是 DeepSeek R1 还是 Grok-3 的 DeepSearch，在面对一些专业问题或者细节问题时，都很容易出现明显的幻觉问题（hallucination）。仔细审查会发现其存在很多明显的错误，这也凸显了当前大模型在内容生成方面可能存在的局限性.如下图所示为 DeepSeek R1 的部分结果，红框中的结果均存在不准确的地方：

如下图所示为腾讯元宝中使用 DeepSeek-R1 的结果：

二、混合 MoE

2.1 Google Switch Transformer

Google Switch Transformer 论文（[2101.03961] Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity [1]）中对 MoE Layer 的分布介绍的非常隐晦，单看架构图很容易误解为是一个纯粹的 MoE 模型（每一个 Transformer Layer 都包含 MoE Block），一些非官方的代码实现中也是如此。然而实际上并非如此：

如下图 Table 1 的说明中提到，“with experts at every other feed-forward layer”，说明 MoE Transformer Layer 和 Dense Transformer Layer 是交替的：

如下图 Table 9 所示，其中提到 Expert Freq 为 1/2，表明 MoE Transformer Layer 和 Dense Transformer Layer 各占 1/2，与上述的交替相对应：

而在 Huggingface 的 Switch Transformer 实现中（Huggingface configuration_switch_transformers.py [2]），包含 num_sparse_decoder_layers 参数，表示每隔多少层有一个 MoE Layer，也可以间接支持上述结构，如下所示：

2.2 Google GLaM

Google 在其 GLaM 模型（[2112.06905] GLaM: Efficient Scaling of Language Models with Mixture-of-Experts [3]）中依然延续了 Dense Layer 和 MoE Layer 交错的方式。如下图 Figure 2 所示，这次的架构图很清晰：

此外，对应的层数也是标准的 4 或 8 的整数倍：

2.3 Google ST-MoE

Switch Transformer 的作者在 [2202.08906] ST-MoE: Designing Stable and Transferable Sparse Expert Models [4] 中进一步提出了 ST-MoE 模型，其相比 Switch Transformer，其中 MoE Layer 的占比更低，只有 1/4，并且在这篇论文中也给出了 Expert Freq 的说明：

为了支持 Switch Transformer 和 ST-MoE 模型，作者开源了对应的 GitHub - google/flaxformer [5]。如下图所示，其通过 sparse_layout 和 num_sparse_layers 可以提供各种灵活配置（也可以支持 Switch Transformer），比如：

• 只有前几层是 MoE。
• 只有中间几层是 MoE。
• Dense Transformer Layer 中交替插入 MoE。
• 只有最后几层是 MoE。

现在想想，不知道为何 Google 一直在坚持这种交错的范式，也许是早期的 MoE 模型还不成熟，专家负载均衡的问题还没有被很好的解决，或者是对训练稳定性与计算效率的一种妥协。

2.4 Snowflake Arctic

在使用 Grok DeepSearch 查找相关工作时也有意外收获，比如其提到了 Snowflake AI Research 发布的 Snowflake Arctic 模型（GitHub - Snowflake-Labs/snowflake-arctic [6]）。

如下图所示，其所谓的混合是在一个 Transformer Layer 中既有常规的 FFN，还有一个额外的 MoE 分支，只不过 MoE 分支和 Attention+FFN 是并联的方式。实际上，如果 MoE 的输入和 FFN 的输入相同（如红线所示），对应的就是 DeepSeek 的 Shared Expert + Sparse Expert 的方式。该模型的 Dense 分支总共包含 10B 参数量，残差连接的 MoE 分支包含 128x3.66B 参数量，总计参数量达到 480B，其中通过 top-2 Gating 机制选定的活跃参数为 17B。

2.5 MixCon

还看到其他的隔层 MoE 的架构，比如 MixCon: A Hybrid Architecture for Efficient and Adaptive Sequence Modeling [7]。MixCon 是一种新的混合序列建模的架构，主要是结合了基于 Attention 机制的标准 Transformer Layer、Conba Layer 以及 MoE Block。其在长序列建模中可以获得很高的计算效率。

2.6 MiniMax-01

与 MixCon 类似，其实 MiniMax 发布的开源大模型 [2501.08313] MiniMax-01: Scaling Foundation Models with Lightning Attention [8] 中也采用了混合架构，只不过是 Attention 的混合。为了弥补 Linear Attention 长距离序列建模能力不足的问题，作者在每隔 M 层会采用一个标准的 Softmax Attention Block。

2.7 DeepSeekMoE

对于之前的疑问 “DeepSeek 中为什么在浅层使用 Dense Layer 以及使用多少个 Dense Layer 更好？”，在 DeepSeek V2、V3 以及其中使用的 MoE 负载均衡损失（[2408.15664] Auxiliary-Loss-Free Load Balancing Strategy for Mixture-of-Experts [9]）等 Paper 中并没有找到具体答案。最终在 [2401.06066] DeepSeekMoE: Towards Ultimate Expert Specialization in Mixture-of-Experts Language Models [10] 看到，作者提到第一层的负载均衡状态收敛很慢，因此保留第一层为 Dense Layer：

不过论文中针对这个问题并没有太多的消融实验，在 DeepSeek V3 中也是直接将 Dense Layer 从 1 层扩展到 3 层。

2.8 Router 负载实验

在最近的一篇论文 [2503.05029] Continual Pre-training of MoEs: How robust is your router? [14] 中，作者发现，在多个 MoE 模型中都一致地出现了类似上述 DeepSeekMoE 的结论。也就是：在多个 MoE 模型的早期层都一致的出现了 MRI（Maximum Routing Imbalance，最大路由不平衡）高的情况。MRI 定义为在某个训练迭代和 MoE 层中，单个专家处理的 Token 比例的最大值。MRI 的值越高，表示路由越不平衡，即某个专家被分配了更多的 Token，可能导致负载不均衡。如下图所示：

三、Pipeline Parallelism & Layer

3.1 Meta LLaMA 3

Meta 的 LLaMA 3 405B（[2407.21783] The Llama 3 Herd of Models [11]） 包含 126 个 Transformer Layer。如果是 128 个 Layer，很容易将它们均分到不同的 PP Stage。比如，16 个 PP Stage，则每个 Stage 包含 8 个 Layer。

然而实际只有 126 个 Layer，这是因为默认的 Pipeline Parallelism 实现会导致资源消耗不均衡。由于 Word Embedding 和 Warmup Micro Batch 的存在，第一个 Stage 会消耗更多内存；由于 LM Head 的存在，最后一个 Stage 也会多消耗一些内存。

如下图所示为标准的 1F1B PP：

• Device 1 上执行 Micro Batch 1 的 Backward（橙色）之前，Micro Batch 1/2/3/4 Forward（蓝色）产生的激活会一直占用内存。占用空间最大。
• Device 3 上执行 Micro Batch 1 的 Backward（橙色）之前，Micro Batch 1/2 Forward（蓝色）产生的激活会一直占用内存。
• Device 4 上执行 Micro Batch 1 的 Backward（橙色）之前只有 Micro Batch 1 Forward（蓝色）产生的激活。占用空间最小。

为了使 PP 的资源消耗更加均衡，作者从第一个 PP Stage 和最后一个 PP Stage 都减少了一个 Transformer Layer。

3.2 GLM-130B

如下图所示，其实智谱 2022 年在训练 GLM-130B 模型（[2210.02414] GLM-130B: An Open Bilingual Pre-trained Model [12]）时已经采用过类似上述 Meta 的方案。具体来说，其会在第一个 PP 和最后一个 PP 时让 Transformer Layer 少一点，以便更加的均衡（PP 为 8，共 70 层，中间各 9 层，起始各 8 层）。

3.3 PipeOffload

最近看到 Sea AI-Lab 发表了一篇 PipeOffload: Improving Scalability of Pipeline Parallelism with Memory Optimization [13]，其在 Pipeline Parallelism 中通过调度和 Offload 等机制来降低内存开销。实验证明，每设备的激活内存随 Stage 总数有效减少，使 PP 成为比 TP（Tensor Parallelism）更具优势的选择，在内存消耗更低的情况下，最高可带来 19% 的加速。

如下图 Figure 5 所示，通过最简单的调整 Interleaved 1F1B 中 Warmup 的调度（GIS），从而实现内存的节约。其中红框部分的几个 Forward Stage 被延后处理，进而可以延缓对应激活的生命周期：

如下图 Figure 6 所示，进一步对 GIS 进行改进（GIS-H），可以进一步降低激活内存的需求，不过相应的 Bubble 率也会提升：

既然一些激活要很长一段时间之后才会被用到，那么将其 Offload 到 Host 内存中就是一种很自然的想法。如下图 Figure 12 所示为一种比较极端的 Case。由于最后一个 PP Stage 在计算完 Forward 后可以马上计算 Backward，因此不需要 Offload，其他的 Stage 均可使用。不过需要在 Offload 开销与内存节约之间取得平衡。其中的箭头标注了 Offload 对前序 Forward 计算的依赖，以及 Backward 计算对 Reload 的依赖。

四、参考链接

• ​​https://arxiv.org/abs/2101.03961​​
• ​​https://github.com/huggingface/transformers/blob/v4.49.0/src/transformers/models/switch_transformers/configuration_switch_transformers.py​​
• ​​https://arxiv.org/abs/2112.06905https://arxiv.org/abs/2202.08906​​
• ​​https://github.com/google/flaxformer​​
• ​​https://github.com/Snowflake-Labs/snowflake-arctic​​
• ​​https://zhouchenlin.github.io/Publications/2024-ECAI-MixCon.pdf​​
• ​​https://arxiv.org/abs/2501.08313https://arxiv.org/abs/2408.15664​​
• ​​https://arxiv.org/abs/2401.06066​​
• ​​https://arxiv.org/abs/2407.21783​​
• ​​https://arxiv.org/abs/2210.02414​​
• ​​https://arxiv.org/pdf/2503.01328​​