LLM训练实战：从零到一的完整指南

1. 前言

在旁观者眼中，一篇光鲜亮丽的研究论文似乎总把模型训练描绘得轻而易举：正确的架构选择、精心策划的数据集，再加上充足的算力，一切水到渠成。最终的结果光彩夺目，消融实验（ablations）清晰明了，仿佛每一个决策都是理所当然。

然而，这些报告往往只展示了成功的“果”，并用“玫瑰色的滤镜”回顾了过程。它们没有记录下那些凌晨两点还在调试的 dataloader、训练中突然爆发的 Loss 尖峰，或是那个悄无声息破坏你训练的张量并行（Tensor Parallelism）Bug。现实远比论文描述的更加混乱、更依赖迭代，充满了那些最终未能写进纸面的“纠结瞬间”。

这一次，我们将带你深入幕后，直击 SmolLM 的训练全程——这是一个在 11万亿（11T）Token 上训练出来的 30亿（3B）参数多语言推理模型。

这并非一篇按部就班的博客，而是一份详尽的实战梳理，它网罗了我们在构建世界级语言模型过程中的所有决策、发现乃至走过的弯路，旨在为你揭示那些最核心的洞察。

同时，本文也是我们模型训练系列长文的收官之作。此前，我们已经深入探讨了大规模数据集的构建（FineWeb）、如何调度数千块GPU协同工作（Ultra Scale Playbook），以及如何在每个环节选择最佳评估方法（Evaluation Guidebook）。现在，我们将把所有这些要素融会贯通，共同打造一个强大的AI模型。

我们将全程陪伴，不仅分享最终成功的“秘方”，更会剖析那些塑造了每一个决策的失败、基础设施故障以及艰难的调试过程。

这个故事读起来就像一出扣人心弦的“戏剧”：

你会看到，为何那些在小规模实验中前景光明的想法，到大规模训练时却可能“水土不服”。
为什么我们在训练了 1万亿（1T）Token 后不得不从头重启。
如何有效地平衡多语言、数学和代码这几个相互竞争的目标，同时保持强大的英语性能。
以及最终，我们是如何后训练（post-train）出一个混合推理模型的。

我们努力将这趟冒险之旅组织成一个连贯的故事，而非一份冰冷的步骤清单。请将它视为一本实战手册，献给所有渴望从“我们有优秀的数据集和GPU”迈向“我们构建了一个真正强大的模型”的实践者。

我们希望这种毫无保留的分享，能够弥合研究与生产之间的鸿沟，让你下一次的训练之旅少一些混乱，多一份从容。

1.1 如何阅读这篇文章？

坦白说，这篇文章篇幅极长，想一口气从头读到尾并不现实。

好消息是，我们已将文章结构化为几个相对独立的板块，你可以根据自己的兴趣和需求，选择性地阅读或跳过。

以下是文章的结构指南：

🧭 训练指南针 (Training Compass)：
- 核心内容： 宏观探讨你是否应该亲自预训练（Pretrain）一个模型。
- 适用人群： 在你“烧光”所有风投资金之前，我们为你列出几个必须扪心自问的问题，并系统地指导你完成决策。
- 温馨提示： 这部分偏向战略思考。如果你是“技术党”，想直奔硬核内容，可以快速浏览。
🚀 预训练 (Pretraining)：
- 核心内容： 涵盖了构建可靠预训练流程所需的一切知识：如何运行消融实验、选择评估指标、混合数据源、制定架构决策、调整超参数，以及最终“熬过”这场训练马拉松。
- 适用人群： 无论你是计划从头预训练，还是对持续预训练（Continued Pretraining）感兴趣，这个板块都值得一读。
🍒 后训练 (Post-training)：
- 核心内容： 你将学到最大化利用预训练模型所需的所有“技巧”。从 SFT (监督式微调)、DPO (直接偏好优化) 到 模型合并（Model Merging），我们将揭示这些充满“炼金术”色彩操作背后的门道。
- 价值所在： 我们将分享那些通过惨痛教训换来的宝贵经验，希望能让你在实践中少走弯路。
🏭 基础设施 (Infrastructure)：
- 核心比喻： 如果说预训练是蛋糕，后训练是糖霜，那么基础设施就是那台工业级烤箱。没有它，一切免谈；如果它出故障，你愉快的烘焙时光就会变成一场灾难。
- 核心内容： 本节将详细讲解 GPU 布局、各组件间的通信模式，以及如何识别和克服瓶颈，这些知识往往分散在各种库、文档和论坛中。

那么，从何处开始呢？很简单，选择你最感兴趣的板块，让我们即刻出发！

2. 训练指南针：灵魂三问（Why → What → How）

机器学习领域似乎对“优化”有种近乎痴迷的执着。我们的目光总是聚焦于Loss曲线、模型架构和训练吞吐量。然而，在深入这些技术细节之前，一个更根本的问题常常被忽略：我们真的有必要从头训练这个模型吗？

如今的开源AI生态系统几乎每天都在涌现世界级的模型：Qwen、Gemma、DeepSeek、Llama……这份名单还在不断加长。它们不再是简单的研究原型，而是可以直接用于生产的强大模型，覆盖了从多语言理解到代码生成，再到复杂推理的广泛应用场景。更重要的是，它们大多附带宽松的许可协议，并拥有活跃的社区随时提供支持。

这也引出了一个残酷的真相：也许，你根本不需要训练自己的模型。

这听起来像是一个“大模型训练指南”最奇怪的开场白。但事实是，许多失败的训练项目，并非因为超参数设置不当或代码有Bug，而是因为决策者决定训练一个他们根本不需要的模型。因此，在投入真金白银和时间之前，你必须先回答两个核心问题：你为什么要训练这个模型？ 你应该训练一个什么样的模型？ 如果对这两个问题没有清晰的答案，你很可能会浪费数月的算力与工程师时间，最终造出一个“重复的轮子”，甚至更糟——一个根本没人需要的东西。

让我们从 “Why”（为什么） 开始。因为如果目标不明确，后续的所有决策都将是无的放矢。

2.1 Why：那个没人愿意回答的问题

让我们坦诚地谈谈现实中经常发生的一幕。

某人（如果足够幸运）获得了GPU集群的访问权限，思路通常是这样的：“我们有100块H100，闲置三个月，不如来训练一个模型吧！”于是，模型大小被随意选定，数据集从各处拼凑而来，训练就这样开始了。六个月后，算力预算和团队士气消耗殆尽，模型却无人问津，只因从未有人认真问过“为什么”。

