企业官网建设流程全解析

“三天速通大模型”这个说法，我在不少训练营和大纲里见过。它的真实含义，不是让你三天内从零变成算法工程师，而是让你把一条已经有人走过的路走通：拿到一个开源模型，准备一份数据，在消费级显卡上完成微调，再把模型部署起来跑一个Demo。这条路径本身不难，真正难得的是，大多数教程只给命令，不给背后为什么要这么做的逻辑。结果就是，你照着敲完，模型是能说话了，可一旦任务稍微偏一点，batch size调大一点、数据格式换一种，问题就全来了。

这篇文章想写点不一样的，我尽量按照“三天速通 Qwen 微调”这个目标来拆解，但重点放在那些教程不会提前告诉你、却最容易卡住你的地方：模型版本和硬件的关系、数据格式的真实含义、训练完之后的评测和导出、以及微调、RAG、Agent 这三者到底该在什么场景下配对使用。文章会用一个“最小可行闭环”贯穿始终——先跑通一次完整流程，再逐步加复杂度，最后你手里的不是一堆命令，而是一套能复用的判断标准。

1. 先搞懂微调在整个技术栈里的位置，不要一上来就调参

很多人在动手微调之前，其实还没有回答一个更基本的问题：在这个项目里，微调到底要解决什么问题？这个问题如果不先想清楚，后面绝大多数调参都是无效劳动。

1.1 微调不是“变聪明”，而是“换工作方式”

开源大模型目前已经具备很强的通用能力。你问它写周报、做翻译、整理要点，它都能做。但如果你希望它稳定输出某一种特定格式，或者必须遵循你所在领域的专业逻辑，仅靠提示词往往不够。这时候微调才变得有必要。

换句话说，微调不是让模型变得更聪明，而是让模型适应你的任务偏好。基座模型像一个读过很多书但还没定岗的实习生，微调就是你拿着具体业务手册给他做入职培训。培训不是让他重新学会阅读，而是让他知道，在你这条业务线里，什么话该说、什么格式必须遵守、哪些信息不能被漏掉。

这个理解很重要，因为它决定了你的预期。如果你发现模型微调后，在常识问题上变笨了，那大概率不是微调本身的问题，而是数据配比、超参设置或灾难性遗忘没有处理好。你需要的不是“更好更多的通用知识”，而是平衡。

1.2 在今天的开源生态里，微调只是其中一个选项

有一个问题值得先说清楚：你是不是一定要微调？

如果你想让模型具备最新的文档知识，最适合的方案是RAG；如果你想让模型学会调用工具、反复推理后再给答案，那更适合的做法是Agent框架；如果你只是想让模型说话更像某一个角色的风格，有时候靠一个长提示词就够用。微调的优先级，往往应该排在它们之后，而不是之前。

很多项目的实际任务，是下面这样的混合形态：

• 用户问一个问题。
• 系统先从知识库里检索相关片段。
• 模型把片段整理成答案。
• 如果上下文里涉及工具调用，再触发相应的外部动作。

这种流程里，最值得先尝试的是朴素的RAG链路，用现成的检索库加向量化接口就能搭一个雏形。只有当模型在“回答风格”“结构化输出”“任务指令理解”这几个维度上，怎么试都达不到要求时，才轮到微调出场。

不过，这里也有一个反向场景：如果模型连基本指令都听不懂，即便你用RAG给了完整的上下文，它依然会总结得乱七八糟。这时候先做指令微调，反而能提高全体应用的上限。判断方法很简单：让模型拿一条高质量例子做小样本推理，如果小样本也不行，说明不是提示词的问题，而是模型理解能力的问题，需要微调介入。

1.3 标题里这些高频词，在实战中分别对应什么

标题里挂着一串关键词：Prompt、ReAct、RAG、Agent、QAT、Harness。它们不是平级的概念，实战中是一个层层递进的关系：

• Prompt是基础，负责定义任务输入和输出格式；
• ReAct是推理范式，让模型在思考时能够调用外部信息或工具；
• RAG负责给模型补充外部知识，解决信息过时和专业语料不足的问题；
• Agent是把模型、工具、记忆、执行流程组装成一个可协作的系统；
• QAT是量化感知训练，等模型训练完、准备部署时才会遇到；
• Harness是评测框架，用来判断模型训练完到底变好了还是变差了。

如果你把所有环节铺开看，微调只是中间一环，而不是全部。很多教程把RAG和Agent放在微调里讲，是顺着“大模型应用”这个大主题讲的，不是微调本身必须包含的步骤。你心里先有一个地图，再动手，就不会迷路。

