企业官网建设流程全解析

大模型微调这几年几乎成了 AI 工程师的必修课。手里有一个开源基座模型，跑通用问答没问题，但要它按照你公司的口径回复业务问题、输出固定格式的分析报告、处理某个垂直场景的专业术语，它立刻露怯。把通用能力变成特定领域的可用能力，就是所谓的“最后一公里”，干这件事最常见的方式就是大模型微调。这篇文章不聊空泛的概念，核心是把这个过程拆透：什么时候该微调、三种训练路线怎么取舍、数据怎么准备、环境怎么搭、实战怎么跑、模型怎么部署上线，最后附上我自己踩过的坑。

不管你是刚入门的算法工程师，还是正在做企业 AI 项目的开发负责人，按这个路径走一遍，心里基本就有谱了。

1. 先说清楚：微调到底在解决什么问题

1.1 基座模型是“通才”，但不是你的“专才”

基座模型，比如 Qwen、Llama 这类开源大模型，在训练阶段见了海量通用文本，所以它知道很多东西，逻辑推理、文本总结、翻译、代码生成都拿得出手。但它的“知道”是泛化的，没有经过某个具体行业的定向强化。举个例子：你跟通用模型说“帮我写一份设备故障记录”，它能写，但格式大概率不是你所在行业的标准格式，里面的故障等级、影响范围、处理建议这些字段，它不会严格按你的规范来。甚至一些行业黑话它会理解偏。

这就是通才和专才的差距。专才是被“调教”过的——通过微调，把模型的输出分布向你的业务场景倾斜。微调的本质是继续训练，用你的高质量数据刷新模型的一部分权重，让它从“什么都会一点”变成“你要求的活干得漂亮”。

1.2 遇到问题别急着微调：先分清提示词、RAG 和微调的边界

很多人一上来就问“我这需求该怎么微调”，但实际评估之后发现根本不需要微调。判断该不该微调，先看三个问题：你的知识是否经常变化、你的任务是否对格式有强要求、你手里的数据量是否足够。

如果任务是开放问答，知识来自公司内部文档，那优先考虑 RAG（检索增强生成）。把文档切片、向量化、检索出来塞进上下文，让模型基于检索结果回答。RAG 的好处是知识可以随时更新，不用重新训练模型。

如果只是想让模型按特定口吻、特定行为方式输出，可以先试提示词工程。把规则写清楚、给几个 few-shot 示例，大概率能解决六成问题。

什么时候才轮到微调？典型场景有三类。第一，输出格式高度固定，比如从病历文本中抽取结构化要素、把口语转成标准工单，提示词再怎么调也有漏字段的问题。第二，行业术语密集且含义特殊，通用模型搞不懂。第三，推理链有固定的领域逻辑，比如风控审核规则，光靠提示词难以稳定复现。这时候微调能把模型的行为“焊死”在正确路径上，成本虽比提示词高，但效果稳定、推理时几乎不增加额外开销。

2. 全参、LoRA、QLoRA：三条技术路线怎么选

2.1 全参微调：效果上限高，但门槛也高

全参微调（Full Fine-tuning）是让模型所有层的权重都参与梯度更新。理论上效果上限最高，因为模型适配空间最大。但代价极其现实：显存需求大，7B 模型用全参微调，即使 batch size 很小，也至少要 60G 以上显存；数据需求也高，动辄上万条高质量数据才不容易过拟合；训练时间长，大模型全量更新一轮的成本普通团队扛不住。

除非你有 A100/H100 级别的资源，或者做的是学术研究要探查模型能力上限，否则我不建议业务场景一上来就全参。

2.2 LoRA 和 QLoRA：多数人的务实之选

LoRA（Low-Rank Adaptation）的核心思路是冻结原模型权重，只训练注入的少量低秩矩阵。你可以把它理解成给模型加了一个“小外挂”，不动原厂发动机，只额外装一个调校模块。训练参数量通常只有全参的 1% 左右，显存和训练时长都大幅下降。

QLoRA 则更进一步：先把基座模型量化到 4-bit，再在此基础上做 LoRA。效果会有轻微损失，但显存需求能压到很低。我自己实测下来，一个 7B 模型用 QLoRA 训练，16G 显存就能跑得动，消费级显卡有戏。LoRA 和 QLoRA 在绝大多数业务场景中，效果和全参的差距并没有想象中那么大，尤其是数据量只有几千到几万条时，LoRA 甚至更不容易过拟合。

