自最初的 GPT 架构被提出以来，已经过去了七年。乍一看，从 2019 年的 GPT-2 回顾，再展望 2024–2025 年的 DeepSeek V3 和 Llama 4，人们或许会惊讶地发现，这些模型在结构上依然高度相似。

当然，位置嵌入已经从绝对位置演进为旋转位置编码（RoPE），多头注意力（Multi-Head Attention）在很大程度上被分组查询注意力（Grouped-Query Attention）所取代，而效率更高的 SwiGLU 也替代了诸如 GELU 之类的激活函数。但在这些看似细微的改进之下，我们真的看到了颠覆性的变化吗？还是说，我们只是在不断打磨同一套架构基础？

比较不同的大语言模型（LLM），以判断哪些关键因素真正促成了它们良好（或不那么理想）的性能，是一件出了名的困难之事：数据集、训练方法以及超参数设置差异巨大，而且往往缺乏充分的公开说明。

然而，我仍然认为，审视架构本身的结构性变化依然具有很高的价值，因为它可以帮助我们了解 2025 年的 LLM 开发者究竟在做些什么。（其中一部分架构展示在下方的图 1 中。）

因此，在这篇文章中，我不会讨论基准测试性能或训练算法，而是将重点放在定义当今旗舰级开源模型的架构层面上的发展。

（你或许还记得，我不久前曾撰文讨论过多模态 LLM；在本文中，我将专注于近期模型的文本能力，并把多模态能力的讨论留待以后）

1. DeepSeek V3/R1

正如你现在可能已经不止一次听说过的那样，DeepSeek R1 在 2025 年 1 月发布时引起了巨大反响。DeepSeek R1 是一个推理模型，构建在 DeepSeek V3 架构 之上，而该架构于 2024 年 12 月首次提出。

虽然我在本文中的重点是 2025 年发布的架构，但我认为将 DeepSeek V3 纳入讨论是合理的，因为它真正获得广泛关注和采用是在 DeepSeek R1 于 2025 年发布之后。

如果你对 DeepSeek R1 本身的训练过程感兴趣，那么你可能也会觉得我今年早些时候写的那篇文章很有帮助：

Understanding Reasoning LLMs：

https://magazine.sebastianraschka.com/p/understanding-reasoning-llms

在本节中，我将重点介绍 DeepSeek V3 中引入的两项关键架构技术，它们提升了计算效率，并使其区别于许多其他大语言模型：

• • Multi-Head Latent Attention（MLA）
• • Mixture-of-Experts（MoE）

1.1 Multi-Head Latent Attention（MLA）

在讨论 Multi-Head Latent Attention（MLA）之前，让我们先简要回顾一些背景，以说明为什么要使用它。为此，我们先从 Grouped-Query Attention（GQA）开始。近年来，GQA 已成为 Multi-Head Attention（MHA）的一种更具计算效率和参数效率的替代方案，并逐渐成为新的标准。

下面是对 GQA 的简要总结。与 MHA 不同，在 MHA 中，每个注意力头都有自己的一组 key 和 value，而在 GQA 中，为了减少内存使用，会将多个注意力头分组，并让它们共享同一组 key 和 value 投影。

例如，如下方图 2 所进一步展示的那样，如果有 2 个 key-value 组和 4 个注意力头，那么第 1 和第 2 个头可能共享一组 key 和 value，而第 3 和第 4 个头共享另一组。这样可以减少 key 和 value 的总体计算量，从而降低内存使用并提升效率（根据消融实验的结果，在不明显影响建模性能的情况下）。

因此，GQA 的核心思想是通过在多个 query 头之间共享 key 和 value 头，来减少 key 和 value 头的数量。这一做法带来两个好处：（1）降低模型的参数数量；（2）在推理过程中减少 key 和 value 张量的内存带宽使用，因为需要存储和从 KV cache 中读取的 key 和 value 更少。

（如果你对 GQA 在代码中的实现方式感到好奇，可以查看我写的 GPT-2 转换为 Llama 3 的指南，其中提供了一个不使用 KV cache 的版本；而带有 KV cache 的变体可以在另一个链接中找到。）

