HuggingFace发布实战指南，从决策到落地手把手教你训练大模型

机器之心报道

机器之心编辑部

近期，HuggingFace 发布的超过 200 页的超长技术博客，系统性地分享训练先进 LLM 的端到端经验。

博客的重点是 LLM 开发过程中「混乱的现实」。它坦诚地记录了哪些方法有效、哪些会失败，以及如何应对实际工程中遇到的陷阱。内容基于团队的实际项目经验，特别是他们近期使用 384 块 H100 GPU 训练 3B 参数模型 SmolLM3 的过程。

博客中提供了深入的技术细节、代码片段和调试技巧，对于有兴趣亲自构建 LLM 的读者来说非常有指导意义。

• 博客地址：https://huggingface.co/spaces/HuggingFaceTB/smol-training-playbook#positional-encodings--long-context

训练罗盘：Why→What→How

这一部分是在投入技术细节（如何训练）之前，提出了一个关键问题：「你是否真的需要训练这个模型」？

鉴于（如 Qwen、Gemma、Llama 等）世界级开源模型层出不穷，大多数人可能并不需要从头开始训练自己的模型。

Why

文章列举了一些不应该训练模型的错误理由，例如：「我们有闲置算力」、「别人都在做」或「AI 是未来」。

然后提供了一个流程图，帮助你思考是否真的训练一个自己的模型。

当你发现：现有模型不可用 —> 提示词工程无法解决 —> 微调无法解决，你就可以考虑从头开始训练了。

定制化预训练通常适用于三个主要领域：

• 研究：你有一个明确的科学问题需要回答。例如，测试新的优化器、探索模型能力（如仅用强化学习）或测试新的数据集（如纯合成数据）。
• 生产：你的业务有无法被满足的特定需求。如 DNA、法律、金融等高度专业化的词汇或逻辑； 需要在特定硬件（如无人机、本地 FPGA）上运行，或有严格的延迟要求；处于受监管行业，需要对训练数据和模型行为有 100% 的控制和可追溯性。
• 战略开源：你发现并有能力填补当前开源生态系统中的一个特定空白。

What

一旦你明确了「Why」，就可以推导出「训练什么 (What)」。包括模型类型（密集型、MoE、混合型、某种新型）、模型大小、架构细节和数据混合。

同时前面的领域目标决定了你的训练决策：例如，为设备端运行 —> 训练小型高效模型；需要多语言能力 —> 使用更大的 tokenizer 词汇表；超长上下文 —> 混合架构。

这个决策过程分为两个阶段。将你的约束（来自「Why」）映射到具体的模型规格；验证：通过系统性的实验（消融实验）来测试你的选择。

文章指出了成功 LLM 训练团队的两个关键特质：

• 迭代速度：训练 LLM 是一个「边训练边学」的过程。能够快速、频繁地（例如每季度而不是每年）迭代训练新模型的团队，会进步得更快。
• 数据管理：最优秀的团队是那些「痴迷于高质量数据」的团队，数据质量的影响远超架构选择。

文章还建议，预训练团队一开始不需要很多人（2-3 人足矣），关键是配备足够的算力并保持快速迭代。

每一个大型模型都始于一个小型消融

在开始训练 LLM 之前，需要做出一系列关键决策（架构、优化器、数据组合等）。人们常以为这些决策是靠深思熟虑得出的，但仅凭推理是不够的，因为 LLM 的行为常常反直觉。

一个典型的例子是：使用看似「最高质量」的 arXiv 科学论文数据，反而可能会损害模型（尤其是小模型）的性能，因为它过于专业化，缺乏通用文本的多样性。

既然纯粹的思考行不通，答案就是像经验主义者一样「运行大量实验」（即消融实验）。

设置消融实验的完整流程：

选择你的基线

不要从零开始，应该选择一个已被验证的、成熟的架构（如 Llama 3.1、Qwen3、Gemma3）作为起点，这样可以继承所有已知的优化和稳定性经验。