以下是一些绝对不应该成为你训练模型理由的常见想法：

“我们恰好有空闲的算力。”（这是资源，不是目标。）
“别人都在做。”（这是同侪压力，不是战略。）
“AI是未来。”（这是陈词滥调，不是计划。）
“我们想要最强大的模型。”（这个目标过于模糊，无法指导任何实际决策。）

“我们训练了自己的模型”这句话听起来很有诱惑力。但在投入大量资源之前，请务必扪心自问：你到底为什么需要训练这个模型？

在启动一个大型预训练项目前，你应该先理清思路。从技术角度看，首要问题是：是否已经有一个现成的模型，通过简单的提示（Prompt）或微调（Fine-tune）就能满足你的需求？

本质上，只有在以下三个领域，定制化的预训练才可能真正有意义：你想进行开创性的研究，你的生产用例有非常特殊的需求，或者你想填补开源生态系统中的某个空白。让我们逐一分析：

2.1.1 科研（Research）：你到底想验证什么？

在LLM领域，有无数值得研究的课题。这些研究项目的共同点是，它们通常都始于一个清晰定义的问题。例如：

我们能否将基于某种新型优化器的训练扩展到百亿参数以上的模型？
仅使用强化学习，不依赖SFT，能否有效激发模型的推理能力？
我们能否仅靠纯合成的“教科书式”数据，训练出优秀的小型模型？
我们能否通过只训练公开许可的数据来达到具有竞争力的性能？

把研究假设设定得尽可能具体，并提前思考所需的实验规模，能够大大增加成功的几率。

2.1.2 产品化（Production）：为什么现有模型不够用？

企业之所以不能直接使用现成的通用模型（off-the-shelf models），主要有三个原因。其中两个是技术性的，另一个则关乎治理。

第一个原因是领域特殊性（Domain Specificity）。 当你的数据或任务涉及高度专业化的词汇或结构，而现有通用模型无法很好地处理时。例如：

一个处理DNA序列的模型，需要独特的词汇表和处理长距离依赖关系的能力。
一个法律或金融模型，要求对领域特定的术语和逻辑有深刻的理解。

第二个原因是部署约束（Deployment Constraints）。 当你需要模型适配特定的硬件、延迟或隐私要求时。例如，一个需要在无人机上运行，或在配备定制硬件（如FPGA）的本地系统上运行的大模型。

这里有一个简单的测试方法：花几天时间，基于Qwen、Gemma或其他SOTA模型进行构建。你能通过提示（Prompting）、工具调用（Tool-use）或后训练（Post-training） 达到你的性能目标吗？如果不能，那么或许就该自己训练一个了。

友情提醒： 即使为了满足需求，所需的后训练预算非常庞大，它仍可能比从头开始预训练更经济。 毕竟，为模型微调1万亿（1T）Token，依然比从头训练10万亿（10T）Token更划算。

第三个原因是安全与治理（Safety and Governance）。 如果你身处一个受严格监管的行业或处理高风险应用，你需要对训练数据、模型行为和更新周期拥有完全的控制权。你需要确切地知道模型中包含了什么，并能够向监管机构证明这一点。在这种情况下，自建模型可能是唯一的选择。

以上是企业训练内部模型的主要原因。那么，那些发布开源模型的组织又是如何考虑的呢？

2.1.3 战略性开源（Strategic Open-Source）：你是否看到了可以填补的空白？

经验丰富的AI实验室发布新的开源模型，最常见的原因之一是：他们识别出了开源生态系统中的一个特定空白或一个新的AI应用场景。

这种模式通常是这样的：你注意到一个未被充分探索的领域。也许现在缺少一个强大且具备超长上下文能力的端侧（on-device）模型；或者现有的多语言模型在低资源语言上表现不佳；又或者，行业正在转向交互式世界模型，但还没有好的开源替代品出现。

你有理由相信自己可以做得更好。也许你整理了更优质的训练数据，开发了更出色的训练“配方”，或者拥有其他机构无法企及的算力优势来支持“过度训练”（Overtrain）。你的目标是具体的：不是“史上最强模型”，而是“最适合端侧使用的3B模型”，或“首个具备1M上下文的小模型”。

这是一个真实且有价值的目标。成功会创造巨大的价值：开发者会采用你的模型，它会成为他人的基础设施，或者为你建立技术信誉。但成功需要经验。在一个竞争激烈的领域，你需要清楚地知道什么是可行的，以及如何可靠地执行。

为了让这个思路更具体，让我们看看Hugging Face是如何思考这个问题的。

2.1.4 Hugging Face的思考：我们为什么要训练开源模型？

Hugging Face致力于构建对开源生态系统有用的东西，并填补那些鲜有人涉足的空白。

这包括数据集、工具，当然也包括模型。我们启动的每一个LLM训练项目，都始于发现一个空白，并坚信我们能做出有意义的贡献。

我们最初的LLM项目是在GPT-3发布后启动的。当时，似乎没有人愿意构建一个开放的替代品，我们担心相关知识最终会被少数几个工业实验室垄断。因此，我们发起了BigScience研讨会，旨在训练一个开源版本的GPT-3。最终诞生的Bloom模型，汇集了数十位贡献者一年的努力，从构建训练堆栈、分词器到预训练语料库，最终预训练出一个175B参数的模型。

Bloom的继任者是2022年的StarCoder。当时OpenAI为GitHub Copilot开发的Codex是闭源的。很明显，一个开源替代品将为整个生态系统带来巨大价值。因此，我们与ServiceNow合作，在BigCode框架下，构建了The Stack数据集，并训练了StarCoder 15B来复现Codex的能力。StarCoder2的诞生，则源于我们认识到可以进行更长时间的训练，并意识到更小但训练更久（overtrained）的模型可能比一个巨型模型更有价值。我们训练了一个模型家族（3B/7B/15B），使用了数万亿的Token，远超当时任何开放代码模型的训练量。

SmolLM系列也遵循了类似的模式。我们注意到当时强大的小型模型非常稀缺，而我们刚刚构建了FineWeb-Edu这个强大的预训练数据集。SmolLM (135M/360M/1.7B)是我们的第一个版本。SmolLM2则专注于更好的数据和更长的训练，在多个方面达到了SOTA性能。而SmolLM3则扩展到了3B参数，同时加入了混合推理、多语言能力和长上下文等社区在2025年高度重视的功能。