2. 环境准备与模型选型：先把“能不能跑起来”这个门槛跨过去

微调遇到的第一道坎，通常不是算法，而是环境。显卡稍微弱一点，或者模型版本没选对，整个流程都会卡死。

2.1 模型版本和硬件底数，决定你能走多远

在标题里出现了“Qwen3.5”这个叫法。需要先说明一下：目前开源社区里叫 Qwen3.5 的，有可能是某个真实存在的版本，也有可能是社区整理的特殊版型、量化版或者基于Qwen系列二次开发的命名。落地前，最好先去模型托管平台确认有没有对应版本，以及它到底是什么参数量、什么许可协议。不要让一个版本的命名成为你整个项目的假设前提。

如果确认找不到 Qwen3.5 这个明确版本，更稳妥的做法是从你实际能拉到的模型里选一个可用的Qwen系列版本。不管哪个版本，在微调之前，都要先确认三件事：

1. 模型参数量：7B、14B、72B 对显存的要求完全不同。单卡 24G 显存时，7B 级别的模型配合 LoRA 通常是稳妥起步；14B 级别则需要更谨慎地配 batch size 和梯度累积，否则很容易 OOM。
2. 量化状态：如果模型已经是量化版本，比如 GGUF 或 GPTQ，你用普通的训练框架不一定能直接微调，往往需要先把模型转成训练框架支持的格式，或者直接选原生 BF16 权重。
3. 框架兼容性：你用的微调脚本是否支持这个模型架构。如果脚本是基于 Qwen2.5 或 Qwen3 写的，换成 Qwen3.5 后，配置里的模型路径、tokenizer 路径、对话模板可能都要核对一遍。

这里最容易出现的误解是：本地已经能通过 Ollama 跑通模型，就觉得微调环境也没问题。实际不是。Ollama 主要解决的是部署和推理场景，微调需要的是另一套训练链路，包括模型权重、数据加载器、优化器、保存检查点等。两者对显存的敏感度、对驱动和 CUDA 版本的要求也完全不同。

2.2 训练框架与输出目录：先跑通，再谈优化

我比较推荐的实践是把第一次实验目标定成“程序不报错并保存一个检查点”，而不是“效果达到预期”。所以第一次运行时，建议采用最小的参数量和最小的数据规模：

• 关掉或调小验证集评估，避免额外显存开销；
• batch size 先设成 1，通过梯度累积把总batch逼近合理区间；
• LoRA 的秩不要设太大，先按基础配置来；
• 训练轮数先设 1 个 epoch，甚至只跑几百条数据；
• 输出目录单独建一个清晰路径，避免和旧实验混淆。

启动之前，还要确认一个经常被忽略的问题：输出目录有没有写权限？磁盘空间够不够？很多微调脚本会在保存检查点时报错，报错信息不一定直接说磁盘满，只会提示保存失败或训练中断。如果你是一边训练一边跑其他服务，磁盘很快会占满，所以训练前用df -h看一眼空间，是一个非常低成本但高收益的动作。

2.3 一个常见但容易被忽略的认知差：全参微调与 LoRA 对显存的需求差在哪

很多第一次接触微调的人会问：为什么不能用全参微调？答案不是“全参微调不行”，而是资源开销完全不在一个量级。

全参微调要更新模型所有参数，优化器状态、梯度、激活值都会额外占显存。即便是一个7B模型，使用全参微调也可能需要40G以上显存，不是普通单卡能处理的。LoRA 只训练新增的低秩矩阵，冻结底模参数，显存占用大幅下降，所以它才成为个人开发者和中小团队的主流选择。

但 LoRA 也有自己的代价。它改变的是模型在特定任务上的偏好，而不是模型的底层知识图谱。你如果希望模型学会一套非常细的领域规则，LoRA 能学会，但需要数据本身非常充分、一致。训练完之后，LoRA 权重通常需要和基座模型合并，再导成可部署格式。这个导出步骤如果少做，后面部署时模型加载出来的行为会和你预期的完全不同。

3. 微调实操：把它当成一次“最小可行实验”来做

如果你已经把基础环境确认到“能启动训练”这一步，接下来真正决定成败的，不是你敲了多少代码，而是你如何设计数据、设置参数和评估结果。

3.1 数据格式：不同训练框架的约定是什么

项目标题里出现了“Qwen”和“微调实战”，那就必须落到一个具体的数据结构上。不同训练框架的默认格式不完全一样，但有一点是共同的：模型看到的训练样本，不是一段文本，而是一段“指令-输入-输出”结构化的对话。