2.3 LoRA 参数怎么定：rank 和 alpha 的选择

LoRA 里最常调的两个参数是 rank（秩）和 alpha（缩放系数）。rank 决定低秩矩阵的维度，通俗说就是“外挂模块的容量”。rank 太小，模型记不住领域规则；rank 太大，训练慢且容易过拟合。实践经验是：7B 模型做指令微调时，rank 取 16 到 64 之间基本够用；数据量小、任务简单，可以用 8；数据量大、任务复杂，才考虑 64。

alpha 是缩放系数，一般取 rank 的 1 到 2 倍。alpha 太大会导致微调权重占比过高，破坏基座模型的通用能力，训完之后模型会“变傻”；太小则微调效果不明显。通常 rank=16 配 alpha=32，rank=64 配 alpha=128，这个组合在多数项目里都很稳。

3. 数据准备：一个微调项目的命根子

3.1 指令数据集的格式：先搞懂对话模板

微调数据要组织成“指令-期望输出”的配对。不同训练的框架目标格式略有差异，但大方向一致。LLaMA-Factory 支持的标准格式大致是这种：

[ { "instruction": "根据患者主诉，抽取症状、持续时间和就诊建议，以 JSON 格式输出。", "input": "患者近一周反复出现头痛、鼻塞，午后加重，自行服用布洛芬效果不佳。", "output": "{\"症状\": [\"头痛\", \"鼻塞\"], \"持续时间\": \"一周\", \"就诊建议\": \"建议耳鼻喉科就诊，完善鼻内镜检查\"}" } ]

input 可以为空，也可以放上下文材料。多轮对话类数据则要用 conversations 结构，把历史对话原文逐条放进去。

有一点要当心：基座模型各有各的对话模板，比如 Qwen 有 chatml 模板，Llama 有自己的系统提示格式。LLaMA-Factory 会自动套用对应模板，但如果你自己写训练脚本，漏掉模板会导致模型训练时上下文结构错乱，部署后对话语无伦次。所以新手优先用成熟的训练框架，不要自己手搓数据加载和模板拼接。

3.2 数据清洗与去重：脏数据比数据少更致命

我见过不少项目，模型训完效果反而退化，查到最后是数据没洗干净。数据清洗的核心是四件事：去重、过滤、纠错、对齐。

去重要做两层。一层是重复样本去重，同一条数据在文件里出现多遍，会被放大学习，导致模型过度拟合到某几条样本；另一层是近似去重，用文本相似度或 embedding 距离把语义重复的数据筛掉，避免训练集里全是同一类问题。

过滤要筛掉：输出非常简短或者直接是空的数据；带大量乱码、表情符号、无关 HTML 的数据；明显标注错误的 pair。还有一个容易被忽略的点：输出里不能带“根据以上内容，我们可以总结为”这类模型常见废话，微调完模型会把这套废话腔学进去。

纠错主要针对格式问题。比如要求模型输出 JSON，但数据里部分输出是普通文本加解释，模型学到的是“有时输出 JSON，有时解释”，推理时就不稳定。这种要统一格式再进训练集。

对齐指的是指令的多样性。指令不要全是同一个句式，要模拟真实用户的表达变化。比如“抽取症状”“提取一下症状信息”“这里面有哪些症状”都要出现，模型才能学到意图背后的任务，而不是死记句式。

3.3 多少条数据才够：没有标准答案但有经验区间

很多人问微调至少要多少条数据。我给一个实战经验区间：任务模式单一、规则明确的任务，比如固定抽取某个字段，500 到 2000 条高质量数据就能看到明显变化；需要模型学会一种写作风格或复杂推理链，建议 5000 到 20000 条；如果几万条数据训完效果差距仍然很大，大概率是数据质量或任务定义有问题，而不是数据不够。

不要盲目堆量。有一类错误是数据量堆到几万条，但里面一半是低质量生成数据。宁可要 3000 条人工精标数据，也不要 3 万条粗制滥造的合成数据。数据质量的权重在实战中永远高于数量。

4. 环境配置与工具选型：先搭好能跑的台子

4.1 训练框架怎么选：LLaMA-Factory 对新手最友好