这种模式甚至延伸到了预训练之外：我们训练了Zephyr来证明DPO可以大规模应用；启动了Open-R1来复现DeepSeek R1的蒸馏管线；并发布了用于竞技编程的OlympicCoder。我们还探索了其他模态，例如用于视觉的SmolVLM和用于机器人技术的SmolVLA。

希望这一部分已经说服你：深入思考你为什么要训练一个模型是极具价值的。

在本文接下来的部分，我们将假设你已经完成了这场“灵魂拷问”，并且有了一个充分且合理的理由来启动你的训练项目。

2.2 What：将目标转化为实际决策

既然你已经明确了为什么要训练，接下来就该确定应该训练什么了。

这里的“做什么”（What）指的是：模型类型（密集型、MoE、混合型，还是全新类型）、模型规模、架构细节和数据混合配比。

一旦确定了“Why”，你就可以顺理成章地推导出“What”。举例来说：

训练目的 (Why)	$\rightarrow$	模型规格 (What)
追求可在端侧运行的快速模型	$\rightarrow$	小巧且高效的模型
构建强大的多语言模型	$\rightarrow$	更大的分词器词汇表
需要超长上下文能力	$\rightarrow$	混合型架构

除了受用例驱动的决策外，还有一些选择旨在优化训练本身，例如让训练更稳定、更具样本效率或速度更快。这些决策并非总是非黑即白，但你可以大致将决策过程分为两个阶段：

规划阶段（Planning）： 在实验之前，你需要将你的用例映射到具体的组件上：你的部署环境决定了模型规模的限制；你的时间表决定了你可以承担哪些架构风险；你的目标能力决定了数据集的要求。这个阶段的核心就是将“Why”中的每一个约束，都与“What”中的具体规格紧密相连。

验证阶段（Validation）： 一旦你有了一个起点和一份潜在修改清单，就要进行系统性的测试。由于测试成本高昂，你应该将精力集中在那些能有意义地提升用例性能或显著优化训练过程的改动上。这就是消融实验（Ablations）发挥作用的地方，我们将在后续章节详细介绍。

在接下来的章节中，你将了解到定义模型的所有选项，以及如何通过系统性实验来缩小选择范围。但在那之前，我们想分享一些关于如何组织团队和项目的经验——这些经验来自于我们自己训练模型的实践，以及观察那些成功构建优秀LLM团队的做法。

2.3 How：迭代速度与数据质量

通往成功的道路不止一条，但我们发现，成功的LLM训练团队之所以能脱颖而出，其关键在于迭代速度。

训练LLM本质上是一种“边做边学”的学科，你训练的次数越多，团队就会变得越优秀。因此，那些一年只训练一个模型的团队，和那些一个季度就能训练一个模型的团队相比，后者的进步速度会快得多。Qwen和DeepSeek等团队如今已是家喻户晓，他们正是凭借长期以来持续快速地发布新模型而奠定地位的。

除了迭代速度，数据策划（Data Curation）是迄今为止对LLM训练最具影响力的方面。人们天然倾向于钻研架构来改进模型，但那些在大模型训练中表现优异的团队，无一不是对高质量数据痴迷到无以复加的团队。

另一个与迭代速度紧密相关的因素是团队规模：对于主要的预训练任务，你只需要少数几个人，并为他们配备足够的算力。例如，如今要预训练一个像Llama 3这样的模型，可能只需要2到3个人。只有当你开始涉足更多元化的任务（如多模态、多语言、后训练等）时，才需要逐步增加人手。

因此，秘诀就是：从一个小型、装备精良的团队开始，每隔两到三个月就构建一个新模型，你将在短时间内攀升至行业顶端。

好了，接下来的文章将专注于这个团队的日常技术细节！

3. 每个大模型的诞生，都始于一场小小的“消融实验”

在开始训练一个大型语言模型（LLM）之前，我们需要做出无数决策，这些决策将直接影响模型的性能和训练效率。我们该选择什么样的架构？使用哪种优化器和学习率？如何混合不同的数据源？

人们常常好奇这些决策是如何做出的，有时会期望它们源于深刻的理论推演。虽然战略性思维至关重要——它能帮你识别哪些改动值得测试——但仅仅依靠推理是远远不够的。在LLM领域，直觉并不可靠，那些“理论上应该有效”的假设在实践中往往会落空。

举个例子，使用看起来“质量最高的数据”并不一定能产出更强的模型。以arXiv为例，它是人类科学知识的巨大宝库。直觉上，用如此丰富的STEM数据进行训练应该能产出更优秀的模型，对吗？但实际上，它并非总是如此，特别是对于小模型，甚至可能损害性能。原因是虽然arXiv论文知识丰富，但它们高度专业化，并以一种狭隘的学术风格撰写，这与模型最擅长学习的多样化、通用性文本截然不同。

那么，如果冥思苦想没有帮助，我们如何知道什么才是有效的呢？答案是：像优秀的经验主义者一样，运行大量的实验！ 机器学习更像是一门实验科学。由于这些实验将指导我们许多关键决策，因此正确地设置它们至关重要。我们希望从实验中获得两个主要属性：

速度（Speed）： 实验应该尽可能快地运行，以便我们能够频繁迭代。
可靠性（Reliability）： 实验应提供强大的判别力（discriminative power）。如果关注的指标无法在早期有意义地区分不同设置的优劣，那么实验提供的洞察就会很少。

但在设置消融实验之前，我们需要对架构类型和模型规模做出一些基础性的选择。这些决策会影响我们使用哪种训练框架、如何分配算力预算，以及从哪个基线开始。

对于SmolLM，我们选择了30亿参数的密集型（dense）Llama风格架构，因为我们的目标是小型设备端模型。但正如你将在后续章节中看到的，MoE或混合模型可能更适合你的用例。现在，让我们从最实际的第一步开始：选择你的基线（Baseline）。

3.1 选择你的基线（Baseline）

每一个成功的模型都建立在一个经过验证的基础之上，然后根据自身需求进行修改。

当Qwen训练他们的第一个模型家族时，他们以Llama的架构为起点。
当Meta训练Llama 3时，他们从Llama 2开始。
Kimi K2则始于DeepSeek-V3的MoE架构。

这种“继承”不仅适用于架构，也适用于训练超参数和优化器。