尽管 GQA 主要是作为 MHA 的一种计算效率优化方案，但消融研究（例如原始 GQA 论文以及 Llama 2 论文中的实验）表明，在 LLM 的建模性能方面，它与标准 MHA 表现相当。

现在，Multi-Head Latent Attention（MLA）提供了一种不同的节省内存的策略，并且同样非常适合与 KV cache 搭配使用。与 GQA 通过共享 key 和 value 头不同，MLA 会在将 key 和 value 张量存入 KV cache 之前，先将它们压缩到一个更低维的空间中。

在推理时，这些被压缩的张量会在使用前被投影回原始维度，如下方图 3 所示。这一过程会增加一次额外的矩阵乘法，但能够显著减少内存使用。

（作为补充说明，query 在训练阶段也会被压缩，但在推理阶段不会。）

顺便一提，MLA 并不是首次出现在 DeepSeek V3 中，因为它的前代模型 DeepSeek-V2 就已经使用并且实际上引入了这一方法。此外，V2 论文中还包含了一些有趣的消融实验，可能解释了为什么 DeepSeek 团队选择了 MLA 而不是 GQA（见下方图 4）。

如上方图 4 所示，GQA 的表现似乎不如 MHA，而 MLA 在建模性能上优于 MHA，这很可能就是 DeepSeek 团队选择 MLA 而不是 GQA 的原因。（如果能看到 MLA 与 GQA 在 “每 token 的 KV cache 占用” 方面的节省对比，那将会非常有意思！）

在进入下一个架构组件之前，对本节内容进行一个总结：MLA 是一种巧妙的技术手段，它可以在降低 KV cache 内存使用的同时，在建模性能上甚至略微优于 MHA。

1.2 Mixture-of-Experts（MoE）

DeepSeek 中另一个值得重点介绍的主要架构组件是其对 Mixture-of-Experts（MoE）层的使用。虽然 MoE 并非 DeepSeek 首创，但它在今年迎来了复兴，且我们稍后将讨论的许多其他架构也都采用了这一设计。

你可能已经对 MoE 非常熟悉了，但快速回顾一下仍然是有帮助的。

MoE 的核心思想是，用多个专家层来替换 transformer 块中的每一个 FeedForward 模块，而这些专家层本身也都是 FeedForward 模块。也就是说，我们用多个 FeedForward 块来替代原本的单个 FeedForward 块，如下方图 5 所示。

图 5：DeepSeek V3/R1 中的 Mixture-of-Experts（MoE）模块（右）与使用标准 FeedForward 块的 LLM（左）的示意对比。

Transformer 块中的 FeedForward 模块（在上图中以深灰色块表示）通常包含了模型总参数量中的很大一部分。（需要注意的是，transformer 块——以及其中的 FeedForward 模块——在 LLM 中会被重复多次；例如在 DeepSeek V3 中，总共重复了 61 次。）

因此，用多个 FeedForward 模块替换单个 FeedForward 模块（如 MoE 设计所做的那样）会显著增加模型的总参数量。然而，关键的技巧在于：并不会为每个 token 使用（或“激活”）所有专家。相反，一个路由器会为每个 token 只选择一小部分专家。（出于时间限制，或者说文章篇幅的原因，我将把对路由器的更详细讨论留到以后。）

由于每次只激活少数几个专家，MoE 模块通常被称为“稀疏”的，与始终使用全部参数集的“稠密”模块相对。然而，通过 MoE 引入的大量总参数会提升 LLM 的容量，这意味着它在训练过程中可以吸收更多的知识。而稀疏性则保证了推理过程的高效性，因为并不是所有参数都会同时被使用。

例如，DeepSeek V3 在每个 MoE 模块中拥有 256 个专家，总参数量达到 6710 亿。然而在推理过程中，每次只有 9 个专家是活跃的（1 个共享专家加上由路由器选择的 8 个）。这意味着在每一步推理中，实际使用的参数量只有 370 亿，而不是全部的 6710 亿。

DeepSeek V3 的 MoE 设计中一个值得注意的特点是使用了共享专家（shared expert）。这是一个对每个 token 都始终处于激活状态的专家。这一想法并不新，早在 DeepSeek 2024 年的 MoE 工作以及 2022 年的 DeepSpeedMoE 论文中就已经提出。

