编者按： 在 Transformer 架构诞生八年之际，我们是否真的见证了根本性的突破，还是只是在原有设计上不断打磨？今天我们为大家带来的这篇文章，作者的核心观点是：尽管大语言模型在技术细节上持续优化，其核心架构仍保持延续，真正的创新更多体现在效率提升与工程实现上。
文章系统梳理了 2025 年多个主流开源模型的架构演进，重点分析了 DeepSeek-V3/R1 的多头潜在注意力（MLA）与混合专家模型（MoE）、OLMo 2 的归一化层放置策略与 QK 归一化、Gemma 3 的滑动窗口注意力机制，以及 Mistral Small 3.1 在推理效率上的优化。
这篇文章为我们提供了一个冷静而深入的视角，提醒我们在追逐 SOTA 榜单的同时，不应忽视那些真正推动技术前进的、看似细微却至关重要的架构设计选择。
作者 | Devansh and Sebastian Raschka, PhD
编译 | 岳扬
目录
01 DeepSeek V3/R1
1.1 多头潜在注意力机制（MLA）
1.2 混合专家模型（MoE）
1.3 DeepSeek 架构总结
02 OLMo 2
2.1 归一化层放置策略
2.2 QK-Norm
2.3 OLMo 2 架构总结
03 Gemma 3
3.1 滑动窗口注意力机制
3.2 Gemma 3 的归一化层布局策略
3.3 Gemma 3 架构总结
3.4 附加内容：Gemma 3n
04 Mistral Small 3.1
自最初的 GPT 架构问世以来，已经过去了七年时间。当我们回望 GPT-2（2019 年）并展望 DeepSeek-V3 与 Llama 4（2024 - 2025年）时，可能会惊讶地发现这些模型在结构上仍然如此相似。
诚然，位置编码已从绝对位置编码发展为旋转位置编码（RoPE），多头注意力机制已普遍被分组查询注意力机制取代，而更高效的 SwiGLU 激活函数也替代了 GELU 等传统激活函数。但在这些细微改进之下，我们是否真正见证了突破性的变革？抑或只是在相同架构基础之上进行精雕细琢？
比较不同大语言模型来确定影响其性能优劣的关键因素历来充满挑战：数据集、训练技术和超参数不仅差异巨大，且往往缺乏完整记录。
尽管如此，我仍认为审视架构本身的结构性变化极具价值 ------ 这能帮助我们洞察 2025 年大语言模型开发者的核心关注点（部分架构如图 1 所示）。
图 1：本文涉及的部分架构示意图
因此，本文将聚焦定义当今主流开源模型的核心架构演进，而非基准测试表现或训练算法的讨论。
01 DeepSeek V3/R1
DeepSeek R1 在 2025 年 1 月发布时引起了巨大轰动。该推理模型基于 2024 年 12 月推出的 DeepSeek V3 架构构建。
虽然本文主要关注 2025 年发布的模型架构，但考虑到 DeepSeek V3 正是在 2025 年凭借 DeepSeek R1 的发布才获得广泛关注与应用，将其纳入讨论范围是合理的。
若您对 DeepSeek R1 的训练细节感兴趣，可参阅我今年早前的文章《Understanding Reasoning LLMs》[1]：
本节将重点解析 DeepSeek V3 中两项提升计算效率的核心架构技术（这也是其区别于其他大语言模型的重要特征）：
- 多头潜在注意力机制（MLA）
- 混合专家模型（MoE）
1.1 多头潜在注意力机制（MLA）
在探讨多头潜在注意力机制（MLA）之前，我们先简要回顾相关背景以理解其设计动机。让我们从分组查询注意力机制（GQA）谈起 ------ 近年来它已成为替代多头注意力机制（MHA）的新标准方案，具有更高的计算效率与参数效率。
以下是 GQA 的核心概要：与 MHA 中每个注意力头都拥有独立的键值对不同，GQA 通过让多个注意力头共享同一组键值投影来降低内存消耗。例如，如图 2 所示，若存在 2 个键值组和 4 个注意力头，则注意力头 1 与注意力头 2 可能共享一组键值，而注意力头 3 与注意力头 4 共享另一组。这种方式减少了键值计算总量，从而降低内存使用并提升效率（消融实验表明其对模型性能无明显影响）。
图 2：MHA 与 GQA 对比示意图（组大小为 2，即每两个查询头共享一组键值对）
GQA 的核心思想是通过让多个查询头共享键值头来减少键值头数量，这带来两大优势： （1）降低模型参数量；（2）推理时减少键值张量的内存带宽占用，因为需要存储和从 KV 缓存中检索的键值对更少。
（若想了解 GQA 的代码实现，可参阅笔者撰写的无 KV 缓存版《GPT-2 to Llama 3 conversion guide》[2]及带 KV 缓存的改进版本[3]。）
尽管 GQA 本质上是针对 MHA 的计算效率优化方案，但消融研究（包括原版 GQA 论文[4]和 Llama 2 论文[5]）表明其在 LLM 建模性能上与标准 MHA 相当。
而多头潜在注意力机制（MLA）则提供了另一种内存优化策略，尤其与 KV 缓存机制高度契合。与 GQA 共享键值头的思路不同，MLA 将键值张量压缩至低维空间后再存入 KV 缓存。
推理时，这些压缩张量会先通过投影恢复原始尺寸后再参与计算（如图 3 所示）。虽然增加了矩阵乘法操作，但大大降低了内存占用。
图 3：MLA（用于 DeepSeek V3 和 R1 中）与常规 MHA 的对比示意图
（需要说明的是，查询向量在训练过程中也会被压缩，但该操作仅适用于训练阶段，不涉及推理过程。）
值得一提的是，MLA 并非 DeepSeek V3 首创 ------ 其前代版本 DeepSeek-V2 早已采用（甚至可以说是由其率先引入）这项技术。此外，V2 论文中多项有趣的消融实验或许能解释开发团队为何选择 MLA 而非 GQA（见图 4）。
图 4：带有标注的摘自 DeepSeek-V2 论文的表格（来源：arxiv.org/abs/2405.04...
如图 4 所示，GQA 的表现似乎逊于 MHA，而 MLA 的建模性能反而优于 MHA ------ 这很可能是 DeepSeek 团队舍弃 GQA 选择 MLA 的原因。（若能同时对比 MLA 与 GQA 在"每词元 KV 缓存"上的节省效果，或许会更有趣！）
对此部分进行总结：MLA 是一种巧妙的 KV 缓存内存优化技术，其在建模性能方面甚至较 MHA 略有提升。
1.2 混合专家模型（MoE）
DeepSeek 架构中另一个值得重点阐述的核心组件是其采用的混合专家模型（MoE）层。尽管 MoE 并非由 DeepSeek 首创，但今年该技术正迎来复兴浪潮，后续将讨论的诸多模型架构也都采用了这一方案。
MoE 的核心思想是将 Transformer 模块中的每个前馈网络替换为多个专家层 ------ 每个专家层本身也是前馈模块。这意味着我们用多个前馈模块替代单一前馈模块，具体如图 5 所示。
图 5：DeepSeek V3/R1 采用的 MoE 模块（右）与标准前馈网络结构（左）对比示意图
Transformer 模块内的前馈网络（上图中深灰色模块）通常占据着模型的绝大部分参数量（需注意 Transformer 模块及其内含的前馈网络会在 LLM 中重复多次，例如 DeepSeek-V3 中就重复了 61 次）。
因此，用多个前馈模块替代单一前馈模块（MoE 的实现方式）会大大增加模型的总参数量。但并非每个 token 都会激活所有专家。相反，路由层会为每个 token 仅选择一小部分专家（由于篇幅所限，关于路由层的细节将另文详述）。
由于每次仅激活少量专家模块，MoE 系统通常被称为稀疏架构，这与始终使用全部参数的密集架构形成对比。通过 MoE 实现的庞大总参数量提升了 LLM 的容量上限，使其在训练过程中能吸收更多知识。而稀疏特性则保证了推理效率 ------ 因为我们不会同时调用所有参数。
以 DeepSeek-V3 为例：每个 MoE 模块包含 256 个专家，总参数量达 6710 亿。但在推理过程中，每次仅激活 9 个专家（1 个共享专家 + 路由层选出的 8 个专家）。这意味着每个推理步骤仅使用 370 亿参数，而非全部 6710 亿。
DeepSeek-V3 的 MoE 设计有一个特点：采用共享专家机制。这个专家会对每个 token 始终保持激活状态。 该理念并非首创，早在 2024 年 DeepSeek MoE 论文[6]和 2022 年 DeepSpeedMoE 论文[7]中就已提出。
图 6：带有标注的摘自《DeepSeekMoE: Towards Ultimate Expert Specialization in Mixture-of-Experts Language Models》的图示，arxiv.org/abs/2401.06...
共享专家的优势最初在 DeepSpeedMoE 论文[7]中被指出：相比无共享专家的设计，它能提升整体建模性能。这很可能是因为常见模式或重复模式无需由多个独立专家重复学习，从而为专家们留出更多专攻特殊化模式的空间。
1.3 DeepSeek 架构总结
总而言之，DeepSeek-V3 作为一个拥有 6710 亿参数的巨型模型，在发布时性能就超越了包括 4050 亿参数的 Llama 3 在内的其他开放权重模型。尽管参数量更大，但其推理效率却明显更高 ------ 这得益于其混合专家系统（MoE）架构的设计，该架构使得每个 token 仅激活参数总量的极小部分（仅 370 亿参数）。
另一个关键区别在于 DeepSeek-V3 采用多头潜在注意力机制（MLA）替代了分组查询注意力机制（GQA）。MLA 与 GQA 都是标准多头注意力（MHA）的高效推理替代方案，尤其在配合 KV 缓存使用时优势明显。虽然 MLA 的实现更为复杂，但 DeepSeek-V2 论文中的研究表明，其建模性能优于 GQA。
02 OLMo 2
非营利组织艾伦人工智能研究所（Allen Institute for AI）推出的 OLMo 系列模型同样值得关注，这主要得益于其在训练数据与工程代码方面的高透明度，以及相对详尽的技术报告。
虽然 OLMo 模型可能不会在各类基准测试或排行榜上名列前茅，但其架构设计清晰简洁。更重要的是，凭借完全开源的特性，该系列模型为 LLM 的开发提供了极佳的蓝图参考。
尽管 OLMo 模型因其透明性而广受欢迎，但其性能表现同样可圈可点。实际上，在今年 1 月发布时（早于 Llama 4、Gemma 3 和 Qwen 3），OLMo 2 系列模型正处于计算效率与性能的帕累托前沿【译者注："帕累托前沿"（Pareto Frontier）是一个起源于经济学和优化理论的重要概念，它描述的是一种最优状态，在这种状态下，任何一方的利益或某个目标的提升都无法不以牺牲其他方利益或其他目标的下降为代价。】，如图 7 所示。
图 7：不同 LLMs 的基准测试性能（越高越好）与预训练成本（FLOPs；越低越好）对比（这张经过标注的图片源自 OLMo 2 论文，arxiv.org/abs/2501.00...
如本文开头所述，为控制篇幅，我们将聚焦于 LLM 的架构细节（暂不涉及训练细节与数据）。那么 OLMo 2 有哪些值得关注的架构设计选择？主要可归结为归一化技术的应用：包括 RMSNorm 层的布局以及新增的 QK 归一化设计（后续将详细讨论）。
另值得一提的是，OLMo 2 仍采用传统多头注意力（MHA）机制，而非 MLA 或 GQA。
2.1 归一化层放置策略
总体而言，OLMo 2 基本遵循了原始 GPT 的架构设计，这与当代其他大语言模型相似。但其仍存在一些值得关注的差异，让我们先从归一化层说起。
与 Llama、Gemma 及多数主流大语言模型类似，OLMo 2 也将 LayerNorm 层替换为了 RMSNorm 层。
但由于 RMSNorm 已是成熟技术（本质上是 LayerNorm 的简化版，拥有更少的可训练参数），本文将不再讨论 RMSNorm 与 LayerNorm 的区别（感兴趣的读者可参阅笔者撰写的《GPT-2 to Llama conversion guide》[8]中的 RMSNorm 代码实现）。
然而，RMSNorm 层的放置位置值得深入探讨。原始 Transformer 架构（出自《Attention is all you need》[9]论文）将两个归一化层分别放置在注意力模块和前馈网络模块之后。
这种设计被称为后归一化（Post-LN 或 Post-Norm）。
而 GPT 及之后大多数大语言模型则将归一化层置于注意力模块和前馈网络模块之前，称为前归一化（Pre-LN 或 Pre-Norm）。两种归一化方式的对比如下图所示。
图 8：后归一化、前归一化与 OLMo 2 采用的后归一化变体对比示意图
2020 年，Xiong 等人通过研究[10]证明：前归一化能使梯度在初始化阶段表现更稳定。研究人员还指出，前归一化即使不配合精细的学习率预热策略也能良好工作，而这对于后归一化而言却是至关重要的训练保障。
此处特别提及该研究是因为 OLMo 2 采用了一种后归一化变体（但使用 RMSNorm 替代了 LayerNorm，故称其为 Post-Norm）。
在 OLMo 2 中，归一化层被放置在注意力层和前馈网络层之后（而非之前），如上图所示。但请注意：与原始 Transformer 架构不同，这些归一化层仍位于残差层（跳跃连接）内部。
那么为何要调整归一化层的位置？原因在于这种设计能提升训练稳定性，如下图所示。
图 9：前归一化（GPT-2、Llama 3 等模型采用）与 OLMo 2 后归一化变体的训练稳定性对比图。此带有标注的图表取自 OLMo 2 论文，arxiv.org/abs/2501.00...
遗憾的是，该图表将归一化层重定位与 QK-Norm（另一个独立概念）的效果合并展示，因此难以单独判断归一化层位置调整的具体贡献程度。
2.2 QK-Norm
既然上一节已提及 QK-Norm，且后续将讨论的其他大语言模型（如 Gemma 2 和 Gemma 3）也采用了该技术，我们不妨简要探讨一下其原理。
QK-Norm 本质上是另一个 RMSNorm 层。它被置于多头注意力（MHA）模块内部，在应用旋转位置编码（RoPE）之前对查询向量（q）和键向量（k）进行归一化处理。为直观说明，以下内容摘录自我在《Qwen3 from-scratch implementation》[11]编写的分组查询注意力（GQA）层代码（GQA 中的 QK-Norm 应用方式与 OLMo 的 MHA 类似）：
如前文所述，QK-Norm 与后归一化配合使用可提升训练稳定性。需要注意的是，QK-Norm 并非由 OLMo 2 首创，其最早可追溯至 2023 年发表的《Scaling Vision Transformers》[12]论文。
2.3 OLMo 2 架构总结
简而言之，OLMo 2 值得关注的架构设计决策主要集中于 RMSNorm 的放置策略：将 RMSNorm 置于注意力模块和前馈网络模块之后（一种后归一化变体），而非之前。同时在注意力机制内部为查询向量和键向量添加 RMSNorm（即 QK-Norm）。这两项改进共同作用，有效稳定了训练损失。
下图进一步对比了 OLMo 2 与 Llama 3 的架构差异：可见除 OLMo 2 仍采用传统 MHA 而非 GQA 外，两者结构总体相似（但 OLMo 2 团队在三个月后发布了采用 GQA 的 320 亿参数变体）。
图 10：Llama 3 与 OLMo 2 的架构对比示意图
03 Gemma 3
Google 的 Gemma 系列模型始终保持着卓越的性能，但与 Llama 等热门模型相比，其关注度始终略显不足。
Gemma 的显著特征之一是其超大的词表规模（以便更好地支持多语言场景），以及更侧重 27B 参数规格（而非 8B 或 70B）。需注意的是，Gemma 2 也提供更小规格版本：1B、4B 与 12B。
27B 规格堪称最佳平衡点：性能远超 8B 模型，资源消耗却远低于 70B 模型，甚至能在 Mac Mini 上实现本地流畅运行。
那么 Gemma 3[13] 还有哪些亮点？如前文所述，DeepSeek-V3/R1 等模型采用 MoE 架构在固定模型规模下降低推理内存需求（后续讨论的其他模型也采用了 MoE 方案）。
Gemma 3 则运用了不同的技巧来减少计算开销 ------ 即滑动窗口注意力机制。
3.1 滑动窗口注意力机制
通过采用滑动窗口注意力机制（该技术最初在 2020 年由 LongFormer 论文[14]提出，Gemma 2[15] 也已采用），Gemma 3 团队大大降低了 KV 缓存的内存需求，如下图所示：
图 11：带有标注的 Gemma 3 论文示意图（ arxiv.org/abs/2503.19... ），展示了滑动窗口注意力机制对 KV 缓存的内存节省效果
那么什么是滑动窗口注意力机制？如果将常规自注意力视为全局注意力机制（每个序列元素可访问任意其他元素），那么滑动窗口注意力可理解为局部注意力 ------ 它会限制当前查询位置周围的上下文大小，具体如下图所示：
图 12：常规注意力（左）与滑动窗口注意力（右）对比示意图
需要注意的是，滑动窗口注意力可同时适用于多头注意力和分组查询注意力，Gemma 3 采用的是分组查询注意力版本。
如前文所述，滑动窗口注意力又称为"局部注意力"，因为其滑动窗口会围绕当前查询位置移动。相比之下，常规注意力是全局性的，每个词元都能访问所有其他词元。
不过，前代架构 Gemma 2 早已采用滑动窗口注意力。Gemma 3 的改进在于调整了全局注意力（常规）与局部注意力（滑动）的比例。
例如，Gemma 2 采用混合注意力机制，以 1:1 的比例结合滑动窗口（局部）与全局注意力，每个词元可关注附近 4K 词元的上下文窗口。
Gemma 2 在每一层都使用滑动窗口注意力，而 Gemma 3 将比例调整为 5:1 ------ 即每 5 个滑动窗口（局部）注意力层才设置 1 个全局注意力层。同时滑动窗口大小从 Gemma 2 的 4096 缩减至 1024。这种设计使模型更聚焦于高效的局部计算。
根据消融实验，滑动窗口注意力对建模性能的影响微乎其微，如下图所示：
图 13：带有标注的 Gemma 3 论文示意图（ arxiv.org/abs/2503.19... ），表明滑动窗口注意力对大语言模型输出困惑度的影响极小
虽然滑动窗口注意力是 Gemma 3 最显著的架构特性，但作为前文 OLMo 2 章节的延续，我们还需简要讨论其归一化层的布局策略。
3.2 Gemma 3 的归一化层布局策略
一个虽细微却值得关注的设计是：Gemma 3 在其分组查询注意力模块周围同时采用了前归一化（Pre-Norm）与后归一化（Post-Norm）的 RMSNorm 配置。
此设计虽与 Gemma 2 类似，但仍值得强调 ------ 因为它既不同于原始 Transformer（《Attention is all you need》）采用的后归一化，也区别于 GPT-2 推广并被后续众多模型架构采用的前归一化，同时与我们前文讨论的 OLMo 2 后归一化变体存在差异。
图 14：OLMo 2 与 Gemma 3 的架构对比图。注意 Gemma 3 中增加的归一化层
笔者认为这种归一化层布局是一种直观而高效的方案，它融合了前归一化和后归一化的双重优势。从实践角度看，适当增加的归一化操作通常利大于弊：在最坏情况下，即便存在冗余也仅会带来轻微的效率损失。由于 RMSNorm 在整体计算开销中占比极低，这种设计实际上不会产生明显影响。
3.3 Gemma 3 架构总结
Gemma 3 是一款性能优异的开放权重大语言模型，但其在开源社区中的认可度与其实力并不匹配。最引人注目的是其采用滑动窗口注意力提升效率的设计（未来若能与 MoE 结合将更具想象空间）。
此外，Gemma 3 采用独特的归一化层布局策略，在注意力模块和前馈网络模块前后均部署了 RMSNorm 层。
3.4 附加内容：Gemma 3n
Gemma 3 发布数月后，谷歌推出了专为移动设备优化的 Gemma 3n[16] 版本，其核心目标是实现在手机端高效运行。
Gemma 3n 为提升效率做出的改进之一是引入 Per-Layer Embedding（PLE）层。 该设计的核心思想是不将整个模型的所有参数都加载到昂贵的 GPU 内存中，而是只保留其中最核心、最常用的一部分，而文本、音频、视觉等模态的特定词元层嵌入则按需从 CPU 或 SSD 动态加载。
下图展示了 PLE 机制的内存优化效果：标准 Gemma 3 模型（可能指 4B 参数版本）标注的参数量为 5.44B。
图 15：经过标注的摘自谷歌 Gemma 3n 相关博客的示意图（ developers.googleblog.com/en/introduc... ），展示了 PLE 内存优化机制
5.44B 与 4B 参数的统计差异源于谷歌采用了一种特殊的参数计数方式：他们通常排除嵌入参数以使模型显得更小，但在需要凸显规模时（比如此处）又会将其计入。这种统计方式并非谷歌独有，已成为行业普遍做法。
另一项有趣的技术是 MatFormer[17] 概念（Matryoshka Transformer 的简称）。例如，Gemma 3n 使用一个共享的 LLM（Transformer）架构，可以将其切割成多个更小的、独立运行的子模型。每个子模型经过独立训练后均能单独运行，因此在推理时只需调用所需的部分（无需启动整个大模型）。
04 Mistral Small 3.1
于 Gemma 3 发布后不久在三月问世的 Mistral Small 3.1 24B[18] 值得关注 ------ 它在多项基准测试（除数学外）中性能超越 Gemma 3 27B，且推理速度更快。
Mistral Small 3.1 推理延迟低于 Gemma 3 的原因可能包括：定制化的分词器、KV 缓存压缩以及层数的精简。 其余部分则采用标准架构（如下图对比所示）。
图 16：Gemma 3 27B 与 Mistral 3.1 Small 24B 架构对比示意图
有趣的是，早期 Mistral 模型曾采用滑动窗口注意力机制，但该设计在 Mistral Small 3.1 中被弃用。由于 Mistral 改用标准的分组查询注意力（而非 Gemma 3 采用的滑动窗口注意力），其或许能通过调用经过深度优化的底层计算代码（如 FlashAttention）进一步降低推理开销。例如，笔者推测：滑动窗口注意力机制虽降低了内存占用，但未必会减少推理延迟 ------ 而这正是 Mistral Small 3.1 的核心优化目标。
END
本期互动内容 🍻
❓你是否同意"过去几年 Transformer 架构没有根本性突破"这一观点？为什么？
文中链接
1\][magazine.sebastianraschka.com/p/understan...](https://link.juejin.cn?target=https%3A%2F%2Fmagazine.sebastianraschka.com%2Fp%2Funderstanding-reasoning-llms "https://magazine.sebastianraschka.com/p/understanding-reasoning-llms") \[2\][github.com/rasbt/LLMs-...](https://link.juejin.cn?target=https%3A%2F%2Fgithub.com%2Frasbt%2FLLMs-from-scratch%2Fblob%2Fmain%2Fch05%2F07_gpt_to_llama%2Fconverting-llama2-to-llama3.ipynb "https://github.com/rasbt/LLMs-from-scratch/blob/main/ch05/07_gpt_to_llama/converting-llama2-to-llama3.ipynb") \[3\][github.com/rasbt/LLMs-...](https://link.juejin.cn?target=https%3A%2F%2Fgithub.com%2Frasbt%2FLLMs-from-scratch%2Fblob%2Fmain%2Fpkg%2Fllms_from_scratch%2Fllama3.py "https://github.com/rasbt/LLMs-from-scratch/blob/main/pkg/llms_from_scratch/llama3.py") \[4\][arxiv.org/abs/2305.13...](https://link.juejin.cn?target=https%3A%2F%2Farxiv.org%2Fabs%2F2305.13245 "https://arxiv.org/abs/2305.13245") \[5\][arxiv.org/abs/2307.09...](https://link.juejin.cn?target=https%3A%2F%2Farxiv.org%2Fabs%2F2307.09288 "https://arxiv.org/abs/2307.09288") \[6\][arxiv.org/abs/2401.06...](https://link.juejin.cn?target=https%3A%2F%2Farxiv.org%2Fabs%2F2401.06066 "https://arxiv.org/abs/2401.06066") \[7\][arxiv.org/abs/2201.05...](https://link.juejin.cn?target=https%3A%2F%2Farxiv.org%2Fabs%2F2201.05596 "https://arxiv.org/abs/2201.05596") \[8\][github.com/rasbt/LLMs-...](https://link.juejin.cn?target=https%3A%2F%2Fgithub.com%2Frasbt%2FLLMs-from-scratch%2Fblob%2Fmain%2Fch05%2F07_gpt_to_llama%2Fconverting-gpt-to-llama2.ipynb "https://github.com/rasbt/LLMs-from-scratch/blob/main/ch05/07_gpt_to_llama/converting-gpt-to-llama2.ipynb") \[9\][arxiv.org/abs/1706.03...](https://link.juejin.cn?target=https%3A%2F%2Farxiv.org%2Fabs%2F1706.03762 "https://arxiv.org/abs/1706.03762") \[10\][arxiv.org/abs/2002.04...](https://link.juejin.cn?target=https%3A%2F%2Farxiv.org%2Fabs%2F2002.04745 "https://arxiv.org/abs/2002.04745") \[11\][github.com/rasbt/LLMs-...](https://link.juejin.cn?target=https%3A%2F%2Fgithub.com%2Frasbt%2FLLMs-from-scratch%2Ftree%2Fmain%2Fch05%2F11_qwen3 "https://github.com/rasbt/LLMs-from-scratch/tree/main/ch05/11_qwen3") \[12\][arxiv.org/abs/2302.05...](https://link.juejin.cn?target=https%3A%2F%2Farxiv.org%2Fabs%2F2302.05442 "https://arxiv.org/abs/2302.05442") \[13\][arxiv.org/abs/2503.19...](https://link.juejin.cn?target=https%3A%2F%2Farxiv.org%2Fabs%2F2503.19786 "https://arxiv.org/abs/2503.19786") \[14\][arxiv.org/abs/2004.05...](https://link.juejin.cn?target=https%3A%2F%2Farxiv.org%2Fabs%2F2004.05150 "https://arxiv.org/abs/2004.05150") \[15\][arxiv.org/abs/2408.00...](https://link.juejin.cn?target=http%3A%2F%2Farxiv.org%2Fabs%2F2408.00118 "http://arxiv.org/abs/2408.00118") \[16\][developers.googleblog.com/en/introduc...](https://link.juejin.cn?target=https%3A%2F%2Fdevelopers.googleblog.com%2Fen%2Fintroducing-gemma-3n%2F "https://developers.googleblog.com/en/introducing-gemma-3n/") \[17\][arxiv.org/abs/2310.07...](https://link.juejin.cn?target=https%3A%2F%2Farxiv.org%2Fabs%2F2310.07707 "https://arxiv.org/abs/2310.07707") \[18\][mistral.ai/news/mistra...](https://link.juejin.cn?target=https%3A%2F%2Fmistral.ai%2Fnews%2Fmistral-small-3-1 "https://mistral.ai/news/mistral-small-3-1") **原文链接：** [artificialintelligencemadesimple.substack.com/p/a-look-th...](https://link.juejin.cn?target=https%3A%2F%2Fartificialintelligencemadesimple.substack.com%2Fp%2Fa-look-through-the-seven-years-of "https://artificialintelligencemadesimple.substack.com/p/a-look-through-the-seven-years-of")