企业级AI落地项目系列课程详解 -> 点击进入

一、大模型微调技术快速入门

1. 微调基础概念介绍

1.1 微调基本概念

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

1.2 全量微调与高效微调

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

1.3 模型微调的优劣势分析

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

1.4 高效微调与LoRA、QLoRA

        尽管全量微调可以对模型的能力进行深度改造，但要带入模型全部参数进行训练，需要消耗大量的算力，且有一定的技术门槛。相比之下，在绝大多数场景中，如果我们只想提升模型某个具体领域的能力，那高效微调会更加合适。尽管在2020年前后，深度学习领域诞生了很多高效微调的方法，但现在适用于大模型的最主流的高效微调方法只有一种——LoRA。

        LoRA（Low-Rank Adaptation）微调是一种参数高效的微调方法，旨在通过引入低秩矩阵来减少微调时需要调整的参数数量，从而显著降低显存和计算资源的消耗。具体来说，LoRA 微调并不直接调整原始模型的所有参数，而是通过在某些层中插入低秩的适配器（Adapter）层来进行训练。

LoRA的原理：

• 在标准微调中，我们会修改模型的所有权重，而在 LoRA 中，只有某些低秩矩阵（适配器）被训练和调整。这意味着原始模型的参数保持不变，只是通过少量的新参数来调整模型的输出。

• 低秩矩阵的引入可以在显存和计算能力有限的情况下，依然有效地对大型预训练模型进行微调，从而让 LoRA 成为显存较小的设备上的理想选择。

LoRA的优势：

1. 显存优化： 只需要调整少量的参数（适配器），显著减少了显存需求，适合显存有限的GPU。

1. 计算效率： 微调过程中的计算负担也更轻，因为减少了需要调整的参数量。

1. 灵活性： 可以与现有的预训练模型轻松结合使用，适用于多种任务，如文本生成、分类、问答等。

        而QLoRA（Quantized Low-Rank Adaptation） 则是 LoRA 的一个扩展版本，它结合了 LoRA 的低秩适配器和量化技术。QLoRA 进一步优化了计算效率和存储需求，特别是在极端显存受限的环境下。与 LoRA 不同的是，QLoRA 会将插入的低秩适配器层的部分权重进行量化（通常是量化为 INT4 或 INT8），在保持性能的同时显著降低模型的存储和计算需求。

• 核心思想： 在 LoRA 的基础上加入量化技术，减少权重表示的位数，从而降低显存和计算需求。QLoRA 结合了低秩适配器和量化的优点，能够在显存有限的设备上进行更高效的微调。

• 量化： 通过将模型权重量化为低精度（如 INT4），减少内存占用，并提高推理和训练速度。

• 优势：

• 在显存非常有限的情况下仍能进行微调。

• 可以处理更大规模的模型。

• 适合用于边缘设备和需要低延迟推理的场景。

LoRA 与 QLoRA 二者对比如下

特性	LoRA	QLoRA
核心技术	低秩适配器（Low-Rank Adapters）	低秩适配器 + 量化技术（Low-Rank Adapters + Quantization）
适用场景	显存受限，但设备性能较好	极限显存受限或需要快速推理的设备
计算效率	提高计算效率，减少调整的参数数量	进一步提升效率，减少内存使用并加快推理速度
量化技术	无量化	将权重量化为低精度（如 INT4 或 INT8）
内存消耗	较低，但不如 QLoRA 低	显著降低内存消耗，适合更小的设备
训练复杂度	较简单，适用于大多数微调场景	需要更多的量化和适配工作，但适合超大模型和设备受限场景

2. 高效微调的应用场景

        在实际大模型应用场景中，高效微调主要用于以下四个方面：

• 对话风格微调：高效微调可以用于根据特定需求调整模型的对话风格。例如，针对客服系统、虚拟助理等场景，模型可以通过微调来适应不同的 语气、礼貌程度 或 回答方式，从而在与用户互动时提供更符合要求的对话体验。通过微调少量的参数（例如对话生成的策略、情感表达等），可以使模型表现出更具针对性和个性化的风格。

• 知识灌注：知识灌注是指将外部知识或领域特定的信息快速集成到已有的预训练模型中。通过高效微调，模型可以更好地学习新领域的专有知识，而无需重新从头开始训练。例如，对于法律、医疗等专业领域，可以使用少量的标注数据对预训练模型进行微调，帮助模型理解特定行业的术语、规则和知识，进而提升专业领域的问答能力。