最早是在 DeepSpeedMoE 论文中指出，共享专家可以提升整体建模性能，相较于没有共享专家的设置表现更好。这很可能是因为一些通用或重复出现的模式不需要被多个独立专家分别学习，从而为这些专家腾出了更多空间去学习更具专门性的模式。

1.3 DeepSeek 总结

总的来说，DeepSeek V3 是一个规模极其庞大的 6710 亿参数模型，在发布时，其性能超过了其他开源权重模型，包括 405B 的 Llama 3。尽管模型规模更大，但由于采用了 Mixture-of-Experts（MoE）架构，在推理阶段每个 token 只激活很小一部分参数（仅 370 亿），因此推理效率非常高。

另一个关键的区别性特征是，DeepSeek V3 使用了 Multi-Head Latent Attention（MLA）而不是 Grouped-Query Attention（GQA）。无论是 MLA 还是 GQA，都是在使用 KV cache 时，相较于标准 Multi-Head Attention（MHA）更加高效的推理替代方案。尽管 MLA 的实现更为复杂，但 DeepSeek-V2 论文中的研究表明，其建模性能优于 GQA。

2. OLMo 2

由非营利机构 Allen Institute for AI 推出的 OLMo 系列模型因其在训练数据和代码方面的高度透明性，以及相对详细的技术报告而值得关注。

虽然你可能不会在任何基准榜单或排行榜的最前列看到 OLMo 模型，但它们相当“干净”，更重要的是，由于其透明性，它们是开发 LLM 的一个极佳蓝图。

而且，尽管 OLMo 模型因透明性而广受欢迎，它们的性能其实也并不差。事实上，在 1 月发布时（在 Llama 4、Gemma 3 和 Qwen 3 之前），OLMo 2 模型正处在计算成本与性能的帕累托前沿，如下图所示。

正如本文前面提到的，我的目标是只关注 LLM 的架构细节（而非训练或数据），以控制文章长度。那么，OLMo 2 在架构设计上有哪些有趣的选择呢？主要体现在归一化上：RMSNorm 层的放置方式，以及额外引入的 QK-norm，下面我将对此进行讨论。

另外值得一提的是，OLMo 2 仍然使用传统的多头注意力（MHA），而不是 MLA 或 GQA。

2.1 归一化层的位置

总体而言，OLMo 2 在很大程度上遵循了原始 GPT 模型的架构，与其他当代 LLM 类似。不过，它也有一些值得注意的偏离之处。我们先从归一化层说起。

与 Llama、Gemma 以及大多数其他 LLM 类似，OLMo 2 从 LayerNorm 切换到了 RMSNorm。

但由于 RMSNorm 已经是老生常谈（它本质上是 LayerNorm 的简化版本，具有更少的可训练参数），因此我将跳过对 RMSNorm 与 LayerNorm 的讨论。（感兴趣的读者可以在我撰写的 GPT-2 到 Llama 转换指南中找到 RMSNorm 的代码实现。）

不过，值得讨论的是 RMSNorm 层的放置位置。最初的 Transformer（出自《Attention is all you need》论文）在 Transformer 块中，将两个归一化层分别放在注意力模块和前馈模块之后。

这种方式也被称为 Post-LN 或 Post-Norm。

而 GPT 以及之后的大多数 LLM，则将归一化层放在注意力模块和前馈模块之前，这被称为 Pre-LN 或 Pre-Norm。下面的图展示了 Post-Norm 与 Pre-Norm 的对比。

在 2020 年，Xiong 等人表明，Pre-LN 在初始化阶段会产生更加稳定的梯度。此外，研究人员还提到，Pre-LN 即使在没有精心设计的学习率 warm-up 的情况下也能很好地工作，而 warm-up 通常是 Post-LN 的一个关键工具。

之所以提到这一点，是因为 OLMo 2 采用了一种 Post-LN 的形式（但使用的是 RMSNorm 而不是 LayerNorm，因此我称之为 Post-Norm）。

在 OLMo 2 中，归一化层并不是放在注意力层和前馈层之前，而是放在它们之后，如上图所示。不过请注意，与原始 Transformer 架构不同的是，这些归一化层仍然位于残差（跳连）结构之内。

那么，为什么要移动归一化层的位置呢？原因在于，这样做有助于提升训练稳定性，如下图所示。

