HuggingFace重磅开源SmolLM3:小巧、多语言、长上下文推理模型,训练细节技术报告解读!

大模型向量数据库云安全

SmolLM3:小巧、多语言、长上下文推理模型

小型语言模型正变得日益重要,用户寻求功能强大且能高效部署的模型。社区已经涌现出许多出色的小型模型,它们不断突破该规模模型能力的界限。通过 SmolLM3,HF也很高兴能为大家贡献一个全新的、性能具有竞争力且完全开源的 30 亿参数模型:

*指令遵循及推理模型: https://hf.co/HuggingFaceTB/SmolLM3-3B

原文博客: https://huggingface.co/blog/smollm3

SmolLM3在效率上取得了黄金平衡点。 HF的 30 亿参数模型性能超越了 Llama-3.2-3B 和 Qwen2.5-3B,同时与更大的 40 亿参数模型(Qwen3 & Gemma3)保持了竞争力。除了性能数据,HF还精确分享了如何使用公共数据集和开源训练框架构建该模型。

picture.image模型总结:

  • 30 亿参数模型 ,在 11 万亿 (T) 个词元上训练,在 30 亿参数规模达到了领域最佳 (SoTA),并与 40 亿参数模型具有竞争力。
  • 指令遵循模型 ,支持 双模式推理 ,支持 /think (思考)和 /no\_think (不思考)模式。
  • 多语言支持 ,涵盖 6 种语言:英语、法语、西班牙语、德语、意大利语和葡萄牙语。
  • 长上下文支持 ,使用 NoPE 和 YaRN 技术实现最高 128k 的上下文长度。

完整的训练方案: HF发布 SmolLM3 的同时也提供了完整的工程蓝图。这包括架构细节、精确的数据混合比例(展示HF如何通过三阶段预训练方法逐步提升各领域的性能),以及构建混合推理模型的方法论。通常,实现这些结果需要花费数月进行逆向工程。而HF选择直接提供了完整的方法。

picture.image

无论您是自己构建模型,还是想了解在这一规模下哪些因素能提升性能,这份蓝图都将揭示实现 30 亿参数模型竞争性性能背后的工程故事。

接下来看看预训练阶段。

预训练

SmolLM3 在其前代模型的基础上,改进了架构和数据混合比例。首先来看看架构和训练配置细节!

架构和训练细节

picture.image

SmolLM3 采用了一种类似于 SmolLM2 的 Transformer 解码器架构,并使用了绑定嵌入 (tied embedding)。它基于 Llama 架构,并进行了一些关键修改,以优化效率和长上下文性能。

分组查询注意力 (Grouped Query Attention, GQA): HF使用 4 个分组替换了多头注意力 (multi-head attention)。HF在使用 FineWeb-Edu 的 1000 亿 (B) 个词元训练的 30 亿参数模型上进行消融实验表明,GQA 在性能上与多头注意力相当,同时显著减少了推理期间的 KV 缓存大小。

NoPE: HF实现了论文 “ RoPE to NoRoPE and Back Again: A New Hybrid Attention Strategy ” (Yang et al., 2025) 中的 NoPE 技术,选择性地从每四层中移除旋转位置嵌入 (Rotary Position Embeddings, RoPE)。HF的消融实验证实,这种方法在不影响短上下文能力的同时,提高了长上下文性能。

文档内掩码 (Intra-Document Masking): 在训练期间,HF使用注意力掩码 (attention masking) 来确保同一训练序列中来自不同文档的词元互不关注。与 Llama 3 类似,这有助于进行更快速稳定的长上下文训练,同时保持短上下文性能。

训练稳定性: 遵照 OLMo 2 的做法,HF移除了嵌入层 (embedding layers) 的权重衰减 (weight decay),以提高训练稳定性。在HF的消融实验中,这一修改有助于实现更稳定的训练过程,嵌入范数 (embedding norms) 在训练期间自然稳定在更健康的数值,且不影响整体性能。

所有这些修改都通过在用 FineWeb-Edu 的1000 亿个词元训练的相同 30 亿参数架构上进行消融实验得到了验证,确保了每项修改要么提升了性能,要么在保持性能的同时带来了其他益处。