• 推理能力提升：高效微调还可以用于提升大模型的推理能力，尤其是在处理更复杂推理任务时。通过微调，模型能够更加高效地理解长文本、推理隐含信息，或者从数据中提取逻辑关系，进而在多轮推理任务中提供更准确的答案。这种微调方式可以帮助模型在解答复杂问题时，提高推理准确性并减少错误。

• Agent能力（Function calling能力、或者MCP能力）提升：在多任务协作或功能调用场景中，高效微调能够显著提升模型的Agent能力，使得模型能够有效地与其他系统进行交互、调用外部API或执行特定任务。通过针对性微调，模型可以学会更精准的功能调用策略、参数解析和操作指令，从而在自动化服务、智能助手或机器人控制等领域表现得更加高效和智能。

3. 主流微调工具介绍

        在入手学习大模型微调时，首先推荐功能层次封装层次较高的微调四套工具：unsloth、Llama-Factory、ms-SWIFT和ColossalAI。除此之外，也可以借助更加底层的库，如peft、LoRA、transformer等实现高效微调。对于初学者来说，首先使用现成工具来进行微调，四种工具基本说明如下。

3.1 unsloth

• unsloth GitHub主页：https://github.com/unslothai/unsloth

        unsloth 是一个专为大型语言模型（LLM）设计的动态量化与微调框架，旨在提高微调效率并减少显存占用。 它通过手动推导计算密集型数学步骤并手写 GPU 内核，实现了无需硬件更改即可显著加快训练速度。

        unsloth 与 HuggingFace 生态兼容，可以很容易地transformers、peft、trl 等库结合，以实现模型的监督微调（SFT）和直接偏好优化（DPO），仅需模型的加载方式，无需对现有训练代码进行修改。

• Unsloth动态量化模型：https://unsloth.ai/blog/dynamic-v2

        Unsloth 的动态量化方法，特别是其最新的 Dynamic 2.0 版本，旨在在尽量减少性能损失的同时显著压缩大型语言模型（LLMs）的体积。对于 Qwen3 模型，尤其是 4-bit 动态量化版本，现有的评测显示其性能下降非常有限，甚至在某些任务上与原始模型相当。具体评测结果如图所示：

        而目前，关于 Qwen3 模型在 4-bit 动态量化下的具体性能下降数据尚不全面。然而，根据最近的一项研究，Qwen3 模型在4bit动态量化时，仅损失不到1%的性能。

论文地址：https://arxiv.org/abs/2505.02214

这也使得Unsloth的动态量化模型成为个人配置下的最佳微调工具。

        不过需要注意的是，动态量化由利也有弊，其好处在于可以极大程度压缩模型运行所需占用的显存大小，同时几乎不损失性能，但问题在于动态量化的模型，无论是推理还是微调，只能单卡运行，这就使得其吞吐量有限，无法在一台物理机上实现多GPU并行从而扩大吞吐量。

主要功能点：

• 高效微调： unsloth 通过深度优化，使 LLM 的微调速度提高 2-5 倍，显存使用量减少约 80%，且准确度无明显下降。

• 广泛的模型支持： 目前支持的模型包括目前各类主流模型，用户可以根据需求适合的模型进行微调。

• 兼容性： unsloth 与 HuggingFace态系统兼容，用户可以轻松将其与 traformers、peft、l 等库结合，实现模型的监督微调（SFT）和直接偏好优化（DPO），仅需修改模型的加载方式，无需对现有训练代码进行过多修改。

• 内存优化： 通过 4 位和 16 位的 QLoRA/LoRA 微调，unsloth 显著了显存占用，使得在资源受限的环境中也能大的微调。

unsloth核心优势：

• 显著提升微调效率： 相比传统方法，Unsloth采用独家4bit动态量化技术，能够在更短的时间内完成微调任务，节省时间成本。

• 降低硬件要求： 通过优化显存使用，用户可以在显存较小的 GPU 上进行大模型的微调，降低了硬件门槛。

• 开源免费： Unsloth 提供开源版本，用户可以在 Google Colab 或 Kaggle Notebooks 上免费试用，方便上手体验。

总的来说，unsloth 为大型语言模型的微调提供了高效、低成本的解决方案，适合希望在有限资源下进行模型微调的开发者和研究人员。

3.2 LLama-Factory

• LLama-Factory GitHub主页：https://github.com/hiyouga/LLaMA-Factory

        LLaMA-Factory 是一个统一且高效的微调框架，旨在为超过 100 种大型语言模型（LLMs）和视觉语言模型（VLMs）提供便捷的微调支持。 用户能够灵活地定制模型以适应各种下游任务。

主要功能和特点：