用最常见的对话式微调来做例子，数据结构大致长这样：

[ { "conversations": [ { "from": "human", "value": "把下面这段客户反馈做情绪分类，只输出“正面”“负面”“中性”。\n反馈内容：等了三天货还没到，客服也不回信息。" }, { "from": "gpt", "value": "负面" } ] } ]

请注意，这里不只是普通的“问题-答案”对。在对话模板里，每个角色都有明确的标识。如果你的训练框架用的是 chat template，那from字段里的角色名要和你模型模板里定义的角色对应上。如果对应不上，模型会把它当成一段普通文本，导致训练失效，但你很难从 loss 曲线里直接看出来。

还有一类常见数据是纯指令格式：

{ "instruction": "提取文本中的时间、地点、人物", "input": "2025年6月，项目组在北京会议室讨论了新方案，张工负责推进。", "output": "时间：2025年6月；地点：北京会议室；人物：张工。" }

数据整理阶段，我建议按顺序检查三件事：

1. 字段名是否和脚本要求一致，比如instruction、input、output，还是conversations、from、value。
2. 每一轮对话是否有结尾标记，很多模板在训练时会自动补上，但如果数据结构里已经有特殊标记，就要防止重复拼接。
3. 训练集和验证集是否重叠，如果验证集里混入训练样本，评测结果会虚高，后续判断模型真实效果时会误判。

3.2 关键训练参数：先理解，再调整

微调脚本里常见参数很多，但重要的其实就一组。第一次训练时，你可以按这个基准去微调：

• learning_rate：一般从 1e-4 到 2e-4 起步，LoRA 用这个范围通常可行。如果 loss 震荡得很厉害，优先降低学习率，而不是先改模型结构。
• per_device_train_batch_size：小显存从 1 开始，配gradient_accumulation_steps来提高有效批次。
• num_train_epochs：数据质量高时，1 到 3 个 epoch 常常够用。训练轮数过多了，模型反而会开始背诵数据，在验证集上表现变差。
• cutoff_len：控制输入序列最大长度。不是越长越好，越长越占显存，而且过长的上下文里往往混着更多无关信息。
• lora_rank：先试用常见值，效果不够再加。秩增大意味着可学习的参数变多，但不一定带来质量提升，还可能导致过拟合。

这里我要提醒一个新手非常容易踩的坑：不要只看 loss 最终降下来了，就觉得训练成功了。loss 降低说明模型在训练集上拟合了，但拟合不代表泛化。真正判断训练效果，必须留出一部分没有参与训练的验证样本，让模型在这部分样本上做预测，再看输出格式、内容正确率、漏报率是否达标。

3.3 训练过程中出现异常，按这个顺序排查

微调过程中遇到报错或奇怪行为，不要急着搜报错信息。按照从现象到底层链条的顺序排查，通常更快：

1. 先看是不是显存不足：显存不足的报错一般很直接，比如 CUDA out of memory。此时优先降低 batch size、缩短序列长度，而不是换一个更大的模型。
2. 再看是不是数据格式问题：如果训练能跑起来，但 loss 不降，检查数据里目标输出是否被正确拼接到模板里，尤其注意特殊 token 和结束符是否缺失。
3. 然后看环境和依赖版本：比如 transformers、peft、accelerate 版本不一致，有时候会导致参数生效顺序错乱，报错信息反而不明显。
4. 再看训练和验证是否共用同一套模板：训练时用的对话模板，和你测试时用的模板如果不同，模型的行为会骤变。
5. 最后检查模型文件和 tokenizer 是否匹配：加载模型时如果 tokenizer 和模型版本不匹配，词表对不上，训练出来的模型很容易出现乱码或生成长度异常。

3.4 Loss 不收敛，很多时候不是模型的问题

有一个高频现象：loss 一直在降，但最后模型输出完全没有按照要求来。这种“训练看似成功、实际没学会”的情况，常见原因包括：

• 数据里大部分内容都一样，模型学到的是平均输出，而不是规律；
• 指令和输出之间没有强关联，模型学不到任务逻辑；
• 数据集中存在大量重复样本，模型只记住了重复内容；
• 目标输出太长，模型在有限的训练步数里无法覆盖。

所以数据质量永远是第一位的。代码、脚本、参数都可以复用，只有数据是你这个任务里最不可替代的部分。

4. 从训练到部署：量化、评测和结构化输出

模型训练好了，还只走到一半。你在训练脚本里看到model已经能回答问题了，不代表它就能被正式部署。