训练配置: HF使用了全局批次大小为 236 万词元,序列长度 4096。学习率为 2e-4,优化器为 AdamW (beta1: 0.9, beta2: 0.95),权重衰减 0.1,梯度裁剪 1。HF使用了 WSD (Warmup-Stable-Decay) 调度器,预热阶段 2000步,并在最后 10% 的训练步数中线性衰减至 0。HF使用 nanotron 框架进行训练, datatrove 进行数据处理, lighteval 进行评估。模型在 384 个 H100 GPU 上训练了 24 天。您可以在下图中看到分布式训练设置。

picture.image

除了架构更改,HF还通过消融实验改进了训练策略。接下来更详细地看看数据混合和大训练阶段。

数据混合和大训练阶段

沿承 SmolLM2 的多阶段方法,HF使用三阶段训练策略在 11.2 万亿个词元上训练了 SmolLM3,该策略混合了网络、数学和代码数据,且比例不断调整。HF在 500 亿至 1000 亿词元训练的 30 亿参数模型上进行了广泛的消融实验,以确定最终的数据混合比例和配比。

picture.image

预训练包括以下阶段(如上图所示):

  • 阶段 1:稳定阶段 (0 万亿 → 8 万亿词元) 这一基础阶段使用HF的核心数据集混合建立了强大的通用能力:
  • 网络数据:85%(其中 12% 为多语言数据)- FineWeb-Edu, DCLM, FineWeb2 和FineWeb2-HQ
  • 代码数据:12% - The Stack v2(涵盖 16 种编程语言)、StarCoder2 拉取请求、Jupyter 和 Kaggle Notebooks、GitHub 问题 (Issues) 和 StackExchange。
  • 数学数据:3% - FineMath3+ 和 InfiWebMath3+
  • 阶段 2:稳定阶段 (8 万亿 → 10 万亿词元) HF引入更高质量的数学和代码数据集,同时保持良好的网络数据覆盖:
  • 网络数据:75%(其中 12% 为多语言数据)
  • 代码数据:15% - 添加 Stack-Edu
  • 数学数据:10% - 引入 FineMath4+, InfiWebMath4+, 和 MegaMath (包括 Qwen 问答数据、Pro 的合成重写数据以及文本-代码穿插块)
  • 阶段 3:衰减阶段 (10 万亿 → 11.1 万亿词元) 最后阶段进一步提高数学和代码数据的采样比例:
  • 网络数据:63%(其中 12% 为多语言数据)
  • 代码数据:24% - 高质量代码数据上采样
  • 数学数据:13% - 数学数据上采样,并引入指令和推理数据集,例如 OpenMathReasoning。

通过这些阶段和混合比例,HF为基础模型取得了非常有竞争力的性能。更多内容将在评估部分介绍。您可以在 这里 找到包含精确数据权重的 nanotron 训练配置。HF还将分享训练日志和中间检查点。

在完成主要预训练后,HF在中期训练阶段改进了模型的长上下文和推理能力。

中期训练

HF将长上下文适应性训练和推理能力适应性训练称为“中期训练”。这些阶段比主要预训练要短得多,但仍然是通用性的,旨在提升模型在这两个领域的能力。首先来看看长上下文训练。

长上下文扩展

picture.image

在主要预训练之后,HF额外训练了 SmolLM3 1000 亿个词元,以扩展其上下文长度。HF分两个阶段顺序扩展了上下文窗口,每个阶段使用 500 亿个词元:首先从 4k 上下文过渡到 32k,同时将 RoPE theta 增加到 150 万;然后从 32k 上下文过渡到 64k,同时将 RoPE theta 增加到 500 万。这两个阶段都提高了数学、代码和推理数据的采样比例。消融实验中,HF发现上采样特定的长上下文数据(例如代码仓库、书籍和长网页,这些数据本身比HF混合数据中的自然长样本更长)未能进一步提升 RULER 和 HELMET 基准测试的性能。事实证明,使用 NoPE 并通过长度更长的序列和增加的 RoPE theta 值在衰减阶段的数据混合上进行训练,就足以达到最高 64k 的竞争性长上下文性能。

与 Qwen2.5 类似,HF使用 YaRN 技术将上下文长度外推 (extrapolate) 到训练上下文长度之外。在推理过程中,模型现在可以处理最高 128k 的上下文(是 64k 训练长度的 2 倍扩展)。

