Smol Training Playbook：
构建世界级大语言模型的秘诀

引言

训练一个高性能 LLM（大语言模型）究竟需要什么？

已发表的研究论文让这一切看起来简单明了：精心选择的架构、仔细筛选的数据集，再加上足够的算力。结果总是经过打磨的，消融实验（ablation）整洁有序。每一个决策事后看来都理所当然。但那些论文只呈现了最终奏效的部分，并带着些许”事后诸葛亮”的滤镜——它们不会记录凌晨两点调试 dataloader（数据加载器）的煎熬、loss（损失值）的突然飙升，也不会记录那个悄悄破坏训练过程的隐蔽 tensor parallelism（张量并行）bug（见后文！）。现实远比论文混乱，更具迭代性，充满了那些永远不会出现在最终论文里的决策。

跟我们一起走进 SmolLM3 训练过程的幕后——这是一个拥有 30 亿参数的多语言推理模型，在 11 万亿 token（词元）上完成训练。这不是一篇普通的指南，而是一张错综复杂的决策之网、探索之路与死胡同的全景拆解，最终引领我们深刻理解构建世界级语言模型究竟需要什么。

这也是我们长篇模型训练系列的收官之作。我们已经历过大规模数据集构建（FineWeb）、驱动数千块 GPU 协同运作（The Ultra-Scale Playbook），以及在训练每个阶段筛选最优评估方案（The LLM Evaluation Guidebook）。现在，我们将把这一切融为一体，构建一个强大的 AI 模型。我们将带你走完整段旅程——不只是那套最终奏效的配方，还有塑造每一个决策的失败、基础设施崩溃与调试过程。你将看到：前景光明的小规模消融实验有时无法在大规模训练中复现；为什么我们在训练 1 万亿 token 后重新启动了训练；我们如何在多语言、数学和代码等相互竞争的目标之间寻求平衡，同时保持强劲的英语能力；以及最终如何对一个混合推理模型进行 post-training（后训练）。

我们努力避免流水账式地罗列所有操作，转而以有组织的故事形式呈现这段探索历程。把这份指南当成一本写给所有人的手册——适用于那些想要从”我们有优质数据集和 GPU”走到”我们构建了一个真正强大的模型”的人。我们希望如此开放的分享能够帮助缩小研究与生产之间的鸿沟，让你的下一次训练稍微少一点混乱。

如何阅读本指南

你不需要从头到尾读完整份指南，事实上它已经太长，无法在一次坐下来时实际读完。它由几个相对独立的部分组成，任何一部分都可以单独阅读或跳过：

• 训练指南针（Training compass）： 关于是否应该自行预训练模型的高层次讨论。我们将引导你思考在烧光所有风投资金之前应该问自己的基本问题，以及如何系统地梳理决策过程。这是一个宏观章节；如果你想直接进入技术内容，完全没问题。
• 预训练（Pretraining）： 训练指南针之后的章节涵盖了构建自己预训练方案所需了解的一切：如何运行消融实验、选择评估指标、混合数据来源、做出架构选择、调整超参数（hyperparameter），以及最终如何熬过训练马拉松。如果你不打算从头预训练，但对 continued pretraining（持续预训练，又称 mid-training，中间训练）感兴趣，本章同样适用。
• 后训练（Post-training）： 在本部分，你将学到充分发挥预训练模型潜力所需的全部技巧。我们将覆盖完整的后训练字母表，从 SFT（监督微调）、DPO（直接偏好优化）、GRPO，到模型合并的黑魔法与炼金术。让这些算法真正奏效的知识往往是通过痛苦的教训换来的，我们将在这里分享我们的经验，希望能帮你少走一些弯路。
• 基础设施（Infrastructure）： 如果说预训练是蛋糕，后训练是糖霜和樱桃，那么基础设施就是工业级烤箱。没有它，一切都无从发生；如果它坏了，你轻松愉快的周日烘焙就会变成一场火灾隐患。关于如何理解、分析和调试 GPU 集群的知识散落在互联网各处——各种库、文档和论坛里。本章将系统梳理 GPU 布局、CPU/GPU/节点/存储之间的通信模式，以及如何识别并突破性能瓶颈。

那么，我们从哪里开始呢？选一个你最感兴趣的章节，出发吧！

训练指南针：为什么 → 训练什么 → 怎么训练

机器学习领域与优化有着近乎偏执的关系。我们痴迷于 loss curve（损失曲线）、模型架构和吞吐量；毕竟，机器学习从根本上就是在优化模型的损失函数。然而，在深入这些技术细节之前，有一个更根本的问题往往无人追问：我们真的需要训练这个模型吗？

如下方热力图所示，开源 AI 生态系统几乎每天都在发布世界级模型：Qwen、Gemma、DeepSeek、Kimi、Llama 🪦、OLMo，这份名单每个月都在变长。这些不只是研究原型或玩具示例：它们是生产级模型，覆盖了从多语言理解到代码生成和推理的惊人广度的用例。大多数还附带宽松的许可证和活跃的社区，随时准备帮助你使用它们。

这就引出了一个令人不安的观点：也许 你 根本不需要训练自己的模型。

以这种方式开启一篇”LLM 训练指南”似乎有些奇怪。但许多失败的训练项目并非因为超参数不当或代码有 bug 而失败；它们失败是因为有人决定训练一个根本不需要的模型。所以，在你承诺开始训练并深入研究 如何 执行之前，你需要回答两个问题：为什么 要训练这个模型？应该 训练什么模型？没有清晰的答案，你可能会浪费数月的算力和工程时间，最终构建出世界上已经有的东西，或者更糟——构建出没有人需要的东西。

让我们从 为什么 开始，因为不理解目的，你就无法对后续的任何事情做出连贯的决策。

为什么：那个没人想回答的问题

让我们直言不讳地说说实际发生的情况。某人（如果幸运的话）获得了一个 GPU 集群的访问权限——也许通过研究经费，也许通过公司的闲置算力——思维过程大致是这样的：“我们有 100 块 H100，用三个月。我们来训练一个模型吧！“模型大小被随意确定，数据集由手头现有的东西拼凑而成。训练开始了。六个月后，在烧掉了算力预算和团队士气之后，最终的模型无人问津——因为从来没有人问过 为什么。

以下是一些不应该训练模型的理由：

“我们训练了自己的模型”这种诱惑是强大的，但在投入大量时间和资源之前，问清楚这个问题是有意义的：我们为什么需要训练这个模型？

以下流程图引导了在启动大型预训练项目之前应该经历的思考过程。从技术角度来看，你应该首先找出是否存在一个现有模型，可以通过提示（prompt）或微调（fine-tune）来完成任务。

基本上有三个常见领域，自定义预训练是合理的：你想做前沿研究、你的生产用例有非常特定的需求，或者你想填补开放模型生态系统中的空白。让我们快速看看每一个。

研究：你想理解什么？

LLM 领域有大量研究工作可以做。LLM 研究项目的共同点是，你通常从一个明确定义的问题开始：

• 能否将这个新优化器的训练扩展到 100 亿+参数的模型？（参见 “Muon is Scalable for LLM Training.”）
• 仅凭强化学习（reinforcement learning），不经过 SFT（监督微调），能否产生推理能力？（参见 “DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning.”）
• 能否在纯合成教科书数据上训练出优秀的小模型？（参见 “Textbooks Are All You Need.”）
• 能否通过仅在开放许可数据上训练来实现有竞争力的性能？（参见 “The Common Pile v0.1: An 8TB Dataset of Public Domain and Openly Licensed Text.”）

让假设尽可能具体，并思考必要的实验规模，能够增加成功的概率。

生产：为什么不能使用现有模型？

公司无法将现成模型用于其用例，主要有三个原因。其中两个是技术原因，另一个是治理原因。

训练自己模型的第一个原因是 领域专一性（domain specificity）：当你的数据或任务涉及高度专业化的词汇或结构，而现有模型无法很好地处理时。例如，你可能想训练：

• 一个具有独特词汇表和长程依赖的 DNA 模型
• 一个需要深度熟悉领域专用术语和逻辑的法律或金融模型

第二个相关原因是 部署约束（deployment constraints）：当你需要一个针对特定硬件、延迟或隐私要求定制的模型时。这里的例子可能包括在无人机上运行的 LLM，或者使用 FPGA 等定制硬件的本地部署系统。

这里有一个简单的测试：花几天时间在 Qwen3、Gemma 3 或其他当前 SOTA（最先进）模型的基础上构建。你能否通过 prompting（提示）、工具使用或后训练达到你的性能目标？如果不能，那大概是时候训练自己的模型了。

即使满足你的需求所需的后训练预算是巨大的，它仍然可能比从头开始更划算。为你的模型进行 1 万亿 token 的微调，比从头开始训练 10 万亿+ token 更经济。

构建自己的内部语言模型的第三个原因是 安全与治理（safety and governance）：你需要对训练数据、模型行为和更新周期有完全的控制，因为你处于受监管的行业或高风险的应用场景中。你需要 确切 知道模型中包含了什么，并能够向监管机构证明。在某些情况下，你可能没有其他选择，只能构建自己的模型。

这些是公司训练内部模型的主要原因——那么发布开放模型的公司或组织呢？

战略性开源：你能填补某个空白吗？

有经验的 AI 实验室发布新开放模型的最常见原因之一，是他们发现了开源生态系统中一个特定的空白或新的 AI 用例。

这种模式通常是这样的：你注意到一个尚未被充分探索的领域——也许没有强大的支持超长上下文的设备端（on-device）模型，或者多语言模型存在但在低资源语言上表现薄弱，或者该领域正在向 Genie 3 这样的交互式世界模型发展，但还没有好的开放权重模型存在。

你有理由相信自己能做得更好：也许你整理了更好的训练数据，开发了更好的训练方案，或者有算力在别人无法做到的地方进行过度训练。你的目标是具体的：不是”有史以来最好的模型”，而是”最佳的 30 亿参数设备端模型”或”首个拥有 100 万 token 上下文窗口的小模型”。

这是一个真实的目标，成功能创造价值：开发者采用你的模型，它成为他人的基础设施，或者建立起技术可信度。但成功需要经验。你需要知道什么是真正可行的，以及如何在竞争激烈的空间中可靠地执行。为了让这一点更具体，让我们看看 Hugging Face 是如何思考这个问题的。

Hugging Face 的历程

那么，Hugging Face 为什么要训练开放模型？答案很简单：我们构建对开源生态系统有用的东西，填补很少有人在填补的空白。

这包括数据集、工具链和模型训练。我们启动的每一个 LLM 训练项目，都始于发现一个空白并相信我们能够贡献一些有意义的东西。

我们在 GPT-3 (Brown et al., 2020) 发布后开始了第一个 LLM 项目。当时，感觉没有其他人在构建开放的替代品，我们担心这些知识会被锁在少数几个行业实验室里。于是我们启动了 BigScience 研讨会，旨在训练 GPT-3 的开放版本。最终的模型是 BLOOM，由数十名贡献者历时一年，构建训练堆栈、tokenizer（分词器）和预训练语料库，预训练了一个 1750 亿参数的模型。

BLOOM 的继任者是 2022 年的 StarCoder (Li et al., 2023)。OpenAI 为 GitHub Copilot 开发了 Codex (Chen et al., 2021)，但它是闭源的。构建一个开源替代品显然会为生态系统提供价值。于是，在 ServiceNow 的合作下，在 BigCode 的旗帜下，我们构建了 The Stack 数据集，并训练了 StarCoder 15B 来复现 Codex。StarCoder2 (Lozhkov et al., 2024) 则来自于我们意识到可以训练更长时间，并认识到更小的模型训练更长时间可能比一个大模型更有价值。我们在数万亿 token 上训练了一个模型家族（30 亿/70 亿/150 亿参数），远超当时任何开放代码模型的训练量。

SmolLM 家族 遵循了类似的模式。我们注意到强大的小模型非常稀少，而我们刚刚构建了 FineWeb-Edu (Penedo et al., 2024)，这是一个强大的预训练数据集。SmolLM（1.35 亿/3.6 亿/17 亿参数）是我们的第一个版本。SmolLM2 (Allal et al., 2025) 专注于更好的数据和更长时间的训练，在多个方面达到了 SOTA 性能。SmolLM3 将参数规模扩展到 30 亿，同时增加了混合推理（hybrid reasoning）、多语言能力（multilinguality）和长上下文（long context）——这些都是社区在 2026 年重视的特性。

这种模式延伸到了预训练之外：我们训练了 Zephyr (Tunstall et al., 2023) 以证明 DPO（直接偏好优化）在规模上有效，启动了 Open-R1 来复现 DeepSeek-R1 的蒸馏 pipeline（流水线），并发布了 OlympicCoder 用于竞争性编程，在国际信息学奥林匹克竞赛中达到 SOTA 性能。我们还探索了其他模态，包括用于视觉的 SmolVLM (Marafioti et al., 2025) 和用于机器人的 SmolVLA (Shukor et al., 2025)。

希望本章已经让你相信，深入思考为什么要训练模型是有价值的。

对于本指南的其余部分，我们将假设你已经完成了这番自省，并有充分的理由进行训练。

训练什么：将目标转化为决策

现在你知道了 为什么 要训练，那 应该 训练什么？“训练什么”是指模型类型（dense（稠密）、mixture of experts（专家混合）、hybrid（混合）或其他新型架构）、模型大小、架构细节和数据混合。一旦确定了”为什么”，就可以推导出”训练什么”。例如：

• 设备端的快速模型 → 小型高效模型
• 多语言模型 → 大型 tokenizer（分词器）词汇表
• 超长上下文 → 混合架构

除了由用例驱动的决策之外，还有一些选择可以优化训练本身，使其更稳定、更高效或更快。这些决策并不总是那么明确，但你可以大致将决策过程分为以下几个阶段：

• 规划（Planning）： 在运行实验之前，将你的用例映射到需要决定的组件。你的部署环境决定了模型大小的约束。你的时间线决定了你可以承担哪些架构风险。你的目标能力决定了数据集要求。这个阶段是将”为什么”中的每个约束条件与”训练什么”中的具体规格联系起来。
• 验证（Validation）： 一旦有了起点和潜在修改列表，就要系统地测试。由于测试代价高昂，要专注于能够有意义地改善你用例性能或优化训练的变更。这就是消融实验（ablation）发挥作用的地方，在 “每个大模型都从一个小型消融实验开始” 中会详细介绍。

在接下来的章节中，你将了解定义模型的所有选项，以及如何通过系统化实验缩小选择范围。在深入之前，我们想分享一些关于如何组建团队和推进项目的经验——这些经验来自我们自己训练模型以及观察其他优秀团队构建伟大 LLM 的过程。

核心优势：速度与数据

当然，条条大路通罗马，但我们发现，迭代速度 是成功的 LLM 训练团队始终如一的制胜法宝。训练 LLM 本质上是一门”从做中学”的学问：你训练的次数越多，你的团队就会越强。所以，在每年训练一个模型的团队和每季度训练一个模型的团队之间，后者的进步速度要快得多。看看 Qwen 和 DeepSeek 的团队就知道了——如今已是家喻户晓的名字，他们有着以快速节奏持续发布新模型的长期记录。

除了迭代速度，迄今为止对 LLM 训练影响最大的方面是 数据整理（data curation）。人们天然倾向于钻研架构选择来改进模型，但在 LLM 训练中出类拔萃的团队，是那些对高质量数据的痴迷超过一切的团队。

另一个与迭代速度密切相关的方面是 团队规模。对于主要的预训练任务，你只需要少数几个人，加上足够的算力来执行。要在今天预训练一个类似 Llama 3 的模型，你可能只需要两三个人。一旦你开始涉足更多样化的训练和下游任务（多模态、多语言、后训练等），你需要增加更多人来在每个领域出类拔萃。

所以，从一个精干、装备齐全的小团队开始，每两三个月发布一个新模型，在短时间内你就能跻身顶尖。本指南的其余部分将专注于这个团队的日常技术工作！

每个大模型都从小规模消融实验起步

在开始训练 LLM（大语言模型）之前，我们需要做出许多决策，这些决策将决定模型的性能和训练效率。哪种架构最适合我们的使用场景？该用什么 optimizer（优化器）和学习率调度？应该混合哪些数据源？

这些决策是如何做出的，是个常被问到的问题。人们有时期待这需要深思熟虑。诚然，战略性思考至关重要——正如我们在上一节中所讲——但光靠推理是不够的。LLM 领域并不总是符合直觉，对”应该有效”的假设有时在实践中行不通。

举个例子，使用看起来”质量最高的数据”并不总能带来更强的模型。以 arXiv 为例，它汇集了人类大量的科学知识。直觉上，训练如此丰富的 STEM（科学、技术、工程、数学）数据应该能产出更优秀的模型，对吗？但实践中并非如此，尤其对于较小的模型，这甚至可能损害性能 (Shao et al., 2024)。为什么？arXiv 论文虽然知识丰富，但高度专业化，写作风格狭窄，与模型最擅长学习的多样化通用文本差异较大。

那么，如果死盯着问题苦思冥想没有用，我们怎么知道什么有效？我们像优秀的实证主义者一样，大量做实验！机器学习不是纯粹的数学，它本质上是一门实验科学。

由于这些实验将指导我们许多关键决策，把它们设置好真的非常重要。我们对实验基本上有两个核心要求：

1. 速度： 实验要尽可能快，这样我们才能频繁迭代。能跑的消融实验越多，能验证的假设就越多。
2. 可靠性： 实验应具备强判别力。如果我们观察的指标无法在早期有意义地区分不同设置，消融实验可能就没什么收获（如果指标噪声太大，我们还可能在追逐噪声！）。更多细节请参考我们关于将 FineWeb 扩展到 1000+ 种语言的博客文章。

在设置消融实验之前，我们需要先对架构类型和模型规模做出一些基础性选择。这些决策——由我们的指南针引导——影响着我们选用哪个训练框架、如何分配算力预算，以及从哪个基线出发。

对于 SmolLM3，我们选择了 3B 参数的密集型 Llama 风格架构，因为我们的目标是小型设备端模型。但正如你将在”设计模型架构”中看到的，mixture of experts（专家混合，MoE）或 hybrid model（混合模型）可能更适合你的使用场景，不同的模型规模也有不同的权衡取舍。我们稍后会深入探讨这些选择，并告诉你如何做决定。现在，让我们从最实际的第一步开始：选择你的基线。

选择你的基线

每个成功的模型都建立在经过验证的基础上，并针对自身需求进行修改。当 Qwen 训练其第一个模型系列时 (Bai et al., 2023)，他们以 Llama 的架构为起点。当 Meta 训练 Llama 3 时，他们以 Llama 2 为起点。Kimi K2 则从 DeepSeek-V3 的 MoE 架构出发。这不仅适用于架构，也适用于训练超参数和优化器。

为什么？设计良好的架构和训练设置需要许多组织经过多年迭代。标准 transformer（变换器）和 Adam 等优化器经过了数千次实验的打磨。人们发现了它们的失效模式，调试了不稳定性，优化了实现方式。从经过验证的基础出发意味着继承了所有这些积累的知识。从头开始则意味着要自己重新踩每一个坑。

一个好的起点架构应该：

• 符合你的约束条件 ，与你的部署目标和使用场景对齐
• 经过规模验证 （在相似或更大规模的万亿 token 训练中得到验证）
• 文档完善 ，具有已知的、在开放模型中被证明有效的超参数
• 具有良好的框架支持 （理想情况下，应在你考虑的训练框架和计划使用的推理框架中得到支持）

以下是截至撰写本文时（2026 年初）各类架构的强力 2025 基线选项（非穷举列表）：

找到你的架构类型，选择一个参数量接近你目标的基线。不必想太多，因为你起步的架构并非一成不变。在下一节中，你将看到如何从基线出发，得到最适合你的最终架构。

修改你的基线：去风险化的纪律

现在你有了一个有效且适合你使用场景的基线。你可以到此为止，直接训练它，假如数据混合足够好，很可能也能得到一个不错的模型。很多成功项目就是这么做的。但基线并非针对你的特定约束进行了优化；它们是为构建者自己的使用场景和部署目标而设计的。这意味着可能存在值得做的修改，以更好地与你的目标对齐。然而，每一次架构变更都伴随着风险：可能提升性能，可能拖垮性能，也可能毫无效果而白白消耗消融算力。

让你保持正轨的纪律叫做 去风险化（derisking） ：未经测试证明有效的改动，一律不要采用。

棘手之处在于，你的基线和训练设置有许多可以修改的组件：attention mechanism（注意力机制）、positional encoding（位置编码）、activation function（激活函数）、optimizer（优化器）、训练超参数、normalization scheme（归一化方案）、模型布局等等。每一项都代表一个潜在的实验，而这些组件往往以非线性方式相互作用。你既没有时间也没有算力测试所有内容或探索所有交互。

因此，先针对当前基线测试有潜力的改动。当某项改动有效时，将其整合以创建新基线，然后再针对该基线测试下一项改动。如果你的算力预算允许，可以逐一测试每项改动并进行留一法分析。不要陷入对每个超参数进行穷举网格搜索、或测试每一个新出现的架构变体的陷阱。

现在你已经知道如何通过战略性规划识别有潜力的方向，是时候进入实证验证阶段了。在接下来的几节中，我们将展示如何在实践中测试这些改动。我们将介绍如何建立可靠的实验、解读结果，以及避免常见陷阱。然后，在后续章节中，我们将通过具体示例演示如何测试流行的架构、数据、基础设施和训练决策。

选择训练框架

我们需要做的第一个决定是使用哪个框架来训练模型，进而用于所有消融实验。

这一选择涉及三个关键考量之间的平衡：

1. 框架必须支持我们的目标架构，或者允许我们轻松扩展它。
2. 它需要稳定且生产就绪，不会在训练中途莫名其妙地崩溃。
3. 它应提供强大的 throughput（吞吐量），让我们能快速迭代并充分利用算力预算。

在实践中，这些要求可能相互拉扯，产生权衡取舍。让我们看看一些可用选项：

该表格总结了主流框架之间的关键权衡。前三个框架的代码行数来自 TorchTitan 技术报告 (Liang et al., 2025)。让我们更详细地讨论每一个：

• NVIDIA 的 Megatron-LM 已经存在多年，久经实战检验。它是 Kimi K2 (Team et al., 2025) 等模型的训练引擎；吞吐量出色，拥有我们所需的大部分生产特性。但成熟带来了复杂性：对新手来说，代码库可能难以导航和修改。
• DeepSpeed 属于类似的类别。它是 ZeRO 优化的先驱，支撑了 BLOOM 和 GLM 等模型的训练。与 Megatron-LM 一样，它经过了广泛的实战检验和优化，但同样面临复杂性挑战。庞大的代码库（共 194k 行）在入门时可能令人望而生畏，尤其是在实现自定义功能或调试意外行为时。
• 另一方面，PyTorch 最近推出的 TorchTitan 库则轻量得多，由于代码库紧凑且模块化，更易于导航。它具备预训练所需的核心功能，非常适合快速实验。然而，由于相对较新，它不如前者经受过广泛实战检验，并且在积极开发中可能仍有些不稳定。
• Nanotron 是我们从头构建的框架。这给了我们充分的灵活性和对大规模预训练的深入理解——这些洞察后来演变为 Ultra-Scale Playbook。自从我们开源这个库以来，也获得了社区的宝贵反馈，尽管大多数情况下我们需要先自己进行实战检验。该框架现在支持训练所需的所有生产特性，但我们仍在完善 MoE 支持等领域。

在我们的场景下从头构建是合理的，但这需要团队在专业知识和时间上的大量投入，用于调试问题和补充缺失功能。一个强有力的替代方案是 fork 一个现有框架并针对你的需求进行增强。例如，Thinking Machines Lab 将他们的内部预训练库构建为 TorchTitan 的一个 fork。

最终，你的选择将取决于团队的专业知识、目标功能，以及你愿意在开发投入与使用最生产就绪选项之间如何取舍。

如果多个框架都能满足你的需求，请在你的特定硬件上比较它们的吞吐量。对于快速实验和速度测试，更简洁的代码库往往更胜一筹。

消融实验设置

选定框架之后，我们需要设计消融实验方案。我们需要的实验既要足够快以便快速迭代，又要足够大以提供有意义的信号并能迁移到最终模型。

建立我们的消融实验框架

消融实验的目标是在小规模下运行实验，并获得可以自信地外推到最终生产运行的结果。

主要有两种方法。第一种，我们可以取目标模型大小，用较少的 token 对其进行训练。对于 SmolLM3 的消融实验，我们在 100B token 上训练了完整的 3B 模型，而非最终的 11T。第二种，如果我们的目标模型太大，可以训练一个更小的代理模型用于消融实验。例如，当 Kimi 开发其具有 32B 激活参数的 1T 参数 K2 模型时，对所有消融实验使用完整尺寸的代价过于高昂，因此他们在一个具有 0.5B 激活参数的 3B MoE 上运行了部分消融实验 (Team et al., 2025)。

一个关键问题是，这些小规模发现是否真的能够迁移。根据我们的经验，如果某件事在小规模下损害了性能，你可以自信地在大规模下将其排除。但如果某件事在小规模下有效，你需要确保已经训练了合理数量的 token，才能以较高概率得出这些发现会外推到更大规模的结论。训练时间越长，消融模型越接近最终模型，效果越好。

我们决定对所有消融实验使用一个基线 vanilla transformer（标准变换器）。我们的主要设置是一个遵循 Llama 3.2 1B 架构的 1B transformer，在 45B token 上训练。使用此 Nanotron 配置在八张 H100 的节点上大约需要一天半时间（每 GPU 每秒 42k token）。

我们的基线 1B 配置以结构化的 YAML 格式捕获了所有关键训练细节。以下是关键部分：

## Datasets and mixing weights
data_stages:
- data:

    dataset:
      dataset_folder:
      - fineweb-edu
      - stack-edu-python
      - finemath-3plus

      dataset_weights:
      - 0.7
      - 0.2
      - 0.1