4.1 什么是 QAT，它和普通微调有什么不同

标题里提到的 QAT，全称是 Quantization-Aware Training，量化感知训练。它解决的是一个部署问题：训练好的模型体积可能太大，推理速度也慢，你希望把它量化成更小、更快的版本。普通的训练后量化可以直接把权重从 FP16 转成 INT8 或 INT4，但精度会有损失。QAT 的思路是把量化的误差模拟过程放进训练里，让模型在训练时就学会适配低精度表示。

不理解 QAT 可以，但要理解它的使用时机。日常微调中用 LoRA 训练出来的结果，大多数时候不需要重新做 QAT。只有在极端部署约束下，比如必须在边缘设备、低内存环境里跑模型时，QAT 才是一个值得考虑的选项。如果把微调和 QAT 一起放进“三天速通”的路线，我会建议把 QAT 放到最后一步，先用普通量化和推理速度测试，不够再上 QAT。

4.2 用 Harness 评测，而不是凭感觉判断效果

Harness 在标题里指评测框架。微调后你当然可以和模型聊几句，看看它是不是更听话了。但这种“感觉”不能作为唯一判断依据，尤其是多个实验之间对比时，必须有可复现的评测指标。

一个很实用的做法是：准备一组固定的评测集，把模型的输出存成 JSON 文件，然后再逐一检查：

• 输出格式是否合法，比如 JSON 能不能被解析；
• 关键字段是否缺失；
• 在分类任务上准确率是多少；
• 在生成任务上，回答是否比基座模型更符合业务要求。

如果把评测环节放在训练完立刻做，不仅能看到效果，还能反推数据质量。比如验证集里某一类样本总是出错，说明训练数据里这类样本数量不够或标注不一致。

4.3 导出、加载和部署的常见坑

训完的模型要进入实际使用，通常会遇到三个问题：

一是检查点和最终模型的区别。训练脚本运行时保存的是检查点，里面包含模型权重、优化器状态、训练步数等信息。部署时，通常只导出推理需要的权重。如果你直接加载检查点，有时会因为优化器状态文件过大，加载很慢，甚至报错。

二是LoRA 合并问题。如果你是用 LoRA 训练，部署前需要把 LoRA 权重合并回基座模型。不合并，每次部署都要额外带一个 adapter 文件，而且有的推理框架不支持动态加载 LoRA。

三是对话模板不匹配。训练时用的提示词模板和部署时用的模板如果不一致，用户在应用里输入的话，模型可能不理解。这也是最隐蔽的问题，因为它不报错，只是回答质量变差。

如果你计划用 Ollama 来跑本地服务，一个常见路径是：先把模型合并成完整权重，然后转换成 GGUF 格式，再通过 Ollama 导入。注意，这个转换过程不是省略步骤的“一个命令搞定”，中间要确认输出路径、GGUF 分片大小和模板配置都对。

5. 微调不是唯一解：和 RAG、Agent、ReAct 的配合边界

前面说过，微调在整条链路里只占一环。这里需要再展开一点：当你做完一次微调后，会发现它和 RAG、Agent 不是互斥的，而是经常搭配使用。

5.1 微调解决“表达和控制”，RAG 解决“知识和更新”

如果你的业务知识会持续更新，比如产品手册每月变一次，那你每个月都去微调一次模型既不现实，也没必要。更好的是把最新文档放进一个向量库里，用 RAG 的方式让模型在回答前先检索相关内容。

微调和 RAG 的边界大致是：

• 当你想让模型“稳定以专业口吻回答”，微调有效；
• 当你想让模型“回答最新问题”，RAG 有效；
• 当两个问题纠缠在一起时，先做 RAG 链路，再做微调优化效果。

RAG 落地时的切块策略，是很多人容易忽略的关键点。块太长，检索出来的信息可能会夹杂很多无关内容；块太短，又可能让模型缺乏足够的上下文来判断。常见的做法是先用固定长度切分，再根据文档结构做小节切分，最后在验证集上比较检索命中率。你做微调时的验证集，也可以用来测试 RAG 系统最终输出的整体质量。

5.2 ReAct 与 Agent 在什么场景下才需要

ReAct 是一种让模型“先思考、再行动、再观察结果”的范式。Agent 则是承载这个范式的一套更完整的系统，通常包含模型、工具列表、记忆和循环执行机制。

直接说一个经验：如果任务只是单轮问答，RAG 通常已经够用，Agent 反而会带来延迟和不确定性。但如果你期望模型能够完成多步任务，比如查天气、订日程、写邮件，那单靠提示词无法稳定做对，这时 ReAct 和 Agent 就体现出价值。