遗憾的是，这张图展示的是重新排列归一化层位置与 QK-Norm 同时作用的结果，而 QK-Norm 是一个独立的概念。因此，很难判断仅仅是归一化层重排本身贡献了多少效果。

2.2 QK-Norm

既然上一节已经提到了 QK-Norm，而且我们稍后将讨论的其他 LLM（如 Gemma 2 和 Gemma 3）也使用了 QK-Norm，那么这里我们就简要说明一下它是什么。

QK-Norm 本质上是又一个 RMSNorm 层。它被放置在多头注意力（MHA）模块内部，并在应用 RoPE 之前作用于查询（q）和键（k）。为了说明这一点，下面是我在 Qwen3 从零实现中编写的一个分组查询注意力（GQA）层的代码片段（GQA 中的 QK-Norm 应用方式与 OLMo 中的 MHA 类似）：

     
     class GroupedQueryAttention(nn.Module):
    def __init__(
        self, d_in, num_heads, num_kv_groups,
        head_dim=None, qk_norm=False, dtype=None
    ):
        # ...

        if qk_norm:
            self.q_norm = RMSNorm(head_dim, eps=1e-6)
            self.k_norm = RMSNorm(head_dim, eps=1e-6)
        else:
            self.q_norm = self.k_norm = None

    def forward(self, x, mask, cos, sin):
        b, num_tokens, _ = x.shape

        # Apply projections
        queries = self.W_query(x) 
        keys = self.W_key(x)
        values = self.W_value(x) 

        # ...

        # Optional normalization
        if self.q_norm:
            queries = self.q_norm(queries)
        if self.k_norm:
            keys = self.k_norm(keys)

        # Apply RoPE
        queries = apply_rope(queries, cos, sin)
        keys = apply_rope(keys, cos, sin)

        # Expand K and V to match number of heads
        keys = keys.repeat_interleave(self.group_size, dim=1)
        values = values.repeat_interleave(self.group_size, dim=1)

        # Attention
        attn_scores = queries @ keys.transpose(2, 3)
        # ...

如前所述，Post-Norm 与 QK-Norm 共同作用，可以稳定训练过程。需要注意的是，QK-Norm 并非由 OLMo 2 首次提出，而是可以追溯到 2023 年的《Scaling Vision Transformers》论文。

2.3 OLMo 2 总结

简而言之，OLMo 2 在架构设计上最值得注意的决策，主要集中在 RMSNorm 的放置方式上：将 RMSNorm 放在注意力层和前馈层之后（一种 Post-Norm 变体），以及在注意力机制内部为查询和键额外加入 RMSNorm（QK-Norm）。这两者结合在一起，有助于稳定训练损失。

下面的图进一步将 OLMo 2 与 Llama 3 并排对比；可以看到，除了 OLMo 2 仍然使用传统的 MHA 而非 GQA 之外，两者在架构上整体相当相似。（不过，OLMo 2 团队在 3 个月后发布了一个使用 GQA 的 32B 变体。）

3. Gemma 3

Google 的 Gemma 系列模型一直以来都非常优秀，而且我认为，相比于 Llama 系列等其他流行模型，它们一直有些被低估。

Gemma 的一个显著特点是其相当大的词表规模（以更好地支持多语言），以及对 27B 参数规模的更强关注（而不是 8B 或 70B）。不过需要注意的是，Gemma 2 也提供了更小的版本：1B、4B 和 12B。

27B 这个规模达到了一个非常理想的“甜点区间”：它的能力明显强于 8B 模型，但又不像 70B 模型那样消耗大量资源，而且它在我的 Mac Mini 上本地运行也完全没有问题。

那么，Gemma 3 还有哪些有趣之处呢？正如前文所讨论的，像 DeepSeek V3/R1 这样的其他模型采用了混合专家（Mixture-of-Experts，MoE）架构，以在固定模型规模的前提下降低推理阶段的内存需求。（这种 MoE 方法也被我们稍后将讨论的其他多个模型所采用。）

Gemma 3 采用了一种不同的“技巧”来降低计算成本，即滑动窗口注意力（sliding window attention）。

3.1 滑动窗口注意力