为什么呢？ 优秀的架构和训练设置是多年迭代和众多组织智慧的结晶。标准的Transformer结构和Adam等优化器，都是经过数千次实验才被完善的。人们已经发现了它们的失败模式，调试了不稳定性，并优化了实现。

从一个经过验证的基础开始，意味着你继承了所有这些积累的知识。 而从零开始，则意味着你需要自己重新发现每一个问题。

一个好的架构起点应该具备以下条件：

符合你的约束条件： 契合你的部署目标和实际用例。
经过大规模验证： 在相似或更大的规模上，跑过数万亿（multi-trillion）Token的训练。
文档完善： 有明确的、被证明有效的超参数配置。
框架支持良好： 理想情况下，它应该被你计划使用的训练框架和推理框架所支持。

下面列出了一份非详尽的清单，展示了2025年针对不同架构类型和模型规模的一些强大基线选项：

架构类型	模型家族	常见规模 (Sizes)
密集型（Dense）	Llama 3.1, Llama 3.2, Qwen3, Gemma3, SmolLM2, SmolLM3	0.6B - 70B
MoE (专家混合)	Qwen3 MoE, GPT-OSS, Kimi Moonlight, Kimi-k2, DeepSeek V3	16B - 1T
混合型（Hybrid）	Zamba2, Falcon-H1	0.5B - 34B
MoE + 混合型	Qwen3-Next, MiniMax-01	80B - 456B

请找到你的架构类型，并选择一个参数量接近你目标模型的基线。不必过度纠结，因为你最初选择的架构并非一成不变。

3.1.1 修改你的基线：“去风险化”的原则

现在你拥有了一个有效的基线模型。你大可以停在这里，用你的数据进行训练，很可能会得到一个不错的模型。然而，基线模型并非为你的特定需求而优化。因此，你很可能需要进行一些修改。但请注意，每一次架构上的更改都伴随着风险：它可能提升性能、彻底搞砸，或者毫无作用。

让你保持在正轨上的纪律是“去风险化”（Derisking）：除非你已经测试并确认它有帮助，否则绝不更改任何东西。

棘手之处在于，可修改的组件太多了：注意力机制、位置编码、激活函数、优化器、归一化方案等等。每一个都代表着一个潜在的实验，而这些组件往往以非线性的方式相互作用。你没有时间或算力来测试所有组合。

正确的做法是：从测试有前景的改动开始，并以当前基线为参照。 当某个改动有效时，就将其集成进来，创建一个新的基线，然后针对这个新基线测试下一个改动。

千万不要掉入陷阱： 避免对每一个超参数进行详尽的网格搜索（Grid Searches），也避免测试每一个新出现的架构变体。

现在你知道了如何通过战略规划来确定哪些改动是有前景的，接下来就该进入经验验证了。

3.2 挑选训练框架

我们需要做的第一个决策是：选择哪个框架来训练模型。这个选择需要平衡以下三个关键考量点：

架构兼容性： 框架必须支持我们的目标架构，或能让我们轻松地进行扩展。
稳定性和生产就绪： 框架需要稳定、成熟，不会在训练中途神秘地崩溃。
高吞吐量： 它应该能提供强大的吞吐量，以便我们快速迭代。

在实践中，这些要求可能相互掣肘。让我们来看看几个流行的选项：

框架	特性覆盖	实战检验	优化程度	核心/总代码行数	扩展性与调试难度
Megatron-LM	✅ 全面	✅ Kimi-K2, Nemotron	✅ 3D并行先驱	93k / 269k	⚠️ 难度大，不适合新手
DeepSpeed	✅ 全面	✅ BLOOM, GLM	✅ ZeRO & 3D并行先驱	94k / 194k	⚠️ 难度大，不适合新手
TorchTitan	⚡ 持续增长	⚠️ 较新	⚡ 针对密集模型优化	7k / 9k	⚡ 适中
Nanotron	🎯 为HF预训练定制	✅ StarCoder, SmolLM	✅ 高度优化	15k / 66k	⚡ 适中

Megatron-LM & DeepSpeed: 功能强大，久经沙场，但代码库庞大复杂，对新手不友好。
TorchTitan: PyTorch官方出品，轻量且易于上手，非常适合快速实验，但相对较新，稳定性可能略逊一筹。
Nanotron: Hugging Face自研框架，为大规模预训练深度优化，灵活性高，但某些功能（如MoE）仍在构建中。

对于我们而言，从头构建Nanotron是合理的，但这需要巨大的投入。一个强大的替代方案是分叉（fork）一个现有框架并根据需求进行增强。

最终，你的选择取决于团队的专业知识、目标功能，以及你愿意投入多少时间进行二次开发。 如果多个框架都能满足需求，请在你的硬件上比较它们的吞吐量。对于快速实验，更简洁的代码库通常会胜出。

3.3 消融实验设置

既然训练框架已定，我们现在就需要设计我们的消融实验。实验需要足够快以便快速迭代，但又需要足够大，以确保结果能外推（extrapolate）到最终模型。

3.3.1 搭建消融实验框架

主要有两种方法：

方法一（减少Token）： 保持目标模型大小不变，但在更少的Token上进行训练。例如，在SmolLM的消融实验中，我们用完整的3B参数模型，但在100B Token上训练，而不是最终的11T Token。
方法二（减小模型）： 如果目标模型太大，我们可以训练一个更小的代理模型。例如，Kimi在开发其1T参数的K2模型时，就使用了一个3B参数的MoE模型来运行部分消融实验。

一个关键问题是：这些小规模的发现真的能迁移吗？根据我们的经验，如果某个改动在小规模上损害了性能，你可以放心地将其排除。但如果某个改动在小规模上有效，你仍然需要确保在合理的Token数量上进行了训练，才能高概率地得出结论。训练时间越长，结果越可靠。

在本文中，我们将使用一个1B参数的Llama 3.2风格Transformer，在45B Token上进行所有消融实验。这在一个配备8块H100的节点上大约需要1.5天。

我们的基线配置以YAML格式记录了所有重要的训练细节，包括数据集、模型架构、优化器和并行化策略。在实验中，我们会根据测试内容修改不同的部分，同时保持其他一切不变。

3.3.2 理解效果：评估至关重要

我们如何判断哪些改动有效？第一直觉是看Loss曲线。它确实很重要，你希望看到它平滑下降。