推理能力中期训练

在扩展模型的上下文长度之后,HF在中期训练阶段对其进行训练,以整合推理能力。中期训练阶段与预训练和后训练阶段的主要区别在于,HF旨在提升一种通用能力,尚未侧重于特定领域。在本例中,HF希望训练模型进行推理,但不针对特定领域,例如数学或计算机代码。

HF的中期训练数据集包含 350 亿个词元,源自 Open Thought 的 OpenThoughts3-1.2M 和 NVIDIA 的 Llama-Nemotron-Post-Training-Dataset-v1.1 中包含 R1 推理过程痕迹 (reasoning traces) 的一部分数据。HF使用了 ChatML 对话模板 (chat template) 和 wrapped packing 技术,以避免为模型提供过多结构。HF训练了模型 4 个世代 (epochs)(约 1400 亿个词元),并使用这个检查点进行后续的 SFT 阶段。

后训练(指令微调与对齐)

DeepSeek R1 ( arxiv.org/abs/2501.12948 ) 和 Qwen3 ( arxiv.org/abs/2505.09388 ) 等推理模型的发布,展示了当模型能够进行显式推理时所展现出的强大能力。然而,社区目前仍缺乏完整的公开方案,可以使用公共数据集构建支持推理和非推理双模式的指令模型。现有的大多数方法涉及复杂的强化学习过程和私有数据集,这使得研究人员难以复现和在此基础上构建工作。

在本节中,HF将解释如何解决这些挑战,并分享构建双模式指令模型的完整方案。HF将详细介绍如何通过精心设计的训练流程平衡推理模式和非推理模式之间的性能,该流程包括用于通用推理能力的中期训练、使用合成数据生成的监督式微调 (SFT),以及使用锚定偏好优化 (Anchored Preference Optimization, APO)(一种最新的 DPO 变体)进行的对齐。

picture.image

构建对话模板

在深入探讨训练方法之前,理解用户如何与HF的双模式模型互动至关重要。对话模板 (chat template) 作为实现推理模式和非推理模式无缝切换的界面,其设计直接影响HF的训练数据格式和模型行为。SmolLM3 的对话模板允许用户在对话过程中控制推理模式。用户可以通过在系统提示词 (system prompt) 中包含/think/no\_think标签来分别激活推理或非推理模式。在非推理模式下,HF会用空的思考块预填充模型的响应(类似于 Qwen3),以确保直接回答,无需显式推理过程。SmolLM3 支持工具调用 (tool calling),其对话模板包含了两个独立的工具描述部分:XML Tools 和 Python Tools。事实证明,这种特定的分类在HF实验中有助于模型准确理解这两种格式的工具定义。

对话模板为两种推理模式提供了默认的系统消息,以及一个元数据部分,包括日期、知识截止日期和当前的推理模式。用户可以通过提供一个带有system角色的消息来替换默认系统消息。元数据部分可以通过在系统提示词中使用/system\_override标签排除,为特定用途提供了灵活性。

监督式微调 (SFT)

在推理中期训练阶段(HF在 1400 亿个词元的一般推理数据上训练了模型)之后,HF继续进行监督式微调 (Supervised Finetuning, SFT),以整合数学、代码、通用推理、指令遵循、多语言能力和工具调用等方面的推理和非推理双模式能力。训练一个双模式模型需要在数据混合比例上仔细平衡,以在所有目标领域保持两种模式下的强大性能。为了评估 SmolLM3 在整个训练过程中的表现,HF追踪了以下domains:数学、代码、通用推理、指令遵循和多语言能力。

在构建推理模式数据集时,HF遇到的主要挑战是某些领域缺乏包含推理过程痕迹的数据集。为了弥补这一不足,HF生成了合成数据 (synthetic data):在推理模式下提示 Qwen3-32B ,使用现有非推理数据集中的提示词。这使HF能够提高模型最初在推理模式下表现不佳的领域(例如多轮对话和日常对话)的性能。

picture.image