现在微调工具有很多选择。原生的 Hugging Face transformers + peft 库，灵活度最高，适合要定制训练逻辑的开发者，但代码工作量大。Axolotl 配置灵活，很多海外项目在用，只是文档对中文支持不够友好。我的建议是新项目直接用 LLaMA-Factory，它把这些工具整合得很干净，支持数据集管理、多模型模板、LoRA/QLoRA 一站式跑通，而且命令行和 Web UI 都有。

我自己在多个项目里用 LLaMA-Factory 跑微调，从 Qwen2.5-7B 到一些小模型变体，过程都比较顺。最大的好处是模型模板覆盖全，不用自己拼 tokenizer 和对话模板，极大减少了“环境对不上、模板出错”这类问题。

另外提一句：如果你需要做视觉模型微调，比如多模态数据或者图像描述任务，也可以先看 LLaMA-Factory 是否支持该模型结构。现在它对常见的多模态基座模型也有适配。专业场景下，比如目标检测模型微调，那就还是要回到 Detectron2、MMDetection 这类专用工具里，不要硬套大语言模型框架。

4.2 依赖版本匹配：CUDA、PyTorch、Transformers 的坑

环境配置最常见的坑是版本不匹配。基本原则是：先定 PyTorch 版本，再定 CUDA 版本，最后向外扩展安装其他依赖。

举个例子，如果你使用 RTX 4090 或更新显卡，建议装 CUDA 11.8 或 12.1 对应的 PyTorch 2.1 左右版本。如果显卡较老、显存 8G 甚至 6G，那目标就不是跑 7B，而是用 1.5B、3B 这类小规模的模型。安装命令一般都通过 PyTorch 官网生成，不要手动在 PyPI 里乱装，否则常见的错误是“CUDA 不可用”“算子编译失败”。

Transformers、peft、bitsandbytes 也要尽量选兼容组合。经验做法是：在 LLaMA-Factory 的 requirements.txt 基础上直接用pip install -r requirements.txt装，它锁定的版本经过团队测试，比你自己一个个装稳得多。

提示：遇到 CUDA out of memory 不一定是环境问题，也可能是 batch size 和模型规模不匹配。先看报错是显存不足还是算子不兼容，两个问题处理方向完全不同。

4.3 显存到底怎么估算：一个简单的账本

很多人问我：我的显卡能不能跑 7B 微调？我给你一个估算口径：模型权重本身占大头，LoRA 训练时还需要存梯度、优化器状态和激活值。7B 模型即使做了 4-bit 量化，峰值显存也差不多要 14G 左右；如果加载 16-bit 权重做 LoRA，峰值会到 20G 以上。

实际项目里，我用 16G 显存的显卡跑 Qwen2.5-7B QLoRA 是可以完成的，但 batch size 要调小到 1，梯度累积适当加大。如果你的显卡只有 8G，那务实的选择是用 1.5B 或 3B 级别模型，或者只做推理不做训练。别硬扛，硬扛的结果是频繁 OOM 中断，浪费的是自己的时间。

5. 从零跑通 Qwen2.5-7B 微调：完整实操记录

5.1 准备数据集和训练配置

我用一个“医疗病历要素抽取”的实战案例来说明，数据量选了 3000 条，任务是从病历文本里抽取患者症状、用药情况、既往病史，并输出结构化 JSON。数据集文件放到 LLaMA-Factory 的data目录下，然后在dataset_info.json里注册数据集名称：

{ "medical_ner_dataset": { "file_name": "medical_ner.json", "formatting": "alpaca", "columns": { "instruction": "instruction", "input": "input", "output": "output" } } }

训练命令我用llamafactory-cli直接跑，参数如下：

llamafactory-cli train \ --model_name_or_path Qwen/Qwen2.5-7B-Instruct \ --dataset medical_ner_dataset \ --template qwen \ --stage sft \ --finetuning_type lora \ --quantization_bit 4 \ --lora_rank 16 \ --lora_alpha 32 \ --output_dir outputs/medical_ner_7b_lora \ --num_train_epochs 3 \ --per_device_train_batch_size 1 \ --gradient_accumulation_steps 8 \ --learning_rate 2e-4 \ --lr_scheduler_type cosine \ --max_source_length 1024 \ --max_target_length 512 \ --logging_steps 10 \ --save_steps 500 \ --fp16