然而，仅看Loss并不可靠。例如，用维基百科训练比用网页训练得到的Loss更低，但这不意味着模型更有能力。如果更改了分词器，Loss也无法直接比较。因此，我们需要更细致的下游评估（downstream evaluations）来测试知识、推理等能力。

对于消融实验，最好关注那些能提供良好早期信号并避免嘈杂基准的任务。我们主要关注多项选择格式 (MCF) 或完形填空表述 (CF)。研究表明，CF更适合获取早期信号。

我们的消融评估套件包括MMLU、ARC、HellaSwag等一系列基准，覆盖了世界知识、推理和常识。

3.3.2.1 消融实验使用什么数据混合配比？

对于架构消融实验，我们使用固定的高质量数据集混合（英语、数学、代码）。对于数据消融实验，我们固定架构，并系统地改变数据混合配比。

3.3.3 估算消融实验成本

消融实验需要GPU时间，理解其成本至关重要。下表显示了SmolLM预训练的算力分解：

阶段	GPU 数量	天数	GPU-小时
主预训练运行	384	30	276,480
消融实验（预训练前）	192	15	69,120
消融实验（训练中）	192	10	46,080
训练重启与调试	384/192	3/4	46,080
总成本	-	-	437,760

这些数字揭示了一个重要事实：消融实验和调试总共消耗了超过主训练运行一半的成本。 这突出表明了为什么消融实验的成本必须计入你的算力预算。

3.4 实验守则

验证你的评估套件。 在训练任何模型之前，确保你的评估套件能够复现已知模型的结果。

测试每一个更改，无论多小。 一个看似无害的库升级或代码修改都可能引入微妙的Bug。

一次只改变一件事。 首先评估每个变化的单独贡献，然后再尝试将它们结合起来。

训练足够的Token，并使用充分的评估。 在这里“偷工减料”将导致嘈杂的结果和错误的决策。

遵守这些规则可能感觉过于谨慎，但它能让你避免花费数天时间调试神秘的性能下降。黄金原则：一旦你拥有一个良好的设置，任何更改都应该经过测试！

4. 设计模型架构

既然我们已经有了实验框架，是时候做出定义我们模型的重大决策了。从模型大小到注意力机制再到分词器，每一个选择都会直接影响模型的训练和最终使用。

请记住“训练指南针”：在做出任何技术选择之前，我们都需要对“为什么”（Why）和“做什么”（What）有清晰的认识。我们的目标是构建一个英语SOTA模型吗？长上下文是我们的首要任务吗？还是我们试图验证一种新的架构？

对于SmolLM3，我们的目标是构建一个强大的端侧应用模型，同时具备有竞争力的多语言性能、可靠的数学和编码能力，以及强大的长上下文处理能力。 这引导我们选择了一个30亿参数的密集型模型：它足够大以提供强大的能力，但又足够小以舒适地安装在手机上。

我们从SmolLM2获得了一个小规模（1.7B）的英语训练“配方”，但扩大规模意味着重新验证一切，并解决多语言和扩展上下文长度等新挑战。例如，在SmolLM2中，我们在预训练结束时才努力扩展上下文长度，因此对于SmolLM3，我们从一开始就做出了架构选择——比如使用NoPE和文档内掩码——以最大化成功的几率。

一旦目标明确，我们就可以开始做出技术决策。在本章中，我们将系统地探讨这些核心决策：架构、数据和超参数。

4.1 架构选择

如果你观察最近的模型，比如Qwen3、Gemma3或DeepSeek v3，你会发现尽管它们存在差异，但都共享着同一个基础——2017年引入的Transformer架构。多年来发生变化的不是基本结构，而是对其核心组件的精炼和改进。无论你是构建密集型模型（Dense Model）、专家混合模型（Mixture of Experts, MoE）还是混合架构（Hybrid Architecture），你都在使用这些相同的构建块。

这些改进源于各大团队对更优性能的追求，以及对特定挑战的攻克：推理时的内存限制、大规模训练时的不稳定性，或处理更长上下文的需求。一些修改，比如从多头注意力（MHA）转向计算效率更高的分组查询注意力（GQA），现已被广泛采纳。而其他修改，比如不同的位置编码方案，仍在争论之中。

那么，现代LLM今天实际在使用什么呢？下表展示了部分前沿模型的架构细节：

模型	架构	参数量	训练 Token	注意力机制	上下文长度	位置编码	精度	初始化 (Std)	优化器	最大学习率	学习率调度	Warmup 步数	Batch Size
DeepSeek LLM 7B	Dense	7B	2T	GQA	4K	RoPE	BF16	0.006	AdamW	$4.2 \times 10^{-4}$	Multi-Step	2K	9.4M
DeepSeek V2	MoE	236B (21B)	8.1T	MLA	128K	Partial RoPE	-	0.006	AdamW	$2.4 \times 10^{-4}$	Multi-Step	2K	9.4M -> 37.7M
Kimi K2	MoE	1T (32B)	15.5T	MLA	128K	Partial RoPE	BF16	可能是 0.006	MuonClip	$2 \times 10^{-4}$	WSD	500	67M
OLMo 2 7B	Dense	7B	5T	MHA	4K	RoPE	BF16	0.02	AdamW	$3 \times 10^{-4}$	Cosine	2K	4.2M
SmolLM3	Dense	3B	11T	GQA	128K	NoPE	BF16	0.02	AdamW	$2 \times 10^{-4}$	WSD	2K	2.3M

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

我们将首先关注最简单的密集型模型，然后深入探讨MoE和混合模型，最后探索分词器（Tokenizer）。

4.1.1 注意力机制（Attention）

注意力机制在推理时是主要的瓶颈，尤其是在长上下文场景中。它的计算成本高，并且KV缓存（KV cache）会迅速消耗GPU内存。

4.1.1.1 我的注意力需要多少个头？

多头注意力（Multi-Head Attention, MHA）是标准机制。在推理时，我们可以重用过去Token的KV值，存储这些值的内存被称为KV-Cache。随着上下文窗口的增长，这个缓存会迅速成为瓶颈。例如，对于Llama3 70B模型，在8192的序列长度下，KV缓存大约需要20GB内存。

一个自然的问题是：我们真的需要为每个头都计算新的KV值吗？