微调和 Agent 的关系，我建议这样理解：微调可以增强模型理解指令和输出结构化内容的能力，但 Agent 的主要复杂度在编排逻辑、工具定义和异常处理上。比如 Agent 调用工具后返回了一个错误，模型有没有能力从错误里恢复？这是 Agent 框架需要解决的，不是模型微调几次就能自动获得的。微调的数据里如果都只是“成功路径”的样本，模型训练完倒可能更不擅长处理异常情况。

5.3 一个可复用框架：先补知识，再调行为，最后编排任务

如果你正在规划一个大模型应用，我建议按以下顺序判断：

1. 任务是否需要最新知识：需要，先做 RAG。
2. 任务是否需要特定输出风格或格式规则：需要，再考虑微调。
3. 任务是否需要多步工具调用：需要，再引入 Agent。
4. 任务对延迟和成本是否敏感：敏感，优先量化、剪枝、蒸馏，把 QAT 放到最后。

反着读这个框架同样有意义：一上来就搭 Agent 或者做微调，往往会在走不通之后才意识到，其实大部分问题出在知识没有补全、指令没有设计好。大模型应用的项目失败，通常不是因为模型能力不够，而是因为系统设计没有匹配任务需求。

6. 三天速通的真正含义：用最小闭环建立工程直觉

再回到“三天速通大模型”这个标题。三天能不能速通？从“能复现一条完整流程”这个目标来看，可以。从“理解每个环节的边界和长期风险”这个目标来看，三天远远不够。但这两者之间不是对立的，先完成前者，才能为后者积累真实的工程直觉。

6.1 什么叫“最小可行闭环”

在微调这个场景里，最小可行闭环可以这样定义：

• 你可以从平台下载一个开源模型；
• 准备一份几百条到几千条的结构化训练数据；
• 用 LoRA 方法跑通一次训练；
• 验证模型在固定评测集上的效果；
• 导出合并权重，并在本地的推理服务里完成一次真实调用。

只要能把这个闭环跑通，你就已经超越了绝大多数停留在“看过教程”的人。接下来再往里面加东西，比如更复杂的 RAG、Agent 工具调用、QAT 量化部署，每一次增量都建立在一个你已经验证过的基座上，问题会更可控。

6.2 先跑通，再优化，最后工程化

这是我反复说的一句话，但值得再展开。在训练初期，“跑通”的定义不是效果完美，而是“程序不报错、检查点能保存、推理结果能拿到”。在这个阶段，宁可牺牲参数量、训练时长、数据量，也要确保整个链路是通的。因为一旦链路断了，你很难判断问题出在数据、参数还是代码版本上。

当你把链路跑通，接下来才是调参和优化。常见的优化方向包括：

• 基于验证集表现调整学习率和 LoRA 秩；
• 增加更多高质量样本，而不是盲目扩充数据量；
• 把训练脚本参数抽成配置文件，方便重复实验；
• 把评测结果记录成表格，方便多个实验横向对比。

最后一步“工程化”，是把工作流固化下来的过程。比如把训练数据校验、训练启动、模型导出、部署上线写成一个可重复运行的脚本，每次只需要修改文件路径和关键参数。这实际上也是长期价值所在：你不再依赖一次性的“手感”，而是依赖一套可复现、可迭代的流程。

6.3 标题里的“Prompt、ReAct、RAG、Agent、QAT、Harness”怎么串起来读

这篇文章写到这里，你已经能看出，这些关键词不是等价的，它们是一条应用链上的不同位置。

• 先有 Prompt，定义任务；
• 再通过 RAG 补知识；
• 如果有工具调用需求，用 ReAct 编排思考过程，用 Agent 搭建系统；
• 如果模型效果不达标，用微调调行为；
• 部署时，如果需要更小更快，再考虑 QAT；
• 最后，用 Harness 评判整条链路是否真的变好了。

微调的经验不是孤立的。你越能理解它在整条链路中的位置，就越能判断什么时候该做、什么时候不该做，以及做完之后应该怎么评估。这件事，要比单纯熟练记几条训练命令重要得多。

如果你真的只有三天，我建议第一天把最小闭环跑通，第二天做一轮数据清洗和微调，第三天把模型放到一个简单的 RAG 场景里验证端到端效果。跑完之后，你大概就能亲手体会到：真正决定大模型项目成败的，绝对不是技术方案有多酷，而是你对数据、边界和流程的控制有多扎实。