Qwen3高效微调

高效微调

场景、模型、数据、算力

高效微调的应用场景

对话风格微调：高效微调可以用于根据特定需求调整模型的对话风格。例如，针对客服系统、虚拟助理等场景，模型可以通过微调来适应不同的 语气、礼貌程度 或 回答方式，从而在与用户互动时提供更符合要求的对话体验。通过微调少量的参数（例如对话生成的策略、情感表达等），可以使
模型表现出更具针对性和个性化的风格。
知识灌注：知识灌注是指将外部知识或领域特定的信息快速集成到已有的预训练模型中。通过高效微调，模型可以更好地学习新领域的专有知识，而无需重新从头开始训练。例如，对于法律、医疗等专业领域，可以使用少量的标注数据对预训练模型进行微调，帮助模型理解特定行业的术语、规
则和知识，进而提升专业领域的问答能力。
推理能力提升：高效微调还可以用于提升大模型的推理能力，尤其是在处理更复杂推理任务时。通过微调，模型能够更加高效地理解长文本、推理隐含信息，或者从数据中提取逻辑关系，进而在多轮推理任务中提供更准确的答案。这种微调方式可以帮助模型在解答复杂问题时，提高推理准确性并减少错误。
Agent能力（Function calling能力、或者MCP能力）提升：在多任务协作或功能调用场景中，高
效微调能够显著提升模型的Agent能力，使得模型能够有效地与其他系统进行交互、调用外部API或
执行特定任务。通过针对性微调，模型可以学会更精准的功能调用策略、参数解析和操作指令，从
而在自动化服务、智能助手或机器人控制等领域表现得更加高效和智能。

模型微调技术

1.1 微调基本概念

所谓大模型微调，指的在已有的大规模预训练模型基础上，通过对标注数据进行训练，进一步优化
模型的表现，以适应特定任务或场景的需求。不同于RAG或者Agent技术，通过搭建工作流来优化模型表现，微调是通过修改模型参数来优化模型能力，是一种能够让模型“永久”掌握某种能力的方法。

1.2 全量微调与高效微调

从方法的大类上来划分，微调又可以划分为全量微调：带入全部数据进行微调，和高效微调：只
带入部分数据进行微调。毫无疑问，全量微调是一种算力消耗更大、但对模型的能力改造更为彻底的方法，而高效微调则更类似一种“四两拨千斤”的方法，通过修改模型部分参数，来调整模型整体能力。

1.3 模型微调的优劣势分析

尽管模型微调能够通过修改模型参数的方式，永久的修改模型的能力，但这其实是一把双刃剑，如
果处理不当，很可能造成模型原始能力的灾难性遗忘、即会导致模型原始能力丢失，对于复杂模型尤其如此。而为了能够满足微调最初目标，我们必须小心谨慎的设计模型微调数据集和微调训练流程，并经过反复多次训练验证，得到一个最佳模型。

1.4 高效微调与LoRA、QLoRA

用于大模型的最主流的高效微调方法只有一种—LoRA。
LoRA（Low-Rank Adaptation）微调是一种参数高效的微调方法，旨在通过引入低秩矩阵来减少微
调时需要调整的参数数量，从而显著降低显存和计算资源的消耗。具体来说，LoRA 微调并不直接调整原始模型的所有参数，而是通过在某些层中插入低秩的适配器（Adapter）层来进行训练。
LoRA的原理：
在标准微调中，我们会修改模型的所有权重，而在 LoRA 中，只有某些低秩矩阵（适配器）被训练
和调整。这意味着原始模型的参数保持不变，只是通过少量的新参数来调整模型的输出。低秩矩阵的引入可以在显存和计算能力有限的情况下，依然有效地对大型预训练模型进行微调，从而让 LoRA 成为显存较小的设备上的理想选择。
LoRA的优势：