这几个参数背后是有考量的。per_device_train_batch_size=1是因为显存有限，很小；用gradient_accumulation_steps=8等效出 batch size 8 的更新效果。learning_rate=2e-4是 LoRA 比较稳妥的起点，QLoRA 有时还可以略高一点，但太高容易让 loss 震荡。max_source_length=1024是根据业务输入长度估算的，太长浪费显存，太短会截断关键信息。

5.2 训练过程监控：loss 该降到多少才合理

启动训练后，不要只盯着它跑。关键要看 loss 曲线。我这里跑 3 个 epoch，前 500 步 loss 从 1.8 左右快速下降到 0.6 左右，之后下降速度放缓，到 1500 步之后基本在 0.3 附近震荡。这个形态就对了。

如果 loss 从一开始就非常低，比如 0.05 以下，要警惕是不是数据里有大量重复样本，模型在背答案而不是学规则。如果 loss 训完还在 1.0 以上，先检查数据质量，而不是急着加 epoch。训练过程中建议每 500 步保存一个 checkpoint，这样如果最后一个 checkpoint 过拟合了，还能回退到中间的版本。

5.3 训练后先做静态评估：别急着部署

训练完成后，别急着合并部署，先做一轮静态测试。用测试集里没参与训练的数据，加载 LoRA 权重做推理，人工检查输出格式和内容正确率。

我一般会跑 50 到 100 条盲测样本。输出全部能解析为合法 JSON、关键字段抽取准确率达到 90% 以上，才认为这次微调基本合格。如果输出格式偶尔错乱，优先怀疑对话模板不对；如果关键词经常抽取成同义表述，比如把“头疼”抽成“头痛”，优先检查数据里标签词汇是否统一。

6. 模型部署与效果展示：微调完要能真正上线

6.1 合并 LoRA 权重：让模型变成完整的可用模型

LoRA 训练完得到的只是增量权重，直接拿这个权重做推理比较麻烦，通常要把它合并回基座模型。LLaMA-Factory 提供了一行命令：

llamafactory-cli export \ --model_name_or_path Qwen/Qwen2.5-7B-Instruct \ --adapter_name_or_path outputs/medical_ner_7b_lora \ --template qwen \ --finetuning_type lora \ --export_dir models/medical_ner_7b_full \ --export_size 4 \ --export_legacy_format false

合并之后，models 目录下就是一个完整的、可以直接推理的模型文件夹，包含 config、tokenizer 和模型权重。这一步有两个作用：一是方便后续用各种推理框架加载；二是避免上线时还要维护两个权重文件的对应关系。

6.2 部署方式对比：vLLM、Ollama、llama.cpp 各有定位

微调完成的模型部署主要看场景。在线服务、高并发、需要低延迟的场景，推荐 vLLM。它支持连续批处理、PagedAttention，吞吐量在主流框架里领先，一套 GPU 服务能扛更多请求。中小团队、个人电脑、内部工具演示，推荐 Ollama + GGUF 格式。先把合并后的模型转成 GGUF，再放到 Ollama 里，一条命令就能起服务。

如果你的最终产品是手机 App 等端侧场景，那更要走 GGUF 路线。现在不少端侧推理引擎支持 Android 集成 GGUF 模型，把模型压缩量化到 4-bit 后，一部中端手机也能跑得动。我一般用 llama.cpp 的convert_hf_to_gguf.py转换脚本，先从 Hugging Face 格式转 GGUF，再用llama-quantize做 Q4_K_M 量化：

python convert_hf_to_gguf.py models/medical_ner_7b_full --outfile models/medical_ner_7b.gguf --outtype f16 ./llama-quantize models/medical_ner_7b.gguf models/medical_ner_7b_Q4_K_M.gguf Q4_K_M

6.3 输出格式的最后一环：流式输出与中断处理

部署上线时还有个细节，我见过很多团队栽在这里：前端页面向模型请求回答，用的是普通的一次性 HTTP 请求，结果大模型生成时间太长，用户刷一下就超时。正确做法是用 SSE（Server-Sent Events）做流式输出，把模型生成的 token 逐段推给前端，用户看到的是“打字机”一样的效果，体验好很多。