多查询注意力（Multi-Query Attention, MQA）在所有头之间共享KV值，极大地减小了KV缓存的大小。
分组查询注意力（Grouped Query Attention, GQA）则是一个折中方案，在分组的头之间共享KV值，在效率和性能之间取得了平衡。
最近，多潜变量注意力（Multi-Latent Attention, MLA）被提出，它不减少KV值的数量，而是减少它们的维度，通过存储一个可在运行时解压的潜变量来压缩缓存。

下表比较了这些注意力机制的KV缓存大小：

注意力机制	每个Token的KV-Cache参数量
MHA	$2 \times n_{heads} \times n_{layers} \times dim_{head}$
MQA	$2 \times 1 \times n_{layers} \times dim_{head}$
GQA	$2 \times g \times n_{layers} \times dim_{head}$ (g为组数)
MLA	$4.5 \times n_{layers} \times dim_{head}$

4.1.1.2 消融实验 - GQA胜过MHA

我们比较了MHA、MQA和不同分组比率的GQA。为了保持参数量大致相同，我们调整了部分配置的层数。

实验结果显示，MQA和高分组比率的GQA性能显著低于MHA。而分组比率较低的GQA（如2、4、8）性能与MHA大致持平。这个结论在Loss曲线和下游评估中都保持一致。

基于这些实验，GQA是MHA的一个可靠替代品。它在保持性能的同时，在推理时更加高效。对于SmolLM3，我们最终使用了分组比率为4的GQA。

4.1.1.3 文档掩码（Document Masking）

在预训练期间，我们通常将多个可变长度的文档打包（Packing）成固定长度的序列。在标准的因果掩码（Causal Masking）下，一个Token可以关注打包序列中的所有先前Token，即使它们来自不相关的文档。这意味着绝大多数Token将浪费算力去关注不相关的内容，并可能引入噪音，降低性能。

文档内掩码（intra-document masking）解决了这个问题：我们修改注意力掩码，使得Token只能关注同一文档内的先前Token。Llama 3等模型也使用了这种技术，发现在长上下文扩展时益处显著。

我们的消融实验显示，与标准因果掩码相比，文档内掩码在短上下文任务上的Loss和评估得分几乎完全相同。然而，考虑到它在扩展到长序列时能加快训练速度，我们在SmolLM3的整个训练过程中都采用了它。

LLM有两个嵌入组件：输入嵌入和输出嵌入。在小型模型中，这两部分可以占据总参数量的很大一部分。嵌入层共享（在输出层重用输入嵌入）成为一种自然的优化。

4.1.2.1 消融实验 - 绑定嵌入可媲美更大参数量的非绑定变体

我们比较了三种模型：

基线模型 (1.2B): 绑定嵌入（16层）。
非绑定-减少层数 (1.2B): 非绑定嵌入，但层数更少（12层）以保持参数预算。
非绑定-相同层数 (1.46B): 非绑定嵌入，层数与基线相同（16层）。

结果表明，我们的1.2B绑定嵌入基线模型，在参数少18%的情况下，实现了与1.46B非绑定模型相当的性能。而参数量相同但层数更少的1.2B非绑定模型性能最差。这表明，在参数预算相等的情况下，增加模型深度比解绑嵌入层更有益。

基于这些结果，我们为SmolLM3 3B模型保留了绑定嵌入。

4.1.3 位置编码与长上下文

Transformer天生对词序不敏感，需要位置嵌入（Positional Embeddings）来赋予序列中每个Token一个独特的“地址”。随着上下文窗口从几百扩展到百万级，位置编码的选择变得至关重要。

4.1.3.1 RoPE：将位置编码为旋转

主导近期大模型的技术是旋转位置嵌入（Rotary Position Embedding, RoPE）。其核心思想是将位置信息编码为高维空间中的旋转角度。通过依赖于其绝对位置的角度来旋转查询（Query）和键（Key）向量，使得注意力模式仅取决于Token间的相对距离，从而学习到基于距离的模式，并可以外推到更长的序列。

4.1.3.2 如何处理长上下文？

典型的做法是用较短的序列完成大部分预训练，然后在最后阶段使用更长的序列。然而，随着序列长度增长，RoPE的旋转角度可能导致远处Token的注意力得分衰减过快。解决方案是增加基础频率，使用诸如ABF和YaRN之类的方法来减缓衰减。

4.1.3.3 混合位置编码方法

最近的研究挑战了显式位置编码的必要性。

NoPE (No Position Embedding): 在没有任何显式位置编码的情况下训练Transformer，允许模型通过因果掩码隐式学习位置信息。它表现出更好的长度泛化能力，但可能在短上下文任务上表现较弱。
RNoPE (混合方法): 结合RoPE和NoPE，在模型中交替使用RoPE层和NoPE层，试图兼得两者之长。Llama 4、Command A和SmolLM3都采用了这种技术。

4.1.3.4 消融实验 - NoPE在短上下文上与RoPE匹配

我们比较了纯RoPE基线、一个每隔4层移除位置编码的NoPE变体，以及结合NoPE和文档掩码的配置。结果显示，所有三种配置的性能相似。这表明NoPE在保持强大的短上下文能力的同时，为更好的长上下文处理提供了基础。因此，我们为SmolLM3采用了NoPE + 文档掩码的组合。

4.1.3.5 限制注意力范围

另一种互补的策略是限制哪些Token相互关注，以降低计算成本和内存需求。

分块注意力（Chunked Attention）: 将序列分成块，Token只能在自己的块内关注。
滑动窗口注意力（Sliding Window Attention, SWA）: 每个Token只关注最近的N个Token。
双块注意力（Dual Chunk Attention, DCA）: 一种免训练的方法，结合了块内、块间和连续块注意力，以保持跨块的信息流。

4.1.3.6 注意力汇聚（Attention Sinks）

研究发现，模型会为序列中的起始Token分配异常高的注意力分数，这些Token充当了注意力的“汇聚点”。利用这一现象，仅保留起始几个Token和最近Token的滑动窗口的KV缓存，就可以在很大程度上恢复长上下文性能。这可以通过添加特殊Token或学习到的偏差来实现。

4.1.4 提高稳定性

大规模训练中，不稳定性（如Loss尖峰）是一个巨大挑战。一些架构技术可以提供帮助：

Z-loss: 一种正则化技术，通过惩罚过大的Logits来提高数值稳定性。
从嵌入层中移除权重衰减: OLMo的研究发现，这样做可以提高训练稳定性，因为它可以防止早期层中的梯度变得过大。
QK-norm: 在计算注意力之前对查询和键向量进行层归一化，有助于防止注意力Logits过大。但有研究发现它可能损害长上下文任务。