## Model architecture, Llama 3.2 1B configuration
model:
  model_config:
    hidden_size: 2048
    num_hidden_layers: 16
    num_attention_heads: 32
    num_key_value_heads: 8  
    intermediate_size: 8192
    max_position_embeddings: 4096
    rope_theta: 50000.0
    tie_word_embeddings: true

## Training hyperparameters, AdamW with cosine schedule
optimizer:
  clip_grad: 1.0
  learning_rate_scheduler:
    learning_rate: 0.0005
    lr_decay_starting_step: 2000
    lr_decay_steps: 18000
    lr_decay_style: cosine
    lr_warmup_steps: 2000
    lr_warmup_style: linear
    min_decay_lr: 5.0e-05
  optimizer_factory:
    adam_beta1: 0.9
    adam_beta2: 0.95
    adam_eps: 1.0e-08
    name: adamW

## Parallelism, 1 node
parallelism:
  dp: 8  # Data parallel across 8 GPUs
  tp: 1  # No tensor or pipeline parallelism needed at 1B scale
  pp: 1 

## Tokenizer
tokenizer:
  tokenizer_max_length: 4096
  tokenizer_name_or_path: HuggingFaceTB/SmolLM3-3B

## Batch size, sequence length and total training for 30B tokens
tokens:
  batch_accumulation_per_replica: 16
  micro_batch_size: 3 # GBS (global batch size)=dp * batch_acc* MBS * sequence=1.5M tokens
  sequence_length: 4096
  train_steps: 20000 # GBS * 20000 = 30B
 
...

在我们的消融实验中，我们将根据测试内容修改不同的部分，同时保持其他所有内容不变：model 部分用于架构选择，optimizer 部分用于优化器和训练超参数，data_stages 部分用于数据整理。

在运行消融实验时，一些架构改动会显著改变参数数量。例如，从 tied embedding（共享嵌入）切换到 untied embedding（独立嵌入）会使嵌入参数翻倍，而使用 grouped query attention（分组查询注意力）或 multi-query attention（多查询注意力）代替 multi-head attention（多头注意力）会大幅减少注意力参数（我们很快将详细讨论所有这些内容）。

为了确保公平比较，我们需要跟踪参数数量，并偶尔调整其他超参数（如 hidden size 或层数）以保持模型规模大致相同。以下是我们用来估算不同配置参数数量的一个简单函数：

from transformers import LlamaConfig, LlamaForCausalLM

def count_parameters(
    tie_embeddings=True,
    num_key_value_heads=4,
    num_attention_heads=32,
    hidden_size=2048,
    num_hidden_layers=16,
    intermediate_size=8192,
    vocab_size=128256,
    sequence_length=4096,
):
    config = LlamaConfig(
        hidden_size=hidden_size,
        num_hidden_layers=num_hidden_layers,
        num_attention_heads=num_attention_heads,
        num_key_value_heads=num_key_value_heads,
        intermediate_size=intermediate_size,
        vocab_size=vocab_size,
        max_position_embeddings=sequence_length,
        tie_word_embeddings=tie_embeddings,
    )
    model = LlamaForCausalLM(config)  
    return f"{sum(p.numel() for p in model.parameters())/1e9:.2f}B"

我们还提供了一个交互式工具，用于可视化密集型 transformer 的 LLM 参数分布。在做出架构决策或为消融实验设置配置时，这非常实用。

理解什么有效：评估

一旦我们启动消融实验，如何知道什么有效，什么无效？

训练模型的人的第一直觉可能是看 loss（损失），是的，这很重要。你希望看到它平稳下降，没有剧烈波动或不稳定。对于许多架构选择，loss 与下游性能的相关性良好，有时就足够了 (Y. Chen et al., 2025)。然而，仅看 loss 并不总是可靠的。以数据消融为例，你会发现在 Wikipedia 上训练比在网页上训练得到更低的 loss（下一个 token 更容易预测），但这并不意味着你会得到更有能力的模型。同样，如果我们在不同运行之间更换 tokenizer（分词器），损失值之间无法直接比较，因为文本的切分方式不同。一些改动可能专门影响某些能力，如推理和数学，但会被平均 loss 掩盖。最后，模型可以在预训练 loss 收敛后继续在下游任务上提升 (Liu et al., 2022)。

我们需要更细粒度的评估来了解全貌，理解这些微妙的效果。一个自然的方法是使用下游评估来测试知识、理解、推理以及对我们重要的任何其他领域。

对于这些消融实验，专注于能提供良好早期信号并避免嘈杂 benchmark（基准测试）的任务很有用。在 FineTasks 和 FineWeb2 中，可靠的评估任务由四个关键原则定义：

• 单调性： 随着模型训练时间增加，benchmark 分数应持续提升。
• 低噪声： 当我们用相同设置但不同随机种子训练模型时，benchmark 分数不应剧烈波动。
• 高于随机的性能： 许多能力只在训练后期才涌现，因此在较长时间内仍处于随机水平的任务对消融实验没有用。例如，多选格式的 MMLU 就是这种情况，我们稍后会解释。
• 排名一致性： 如果一种方法在早期阶段优于另一种，这种顺序应在训练持续过程中保持稳定。

任务的质量也取决于任务表述方式（我们如何向模型提问）和指标选择（我们如何计算答案得分）。

三种常见的任务表述是 multiple choice format（MCF，多选格式） 、cloze formulation（CF，完形填空表述） 和 free-form generation（FG，自由生成） 。MCF 要求模型从明确呈现在提示中并以 A/B/C/D 为前缀的选项中选择一个（如 MMLU 的做法）。CF 中，我们比较不同选项的可能性，以确定哪个更可能，而无需在提示中提供这些选项。FG 中，我们查看给定提示的 greedy generation（贪婪生成）的准确性。FG 需要模型有大量的潜在知识，通常难度过大，对于在完整训练运行前的短暂预训练消融实验来说实用性不足。因此，我们在运行小规模消融实验时专注于多选表述（MCF 或 CF）。

研究还表明，模型在训练早期难以应对 MCF，因此 CF 对于早期信号更好 (Du et al., 2025; Gu et al., 2025; J. Li et al., 2025)。因此，我们对小规模消融实验使用 CF，并在主运行中整合 MCF（因为 MCF 在训练后期提供更好的信号）。为了在序列似然评估（如 CF）中给模型答案打分，我们将准确率计算为正确答案具有最高 log probability（对数概率，按字符数归一化）的问题百分比。这种归一化可以防止对较短答案的偏好。

我们的消融实验评估套件包含来自 FineWeb 消融实验的 benchmark，但不包括我们发现噪声过大的 SIQA。我们添加了 GSM8K 和 HumanEval 等数学和代码 benchmark，以及用于长上下文消融实验的长上下文 benchmark RULER。这一任务聚合测试了各种格式下的世界知识、推理和常识，如下表所示。为了以增加少量噪声为代价加速评估，我们对每个 benchmark 只评估 1,000 道题（GSM8K、HumanEval 和 RULER 除外，在 3B SmolLM3 消融实验中我们使用完整版本，但在 1B 实验中省略）。我们使用 CF 来评估所有多选 benchmark，如前文所述。请注意，对于多语言消融实验和实际训练，我们会添加更多 benchmark 来测试多语言能力，详见后文。这些评估使用 LightEval 运行。以下是每个 benchmark 关键特性的摘要：

让我们看几道示例题，以具体了解这些评估实际测试的内容：

你可以在交互版本中浏览示例，了解每个 benchmark 中的题目类型。请注意，MMLU 和 ARC 以多选形式测试事实知识，GSM8K 需要计算数学问题的数值答案，而 HumanEval 则需要生成完整的 Python 代码。这种多样性确保我们在整个消融实验过程中测试了模型能力的不同方面。

消融实验的数据混合方案？

对于 架构消融实验 ，我们在一个固定的高质量数据集混合上进行训练，这些数据集能在各类任务上提供早期信号。我们使用英语（FineWeb-Edu）、数学（FineMath）和代码（Stack-Edu-Python）。架构发现应该能很好地外推到其他数据集和领域，包括多语言数据，因此我们可以保持数据混合简单。

对于 数据消融实验 ，我们采取相反的方法：我们固定架构，系统地改变数据混合，以了解不同数据源如何影响模型性能。

扎实的消融实验设置的真正价值不仅仅是构建一个好模型。当主训练运行中出现问题时（无论我们做多少准备，这都会发生），我们希望对每个决定都有信心，并能快速识别哪些组件未经测试。这种准备可以节省调试时间，保护我们未来的心理健康。

估算消融实验成本

消融实验很棒，但需要 GPU 时间。了解这些实验的成本是值得的。下表显示了我们 SmolLM3 预训练的完整算力明细：主运行（含偶发停机时间）、训练前后的消融实验，加上因意外扩展问题而被迫重启和一些调试所消耗的算力（我们稍后将详细说明）。

这些数字揭示了一个重要事实：消融实验和调试共消耗了 161,280 GPU 小时，超过我们主训练运行成本的一半（276,480 GPU 小时）。在 SmolLM3 的开发过程中，我们进行了超过 100 次消融实验：预训练消融实验花费了 20 天，中间训练消融实验花费了 10 天，从上述意外训练问题中恢复花费了 7 天。

这凸显了为什么消融实验成本必须纳入你的算力预算：计划时要将训练成本加上消融实验，再加上一个应对意外的缓冲。如果你的目标是达到 SOTA（最先进）性能、实现新架构改动，或者还没有经过验证的配方，消融实验就会成为一个重要的成本中心，而非小打小闹的实验。

在我们开始设计模型架构之前，让我们建立一些每个运行实验的人都应该遵守的基本规则。

参与规则

TL;DR（太长不读）：保持偏执。

验证你的评估套件。 在训练任何模型之前，确保你的评估套件能够复现你将与之比较的模型的已发布结果。如果任何 benchmark 是生成式的（例如 GSM8k），要格外谨慎，手动检查几个样本，确保提示格式正确，以及任何后处理都能正确提取信息。由于评估将指导每一个决定，把这一步做对对项目的成功至关重要！

测试每一个变更，无论多小。 不要低估那个看似无害的库升级或”只改了两行”的提交的影响。这些小变化可能引入细微的 bug 或性能偏移，从而污染你的结果。你需要一个在对你重要的情况下有强大测试套件的库，以避免回归。

每次只改一件事。 实验之间保持其他所有条件完全相同。某些变化可能以意想不到的方式相互作用，因此你需要先评估每个变化的单独贡献，然后尝试组合它们以查看整体影响。

训练足够多的 token 并使用充分的评估。 正如我们前面提到的，你需要确保评估套件有良好的覆盖率，并训练足够长的时间以获得可靠信号。在这里走捷径会导致嘈杂的结果和错误的决策。

遵循这些规则可能感觉过于谨慎，但替代方案是花数天时间调试神秘的性能下降，结果发现是几天前一个不相关的依赖项更新造成的。黄金原则：一旦你有了一个好的设置， 任何变更都不应未经测试就投入使用！

设计模型架构

现在我们的实验框架已经到位，是时候做出定义模型的重大决策了。我们做出的每一个选择——从模型规模到注意力机制（attention mechanism）再到分词器（tokenizer）——都会产生约束和机遇，影响模型训练和使用。

请记住训练罗盘：在做任何技术选择之前，我们需要对为什么和是什么有清晰的认识。我们为什么要训练这个模型，它应该是什么样的？

这听起来显而易见，但正如我们之前解释的那样，在这里保持深思熟虑会塑造我们的决策，并使我们不至于迷失在无尽的实验空间中。我们的目标是打造一个英文领域的 SOTA 模型吗？长上下文是优先考虑的吗？还是我们在尝试验证一种新架构？这些情况下的训练循环可能看起来相似，但我们运行的实验和接受的权衡会有所不同。早早回答这些问题有助于我们决定如何在数据和架构工作之间分配时间，以及在开始训练之前在每个方面进行多少创新。

因此，让我们以身作则，回顾一下指导 SmolLM3 设计的目标。我们希望构建一个适用于设备端应用的强大模型，具备有竞争力的多语言性能、扎实的数学和编程能力，以及强健的长上下文处理能力。如我们之前所提到的，这促使我们选择了拥有 3B 参数的密集模型（dense model）：足够大以具备强大能力，但又足够小以能舒适地运行在手机上。考虑到边缘设备的内存限制和我们的项目时间线（大约三个月），我们选择了密集 Transformer 而非混合专家模型（MoE）或混合架构。

我们有一个在较小规模（1.7B 参数）下针对英文的 SmolLM2 成熟方案，但扩展规模意味着需要重新验证所有内容，并应对新挑战，如多语言性和扩展上下文长度。明确的目标塑造了我们的方法。例如，在 SmolLM2 中，我们在预训练结束时难以扩展上下文长度，因此对于 SmolLM3，我们从一开始就做出了架构选择——例如使用 NoPE 和文档内掩码（intra-document masking，详见后文）——以最大化我们成功的机会，而这果然奏效了。

一旦目标明确，我们就可以开始做出将其付诸实践的技术决策。在本章中，我们将介绍对这些核心决策的系统性方法：架构、数据和超参数。将此视为战略规划阶段——把这些基础搞对，将使你在实际的训练马拉松中免于代价高昂的错误。

架构选择

如果你看看 Qwen3、Gemma 3 或 DeepSeek-V3 等近期模型，你会发现尽管它们之间存在差异，但都共享同一基础：2017 年提出的 Transformer 架构 (Vaswani et al., 2023)。其基本结构多年来变化不大，但其核心组件已有所改进。无论你是在构建密集模型、混合专家模型（mixture of experts model），还是混合架构，你都是在使用相同的构建模块。

这些改进来自于各团队对更好性能的追求，以及对特定挑战的应对：推理时的内存约束、大规模训练的不稳定性、处理更长上下文的需求。一些改动，如从多头注意力（multi-head attention）转向计算效率更高的分组查询注意力（grouped query attention，GQA (Ainslie et al., 2023)），已被广泛采用。另一些，如不同的位置编码（positional encoding）方案，仍在讨论之中。最终，今天的实验将会凝结成明天的基线。

那么，大型语言模型（LLM）今天实际在用什么？让我们看看领先模型已经收敛到了什么方案。遗憾的是，并非所有模型都公开了其训练细节，但我们从 DeepSeek、OLMo、Kimi 和 SmolLM 等模型家族中获得了足够的透明度，可以看到当前的全貌：

如果你还不理解其中一些术语，例如 MLA、NoPE 或 WSD，不用担心；我们将在本节中逐一解释。现在，只需注意其中的多样性：不同的注意力机制（MHA、GQA、MLA）、位置编码（RoPE、NoPE、partial RoPE）和学习率调度（cosine、multi-step、WSD）。

面对这一长串架构选择，甚至很难知道从哪里开始。和大多数此类情况一样，我们将一步一步来，逐渐积累所有必要的知识。我们将首先关注最简单的基础架构（密集模型），并详细研究每个架构方面。之后，我们将深入探讨 MoE 和混合模型，并讨论何时使用它们是个好选择。最后，我们将探索分词器（tokenizer）——一个经常被忽视和低估的组件。我们应该使用现有的还是训练自己的？我们又如何评估我们的分词器是否优质？

我们将从每个 LLM 的核心开始：注意力机制。

注意力机制（Attention）

Transformer 架构中最活跃的研究领域之一是注意力机制。尽管前馈层（feedforward layer）在预训练期间主导了计算量，但注意力在推理时（尤其是长上下文时）成为主要瓶颈，推高了计算成本和 GPU 内存需求，降低了吞吐量。让我们简要了解主要的注意力机制及其在能力与速度之间的权衡。

我的注意力需要多少个头（head）？

多头注意力（Multi-head attention，MHA） 是随原始 Transformer 架构引入的标准注意力机制 (Vaswani et al., 2023)。其核心思想是拥有 N 个注意力头（attention head），每个头独立执行相同的检索任务：将隐藏状态转换为查询（queries）、键（keys）和值（values），然后使用当前查询通过与键（K）的匹配来检索最相关的 token，最后转发与匹配 token 关联的值（V）。在推理时，我们不需要重新计算过去 token 的 KV 值；我们可以复用它们。存储过去 KV 值的内存被称为 KV 缓存（KV cache）。随着上下文窗口增长，这个缓存可能迅速成为推理瓶颈，消耗大量 GPU 内存。以下是一个简单的计算，用于估算采用 MHA 的 Llama 3 架构在序列长度为 8,192 时的 KV 缓存大小 $s_{KV}$：

请注意，前导因子 2 来自于同时存储键和值的缓存。如你所见，缓存大小随序列长度线性增长——但上下文窗口已呈指数级增长，现已达到数百万 token。提高缓存效率将使在推理时扩展上下文变得容易得多。

一个自然的问题是：我们真的需要为每个头提供新的 KV 值吗？可能不需要，多查询注意力（multi-query attention，MQA） (Shazeer, 2019) 和 分组查询注意力（grouped query attention，GQA） (Ainslie et al., 2023) 都解决了这个问题。最简单的选项是在所有头之间共享 KV 值，从而将 KV 缓存大小除以 $n_{heads}$（对于 Llama 3 70B 来说减少了 64 倍）！这就是 MQA 的思路，它被一些模型（如 StarCoder）用作 MHA 的替代方案。然而，这种方法可能会放弃我们不愿舍弃的一些注意力容量。另一个选项是在头的组之间共享 KV 值——例如，可能有四个头共享相同的 KV 值。这就是 GQA 方法，它在 MQA 和 MHA 之间取得了中间地带。

更近期，DeepSeek-V2 引入了多头潜在注意力（multi-head latent attention，MLA） (DeepSeek-AI et al., 2024)，使用了不同的策略来压缩缓存（V3 中也使用了该策略）：它不是减少 KV 值的数量，而是减少其大小，仅存储一个可在运行时解压缩为 KV 值的潜在变量（latent variable）。通过这种方法，DeepSeek 设法将缓存减少到相当于 GQA 2.25 组的大小，同时实现了比 MHA 更强的性能！为了使其与 RoPE（旋转位置嵌入，Rotary Positional Embedding）协同工作，需要一个带有额外小潜在向量的小调整。对于 DeepSeek-V2，主潜在变量选择了 $4*dim_{head}$，RoPE 部分选择了 $1/2*dim_{head}$，总计 $4.5*dim_{head}$。这同时用于 K 和 V，从而去掉了前导因子 2。

以下图形展示了每种注意力机制的可视化说明：

下表比较了本节中讨论的注意力机制。为简单起见，我们比较每个 token 使用的参数量；如果要计算总内存，只需乘以每个参数的字节数（通常为 2）和序列长度。

现在让我们看看这些注意力机制在实际实验中的表现！

消融实验——GQA 优于 MHA

我们的基线模型使用 32 个查询头和 8 个 KV 头，对应于比率为 32 / 8 = 4 的 GQA。如果我们使用 MHA，或者使用更少的 KV 头和更高的 GQA 比率，性能会如何变化？

更改 KV 头的数量会影响参数数量，尤其是在 MHA 的情况下。为了保持一致性，我们为 MHA 运行调整了层数，因为否则会存在 100M+ 的参数差异；对于其余情况，我们保持默认的 16 层。我们将比较 MHA、MQA 以及四种 GQA 设置（比率 2、4、8、16）。你可以在此处找到 Nanotron 配置文件。

观察消融实验结果，我们发现 MQA 和仅 16 组的 GQA（分别只使用 1 和 2 个 KV 头）的性能明显弱于 MHA。另一方面，具有 2、4 和 8 组的 GQA 配置大致匹配 MHA 性能：

这些结果在损失曲线和下游评估中均保持一致。我们在 HellaSwag、MMLU 和 ARC 等基准测试中观察到这一点非常清晰，而 OpenBookQA 和 WinoGrande 等基准测试则显示出一些噪声。

根据这些消融实验，GQA 是 MHA 的可靠替代方案。它在保留性能的同时，推理效率更高。一些近期模型已采用 MLA 以实现更大的 KV 缓存压缩，尽管它尚未被广泛采用。由于在进行消融实验时 MLA 尚未在 Nanotron 中实现，我们没有对其进行消融。对于 SmolLM3，我们使用了 4 组的 GQA。

除了注意力架构本身之外，我们在训练期间使用的注意力模式也很重要。让我们来看看。

文档掩码（Document Masking）

我们如何在训练序列中应用注意力，既影响计算效率，也影响模型性能。这引出了文档掩码以及数据加载器中如何组织训练样本这一更广泛问题。

在预训练期间，我们使用固定的序列长度进行训练，但我们的文档长度是可变的。一篇研究论文可能有 10k token，而一个简短的代码片段可能只有几百个。我们如何将可变长度的文档放入固定长度的训练序列中？用填充（padding）将较短的文档填充到目标长度会在无意义的填充 token 上浪费计算量。取而代之，我们使用打包（packing）：将文档随机打乱并用序列结束（EOS）token 连接起来，然后将结果分割成与序列大小匹配的固定长度块。

以下是实践中的效果：

File 1: "Recipe for granola bars..." (400 tokens) <EOS>
File 2: "def hello_world()..." (300 tokens) <EOS>  
File 3: "Climate change impacts..." (1000 tokens) <EOS>
File 4: "import numpy as np..." (3000 tokens) <EOS>
...

After concatenation and chunking into 4k sequences:
Sequence 1: [File 1] + [File 2] + [File 3] + [partial File 4]
Sequence 2: [rest of File 4] + [File 5] + [File 6] + ...

如果一个训练序列足够长以填充我们的 4k 上下文，它可能包含一个完整的文件，但大多数文件比这短，因此序列通常包含多个随机文件的拼接。

在标准因果掩码（causal masking）下，token 可以注意到打包序列中所有之前的 token。在上面的例子中，文件 4 Python 脚本中的一个 token 可以注意到 granola bars 菜谱、函数定义和气候变化文章。

让我们看看一个典型的 4k 预训练上下文包含什么内容。一项快速分析表明，Common Crawl 和 GitHub 数据集中相当大比例（约 80–90%）的文件少于 2k token。以下图表检查了本指南中使用的更新数据集的 token 分布：

FineWeb-Edu、DCLM、FineMath 和 Python-Edu 中超过 80% 的文档也包含少于 2k token。这意味着，使用 2k 或 4k 训练序列和标准因果掩码时，绝大多数 token 会将计算量花费在注意力指向打包在一起的无关文档上。

除了计算效率低下的问题之外，@zhao2024 还发现这种方法引入了来自无关内容的噪声，可能会降低性能。他们建议使用文档内掩码（intra-document masking），我们修改注意力掩码，使 token 只能注意到同一文档中的之前 token。以下可视化说明了其区别。

Zhu et al. (2025) 在 SkyLadder 中发现了文档内掩码的类似好处，但他们提供了不同的解释：他们发现较短的上下文长度在训练中效果更好，而文档内掩码有效地减少了平均上下文长度。

Meta 在训练 Llama 3 (Grattafiori et al., 2024) 时也使用了文档内掩码；他们发现在短上下文预训练期间影响有限，但在长上下文扩展时有显著好处，因为那时注意力开销变得更加显著。此外，ProLong 论文 (Gao et al., 2025) 表明，在持续预训练中使用文档掩码来扩展 Llama 3 8B 的上下文，对长上下文和短上下文基准测试都有益。

我们决定在 1B 基线模型上运行消融实验，测试文档掩码是否影响短上下文性能。你可以在此处找到配置文件。要在 Nanotron 中启用文档掩码，只需将 _use_doc_masking 标志设置为 true：

model_config:
  _attn_implementation: flash_attention_2
  _fused_rms_norm: true
  _fused_rotary_emb: true
- _use_doc_masking: false
+ _use_doc_masking: true

结果显示，与标准因果掩码相比，损失曲线和下游评估分数完全相同，如以下图表所示。

与 Llama 3 一样，我们没有观察到对短上下文任务的明显影响，除了在 PIQA 上有小幅改善。然而，文档掩码在扩展到长序列以加速训练时变得至关重要。这对于我们的长上下文扩展尤其重要，我们在那里将上下文从 4k 扩展到 64k token（详见”训练马拉松”）。因此，我们在 SmolLM3 的整个训练过程中采用了它。

在本节中，我们介绍了注意力如何处理序列。现在让我们看看 Transformer 中另一个主要参数块：嵌入（embeddings）。

嵌入共享（Embedding Sharing）

如果你查看我们基线消融模型的配置文件，与标准 Transformer 不同的一点是嵌入共享，由 tie_word_embeddings 标志启用。

LLM 有两个嵌入组件：输入嵌入（input embeddings），作为 token 到向量的查找表（大小为 vocab_size × hidden_dim）；以及输出嵌入（output embeddings），即将隐藏状态映射到词汇表 logit 的最终线性层（hidden_dim × vocab_size）。在这两者为独立矩阵的经典情况下，嵌入参数总量为 2 × vocab_size × hidden_dim。因此，在小型语言模型中，嵌入可以占总参数数量的很大一部分，尤其是在词汇表较大的情况下。这使得嵌入共享（在输出中复用输入嵌入）成为小型模型的自然优化方案。

较大的模型通常不使用这种技术，因为嵌入在其参数预算中占比较小。例如，如以下饼图所示，在 Llama 3.2 8B 中，未共享的总嵌入仅占参数的 13%，在 Llama 3.1 70B 中仅占 3%。

消融实验——绑定嵌入的模型与更大的非绑定变体性能相当

让我们评估嵌入共享对我们消融模型的影响。我们将从 MobileLLM 在 125M 规模下对这一技术进行的全面消融中获得见解，该消融证明共享使参数数量减少了 11.8%，而精度损失极小。

由于非绑定嵌入（untied embeddings）将我们的参数数量从 1.2B 增加到 1.46B，我们将训练另一个具有非绑定嵌入但层数更少的模型，使其参数数量与基线 1.2B 模型相匹配。然后，我们将比较两个 1.2B 模型——我们具有绑定嵌入的基线（16 层）和具有 12 层的非绑定版本——以及具有非绑定嵌入且层数与基线相同的 1.46B 模型作为额外参考点。你可以在此处找到 Nanotron 配置文件。