同时要注意中止请求。用户点击“停止生成”时，前端要能主动 abort 请求，后端也要捕获到客户端断开连接的事件，及时取消生成任务，否则 GPU 资源会被无效请求白白占住。这个在 vLLM 里可以通过异步生成器和客户端 disconnect 检测配合实现。部署方案虽然看起来只差这一步，但在真实产品里体验差距是肉眼可见的。

7. 常见问题与排查技巧实录

7.1 训练崩溃的典型症状

我在多个项目里遇到过的崩溃场景，基本逃不出下面几个原因。最经常出现的是 OOM（显存不足）。解决方向只有三个：换更小的模型、用 4-bit 量化、减小 batch size 或max_length。其中max_length是最容易被忽视的，它直接影响激活值显存占用，从 2048 改到 1024 往往立竿见影。

第二个是 loss 变成 NaN（不是数字）。常见原因是学习率过大或数据里有 NaN 值。检查数据集里是否有空字段、全数字文本、极长的异常样本；实在不行把学习率从 2e-4 降到 1e-4。第三个是训练过程被中断，比如机器掉电、显存波动。我的习惯是开启自动保存 checkpoint，并选择训练框架中带断点续训功能的脚本。

7.2 微调灾难：模型变傻、胡言乱语怎么办

一个让很多人崩溃的现象是：微调完之后，通用问答能力明显下降，甚至开始输出无意义内容。这就是灾难性遗忘。处理办法有几种。第一，把学习率调低，LoRA 场景下 2e-4 已经不算低，有些敏感任务要降到 1e-5。第二，减少 epoch，很多任务 2 到 3 轮足够，训练轮数过多直接导致过拟合和遗忘。第三，在训练数据中混入一定比例的通用数据，比例可以控制在 10% 左右，保住模型的“通才”底座。

还有一类问题：不是完全变傻，而是输出风格不对，比如总是用训练集里的固定开头。这是数据多样性不足，回到第 3 章，重新扩充指令的句式多样性。

7.3 效果没提升：先检查数据，再检查评估方法

很多人微调完之后，拿测试集一测，发现准确率跟基座模型比没有明显提升，于是怀疑是框架问题或者模型问题。实际上绝大部分情况是数据或评估方式的问题。

先看测试集是否跟训练集分布太大。如果测试数据里的术语、句式是训练集里完全没出现过的，模型泛化不出来，那是数据覆盖问题。再看评估指标是不是太粗。比如抽取任务，你用“整个 JSON 完全匹配”当唯一指标，模型只要多一个空格就算错；应该拆成字段级准确率和召回率来评估。还要确认你是不是真的把 LoRA 权重加载进来了。我碰到过几次所谓“效果没变化”，查到最后是推理时只加载了基座模型，没加载 adapter。

提示：微调后效果评估一定要用“模型在训练时没见过的样本”。如果把训练集又拿回去测，过拟合模型也会给你一个虚高分数，误导你继续堆 epoch。

7.4 消费级显卡用户特别关心的两个问题

有朋友问，RX6750GRE 这种显卡能不能训练？这类显卡的显存通常在 12G 左右，性能上可以做 QLoRA，但要注意训练框架对 AMD 显卡的支持不如 NVIDIA 那么顺畅。如果你主力就是 A 卡，建议优先用支持 ROCm 的框架和 PyTorch 版本，并且提前做好“某些算子不兼容”的心理准备。最省事的替代方案是：把数据准备好，在云上租一张 4090 或 A100 跑训练，本地只做推理部署。很多个人项目其实没必要在本地死磕训练环境。

另一个高频问题是“Qwen3-0.6B 这种小模型值得微调吗”。我的回答是：值得，但要控制预期。0.6B 模型参数量小，擅长做单一、规则明确的抽取或分类任务，内存占用低，部署容易。但你指望它做复杂推理或者长文写作，那是强人所难。小模型微调的核心是任务足够简单、数据足够干净。

我在做完十几个微调项目之后有一个很深的体会：微调本身并不难，难的是把数据、参数、评估、部署这一整条链路都考虑周全。任何一个环节偷懒，最后都要在效果和返工上付出代价。如果这篇文章只能留下一句话，那就是：开始之前，先把你想要模型学会的“专才能力”定义清楚，再动手准备数据。数据对了，后面每一步都是顺水推舟；数据错了，后面每一步都是给自己埋坑。