1. 显存优化： 只需要调整少量的参数（适配器），显著减少了显存需求，适合显存有限的GPU。
2. 计算效率： 微调过程中的计算负担也更轻，因为减少了需要调整的参数量。
3. 灵活性： 可以与现有的预训练模型轻松结合使用，适用于多种任务，如文本生成、分类、问答等。
   QLoRA（Quantized Low-Rank Adaptation）
   是 LoRA 的一个扩展版本，它结合了 LoRA 的
   低秩适配器和量化技术。QLoRA 进一步优化了计算效率和存储需求，特别是在极端显存受限的环境下。与 LoRA 不同的是，QLoRA 会将插入的低秩适配器层的部分权重进行量化（通常是量化为 INT4 或INT8），在保持性能的同时显著降低模型的存储和计算需求。
   核心思想
   在 LoRA 的基础上加入量化技术，减少权重表示的位数，从而降低显存和计算需求。QLoRA 结合了低秩适配器和量化的优点，能够在显存有限的设备上进行更高效的微调。
   量化： 通过将模型权重量化为低精度（如 INT4），减少内存占用，并提高推理和训练速度。
   优势：在显存非常有限的情况下仍能进行微调。
   

Qwen 3 模型

网络结构主要的改进点：

attention层
使用了grouped query attention：主要是节约显存
Q和K做attention前分别做了RMSNorm：分别做归一化，主要是为了后续梯度下降时快速收敛，避免来回震荡
MLP层
经典的MLP就是多层全连接，但这里明显多了linear层，核心目的是做信息筛选（通过乘以矩阵过滤某些不重要的信息），所以取名Gate。经过Gate后才是相乘来融合信息，最终再经过linear降维进入output
滑动窗口
最长已经到128K了，这么长的context，attention怎么做？attention的算法是找到距离接近的token，然后把value按照weight比例加过来，核心目的做信息融合：距离近的value多融合一些，距离远的就少融合一些；从业务上讲意义接近的token之间的距离不会太远，比如几十万字的书，某个章节内部的token之间距离较近，章节之间的token距离不会那么近了，所以站在业务角度：短距离内的token再计算相似度就行了，距离太远其实已经没啥业务关联了，没必要做attention！按照这个思路，Qwen3把attention的距离缩短到了4096个，也就是4k的距离，使用的是sliding windows实现的
图示如下：

专家模型
大参数model还是用MOE，推理的时候选择top 8个expert计算：

训练过程

• 网络爬取的高质量文本；
• 使用qwen2.5-VL从PDF文档中提取的内容.这是个多模态的model，应该是从图片提取文本
• 由Qwen2.5-Math和awen2.5-Coder合成的专业领域数据
• 
  数据准备妥当后，就要train了；总所周知，LLM目前train的范式分别是pre-train、post-train；pre-train没啥说的，核心是post-train了，一般先做SFT，再做RL；Qwen3也不例外，也是这个套路，不过因为需求多样，post-train做了4个阶段
  
• 阶段1：使用math、code、long-cot、STEM等问题做SFT，让model具备这些领域的知识，配备基础的推理能力
• 阶段2：做大规模的RL，利用基于规则（code、math等很容易判断对错）的reward让model做大量的exploration，提升其探索、专研能力
• 阶段3：在一份包括long-cot数据和常用的instruction数据的组合数据上对模型进行微调，将非思考模式整合到思考模型中，确保了推理和快速响应能力的无缝结合。
  并不是所有的问题都要深度思考，比如用户问1+1等于多少？这种简单问题还做long-cot这种思考推理那就是浪费用户时间和自己的算力；所以也要用一些non-cot数据训练，让model学会快速响应和回复！
• 阶段4：在包括指令遵循、格式遵循和Agent 能力等在内的 20 多个通用领域的任务上应用了RL，以进一步增强模型的通用能力并纠正不良行为。让model严格遵循指令输出response，比如输出json格式的数据；或则按照agent的需求输出结果，所以这一步需要加强训练，以便输出的格式符合预期！

大模型训练完后，为了方便不同层级和场景的用户使用，需要蒸馏成不同的尺寸.
　
Qwen3一个明显的特点是支持两种不同的思考模式：
思考模式:在这种模式下，模型会逐步推理，经过深思熟虑后给出最终答案。这种方法非常适合需要深入思考的复杂问题。
非思考模式:在此模式中，模型提供快速、近乎即时的响应，适用于那些对速度要求高于深度的简单问题：自动带上think标签，并且标签里面是空的；

数据