损失和评估结果表明，尽管参数少了 18%，我们的基线 1.2B 绑定嵌入模型在所有基准测试（WinoGrande 除外）上都达到了与 1.46B 非绑定等效模型相当的性能。具有非绑定嵌入和减少层数（12 层 vs. 16 层）的 1.2B 模型在两种配置中表现均不如，呈现出更高的损失和更低的下游评估分数。这表明，在等效参数预算下，增加模型深度比解除嵌入绑定带来更大的收益。

根据这些结果，我们在 SmolLM3-3B 模型中保留了绑定嵌入。

然而，仅靠嵌入无法捕获序列中 token 的顺序；提供这一信息是位置编码（positional encoding）的职责。在下一节中，我们将探讨位置编码策略的演变，从标准 RoPE 到 NoPE（无位置嵌入，No Positional Embedding）等更新方法，后者能够更有效地对长上下文建模。

位置编码（Positional Encoding）与长上下文

当 Transformer 处理文本时，它们面临一个根本性挑战：它们天然地没有词序感，因为它们通过并行注意力操作同时处理整个序列。这使得训练效率很高，但也带来了问题。如果没有明确的位置信息，从模型的角度来看，“Adam beats Muon” 与 “Muon beats Adam” 看起来是一样的。

解决方案是位置嵌入（positional embeddings）：为序列中每个 token 赋予唯一”地址”的数学编码。但随着我们向越来越长的上下文推进——从早期 BERT 的 512 token 到今天的数百万 token 模型——位置编码的选择对性能和计算效率都变得越来越关键。

位置编码的演进

早期 Transformer 使用简单的绝对位置嵌入（absolute positional embeddings），本质上是将每个位置（1、2、3……）映射到一个向量并添加到 token 嵌入上的学习查找表 (Vaswani et al., 2023)。这对短序列效果很好，但有一个主要限制：模型的最大输入序列长度受限于其训练时的最大输入序列长度。它们没有开箱即用的能力来泛化到更长的序列。

该领域因此向*相对位置嵌入（relative positional embeddings）*演进，这种方法捕获 token 之间的距离，而非其绝对位置。这在直觉上很有意义：两个词之间相差 3 个位置，比它们分别处于位置 (5,8) 还是 (105,108) 更重要。

ALiBi（带线性偏置的注意力，Attention with Linear Biases）(Press et al., 2022) 特别地根据 token 距离修改注意力分数。两个 token 相距越远，通过应用于注意力权重的简单线性偏置，其注意力受到的惩罚就越大。你可以在 labml.ai 找到 ALiBi 的详细实现。

然而，主导近期大型语言模型的技术是 RoPE (Su et al., 2023)。

RoPE：将位置表示为旋转

RoPE 的核心思想是在高维空间中将位置信息编码为旋转角度。RoPE 不是将位置向量添加到 token 嵌入，而是根据查询和键向量的绝对位置，按相应角度旋转它们。

其直觉是，我们将嵌入中的每对维度视为圆上的坐标，并通过以下因素确定的角度旋转它们：

• token 在序列中的位置
• 我们正在处理哪个维度对（不同的对以不同的频率旋转，这些频率是基础/参考频率的指数）

import torch