通过滑动窗口注意力（最早在 2020 年的 LongFormer 论文中提出，并且 Gemma 2 也已经在使用），Gemma 3 团队能够显著减少 KV 缓存的内存需求，如下图所示。

那么，什么是滑动窗口注意力？如果我们将常规自注意力理解为一种全局注意力机制（因为序列中的每个元素都可以访问其他所有元素），那么滑动窗口注意力可以被视为一种局部注意力机制，因为它限制了当前查询位置周围的上下文范围。如下图所示。

请注意，滑动窗口注意力既可以与多头注意力（Multi-Head Attention，MHA）一起使用，也可以与分组查询注意力（Grouped-Query Attention，GQA）一起使用；Gemma 3 使用的是分组查询注意力。

如上所述，滑动窗口注意力也被称为局部注意力，因为这个局部窗口会围绕当前查询位置并随之移动。相比之下，常规注意力是全局的，因为每个 token 都可以访问所有其他 token。

如前面简要提到的那样，Gemma 2 的前代架构也使用过滑动窗口注意力。Gemma 3 的不同之处在于，它调整了全局（常规）注意力与局部（滑动窗口）注意力之间的比例。

例如，Gemma 2 使用了一种混合注意力机制，以 1:1 的比例结合滑动窗口（局部）注意力和全局注意力。每个 token 可以关注一个 4k token 的局部上下文窗口。

而在 Gemma 3 中，滑动窗口注意力与全局注意力的比例变为 5:1，也就是说，每 5 层滑动窗口（局部）注意力层才有 1 层完整的全局注意力层；此外，滑动窗口的大小也从 Gemma 2 的 4096 缩小到了 Gemma 3 的 1024。这一变化使模型的计算更加偏向高效的局部计算。

根据其消融实验，使用滑动窗口注意力对建模性能的影响非常小，如下图所示。

虽然滑动窗口注意力是 Gemma 3 在架构层面上最引人注目的特性，但我还想简要讨论一下其归一化层的位置安排，作为对前面 OLMo 2 章节的延续。

3.2 Gemma 3 中的归一化层位置

一个虽小但有趣的细节是，Gemma 3 在其分组查询注意力模块的前后同时使用了 RMSNorm，也就是说，它同时采用了 Pre-Norm 和 Post-Norm。

这一点与 Gemma 2 类似，但仍然值得强调，因为它不同于：（1）原始 Transformer（《Attention is all you need》）中使用的 Post-Norm，（2）由 GPT-2 推广并被许多后续架构采用的 Pre-Norm，以及（3）我们在前文看到的 OLMo 2 中使用的 Post-Norm 变体。

我认为这种归一化层的位置安排是一个相当直观的设计，因为它在一定程度上兼顾了 Pre-Norm 和 Post-Norm 的优点。在我看来，多一点归一化通常并不会有什么坏处。最坏的情况是，如果额外的归一化是冗余的，那么它只会通过这种冗余带来一点点效率损失。而在实践中，由于 RMSNorm 在整体计算中相对开销较小，这种影响基本可以忽略不计。

3.3 Gemma 3 总结

Gemma 3 是一个性能出色的开源权重 LLM，在我看来，它在开源社区中有些被低估。其最有趣的地方在于通过滑动窗口注意力来提升效率（未来如果能与 MoE 结合，将会非常值得期待）。

此外，Gemma 3 还采用了一种独特的归一化层布局方式，在注意力模块和前馈模块的前后都放置了 RMSNorm。

3.4 附加内容：Gemma 3n

在 Gemma 3 发布几个月后，Google 又发布了 Gemma 3n，这是一个针对小型设备效率进行优化的 Gemma 3 模型，其目标是在手机等设备上运行。

为了实现更高的效率，Gemma 3n 引入了一项名为“逐层嵌入参数（Per-Layer Embedding，PLE）”的改动。其核心思想是，只将模型参数中的一部分保留在 GPU 内存中，而与 token 和层相关的特定嵌入参数（例如文本、音频和视觉模态的嵌入）则在需要时从 CPU 或 SSD 中按需加载。

下图展示了 PLE 所带来的内存节省效果，其中列出的 54.4 亿参数对应的是一个标准的 Gemma 3 模型。这很可能指的是 Gemma 3 的 4B 版本。