HF最终的数据混合 비율 是广泛消融实验的结果,这些实验 بررسی 了推理模式和非推理模式词元之间的最佳比例以及各模式内部组成。最终的 SFT 数据集包含 18 亿个词元:10 亿个非推理模式词元和 8 亿个推理模式词元,共包含 12 个非推理数据集和 10个包含推理过程痕迹的数据集。HF训练了 4 个世代 (~80 亿词元),使用 BFD (best-fit decreasing) packing 技术,并对用户轮次和工具调用结果的损失进行掩码。

HF将发布此数据混合比例以及完整的训练脚本,以便社区能够复现并利用HF的工作。

使用锚定偏好优化 (APO) 进行离线模型对齐

SFT 步骤后,HF进行了新一轮的模型对齐,结合使用了用于非推理模式的 Tulu3 偏好数据集 以及HF从 Qwen3-32B 和 Qwen3-0.6B 生成的用于推理模式的新合成偏好对。为了确保非思考数据集充分覆盖所有领域,HF生成了互补的思考模式偏好对。HF选择了 Qwen3-32B 的生成结果作为 “chosen” (优选),将 Qwen3-0.6B 的回复作为 “rejected” (拒绝),用于与锚定偏好优化 (Anchored Preference Optimization, APO) 对齐。

picture.image

锚定偏好优化 (APO)直接偏好优化 (Direct Preference Optimization, DPO) 的一种变体,它提供了一个更稳定的优化目标。在 DPO 中,奖励函数

衡量的是训练过程中序列的概率与训练开始时模型(参考模型)的概率的对数比率 (log-ratio):

picture.image

这里的

控制优化中的模型相对于参考模型可以改变多少。DPO 损失函数优化的是由提示词 x、优选响应

和拒绝响应

组成的三元组:

picture.image

APO 目标函数已被证明更加稳定,HF在内部消融实验中也观察到了更高的下游任务性能。

picture.image

虽然下游评估显示在数学、科学、指令遵循、编码、聊天和多语言任务上有所改进,但HF观察到长上下文基准测试(如 RULER)的性能有所下降。HF将这种下降追溯到推理中期训练阶段,该阶段对推理能力的侧重影响了长上下文性能。此外,APO 训练数据限制在 24k 词元,因为HF的推理数据集绝大部分长度低于此值。

为了减轻这种性能下降,HF探索了模型合并作为一种解决方案。

模型合并

模型合并是一种常用且强大的技术,它可以在不增加集成计算开销或需要额外训练的情况下,结合不同模型的优点。HF使用 MergeKit 库执行模型合并,该库包含多种合并方法,例如线性合并和非线性合并。

HF的合并方案包括两个步骤:

  1. 将每个 APO 检查点整合成一个模型“汤”(model soup)。
  2. 将该模型汤与在长上下文方面表现出色的中期训练检查点结合。事实证明,采用权重为 0.9 (APO 模型汤) 和 0.1 (中期训练检查点) 的线性合并取得了最佳性能。HF成功地恢复了基础模型在最高 128k 上下文长度下在 RULER 上的得分。

由此产生的模型就是HF今天发布的检查点。它在广泛的任务上保持了性能。接下来,来看看基础模型和指令模型的评估结果。

评估

HF评估了SmolLM3 的基础模型以及推理和非推理模式下的指令模型。首先介绍基础模型的性能!

基础模型

下图显示了 SmolLM3 在评估知识、推理、数学和编码能力的 12 个流行基准测试中的胜率。SmolLM3 持续超越其他 30 亿参数模型,并与包括 Qwen3-4B 和 Gemma3-4B 在内的更大模型取得了具有竞争力的性能。

用于计算胜率的评估基准测试:HellaSwag, ARC, Winogrande, CommonsenseQA, MMLU-CF, MMLU Pro CF, PIQA, OpenBookQA, GSM8K, MATH, HumanEval+, MBPP+

picture.image

SmolLM3 在知识和推理基准测试(HellaSwag, ARC, BoolQ)中排名第一或第二,显示出在这些核心能力上的强大表现。数学和编码性能在 30 亿参数级别中具有竞争力。长上下文性能在 Ruler64k 测试中显示模型能有效处理扩展序列。

picture.image