基线虽好，但并非为你量身定制，因此需要修改。然而，「任何架构上的改变都伴随着风险」。为此，必须遵守「去风险」的纪律，即：「除非你测试过它确实有帮助，否则不要改变任何东西。」

修改的难点在于组件太多且相互作用。你不能测试所有组合。正确的方法是：一次只测试一个有潜力的变更。如果它有效，就将其整合，使其成为新的基线，然后再测试下一个变更。

选择训练框架

这是一个关键的技术决策，需要在功能、稳定性和吞吐量之间权衡。

文章对比了几个主流框架：

• Megatron-LM / DeepSpeed：功能强大，经过实战考验，但代码库庞大且复杂。
• TorchTitan：更轻量级，易于上手和实验，但相对较新。
• nanotron (作者自研)：提供了完全的灵活性，但需要大量投入来开发和测试。

设计消融实验

实验必须足够快（以便快速迭代）和足够可靠（结果能外推到最终模型），有两种主要方法：

• 全尺寸模型，少量数据： 使用最终模型的尺寸（如 SmolLM3 使用 3B 模型），但在更少的 Token 上训练（如 100B 而非 11T）。
• 小型代理模型： 如果目标模型太大（如 1T 参数），则使用一个按比例缩小的代理模型（如 3B 模型）进行实验。

接下来文章介绍了其基准消融设置（1B 的 Llama 模型，训练 45B Token），并展示了配置文件的关键部分（数据、模型、优化器等）。

理解哪些有效：评估

文章指出，评估实验结果时，只看训练损失 (Loss) 是不可靠的。例如，训练维基百科的 Loss 更低，但不代表模型能力更强；更换分词器也会导致 Loss 无法直接比较。因此，必须使用更细粒度的下游评估。

一个可靠的评估任务应具备四个标准：单调性、低噪声、超随机性能和排名一致性。

特别是在早期实验中，「完形填空（CF）」格式比「多项选择（MCF）」更优越，因为后者（如 MMLU）在模型训练的早期阶段表现接近随机，无法提供有效的早期信号。

消融实验的真正价值不仅在于构建好模型，更在于它为未来的调试提供了信心：当主训练不可避免地出错时，系统性的实验结果能帮助团队快速定位问题。

不过，这种价值的成本极其昂贵。以 SmolLM3 为例，消融和调试所消耗的 GPU 时间超过了主训练运行的一半。

模型架构设计

这部分内容详细阐述了设计和确定 LLM 架构的完整决策过程，从高层目标到具体的组件选择和超参数设置。

文章以一个名为 SmolLM3 的 3B（30亿参数）模型为例，系统性地展示了如何从零开始构建一个模型的「蓝图」。

文章深入探讨了构成现代 Transformer 的核心架构选择并指出，当今的模型（如 Qwen3、Gemma3）共享 Transformer 基础，但通过组件改进（如 GQA、位置编码）来解决具体问题（如内存、稳定性）。

• 注意力机制：这是推理时的主要瓶颈，关键在于 KV 缓存。文章对比了 MHA（标准，高内存）、MQA（极端压缩，可能损失性能）和 GQA（分组查询）。消融实验证实，GQA 在性能上与 MHA 相当，但极大节省了 KV 缓存，是 SmolLM3 的最终选择。
• 长上下文：文章探讨了两种策略。首先是文档掩码，在训练「打包」的数据时，它能防止模型关注到序列中不相关的其他文档，这被证实对长上下文扩展至关重要。其次是位置编码，标准 RoPE 在长序列上外推能力有限。SmolLM3 采用了 NoPE（实为 RNoPE）的混合策略，即交替使用 RoPE 层（处理短上下文）和 NoPE 层（处理长距离检索），消融实验表明这种方法在不牺牲短上下文性能的同时，为长上下文打下了基础。
• 嵌入共享：对于 SmolLM3 这样的小模型，嵌入层占比较大。文章通过消融实验证明，将参数用于增加模型深度（更多层）比用于「解绑」输入和输出嵌入层更有效。因此，SmolLM3 采用了嵌入共享。
• 稳定性：为防止大规模训练崩溃，文章测试了 Z-loss、QK-norm 等技术。最终，SmolLM3 采用了 OLMo2 的技巧，即移除嵌入层的权重衰减，以提高稳定性。