在我们的实验中，Z-loss和移除嵌入层权重衰减对性能没有负面影响，因此我们在SmolLM3中采用了后者。由于可能损害长上下文性能，我们没有使用QK-norm。

4.1.6 走向稀疏：专家混合模型（MoE）

MoE的核心思想是：增加总参数量，同时不增加每个Token的“活跃”参数量。它将MLP层替换为多个“专家”，并由一个可学习的“路由器”为每个Token选择少数专家进行计算。这使得模型可以在拥有巨大容量的同时，保持较低的训练和推理成本。

设计MoE涉及几个核心问题：

稀疏度/激活比率: 最近的趋势是MoE模型正变得越来越稀疏（即总专家数远大于激活专家数），但这存在一个收益递减点。
粒度: 指的是每个专家应该有多大。最近的模型倾向于更高的粒度（即更多、更小的专家）。
共享专家: 让每个Token都通过一组始终激活的“共享专家”，可以帮助它们吸收通用模式，让其他专家更专注于特定领域。通常一个共享专家就足够了。
负载均衡: 这是MoE的关键。如果路由器总把Token发给少数几个专家，会造成资源浪费和性能下降。通过辅助损失函数来鼓励路由器均匀分配Token是标准做法。

4.1.7 混合模型（Hybrid Models）

最近的另一个趋势是使用状态空间模型（SSM）或线性注意力来增强标准Transformer，以解决其在处理极长上下文时效率低下的问题。这些混合模型试图兼具循环模型（RNN）的线性扩展能力和Transformer的强大上下文利用能力。

它们通过重新排序计算，将注意力的复杂度从$O(N^2)$降低到$O(N)$，从而在长序列上实现显著的效率优势。Mamba、RetNet等都属于这一范畴。虽然它们显示出巨大潜力，但当扩展到大规模时，仍需考虑许多细微差别，其成熟度也不及密集型和MoE模型。

4.1.8 要不要MoE：如何选择基础架构？

你的选择取决于部署环境、团队专业知识和项目时间线。

部署场景决定内存约束：
- 端侧/低显存: 内存是瓶颈，基本排除MoE。首选密集型。
- 云端/算力充裕: 内存不是瓶颈，优先考虑MoE（最佳性能/计算比）或混合型（极致长上下文）。
团队经验和时间线决定技术风险：
- 时间紧迫/经验相对较少: 选择密集型，这是最稳健的路径。
- 有时间探索/有资深工程师: 可以在MoE或混合型上进行探索。

以SmolLM3为例： 我们的目标是端侧部署，时间线约为3个月，且过去主要训练密集型模型。因此，我们选择了Llama风格的密集型模型。

4.1.9 分词器（Tokenizer）：被低估的“语言翻译官”

分词器是将原始文本转换为模型可处理的数字序列的桥梁，其质量至关重要。设计分词器需要回答几个根本问题：支持哪些语言？哪些领域很重要？目标数据混合配比是什么？

词汇表大小: 更大的词汇表能更有效地压缩文本，但会增加嵌入矩阵的大小。对于多语言模型，通常需要100k以上的词汇表。Llama 3等现代模型已采用128k+。
分词算法: BPE (Byte-Pair Encoding)仍然是最流行的选择。

衡量分词器质量

我们使用两个关键指标：

Token消耗比（Fertility）: 编码一个词平均所需的Token数量。越低越好。
连续词比例: 有多少百分比的词语被分割成多个片段。越低越好。

我们对流行的分词器进行了评估，发现Gemma 3在多种语言上表现优异，这得益于其庞大的262k词汇表。Qwen 3在中文上表现出色。Llama 3则在多语言和代码上提供了良好的平均质量。

对于SmolLM3，我们选择了Llama 3的分词器，因为它在我们的目标语言上提供了最佳的权衡，同时词汇表大小适中。

4.1.10 SmolLM3的最终架构选择

我们以SmolLM2的1.7B架构为基础，系统性地进行了一系列消融实验，最终确定了SmolLM3的架构：

分词器: Llama 3.2的分词器 (128k)。
注意力: GQA，分组比率为4。
位置编码: NoPE（每隔4层移除RoPE）+ 文档内掩码。
模型布局: 采用了更深的Qwen 2.5-3B布局。
稳定性: 保留了绑定嵌入，并移除了嵌入层的权重衰减。

这种系统性的方法让我们能够自信地将所有这些修改结合起来。

5. 数据策划的艺术

如果说模型架构定义了模型如何学习，那么数据就定义了它学什么。再好的架构也无法从糟糕的数据中拯救一个模型。搞定训练数据不仅关乎拥有好的数据集，更关乎组建正确的混合配比（Mixture）。

5.1 数据混合的非直观性

找到好的数据混合配比并非易事。不同领域的数据可能会相互竞争。增加代码数据的权重可能会损害模型的自然语言能力。此外，我们希望在利用高质量数据的同时，避免过度重复，因为这可能是有害的。

为了平衡这一切，我们需要仔细设计混合配比，并在训练过程中动态调整，即多阶段训练（Multi-Stage Training）或课程学习（Curriculum）。其核心思想是：在训练早期增加更多样化的数据来源，在接近尾声时混入更小、更高质量的来源，因为模型的最终行为受到训练末期看到的数据的强烈影响。

5.2 SmolLM3的数据策划过程

对于SmolLM3，我们希望模型能处理英语和多种其他语言，并在数学和代码方面表现出色。

英语网络数据: 我们混合了FineWeb-Edu和DCLM这两个高质量数据集，比例为50/50，构成了数据的基础层。
多语言网络数据: 我们从FineWeb2-HQ中选择了5种目标语言，并加入了其他10种语言。消融实验发现，网络混合中12%的多语言内容达到了最佳平衡，在不降低英语性能的情况下提高了多语言能力。
代码数据: 我们从The Stack v2和StarCoder2语料库中提取数据。实验表明，10%的代码比例是一个很好的权衡点。
数学数据: 早期我们使用了FineMath3+等通用数据集，后期则上采样了FineMath4+并引入了MegaMath等更高质量的数据集。

我们通过从头开始的消融实验来确定第一阶段的混合配比，并通过退火实验（从主运行的中间检查点开始，用修改后的数据继续训练）来测试新阶段的数据集。

6. 训练马拉松