• 广型支持： LLaMA-Factory 支持对 100 多LLMs 和 VLMs 进行微调，包括最新的模型版本，如 Llama 3、GLM-4、Mistral Small、PaliGemma2 等。

• 高效的微调方法： 框架集成了多nk Adaptation）、QRA（Quantized LoRA）等，以提高训练速度并减少显存占用。

• 多模态任务支持： 除了传统的文本任务外，LLaMA-Factory 还支频识别、音频理解等多种任务类型。

• 实验监控： 提供了丰富的实验监控工具，如 LlamaBoard、TensorBoard、Wandb、MLflow、练过程。

• 快速： 框架提供了类似 OpenAI 风格的 API、Gradio UI 和命令行界面，并结合 vLLM worker，实现了高效的推理能力。

3.3 ms-SWIFT

• ms-SWIFT GitHub项目主页：https://github.com/modelscope/swift

        ms-swift（Scalable lightWeight Infrastructure for Fine-Tuning）是由魔搭社区（ModelScope）开发的高效微调和部署框架，旨在为研究人员和开发者提供一站式的大模型与多模态大模型的训练、推理、评测、量化和部署解决方案。 的模型支持：** ms-swift 支持超过 450 种大型模型（LLMs）和 150 多种多模态大模型（MLLMs）的训练和部署**，包括最新的模型版本，如 Qwen2.5、InternLM3、GLM4、Llama3.3、Mistral、DeepSeek-R1、Yi1.5、Baichuan2、Gemma2 等，以及多模态模型如 Qwen2.5-VL、Qwen2-Audio、Llama3.2-Vision、Llava、InternVL2.5 等。

• 多样化的训练技术： 框架集oRA、Llama-Pro、LonoRA、GaLore、Q-GaLore、LoRA+、LISA、DoRA、FourierFt、ReFT、UnSloth 和 Liger 等，满足不同的微调需求。

• 轻量级微调： 支持多种轻量级微调方法，如 LoRA、QLoRA、DoLLaMAPro、Adapt、GaLore、Q-Galore、LISA、UnSloth、Liger-Kernel 等，降低显存和计算资源的消耗。

• 分布式训练： 支持分布式数据并行（DDP）、DeepSpeed ZeRO2/ZeRO3、FSDP 等技术，提升推理加速：** 提供 BNBWQ、GPTQ、AQLM、HQQ、EETQ 等量化方法，并支持使用 vLLM 和 LMDeploy 对推理、评测和部署 支持图像、视频和语音等多种模态型训练，涵盖 VQA、Caption、OCR、Grounding 等任务。

• 用户友好的界面： 提供基于 Gradio 的 We和量化操作，简化了大模型的全链路流程。

3.4 ColossalAI

• ColossalAI GitHub项目主页：https://github.com/hpcaitech/ColossalAI

        Colossal-AI 是一个高效的分布式人工智能训练系统，旨在最大化提升人工智能训练效率，同时最小化训练成本。作为深度学习框架的内核，Colossal-AI 提供了自动超高维并行、大规模优化库、自适应任务调度、内存优化以及最新模型复现等前沿技术。与英伟达的 Megatron-LM 相比，Colossal-AI 仅需一半数量的 GPU 即可完成 GPT-3 训练，半小时内预训练 ViT-Base/32，并在两天内训练完 15 亿参数的 GPT 模型。此外，Colossal-AI 提供了多种并行技术，如数据并行、流水线并行和张量并行，以加速模型训练。 citeturn0search1该项目自开源以来，迅速登上 GitHub 热榜，成为解放 AI 生产力的最佳选择。

        并且，ColossalAI也是目前唯一支持DeepSeek R1非量化模型高效微调的框架，仅需4个节点、8卡A100服务器即可完成DeepSeek R1高效微调。

注一：若是强化学习训练，则推荐veRL和OpenRLHF等框架。

注二：其他更底层微调框架推荐

框架	优势	适用场景
Hugging Face	高度兼容，易用，文档丰富	一般 NLP 任务，模型选择丰富
LoRA	显存节省，减少微调计算量	显存有限的设备，微调大规模模型
PEFT	高效微调，低计算开销	资源有限的环境，适合大规模预训练模型的微调
DeepSpeed	大规模分布式训练，显存优化	超大规模训练，多卡分布式训练
AdapterHub	低资源消耗，快速微调	多任务微调，资源有限的环境
Alpaca-LoRA	生成任务优化，LoRA 技术结合	对话生成、文本生成
FastChat	对话系统微调，快速集成	对话生成任务，尤其是对 ChatGPT 等模型微调
FairScale	大规模分布式训练优化，自动化优化	多卡分布式训练，大规模微调