文章对比了密集型、MoE（混合专家）和 Hybrid（混合模型）三种架构。MoE 通过稀疏激活（只激活部分「专家」）来用更少的计算换取更大的容量，但内存占用极高。Hybrid（如 Mamba）则通过线性注意力或 SSM 来解决 Transformer 在长上下文上的计算瓶颈。SmolLM3 因其「端侧部署」的目标（内存受限）而坚持使用密集型架构。

随后，文章转向了常被低估的Tokenizer。选择分词器涉及词汇量大小（影响压缩率和嵌入矩阵大小）和算法（BPE 最常用）。

文章引入了「Fertility」（每词平均 Token 数）和「连续词比例」作为评估指标。通过对比 Llama3、Gemma3、Qwen3 等，SmolLM3 最终选择了 Llama3 的 128k 词汇表，因为它在目标语言和模型大小之间取得了最佳平衡。

接下来，文章探讨了决定训练过程的核心要素：优化器、学习率和批量大小。文章指出，直接借用其他模型的超参数虽然简单，但可能不是最优的，因为这些值是针对特定的架构、数据和约束条件优化的。

最后回顾了关于模型规模（参数量 N）和数据量（Token 数 D）的经典权衡。

数据管理艺术

这部分内容详细阐述了「数据策展的艺术」，强调了在 LLM 训练中，数据是决定模型「学到什么」的关键因素，其重要性甚至超过了模型架构。

模型架构决定了模型如何学习，而数据则决定了模型学习的内容。如果数据质量差或「混合比例」不当，再好的架构或超参数也无法挽救。

文章指出，构建一个优秀的数据集并不仅仅是收集好数据，而是要设计一个训练混合

例如，过分增加代码数据的比例（「上采样」）会隐式地减少其他数据的比例，可能损害模型的通用能力。

此外，对于像 SmolLM3 这样需要 11T Token 的超长训练，如果只使用「最高质量」的数据，将导致严重的数据重复，这对模型性能有害。

为了解决这些平衡性问题，现代 LLM 训练已经从「静态混合」（如 GPT-3）演变为多阶段训练（如 Llama3、SmolLM2）。这种方法在训练过程中动态地改变数据混合比例。

其核心洞察是，模型的最终行为深受其在训练末期看到的数据的影响。因此，策略是：

• 在训练早期，使用丰富、多样化但质量稍低的数据（如网页文本）。
• 在训练末期（特别是在学习率衰减的「退火阶段」），引入稀缺、高质量的数据（如专业数学和代码数据集），以最大化其影响力。

何时改变混合比例通常由性能驱动的干预决定：例如，当发现模型的数学能力停滞不前时，就是引入更多高质量数学数据的信号。

确定数据配方的过程依赖于系统的消融实验。与架构不同，数据混合的消融实验必须在目标模型规模（例如 3B）上运行，因为模型的容量会显著影响它吸收不同数据的效果。

文章介绍了两种主要的实验方法：

• 从零开始的消融：使用目标模型（如 3B）进行短期训练（如 100B Token），以测试不同的初始混合比例。
• 退火实验：这是测试多阶段课程的关键。团队会从主训练中（例如在 7T Token 处）获取一个检查点，然后用新的数据混合（例如 40% 基线 + 60% 新数学数据）继续训练一小段时间（如 50B Token），以验证新数据在后期引入的有效性。

作者提到，尽管存在 DoReMi 等自动优化方法，但在他们的实践中，仔细的手动消融实验仍然是 SOTA 模型（包括 SmolLM3）确定数据混合的最佳途径。

文章最后以 SmolLM3 为例，展示了如何应用这些原则。

堪比「马拉松」的长周期训练