在评估多语言基准测试(包括 Global MMLU, MLMM HellaSwag, Flores-200, Belebele,涵盖知识、常识推理、文本理解和翻译等测试)时,模型在五种主要的欧洲语言中表现出强大的多语言性能。这表明 SmolLM3 在英语之外也能保持 consistent 的性能。

picture.image

总的来说,基础模型在许多领域都表现出了非常强大的性能。接下来看看指令模型的性能如何。

双模式指令 / 推理模型

由于 SmolLM3既有指令模式也有推理模式,HF需要在两种模式下对模型进行评估,并与具有相同能力的其他模型进行比较。

无扩展思考评估

HF将 SmolLM3 与其他 30 亿参数的非推理模型进行评估,并将其与 Qwen3 推理模型在“不思考”模式下跨多个基准测试进行比较。如下图所示,SmolLM3 性能超越了其他 30 亿参数的非推理模型,包括 Llama3.2 3B Instruct 和 Qwen2.5 3B Instruct,并在推理模型中处于效率的黄金地带,显著超越了 Qwen3 1.7B,同时以更低的计算成本接近了 40 亿参数模型的性能。

picture.image

因此,指令模型恰好处于性能和成本的帕累托前沿 (pareto front)。接下来看看推理模型的表现!

扩展思考评估

启用扩展思考 (extended thinking) 后评估 SmolLM3 的推理能力时,模型在绝大多数基准测试中的性能相比其非推理版本都有显著提升。在 AIME 2025 (36.7% vs 9.3%)、LiveCodeBench 上的竞争性编程 (30.0% vs 15.2%),以及 GPQA Diamond 上的研究生级别推理 (41.7% vs 35.7%) 等挑战性任务中,HF观察到显著的提升。

虽然 Qwen3 4B 通常在思考和非思考模式下都取得最高分,SmolLM3 在 30 亿参数类别的模型中表现出色,特别是在数学推理和复杂问题解决任务中。模型的双模式能力允许用户在更快速的推理和更彻底的思考分析之间进行选择。

picture.image

那么最后一个问题是:如何使用这个模型?

本地运行指南

SmolLM3 的建模代码已在 transformersv4.53.0版本中提供,因此请确保您的 transformers 版本已升级。您也可以使用最新版本的vllm加载模型,vllm使用 transformers 作为后端。

  
pip install -U transformers
  
model\_name = "HuggingFaceTB/SmolLM3-3B" device = "cuda" # 用于GPU,若使用CPU则为 "cpu"  # 加载 tokenizer 和模型 tokenizer = AutoTokenizer.from\_pretrained(model\_name) model = AutoModelForCausalLM.from\_pretrained(     model\_name, ).to(device)  # 准备模型输入 prompt ="用简单的语言给我解释一下引力。" messages\_think = [\     {"role": "user", "content": prompt}\ ]  text = tokenizer.apply\_chat\_template(     messages\_think,     tokenize=False,     add\_generation\_prompt=True, ) model\_inputs = tokenizer([text], return\_tensors="pt").to(model.device)  # 生成输出 generated\_ids = model.generate(**model\_inputs, max\_new\_tokens=32768)  # 获取并解码输出 output\_ids = generated\_ids[0][len(model\_inputs.input\_ids[0]) :]print(tokenizer.decode(output\_ids, skip\_special\_tokens=True))

HF建议在采样参数中设置temperature=0.6top\_p=0.95

启用和禁用扩展思考模式

HF默认启用扩展思考,所以上面的示例会生成带有推理过程痕迹的输出。要在启用和禁用之间选择,您可以通过系统提示词提供/think/no\_think标签,如下面的代码片段所示,这用于禁用扩展思考。如果需要启用扩展思考来生成响应,代码是相同的,只是系统提示词应包含/think而不是/no\_think

  
prompt = "用简单的语言给我解释一下引力。"  
messages = [\  
    {"role": "system", "content": "/no\_think"},\  
    {"role": "user", "content": prompt}\  
]  
  
text = tokenizer.apply\_chat\_template(  
    messages,  
    tokenize=False,  
    add\_generation\_prompt=True,  
)  
  
# 后续模型生成代码与上面相同  
# model\_inputs = tokenizer([text], return\_tensors="pt").to(model.device)  
# generated\_ids = model.generate(**model\_inputs, max\_new\_tokens=32768)  
# output\_ids = generated\_ids[0][len(model\_inputs.input\_ids[0]) :]  
# print(tokenizer.decode(output\_ids, skip\_special\_tokens=True))  

