近期，HuggingFace 发布的超过 200 页的超长技术博客，系统性地分享训练先进 LLM 的端到端经验。
博客的重点是 LLM 开发过程中「混乱的现实」。它坦诚地记录了哪些方法有效、哪些会失败，以及如何应对实际工程中遇到的陷阱。内容基于团队的实际项目经验，特别是他们近期使用 384 块 H100 GPU 训练 3B 参数模型 SmolLM3 的过程。
博客中提供了深入的技术细节、代码片段和调试技巧，对于有兴趣亲自构建 LLM 的读者来说非常有指导意义。
下面是对博客内容的概述，非常推荐感兴趣的读者阅读原文。
这一部分是在投入技术细节（如何训练）之前，提出了一个关键问题：「你是否真的需要训练这个模型」？
鉴于（如 Qwen、Gemma、Llama 等）世界级开源模型层出不穷，大多数人可能并不需要从头开始训练自己的模型。
文章列举了一些不应该训练模型的错误理由，例如：「我们有闲置算力」、「别人都在做」或「AI 是未来」。
然后提供了一个流程图，帮助你思考是否真的训练一个自己的模型。
当你发现：现有模型不可用 —> 提示词工程无法解决 —> 微调无法解决，你就可以考虑从头开始训练了。
定制化预训练通常适用于三个主要领域：
一旦你明确了「Why」，就可以推导出「训练什么 (What)」。包括模型类型（密集型、MoE、混合型、某种新型）、模型大小、架构细节和数据混合。
同时前面的领域目标决定了你的训练决策：例如，为设备端运行 —> 训练小型高效模型；需要多语言能力 —> 使用更大的 tokenizer 词汇表；超长上下文 —> 混合架构。
这个决策过程分为两个阶段。规划：将你的约束（来自「Why」）映射到具体的模型规格；验证：通过系统性的实验（消融实验）来测试你的选择。
文章指出了成功 LLM 训练团队的两个关键特质：
文章还建议，预训练团队一开始不需要很多人（2-3 人足矣），关键是配备足够的算力并保持快速迭代。
在开始训练 LLM 之前，需要做出一系列关键决策（架构、优化器、数据组合等）。人们常以为这些决策是靠深思熟虑得出的，但仅凭推理是不够的，因为 LLM 的行为常常反直觉。
一个典型的例子是：使用看似「最高质量」的 arXiv 科学论文数据，反而可能会损害模型（尤其是小模型）的性能，因为它过于专业化，缺乏通用文本的多样性。
既然纯粹的思考行不通，答案就是像经验主义者一样「运行大量实验」（即消融实验）。
设置消融实验的完整流程：
不要从零开始，应该选择一个已被验证的、成熟的架构（如 Llama 3.1、Qwen3、Gemma3）作为起点，这样可以继承所有已知的优化和稳定性经验。
基线虽好，但并非为你量身定制，因此需要修改。然而，「任何架构上的改变都伴随着风险」。为此，必须遵守「去风险」的纪律，即：「除非你测试过它确实有帮助，否则不要改变任何东西。」
修改的难点在于组件太多且相互作用。你不能测试所有组合。正确的方法是：一次只测试一个有潜力的变更。如果它有效，就将其整合，使其成为新的基线，然后再测试下一个变更。
这是一个关键的技术决策，需要在功能、稳定性和吞吐量之间权衡。
文章对比了几个主流框架：
实验必须足够快（以便快速迭代）和足够可靠（结果能外推到最终模型），有两种主要方法：
接下来文章介绍了其基准消融设置（1B 的 Llama 模型，训练 45B Token），并展示了配置文件的关键部分（数据、模型、优化器等）。
文章指出，评估实验结果时，只看训练损失 (Loss) 是不可靠的。例如，训练维基百科的 Loss 更低，但不代表模型能力更强；更换分词器也会导致 Loss 无法直接比较。因此，必须使用更细粒度的下游评估。
一个可靠的评估任务应具备四个标准：单调性、低噪声、超随机性能和排名一致性。
特别是在早期实验中，「完形填空（CF）」格式比「多项选择（MCF）」更优越，因为后者（如 MMLU）在模型训练的早期阶段表现接近随机，无法提供有效的早期信号。
消融实验的真正价值不仅在于构建好模型，更在于它为未来的调试提供了信心：当主训练不可避免地出错时，系统性的实验结果能帮助团队快速定位问题。
不过，这种价值的成本极其昂贵。以 SmolLM3 为例，消融和调试所消耗的 GPU 时间超过了主训练运行的一半。
这部分内容详细阐述了设计和确定 LLM 架构的完整决策过程，从高层目标到具体的组件选择和超参数设置。
文章以一个名为 SmolLM3 的 3B（30亿参数）模型为例，系统性地展示了如何从零开始构建一个模型的「蓝图」。
文章深入探讨了构成现代 Transformer 的核心架构选择并指出，当今的模型（如 Qwen3、Gemma3）共享 Transformer 基础，但通过组件改进（如 GQA、位置编码）来解决具体问题（如内存、稳定性）。
文章对比了密集型、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）上运行，因为模型的容量会显著影响它吸收不同数据的效果。
文章介绍了两种主要的实验方法：
作者提到，尽管存在 DoReMi 等自动优化方法，但在他们的实践中，仔细的手动消融实验仍然是 SOTA 模型（包括 SmolLM3）确定数据混合的最佳途径。
文章最后以 SmolLM3 为例，展示了如何应用这些原则。
从前面来看，此时已经准备好了大部分的工作，经过验证的模型架构、最终确定的数据混合方案、调好的超参数，剩下的任务就是搭建好基础设施（这在最后讲解），然后「开始」训练。而训练是一个堪比「马拉松」的长周期过程，过程中可能会出现各种情况，所以要做好面对各种挑战的准备。
而这部分主要讲的就是，训练前的「飞行前检查」、过程中那些不可避免的意外状况，以及如何保持系统稳定、不中断。
文章以启动 SmolLM3 前执行的「起飞前检查」清单为例，展示了在开始训练前的准备工作，包括基础设施准备、评测系统准备、Checkpoint 与自动恢复机制、指标日志记录、训练配置复核等。
尤其是在最后按下「训练」按钮之前的训练配置复核，一定要仔细检查训练配置文件、启动脚本、Slurm 提交命令等，以确保参数、路径、环境变量都正确无误。
当然，即使做好了万全准备，在规模化训练过程中，也依然会遇到一些问题。比如在训练启动后的短短数小时内系统的吞吐率（throughput）骤然下滑、持续下滑，以及在引入新的 dataloader（数据加载器） 后，虽然吞吐率下降的问题不再出现，但损失曲线（loss curve）却明显变得更加噪声化，波动比以前大得多等等，各种问题随时都会出现，所以要做好及时应对各种问题的准备。
另外，文章还指出，在现代 LLM 的预训练中，通常会采用多阶段训练策略（multi-stage training），每个阶段使用不同的数据混合比例，并在最后阶段进行上下文长度扩展。比如 Qwen3 就采用了通用阶段、推理阶段、长上下文阶段的三阶段训练方案。而 SmolLM3 采用了类似的理念，在训练过程中计划性地引入高质量数据集并扩展上下文长度，同时根据性能监控结果进行动态调整。
这部分主要介绍了模型的后训练（Post-training）。以 SmolLM3 为例，在完成预训练（Pre-training）后就拥有了 SmolLM3 的原始能力（raw ability），但在 GPU 的温度还未降下之前，就进入了后训练（Post-training）阶段。
当然，在这一切开始之前，就像预训练阶段一样，你也要问自己三个问题：
如果确定了要进行后训练，那么又出现一个问题，你想要后训练实现什么目标：一个严格执行指令、几乎不偏题的模型？一个多才多艺的助手，能灵活切换语气与角色？一个擅长数学、代码或推理任务的「思考引擎」？还是一个能多语言流畅交流的通用对话体？
只有明确目标才能选择合适的技术路线。
而一旦前面这几个问题答案都明确之后，接下来就要开始进行训练了，主要步骤包括：
文章以 SmolLM3 为例，回答了在进行后训练阶段需要回答的几大问题：
SmolLM3 是一个优秀的基础模型，但要在发布前变得可用，必须经过后训练。同时，混合推理模型（如 Qwen3 系列）正快速兴起，但开源社区中缺乏公开可复现的训练配方。因此，SmolLM3 的后训练目标有两点：打造一个可实用的高质量模型；贡献一份完整开源的训练方案，让它能与 Qwen3 的 1.7B 和 4B 模型一同位列行业前沿。
而在后训练的实战阶段时，需要做很多事情，比如选择后训练框架、工具等。不同的框架各自支持不同的算法类型、微调方法、可扩展能力等。
文章总结了一些主要的框架在后训练各环节中的支持范围，涵盖从监督微调到偏好优化，再到强化学习等核心领域的能力对比。
而在主要步骤阶段，文章解答了为何几乎所有的后训练流程都是以监督微调为起点，原因很简单：
这部分主要是将基础设施，因为大多数从事模型训练的人都非常关心模型架构和数据质量，而忽视了底层的基础设施，认为「租几块 GPU，撞上 Pytorch 就可以了」。然而并非如此，如果用一个比喻来形容，那就是「预训练是蛋糕坯，后训练是上面的糖霜和樱桃，而基础设施就是工业级烤箱」。没有它，一切无从谈起。
像在训练 SmolLM3 时，使用了 384 块 H100 GPU，持续了将近一个月，总共处理了 11 万亿个 token，工程量之浩大，过程之繁琐。
文章指出，对于基础设施，你首先需要知道的是，GPU 的构成、内存层级的工作方式、CPU 与 GPU 之间的通信方式、获取 GPU 时的注意事项，以及在投入长期训练任务前如何测试它们。
其中，需要注意的是，在大型模型训练中，拥有足够多且高速的 GPU 固然重要，但由于 LLM 训练通常持续数周甚至数月，持续追踪 GPU 的健康状态就成为了保持训练稳定性的关键。
文章以 SmolLM3 的训练为例，列举了对 GPU 进行全面诊断的工具：
最后，关于训练模型到底要用多少块 GPU，文章指出决策的核心在于训练时间、成本与扩展效率之间权衡的过程。用一个公式来估算就是：
其中，所需总 FLOPs，训练模型所需的计算量，取决于模型规模、训练 token 数量和架构设计；单 GPU 吞吐量，即每张 GPU 际每秒可执行的 FLOPs 数量；目标训练时长，就是你期望训练完成所需的时间。
以 SmolLM3 为例，根据模型规模 30 亿参数、训练 token 数：11 万亿、目标训练时间约 4 周等信息，代入 GPU 需求公式得出的结果约为 379 GPUs。
这一计算结果指向了一个合理的范围：约 375–400 张 H100 GPU，而最后实际上是部署了 384 张 H100，这一规模既符合我们的并行化策略（parallelism strategy），也为训练中可能出现的节点故障、重启等意外情况预留了充足的缓冲空间，从而确保模型能在约 4 周时间内顺利完成训练。
而这也再次证明基础设施对于模型训练的重要性，不要忽视它！
更多信息，可以查看原文！
本文来自微信公众号“机器之心”（ID：almosthuman2014），作者：关注AI的，36氪经授权发布。
发布时间：2025-11-10 08:03
立即订购
在线咨询
返回顶部