万事俱备，真正的乐趣即将开始。对于SmolLM3，我们在384块H100 GPU上训练了近一个月，处理了11万亿Token。本节将带你了解在一次漫长的训练运行中实际会发生什么。

6.1 起飞前检查清单

在按下“训练”按钮前，我们会过一遍检查清单：

基础设施: 确保Slurm预留、GPU压力测试、存储管理都已就绪。
评估: 评估流程完全自动化，并能正确记录结果。
检查点与恢复: 验证检查点能正确保存，并且作业可以自动恢复。
指标记录: 确认所有关心的指标（吞吐量、Loss、硬件健康状况等）都在记录中。
配置检查: 仔细检查所有配置文件和启动脚本。

6.2 规模化带来的“惊喜”

在为SmolLM3运行了广泛的消融实验后，我们满怀信心地开始了全面规模的运行。然而，现实很快就给我们抛来了曲线球。

谜团 #1 – 消失的吞吐量

启动后几小时内，吞吐量骤降。经过排查，我们发现问题出在数据存储上。我们最初使用的FSx存储在我们庞大的数据集压力下开始驱逐数据分片，导致训练停顿。修复方法是：将数据存储在每个节点的本地存储/scratch中，并预留一个带有预加载数据的备用节点，以实现节点故障时的零延迟恢复。

谜团 #2 – 持续的吞吐量下降

即使更换了存储，个别的吞吐量下降仍在发生。我们最终发现，问题出在软件瓶颈上，具体来说是nanotron的内置数据加载器（nanosets）。它在处理非常大的步数时，会构建一个巨大的索引，导致共享内存增加，从而引发吞吐量下降。修复方法是：将SmolLM2中使用的、经过验证的TokenizedBytes数据加载器复制到nanotron中。

谜团 #3 – 嘈杂的Loss

换上新的数据加载器后，吞吐量稳定了，但Loss曲线变得更嘈杂。我们发现这是因为新的数据加载器存在一个洗牌Bug：它只洗牌了文档，但一个批次内的序列是按顺序读取的。这导致一个长的、低质量的文件可能会填满整个批次，引发Loss尖峰。修复方法是：离线预洗牌分词后的序列。

谜团 #4 – 不尽如人意的性能

在解决了上述所有问题并重新启动后，训练平稳进行。然而，在大约1万亿Token时，我们发现尽管拥有更多参数和更好的数据，3B模型的表现竟然比1.7B的SmolLM2更差。由于所有其他组件都经过了验证，我们最终将矛头指向了唯一未经充分测试的差异：张量并行（Tensor Parallelism, TP）。

最终的修复： 经过排查，我们发现了一个微妙但致命的Bug：我们在所有TP等级（Ranks）上使用了相同的随机种子，而每个等级应该使用不同的种子。这导致了权重初始化相关，从而影响了收敛。修复这个Bug后，性能终于与预期一致。

这次调试过程强化了一个核心原则：一个坚实的消融实验设置的真正价值，不仅在于构建一个好模型，更在于当问题发生时，它能让你快速定位问题根源。

6.3 坚持到底

训练监控: 不要只看Loss曲线。下游评估结果和与历史运行的比较至关重要。同时，持续监控吞吐量和硬件健康状况。
处理Loss尖峰: 尖峰分为可恢复和不可恢复两种。常见的罪魁祸首包括高学习率、坏数据、糟糕的初始化或精度问题。修复方法包括跳过有问题的批次、临时收紧梯度裁剪等。

6.4 中途训练

现代LLM预训练通常涉及多个阶段。SmolLM3也遵循了类似的理念，有计划好的干预以引入更高质量的数据和扩展上下文。

第一阶段 (8T Token, 4k上下文): 基础训练，使用核心预训练混合数据。
第二阶段 (2T Token, 4k上下文): 注入更高质量的过滤数据集，如Stack-Edu和FineMath4+。
第三阶段 (1.1T Token, 4k上下文): 在学习率衰减阶段，进一步上采样高质量数据，并引入指令和推理数据。

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

我们没有直接跳到128k，而是分阶段逐渐扩展上下文：4k → 32k → 64k。在每个阶段，我们都重新开始一个短期的学习率调度，并运行消融实验来寻找最佳的长上下文数据混合和RoPE theta值。最终，我们使用YARN技术，让在64k上下文上训练的模型能够在推理时外推到128k。

7. 超越基础模型 — 2025年的后训练

预训练赋予了SmolLM3原始的能力，但要成为一个人们能实际使用的模型，我们还需要进行后训练（Post-Training）。这包括监督式微调（SFT）、强化学习（RL）、模型合并等等。

如果说预训练是将知识强行灌输到权重中，那么后训练就是将这种原始能力雕琢成某种可靠且可控的东西。

7.1 后训练指南针

就像预训练一样，后训练也需要一个清晰的指南针：

为什么？ 明确你的目标：是进行研究，是满足特定的生产需求，还是填补开源空白？
做什么？ 确定你的优先事项：是追求指令遵循，还是多功能助手，还是推理引擎？
怎么做？ 这就是“配方”发挥作用的地方，包括SFT、偏好优化（PO）、RL、数据策划和评估。

对于SmolLM3，我们的目标是训练一个混合推理模型，其推理能力在非英语语言中也保持良好，并支持工具调用和长上下文。

7.2 首要任务：评估先于一切

后训练的第一步是决定正确的评估集。一个好的助手应该能够处理模糊指令、进行分步规划、编写代码和调用工具。这依赖于推理、长上下文处理、数学、代码和工具使用的混合技能。

我们使用一个分层的评估套件，包括：

能力评估: 针对基本技能，如使用GPQA Diamond进行知识评估，使用AIME进行数学评估，使用LiveCodeBench进行代码评估。
综合任务评估: 测试接近真实场景的能力，如使用RULER和HELMET进行长上下文评估，使用IFEval进行指令遵循评估，使用AlpacaEval和ArenaHard进行对齐评估，使用TAU-Bench进行工具调用评估。
防止过拟合评估: 使用如GSMPlus这样对现有基准进行扰动的评估。
内部评估和“感觉”评估: 实现针对特定能力的内部评估，并让专家与模型互动，以发现评估分数无法捕捉到的微妙问题。

至此，我们已经走过了从预训练到后训练规划的完整旅程。每一个环节都充满了挑战与权衡，但通过系统性的方法和严格的实验，我们最终将原始的算力转化为了一个强大而可靠的AI模型。