def apply_rope_simplified(x, pos, dim=64, base=10000):
    """
    Rotary Positional Embedding (RoPE)

    Idea:
    - Each token has a position index p (0, 1, 2, ...).
    - Each pair of vector dimensions has an index k (0 .. dim/2 - 1).
    - RoPE rotates every pair [x[2k], x[2k+1]] by an angle θ_{p,k}.

    
    Formula:
      θ_{p,k} = p * base^(-k / (dim/2))

    - Small k (early dimension pairs) → slow oscillations → capture long-range info.
    - Large k (later dimension pairs) → fast oscillations → capture fine detail.

    """
    rotated = []
    for i in range(0, dim, 2):
        k = i // 2  # index of this dimension pair

        # Frequency term: higher k → faster oscillation
        inv_freq = 1.0 / (base ** (k / (dim // 2)))
        theta = pos * inv_freq  # rotation angle for position p and pair k

        cos_t = torch.cos(torch.tensor(theta, dtype=x.dtype, device=x.device))
        sin_t = torch.sin(torch.tensor(theta, dtype=x.dtype, device=x.device))

        x1, x2 = x[i], x[i+1]

        # Apply 2D rotation
        rotated.extend([x1 * cos_t - x2 * sin_t,
                        x1 * sin_t + x2 * cos_t])

    return torch.stack(rotated)

## Q, K: [batch, heads, seq, d_head]
Q = torch.randn(1, 2, 4, 8)
K = torch.randn(1, 2, 4, 8)

## 👉 apply RoPE to Q and K *before* the dot product
Q_rope = torch.stack([apply_rope(Q[0,0,p], p) for p in range(Q.size(2))])
K_rope = torch.stack([apply_rope(K[0,0,p], p) for p in range(K.size(2))])

scores = (Q_rope @ K_rope.T) / math.sqrt(Q.size(-1))
attn_weights = torch.softmax(scores, dim=-1)

这段代码看起来可能比较复杂，我们用一个具体的例子来拆解。以短语 “The quick brown fox” 中的单词 “fox” 为例。在我们的基准 1B 模型中，每个注意力头处理的是一个 64 维的 query（查询）/key（键）向量。RoPE（旋转位置编码）将该向量分组为 32 对：(x₁, x₂)、(x₃, x₄)、(x₅, x₆)，依此类推。我们按对处理，是因为我们在二维空间中绕圆旋转。为简单起见，我们只关注第一对 (x₁, x₂)。“fox” 在短语中出现在第 3 个位置，因此 RoPE 会将这第一个维度对旋转：

rotation_angle = position × θ₀ 
                = 3 × (1/10000^(0/32))
                = 3 × 1.0 
                = 3.0 radians 
                = 172° degrees

我们的基础频率（base frequency）是 10,000，但对于第一个维度对（k=0），指数为 0，因此基础频率不影响计算（我们将其指数化为 0 次方）。下面的可视化图示展示了这一点。

现在，当两个 token（词元）通过注意力机制发生交互时，神奇的事情就发生了。它们旋转后的表示之间的点积，通过旋转角度之间的相位差直接编码了相对距离（其中 m 和 n 是 token 的位置）：

dot_product(RoPE(x, m), RoPE(y, n)) = Σₖ [xₖ * yₖ * cos((m-n) * θₖ)]

注意力模式只取决于（m-n），因此相距五个位置的 token 之间的角度关系始终相同，与它们在序列中的绝对位置无关。这样，模型就能学习到基于距离的模式，这些模式在序列的任意绝对位置都有效，也能泛化到更长的序列。

配置 RoPE（旋转位置编码）频率

在实践中，大多数 LLM 预训练都以相对较短的上下文长度（2–4k tokens）开始，使用 10k 或 50k 等 RoPE 基础频率。从一开始就使用很长的序列进行训练，由于注意力机制随序列长度呈二次方扩展，以及长上下文数据（超过 4k 上下文长度的样本）的有限性，计算成本会非常高，正如我们在 文档遮蔽 部分看到的那样。研究也表明，这可能损害短上下文的性能 (Zhu et al., 2025)。模型通常首先学习词语之间的短程关联，因此长序列在初期帮助不大。典型的做法是：大部分预训练使用较短的序列，然后进行持续预训练，或在最后数千亿 tokens 阶段切换到更长的序列。然而，随着序列长度的增加，与 token 位置成正比的旋转角度也会增大，这可能导致远处 token 的注意力分数衰减过快 (Rozière et al., 2024; Xiong et al., 2023)：

θ = position x 1 / (base^(k/(dim/2)))

解决方案是在序列长度增加时相应增大基础频率，以防止这种衰减，常用方法包括 ABF 和 YaRN。

RoPE ABF（带调整基础频率的 RoPE） (Xiong et al., 2023b) 通过增大 RoPE 公式中的基础频率来解决长上下文中的注意力衰减问题。这种调整减慢了 token 位置之间旋转角度的变化速度，防止远处 token 的注意力分数衰减过快。ABF 可以分单阶段（直接提升频率）或多阶段（随上下文增长逐步提升）应用。该方法实现简单，并以更高的粒度分布嵌入向量，使模型更容易区分远距离位置。

虽然 ABF 简单有效，但其对所有维度的统一缩放对于极长上下文可能并不最优。 YaRN（Yet another RoPE extensioN，另一种 RoPE 扩展） (Peng et al., 2023) 则采用更复杂的方式，使用斜坡函数或缩放函数对 RoPE 各维度的频率进行不均匀插值。与 ABF 的统一调整不同，YaRN 对不同频率分量施加不同的缩放因子，从而优化扩展后的上下文窗口。它还包含动态注意力缩放和注意力 logit 温度调整等技术，有助于在极大上下文规模下保持性能。YaRN 支持高效的”短序列训练，长序列测试”策略，实现稳健外推所需的 tokens 更少、微调量也更少。与 ABF 相比，YaRN 对极长上下文通常能提供更好的实测性能，因为它提供更平滑的缩放并缓解了灾难性注意力损失问题。它也可以仅在推理阶段使用，无需任何微调。

这些频率调整方法减缓了注意力分数的衰减效应，并保持了远处 token 的贡献。例如，Qwen3 的训练过程中，随着序列长度从 4k 扩展到 32k 上下文窗口，频率从 10k 增加到 1M（使用 ABF），之后团队应用 YaRN 将上下文扩展到 131k，达到 4× 外推。需要注意的是，目前对最优值尚无强共识，通常在上下文扩展阶段尝试不同的 RoPE 值，找到适合特定配置和评估基准的最佳设置，是一个好习惯。

目前，大多数主流模型都使用 RoPE：Llama、Qwen、Gemma 及其他许多模型。这项技术已被证明在不同模型规模和架构（密集、MoE、混合）中都表现稳健。

混合位置编码方案

然而，随着模型向越来越大的上下文迈进 (Meta AI, 2025; Yang et al., 2025)，即便是 RoPE 也开始面临性能挑战。在比 Needle in a Haystack（NIAH）(Kamradt, 2023) 更难的长上下文基准（如 RULER 和 HELMET (Hsieh et al., 2024; Yen et al., 2025)）上评估时，在长上下文扩展阶段增大 RoPE 频率的标准方法存在局限性。为此，一些新技术被引入以提供帮助。

我们在本节开头提到，transformer（变换器）需要位置信息来理解 token 顺序，但近期研究对这一假设提出了挑战。如果显式位置编码根本不是必需的，又会怎样？

NoPE (Kazemnejad et al., 2023) 在不使用任何显式位置编码的情况下训练 transformer，允许模型通过因果遮蔽（causal masking）和注意力模式隐式学习位置信息。作者表明，与 ALiBi 和 RoPE 相比，这种方法展示出更好的长度泛化能力。由于没有显式位置编码需要在训练长度之外进行外推，NoPE 天然能处理更长的上下文。然而在实践中，NoPE 模型在短上下文推理和知识任务上往往弱于 RoPE 模型 (B. Yang et al., 2025)。这表明，尽管显式位置编码可能限制外推，但它们为训练上下文长度以内的任务提供了有益的归纳偏置（inductive biases）。

鉴于这些权衡，@rnope 认为结合不同位置编码策略可能是有趣的方向。他们引入的混合方法 RNoPE，在模型各层之间交替使用 RoPE 和 NoPE 层。RoPE 层提供显式位置信息，并通过近时偏置（recency bias）处理局部上下文，而 NoPE 层则改善了长距离的信息检索。这项技术最近被用于 Llama 4、Command A 和 SmolLM3。

消融实验——NoPE 在短上下文文档上与 RoPE 相当

让我们来测试混合 NoPE 方案。我们将对比一个纯 RoPE 的 1B 消融基线、每四层去除一次位置编码的 NoPE 变体，以及第三种将 NoPE 与文档遮蔽结合的配置，以测试这两项技术之间的交互效果。我们的基本问题是：能否在获得长上下文能力的同时保持强短上下文性能？

损失和评估结果在三种配置下均表现相近，表明 NoPE 在保持强短上下文能力的同时，也为更好的长上下文处理奠定了基础。基于这些结果，我们在 SmolLM3 中采用了 NoPE + 文档遮蔽的组合方案。

另一个互补的思路是仅在模型隐藏维度的子集上应用 RoPE。与 RNoPE 在整个层级之间交替使用 RoPE 和 NoPE 不同， partial RoPE（部分 RoPE） 在同一层内将两者混合。GLM‑4.5 (5 Team et al., 2025) 和 MiniMax-01 (MiniMax et al., 2025) 等近期模型采用了这一策略，但它也存在于 GPT-J (Wang & Komatsuzaki, 2021) 等较早的模型中。所有使用 MLA（多头潜在注意力）的模型中也都有部分 RoPE，因为这对于合理的推理成本来说是必须的。

限制长上下文的注意力范围

到目前为止，我们探讨了如何处理长上下文的位置信息：激活 RoPE、禁用它（NoPE）、在部分层（RNoPE）或部分隐藏维度（partial RoPE）上应用它，或调整其频率（ABF、YaRN）。这些方法通过修改模型编码位置的方式来处理比训练时更长的序列。但还有一种互补策略：与其调整位置编码，不如限制哪些 token 之间可以相互关注。

为了理解这为何重要，设想一个在 8 个 token 的序列上预训练的模型。在推理时，我们希望处理 16 个 token（超过训练长度）。位置 8–15 对于模型的位置编码来说是分布之外的。虽然 RoPE ABF 等技术通过调整位置频率来解决这一问题，注意力范围方法则采用不同的路径：它们有策略地限制哪些 token 之间可以相互关注，将注意力模式保持在熟悉的范围内，同时仍然处理完整序列。这同时降低了计算成本和内存需求。

下图比较了在预训练窗口为 8 的情况下处理 16 个 token 序列的五种策略。

分块注意力（Chunked attention） 将序列分成固定大小的块，token 只能在其所在块内进行关注。在我们的示例中，16 个 token 被分成两个 8 token 的块（0 到 7，以及 8 到 15）。注意，token 8 到 15 完全无法回顾前一个块。这造成了在块边界处重置的孤立注意力窗口。Llama 4 (Meta AI, 2025) 在 RoPE 层（每四个解码器层中的三个）使用 8,192 token 块的分块注意力，而 NoPE 层则保持完整的上下文访问。这通过限制每层的 KV 缓存大小来降低内存需求，但一个块中的 token 无法关注前一个块，这可能影响某些长上下文任务。

滑动窗口注意力（Sliding Window Attention，SWA） 由 Mistral 7B (Child et al., 2019; Jiang et al., 2023) 推广，基于”近期 token 最为相关”的直觉采用不同方法。每个 token 不再有硬性块边界，而是只关注最近的 N 个 token。如图所示，每个 token 可以向前回顾至多 8 个位置，形成一个在整个序列中连续滑动的窗口。注意 token 15 可以关注位置 8 到 15，而 token 10 则关注位置 3 到 10。窗口向前滑动，在整个序列中保持局部上下文，而没有分块的人为屏障。Gemma 3 将 SWA 与全注意力以交替层的形式结合，类似于混合位置编码策略混合不同技术的方式。

双块注意力（Dual Chunk Attention，DCA） (An et al., 2024) 是一种无需训练的方法，在扩展分块注意力的同时保持跨块信息流。在我们的示例中，使用块大小 s=4，将 16 个 token 分成 4 个块（想象沿对角线排列的 4×4 方块）。DCA 结合三种机制：

1. 块内注意力：token 在其块内正常关注（对角线模式）
2. 块间注意力：query（查询）使用位置索引 c−1=7 来关注前一个块，创建上限为 7 的相对位置
3. 相邻块注意力：局部窗口 w=3，保持相邻块之间的局部性

这使所有相对位置都保持在训练分布内（0 到 7），同时在块边界处实现平滑过渡。DCA 使 Qwen2.5 等模型能够在推理时支持超长上下文窗口（最多 100 万 tokens），而无需在百万 token 序列上进行持续训练。

我们现在已经涵盖了注意力机制的核心组件：平衡内存与计算的不同头部配置（MHA、GQA、MLA），帮助模型理解 token 顺序的位置编码策略（RoPE、NoPE 及其变体），以及使长上下文变得可行的注意力范围技术（滑动窗口、分块和注意力汇聚）。我们还研究了嵌入层应如何配置和初始化。这些架构选择决定了模型如何处理和表示序列。

但拥有正确的架构只是成功的一半。即使设计良好的模型也可能遭受训练不稳定的问题，尤其是在大规模时。让我们来看看一些有助于保持训练稳定的技术。

提升稳定性

我们现在将转向 LLM 预训练中最大的挑战之一：不稳定性。这类问题通常表现为 loss spike（损失尖峰）或训练损失的突然跳跃，在大规模时尤为常见。

虽然我们将在”训练马拉松”部分深入探讨不同类型的尖峰及处理方法（涵盖浮点精度、优化器和学习率等话题），但某些架构和训练技术也能帮助我们减少不稳定性，因此让我们花时间研究一下它们。我们将介绍近期大规模训练运行（例如 OLMo 2 (OLMo et al., 2025) 和 Qwen3 (A. Yang, Li, et al., 2025)）中用于提升稳定性的几种简单技术：Z-loss、从嵌入中移除权重衰减，以及 QK-norm。

Z-loss

Z-loss (Chowdhery et al., 2022) 是一种正则化技术，通过在损失函数中添加惩罚项来防止最终输出 logit 过大。该正则化鼓励 logit 上 softmax 分母保持在合理范围内，有助于在训练期间保持数值稳定性：

在 1B 模型上的消融实验结果表明，添加 Z-loss 不会影响训练损失或下游性能。对于 SmolLM3，我们最终没有使用它，因为我们的 Z-loss 实现引入了一些在训练开始前尚未优化的训练开销。

从嵌入中移除权重衰减

权重衰减（weight decay）通常作为正则化技术应用于所有模型参数，但 OLMo et al. (2025) 发现，将嵌入层排除在权重衰减之外可以提升训练稳定性。原因是权重衰减会导致嵌入的范数（norm）在训练过程中逐渐减小，这可能导致早期层的梯度变大，因为层归一化（layer normalization）的 Jacobian 与输入范数成反比 (Takase et al., 2025)。

我们通过训练三种配置测试了这一方法：使用标准权重衰减的基准、不对嵌入使用权重衰减的变体，以及结合了所有已采用修改（不对嵌入使用权重衰减 + NoPE + 文档遮蔽）的第三种配置，以确保各技术之间没有负面交互。三种配置的损失曲线和评估结果几乎相同，因此我们在 SmolLM3 训练中采用了所有三项修改。

QK-norm

QK-norm (Dehghani et al., 2023) 在计算注意力之前对 query 和 key 向量都应用层归一化。这项技术有助于防止注意力 logit 变得过大，许多近期模型使用它来提升稳定性。

然而，@rnope 发现 QK-norm 会降低长上下文任务的性能。他们的分析揭示，QK-norm 导致相关 token（needle）上的注意力权重减少，无关上下文上的注意力权重增加。他们认为这是因为归一化操作去除了 query-key 点积中的量级信息，使注意力 logit 在量级上更接近。出于这个原因，我们没有在 SmolLM3 中使用 QK-norm。（此外，作为一个 3B 参数的小模型，与那些 QK-norm 证明最为有益的更大规模模型相比，它面临训练不稳定的风险也更小。）

其他注意事项

除了我们目前涵盖的组件之外，还有一些其他值得为完整性而提及的架构决策。

在参数初始化方面，现代模型通常使用截断正态初始化（truncated normal initialization，均值=0，标准差=0.02 或 0.006），或 μP (G. Yang & Hu, 2022) 等初始化方案（例如 Cohere 的 Command A (Cohere et al., 2025)）。这也是可以进行消融实验的另一个话题。

在激活函数方面，SwiGLU 已成为现代 LLM 的事实标准（除了 Gemma 2 使用 GeGLU，以及 NVIDIA 使用 ReLU^2 (Nvidia et al., 2024; NVIDIA et al., 2025)），取代了 ReLU 或 GELU 等旧有选择。

从更宏观的层面来看，架构布局的选择也在塑造模型行为方面起着作用。虽然总参数量在很大程度上决定了语言模型的容量，但这些参数如何分布在深度和宽度上同样重要。@petty2024impactdepthcompositionalgeneralization 发现，在语言建模和组合泛化任务上，更深的模型优于同等规模但更宽的模型，直到收益趋于饱和。这种”深而窄”的策略在 MobileLLM 的消融实验 (Z. Liu et al., 2024) 中对十亿参数以下的 LLM 效果良好，而更宽的模型由于较高的并行性往往提供更快的推理速度。正如 Sebastian Raschka 在其 LLM 架构对比文章 中所指出的，现代架构以不同方式体现了这种权衡。

我们现在已经涵盖了密集 transformer（dense transformer）架构中值得针对训练运行进行优化的最重要方面。然而，最近还出现了其他一些关乎模型整体的架构干预，包括 MoE（专家混合）和混合模型。让我们来看看它们能提供什么，首先从 MoE 开始。

走向稀疏：MoE

专家混合模型（Mixture of Experts，MoE）的直觉是，我们不需要对每个 token 预测都使用完整模型，就像我们的大脑会根据任务激活不同区域一样（例如视觉皮层或运动皮层）。对于 LLM 来说，这可能意味着在模型执行翻译任务时，学习了编程语法的部分不需要被激活。如果能做到这一点，我们可以节省大量计算，因为这意味着在推理时我们只需运行完整模型的一部分。

从技术层面来说，MoE 有一个简单的目标：在不增加每个 token”激活”参数数量的前提下，扩大总参数量。简单来说，总参数量影响模型的整体学习容量，而激活参数量决定训练成本和推理速度。这就是为什么如今许多前沿系统（例如 DeepSeek-V3、Kimi K2，以及 Gemini、Grok 等闭源模型）都采用 MoE 架构。以下来自 Ling 1.5 论文 (L. Team et al., 2025) 的图表比较了 MoE 和密集模型的缩放规律（scaling laws）。

如果你是第一次接触 MoE，不用担心，其机制并不复杂。我们从标准密集架构出发，看看 MoE 需要做哪些改动（图示来自 Sebastian Raschka）：

在 MoE 中，我们将单一的多层感知机（MLP，multilayer perceptron）替换为多个 MLP（“专家”），并在 MLP 之前添加一个可学习的路由器。对于每个 token，路由器选择一小部分专家来执行。这就是总参数量与激活参数量之间差异的来源：模型拥有许多专家，但任何给定的 token 只使用其中几个。

设计 MoE 层会引发几个核心问题：

• 专家形状与稀疏性： 应该使用许多小专家还是较少的大专家？每个 token 应激活多少个专家，总共需要多少个专家（即稀疏度或”top-k”）？是否应该有一些全局专家始终处于激活状态？
• 利用率与专业化： 如何选择路由的专家，并保持它们被充分使用（即避免空闲容量），同时还鼓励它们专业化？在实践中，这是一个负载均衡问题，对训练和推理效率有重大影响。

在这里，我们关注一个目标：在固定计算预算的情况下，如何选择一种能最小化损失的 MoE 配置？这与纯粹的系统效率（吞吐量/延迟）是不同的问题，我们稍后会回到这个问题。

本节的大部分内容遵循蚂蚁集团 MoE 缩放规律论文 (Tian et al., 2025) 中的分析。我们将使用他们的 效率杠杆（efficiency leverage，EL） 概念。简单来说，EL 衡量需要多少密集计算才能匹配某个 MoE 设计所达到的损失，计量单位是浮点运算次数（FLOPs）。更高的 EL 意味着与密集训练相比，该 MoE 配置在每单位计算量上带来了更多的损失改善。

让我们更仔细地了解如何设置 MoE 的稀疏性以提升效率杠杆。

稀疏性/激活比

TL;DR：稀疏性越高 → FLOPs 效率越好 → 在极高稀疏性时收益递减 → 最佳点取决于计算预算。

本节的目标是找出哪种 MoE 设置最好。从渐近的角度来看，很容易看出两种极端都不理想。一方面，始终激活所有专家使我们回到了所有参数都一直被使用的密集设置。另一方面，如果激活参数量极低（极端情况下，想象只有一个参数被激活），显然即使在狭窄的领域内也不足以解决任务。因此我们需要找到某个中间值。在深入寻找最优设置之前，定义两个量会很有用，即 激活比（activation ratio） 及其倒数 稀疏度（sparsity）：

从计算角度来看，成本由激活参数量驱动。如果固定激活专家的数量（和大小），并增加专家总数，你的推理/训练 FLOPs 预算基本不变，但增加了模型容量，因此只要训练足够长，模型通常应该会更好。

如果调研近期的 MoE 论文，会发现一些有趣的经验性结论：固定激活专家的数量和大小，增加专家总数（即降低激活比/提高稀疏度）能改善损失，但一旦稀疏度变得非常高，收益开始递减。

请看以下图表：

• Kimi K2 的图表 (K. Team et al., 2025) 展示了两种效应：更高的稀疏度改善了性能，但随着稀疏度的增长，收益趋于平缓。
• 蚂蚁集团的图表 (Tian et al., 2025) 得出了相同的结论，并补充说明：更高稀疏度的 MoE 从增加计算量中获益更多。

下表列出了一些 MoE 模型的稀疏度：

近期趋势非常明显：MoE 模型正变得越来越稀疏。尽管如此，最优稀疏度仍然取决于硬件和端到端效率。例如，Step-3 以峰值效率为目标，有意没有将稀疏度最大化，以适配特定的硬件和带宽约束，而 gpt-oss-20b 由于设备内存约束而具有较低的稀疏度（被动专家仍然占用一定内存）。

粒度（Granularity）

除了稀疏度，我们还需要决定每个专家的规模。这由 粒度 来衡量，这是蚂蚁集团引入的一个指标。让我们明确这个术语的含义，因为各论文的术语不尽相同，有些使用略微不同的公式。在这里，我们将使用与我们引用的图表相匹配的定义：

更高的粒度值对应于拥有更多更小维度的专家（在参数总量固定的情况下）。这个指标是专家维度（$d_{expert}$）与模型维度（$d_{model}$）之间的比率。

在密集模型中，一个常用的经验法则是将 MLP 的维度设置为 $d_{intermediate} = 4 * d_{model}$。如果 $\alpha = 4$（遵循 @krajewski2024scalinglawsfinegrainedmixture），可以大致将粒度理解为需要多少个专家才能匹配密集 MLP 的宽度（$4\, d_{\text{model}} = d_{\text{intermediate}} = G\, d_{\text{expert}}$）。

这种解释只是一个粗略的启发式方法：现代 MoE 设计通常分配的总容量远超单个密集 MLP，因此一一对应在实践中并不成立。蚂蚁集团团队选择了 $\alpha = 2$，这只是一种不同的归一化选择。为保持一致性，我们采用这一约定并沿用下去。

下表列出了近期部分 MoE 发布版本的不同取值：

让我们来讨论粒度如何影响行为。来自蚂蚁集团论文：

粒度看起来并不是 EL 的主要驱动因素——它有帮助，尤其是当取值超过 2 时，但它不是决定损失的主导因素。并且存在一个甜蜜点：提高粒度在某一点之前有帮助，之后收益趋于平缓。因此，粒度是一个有用的调整旋钮，在近期发布版本中明显趋向更高值，但不应孤立地对其进行优化。

另一种广泛用于改善 MoE 的方法是 共享专家（shared experts） 的概念。我们来看看！

共享专家

共享专家设置将每个 token 路由到一小组始终激活的专家。这些共享专家吸收数据中的基本、反复出现的模式，从而使其余专家能够更激进地专业化。在实践中，通常不需要太多共享专家；模型设计者通常选择一个，最多两个。随着粒度的增加（例如，从 Qwen3 风格的设置转移到更接近 Qwen3-Next 的设置），共享专家往往变得更有用。从 Tian et al. (2025) 的以下图表来看，总体影响是适度的；它不会显著改变 EL。一个简单的经验法则在大多数情况下效果良好：只使用一个共享专家。这与 DeepSeek-V3、Kimi K2 和 Qwen3-Next 等模型的选择一致，并且在不增加不必要复杂性的情况下倾向于最大化效率。

所以，共享专家是所有 token 都会被路由经过的专家。那其他的专家呢？我们如何学习何时路由到每个专家，并确保我们不会只使用少数几个专家而让其他专家闲置？接下来我们将讨论负载均衡（load balancing），这正是要解决的问题。

负载均衡

负载均衡是 MoE 中的关键部分。如果设置不当，它可能会削弱所有其他设计选择。为了理解为什么糟糕的负载均衡会给我们带来很多麻烦，设想一个非常简单的分布式训练设置：我们有四块 GPU，将模型的四个专家均匀分布在这些 GPU 上。如果路由崩溃，所有 token 都被路由到专家 1，这意味着只有四分之一的 GPU 被利用，对训练和推理效率来说非常糟糕。模型的有效学习容量也会下降，因为并非所有专家都被激活。

为了解决这个问题，我们可以在路由器中添加一个额外的损失项。下面是基于标准辅助损失的负载均衡：

这个简单的公式只使用三个因素：系数 $\alpha$ 决定损失的强度，$f_i$ 是流量分数（通过专家 $i$ 的 token 比例），$P_i$ 是概率质量，即通过该专家的 token 概率之和。两者都是必要的：$f_i$ 对应实际的均衡效果，而 $P_i$ 是平滑且可微的，允许梯度流动。

如果我们实现完美的负载均衡，则 $f_i=P_i=1/N_r$。但我们需要谨慎调整 $\alpha$：如果太小，我们对路由的引导不足；如果太大，路由均匀性会比主要的语言模型损失更重要。

一个关键细节是计算路由统计数据的范围：$f_i$ 和 $P_i$ 是按本地批次（每个 worker 的 mini-batch）还是全局（跨 worker/设备聚合）计算的？Qwen 团队的分析 (Qiu et al., 2025) 表明，当每个本地批次的 token 多样性不足时，本地计算会损害专家专业化（路由健康状况的良好代理）和整体模型性能。专家专业化是指一个或多个专家对特定领域的激活频率高于其他专家的现象。换言之，如果一个本地批次比较单一，其路由统计数据就会变得嘈杂/有偏差，无法实现良好的均衡。这意味着我们应该在可行的情况下使用全局统计数据（或至少进行跨设备聚合）。值得注意的是，在该论文发表时，许多框架——包括 Megatron——默认都是在本地计算这些统计数据。

以下来自 Qwen 论文的图表展示了 micro-batch（微批次）与全局批次聚合之间的差异及其对性能和专业化的影响：

通常，围绕 MoE 的架构选择进行消融实验比较棘手，因为许多方面之间存在相互作用。例如，共享专家的有用性可能取决于模型的粒度。值得花时间确保你有一套好的实验方案，以真正获得你所寻求的洞察！

我们已经涵盖了 MoE 的基础知识，但还有更多值得探索的内容。以下是一份非详尽的可能值得研究的项目列表：

• 零计算专家、MoE 层重缩放和训练监控（LongCat-Flash 论文）

• 正交损失负载均衡（如 ERNIE 4.5）

• 在训练过程中对负载均衡系数进行调度

• MoE 的架构/优化交互，例如：

  • 优化器排名是否在 MoE 中改变
  • 如何将 μP 应用于 MoE
  • 如何为 MoE 调整学习率（因为专家每批次看到的 token 数量不同）

• 开头的密集层数量

我们将留给好奇的读者继续深入探索，同时我们继续讨论最后一个主要架构选择：混合模型！

扩展阅读：混合模型

近期的一个趋势是用状态空间模型（SSM，state space models）或线性注意力机制来增强标准的密集或 MoE 架构 (MiniMax et al., 2025; Zuo et al., 2025)。这类新型模型尝试解决 transformer 在高效处理超长上下文方面的一些根本性弱点。它们在循环模型（recurrent models）和 transformer 之间取得了中间平衡：循环模型能够以线性缩放处理任意长的上下文，但可能难以充分利用上下文中的模式；而 transformer 在长上下文时计算成本非常高，但能很好地利用上下文中的模式。

已有一些研究旨在理解 SSM 的优势与劣势。例如，@waleffe2024empiricalstudymambabasedlanguage 研究了 Mamba 模型（一种 SSM 形式），发现它们在许多基准上表现良好，但在 MMLU 和其他几个任务上表现不足。他们假设是缺乏上下文内学习（in-context learning）导致了这种差距。将 SSM 与密集或 MoE 模型的模块结合，可以兼得两者的优势，这也是 混合模型（hybrid models） 的名称由来。

这些线性注意力机制的核心思想是重新排列计算顺序，使注意力不再需要 $O(n^2d)$ 的代价（这在长上下文时变得难以承受）。这是如何实现的？首先，回顾一下推理时的注意力公式。为 token $t$ 生成输出看起来是：

现在去掉 softmax：

重新排序得到：

我们定义运行状态（running state）：

有简单的更新规则：

因此可以写成：

为什么重新排序很重要？左侧形式 $\sum_{j\le t}(q_t^\top k_j)v_j$ 意味着”对于每个过去的 token $j$，取点积 $q_t^\top k_j$（一个标量），用它缩放 $v_j$，然后将这些 $t$ 个向量相加”——这在步骤 $t$ 时需要约 $O(td)$ 的工作量。右侧形式将其改写为 $\big(\sum_{j\le t} v_j k_j^\top\big) q_t$。你保持一个单一的运行状态矩阵 $S_t=\sum_{j\le t} v_j k_j^\top\in\mathbb{R}^{d\times d}$，它已经汇总了所有过去的 $(k_j,v_j)$。每个新 token 以一次外积 $v_t k_t^\top$ 更新它，代价为 $O(d^2)$；然后输出只需一次矩阵-向量乘法 $S_t q_t$（也是 $O(d^2)$）。因此，用左侧形式从头生成 $T$ 个 token 的代价为 $O(T^2 d)$，而维护 $S_t$ 并使用右侧形式的代价为 $O(T d^2)$。直观地说：左侧 = “每步进行许多小的点积缩放相加”；右侧 = “一个预汇总的矩阵乘以 query”，用对维度的依赖替换了对序列长度的依赖。我们这里关注的是推理和循环形式，但在训练中重新排序同样更高效，如以下公式所示：

这现在看起来非常像 RNN 式的结构。我们已经解决了问题，对吧？几乎。在实践中，softmax 发挥着重要的稳定作用，简单的线性注意力在没有某种归一化的情况下可能不稳定。为此，已经提出了一些实用的变体。

Lightning Attention

基于 NormAttention 的思想 (Qin et al., 2022)——用基于范数的缩放替换 softmax 归一化以控制注意力量级并提升稳定性——Lightning Attention 变体 专注于使实现快速高效，并包含了一些重要的架构改进。以下是各自的公式：

NormAttention：

Lightning Attention：

步骤 1：QKV 投影 + SiLU

步骤 2：衰减因子和（$S_t = KV_t$ 在之前的记号中）

步骤 3：RMSNorm + 门控

根据 MiniMax et al. (2025) 的实测，带有 Lightning Attention 的混合模型在大多数任务上能匹配 softmax 注意力。

有趣的是，在 NIAH 等检索任务上，它的表现可以远远优于全 softmax 注意力，这可能表明 softmax 层和线性层之间存在某种协同效应。

现在，让我们来看一些其他的注意力方法，并了解如何在一个统一的框架内理解它们。

高级线性注意力

循环模型给我们的一个有用启示是，让状态偶尔”放手”忘掉过去。在实践中，这意味着为前一个状态引入一个门控 $\mathbf{G}_t$：

几乎所有最近的线性注意力机制都有这个门控组件，只是对 $\mathbf{G}_t$ 的实现方式不同。以下是来自 Yang et al., 2024 的门控变体及其对应架构列表。

一个值得关注的变体是 Mamba-2 (Dao & Gu, 2024)；它被用于多个混合模型，如 Nemotron-H (NVIDIA, :, Blakeman, et al., 2025)、Falcon H1 (Zuo et al., 2025) 和 Granite-4.0-h (IBM Research, 2025)。然而，目前还处于早期阶段，在扩展到大型混合模型时有重要的细微差别需要考虑。

虽然这些注意力机制展现出潜力，但 MiniMax 在 M2 上的经验表明，在小规模上的优势并不总能转化到大规模生产系统。尽管如此，混合模型发展迅速，仍然是前沿训练的可靠选择。Qwen3-Next（包含门控 DeltaNet 更新 (Qwen Team, 2025)）报告称，其在长上下文推理速度更快、训练速度更快，且在标准基准上表现更好。我们也期待 Kimi 的下一个模型，它很可能会使用他们新的 Kimi Delta Attention。还应提及稀疏注意力（Sparse Attention），它通过仅对选定的块或查询计算注意力来解决长上下文缩放问题。一些例子包括 Native Sparse Attention (Yuan et al., 2025)、DeepSeek Sparse Attention (DeepSeek-AI, 2025) 和 InfLLM v2 (M. Team et al., 2025)。

现在你已经了解了架构选项，如何在它们之间做出选择？在讨论分词器之前，让我们先把这个问题解决掉。

用不用 MoE：选择基础架构

是否使用密集、MoE 还是混合模型，通常取决于几个核心因素：模型的部署位置、团队专业知识，以及你的时间线。让我们简要回顾每种选项的优缺点，并建立一个简单的决策树来做出选择。

密集 transformer（Dense transformers） 是标准的仅解码器 transformer 架构，每个 token 都会激活所有参数。参见 Harvard NLP 的博客文章 “The Annotated Transformer” 了解数学原理，以及 Jay Alammar 的 “The Illustrated Transformer” 建立直觉。

优点：广泛支持、理解透彻、训练稳定、每参数性能良好。

缺点：计算随规模线性扩展；70B 模型的成本约为 3B 的 23 倍。

专家混合（Mixture of Experts，MoE） 模型将 transformer 中的前馈层替换为多个”专家”。一个门控网络将每个 token 路由到少数几个专家。结果是以一小部分计算量实现了大型网络的容量。例如，Kimi K2 拥有 1T 总参数，但每个 token 只有 32B 参数处于活跃状态。代价是所有专家都必须加载到内存中。关于直观理解，请参阅 Maarten Grootendorst 的博客文章。

优点：在训练和推理方面，每单位计算量的性能更好。

缺点：高内存需求（所有专家都必须加载）以及比密集 transformer 更复杂的训练。框架支持正在改善，但不如密集模型成熟，且分布式训练因专家放置、负载均衡和全对全通信（all-to-all communication）的挑战而更加复杂。

混合模型（Hybrid models） 将 transformer 与 Mamba 等状态空间模型结合，为某些操作提供线性复杂度，而非注意力的二次方扩展。这里有一些有用的资源：Sasha Rush 的博客文章以及 Maarten Grootendorst 关于 Mamba 和 SSM 的直观指南。

优点：潜在的更好长上下文处理能力，对超长序列更高效。

缺点：比密集和 MoE 架构更不成熟，经过验证的训练方案更少。框架支持有限。

要做出决定，首先要问模型将部署在哪里。然后考虑团队的专业知识和训练时间线，评估你能承担多少探索。

对于 SmolLM3，我们希望构建一个用于设备端部署的强大小型模型，时间线大约为三个月，且过去我们主要训练密集模型。这排除了 MoE（内存限制）和混合架构（探索时间线短，密集模型足以支持 128k tokens 的目标上下文长度），因此我们选择了密集的 Llama 风格模型。

有了模型架构，现在让我们将注意力转向分词器（tokenizer），它是数据与模型之间的桥梁。

分词器（Tokenizer）

分词方案很可能是任何语言模型中最被低估的组件之一。可以把它看作人类语言与模型所处的数学世界之间的翻译器。尽管架构创新往往占据聚光灯，但就像任何翻译器一样，翻译质量很重要。那么，我们如何为自己的需求构建或选择正确的分词器？

分词器基础

从本质上说，分词器通过将连续文本分割成称为 token（词元）的独立可处理单元，将原始文本转换为模型可以处理的数字序列。在深入技术细节之前，我们应该首先回答一些将指导分词器设计的基本问题：

• 我们希望支持哪些语言？ 如果我们正在构建一个多语言模型，但分词器只见过英语，那么当模型遇到非英语文本时效率会很低，非英语文本将被分割成比必要情况多得多的 token。这直接影响性能、训练成本和推理速度。
• 哪些领域对我们重要？ 除语言外，数学和代码等领域需要仔细表示数字。
• 我们的目标数据混合是什么？ 如果我们计划从头开始训练分词器，理想情况下应该在能反映最终训练混合的样本上进行训练。

一旦回答了这些问题，我们就可以审视主要的设计决策。

词汇量大小（Vocabulary Size）

词汇表（vocabulary）本质上是一个字典，列出我们的模型能识别的所有 token（最小文本单位，如单词、子词或符号）。

较大的词汇表通常能更高效地压缩文本，因为每个句子生成的 token 更少，但存在计算权衡：词汇量大小直接影响嵌入矩阵的大小。如果词汇量为 V，隐藏维度为 h，则输入嵌入有 V × h 个参数，输出层还有另外 V × h 个参数。对于较小的模型，这可能占总参数量的相当大比例（正如我们在”嵌入共享”部分看到的那样），但随着模型规模增大，相对成本会缩小。

最佳点取决于目标覆盖范围和模型规模。对于纯英语模型，约 50k tokens 通常就足够了，但多语言模型通常需要 100k+ 才能高效处理各种书写系统和语言。Llama 3 等现代最先进模型已采用 128k+ 范围的词汇表，以提高跨语言的 token 效率。同一系列中较小的模型通过嵌入共享来降低嵌入参数比例，同时仍能受益于更大的词汇表。

Dagan et al. (2024) 分析了词汇量大小对压缩、推理和内存的影响。他们观察到，更大词汇表带来的压缩收益呈指数递减，这表明存在一个最优大小。对于推理，较大的模型受益于更大的词汇表，因为压缩节省的前向传递成本超过了额外嵌入 token 在 softmax 中的代价。对于内存，最优大小取决于序列长度和批大小：由于 KV 缓存节省，较长的上下文和大批次受益于更大的词汇表。

分词算法

既然我们已经了解了定义分词器的关键参数，我们面临一个实际决策：应该使用现有的分词器还是从头开始训练一个？答案取决于覆盖范围，即现有分词器是否能以我们目标词汇量大小很好地处理我们的语言和领域。

在现有分词器中，字节对编码（BPE，Byte-Pair Encoding）(Sennrich et al., 2016) 仍然是最流行的选择。还有其他算法，如 WordPiece 和 SentencePiece，但它们的采用率较低。（还有越来越多的研究兴趣集中在无分词器方法上，这些方法直接处理字节或字符，可能完全消除分词步骤。）

关于覆盖范围的问题，请看下图，它比较了 GPT-2 的纯英语 BPE 分词器 (Radford et al., 2019) 和 Gemma 3 的多语言 SentencePiece 分词器 (G. Team et al., 2025) 如何分割相同的英语和阿拉伯语句子。

虽然两个分词器在英语上的表现似乎相近，但对于阿拉伯语，差异变得非常显著：GPT-2 将文本分割成一百多个片段，而 Gemma 3 由于其多语言训练数据和更大、更具包容性的词汇表，生成的 token 要少得多。

但要评估分词器的质量，我们不能只看几个分词示例就下结论，就像我们不能在没有运行消融实验的情况下凭直觉进行架构更改一样。我们需要具体的指标。

衡量分词器质量

为了评估分词器的性能，我们可以使用 FineWeb2 (Penedo et al., 2025) 中采用的两个关键指标：

• 生育率（Fertility） 衡量编码一个单词平均需要多少 token（词对 token 的比率）。较低的生育率意味着更好的压缩，从而转化为更快的训练和推理速度。
• 续词比例（Proportion of continued words） 告诉我们有多少百分比的单词被分割成多个部分。百分比越低越好，因为这意味着更少的单词被碎片化，从而实现更高效的分词。

生育率指标围绕”词”的概念定义，因为在合适的分词工具可用时（例如 Spacy 或 Stanza），它提供了有意义的跨语言比较 (Penedo et al., 2025)。对于单一语言内的分词器比较，可以使用字符数或字节数代替词数，得到字符对 token 比率或字节对 token 比率 (Dagan et al., 2024)。然而，这些指标在跨语言比较中有局限性。字节可能有偏差，因为不同脚本的字符需要不同的字节表示（例如，中文字符在 UTF-8 中使用 3 字节，而拉丁字符使用 1 或 2 字节）。类似地，使用字符数没有考虑到跨语言单词长度差异很大的事实。例如，中文词通常比德语合成词短得多。

我们可以如下实现这些指标：

import numpy as np

def compute_tokenizer_metrics(tokenizer, word_tokenizer, text):
    """
    Computes fertility and proportion of continued words.
    
    Returns:
        tuple: (fertility, proportion_continued_words)
            - fertility: average tokens per word (lower is better)
            - proportion_continued_words: percentage of words split into 2+ tokens (lower is better)

    """
    words = word_tokenizer.word_tokenize(text)
    tokens = tokenizer.batch_encode_plus(words, add_special_tokens=False)
    tokens_per_word = np.array(list(map(len, tokens["input_ids"])))
    
    fertility = np.mean(tokens_per_word).item()
    proportion_continued_words = (tokens_per_word >= 2).sum() / len(tokens_per_word)
    
    return fertility, proportion_continued_words

但对于代码和数学等专业领域，除了生育率之外，我们还需要深入了解分词器如何处理特定领域的模式。大多数现代分词器使用单个数字分割，因此 “123” 变成 [“1”, “2”, “3”] (Chowdhery et al., 2022; DeepSeek-AI et al., 2024)。将数字拆开看起来可能有些反直觉，但实际上它有助于模型更有效地学习算术模式。如果 “342792” 被编码为一个不可分割的 token，模型必须记忆当该特定 token 与每个其他数字 token 进行加、减或乘法运算时会发生什么，但当它被拆分后，模型就能学习数字级别的运算规律。一些分词器，如 Llama 3 的 (Grattafiori et al., 2024)，将 1 到 999 的数字编码为唯一 token，其余数字由这些 token 组合而成。

评估分词器

为了跨不同语言比较分词器，我们将使用 FineWeb2 分词器分析 (Penedo et al., 2025) 中的设置，以维基百科文章作为评估语料库。对于每种语言，我们将抽样 100 篇文章以获得有意义的样本，同时保持计算量可管理。

首先，让我们安装依赖项并定义要比较的分词器和语言：

pip install transformers datasets sentencepiece 'datatrove[multilingual]'
## we need datatrove to load word tokenizers

tokenizers = [
    ("Llama3", "meta-llama/Llama-3.2-1B"),
    ("Gemma3", "google/gemma-3-1b-pt"),
    ("Mistral (S)", "mistralai/Mistral-Small-24B-Instruct-2501"),
    ("Qwen3", "Qwen/Qwen3-4B")
]

languages = [
    ("English", "eng_Latn", "en"),
    ("Chinese", "cmn_Hani", "zh"),
    ("French", "fra_Latn", "fr"),
    ("Arabic", "arb_Arab", "ar"),
]

现在让我们加载维基百科样本。我们使用流式传输以避免下载整个数据集：

from datasets import load_dataset

wikis = {}
for lang_name, lang_code, short_lang_code in languages:
	wiki_ds = load_dataset("wikimedia/wikipedia", f"20231101.{short_lang_code}", streaming=True, split="train")
	wiki_ds = wiki_ds.shuffle(seed=42, buffer_size=10_000)
	# Sample 100 articles per language
  ds_iter = iter(wiki_ds)
  wikis[lang_code] = "\n".join([next(ds_iter)["text"] for _ in range(100)])

数据准备好后，我们可以对每种分词器和语言组合进行评估。对于每种组合，我们从 DataTrove 加载相应的词语分词器并计算两个指标：

from transformers import AutoTokenizer
from datatrove.utils.word_tokenizers import load_word_tokenizer
import pandas as pd

results = []
	
for tokenizer_name, tokenizer_path in tokenizers:
    tokenizer = AutoTokenizer.from_pretrained(tokenizer_path, trust_remote_code=True)
    
    for lang_name, lang_code, short_lang_code in languages:
        word_tokenizer = load_word_tokenizer(lang_code)
        
        # Compute metrics on Wikipedia
        fertility, pcw = compute_tokenizer_metrics(tokenizer, word_tokenizer, wikis[lang_code])
        
        results.append({
            "tokenizer": tokenizer_name,
            "language": lang_name,
            "fertility": fertility,
            "pcw": pcw
        })

df = pd.DataFrame(results)
print(df)

      tokenizer    language  fertility       pcw
0        Llama3     English   1.481715  0.322058
1        Llama3     Chinese   1.601615  0.425918
2        Llama3      French   1.728040  0.482036
3        Llama3     Spanish   1.721480  0.463431
4        Llama3  Portuguese   1.865398  0.491938
5        Llama3     Italian   1.811955  0.541326
6        Llama3      Arabic   2.349994  0.718284
7        Gemma3     English   1.412533  0.260423
8        Gemma3     Chinese   1.470705  0.330617
9        Gemma3      French   1.562824  0.399101
10       Gemma3     Spanish   1.586070  0.407092
11       Gemma3  Portuguese   1.905458  0.460791
12       Gemma3     Italian   1.696459  0.484186
13       Gemma3      Arabic   2.253702  0.700607
14  Mistral (S)     English   1.590875  0.367867
15  Mistral (S)     Chinese   1.782379  0.471219
16  Mistral (S)      French   1.686307  0.465154
17  Mistral (S)     Spanish   1.702656  0.456864
18  Mistral (S)  Portuguese   2.013821  0.496445
19  Mistral (S)     Italian   1.816314  0.534061
20  Mistral (S)      Arabic   2.148934  0.659853
21        Qwen3     English   1.543511  0.328073
22        Qwen3     Chinese   1.454369  0.307489
23        Qwen3      French   1.749418  0.477866
24        Qwen3     Spanish   1.757938  0.468954
25        Qwen3  Portuguese   2.064296  0.500651
26        Qwen3     Italian   1.883456  0.549402
27        Qwen3      Arabic   2.255253  0.660318

结果揭示了一些赢家和权衡，具体取决于你的优先级。

Gemma 3 的分词器在多种语言上实现了较低的生育率和单词分割率——尤其在英语、法语和西班牙语上——这可以通过其多语言训练数据和非常大的词汇量（262k tokens，约为 Llama 3 的 128k 的两倍）来解释。Qwen3 的分词器在中文上表现出色，但在英语、法语和西班牙语上落后于 Llama 3。Mistral Small 的分词器 (Mistral AI, 2025) 在阿拉伯语上表现最好，但在英语和中文上落后于其他分词器。

在现有分词器和自定义分词器之间选择

目前，有很好的一批强大分词器可供选择。许多近期模型从 GPT-4 的分词器 (OpenAI et al., 2024) 开始，并添加额外的多语言 token 来增强它。Llama 3 的分词器在多语言文本和代码方面的平均表现良好，而 Qwen2.5 的分词器在中文和一些低资源语言上表现特别出色。如何决定是使用现有选项还是训练自己的？以下是一些帮助你选择的指南：

• 何时使用现有分词器： 如果你的目标用例与上面比较的分词器的语言或领域覆盖相匹配，这些都是经过充分验证的可靠选择。对于 SmolLM3 训练，我们选择了 Llama 3 的分词器：它在我们目标语言（英语、法语、西班牙语、葡萄牙语、德语和意大利语）上提供了具有竞争力的分词质量，词汇量为 128k，这对于我们的小模型规模来说是合理的——足够大以实现多语言效率，但又不至于大到用嵌入权重使我们的 3B 参数量膨胀。对于嵌入参数占总参数比例较小的更大模型，Gemma3 的效率优势会变得更具吸引力。
• 何时训练自己的分词器： 如果你正在为低资源语言训练，或者有独特的数据混合，你很可能需要训练自己的分词器以确保良好的覆盖范围。在这种情况下，重要的是在你认为最终训练混合会是什么样子的数据集上训练分词器。这造成了一个有些鸡生蛋蛋生鸡的问题，因为你需要分词器来运行数据消融实验并找到合适的混合，但你可以在启动最终运行之前重新训练分词器，并验证下游性能是否有所提升，以及生育率是否仍然良好。

你对分词器的选择可能看起来像是一个技术细节，但它会影响模型性能的方方面面。不要害怕在这上面投入时间，把它做好。

SmolLM3

现在我们已经探索了架构领域并运行了一些消融实验，让我们看看这一切如何在 SmolLM3 这样的模型中实践结合起来。

SmolLM 系列旨在突破小型模型的可能边界。SmolLM2 在 135M、360M 和 1.7B 参数下提供了三个能力出色的模型，均被设计为能在设备端高效运行。对于 SmolLM3，我们希望在保持小到足以在手机上运行的同时提升性能，并解决 SmolLM2 的薄弱环节：多语言能力、超长上下文处理和强大的推理能力。我们选择 3B 参数作为这种平衡的最佳点。

由于我们是在扩展一个经过验证的方案，我们自然而然地倾向于密集 transformer。Nanotron 中尚未实现 MoE，而且我们已经具备训练强大小型密集模型的专业知识和基础设施。更重要的是，对于边缘设备部署，我们受内存限制；即使只有少数参数处于激活状态，拥有许多参数的 MoE 仍然需要将所有专家加载到内存中，这使得密集模型成为更实际的选择。

我们以 SmolLM2 1.7B 的架构作为基础，然后使用 Qwen2.5-3B 的布局在 100B tokens 上训练了一个 3B 消融模型。这为我们提供了一个坚实的基准，以单独测试每项修改。每项架构更改都需要在英语基准上改善损失和下游性能，或者在不降低质量的情况下提供可量化的好处（如推理速度）。

以下是我们在启动最终通过验证的运行之前测试的内容：

• 分词器： 在深入架构修改之前，我们需要选择一个分词器。我们找到了一批涵盖我们目标语言和领域的优质候选分词器。基于我们的生育率分析，Llama 3.2 的分词器为我们在六种目标语言上的性能提供了最佳权衡，同时将词汇量保持在 128k——足够大以实现多语言效率，但不至于用嵌入权重使我们的 3B 参数量膨胀。
• 分组查询注意力（GQA）： 我们重新确认了早期发现：4 组 GQA 的性能与 MHA 相当，但这次是在 3B 规模上使用 100B tokens 进行验证的。KV 缓存效率的提升实在诱人，尤其是对于内存宝贵的设备端部署。
• NoPE 用于长上下文： 我们实现了混合位置编码方案，每四层应用一次 NoPE，其余层使用 RoPE。我们的 3B 消融实验确认了之前的发现：NoPE 在不牺牲短上下文性能的情况下改善了长上下文处理能力。
• 文档内注意力遮蔽： 我们在非常长的序列上训练时防止了跨文档注意力，以帮助提升训练速度和稳定性。我们再次发现这不影响下游性能。
• 模型布局优化： 我们比较了文献中近期 3B 模型的布局，有些优先考虑深度，有些优先考虑宽度。我们在训练设置上测试了 Qwen2.5-3B（3.1B）、Llama 3.2-3B（3.2B）和 Falcon3-H1-3B（3.1B）的布局，其中深度和宽度有所不同。结果很有趣：尽管 Qwen2.5-3B 实际上参数量更少，但所有布局的损失和下游性能几乎相同。然而，Qwen2.5-3B 更深的架构与研究表明网络深度有益于泛化的结论一致 (Petty et al., 2024)。因此，我们选择了更深的布局，押注它随着训练的进行会有所帮助。
• 稳定性改进： 我们保留了 SmolLM2 中的参数绑定嵌入，但增加了一个受 OLMo 2 启发的新技巧：从嵌入中移除权重衰减。我们的消融实验表明这不会损害性能，同时降低了嵌入范数，有助于防止训练发散。

系统性消融实验方法的优点在于，我们可以自信地组合所有这些修改，因为每一项都已单独得到验证。

参与规则

TL;DR：你的用例驱动你的选择。

让部署目标指导架构决策。 在评估新的架构创新时，考虑你的模型将如何以及在哪里实际运行。

在创新与务实之间取得正确平衡。 我们不能忽视重大架构进步——在存在更好替代方案（如 GQA）的情况下使用 MHA 将是一个糟糕的技术选择。保持对最新研究的了解，并采用那些提供清晰、经过验证的规模效益的技术。但要抵制追逐每一篇承诺边际收益的新论文的诱惑（除非你有资源这样做，或者你的目标是架构研究）。

系统性胜过直觉性。 验证每一项架构变更，无论它在纸面上看起来多么有前途。在组合之前单独测试修改，以了解它们的影响。

规模效应是真实的——在可能的情况下，在目标规模上重新进行消融实验。 不要假设你的小规模消融实验将在目标模型规模上完美保持。如果你有计算资源，请尝试重新确认它们。

在你实际的领域上验证分词器效率。 跨目标语言和领域的生育率指标比追随最新模型的做法更重要。如果你不覆盖那么多语言，50k 的英语分词器无法胜任认真的多语言工作，但你也不需要 256k 的词汇表。

现在模型架构已经确定，是时候处理将驱动学习过程的优化器和超参数了。

优化器与训练超参数

各项准备工作正在就绪。我们已完成消融实验、确定了模型架构并选定了 tokenizer（分词器）。但在真正启动训练之前，还有一些关键决策需要做出：该使用哪种优化器（optimizer）？学习率（learning rate）和批量大小（batch size）应设为多少？训练过程中学习率应如何调度？

这里的诱人做法是直接借用文献中某个强大模型的参数值。毕竟，对大型实验室有效的配置，对我们应该同样有效，对吧？在许多情况下，如果我们参考的是规模和架构相近的模型，这种方法确实可行。

然而，不针对我们的具体设置调优这些参数，就有可能白白损失性能。文献中报告的超参数是针对特定数据和约束条件优化得到的，而这些约束条件有时甚至与性能无关——也许学习率是在早期开发阶段确定后就再也没有重新审视过的。即便模型作者做了充分的超参数搜索，那些最优值也是针对他们自己的架构、数据和训练机制的特定组合找到的，而不是针对我们的。文献中的参数始终是一个很好的起点，但是否能在其附近找到更优的值，还是值得探索的。

在本节中，我们将研究最新的优化器（并看看值得信赖的老牌 AdamW (Kingma, 2014) 是否仍然经受住了时间的考验），深入探讨超越标准 cosine decay（余弦衰减）的学习率调度策略，并弄清楚在给定模型和数据规模的情况下，应如何调优学习率和批量大小。

让我们从优化器之争开始。

优化器：AdamW 及其他

优化器是整个大语言模型训练操作的核心。它根据历史更新、当前权重以及从损失中计算出的梯度，决定每个参数的实际更新步骤。与此同时，它也是一头内存和算力的消耗大户，因此会影响所需 GPU 数量和训练速度。

我们不遗余力地总结了当前用于大语言模型预训练的优化器格局：

您可能会好奇，为什么大家都在使用 AdamW？

撰写本指南这部分内容的作者认为，这是因为”人们太懒了”（你好，我是 Elie），但其他人可能更现实地说，AdamW 在不同规模下长期以来表现良好/优于竞争对手，而改变如此核心的组件总是令人有些担忧——尤其是当测试其在超长训练运行中的表现既困难（即昂贵）时。

此外，公平地比较优化器比看起来更难。规模的变化会以难以在小型消融实验中模拟的方式改变动态，因此超参数调优十分复杂。您可能会说：“没关系，我已经花了好几周调优 AdamW，我可以直接复用相同的超参数进行比较！“我们多希望这是真的。但遗憾的是，对于每种优化器，您都需要进行合理的超参数搜索（1D？2D？3D？），这使得优化器研究既困难又昂贵。

那么，让我们从这个经典优化器开始——它也是 Durk Kingma 令人生畏的 Google Scholar 统治地位的基石：AdamW。

AdamW

Adam（自适应动量估计，Adaptive Momentum Estimation）是一种一阶优化技术，这意味着它只使用梯度。它通过从历史梯度中导出的动量（momentum）来为每个参数自适应地调整学习率。

细心的读者可能会问：等等，你难道少写了一个 W 吗？确实！我们特别加上 W（weight decay，权重衰减），因为在标准随机梯度下降（SGD）中，我们可以简单地在损失函数中加入 $\lambda \theta^2$（其中 $\theta$ 是权重）来应用 L2 正则化，但如果对 Adam 也这样做，自适应学习率同样会影响 L2 正则化。这意味着正则化强度会依赖于梯度幅度，从而削弱其效果。这不是我们想要的；AdamW 通过将权重衰减从主优化循环中解耦来修复这一问题。

有趣的是，过去几年来 AdamW 的超参数几乎没有变化：

• β₁ = 0.9, β₂ = 0.95
• 梯度范数裁剪（Grad norm clipping）= 1.0
• 权重衰减（Weight decay）= 0.1（Llama 3 405B 将其降至 0.01）

同样的三元组在 Llama 1、2、3 以及 DeepSeek-V1、V2、V3-671B 中被重复使用，没有任何变化。Durk Kingma 从一开始就是对的，还是我们可以做得更好？

Muon 一句话介绍

Adam 是一种一阶方法，因为它只使用梯度。Muon 是一种二阶优化器，作用于参数张量的矩阵视图：

看到这些方程，您可能会疑惑：这怎么是二阶方法——我只看到梯度，没有高阶项！二阶优化实际上发生在 Newton Schulz 步骤内部，我们在此不作进一步展开。有大量高质量的资源对 Muon 进行了深入解释，我们将只介绍三个关键思想：

1. 矩阵级几何 vs. 参数级更新： AdamW 对每个参数进行预条件处理（对角二阶矩）。Muon 将每个权重矩阵视为一个整体对象，并沿 $G=UV^{\top}$ 方向进行更新，从而捕捉行/列子空间结构。
2. 通过正交化实现各向同性步长： 利用奇异值分解（SVD）将 $G=U\Sigma V^{\top}$ 分解，可以将幅度（$\Sigma$）与方向（左/右子空间 $U,V$）分离。用 $UV^{\top}$ 替换 $G$ 会丢弃奇异值，使步长在活跃子空间中各向同性。这乍看起来有些反直觉，因为丢弃 $\Sigma$ 似乎是在丢失信息，但它减少了轴对齐偏差，并鼓励探索那些本来会被极小奇异值所抑制的方向。这种探索方式是否会在模型中积累出仅凭损失值并不明显的不同能力，目前仍是一个开放问题。
3. 对更大批量大小的经验性容忍度： 实践中，Muon 通常能容忍更大的批量大小。我们将在批量大小部分详细讨论这一点，但这可能是 Muon 被采用的一个关键动机！

多年来，社区大多沿用 AdamW，而前沿实验室的优化器方案通常保密（例如 Qwen 从不公开他们的方案），但最近 Muon 已在高知名度发布中得到采用（例如 Kimi K2 和 GLM-4.5）。希望未来我们能看到更多开放且可靠的使用方案。

优化器领域犹如一座野生动物园，研究人员在将各种动量与导数结合方面的创造力，丝毫不逊于他们为这些方法取名的才能：Shampoo、SOAP、PSGD、CASPR、DION、Sophia、Lion……甚至 AdamW 本身也有变体，如 NAdamW、StableAdamW 等。深入探讨所有这些优化器值得单独写一本指南，但我们将留待他日。与此同时，我们强烈推荐 Stanford Marin 团队的精彩论文 (Wen et al., 2025)，他们对许多不同的优化器进行了基准测试，以展示在进行比较时超参数调优的重要性。

与几乎每种优化器选择密切相关的一个问题是权重更新的强度应有多大。这由学习率决定，学习率通常在优化器方程中以一个标量的形式出现。这看似是个简单的话题，但正如您将在下一节中看到的，它有许多方面。

学习率

学习率（LR）是我们必须设定的最重要超参数之一。在每个训练步骤中，它控制着我们根据计算出的梯度对模型权重进行多大程度的调整。学习率过低会使训练慢得令人痛苦，并有陷入糟糕局部极小值的风险。损失曲线会看起来一片平坦，我们的计算预算将被消耗殆尽却没有实质性进展。另一方面，学习率设置过高会导致优化器迈出巨大步伐，越过最优解而无法收敛（或者发生难以想象的事情：损失发散并直冲云霄）。

但最佳学习率甚至不是恒定的，因为训练动态会在过程中发生变化。高学习率在早期、距良好解较远时效果好，但在收敛附近会引发不稳定。这正是学习率调度（learning rate schedule）发挥作用的地方：从零开始预热以避免早期混乱，然后衰减以稳定到一个好的极小值。这些模式（例如预热 + 余弦衰减）多年来已在神经网络训练中得到验证。

让我们来看一些常见的调度策略，然后讨论如何选取峰值。

学习率调度：超越余弦衰减

多年前人们就已知道，改变学习率有助于收敛 (Smith & Topin, 2018)，而长期以来余弦衰减 (Loshchilov & Hutter, 2017) 一直是训练大语言模型的首选调度策略：在预热后从峰值学习率开始，然后沿余弦曲线平滑地降低。这种方法简单且效果良好。其主要缺点是缺乏灵活性；我们需要预先知道要训练多少步，因为余弦周期长度必须与总训练时长相匹配。这在几种常见场景中会成为问题，例如：模型尚未收敛时您获得了更多算力想继续训练，或者您正在进行 scaling law（规模定律）实验并需要在不同 token 数量上训练同一模型。余弦衰减迫使您从头开始。

许多团队现在使用不需要在预热后立即开始衰减的调度策略。如下图所示，预热–稳定–衰减（WSD，warmup–stable–decay） (Hu et al., 2024) 和多步（multi-step） (DeepSeek-AI, :, et al., 2024) 变体就是这种情况：在大部分训练过程中保持恒定的高学习率，然后在 WSD 的最后阶段急剧衰减（通常是最后 10–20% 的 token），或者通过离散的降幅（步进）来降低学习率。例如，DeepSeek LLM 使用多步学习率调度，分别在 80% 和 90% 的训练进度处进行降幅。

这些调度策略相比余弦衰减具有实际优势。我们可以在训练中途扩展训练时长而无需重启，可以提前进行衰减以更清晰地了解训练进度，还可以在单次主训练运行内针对不同 token 数量运行 scaling law 实验。此外，研究表明 WSD 和多步方法都与余弦衰减的性能相当 (DeepSeek-AI, :, et al., 2024; Hägele et al., 2024)，同时对于实际训练场景更为实用。

但您可能已经注意到，与余弦衰减相比，这些调度策略引入了新的超参数。WSD 中的衰减阶段应持续多长时间？多步变体中每一步应持续多长时间？

• 对于 WSD： 达到与余弦衰减相当性能所需的冷却持续时间随训练时长的增加而减少。通常建议将总 token 数的 10–20% 分配给衰减阶段 (Hägele et al., 2024)。我们将在下一节的消融实验中确认此设置与余弦衰减相当。
• 对于多步方法： DeepSeek LLM 的消融实验揭示，虽然他们的基准 80/10/10 分割（稳定至 80%，第一步从 80–90%，第二步从 90–100%）与余弦衰减相当，但通过调整这些比例（例如使用 70/15/15 和 60/20/20 的分割）有可能超越它。

我们甚至可以在学习率调度上更有创意。让我们来看看其他 DeepSeek 模型中使用的调度策略：

DeepSeek LLM 使用了基准多步调度（80/10/10）。DeepSeek V2 (DeepSeek-AI, Liu, et al., 2024) 将比例调整为 60/30/10，为第一个衰减步骤提供了更多时间。DeepSeek V3 (DeepSeek-AI et al., 2025) 采用了最具创意的方法：它不是在恒定学习率后进行两次急剧步进，而是从恒定阶段以余弦衰减的方式过渡（从训练的 67% 到 97%），然后在最后急剧步进之前应用一个短暂的恒定阶段。

让我们在此结束对各类学习率调度的调研，去烧一些 GPU 时间来确定什么在实践中真正有效！

消融实验——WSD 与余弦衰减相当

是时候做消融实验了。让我们测试 WSD 是否真的能达到与余弦衰减相当的性能。我们在此不展示多步消融实验，但建议您查阅 DeepSeek LLM 的消融实验，其中显示了不同阶段分割下多步方法与余弦衰减相当的结果。

我们将余弦衰减与两种衰减窗口（10% 和 20%）的 WSD 进行比较。

评估结果表明，三种配置的最终性能相近。观察损失和评估曲线（尤其是 HellaSwag），我们发现一个有趣的模式：余弦衰减在稳定阶段（WSD 衰减开始之前）取得了更好的损失和评估分数。然而，一旦 WSD 进入衰减阶段，损失和下游指标几乎呈线性改善，使 WSD 能够在训练结束时追赶上余弦衰减。

这证实了 WSD 10–20% 的衰减窗口足以达到与余弦衰减相当的最终性能，同时保持了在训练中途扩展训练的灵活性。我们为 SmolLM3 选择了衰减比例为 10% 的 WSD。

现在我们对常见学习率调度有了很好的了解，下一个问题是：学习率实际上应该设为多少？

寻找最优学习率

为了找到我们特定调度器和训练设置的最优学习率，我们可以像为架构选择所做的那样，在短期消融实验中进行学习率扫描。但最优学习率取决于训练时长：在短期消融实验中收敛最快的学习率，未必是完整训练运行中的最佳选择。而且我们负担不起仅为测试不同学习率就多次运行耗时数周的训练。

让我们先看看一些可以快速排除明显过高或过低学习率的简单扫描。然后我们将讨论超参数的 scaling law。

消融实验——学习率扫描

为了说明学习率的影响，让我们对一个在 45B token 上训练的 1B 消融模型进行扫描。我们将在相同设置下用四种不同学习率训练同一模型：1e-4、5e-4、5e-3、5e-2。结果清楚地展示了两个极端的危险。

学习率 5e-2 几乎立即发散：损失在早期急剧上升且永远无法恢复，导致模型不可用。学习率 1e-4 过于保守；虽然训练稳定，但收敛速度远慢于其他学习率。中间选项学习率 5e-4 和 5e-3 表现出更好的收敛性和相当的性能。

对于 SmolLM3，我们使用 WSD 调度和 AdamW，在 100B token 上训练 3B 模型，比较了多个学习率。我们发现 2e-4 在损失和下游性能上的收敛速度均远快于 1e-4，而 3e-4 仅比 2e-4 略好。3e-4 带来的边际收益伴随着长训练运行中不稳定性增加的风险，因此我们选择 2e-4 作为最佳平衡点。

这些扫描帮助我们排除明显过高（发散）或过低（收敛缓慢）的学习率——但为每种模型规模都进行扫描会很快变得昂贵，更重要的是，这些较短训练运行的结果可能无法准确反映完整训练运行中的情况。这正是 scaling law 变得无价的地方。

不过，在深入讨论超参数的 scaling law 之前，让我们先讨论另一个与学习率相互作用的关键超参数：批量大小。

批量大小

批量大小（batch size）是在更新模型权重之前处理的样本数量。它直接影响训练效率和最终模型性能。如果硬件和训练栈能够良好地跨设备扩展，增大批量大小可以提高吞吐量（throughput）。但超过某个点后，更大的批量会开始损害数据效率（data efficiency）：模型需要消耗更多总 token 才能达到相同的损失。发生这一转变的临界点被称为临界批量大小（critical batch size） (McCandlish et al., 2018)。

扩大批量大小有两种方式：

• 在临界值以下增大批量大小： 增大批量大小并重新调优学习率后，您可以用与小批量运行相同数量的 token 达到相同的损失；没有数据被浪费。
• 在临界值以上增大批量大小： 更大的批量开始牺牲数据效率；达到相同损失现在需要更多总 token（因此花费更多金钱），即使实际时间减少了，因为有更多芯片在工作。

让我们思考为什么需要重新调优学习率，并了解如何估算临界批量大小。

当批量大小增大时，每个小批量的梯度成为真实梯度的更好估计。这允许您安全地采取更大的步长（即增大学习率），并在更少的更新次数内达到目标损失。问题是如何进行缩放。

对 $B$ 个样本求平均：

• 批量梯度：$\tilde{g}_{B} \;=\; \frac{1}{B}\sum_{i=1}^{B} \tilde{g}^{(i)}$
• 均值不变：$\mathbb{E}\!\left[\tilde{g}_{B}\right] \;=\; g$
• 但协方差缩小：$\mathrm{Cov}\!\left(\tilde{g}_{B}\right) \;=\; \frac{\Sigma}{B}$

SGD 参数更新为：

• $\Delta w \;=\; -\,\eta \,\tilde{g}_{B}$

此更新的方差正比于：

• $\mathrm{Var}(\Delta w) \;\propto\; \eta^{2}\,\frac{\Sigma}{B}$

因此，为了保持更新方差大致恒定，如果将批量大小缩放 $k$ 倍，则需要将学习率缩放 $\sqrt k$ 倍。假设您已计算出最优批量大小和学习率，并发现增大到临界批量大小是可行的且能提高吞吐量。您还需要相应地调整最优学习率：

对于 AdamW 或 Muon 等优化器，一个有用的经验法则是随批量大小增长采用平方根 LR 缩放，但其具体工作方式取决于优化器。例如，使用 AdamW 时，与 beta1 / beta2 的交互会引入截然不同的行为。@merrill2025criticalbatchsizerevisited 提出了一种实用替代方案：分叉训练运行持续一个短暂窗口——保持一次原始批量大小的运行，同时以较大批量大小和重新缩放的 LR 启动第二次运行，只有当两条损失曲线在重新缩放后对齐时才采用较大的批量大小。他们在切换批量大小时会对学习率进行预热并重置优化器状态。他们还设定了容差和时间窗口来判断损失是否”匹配”，这两个参数均凭经验选定。他们的结果表明，$B_\text{simple}$ 估计——本身也有噪声——低估了”实际”临界批量大小。这为您提供了一种快速、低风险的方式来检验新的批量/学习率组合是否能保持训练动态。

临界批量大小不是固定的；它随训练的进行而增大。训练早期，模型在进行大步的梯度更新，因此 $\lVert g\rVert^2$ 很大，这意味着 $B_\text{simple}$ 很小，即模型具有较小的临界批量大小。随后，随着模型更新趋于稳定，更大的批量变得更有效。这就是为什么一些大规模训练运行不保持批量大小恒定，而是使用我们称之为*批量大小预热（batch size warmup）*的策略。例如，DeepSeek-V3 在前约 469B token 使用 12.6M 的批量大小，然后在剩余训练中增加到 62.9M。这样的批量大小预热调度与学习率预热的目的相同：随着梯度噪声规模的增大，它使模型保持在高效边界上，从而在整个训练过程中维持稳定高效的优化。

另一种有趣的方法是将损失作为临界批量大小的代理指标。MiniMax-01 采用了这种方法，并在最后阶段使用了 128M 的批量大小！他们没有增大学习率，因此他们的批量大小调度起到了类似学习率衰减调度的作用。

如上文注释所述，选择批量大小和学习率起始点的一种方法是通过 scaling law。让我们来了解这些定律的工作原理。

超参数的 Scaling Law

最优学习率和批量大小不仅与模型架构和规模有关；它们还取决于算力预算，而算力预算由模型参数数量和训练 token 数量共同决定。在实践中，这些因素相互作用，决定了我们的更新应该多激进或多保守。这正是 scaling law 的用武之地。

Scaling law 建立了描述模型性能如何随训练规模（无论是更大的模型还是更多训练数据）增加而演变的经验关系（完整历史详见本章末尾）。但它们也可以帮助我们预测随着训练规模扩大，应如何调整关键超参数，如学习率和批量大小，这已在 DeepSeek LLM 和 Qwen2.5 的近期工作中得到证实。这使我们能够设定有据可依的默认值，而不是完全依赖超参数扫描。

要在此背景下应用 scaling law，我们需要一种量化训练规模的方法。标准度量是算力预算，记为 $C$，可近似为 $C\approx 6×N×D$，其中 $N$ 是模型参数数量（例如，1B = 1e9），$D$ 是训练 token 数量。这通常以 FLOPs（浮点运算次数）来衡量，这是一种与硬件无关的量化实际计算量的方式。如果 FLOPs 感觉过于抽象，可以这样理解：在 100B token 上训练一个 1B 参数模型所消耗的 FLOPs，约为在 100B token 上训练 2B 参数模型或在 200B token 上训练 1B 参数模型的一半。

常数 6 来自对训练 transformer 所需浮点运算次数的经验估计：每个参数每个 token 大约需要 6 次 FLOPs。

那么，这与学习率有何关系？我们可以推导出 scaling law，预测最优学习率和批量大小作为总算力预算（$C$）的函数。它们有助于回答以下问题：

• 当我从 1B 扩展到 7B 参数时，学习率应如何变化？
• 如果我将训练数据翻倍，应该调整学习率吗？

让我们通过回顾 DeepSeek LLM 使用的方法来了解其工作原理。首先，我们选择学习率调度策略，最好是 WSD，因为它具有灵活性。然后，我们在一系列算力预算（例如 1e17、5e17、1e18、5e18、1e19、2e19 FLOPs）下，用不同的批量大小和学习率组合训练模型。更简单地说：我们用不同的 token 数量训练不同规模的模型，测试不同的超参数设置。这正是 WSD 调度大放异彩的地方，因为我们可以将同一训练运行扩展到不同的 token 数量而无需重启。

对于每种设置，我们对学习率和批量大小进行扫描，识别出接近最优性能的配置，通常定义为最佳验证损失（在一个分布与训练集相似的独立验证集上计算）的一个小幅差距以内（例如 0.25%）。每个接近最优的配置都给我们提供一个数据点——一个（算力预算 $C$，最优学习率 $η$）或（$C$，最优批量大小 $B$）的元组。在对数-对数坐标上绘制时，这些关系通常呈现幂律行为，表现为近似直线（如下图所示）。通过拟合这些数据点，我们可以提取描述最优超参数如何随算力演变的 scaling law。

这一过程中一个重要发现是：对于固定的模型规模和算力预算，性能在大范围超参数设置下保持稳定。这意味着存在一个宽泛的最优区间，而非狭窄的最优点。我们不需要找到完美的值，只需找到足够接近的值，这使整个过程更加实用。

以下是 DeepSeek LLM 推导出的 scaling law 结果，其中每个点代表一个接近最优的设置：

这些结果背后的核心直觉是：随着训练规模变大、训练时间变长，我们希望采用更稳定的更新（更小的学习率）和更高效的梯度估计（更大的批量大小）。

这些 scaling law 为我们提供了学习率和批量大小的起点。但目标不是”每次梯度更新使用最优的样本数”，而是”在时间和 GPU 数量约束下达到更低损失”，同时充分利用每个 token 的信号。

在实践中，您可能能够将批量大小增大到超过预测的最优批量大小，以显著提高吞吐量，而不会明显损害数据效率，直到我们之前讨论的临界批量大小为止。

SmolLM3

那么我们最终为 SmolLM3 使用了什么？在消融实验阶段，我们在 100B token 上训练的 1B 模型上比较了 AdamW、AdEMAMix 和 Muon。经过适当调优后，Muon 能够超越 AdamW，但对学习率敏感且容易发散。AdeMAMix 达到了与 Muon 相近的损失，但敏感性较低。AdamW 最为稳定，但最终损失高于调优后的替代方案。

然而，当我们扩展到 3B 时，Muon 和 AdeMAMix 出现了更频繁的发散。这可能是由于我们在完成消融实验后发现的一个并行化 bug（参见”训练马拉松”章节），但我们尚未确认这一点。我们决定使用 AdamW（beta1: 0.9, beta2: 0.95），权重衰减为 0.1，梯度裁剪为 1。最终，是一套非常朴素的设置。

对于学习率调度，我们选择了 WSD。我们在 SmolLM2 中曾成功使用它，事实证明它是我们在易用性和总训练时长灵活性方面的最佳决策之一，同时还支持运行训练中途衰减实验。我们进行了学习率扫描，最终确定为 2e-4。对于全局批量大小，我们测试了从 2M 到 4M token 的值，但发现对损失或下游性能的影响微乎其微，因此选择了 2.36M token，这是给我们带来最佳吞吐量的大小。

参与规则

TL;DR：平衡探索与执行。完成胜于完美。

我们已经大量讨论了”做什么”（优化器、学习率、批量大小），但同样重要的是”怎么做”。我们如何决定什么值得实验？如何规划时间？何时停止探索，直接开始训练？

明智地分配探索与执行之间的时间。 花数周时间从一种新方法中精化微小改进的价值，不如将同等算力投入更好的数据整理或更彻底的架构消融实验。根据我们的经验，尽管这可能会令架构爱好者失望，但最大的性能提升通常来自数据整理。

当存在疑问时，选择灵活性和稳定性而非峰值性能。 如果两种方法表现同等，选择提供更多灵活性或具有更好实现成熟度和稳定性的那种。像 WSD 这样允许您扩展训练或运行训练中途实验的学习率调度，比一个可能收敛略好但固定死板的调度更有价值。

知道何时停止优化，开始训练。 总是还有一个超参数可以调优，或者一个优化器可以尝试。为探索设定一个截止日期并严格遵守——您真正完成训练的模型，永远胜过那个您从未开始训练的完美模型。

完美是优秀的敌人，在有限算力预算和截止日期的压力下尤其如此。

Scaling Law：多少参数，多少数据？

在深度学习的早期，在语言模型（以及训练它们的集群）变得”大型”之前，训练运行通常不受算力的严格限制。训练模型时，您只需选择适合硬件的最大模型和批量大小，然后训练直到模型开始过拟合或数据耗尽。然而，即使在那些早期日子里，人们已经感受到规模是有益的——例如，Hestness 等人在 2017 年提供了一套全面的结果，表明训练更大的模型更长时间能产生可预测的收益。

在大语言模型时代，我们始终受到算力的限制。为什么？早期的可扩展性概念被 Kaplan 等人在”神经语言模型的 Scaling Law”中的工作正式化，该工作表明语言模型的性能在许多数量级的规模上都具有显著的可预测性。这引发了语言模型规模和训练时长的爆炸式增长，因为它提供了一种准确预测增加规模将如何改善性能的方法。因此，构建更好语言模型的竞赛变成了在越来越大的算力预算下用更大数据量训练更大模型的竞赛，语言模型的发展迅速变得受算力约束。

面对算力限制，最重要的问题是训练更大的模型还是使用更多数据。令人惊讶的是，Kaplan 等人的 scaling law 表明，将更多算力分配给模型规模比以往最佳实践更为有利——这促使了，例如，在相对适中的 token 预算（300B token）上训练庞大的（175B 参数）GPT-3 模型。经重新审视，Hoffman 等人（2022）发现了 Kaplan 等人方法中的一个方法论问题，最终重新推导出 scaling law，表明应将更多算力分配给训练时长——例如，这表明 175B 参数 GPT-3 的算力最优训练应当消耗 3.7T token！Hoffman 等人修订后的 scaling law 被称为 Chinchilla 定律，以激发这一更新的 Chinchilla 模型命名。

这一发展将领域重心从”让模型更大”转向了”训练更长时间、更好”。然而，大多数现代训练运行仍不严格遵循 Chinchilla 定律，因为它们有一个缺陷：它们旨在预测在给定算力预算下能达到最佳性能的模型规模和训练时长，但未能考虑到更大的模型在训练之后运行代价更高的事实。换句话说，我们实际上可能更愿意用给定的算力预算训练一个更小的模型更长时间，即使这不是”算力最优”的，因为这将使推理成本更便宜（Sardana 等人，2025；de Vries，2023）。如果我们预期一个模型将被大量推理使用（例如，因为它是开放发布的 🤗），这就可能是合理的选择。近期，这种将模型训练时长”过度”超出 scaling law 建议的实践已成为标准做法，这也是我们开发 SmolLM3 时采取的方法。

虽然 scaling law 为给定算力预算提供了模型规模和训练时长的建议，但选择过度训练意味着您必须自己决定这些因素。对于 SmolLM3，我们首先选定了 3B 参数的目标模型规模。根据规模相近的近期模型，如 Qwen3-4B、Gemma 3 4B 和 Llama 3.2 3B，我们认为 3B 规模足够大，能让模型具备有意义的能力（例如推理和工具调用），但又足够小，能够实现超快推理和高效的本地使用。为了确定训练时长，我们首先注意到近期模型已经极度过度训练——例如，前述 Qwen3 系列声称已在 36T token 上进行训练！因此，训练时长通常由可用算力决定。我们获得了 384 块 H100，使用约一个月，这提供了在 11T token 上训练的预算（假设模型 FLOPs 利用率约为 30%）。

既然我们已经确定了模型架构、训练设置、模型规模和训练时长，我们还需要准备两个关键组件：教导模型的数据混合，以及可靠运行训练的基础设施。SmolLM3 的架构确定为 3B 参数后，我们需要整理能够提供强大多语言、数学和代码性能的数据混合，并建立足以支撑 11T token 训练数据的稳健基础设施。将这些基础工作做好至关重要——即使是最好的架构选择，也无法拯救糟糕的数据整理或不稳定的训练系统。

数据筛选的艺术

想象这样一个场景：你花了数周时间完善架构、调整超参数（hyperparameters）、搭建最健壮的训练基础设施。模型收敛得漂亮极了，然后……它却写不出连贯的代码，连基本的数学都磕磕绊绊，甚至会在句子中途切换语言。哪里出了问题？

答案通常藏在数据里。当我们沉迷于花哨的架构创新和超参数扫描时，数据筛选往往才是决定模型是真正有用还是只是又一次昂贵实验的关键。

如果说模型架构决定了你的模型 如何 学习，那么数据就决定了它 学什么，而再多的算力或优化器调优都无法弥补在错误内容上训练的代价。这就像随机网络爬取与精心筛选的高质量数据集之间的差距——后者才能真正教会模型我们想要的技能。但把训练数据做对，不仅仅是拥有好的数据集，更在于组装正确的 混合配比（mixture）：在相互冲突的目标之间取得平衡（例如强英文能力 vs. 强多语言鲁棒性），并调整数据比例以对齐性能目标。这个过程与其说是找到一个放之四海而皆准的”最优”配比，不如说是提出正确的问题并制定具体计划来回答它们：

• 我们希望模型擅长什么？
• 哪些数据集最适合每个领域，该如何混合它们？
• 对于目标训练规模，我们是否有足够的高质量数据？

本章将帮助你理清这些问题，综合运用有原则的方法、消融实验（ablation experiments）和一点点”炼金术”，将一堆优质数据集炼制成一个出色的训练混合配比。

什么是好的数据混合配比，它为何如此重要？

我们对语言模型寄予厚望：它们应该能帮我们写代码、给出建议、回答几乎任何问题、使用工具完成任务等等。像网络这样丰富的预训练数据来源，并不能覆盖这些任务所需的全部知识和能力。因此，近期的模型还额外依赖针对特定领域（如数学和编程）的更专业化预训练数据集。我们过去在数据集筛选方面做了大量工作，但对于 SmolLM3，我们主要使用的是已有的数据集。（想了解更多数据集筛选的内容，请参阅我们关于构建 FineWeb and FineWeb-Edu、FineWeb2 以及 Stack-Edu and FineMath 的报告。）

数据混合配比的反直觉本质

如果你刚刚接触语言模型训练，也许会觉得找到好的数据混合配比很简单：确定目标能力、为每个领域收集高质量数据集、然后合并它们。现实却更为复杂，因为某些领域可能会在训练预算上相互竞争。当专注于某项特定能力（如编程）时，人们很容易想要上调与任务相关的数据（如源代码）的比例。然而，上调一个来源实际上隐式地下调了所有其他来源，从而损害语言模型在其他场景的能力。因此，在多个不同来源上训练，本质上需要在下游能力之间找到某种平衡。

此外，在所有这些来源和领域中，往往存在一个”高质量”数据的子集，它对提升语言模型能力尤为有效。为什么不把所有低质量数据都扔掉，只在最高质量的数据上训练呢？对于训练预算很大的模型（如 SmolLM3 的 11T tokens），如此极端的过滤会导致数据被重复多次。先前的研究表明，这种重复可能是有害的 (Muennighoff et al., 2025)，所以理想情况下，我们应该能够同时利用高质量和低质量数据，同时最大化模型性能。

为了在各来源之间平衡数据，并确保拥有足够的高质量数据，我们需要仔细设计 混合配比（mixture）：来自每个来源的训练文档的相对比例。由于语言模型在任何给定任务或领域上的表现，很大程度上取决于它见过多少与该任务相关的数据，调整混合权重（mixing weights）提供了一种直接平衡模型跨领域能力的方式。由于这些权衡依赖于模型本身且难以预测，消融实验（ablations）至关重要。

此外，混合配比在训练过程中不必一成不变。通过随着训练进展调整配比——即我们所说的 多阶段训练（multi-stage training）或 课程训练（curriculum training）——我们可以更好地利用高质量和低质量数据。

训练课程的演进

在大语言模型训练的早期，标准做法是在整个训练过程中固定使用单一数据混合配比。GPT-3 和早期版本的 Llama 等模型从始至终都在一个静态配比上训练。近年来，该领域已转向多阶段方法 (Allal et al., 2025)，在训练过程中改变数据混合配比。其主要动机在于：语言模型的最终行为受训练后期所见数据的强烈影响 (Y. Chen et al., 2025b)。这一洞察促成了一种实用策略：在训练早期上调比例更大的来源，在训练后期混入体量更小、质量更高的来源。

一个常见的问题是：如何决定何时改变配比？没有通用规则，但我们通常遵循以下原则：

1. 性能驱动的干预： 在关键基准测试上监控评估指标，并调整数据集配比以解决特定能力瓶颈。例如，如果数学性能停滞不前而其他能力持续提升，这就是引入更高质量数学数据的信号。
2. 为后期阶段保留高质量数据： 体量较小的高质量数学和代码数据集，在退火阶段（即最后阶段，伴随学习率衰减）引入时效果最为显著。

既然我们已经确立了配比为何重要以及课程训练如何运作，接下来让我们讨论如何对两者进行调优。

消融实验设置：如何系统性地测试数据配方

测试数据混合配比时，我们的方法与架构消融实验类似，但有一点不同：我们尽量在目标模型规模上运行实验。小模型和大模型的容量不同。例如，一个很小的模型可能难以处理多种语言，而较大的模型则可以吸收这些语言而不牺牲其他方面的性能。因此，在过小的规模下运行数据消融实验，有可能得出关于最优配比的错误结论。

对于 SmolLM3，我们直接在 3B 模型上运行主要数据消融实验，使用了 50B 和 100B tokens 的较短训练轮次。我们还使用了另一种消融实验设置：退火实验（annealing experiments）。我们不从头开始用不同配比训练，而是从主训练轮次的中间检查点（例如在 7T tokens 处）继续训练，使用经过修改的数据组成。这种方法在 SmolLM2、Llama 3 和 OLMo 2 等近期工作中均有使用，允许我们测试多阶段训练的数据配比变化。在评估方面，我们扩展了基准测试套件，在标准英文评估的基础上加入了多语言任务，以确保能够正确评估不同语言比例之间的权衡。

近期研究已提出了寻找最优数据比例的自动化方法。例如：

• DoReMi (Xie et al., 2023) 使用一个小型代理模型来学习使验证损失最小化的领域权重。
• RHO-LOSS (Mindermann et al., 2022) 基于留出集损失（holdout loss）选择单个训练点，优先选择可学习、与任务相关且模型尚未学会的样本。
• RegMix (Q. Liu et al., 2025) 通过正则化回归（regularized regression）确定最优数据混合比例，在多个评估目标和数据领域之间平衡性能。

我们在过去的项目中试验过 DoReMi 和 RHO-LOSS，但发现它们倾向于收敛到大致反映数据集规模自然分布的分布——本质上是建议我们多用我们本来就更多的数据。尽管在理论上很吸引人，但在我们的实验设置下，它们并没有超过精心手动消融实验的表现。近期最先进的模型仍然依赖通过系统消融实验和退火实验进行的手动配比调优，这也是我们为 SmolLM3 所采用的方法。

SmolLM3：筛选数据混合配比

对于 SmolLM3，我们希望打造一个能够处理英文和多语言内容，并在数学和代码方面表现出色的模型。这些内容类型在大多数 LLM 中很常见，但我们在此描述的过程同样适用于训练低资源语言或特定领域（如金融或医疗健康）的模型。方法是一样的：确定优质候选数据集、运行消融实验，并设计一个平衡所有目标领域的配比。

我们不会在这里介绍如何构建高质量数据集，因为我们已经在早期工作中对此进行了详尽说明。本节重点介绍我们如何将这些数据集 组合 成有效的预训练混合配比。

建立在经过验证的基础之上

在预训练数据方面，好消息是我们几乎不必从零开始。开源社区已经为大多数常见领域构建了强大的数据集。有时我们需要创造新的数据集，就像我们在 Fine 系列（FineWeb、FineMath 等）中所做的那样，但更多时候挑战在于选择和组合现有来源，而不是重新发明它们。

这正是我们面对 SmolLM3 时的处境。SmolLM2 已经在 1.7B 参数规模下为英文网页数据确立了一个强大的配方，并确定了我们当时能获取的最佳数学和代码数据集。我们的目标是将这一成功扩展到 3B 参数，同时增加稳健的多语言能力、更强的数学推理和更好的代码生成等新能力。

英文网页数据：基础层

网页文本构成了任何通用 LLM 的骨架，但质量与数量同样重要。

从 SmolLM2 中，我们了解到 FineWeb-Edu 和 DCLM 是训练时最强的开源英文网页数据集。它们合计为我们提供了 5.1T tokens 的高质量英文网页数据。挑战在于确定最优混合比例：FineWeb-Edu 有助于提升教育类和 STEM 基准测试的表现，而 DCLM 则改善常识推理（common-sense reasoning）能力。

沿用 SmolLM2 的方法，我们在 3B 模型上对 100B tokens 进行了扫描，测试了 FineWeb-Edu/DCLM 比例为 20/80、40/60、50/50、60/40 和 80/20 的情况。我们发现 60/40 或 50/50 的混合比例在各基准测试间提供了最佳平衡，与我们的 SmolLM2 发现一致。我们决定在第 1 阶段采用 50/50 的比例。我们还添加了少量其他数据集，如 pes2o、Wikipedia & Wikibooks 和 StackExchange。这对性能没有任何影响，但我们将其纳入是为了提升多样性。

多语言网页数据

在多语言能力方面，我们将目标锁定在另外五种语言：法语、西班牙语、德语、意大利语和葡萄牙语。我们从 FineWeb2-HQ 中选取了这些语言的数据，共计 628B tokens。我们还以较小的比例纳入了另外 10 种语言，如中文、阿拉伯语和俄语——目的并非让这些语言达到最先进的性能，而是让用户能够轻松地在这些语言上对 SmolLM3 进行持续预训练（continual pretraining）。对于 FineWeb2-HQ 不支持的语言，我们使用了 FineWeb2。

关键问题是：我们的网页数据中应有多少比例是非英文的？我们知道，模型看到某种语言或领域的数据越多，它在该语言或领域的表现就越好。然而，固定的算力预算意味着增加一种语言的数据必然减少其他语言（包括英语）的数据。

通过在 3B 模型上进行消融实验，我们发现 12% 的多语言内容（约占整体网页混合的 14%）达到了恰当的平衡，在提升多语言性能的同时不降低英文基准测试的表现。这符合 SmolLM3 的预期使用场景，即英语仍将是主要语言。值得注意的是，非英语数据仅有 628B tokens，而英语数据高达 5.1T tokens，若比例再高，则需要对多语言数据进行更多轮次的重复训练。

代码数据

第 1 阶段的代码来源提取自 StarCoder2 and The Stack v2 训练语料库。我们纳入了：

• The Stack v2（16 种编程语言）作为基础，经过过滤后称为 StarCoder2Data
• StarCoder2 GitHub pull requests，用于真实世界的代码审查推理
• Jupyter 和 Kaggle notebooks，提供可执行的、循序渐进的工作流
• GitHub issues 和 Stack Exchange 线程，提供围绕代码的上下文讨论

Aryabumi et al. (2024) 指出，代码能够提升语言模型在编程之外的表现，例如在自然语言推理和世界知识方面，并建议在训练混合配比中使用 25% 的代码。受此启发，我们将消融实验的起点设为 25% 的代码比例。然而，我们观察到英文基准测试（HellaSwag、ARC-C、MMLU）出现了显著下降。将代码比例降至 10% 后，与 0% 代码相比，我们在英文基准测试套件上并未观察到改善，但我们还是将其纳入了，因为代码生成是模型必须具备的重要能力。

我们将 Stack-Edu——即 StarCoder2Data 经过教育过滤后的子集——推迟到后续阶段再加入，遵循的是将高质量数据留待训练后期以产生最大影响的原则。

数学数据

我们对数学采用了与代码类似的理念。早期阶段，我们使用体量更大、更通用的 FineMath3+ 和 InfiWebMath3+。后期阶段，我们上调了 FineMath4+ 和 InfiWebMath4+ 的比例，并引入了几个新的高质量数据集：

• MegaMath (Zhou et al., 2025)
• 指令和推理数据集，如 OpenMathInstruct (Toshniwal et al., 2024) 和 OpenMathReasoning (Moshkov et al., 2025)

第 1 阶段我们使用了 3% 的数学数据，在 FineMath3+ 和 InfiWebMath3+ 之间均分。由于只有 54B tokens 可用，而第 1 阶段估计需要 8T 到 9T tokens，超过这一比例将需要对数据集进行五轮以上的重复训练。

为新阶段寻找合适的配比

虽然我们从头运行消融实验来确定最佳的第 1 阶段配比，但对于后续阶段（我们有两个后续阶段）的新数据集测试，我们使用了退火消融实验。我们取约 7T tokens 处（第 1 阶段后期）的检查点，并以如下设置进行 50B tokens 的退火实验：

• 40% 基础配比： 我们一直在训练的第 1 阶段精确配比。
• 60% 新数据集： 我们想要评估的候选数据集。

例如，为了测试 MegaMath 是否能提升数学性能，我们运行了由 40% 第 1 阶段数据（维持 75/12/10/3 的领域分割）和 60% MegaMath 数据组成的退火配比实验。

全部三个阶段的组成详情，您可以在下一章中找到。

在数据经过精心筛选、混合配比通过消融实验验证之后，我们准备好踏上实际的训练之旅。接下来要讲述的，是 SmolLM3 长达一个月训练过程的故事：前期准备、意外挑战，以及沿途积累的经验教训。

训练马拉松

恭喜你坚持到了这一步——真正的乐趣即将开始！

此刻，万事俱备：经过验证的架构、最终确定的数据混合方案，以及调优好的超参数（hyperparameters）。剩下的事情就是搭建基础设施，然后按下”训练”按钮。

对于 SmolLM3，我们在 384 块 H100 GPU（48 个节点）上训练了近一个月，处理了 11 万亿个 token（词元）。本节将带你了解一次漫长训练运行中实际发生的一切：预飞行检查、不可避免的意外，以及我们如何保持训练稳定。你将亲眼见证为什么扎实的消融（ablation）实践和可靠的基础设施都至关重要。我们在最后一章中详细介绍了 GPU 硬件、存储系统和吞吐量优化等技术基础设施细节。

我们的团队经历过多次这样的训练：从 StarCoder 和 StarCoder2，到 SmolLM、SmolLM2，再到如今的 SmolLM3。每一次训练都不尽相同。即使你已经训练过十几个模型，每次新的训练都会找到新的方式让你措手不及。我们的目标是向你展示如何让胜算更多地站在你这边，以便随时应对这些意外。

预飞行检查清单：训练开始前必须核实的事项

在按下”训练”之前，我们会逐项检查清单，确保一切都能端到端正常运行。这包括：

• 基础设施就绪性：

  • 如果你的集群支持 Slurm 预留（reservation），就使用它。对于 SmolLM3，我们在整个训练期间拥有固定的 48 节点预留。这意味着没有排队延迟、吞吐量持续稳定，并且能够长期追踪节点健康状况。
  • 在启动前对 GPU 进行压力测试（我们使用 GPU Fryer 和 DCGM Diagnostics），以发现节流（throttling）或性能下降问题。对于 SmolLM3，我们发现两块 GPU 存在节流现象，并在开始训练前将其更换。
  • 避免存储膨胀。我们的系统将每个检查点（checkpoint）上传到 S3，然后在保存下一个检查点后立即删除本地副本，因此快速本地 SSD 上存储的检查点从不超过一个。

• 评估设置： 评估比看上去更耗时。手动运行评估、记录结果、绘制图表可能占用数小时。如果可能的话，将其完全自动化，并在训练开始前确保评估能够正确运行和记录。对于 SmolLM3，每个保存的检查点都会自动在集群上触发一个评估任务，并将结果记录到 Wandb 和 Trackio。

• 检查点与自动恢复系统： 验证检查点保存正确，且训练任务能够从最新检查点恢复，无需人工干预。在 Slurm 上，我们使用 --requeue 选项，这样失败的任务会自动重新启动，并从最近的检查点恢复。

• 指标记录： 确认你正在记录所有关心的指标：评估分数、吞吐量（tokens/sec，即每秒词元数）、训练损失（training loss）、梯度范数（gradient norm）、节点健康状况（GPU 利用率、温度、内存使用情况），以及特定于你的训练运行的任何自定义调试指标。

• 训练配置合理性检查： 仔细检查你的训练配置、启动脚本和 Slurm 提交命令。

规模化带来的意外

在针对 SmolLM3 进行了大量消融实验之后，我们已为全规模训练做好了准备。我们在 1000 亿 token 上进行的 3B 消融实验结果很有希望。与 SmolLM2 相比引入的架构变化（详见”架构选择”：GQA、NoPE、文档掩码（document masking）、分词器（tokenizer））要么提升了性能，要么保持了性能持平；我们还找到了在英语、多语言、代码和数学性能之间取得良好平衡的数据混合方案（参见”SmolLM3：精心设计数据混合”）。我们针对 384 块 GPU（48 个节点）优化了配置，使模型浮点运算利用率（MFU，Model FLOPs Utilization）达到约 30%。

我们已为大战做好准备：11 万亿 token。然而现实开始接连抛出变数。

谜题 #1——消失的吞吐量

启动后数小时内，吞吐量（throughput）骤然下降。这是一次急剧的跌落，并伴随着反复出现的急剧骤降。

这种情况在任何消融实验运行中都没有出现过，那么究竟发生了什么变化？有三点不同：

1. 训练数据集的规模。我们现在使用的是完整的约 24 TB 训练数据集，而不是消融实验中使用的较小子集，尽管数据来源本身是相同的。
2. 训练步数。我们为 11 万亿 token 设置了真实的步数，而不是 1000 亿 token 消融实验的短期视野。
3. 潜在的硬件状态。在消融实验中运行正常的 GPU 可能在持续负载下发生故障，网络连接也可能出现下降。

其他所有内容与吞吐量消融实验完全相同：节点数量、数据加载器（dataloader）配置、模型布局、并行设置……

直觉上，数据集大小和步数都不应导致吞吐量下降，因此我们自然首先怀疑是硬件问题。我们检查了节点监控指标，发现吞吐量的大幅下降与磁盘读取延迟的骤增相关。这直接将矛头指向了我们的数据存储。

对于 SmolLM3 的 24 TB 数据集，我们最初将数据存储在 FSx（Weka）中。但 24 TB 的训练数据，加上其他几个团队已占用的存储空间，使 Weka 的存储几乎达到了极限。它开始在训练过程中驱逐（evict）数据集分片（shards），这意味着我们不得不重新获取这些分片，从而造成停顿，这也解释了吞吐量的大幅下降。

修复 #1——更换数据存储

我们找不到在整个 Weka 训练期间将数据集文件夹固定为”热”（hot）状态的方法，因此我们尝试更换存储方式。直接从 S3 流式传输速度太慢，于是我们决定将数据存储在每个节点的本地暂存（scratch）存储上。

这有一个问题：如果某个节点故障并被替换，新的替换 GPU 上没有数据。使用 s5cmd 从 S3 下载 24 TB 数据需要 3 小时。通过使用 fpsync 从另一个健康节点复制而不是走 S3，我们将时间缩短到了 1.5 小时。这更快，因为所有节点都在同一个数据中心。

尽管如此，每次节点故障需要 1.5 小时的停机时间，以及需要立即手动将数据复制到新节点，这仍然令人痛苦。最终让这一切变得可以接受的技巧是：在我们的 Slurm 预留中保留一个预装了数据集的备用节点。如果某个节点故障，我们立即用备用节点替换它，恢复延迟为零。在空闲时，备用节点运行评估或开发任务，因此不会浪费资源。

这解决了谜题 #1……或者我们是这么以为的。

谜题 #2——持续出现的吞吐量骤降

即使在将数据迁移到暂存存储之后，单次的吞吐量骤降仍在持续出现，尽管我们在硬件监控指标中没有发现任何异常。下图将修复存储问题后（橙色）的吞吐量与消融实验期间（蓝色）的吞吐量进行了对比。如你所见，骤降实际上变得更加剧烈了。

仍然怀疑是硬件问题，我们决定在较少节点上进行测试。使用 384 块 GPU 时，某些节点发生故障的概率相当高。令人惊讶的是，无论我们测试哪个具体节点，我们都能在单个节点上复现完全相同的吞吐量骤降。这排除了硬件问题。

还记得与消融实验相比变化了的三件事吗？我们已经通过迁移到本地节点存储解决了数据存储问题，硬件问题现在也被排除了。这只剩下一个变量：步数。我们通过回滚到较小的步数（从 320 万降至 3.2 万）来测试这一假设，结果吞吐量骤降变小了！较大的步数会产生更剧烈、更频繁的骤降。

以下是我们使用的精确配置，其他所有内容保持不变：

## Short run (32k steps)
- "lr_decay_starting_step": 2560000
- "lr_decay_steps": 640000
- "train_steps": 3200000

## Long run (3.2M steps)
+ "lr_decay_starting_step": 26000
+ "lr_decay_steps": 6000
+ "train_steps": 32000

如下图所示，结果非常明确：较短的训练产生小的吞吐量骤降，而较大的步数则产生更剧烈、更频繁的骤降。因此，问题不在于硬件，而是软件瓶颈——考虑到训练中大多数其他组件对每个批次的处理方式与步数无关，瓶颈很可能出在数据加载器上。

这时我们才意识到，我们实际上从未使用 Nanotron 的数据加载器进行过大规模预训练。SmolLM2 使用的是源自 Megatron-LM 的数据加载器（TokenizedBytes），通过围绕 Nanotron 的内部包装器实现，并以稳定的吞吐量完成了训练。对于 SmolLM3，我们切换到了 Nanotron 内置的数据加载器（nanosets）。

经过对其实现的深入分析，我们发现它在朴素地构建一个随每个训练步数增长的巨大索引。对于非常大的步数，这会导致更高的共享内存使用量，从而触发吞吐量骤降。

修复 #2——引入 TokenizedBytes 数据加载器

为了确认数据加载器确实是罪魁祸首，我们使用 TokenizedBytes 数据加载器在我们的内部 SmolLM2 框架上启动了相同的配置。使用相同数据集，在 48 个节点上没有出现任何骤降。

最快的解决方案：将这个数据加载器复制到 Nanotron 中。骤降消失了，吞吐量恢复到目标水平。

我们准备重新启动……直到下一个变数出现。

谜题 #3——嘈杂的损失

使用新数据加载器后，我们没有再遇到吞吐量骤降，但损失曲线（loss curve）看起来更嘈杂了。

nanosets 曾产生更平滑的损失，这一差异让我们想起了一场古老的调试大战：几年前，我们在预训练代码中发现了一个 shuffle（随机打乱）错误，文档被打乱了，但批次内的序列没有，导致出现小幅骤升。

检查我们的新数据加载器证实了这一点：它从每个文档中顺序读取序列。对于短文件来说这没问题，但对于代码等领域，一个单独的长低质量文件可能填满整个批次并导致损失骤升。

修复 #3——在序列级别进行打乱

我们有两个选择：

1. 修改数据加载器以进行随机访问（风险：更高的内存使用量）。
2. 离线预先打乱词元化序列。

鉴于开始训练的时间压力以及集群预留的倒计时，我们选择了选项 #2 作为更安全、更快速的修复方案。词元化数据已在每个节点上，因此本地重新打乱成本很低（约 1 小时）。我们使用不同的随机种子为每个轮次（epoch）生成了打乱后的序列，以避免在各个轮次之间重复打乱模式。

第二次启动

至此，我们已具备：

• 稳定的吞吐量（暂存存储 + 备用节点策略）
• 无步数诱发的骤降（TokenizedBytes 数据加载器）
• 干净的序列级打乱（按轮次离线预打乱）

我们重新启动了训练。这一次，一切都稳住了。损失曲线平滑，吞吐量稳定，我们终于可以专注于训练本身，而不是疲于应对各种突发状况。

谜题 #4——令人不满意的性能

我们顺利训练了前两天，日志中没有任何问题的迹象。然而，在大约处理了 1 万亿个 token 时，评估结果揭示了一些出人意料的事情。

作为监控工作的一部分，我们会评估中间检查点，并将其与历史训练运行进行比较。例如，我们拥有 SmolLM2（1.7B）使用类似配方训练时的中间检查点，因此可以追踪两个模型在训练相同阶段时的进展情况。结果令人费解：尽管拥有更多参数和更好的数据混合，3B 模型在相同训练阶段的表现却比 1.7B 模型更差。损失仍在下降，基准测试分数也在提升，但提升速度明显低于预期。

鉴于我们已经彻底测试了 SmolLM3 相比 SmolLM2 引入的每个架构和数据变化，我们将注意力转向了训练框架。在两套训练设置之间，只剩下少数几个未经测试的差异。最明显的是张量并行（TP，Tensor Parallelism）：SmolLM2 可以放在单个 GPU 上，无需 TP 进行训练，而 SmolLM3 需要 TP=2 才能放入内存。我们之前没有想到要测试这一点，因为 TP 在 3B 消融实验中有所使用，且其结果看起来合理。

修复 #4——最终的修复

为了测试 TP 错误的假设，我们使用与 SmolLM3 完全相同的设置训练了一个 1.7B 模型——相同的架构变化（文档掩码、NoPE）、相同的数据混合、相同的超参数——分别使用和不使用 TP。差异立竿见影：TP 版本的损失持续高于非 TP 版本，下游性能也更低。这证实了我们面临的是一个与 TP 相关的错误。

随后我们详细检查了 TP 实现，比较了来自 TP 和非 TP 运行的权重。问题原来微妙但影响深远：我们在所有 TP rank（秩）上使用了相同的随机种子，而每个 rank 本应使用不同的种子进行初始化。这导致分片（shard）之间的权重初始化出现相关性，从而影响了收敛（convergence）。这个影响并非灾难性的——模型仍在训练并持续改进——但它引入了足够的低效率，足以解释我们在规模上观察到的差距。

以下是错误修复：

diff --git a/src/nanotron/trainer.py b/src/nanotron/trainer.py
index 1234567..abcdefg 100644
--- a/src/nanotron/trainer.py
+++ b/src/nanotron/trainer.py
@@ -185,7 +185,10 @@ class DistributedTrainer:
     ):
         # Set random states
-        set_random_seed(self.config.general.seed)
+        # Set different random seed for each TP rank to ensure diversity
+        tp_rank = dist.get_rank(self.parallel_context.tp_pg)
+        set_random_seed(self.config.general.seed + tp_rank)

+

修复随机种子使每个 TP rank 使用不同种子后，我们重复了消融实验，并确认 TP 和非 TP 运行在损失曲线和下游性能上都已匹配。为了确保没有其他隐藏问题，我们进行了额外的合理性检查：一次 SmolLM2 风格（架构和数据层面）的 3B 参数运行，以及一次单独的 SmolLM3 3B 参数运行，并将两者与 SmolLM2 的检查点进行了比较。结果现在与预期一致：1.7B 的 SmolLM2 表现不如 3B 的 SmolLM2 变体，而后者的表现又被 SmolLM3-3B 超越。

这一调试过程强化了我们之前阐述的核心原则之一：“扎实消融设置的真正价值不仅仅在于构建一个好的模型。当我们主训练运行期间出现问题时（无论我们准备多么充分，这种情况都会发生），我们希望对自己做出的每个决定充满信心，并能够快速识别哪些组件没有经过充分测试，可能正在导致问题。这种准备节省了调试时间，也保护了我们未来的精神健康。”

没有什么比盯着神秘的训练失败、却不知道错误藏在哪里更糟糕的了。因为训练设置中的所有其他组件都已经过验证，我们能够将 TP 确定为唯一合理的原因，并在检测到性能差距后的一天内修复了这个错误。

至此，我们解决了自启动以来浮出水面的一系列意外问题中的最后一个。第三次出发，终成正果：从那时起，剩余的一个月训练相对平稳——就是将数万亿 token 转化为最终模型的稳定工作，中间偶尔因节点故障而重启。

坚守航向

如上一节所示，从消融实验扩展到全规模预训练并不是简单的”即插即用”。它带来了意想不到的挑战，但我们成功地识别并解决了每个问题。本节涵盖大规模训练运行所必需的监控设置和注意事项。我们将回答关键问题：遇到问题后何时应该重启训练？如何处理在训练深入阶段才暴露的问题？哪些指标才真正重要？整个训练过程中数据混合方案是否应该保持固定？

训练监控：超越损失曲线

我们发现张量并行错误的原因，不是损失曲线——它看起来一切正常——而是下游评估落后于预期。此外，拥有 SmolLM2 中间检查点的评估结果至关重要，因为它们给了我们一个早期信号，表明 3B 模型的轨迹不对。因此，如果你在训练大型模型，请尽早开始运行下游评估，如果你在与开源模型进行比较，可以询问作者是否能提供中间检查点。这些可以作为无价的参考点。

在基础设施层面，最重要的指标是吞吐量，以每秒 token 数衡量。对于 SmolLM3，我们预期整个训练过程中吞吐量稳定在 13,500–14,000 tokens/sec 之间，任何持续偏差都是一个红色警报。但吞吐量单独来看是不够的：你还需要持续的硬件健康监控，以预测和检测硬件故障。我们追踪的一些关键指标包括 GPU 温度、内存使用量和计算利用率。我们将这些指标记录到 Grafana 仪表板，并为硬件异常设置了实时 Slack 告警。

修复后重启 vs. 边运行边修复

鉴于我们在处理了 1 万亿 token 后重启了训练，一个重要的问题随之而来：出现问题时是否总需要重启？答案取决于问题的严重程度和根本原因。

在我们的案例中，TP 随机种子错误意味着我们从一开始就走错了方向；一半的权重没有被正确初始化。模型的表现与 SmolLM2 相似，并在相似的节点达到了瓶颈，这意味着我们很可能最终得到一个性能相同但训练成本几乎翻倍的模型。重启是合理的。然而，许多问题可以在运行过程中纠偏，以避免浪费计算资源。最常见的问题是损失骤升（loss spike），即训练损失突然跳增，可能预示着轻微的波动或发散（divergence）。

正如 Stas Bekman 在 Machine Learning Engineering Open Book 中精辟地描述的那样：“训练损失图类似于心跳模式——有好的、有坏的，还有让你应该担心的。”

损失骤升分为两类：

• 可恢复的骤升： 这些骤升可能快速恢复（在骤升后立即恢复），也可能缓慢恢复（需要更多训练步骤才能回到骤升前的轨迹）。通常可以继续训练度过这些骤升。如果恢复非常缓慢，可以尝试回退到之前的检查点，跳过有问题的批次。
• 不可恢复的骤升： 对于这些骤升，模型要么发散，要么在比骤升前更差的性能上停滞。它们需要比简单回退到之前检查点更重大的干预。

虽然我们对训练不稳定性（training instabilities）的理解并不完整，但我们知道它们在规模增大时会变得更加频繁。假设采用了保守的架构和优化器，常见的原因包括：

• 过高的学习率： 会在训练早期引发不稳定，可以通过降低学习率来解决。
• 劣质数据： 这通常是可恢复骤升的主要原因，尽管恢复可能很慢。问题可能在训练深入时出现，当模型遇到低质量数据时。
• 数据与参数状态的交互： PaLM (Chowdhery et al., 2022) 观察到骤升通常源于特定数据批次与模型参数状态的组合，而非单纯是”劣质数据”。在不同检查点上对同样有问题的批次进行训练并不能复现骤升。
• 初始化不当： OLMo 2 (OLMo et al., 2025) 的最新研究表明，从缩放初始化切换到简单正态分布（均值=0，标准差=0.02）可以提高稳定性。
• 精度问题： 虽然现在已经没有人用 FP16 训练了，但 BLOOM 发现它与 BF16 相比极不稳定。

你可以怎么做？

在骤升发生之前，建立稳定性

采用保守学习率和良好数据的小模型很少出现骤升，但较大的模型需要主动采取稳定性措施。随着越来越多的团队在规模上进行训练，我们积累了一套有助于防止训练不稳定性的技术。这些包括：

• 数据过滤和打乱： 到目前为止，你已经注意到我们多少次兜兜转转回到数据话题。确保你的数据干净且充分打乱可以防止骤升。例如，OLMo 2 发现删除含有重复 n-gram（1 到 13 个 token 的跨度重复 32 次以上）的文档，显著降低了骤升频率。
• 训练修改： Z-loss 正则化可以防止输出 logit 增长过大，同时不影响性能。从权重衰减（weight decay）中排除嵌入层（embeddings）也有帮助。
• 架构变化： QK-norm（在注意力之前对查询（query）和键（key）投影进行归一化）已被证明是有效的。OLMo2 和其他团队发现它有助于稳定性，有趣的是，Marin 团队发现它甚至可以在训练过程中途应用，以修复发散问题。

当骤升仍然发生时——损害控制

即使有了这些预防措施，骤升仍然可能发生。以下是一些修复选项：

• 跳过有问题的批次： 回退到骤升之前并跳过有问题的批次。这是修复骤升最常见的方法。Falcon 团队 (Almazrouei et al., 2023) 跳过了 10 亿个 token 来解决他们的骤升问题，而 PaLM 团队 (Chowdhery et al., 2022) 发现跳过骤升位置附近 200–500 个批次可以防止复发。
• 收紧梯度裁剪（gradient clipping）： 临时降低梯度范数阈值。
• 应用架构修复： 如上所述，QK-norm 可能有效。

我们已经回顾了所遇到的规模化挑战（从吞吐量骤降到 TP 错误）、尽早发现问题的监控实践，以及防止和修复损失骤升的策略。我们将通过讨论多阶段训练如何提升模型最终性能来结束本章。

中途训练

现代大型语言模型（LLM）预训练通常涉及多个阶段，每个阶段使用不同的数据混合方案，通常还会跟随一个扩展上下文长度的最终阶段。例如，Qwen3 (A. Yang, Li, et al., 2025) 采用三阶段方法：在 4k 上下文长度下对 30 万亿 token 进行通用阶段训练、强调 STEM 和编程的 5 万亿高质量 token 推理阶段，以及最后在 32k 上下文长度下对数千亿 token 进行长上下文阶段。SmolLM3 遵循类似的理念，包含有计划的干预措施（引入更高质量的数据集并扩展上下文），以及基于性能监控的响应式调整。

正如我们在上一章中解释的，数据混合方案不必在整个训练过程中保持固定。多阶段训练允许我们随着训练的进行策略性地调整数据集比例。一些干预措施从一开始就计划好了：对于 SmolLM3，我们知道我们会在阶段 2 引入更高质量的 FineMath4+ 和 Stack-Edu，然后在最终衰减阶段加入精选的问答（Q&A）和推理数据。其他干预措施是响应式的，由训练期间的性能监控驱动。例如，在 SmolLM2 中，当我们发现数学和代码性能落后于目标时，我们精心整理了全新的数据集（FineMath 和 Stack-Edu），并在训练中途引入了它们。这种灵活性——无论是遵循计划好的课程表，还是适应新出现的差距——正是让我们能够最大化计算预算价值的关键。

第 2 阶段和第 3 阶段的数据混合

下图展示了我们的三个训练阶段以及训练过程中网页/代码/数学比例的变化情况。每个阶段的 SmolLM3 训练配置（包含精确的数据权重）可在 SmolLM GitHub 仓库中找到。有关每个阶段构成背后的基本原理的更多详情，请参阅”数据精心整理的艺术”。

阶段 1——基础训练（8 万亿 token，4k 上下文）： 基础阶段使用我们的核心预训练混合方案：来自 The Stack v2 和 StarCoder2 的网页数据（FineWeb-Edu、DCLM、FineWeb2、FineWeb2-HQ）、代码，以及来自 FineMath3+ 和 InfiWebMath3+ 的数学数据。所有训练在 4k 上下文长度下进行。

阶段 2——高质量注入（2 万亿 token，4k 上下文）： 在这一阶段，我们引入了更高质量的过滤数据集，包括用于代码的 Stack-Edu、用于数学的 FineMath4+ 和 InfiWebMath4+，以及用于高级数学推理的 MegaMath（我们还添加了 Qwen 问答数据、合成改写和文本-代码交织块）。

阶段 3——带推理和问答数据的学习率衰减（1.1 万亿 token，4k 上下文）： 在学习率衰减阶段，我们进一步上采样（upsample）高质量代码和数学数据集，同时引入指令（instruction）和推理数据，如 OpenMathReasoning、OpenCodeReasoning 和 OpenMathInstruct。问答样本简单地进行拼接，并用换行符分隔。

长上下文扩展：从 4k 到 128k Token

上下文长度决定了你的模型可以处理多少文本。这对于分析长文档、维持连贯的多轮对话以及处理整个代码库等任务至关重要。SmolLM3 最初在 4k token 下训练，但我们需要扩展到 128k 以满足实际应用需求。

为什么要在训练中途扩展上下文？

从一开始就在长上下文上训练在计算上非常昂贵，因为注意力机制（attention mechanisms）随序列长度呈二次方扩展。此外，研究表明，在训练结束时或持续预训练（continual pretraining）期间，用几十到一百亿 token 扩展上下文，就足以达到良好的长上下文性能 (Gao et al., 2025)。

顺序扩展：4k → 32k → 64k

我们没有直接跳到 128k。而是分阶段逐步扩展上下文，让模型在进一步扩展之前有时间适应每个长度。我们运行了两个长上下文阶段：首先从 4k 增加到 32k，然后从 32k 增加到 64k（128k 能力来自推理时的外推（extrapolation），而不是训练）。我们发现，为每个阶段在 500 亿 token 上重新开始一个学习率调度，比在主衰减阶段最后 1000 亿 token 扩展上下文效果更好。在每个阶段，我们都进行了消融实验，以找到良好的长上下文数据混合和 RoPE theta 值，并在 RULER 基准测试上进行了评估。

在这个阶段，通常需要上采样长上下文文档（如长篇网页和书籍）以提高长上下文性能 (Gao et al., 2025)。我们运行了几次消融实验，对书籍、文章，甚至合成生成的文档（用于检索和填空等任务）进行上采样，遵循 Qwen2.5-1M 的方法 (A. Yang, Yu, et al., 2025)，使用 FineWeb-Edu 和 Python-Edu。令人惊讶的是，与仅使用阶段 3 的基线混合方案相比，我们没有观察到任何改进，而基线混合方案在 RULER 上已经与 Llama 3.2 3B 和 Qwen2.5-3B 等其他最先进模型具有竞争力。我们推测这是因为基线混合方案自然包含来自网页数据和代码的长文档（估计占 token 的 10%），以及使用 NoPE 有所帮助。

带调整基频的 RoPE（ABF，Adjusted Base Frequency）

当上下文长度从 4k 扩展到 32k 时，我们将 RoPE 基频（theta）增加到 2M；从 32k 扩展到 64k 时，我们将其增加到 5M。我们发现使用更大的值（如 10M）略微改善了 RULER 分数，但损害了一些短上下文任务（如 GSM8k），因此我们保持在 5M，这不会影响这些任务。

在这个上下文扩展阶段，我们还借机进一步上采样了数学、代码和推理问答数据，并添加了几十万条 ChatML 格式的样本。

YARN 外推：达到 128k

我们希望 SmolLM3 在推理时能够处理 128k，但在 128k 序列上训练的代价过于高昂。作为替代，我们使用了 YARN（Yet Another RoPE extensioN，又一种 RoPE 扩展方法）(B. Peng et al., 2023)，它允许模型在训练长度之外进行外推。

理论上，YARN 允许序列长度增加四倍。我们发现使用 64k 检查点在 128k 下的表现优于使用 32k 检查点，这证实了训练时长度越接近目标推理长度越有利。然而，推进到 256k（4 × 64k）显示出 RULER 性能下降，因此我们建议仅将模型用于 128k 以内的场景。

至此，我们已经走过了 SmolLM3 完整的预训练历程，从规划和消融实验，到最终的训练运行，以及其中一路涌现的幕后挑战。

预训练收尾

我们涵盖了大量内容：从帮助决定为何训练以及训练什么的训练指南针，到验证每个架构选择的战略规划和系统性消融实验，再到实际的训练马拉松——在我们的案例中，意外在规模化后接连出现（吞吐量神秘崩溃、数据加载器瓶颈，以及一个微妙的张量并行错误，迫使我们在处理了 1 万亿 token 后重启）。

那些精致的技术报告背后凌乱的现实如今已清晰可见：训练 LLM 既需要规范的实验和快速的调试，也需要架构创新和数据精心整理。 规划确定了什么值得测试，消融实验验证每个决策，监控及早发现问题，而当事情不可避免地崩溃时，系统性的风险消除告诉你应该去哪里找问题。

具体到 SmolLM3，这个过程实现了我们最初设定的目标：一个在 11 万亿 token 上训练的 3B 模型，在数学、代码、多语言理解和长上下文任务上具有竞争力，处于 Qwen3 系列模型的帕累托前沿（Pareto frontier）。

基础模型检查点已保存，训练也已完成，我们可能会想就此打住。毕竟，我们拥有一个能够很好地预测文本、在基准测试上取得强劲分数，并展示了我们所追求能力的模型。一切就绪，对吧？

还没有。因为今天人们想要的是助手和编程智能体（coding agents），而不是原始的下一个 token 预测器。

这正是后训练（post-training）的用武之地。就像预训练一样，现实比你想象的更为复杂。

超越基座模型——2025 年的 Post-Training（后训练）

一旦预训练完成，我们应该能在一天之内得到一个 SFT 基线。

预训练赋予了 SmolLM3 原始的能力，但在 GPU 还没冷却下来之前，我们就进入了模型能力的下一个前沿： post-training（后训练） 。这包括监督微调（supervised fine-tuning）、强化学习（reinforcement learning）、模型合并（model merging）等等——所有这些都旨在弥合「一个会预测文本的模型」与「一个人们真正能用的模型」之间的鸿沟。如果说预训练是把知识硬塞进权重里，那么后训练就是把这种原始能力雕琢成可靠且可控的东西。而再一次地，那些打磨光鲜的后训练论文并没有捕捉到深夜里的那些意外：GPU 过热熔毁、挑剔的数据混合（data mixture），或是一个看似微不足道的 chat template（聊天模板）决策如何在下游 benchmark（基准测试）上层层传导。在本章中，我们将展示我们如何在杂乱无章的后训练世界中摸索前行，将 SmolLM3 从一个强大的基座模型转变为最先进（state-of-the-art）的混合推理模型（hybrid reasoner）。

后训练罗盘：Why → What → How

就像预训练一样，后训练也能从一个清晰的罗盘中受益，以避免浪费研究和工程上的迭代周期。下面是构建它的方式：

1. 为什么要做后训练（Why post-train）？ 我们在预训练罗盘中概括的三大训练动机同样适用于后训练。例如，你可能正在探索强化学习是否能在现有模型中解锁新的推理能力（研究），或者你可能因为延迟原因需要把一个大模型蒸馏成一个小模型（生产），又或者你发现了某个特定用例尚无强大开源模型可用的空白（战略性开源）。其区别在于，后训练是在现有能力的基础上构建，而非从零创造。但在你伸手去碰 GPU 之前，先问问自己：

   • 你真的需要后训练吗？如今许多开放权重（open-weight）模型在广泛的任务上已经能与专有模型相媲美。有些甚至可以通过量化（quantization）和适度算力在本地运行。如果你想要一个通用型助手，Hugging Face Hub 上一个现成的模型可能已经能满足你的需求。
   • 你能获取高质量的领域专属数据吗？当你瞄准一个通用模型表现不佳的特定任务或领域时，后训练才最有意义。有了合适的数据，你可以调优模型，使其为你最关心的应用产出更准确的输出。
   • 你能衡量成功吗？没有清晰的评测标准，你就无法知道后训练是否真的有帮助。

2. 后训练应该达成什么（What should post-training achieve）？ 这取决于你的优先级。你想要的是：

   • 一个很少偏离主题、严守指令的模型？
   • 一个能按需切换语气和角色的多面手助手？
   • 一个能攻克数学、代码或 agentic（智能体）问题的推理引擎？
   • 一个能用多种语言对话的模型？

3. 你将如何到达那里（How will you get there）？ 这就是 recipe（配方）发挥作用的地方。我们将涵盖：

   • 监督微调（Supervised fine-tuning, SFT） 用于灌输核心能力
   • 偏好优化（Preference optimization, PO） 用于直接从人类或 AI 偏好中学习
   • 强化学习（Reinforcement learning, RL） 用于超越监督数据，进一步精炼可靠性和推理能力
   • 数据策展（Data curation） 用于在多样性和质量之间取得恰当的平衡
   • 评测（Evaluation） 用于追踪进展并及早发现性能回退

这个罗盘让后训练的混乱有了落脚点。 why 给出方向， what 设定优先级， how 则把雄心壮志转化为一个切实可行的训练循环。

让我们来看看我们是如何为 SmolLM3 回答这些问题的：

• Why？ 对我们来说，“why” 很直白，因为我们有一个在发布前需要后训练的基座模型。与此同时，像 Qwen3 这样的混合推理模型正变得越来越流行，然而展示如何训练它们的开放配方却很稀缺。SmolLM3 给了我们一个同时实现两个目标的机会：为现实世界使用准备一个模型，并贡献一份完全开放的配方，使其与 Qwen3 的 1.7B 和 4B 模型一同站在帕累托前沿（Pareto front）上。
• What？ 我们着手训练一个为 SmolLM3 的优势量身定制的混合推理模型，主要的优势在于推理质量应当在英语以外的语言中也能保持。而且由于现实世界的使用越来越多地涉及 tool calling（工具调用）和长上下文（long context）工作流，这些就成了我们后训练配方中的核心需求。
• How？ 这就是你将在本章余下部分中找到的答案！

就像预训练一样，后训练也是从基础、评测和基线开始的，因为每个大模型都始于一次小的消融实验（ablation）。但在消融的方式上有一个关键区别。在预训练中，“小”通常意味着更小的模型和数据集。在后训练中，“小”意味着更小的数据集和 更简单 的 算法 。我们几乎从不用一个不同的基座模型来做消融，因为行为太依赖于具体模型，而且训练运行足够短，可以直接在目标模型上迭代。

让我们从一个许多模型训练者直到项目太晚才去面对的话题开始：评测。

首要之事：评测先于一切

后训练的第一步——就像预训练一样——是决定一套正确的评测。由于当今大多数 LLM 都被用作助手，我们发现，瞄准一个”好用”的模型，比追逐像 ARC-AGI 那样抽象的”智能”基准更好。那么，一个好的助手需要做什么呢？至少，它应该能够：

• 处理含糊的指令
• 逐步规划
• 编写代码
• 在适当的时候调用工具

这些行为依赖于推理、长上下文处理，以及数学、代码和工具使用方面技能的综合运用。参数量在 3B 甚至更小的模型也能很好地胜任助手角色，不过当低于 1B 时，性能通常会急剧下滑。

在 Hugging Face，我们使用一套分层的评测套件，呼应我们在消融章节中详述的预训练原则（单调性、低噪声、高于随机的信号、排序一致性）。

评测一个后训练模型有很多方法。这些方法包括：

1. 能力评测（Capability evals）。 这一类评测瞄准基础技能：

   • 知识： 我们目前使用 GPQA Diamond (Rein et al., 2024) 作为科学知识的主要评测。这个 benchmark 由研究生水平的多选题组成。对于小模型而言，它远未饱和，并且比 MMLU 之类提供更好的信号，同时运行速度快得多。另一个不错的事实性测试是 SimpleQA (Wei et al., 2024)，尽管小模型由于知识有限，往往在这个 benchmark 上表现得相当吃力。
   • 数学： 为了衡量数学能力，当今大多数模型都在最新版本的 AIME（目前是 2025 版）上进行评测。MATH-500 (Lightman et al., 2023) 对小模型来说仍是一个有用的健全性测试（sanity test），但它已基本被推理模型饱和。要获得一套更全面的数学评测，我们推荐来自 MathArena 的那些。
   • 代码： 我们使用最新版本的 LiveCodeBench 来追踪编程能力。尽管它针对的是竞赛编程问题，我们发现 LiveCodeBench 上的提升确实能转化为更好的编程模型，尽管仅限于 Python。SWE-bench Verified 是一个更复杂的编程技能衡量标准，但它对小模型而言往往太难，因此通常不在我们的考量范围内。
   • 多语言能力： 不幸的是，在测试模型的多语言能力时，可选项并不多。我们目前依赖 Global MMLU (Singh et al., 2025) 来瞄准我们的模型应当表现良好的主要语言，并纳入 MGSM (Shi et al., 2022) 作为多语言数学能力的测试。

2. 集成任务评测（Integrated task evals）。 这些评测测试的能力，与我们希望交付的那些相似：

   • 长上下文使用： 长上下文检索最常用的测试是 Needle in a Haystack（NIAH，大海捞针）(Kamradt, 2023)，其中一个随机事实（“针”）被放置在一个长文档（“草堆”）的某处，模型必须把它检索出来。然而，这个 benchmark 太过表层，无法区分长上下文理解能力，因此社区开发了更全面的评测，比如 RULER (Hsieh et al., 2024) 和 HELMET (Yen et al., 2025)。最近，OpenAI 发布了 MRCR 和 GraphWalks 这两个 benchmark，进一步扩展了长上下文评测的难度。

• 指令遵循（Instruction following）： IFEval (J. Zhou et al., 2023) 目前是衡量指令遵循最流行的评测；它使用针对”可验证指令”的自动评分。IFBench (Pyatkin et al., 2025) 是 Ai2 推出的一个扩展，它包含比 IFEval 更多样的约束集，并缓解了近期一些模型发布中出现的 benchmaxxing¹（刷榜）。对于多轮指令遵循，我们推荐 Multi-IF (He et al., 2024) 或 MultiChallenge (Sirdeshmukh et al., 2025)。
• 对齐（Alignment）： 衡量模型与用户意图对齐的程度，通常由人工标注者完成，或者通过 LMArena 这样的公开排行榜进行。这是因为自由形式生成、风格和整体有用性等品质，很难用自动化指标进行定量衡量。然而，运行这些评测非常昂贵，这就是为什么社区转而使用 LLM 作为人类偏好的代理。这类最流行的 benchmark 包括 AlpacaEval (Dubois et al., 2025)、ArenaHard (T. Li et al., 2024) 和 MixEval (Ni et al., 2024)，其中后者与 LMArena 上的人类 Elo 评分相关性最强。
• 工具调用（Tool calling）： 伯克利函数调用排行榜（Berkeley Function Calling Leaderboard, BFCL） 提供了一个全面的工具调用测试，尽管它往往很快就被饱和。TAU-Bench (Barres et al., 2025) 测试模型在模拟客服场景中使用工具并解决用户问题的能力，也已成为一个流行的报告基准。

1. 过拟合预防评测（Overfitting prevention evals）。 为了测试我们的模型是否对某个特定技能过拟合，我们在评测集中纳入了一些鲁棒性或适应性评测，比如 GSMPlus (Q. Li et al., 2024)，它对 GSM8k (Cobbe et al., 2021) 中的问题进行扰动，以测试模型是否仍能解决相似难度的问题。
2. 内部评测（Internal evals）。 尽管公开 benchmark 在模型开发期间能提供一些有用的信号，但它们无法替代你实现自己的内部评测来瞄准特定能力，或请内部专家与你的模型互动。例如，对于 SmolLM3，我们需要一个 benchmark 来评估模型是否具备多轮推理能力，于是我们实现了一个 Multi-IF 的变体来衡量这一点。

1. 氛围评测与竞技场（Vibe evals and arenas）。 类似地，我们发现对中间检查点（checkpoint）进行”氛围测试（vibe testing）“（即与模型互动）对于发现评测分数未能捕捉的模型行为中的微妙怪癖至关重要。正如我们稍后讨论的，氛围测试发现了我们数据处理代码中的一个 bug——所有 system message 都从语料库中被删除了！这件事也可以大规模进行，以衡量人类偏好，比如在流行的 LMArena 上。然而，众包的人类评估往往很脆弱（偏好谄媚和华丽辞藻而非实际有用性），所以重要的是把它视为一种低信号的反馈。

对于 SmolLM3，我们想要一个混合推理模型，它能可靠地遵循指令，并在数学和代码等流行领域中推理良好。我们还想确保保留了基座模型的多语言和长上下文检索能力。

这引导我们得出以下这套评测：

让我们看几个示例问题，以便对这些评测实际测试什么有一个具体的感受。

你可以在交互式查看器中浏览这些示例，看看每个 benchmark 中的问题类型。注意领域的多样性如何确保我们在整个消融过程中测试了模型能力的不同方面。

对于我们当时所用的 3B 模型规模，我们觉得这些评测（运行起来比训练本身还快）能给我们提供可付诸行动的信号，并让我们有信心相信任何改进都是真实的，而不仅仅是采样带来的噪声。我们还追踪了我们的预训练评测（完整列表见消融章节），以确保我们在基座模型性能上没有回退太多。

交战规则

让我们用几条历经千辛万苦、通过评测数千个模型才学到的教训来总结这一节：

• 使用 小子集 来加速模型开发期间的评测。例如，LiveCodeBench v4 与 v5 高度相关，但运行时间只有一半。或者，使用 tinyBenchmarks (Polo et al., 2024) 中的方法，它寻找能可靠匹配完整评测的最小 prompt 子集。
• 对于 推理模型 ，从 被评分 的输出中剥离思维链（chain of thought）。这能消除假阳性，也直接影响像 IFEval 这样的 benchmark——它会惩罚违反约束（如”用不到 50 个词写一首诗”）的回答。
• 如果某个评测使用 LLM 评判者（judge），就 固定评判者及其版本 ，以便随时间进行同类对比。更好的做法是，使用一个开放权重模型，这样即使某个供应商弃用了评判模型，评测仍然可复现。
• 警惕基座模型中的 污染（contamination） 。例如，大多数在 AIME 2025 之前发布的模型在该测试上的表现明显差于 AIME 2024，这表明存在某种刷榜行为。
• 如果可能，把消融期间使用的任何东西都视为 验证集（validation） ，而非 测试集（test）。 这意味着为最终模型报告保留一套留出（held-out）的 benchmark，类似于 Tulu 3 评测框架 (Lambert et al., 2025)。
• 始终在你自己的数据和任务上纳入一小套 “氛围评测（vibe evals）” ，以捕捉对公开套件的过拟合。
• 对于问题数量较少的评测（通常少于约 2k 个），采样 k 次并报告 avg@ k 准确率。这对于缓解噪声很重要，否则噪声可能在开发期间导致错误决策。
• 实现一个新评测时，确保你能 复现几个模型已发表的结果（在一定误差范围内）。如果做不到这一点，一旦你后面需要修复实现并重新评测许多检查点，就可能浪费大量时间。
• 当存疑时，总是要 回到评测数据本身 ，检查你究竟在用什么来提示你的模型。

有了评测，是时候训练一些模型了！但在那之前，我们需要挑选一个后训练框架。

行业利器

每一个后训练配方的背后，都有一个由框架和库组成的工具箱，它们使得大规模实验成为可能。每个框架都带来了它自己支持的算法、微调方法和可扩展性特性。下表总结了主要的支持领域，从监督微调到偏好优化和强化学习：

这里， FullFT 指的是 全量微调（full fine-tuning） ，即训练期间更新所有模型参数。 LoRA 代表 低秩适配（Low-Rank Adaptation） ，一种参数高效（parameter-efficient）的方法，它只更新小的低秩矩阵，同时保持基座模型冻结。 多模态（Multi-modal） 指的是是否支持在文本以外的模态（例如图像）上训练，而 分布式（Distributed） 表示是否能在多于一个 GPU 上训练模型。

在 Hugging Face，我们开发并维护 TRL，所以它是我们的首选框架，也是我们用来对 SmolLM3 进行后训练的框架。

为什么还要费心用框架？

有那么一类研究者，热衷于抱怨使用训练框架，并主张你应该始终从零实现一切。这里隐含的论点是，“真正的”理解只能来自重新实现每一个 RL 算法、手动编写每一个分布式训练原语，或者东拼西凑出一个一次性的评测框架。

但这种立场忽视了现代研究和生产的现实。以 RL 为例。像 PPO 和 GRPO 这样的算法是出了名的难以正确实现 (Huang et al., 2024)，而在归一化或 Kullback–Leibler（KL）惩罚项上的微小错误，都可能导致数天的算力和精力白白浪费。

类似地，尽管为某个算法写一个单文件实现可能很诱人，但同一个脚本能从 1B 扩展到 100B+ 参数吗？

框架的存在恰恰是因为基础已经被充分理解了，没完没了地重新发明它们是对时间的拙劣利用。这并不是说低层次的折腾没有价值。从零实现一次 PPO 是一个绝佳的学习练习。不用框架写一个玩具 transformer 能教会你 attention 究竟是如何工作的。但在大多数情况下，你最好就挑一个你喜欢的框架，然后为你的目的去魔改（hack）它。

发完这通牢骚之后，让我们来看看我们的训练运行通常从哪里开始。

为什么（几乎）每个后训练流程都从 SFT 开始

如果你最近在 X 上花点时间，你大概会觉得强化学习是唯一的玩家。每天都有新的缩写词、算法上的微调，以及关于 RL 究竟能否激发新能力的激烈辩论 (Chu et al., 2025; Yue et al., 2025)。

当然，RL 并不新鲜。OpenAI 和其他实验室在对齐他们的早期模型时，曾大量依赖从人类反馈中进行强化学习（RLHF）(Lambert et al., 2022)，但直到 DeepSeek-R1 (DeepSeek-AI, Guo, et al., 2025) 发布，基于 RL 的后训练才真正在开源生态中流行起来。

不过，有一件事没有改变：几乎每个有效的后训练流程仍然从监督微调开始。原因很直接：

• 它便宜： 与 RL 相比，SFT 需要的算力适中。你通常无需烧掉一大堆硅片就能获得有意义的收益，而且所需时间只是 RL 的一小部分。
• 它稳定： 不像 RL 那样对奖励设计和超参数出了名地敏感，SFT “就是好使”。
• 它是正确的基线： 一个好的 SFT 检查点通常能给你带来你想要的大部分收益，而且它能让后续方法（如 DPO 或 RLHF）有效得多。

在实践中，这意味着 SFT 之所以是第一步，不仅仅因为它简单；而是因为它是那个能持续提升性能的步骤，在尝试任何更复杂的东西之前都最合理。当你处理基座模型时尤其如此，因为基座模型——除了少数例外——太过粗糙，无法从高级后训练方法中受益。

那么，如果说大多数流程从 SFT 开始，下一个问题就是： 该 微调什么？这要从选择正确的基座模型开始。

挑选一个基座模型

为后训练选择基座模型时，有几个实际维度最为重要：

• 模型大小： 尽管 smol（小）模型随时间已经显著改进，但直到今天，更大的模型泛化得更好仍然成立，而且往往用更少的样本就能做到。选择一个能代表你计划在训练后如何使用或部署模型的大小。在 Hugging Face Hub 上，你可以按模态和大小筛选模型，找到合适的候选者。

• 架构（MoE vs. dense）： MoE（专家混合）模型每个 token 激活参数的一个子集，提供了更高的单位算力容量。它们非常适合大规模服务（serving），但根据我们的经验，更难微调。相比之下，dense（稠密）模型训练起来更简单，且在较小规模下往往优于 MoE。
• 后训练履历： Benchmark 很有用，但如果基座模型已经催生了一批与社区共鸣的强大后训练模型，那就更好了。这为模型是否好训练提供了一个代理指标。

根据我们的经验，来自 Qwen、Mistral 和 DeepSeek 的基座模型最易于进行后训练，其中 Qwen 是明显的最爱，因为每个模型系列通常都覆盖了很大的参数范围（Qwen3 模型大小从 0.6B 到 235B 不等！）。这一特性让规模扩展（scaling）变得直接得多。

一旦你选好了一个符合你部署需求的基座模型，下一步就是建立一个简单、快速的 SFT 基线，来探测它的核心技能。

训练简单基线

对于 SFT，一个好的基线应当训练得快、聚焦于模型的核心技能，并且在某项能力不达标时易于用更多数据扩展。选择哪些数据集来做初始基线，需要一些品味，以及对那些很可能高质量的数据集的熟悉。一般来说，避免过度看重那些在学术 benchmark 上报告高分的公开数据集，而是聚焦于那些被用来训练优秀模型的数据集，比如 OpenHermes。例如，在 SmolLM 的开发中，我们最初在 WebInstruct 上运行 SFT，这在纸面上是个很棒的数据集。然而，在我们的氛围测试中，我们发现它太偏向科学了——对于像”你好吗？“这样简单的问候，模型会用方程式来回应。

这促使我们创建了 Everyday Conversations 数据集，事实证明，它对于给小模型灌输基本的聊天能力至关重要。

对于 SmolLM3，我们着手训练一个混合推理模型，并最初挑选了一小套数据集，瞄准推理、指令遵循和可控性（steerability）。下表展示了每个数据集的统计信息：²

正如我们在 SmolLM3 的整个开发过程中所学到的，训练混合推理模型比标准 SFT 更棘手，因为你不能只是把数据集混在一起；你需要跨模式 配对（pair） 数据。每个示例都必须清楚地标明模型应当进行扩展推理还是给出简洁的回答，而且理想情况下，你想要平行的示例来教会它何时切换模式。从这张表中要注意的另一件事是，你应当以 token 而非 示例 为单位来平衡你的数据混合：例如，s1k-1.1 数据集占总示例数的约 1%，但由于其冗长的推理回答，却占据了总 token 数的约 11%。

这给了我们在最关心的那些技能上的基本覆盖，但也引入了一个新挑战：每个数据集都必须根据它应该启用扩展思考与否而有不同的格式化方式。为了统一这些格式，我们需要一个一致的 chat template。

挑选一个好的 Chat Template

在选择或设计 chat template 时，并没有一刀切的解决方案。在实践中，我们发现有几个值得事先问清的问题：

• 用户能自定义 system 角色吗？ 如果用户应该能够定义他们自己的 system prompt（例如，“扮演一个海盗”），那么模板需要干净利落地处理这一点。
• 模型需要工具吗？ 如果你的模型需要调用 API，模板就需要为工具调用和响应容纳结构化输出。
• 它是推理模型吗？ 推理模型使用像 <think> ... </think> 这样的模板，把模型的”思考”与它的最终答案分隔开。一些模型会在对话的各个回合间丢弃推理 token，而 chat template 需要处理这个逻辑。
• 它能与推理引擎配合工作吗？ 像 vLLM 和 SGLang 这样的推理引擎有专门的推理和工具解析器（parser）。³ 与这些解析器的兼容性能省去后面很多麻烦，尤其是在那些一致的工具调用至关重要的复杂 agent benchmark 中。⁴

下表展示了几个流行的 chat template，以及它们在关键考量上的对比：

在大多数情况下，我们发现 ChatML 或 Qwen 的 chat template 是一个绝佳的起点。对于 SmolLM3，我们需要一个用于混合推理的模板，并发现 Qwen3 是少数几个在我们所关心的各个维度上取得良好平衡的模板之一。然而，它有一个我们不太满意的怪癖：除最后一个回合外，所有回合的推理内容都被丢弃了。如下图所示，这与 OpenAI 的推理模型 的工作方式类似：

flowchart LR
    subgraph Turn1 ["Turn 1"]
        T1_Input["**INPUT**"]
        T1_Output["**OUTPUT**"]
    end

    subgraph Turn2 ["Turn 2"]
        T2_Input["**INPUT**"]
        T2_Output["**OUTPUT**"]
    end

    subgraph Turn3 ["Turn 3"]
        T3_Input["**INPUT**"]
        T3_Output1["**OUTPUT**"]
        Reasoning["**REASONING**"]
        T3_Output2_Top["**OUTPUT**"]
        TruncatedOutput["**TRUNCATED OUTPUT**"]
    end

    T1_Input --> T2_Input
    T1_Output --> T2_Input

    T2_Input --> T3_Input
    T2_Output --> T3_Input

    T3_Input --> T3_Output1
    T3_Output1 --> Reasoning
    Reasoning --> T3_Output2_Top

    T3_Output2_Top -->|CONTEXT WINDOW ✂️| TruncatedOutput

    classDef input fill:#e8f5e8,stroke:#4caf50,stroke-width:2px
    classDef output fill:#e3f2fd,stroke:#2196f3,stroke-width:2px
    classDef reasoning fill:#f5f5f5,stroke:#999,stroke-width:1px
    classDef truncated fill:#ffebee,stroke:#f44336,stroke-width:3px
    classDef subgraphStyle fill:#f8f9fa,stroke:#dee2e6,stroke-width:1px
    classDef linkLabel fill:#f8f9fa,stroke:#dee2e6,stroke-width:1px

    class T1_Input,T2_Input,T3_Input input
    class T1_Output,T2_Output,T3_Output1,T3_Output2_Top output
    class Reasoning reasoning
    class TruncatedOutput truncated
    class Turn1,Turn2,Turn3 subgraphStyle
    linkStyle 4 stroke:#333,stroke-width:2px,fill:#f8f9fa

尽管这对于 推理 来说是合理的（为了避免上下文爆炸），但我们得出的结论是，对于 训练 而言，保留所有回合的推理 token 很重要，以便恰当地条件化（condition）模型。

于是，我们决定打造我们自己的 chat template，具备以下特性：

• 一个结构化的 system prompt，类似于 Llama 3 的 以及那些从专有模型中越狱出来的。我们还想提供完全覆盖 system prompt 的灵活性。
• 支持 code agents（代码智能体），它们执行任意 Python 代码而非进行 JSON 工具调用。
• 通过 system message 对推理模式进行显式控制。

为了迭代 chat template 的设计，我们使用了 Chat Template Playground。这个由我们 Hugging Face 的同事开发的便捷应用，让预览消息如何被渲染以及调试格式化问题变得容易。它看起来是这样的：

你可以自己试一试。从下拉菜单中选择不同的示例，看看 chat template 在多轮对话、推理或工具使用时是如何工作的。你甚至可以手动修改 JSON 输入来启用不同的行为。例如，看看如果你提供 enable_thinking: false 或在 system message 后附加 /no_think 会发生什么。

一旦你确定了一些初始数据集和一个 chat template，就该训练一些基线了！

婴儿级基线

在我们一头扎进优化、榨取每一分性能之前，我们需要建立一些”婴儿级基线（baby baselines）“。这些基线并不是为了达到最先进水平（暂时还不是），而是旨在验证 chat template 做了我们想要的事情，并且初始的超参数集能产生稳定的训练。只有在我们有了这个基础之后，才会开始大力调优超参数和训练混合。

谈到训练 SFT 基线，主要需要考虑以下几点：

• 你会使用全量微调，还是像 LoRA 或 QLoRA（量化 LoRA）这样的参数高效方法？正如 Thinking Machines 那篇精彩的博客文章所描述的，在某些条件下（通常由数据集的大小决定），LoRA 能够匹敌 FullFT。
• 你需要哪种类型的并行？对于小模型或用 LoRA 训练的模型，你通常用数据并行（data parallelism）就能应付。对于更大的模型，你将需要 FSDP2 或 DeepSpeed ZeRO-3 来分片（shard）模型权重和优化器状态。对于用长上下文训练的模型，使用像上下文并行（context parallelism） 这样的方法。
• 如果你的硬件支持，就使用像 FlashAttention 和 Liger 这样的 kernel（核）。这些 kernel 中的许多都托管在 Hugging Face Hub 上，并可以在 TRL 中通过一个简单的参数来设置，从而大幅降低 VRAM（显存）的使用。
• 对损失进行掩码以只在 assistant token 上训练。正如我们稍后讨论的，这可以通过用一个特殊的 {% generation %} 关键字包裹你 chat template 的 assistant 回合来实现。
• 调优学习率（learning rate）。除了数据之外，这是决定你的模型是”还行”还是”很棒”最重要的因素。
• 打包训练样本（Pack the training samples） 并调优序列长度以匹配你数据的分布。这将大幅加速训练。TRL 有一个便捷的应用来替你完成这件事。

让我们看看其中一些选择对 SmolLM3 是如何起作用的。对于我们第一批基线实验，我们想要一个简单的健全性检查：chat template 真的能激发混合推理吗？为了测试这一点，我们比较了来自我们那张表的三种数据混合：

• Instruct（指令型）： 在非推理示例上训练。
• Thinking（思考型）： 在推理示例上训练。
• Hybrid（混合型）： 在所有示例上训练。

对于每种混合，我们在 SmolLM3-3B-Base 上使用 FullFT 运行 SFT，学习率为 1e-5，有效批量大小（effective batch size）为 128，训练 1 个 epoch。

由于这些是小数据集，我们没有使用打包，将 Instruct 子集的序列上限设为 8,192 个 token，其余的设为 32,768 个 token。在一个由八块 H100 组成的节点上，这些实验运行起来很快，根据子集的不同耗时在 30–90 分钟之间。下图比较了每个子集在相应推理模式下的性能。

这些结果很快向我们表明，混合模型表现出一种”裂脑（split brain）“现象，即一种推理模式的数据混合对另一种模式几乎没有影响。这一点从大多数评测在 Instruct、Thinking 和 Hybrid 子集上得分相近就可看出，而 LiveCodeBench v4 和 IFEval 是例外，在这两者上混合数据提升了整体性能。

氛围测试你的基线

尽管评测看起来还行，但当我们试图让混合模型扮演不同人设（例如，像海盗一样）时，它始终无视我们放在 system message 中的任何内容。经过一番挖掘，我们发现原因在于我们格式化数据的方式：

在我们 chat template 的设计中，我们暴露了一个 custom_instructions 参数来存储 system prompt。例如，下面是我们如何在对话中设置一个人设：

from transformers import AutoTokenizer

tok = AutoTokenizer.from_pretrained("HuggingFaceTB/SmolLM3-3B")

messages = [
    {
        "content": "I'm trying to set up my iPhone, can you help?",
        "role": "user",
    },
    {
        "content": "Of course, even as a vampire, technology can be a bit of a challenge sometimes [TRUNCATED]",
        "role": "assistant",
    },
]
chat_template_kwargs = {
    "custom_instructions": "You are a vampire technologist",
    "enable_thinking": False,
}
rendered_input = tok.apply_chat_template(
    messages, tokenize=False, **chat_template_kwargs
)
print(rendered_input)
## <|im_start|>system
### Metadata

## Knowledge Cutoff Date: June 2025
## Today Date: 28 October 2025
## Reasoning Mode: /no_think

### Custom Instructions

## You are a vampire technologist

## <|im_start|>user
## I'm trying to set up my iPhone, can you help?<|im_end|>
## <|im_start|>assistant
## <think>

## </think>
## Of course, even as a vampire, technology can be a bit of a challenge sometimes # [TRUNCATED]<|im_end|>