4. 模型性能评估框架EvalScope

• 项目地址：https://github.com/modelscope/evalscope

        EvalScope 是由阿里巴巴魔搭社区（ModelScope）推出的一款开源模型评估框架，旨在为大语言模型（LLM）和多模态模型提供统一、系统化的性能评估方案。该框架具备高度的自动化和可扩展性，适用于研究机构、工业界以及模型开发者在模型验证与性能对比场景中的广泛需求。

EvalScope 的核心功能和特点包括：

1. 丰富的评测基准覆盖：框架内置多种权威评测数据集，涵盖中英文通用知识问答（如 MMLU、CMMLU、C-Eval）、数学推理（如 GSM8K、MATH）、常识判断（如 HellaSwag、ARC）、代码生成（如 HumanEval）等多个方向，支持对模型能力进行多维度评估。

1. 多样的评估模式支持：EvalScope 提供三种灵活的评估模式，包括单模型评估模式（Single）、基于基线的两两对比模式（Pairwise-Baseline）、以及全模型两两对比模式（Pairwise-All），可满足从快速诊断到全面对比的不同使用场景。

1. 统一的模型接入接口：框架对不同类型的模型提供统一的调用方式，兼容 HuggingFace、本地部署模型及 API 远程调用，支持标准的 generate 与 chat 接口，大大降低了模型集成的复杂度。

1. 评估流程高度自动化：EvalScope 实现了评测任务的全自动执行，包括客观题自动打分、复杂问题使用评审模型辅助判定结果等，支持批量评估与日志记录，极大提升了评估效率与结果一致性。

1. 完善的性能与能力可视化工具：框架支持生成详细的评估报告和图表，展示模型在不同任务维度下的表现，便于开发者进行横向对比和性能分析。

1. 多后端与评测能力扩展：EvalScope 可集成多个评测后端，如 OpenCompass、VLMEvalKit、RAGEval 等，支持从单模态到多模态、从语言建模到 RAG 端到端评测的全链路能力。

1. 支持部署性能测试：除评估模型能力外，EvalScope 还提供服务端推理性能测试工具，涵盖吞吐量、响应时延等关键指标，帮助开发者评估模型的部署实用性。

公开课中我们将借助EvalScope进行模型微调前后的性能对比测试。

5.微调所需软硬件环境说明

        大模型微调属于大模型进阶类技术，不同于普通的模型对话或搭建基础应用，微调往往需要一定的软硬件条件支持。

• 大模型微调所需硬件一览

        硬件方面，不同尺寸模型、不同精度微调时所需显存如下：

Qwen3全系列模型微调所需显存一览

        以下是Qwen3系列模型高效微调显存占用预估表：

模型名称	参数量	FP16 微调显存占用	4-bit 动态量化微调显存占用	备注
Qwen3-0.6B	0.6B	~1.2 GB	~0.5 GB	可在低端 GPU 或 CPU 上运行
Qwen3-1.7B	1.7B	~3.4 GB	~1.5 GB	适合入门级部署
Qwen3-4B	4B	~8.0 GB	~3.5 GB	适合中等规模任务
Qwen3-8B	8B	~16.0 GB	~7.0 GB	需要高端消费级 GPU
Qwen3-14B	14B	~28.0 GB	~12.0 GB	可在单张 RTX 4090 上微调
Qwen3-30B-A3B (MoE)	激活参数约 3B	~85.0 GB	暂不支持	激活部分专家参数，资源需求较高
Qwen3-32B	32B	~65.0 GB	~32.0 GB	需要 A100/H100 或多卡并行
Qwen3-235B-A22B (MoE)	激活参数约 22B	~600 GB	暂不支持	超大模型，适合企业级部署，需高端服务器支持

公开课中将采用H800 GPU服务器为大家展示Qwen3 32B 4bit动态量化模型的高效微调流程，同学们可以根据自己实际硬件条件，选取不同模型进行微调，更换不同模型仅需要下载不同模型权重即可，其他流程完全一致。

注1：CPU不能进行微调；

注2：目前MoE模型只支持4bit普通量化微调，暂不支持动态量化微调。

• 操作系统选择

        而操作系统方面，由于绝大多数工业场景下微调会涉及多卡微调，目前只有Linux系统对DeepSpeed和其他多卡并行加速库支持较好，因此绝大多数工业场景下都会使用Ubuntu操作系统或CentOS操作系统。本节公开课我们以Ubuntu系统为例来进行高效微调。

        若无相关软件环境，本节公开课的相关代码也可以在Windows下运行（本节微调示例不涉及多卡并行）。但若想体验更加真实的工业场景下的微调流程，也可以考虑在AutoDL上租赁显卡并配置Ubuntu服务器来完成操作，例如租赁3090显卡，每小时仅需1.5元，可以微调Qwen3-14B 4bit动态量化模型，运行两小时即可得到结果，仅需不到5元即可完成训练：