如何创建和选取模型微调数据集，是决定模型微调效果成败的最关键因素，截止目前，已经诞生了各类不同的微调框架和海量的微调数据集，在绝大多数情况下，我们只需要选择不同的微调框架并搭配不同的数据集即可。但伴随着模型能力越来越复杂，包括现阶段很多模型具备了Function calling功能，甚至是具备了推理或者混合推理能力，此时如果希望进行一些复杂功能****，希望给模型进行特定领域的知识关注，或者提升模型对于特殊工具组的工具调用准确率，此时就需要手动创建微调数据集了。而要手动合并或者创建微调数据集，就必须深入了解微调数据集构造背后的原理。

对于当代大模型来说，普遍需要通过一些特殊字符来标记用户的不同类型输入、系统提示词、以及工具调用或者多模态输入。其中 <|im_start|> 代表文本开始，而 user 则代表消息身份，用于构建多轮对话，**而 <|im_end|> 则代表文本结束，即用户输入结束，**而 <|im_start|> 代表新一段文本开始， assistant 代表接下来由模型创建消息，而 <|im_end|> 同样代表模型创建消息的结束。

模型通过这样一组特殊字符标记来规范自己的行为，判断当前消息类型，以及通过输出特
殊标记来确定停止时间。对于绝大多数模型，我们可以在模型的 tokenizer_config.json 中看到完整的特殊标记符（以及系统提示词模板）
以Qwen3为例：

1. 模型内置特殊字符及提示词模板

在实际微调过程中，我们都知道需要有监督的数据集、也就是需要输入QA对来进行微调。以著名的alpaca_zh中文微调数据集来说，其基本格式如下：

而在真实的微调过程中，如果是针对Qwen3进行微调，微调脚本会将这条数据集（无论什么格式）转化为如下格式：

在实际训练过程中，模型就会根据assistant前的内容，学习assistant后面的输出内容。

2. 带有系统提示和Function calling微调数据集格式

在很多场景下，我们还会发现一些带有 instruction 字段的微调数据集，那 instruction 字段是
如何带入到微调过程中的呢？

答案非常简单，还是依靠特殊字符。例如有一个对话内容如下：

系统提示词（instruction）：你是一名助人为乐的助手。
用户输入（input）：你好，好久不见。
助手回复（output）：是的呀，好久不见，最近有什么有趣的事情要和我分享么？

此时模型的输入和输出如下：

即会通过 <|im_start|>system…<|im_end|> 来标记系统提示词。实际进行微调时，模型会根据
assistant为界，学习assistant之前的文本输入情况下应该如何输出。

更进一步的，如果对话过程中带入了Function calling，此时首先模型会读取提前准备好的tool
schema（也可能是自动生成的，例如MCP即可自动创建tool schema）：

而假设我们的对话内容如下：

系统提示词（instruction）：你是一名助人为乐的助手。当用户查询天气的时候，请调用
get_weather函数进行天气信息查询。
用户输入（input）：你好，请帮我查询下北京天气。
助手回复（output）：{"name": "get_weather", "arguments": {"location": "北京"}}

此时回复内容就是一条Function call message
而此时模型真实的输入和输出内容如下：

<|im_start|>system
你是一名助人为乐的助手。当用户查询天气的时候，请调用get_weather函数进行天气信息查询。
#Tools
You may call one or more functions to assist with the user query.
You are provided with function signatures within <tools></tools> XML tags:
<tools>
{"name": "get_weather", "description": "查询指定城市的天气信息", "parameters":
{"type": "object", "properties": {"location": {"type": "string", "description":
"要查询天气的城市名称"}}, "required": ["location"]}}
</tools>
For each function call, return a json object with function name and arguments
within <tool_call></tool_call> XML tags:
<tool_call>
{"name": <function-name>, "arguments": <args-json-object>}
</tool_call>
<|im_end|>
<|im_start|>user
你好，请帮我查询下北京天气。<|im_end|>
<|im_start|>assistant
<tool_call>
{"name": "get_weather", "arguments": {"location": "北京"}}
</tool_call><|im_end|>

接下来在进行训练时，**模型同样根据assistant前的内容，学习assistant后面的输出内容。**不过需要注意的是，由于高效微调调整的参数量较少，因此只能优化模型的Function calling能力，并不能从无到有让模型学会Function calling.

3. 带有思考过程的微调数据集结构