这里出现 54.4 亿与 40 亿参数之间差异的原因，在于 Google 在统计 LLM 参数规模时采用了一种颇有意思的方式。他们往往会排除嵌入参数，从而让模型看起来更小；而在像这里这样的场景中，又会将嵌入参数包含在内，从而让模型看起来更大。这种做法并非 Google 独有，而是已经成为该领域中的一种常见实践。

另一个有趣的技巧是 MatFormer（Matryoshka Transformer）概念。例如，Gemma 3n 使用了一个共享的 LLM（Transformer）架构，这个架构可以被“切片”为多个更小、可独立使用的模型。每一个切片在训练时都会被单独训练为可独立工作的模型，因此在推理阶段，我们只需要运行所需的那一部分，而不必运行整个大型模型。

4. Mistral Small 3.1

Mistral Small 3.1 24B 于 3 月发布，时间上紧随 Gemma 3 之后。它之所以值得关注，是因为在多个基准测试中（数学任务除外），其表现超过了 Gemma 3 27B，同时推理速度也更快。

Mistral Small 3.1 相较于 Gemma 3 拥有更低推理延迟，其原因很可能在于它们定制化的 tokenizer，以及对 KV 缓存规模和网络层数的缩减。除此之外，它采用的是一种相当标准的架构，如下图所示。

有意思的是，早期的 Mistral 模型曾使用过滑动窗口注意力，但如果我们查看官方 Model Hub 配置文件中的默认设置（"sliding_window": null），那么在 Mistral Small 3.1 中，它们似乎已经放弃了这一机制。此外，其模型卡片中也没有提及滑动窗口注意力。

因此，由于 Mistral 使用的是常规的分组查询注意力（Grouped-Query Attention），而不是像 Gemma 3 那样带滑动窗口的分组查询注意力，也许在推理计算方面还能获得额外的节省，因为这样可以使用更加优化的实现代码（例如 FlashAttention）。

例如，我推测，虽然滑动窗口注意力可以降低内存使用，但它并不一定能降低推理延迟，而后者正是 Mistral Small 3.1 重点关注的目标。

5. Llama 4

在本文前面已经对混合专家（Mixture-of-Experts，MoE）进行了较为深入的介绍，这里再次派上了用场。Llama 4 同样采用了 MoE 架构，并且在其他方面遵循了一种相对标准的设计，与 DeepSeek V3 非常相似，如下图所示。（Llama 4 具备原生的多模态支持，类似于 Gemma 和 Mistral 等模型。不过，由于本文聚焦于语言建模，这里只讨论其文本模型。）

尽管 Llama 4 Maverick 的整体架构看起来与 DeepSeek V3 非常相似，但其中仍然存在一些值得关注的差异。

首先，Llama 4 像其前代模型一样使用了分组查询注意力（Grouped-Query Attention，GQA），而 DeepSeek V3 使用的是我们在本文开头讨论过的多头潜在注意力（Multi-Head Latent Attention，MLA）。现在，DeepSeek V3 和 Llama 4 Maverick 都是非常大的模型架构，其中 DeepSeek V3 在总参数量上大约大 68%。然而，在激活参数数量方面，DeepSeek V3 每个 token 使用 370 亿个激活参数，而 Llama 4 Maverick 仅使用 170 亿个激活参数，这意味着 DeepSeek V3 的激活参数数量超过了 Llama 4 Maverick 的两倍。

Llama 4 Maverick 采用了一种更加经典的 MoE 设计：专家数量更少，但单个专家更大（每个 token 激活 2 个专家，每个专家的隐藏维度为 8192），而 DeepSeek V3 则是激活 9 个专家（1 个共享专家加 8 个路由专家），每个专家的隐藏维度为 2048。此外，DeepSeek V3 在几乎每一个 Transformer 块中都使用了 MoE 层（除了最前面的 3 层），而 Llama 4 则是在 Transformer 块中交替使用 MoE 模块和致密（dense）模块，即每隔一层才使用一次 MoE。

鉴于不同架构之间存在大量细微差异，很难精确判断这些差异对最终模型性能的具体影响。然而，一个明确的结论是：MoE 架构在 2025 年的流行度显著上升。

6. Qwen3