如何准备微调数据集

Part 1.原理篇

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

        而要手动合并或者创建微调数据集，就必须深入了解微调数据集构造背后的原理。本小节内容，就为大家详细介绍创建微调数据集背后的底层原理。

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

        其实最快速了解构造数据集的方法，是从模型底层原理入手。对于当代大模型来说，普遍需要通过一些特殊字符来标记用户的不同类型输入、系统提示词、以及工具调用或者多模态输入等。而在实际对话过程中，模型对于用户的输入输出是这么进行识别的（以Qwen3为例），一次简答的问答，模型的真实输入和输出如下所示：

其中<|im_start|>代表文本开始，而user则代表消息身份，用于构建多轮对话，而<|im_end|>则代表文本结束，即用户输入结束，而<|im_start|>代表新一段文本开始，assistant代表接下来由模型创建消息，而<|im_end|>同样代表模型创建消息的结束。

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

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

其中的input和output就是输入和输出。例如如下对话：

就可以表示为下列json格式数据集：

JSON   {     "instruction": "",     "input": "输入：你好。",     "output": "输出：你好，有什么可以帮到你的？"   },

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

JSON <|im_start|>user\n你好<|im_end|>\n<|im_start|>assistant\n你好，有什么可以帮到你的？<|im_end|>

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

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

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

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

• 系统提示词（instruction）：你是一名助人为乐的助手。

• 用户输入（input）：你好，好久不见。

• 助手回复（output）：是的呀，好久不见，最近有什么有趣的事情要和我分享么？

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

LaTeX <|im_start|>system 你是一名助人为乐的助手。<|im_end|> <|im_start|>user 你好，好久不见。<|im_end|> <|im_start|>assistant 是的呀，好久不见，最近有什么有趣的事情要和我分享么？<|im_end|>

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

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

JSON tool_schema = [{     "name": "get_weather",     "description": "查询指定城市的天气信息",     "parameters": {         "type": "object",         "properties": {             "location": {                 "type": "string",                 "description": "要查询天气的城市名称"             }         },         "required": ["location"]     } }]

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

• 系统提示词（instruction）：你是一名助人为乐的助手。当用户查询天气的时候，请调用get_weather函数进行天气信息查询。

• 用户输入（input）：你好，请帮我查询下北京天气。

• 助手回复（output）：{"name": "get_weather", "arguments": {"location": "北京"}}

此时回复内容就是一条Function call message

而此时模型真实的输入和输出内容如下：

LaTeX <|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. 带有思考过程的微调数据集结构

        而如果是带有思考链，则一个简单的问答数据如下：

• 系统提示词（instruction）：你是一名助人为乐的助手。

• 用户输入（input）：你好，好久不见。

• 助手回复（output）：好的，用户发来“你好，好久不见！”，我需要回应。首先，用户可能希望得到亲切的回应，所以应该用友好的语气。/n是的呀，好久不见，最近有什么有趣的事情要和我分享么？

此时模型真实的内部输入和输出结果如下：

LaTeX <|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": "北京"}}

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

LaTeX <|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 <think> 好的，用户问北京今天的天气，我应该尝试调用工具 get_weather，并将参数设置为北京。 </think> <tool_call> {"name": "get_weather", "arguments": {"location": "北京"}} </tool_call><|im_end|>

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

4. Qwen3混合推理模型构造微调数据集基本方法

        在了解了微调数据集结构背后的基本原理后，接下来的问题是应该如何构造微调数据集呢？一般来说我们可以在huggingface、ModelScope或llama-factory中挑选合适的数据集，并根据实际情况进行组装。例如围绕Qwen3模型的高效微调，为了确保其仍然保留混合推理能力，我们可以考虑在微调数据集中加入如普通对话数据集FineTome（https://huggingface.co/datasets/mlabonne/FineTome-100k），以及带有推理字段的数学类数据集OpenMathReasoning（https://huggingface.co/datasets/nvidia/OpenMathReasoning），并围绕这两个数据集进行拼接，从而在确保能提升模型的数学能力的同时，保留非推理的功能。同时还需要在持续微调训练过程中不断调整COT数学数据集和普通文本问答数据集之间的配比，以确保模型能够在提升数学能力的同时，保留混合推理的性能。