从前面来看，此时已经准备好了大部分的工作，经过验证的模型架构、最终确定的数据混合方案、调好的超参数，剩下的任务就是搭建好基础设施（这在最后讲解），然后「开始」训练。而训练是一个堪比「马拉松」的长周期过程，过程中可能会出现各种情况，所以要做好面对各种挑战的准备。

而这部分主要讲的就是，训练前的「飞行前检查」、过程中那些不可避免的意外状况，以及如何保持系统稳定、不中断。

文章以启动 SmolLM3 前执行的「起飞前检查」清单为例，展示了在开始训练前的准备工作，包括基础设施准备、评测系统准备、Checkpoint 与自动恢复机制、指标日志记录、训练配置复核等。

尤其是在最后按下「训练」按钮之前的训练配置复核，一定要仔细检查训练配置文件、启动脚本、Slurm 提交命令等，以确保参数、路径、环境变量都正确无误。

当然，即使做好了万全准备，在规模化训练过程中，也依然会遇到一些问题。比如在训练启动后的短短数小时内系统的吞吐率（throughput）骤然下滑、持续下滑，以及在引入新的 dataloader（数据加载器） 后，虽然吞吐率下降的问题不再出现，但损失曲线（loss curve）却明显变得更加噪声化，波动比以前大得多等等，各种问题随时都会出现，所以要做好及时应对各种问题的准备。

另外，文章还指出，在现代 LLM 的预训练中，通常会采用多阶段训练策略（multi-stage training），每个阶段使用不同的数据混合比例，并在最后阶段进行上下文长度扩展。比如 Qwen3 就采用了通用阶段、推理阶段、长上下文阶段的三阶段训练方案。而 SmolLM3 采用了类似的理念，在训练过程中计划性地引入高质量数据集并扩展上下文长度，同时根据性能监控结果进行动态调整。

超越基础模型——2025 年的后训练阶段

这部分主要介绍了模型的后训练（Post-training）。以 SmolLM3 为例，在完成预训练（Pre-training）后就拥有了 SmolLM3 的原始能力（raw ability），但在 GPU 的温度还未降下之前，就进入了后训练（Post-training）阶段。

当然，在这一切开始之前，就像预训练阶段一样，你也要问自己三个问题：

• 你是不是真的需要后训练？如今许多开源权重模型在各种任务上已能媲美闭源模型，其中一些甚至可以在本地运行（通过量化与低计算配置）。如果你的目标只是一个通用助手，那么 Hugging Face Hub 上的现成模型可能已经足够好，没必要重新训练。
• 你是否拥有高质量、领域特定的数据？后训练的最大价值体现在特定任务或领域上。若通用模型在这些场景下表现欠佳，高质量的专用数据能让你定向优化输出效果。
• 你能衡量成功的标准吗？如果没有清晰的评估标准，你将无法判断后训练是否真的给你带来了改进。

如果确定了要进行后训练，那么又出现一个问题，你想要后训练实现什么目标：一个严格执行指令、几乎不偏题的模型？一个多才多艺的助手，能灵活切换语气与角色？一个擅长数学、代码或推理任务的「思考引擎」？还是一个能多语言流畅交流的通用对话体？

只有明确目标才能选择合适的技术路线。

而一旦前面这几个问题答案都明确之后，接下来就要开始进行训练了，主要步骤包括：

• 监督微调（SFT）：注入核心任务能力；
• 偏好优化（PO）：直接从人类或 AI 偏好中学习；
• 强化学习（RL）：在监督数据之外提升模型的可靠性与推理深度；
• 数据筛选与整理（Data Curation）：平衡数据的多样性与质量；
• 评估体系（Evaluation）：持续跟踪进展并及早发现性能回退。

文章以 SmolLM3 为例，回答了在进行后训练阶段需要回答的几大问题：