Agent (智能体) 用法

SmolLM3 支持工具调用 (tool calling)!只需在参数xml\_tools中传递您的工具列表(用于标准工具调用),或在参数python\_tools中传递工具列表(用于在<code>代码块中调用 Python 函数等工具)。

  
from transformers import AutoModelForCausalLM, AutoTokenizer  
  
checkpoint = "HuggingFaceTB/SmolLM3-3B"  
  
tokenizer = AutoTokenizer.from\_pretrained(checkpoint)model = AutoModelForCausalLM.from\_pretrained(checkpoint)  
  
tools = [\  
    {\  
        "name": "get\_weather",\  
        "description": "Get the weather in a city",\  
        "parameters":{"type": "object", "properties": {"city": {"type": "string", "description": "The city to get the weather for"}}}}\  
]  
  
messages = [\  
    {\  
        "role": "user",\  
        "content": "Hello! How is the weather today in Copenhagen?"\  
    }\  
]  
  
inputs = tokenizer.apply\_chat\_template(  
    messages,  
    enable\_thinking=False, # 设为 True 也可以,由您决定!  
    xml\_tools=tools,  
    add\_generation\_prompt=True,  
    tokenize=True,  
    return\_tensors="pt"  
)  
  
outputs = model.generate(inputs)  
print(tokenizer.decode(outputs[0]))  
  

结论

HF发布了 SmolLM3,一个小型、长上下文、多语言的推理模型,支持最高 128k 的上下文长度。除了模型检查点,HF还公开了完整的训练方案,包括预训练、中期训练、后训练和合成数据生成,以及相关数据集(即将发布)。HF希望这个模型能对社区有所帮助,并且开放的方案能让其他团队在此基础上进行改进。

资源






  





  





  







![picture.image](https://p3-volc-community-sign.byteimg.com/tos-cn-i-tlddhu82om/d3a52415d4984b6b9291957f28c9cc34~tplv-tlddhu82om-image.image?=&rk3s=8031ce6d&x-expires=1752820832&x-signature=5%2B8bruGKyGsHxMGHDeS1wWJQDTA%3D)


添加微信,备注”
 **LLM**
“进入大模型技术交流群


![picture.image](https://p3-volc-community-sign.byteimg.com/tos-cn-i-tlddhu82om/d3a52415d4984b6b9291957f28c9cc34~tplv-tlddhu82om-image.image?=&rk3s=8031ce6d&x-expires=1752820832&x-signature=5%2B8bruGKyGsHxMGHDeS1wWJQDTA%3D)


![picture.image](https://p3-volc-community-sign.byteimg.com/tos-cn-i-tlddhu82om/0cf0348f9e7442709017c14a20ef5985~tplv-tlddhu82om-image.image?=&rk3s=8031ce6d&x-expires=1752820832&x-signature=4clXbqGiJkDl62ACD76qEIpWcvg%3D)




> 
> 
> 如果你觉得这篇文章对你有帮助,别忘了点个赞、送个喜欢
> 
> 
> 





>/ 作者:致Great


  >/ 作者:欢迎转载,标注来源即可


  











0
0
0
0
关于作者
关于作者

文章

0

获赞

0

收藏

0

相关资源
大模型解决方案白皮书;社交陪伴场景全流程落地指南
随着大模型技术持续突破,AI正加速重塑社交娱乐的形态与体验。其中,陪伴式聊天因用户黏性强、互动频次高,成为大模型商业化落地的关键赛道。随着模型能力跃升至万亿参数级,AI从工具属性正迈向情感交互生态,现象级产品的诞生条件逐渐成熟。 本白皮书聚焦AI陪伴聊天应用开发,面向“从何起步、如何落地”的新手困惑,系统拆解从需求定义到产品上线的关键流程。我们结合工程化实践路径,打造模块化知识体系与渐进式开发框架,帮助开发者在30天内完成从技术认知到产品原型的跃升,快速构建具备基础交互能力的Web或App应用,迈出大模型
相关产品
评论
未登录
看完啦,登录分享一下感受吧~
暂无评论