<|im_start|>system 你是一名助人为乐的助手。<|im_end|>
<|im_start|>user你好，好久不见。<|im_end|> <|im_start|>assistant < think>好的，用户发来“你好，好久不见！”，我需要回应。首先，用户可能希望得到亲切的回应，所以应该用友好的 语气。 </ think>是的呀，好久不见，最近有什么有趣的事情要和我分享么？<|im_end|>

模型同样根据assistant前的内容，学习assistant后面的输出内容。也就是说，所谓的思考过程，本质上其实是一种文本响应格式，通过模型训练而来。

最后难度升级，假设是带有思考过程、系统提示词的Function calling流程呢？

内容如下：
系统提示词（instruction）：你是一名助人为乐的助手。当用户查询天气的时候，请调用
get_weather函数进行天气信息查询。
用户输入（input）：你好，请帮我查询下北京天气。
助手回复（output）：好的，用户问北京今天的天气，我应该尝试调用工具get_weather，并将参
数设置为北京。/n{“name”: “get_weather”, “arguments”: {“location”: “北京”}}

![在这里插入图片描述](https://i-blog.csdnimg.cn/direct/8d0a14003a8445ad979465d271292cab.png

模型同样根据assistant前的内容，学习assistant后面的输出内容。由此可见，模型拥有不同功能的背后，其实源于不同格式的训练数据集的训练。而对于Qwen3这种模型来说，同时拥有Function calling、混合推理等功能，属于功能非常复杂的模型了。在实际微调过程中，稍有不慎就会令其丧失原有能力。

两种不同的思考模式直接通过设置enable_thinking参数即可！
如果不需要思考，

prompt直接加上< think> < /think>

标签作为pre-fill，让model认为think阶段已经结束，直接输出结果；如果需要思考，

prompt完全不加上< think>< /think>标签

，model回答的时候发现没有think过程，自动补上这个过程，所以控制是否思考就是在prompt加上think标签即可！

不过需要注意的是，Function calling能力微调其实是非常复杂的事情，除了上述系统提示词+思考链+工具并联调用外，还可能出现比如工具串联调用、工具不存在时返回结果、以及多次调用工具（3次）无法成功后返回结果等数据，此外，在真实的Functioncalling能力训练数据集中，还需要包含至少几十种或者上百种API工具调用，才能让大模型本身识别外部工具的能力得到泛化。

个人建议：

1. 微调数据集2000-5000条最佳，因为随着轮次和数据量的增加，会导致模型参数频繁更新，当不断更新时，会导致参数偏离原始权重参数
2. 微调数据集1w条以上，需要混入推理数据，最好再搭配一万条其它类型的聊天数据，2万条数学类或代码类的推理类通用数据集
3. 和数据配比1：1，禁止1万推理数据集，然后另一万数据集直接去掉,相同的问法，但是不一样的回答会导致模型变傻

主流微调工具介绍

在入手学习大模型微调时，首先推荐功能层次封装层次较高的微调工具：unsloth、LlamaFactory。除此之外，也可以借助更加底层的库，如peft、LoRA、transformer等实现高效微调。目前首推使用现成工具来进行微调。
unsloth
是一个专为大型语言模型（LLM）设计的动态量化与微调框架，旨在提高微调效率并减少显存占用。 相比传统方法，Unsloth采用独家4bit动态量化技术，能够在更短的时间内完成微调任务，节省时间成本，使 LLM 的微调速度提高 2-5 倍，显存使用量减少约 80%，且准确度无明显下降。目前，关于 Qwen3 模型在 4-bit 动态量化下的具体性能下降数据尚不全面。然而，根据最近的一项研究，Qwen3 模型在4bit动态量化时，仅损失不到1%的性能。
不过需要注意的是，动态量化由利也有弊，其好处在于可以极大程度压缩模型运行所需占用的显存
大小，同时几乎不损失性能，但问题在于动态量化的模型，无论是推理还是微调，只能单卡运行，这就使得其吞吐量有限，无法在一台物理机上实现多GPU并行从而扩大吞吐量。

LLama-Factory
LLaMA-Factory 是一个统一且高效的微调框架，旨在为超过 100 种**大型语言模型（LLMs）和视觉
语言模型（VLMs）**提供便捷的微调支持。 用户能够灵活地定制模型以适应各种下游任务。： 除了传统的文本任务外，LLaMA-Factory 还视频识别、音频理解等多种任务类型。