SmolLM3 是一个优秀的基础模型，但要在发布前变得可用，必须经过后训练。同时，混合推理模型（如 Qwen3 系列）正快速兴起，但开源社区中缺乏公开可复现的训练配方。因此，SmolLM3 的后训练目标有两点：打造一个可实用的高质量模型；贡献一份完整开源的训练方案，让它能与 Qwen3 的 1.7B 和 4B 模型一同位列行业前沿。

而在后训练的实战阶段时，需要做很多事情，比如选择后训练框架、工具等。不同的框架各自支持不同的算法类型、微调方法、可扩展能力等。

文章总结了一些主要的框架在后训练各环节中的支持范围，涵盖从监督微调到偏好优化，再到强化学习等核心领域的能力对比。

而在主要步骤阶段，文章解答了为何几乎所有的后训练流程都是以监督微调为起点，原因很简单：

• 便宜：相较于 RL，SFT 对算力要求低得多。你通常可以在较短时间内、用较少 GPU，获得显著性能提升——而无需「烧光硅片」。
• 稳定：不同于 RL 那种对奖励设计和超参数极度敏感的训练方式，SFT「开箱即用」——几乎不会崩。
• 是最好的基线：一个良好的 SFT 检查点（checkpoint）通常能提供你所需的大部分性能提升，并让后续如 DPO 或 RLHF 等方法的训练更加高效。

基础设施：被忽视的关键一环

这部分主要是将基础设施，因为大多数从事模型训练的人都非常关心模型架构和数据质量，而忽视了底层的基础设施，认为「租几块 GPU，撞上 Pytorch 就可以了」。然而并非如此，如果用一个比喻来形容，那就是「预训练是蛋糕坯，后训练是上面的糖霜和樱桃，而基础设施就是工业级烤箱」。没有它，一切无从谈起。

像在训练 SmolLM3 时，使用了 384 块 H100 GPU，持续了将近一个月，总共处理了 11 万亿个 token，工程量之浩大，过程之繁琐。

文章指出，对于基础设施，你首先需要知道的是，GPU 的构成、内存层级的工作方式、CPU 与 GPU 之间的通信方式、获取 GPU 时的注意事项，以及在投入长期训练任务前如何测试它们。

CPU 与 GPU 之间的通信路径

其中，需要注意的是，在大型模型训练中，拥有足够多且高速的 GPU 固然重要，但由于 LLM 训练通常持续数周甚至数月，持续追踪 GPU 的健康状态就成为了保持训练稳定性的关键。

文章以 SmolLM3 的训练为例，列举了对 GPU 进行全面诊断的工具：

• GPU Fryer（内部工具）：一款 GPU 压力测试工具，用于检测是否存在热降频；显存错误；性能异常等潜在问题。
• NVIDIA DCGM（数据中心 GPU 管理器）：一款被广泛使用的 GPU 诊断与监控工具，能够执行深度检测，以验证 GPU 硬件、监控性能，并定位故障或功率异常的根本原因。诊断范围包括：计算单元完整性；PCIe 连接稳定性；内存完整性；热稳定性等。

最后，关于训练模型到底要用多少块 GPU，文章指出决策的核心在于训练时间、成本与扩展效率之间权衡的过程。用一个公式来估算就是：

其中，所需总 FLOPs，训练模型所需的计算量，取决于模型规模、训练 token 数量和架构设计；单 GPU 吞吐量，即每张 GPU 际每秒可执行的 FLOPs 数量；目标训练时长，就是你期望训练完成所需的时间。

以 SmolLM3 为例，根据模型规模 30 亿参数、训练 token 数：11 万亿、目标训练时间约 4 周等信息，代入 GPU 需求公式得出的结果约为 379 GPUs。

这一计算结果指向了一个合理的范围：约 375–400 张 H100 GPU，而最后实际上是部署了 384 张 H100，这一规模既符合我们的并行化策略（parallelism strategy），也为训练中可能出现的节点故障、重启等意外情况预留了充足的缓冲空间，从而确保模型能在约 4 周时间内顺利完成训练。

而这也再次证明基础设施对于模型训练的重要性，不要忽视它！

更多信息，可以查看原文！