Qwen 团队一贯能够持续推出高质量的开源权重 LLM。在我于 NeurIPS 2023 协助共同指导 LLM 效率挑战赛时，我记得当时排名最前的解决方案全部都基于 Qwen2。

现在，Qwen3 再次成为各个参数规模榜单中的佼佼者。它包含 7 个致密（dense）模型：0.6B、1.7B、4B、8B、14B 和 32B；以及 2 个 MoE 模型：30B-A3B 和 235B-A22B。

（顺便一提，请注意 “Qwen3” 中缺少空格并不是笔误；我只是保持了 Qwen 团队所选择的原始命名方式。）

6.1 Qwen3（致密模型）

我们先来讨论致密模型架构。截至本文撰写时，0.6B 模型很可能是当前这一代中体量最小的开源权重模型。而根据我个人的使用经验，在如此小的规模下，它的表现非常出色。如果你计划在本地运行，它具备极高的 token/秒吞吐量以及很低的内存占用。更重要的是，由于规模小，它也非常适合在本地进行训练（例如用于教学目的）。

因此，对我而言，Qwen3 0.6B 在大多数使用场景下已经取代了 Llama 3 1B。下面的图展示了这两种架构的对比。

如果你对一个不依赖任何第三方 LLM 库、可读性强的 Qwen3 实现感兴趣，我最近用纯 PyTorch 实现了一个 Qwen3 from-scratch 版本。

上图中的计算性能数据来自我从零实现的 PyTorch 代码，并在 A100 GPU 上运行得到。可以看到，Qwen3 的整体架构更小，因此内存占用更低，同时它也使用了更小的隐藏层维度以及更少的注意力头。不过，它使用了比 Llama 3 更多的 Transformer 块，这导致其运行速度更慢（token/秒生成速度更低）。

6.2 Qwen3（MoE）

如前所述，Qwen3 还提供了两种 MoE 版本：30B-A3B 和 235B-A22B。那么，为什么像 Qwen3 这样的架构会同时提供常规（致密）版本和 MoE（稀疏）版本呢？

正如本文开头所提到的，MoE 版本有助于在大规模基础模型中降低推理成本。在同一模型系列中同时提供致密模型和 MoE 模型，可以让用户根据自身目标和约束条件进行灵活选择。

致密模型通常更容易进行微调、部署，并且在不同硬件平台上更容易优化。

而 MoE 模型则更适合推理阶段的规模化扩展。例如，在固定的推理预算下，它们可以实现更高的整体模型容量（也就是在训练阶段能够吸收更多知识，因为模型总规模更大），而不会成比例地增加推理成本。

通过同时发布这两种模型，Qwen3 系列能够覆盖更广泛的使用场景：致密模型适合追求稳健性、简洁性和易于微调的场合，而 MoE 模型则适合需要高效大规模服务的场景。

作为本节的收尾，我们来看一下 Qwen3 235B-A22B 与 DeepSeek V3 的对比。需要注意的是，Qwen3 每个 token 激活 22B 参数，而 DeepSeek V3 几乎激活了两倍的参数量（37B）。

从上图可以看到，DeepSeek V3 与 Qwen3 235B-A22B 的架构非常相似。不过，一个值得注意的差异是：Qwen3 放弃了共享专家（shared expert）机制（早期的 Qwen 模型，例如 Qwen2.5-MoE，是使用共享专家的）。

遗憾的是，Qwen3 团队并未披露他们放弃共享专家的具体原因。如果让我猜测，原因可能是：当专家数量从 Qwen2.5-MoE 中的 2 个增加到 Qwen3 中的 8 个时，共享专家在训练稳定性方面已经不再是必需的；于是，他们便可以通过只使用 8 个专家而不是 8+1 个专家，来节省额外的计算和内存开销。（不过，这仍然无法解释为什么 DeepSeek V3 仍然保留了共享专家。）

更新说明：Qwen3 的开发者之一 Junyang Lin 对此作出了如下回应：

当时我们并没有发现共享专家能够带来足够显著的提升，同时我们也担心共享专家会对推理阶段的优化产生影响。坦率地说，这个问题并没有一个明确的结论。

未完待续...

https://magazine.sebastianraschka.com/p/the-big-llm-architecture-comparison