1.1 开源模型微调的概念、典型场景与路线选择
我最早接触开源模型微调那会儿，脑子里其实是一团浆糊。后来折腾了几个项目才慢慢摸清楚，微调这件事说白了就是拿一个已经训练好的大模型，用你自己的数据再“教”它一遍，让它更懂你的业务、更贴合你的说话方式。打个比方，基座模型像个刚毕业的高材生，啥都懂一点，但你让他直接上手你们公司的客服话术，他肯定露怯。微调就是给他做岗前培训。这个过程中，模型原有的通用能力不会丢，它只是在你的领域数据上做了针对性调整。我见过不少朋友一上来就想从零训练模型，说实话，没几千万预算和几十张卡，这条路基本走不通。开源模型微调才是大多数团队能落地的那条路。
典型场景这块，我自己的体会是三类需求最集中。一类是垂直领域知识注入，比如医疗问答、法律咨询、金融研报生成，通用模型在这些领域经常一本正经地胡说八道，微调之后准确率能拉上来一大截。另一类是风格对齐，你希望模型输出的语气像你们品牌的调性，或者像某个特定角色的口吻，这种需求靠提示词工程能解决一部分，但稳定性远不如微调。还有一类是任务专用，比如把模型训练成专门做信息抽取、专门做代码补全的“偏科生”。我做过一个电商评论情感分析的微调项目，基座模型直接跑准确率只有六成多，微调之后稳定在九成以上，差别非常明显。
路线选择上，我踩过坑也尝过甜头。全参数微调效果上限高，但显存吃紧、训练慢、容易过拟合，小团队根本扛不住。我现在基本都走参数高效微调这条路，LoRA是主力方案，它只训练一小部分附加参数，显存占用能降一个数量级，效果在多数场景下和全参微调差不了太多。选择路线的时候我会先问自己三个问题：数据量有多大、算力预算有多少、对效果的要求有多苛刻。数据量几千条、预算有限、效果要求不是极致，LoRA闭眼选。数据量几十万条、有A100集群、追求榜单指标，那再考虑全参微调或者继续预训练。这个判断逻辑帮我省了很多冤枉钱。
1.2 开源模型微调数据集制作方法：任务定义与数据采集
任务定义这一步，很多人急着跳过去，结果后面返工返到怀疑人生。我的习惯是先把“模型输入什么、输出什么、什么算对什么算错”用一句话写清楚。比如“输入一段用户投诉文本，输出投诉类别和情绪等级”，这句话看起来简单，但它决定了你后面采什么数据、标什么标签、怎么评估。我做过一个项目，一开始任务定义含糊，数据采回来发现一半样本根本没法用，白白烧了两周时间。任务定义还要考虑边界情况，用户输入跟任务无关的内容怎么办、输入超长怎么办、输出格式允不允许自由发挥，这些提前想清楚，数据采集才有靶子。
数据采集的来源我一般分三路走。第一路是业务系统里的真实数据，质量最高、最贴合场景，但往往涉及隐私清洗和脱敏，量也不一定够。第二路是公开数据集，Hugging Face上能淘到不少宝贝，拿来补充长尾场景很好用，缺点是风格跟你的业务可能对不上。第三路是人工构造或者用更强模型合成，我常用GPT-4这类模型批量生成种子数据，再人工筛选修正。这三路数据我通常会混着用，真实数据打底、公开数据扩面、合成数据补缺。采集的时候我会刻意保持场景多样性，别全是一个模板套出来的，不然模型学到的只是表面模式。
采集量的问题我被问过无数次。我的经验是，分类任务每个类别至少几百条，生成任务上千条起步，复杂推理任务可能得上万。但这个数字不是绝对的，数据质量远比数量重要。我见过用八百条精标数据微调出来的模型，比用八千条脏数据训出来的效果好一大截。采集过程中我会边采边看，隔几天抽一批出来人工过一遍，发现分布偏了就赶紧调整采集策略。这个反馈循环特别重要，等全采完再发现问题，沉没成本就太高了。
1.3 数据清洗、标注规范、指令格式转换与质量评估
数据清洗是个体力活，但偷懒的代价很大。我拿到原始数据第一件事是去重，精确去重和近似去重都要做，重复样本会让模型过拟合到那几条数据上。然后是去噪，HTML标签、乱码、特殊符号、超长空白，这些都得清掉。还有一类隐性噪声是“看似正常但实际无意义”的样本，比如客服对话里大段的“您好”“请问还有什么可以帮您”，这些对训练没贡献，反而稀释信号。我一般会写几个正则脚本批量处理，再抽样人工检查。清洗完的数据量通常会缩水两三成，这很正常，别心疼。
标注规范这块，我的原则是“傻子看了都能标对”。规范文档里要把每个标签的定义、正例、反例、边界情况都写清楚，最好配上标注界面截图。我吃过亏，规范写得太抽象，三个标注员标出来的结果一致性只有七成，返工重标差点把项目拖垮。后来我改成先标一百条做校准，大家坐一起对分歧、统一口径，校准通过了再全量开标。标注过程中我还会设置抽检机制，每天随机抽百分之十复查，发现偏差及时纠正。标注员也是人，标久了会疲劳、会走神，抽检能兜住大部分问题。
指令格式转换是微调数据准备里技术含量比较高的一步。开源模型微调通常要求数据转成特定的对话格式，比如Alpaca格式、ShareGPT格式，不同基座模型吃的格式还不一样。我一般会写一个转换脚本，把清洗好的数据统一映射成目标格式，字段名、角色标记、分隔符都对齐。转换完一定要做格式校验，我写过一个检查清单：字段是否齐全、角色是否合法、有没有空回复、长度是否超限。质量评估我会从三个维度看，一是人工抽检准确率，二是用一个小型评估集跑基座模型看基线表现，三是检查数据分布是否均衡。这三个维度都过关了，数据才算能进训练流程。
1.4 数据集划分、版本管理与合规注意事项
数据集划分看起来简单，其实有讲究。我一般按训练集、验证集、测试集8:1:1来分，但划分的时候要注意不能有数据泄漏。什么叫泄漏？同一个用户的两条相似评论一条进了训练集一条进了测试集，模型在测试集上表现虚高，上线就露馅。我的做法是按实体或者按时间划分，比如按用户ID分组划分，保证同一个用户的数据只出现在一个集合里。时间序列数据就按时间切，用前面的数据训练、后面的数据测试，这样更接近真实上线场景。划分完我会检查一下三个集合的标签分布是否一致，偏得太厉害就重新分层采样。
版本管理这件事，数据量小的时候觉得多余，数据一多就救命了。我给每个数据集版本打三个标记：数据来源、清洗脚本版本、标注规范版本。用DVC或者Git LFS管理大文件，每次改动都留commit记录。有次训练效果突然掉点，回溯发现是有人偷偷换了一批标注数据没通知，要是没有版本记录，排查能查到天荒地老。我还会给每个版本配一个数据卡片，写清楚样本量、类别分布、已知问题、适用场景，团队里谁要用数据先看卡片，省了很多沟通成本。
合规这块我得重点说几句。开源模型微调的数据来源必须干净，版权、隐私、授权三座大山一个都绕不过去。公开数据集要看清License，有些只允许研究用途，商用会踩雷。业务数据要做脱敏，手机号、身份证号、地址这些敏感信息该删删该替换替换。合成数据要注意基座模型的服务条款，有些模型明确禁止用它的输出去训练竞品。我现在的习惯是每个数据集都附一份合规检查表，来源合法性、脱敏处理、授权范围逐项打勾，宁可麻烦一点，也别给后面埋雷。数据是微调的地基，地基不稳，上面盖得再漂亮也白搭。
2.1 环境搭建、基座模型选型与依赖管理
环境搭建这块，我建议你别一上来就装一堆东西。我自己的习惯是先确定显卡型号和驱动版本，再倒推CUDA版本，然后才去选PyTorch。这样做的好处是依赖链条清晰，不会出现装完torch发现跟系统CUDA打架的情况。conda建一个干净环境是最省心的做法，Python版本我一般锁在3.10或者3.11，太新太旧都会遇到一些包不兼容的破事。flashattention、bitsandbytes、peft、transformers这几个核心库我会把版本号写死在requirements文件里，别偷懒用latest，开源库的版本漂移能让你调试到半夜。
基座模型选型我踩过不少坑。参数规模上，7B到13B是LoRA微调最舒服的区间，单张24G显存能跑，效果也够用。再往上到70B，即使用量化加LoRA，显存压力也不小，推理部署成本更是个问题。模型架构我优先看Llama系和Qwen系，社区资源多、踩坑的人多、遇到问题搜得到答案。中英双语场景我会偏向Qwen，纯英文或者代码任务Llama系生态更成熟。还有一个细节是tokenizer的词表大小，词表越大嵌入层参数越多，小数据集微调时这部分没必要训练，我会在配置里冻结掉。
依赖管理我要多说一句，真的太多人栽在这上面了。我现在的做法是每次新建项目都生成一份完整的pip freeze清单，连cuda版本都记下来。transformers和peft之间的版本匹配特别关键，差一个小版本号，LoRA层的注入方式可能就不一样了。还有一个经验是把tokenizers单独锁版本，这玩意跟transformers绑得紧，升一个另一个容易崩。我团队里现在有个规矩，环境配置文件进git，谁要改版本必须写commit说明，不然出了事故都找不到人背锅。
2.2 LoRA微调原理、目标模块选择与关键参数配置
LoRA的原理我用自己的话讲一遍。大模型训练时要更新海量参数，LoRA的思路是冻结原来的权重，在旁边加一条低秩旁路，用两个小矩阵A和B去模拟权重变化量，训练的时候只更新这两个小矩阵。原始权重不动、旁路参数很少、训练完还能把旁路合回原模型，这就是它的三个核心卖点。我最早理解低秩这个概念的时候想了很久，后来想通了，你就当是在原来的大矩阵旁边挂了一个瘦长的小矩阵组合，用很小的参数量去捕捉任务相关的增量信息。
目标模块选择是实战里最容易被忽略又影响很大的环节。LoRA默认一般只挂q和v两个投影层，我一开始也照抄默认，后来实验发现把k、o、gate、up、down全部挂上，效果能明显好一截，代价是参数量和显存稍微涨一点。我的经验是数据量充足、任务复杂度高的时候，全挂更稳；数据量小、任务简单的时候，q和v就够用了。还有一个模块我不建议动，就是embedding层和lm_head，这俩参数量太大了，挂LoRA性价比很低，一般直接冻结。
关键参数里rank和alpha是最核心的两个。rank控制旁路的秩，常见取值8、16、32、64，我一般从16起步，任务复杂或者数据多就往32、64调。alpha是缩放系数，业界默认是alpha等于rank或者两倍rank，我习惯用两倍rank，学习率会设得比较小，1e-4到3e-4这个区间。dropout我一般设0.05，数据量特别小可以设到0.1防止过拟合。还有一个参数叫bias，我通常选none，除非任务对偏置特别敏感。这些参数没有绝对最优，我一般会拿一小批数据做参数扫描，跑三四个组合比一比验证集loss，选最稳的那个。
2.3 训练脚本编写、超参数调优与显存优化
训练脚本我不太喜欢一上来就写几百行的复杂框架，先用几十行跑通一个最小可训练流程才是正道。核心逻辑无非就是加载tokenizer、加载模型、注入LoRA配置、构建数据集、定义训练参数、启动Trainer。我用HuggingFace的Trainer比较多，SFTTrainer也常用，它的好处是帮你处理了指令数据的padding和loss mask。自己写训练循环也不是不行，可控性更强，但初学阶段没必要给自己增加复杂度。脚本写完之后我会先拿十几条样本跑一遍，确认能正常训练、loss在动、checkpoint能保存。
超参数调优这块，我自己的优先级排序是学习率第一、batch size第二、epoch第三。学习率对LoRA特别敏感，太大直接崩成乱码，太小半天不收敛。我一般从2e-4试起，配合cosine学习率调度和warmup比例0.03。batch size受显存限制，我会用gradient accumulation凑到一个等效的全局batch，通常设到32到64之间比较稳。epoch数量上，小数据集1到3轮足够，多了必然过拟合，我一般会用验证集loss做早停，patience设2。还有一个冷门但好用的技巧是分组采样，把长度相近的样本放一个batch，减少padding浪费。
显存优化是我日常跟显存搏斗总结出来的几条路。第一条是bf16混合精度训练，能省一半显存，A100、A10、4090都支持。第二条是gradient checkpointing，用时间换空间，显存能再降三四成，训练速度慢一点但能跑起来。第三条是优化器选择，AdamW换成8bit的paged_adamw_8bit，优化器状态占用能砍掉一大截。第四条是seq长度限制，把最大长度从4096降到1024或者2048，显存需求是平方级下降。最后一条是DeepSpeed或者FSDP，多卡场景才用得上。我一般是先叠前三条，不够再上最后一条。
2.4 训练监控、效果评估与常见问题排查
训练监控我主要盯三样东西。第一是loss曲线，正常情况应该平滑下降然后趋于平稳，出现剧烈震荡或者突然飙升就要警觉。第二是学习率曲线，确认调度器按预期在走，我见过有人把warmup比例写错，前一百步学习率一直是零。第三是梯度范数，这个能提前发现梯度爆炸或者消失。wandb和tensorboard我都用，wandb的界面更直观，tensorboard在离线环境更省事。我一般每十步打一次日志，每两百步存一次checkpoint，这样出了问题能快速回滚。
效果评估不能只看训练loss，这个坑我掉进去过。训练loss降得很好，模型生成出来一塌糊涂，原因是数据里有大量重复样本导致模型背答案。评估我分三层做，第一层是自动指标，分类任务看准确率和F1，生成任务看rouge和bleu，有条件的跑个bert_score。第二层是人工评估，随机抽一百条测试集输出，逐条看质量、格式、逻辑。第三层是A/B对比，拿基座模型和微调模型在相同输入下生成的结果放在一起比，让人盲评。这三层都过了，我才敢说这次微调是有效的。
常见问题排查我列几个高频的。loss不下降，先查数据格式对不对，特别是指令模板有没有和tokenizer匹配，这个错误太常见了。loss突然变成nan，先看学习率是不是太大，再看数据里有没有异常长样本或者空样本。模型输出复读机一样重复，多半是训练数据里重复模式的锅，回头清洗数据。模型遗忘通用能力，说明LoRA影响了太多原有知识，rank降一降或者数据里掺一些通用样本。我还有一个保底习惯，每次出问题先把learning rate降一半再跑一遍，十次里有三次能直接解决。
2.5 模型合并、部署推理与迭代维护
模型合并这一步，原理不复杂但要细心。peft库的merge_and_unload方法能把LoRA权重按公式合回基座模型，得到一个完整的、可以脱离peft库直接加载的模型。合并的时候要注意dtype，基座是fp16就合到fp16，基座是bf16就合到bf16，混了容易出精度问题。合并完我会跑一批固定的测试输入，把合并前后输出做对比，确认数值上基本一致。有些场景我会故意不合并，保留LoRA权重单独挂着，这样切换不同任务的LoRA变得非常方便，一份基座加多个小权重就能服务多个业务场景。
部署推理我推荐vLLM或者TGI，这俩对LoRA都有原生支持。vLLM的优势是吞吐高，多LoRA动态加载做得很成熟，一个服务挂多个适配器没问题。TGI跟HuggingFace生态结合得更紧，部署配置化程度高。小规模场景直接用transformers加载也能跑，就是吞吐差一些。部署的时候我会关注几个指标，首token延迟、生成速度、显存占用、并发上限。量化推理我也常用，AWQ和GPTQ量化之后显存占用能降到原来的三分之一左右，精度损失在可接受范围内。推理服务上生产之前，一定要做压力测试，不然流量一上来直接崩。
迭代维护是长期工程，别以为模型上线就完事了。用户反馈收集、badcase回流、数据版本更新、重新训练、效果对比、灰度发布，这一套流程我建议一开始就搭起来。我现在的习惯是每个月做一次badcase复盘，把线上效果差的样本整理出来，补充进下一版训练数据。模型版本管理用MLflow或者自己搭个简单表记录，每个版本存基座版本、LoRA参数、训练数据版本、评估指标。回滚机制必须有，新版本灰度百分之十流量，观察一周没问题再全量，有问题一键切回上一版。模型维护这件事，七分靠流程、三分靠技术，流程顺了迭代才能快起来。
