大模型微调（Fine-tuning）入门：使用 LoRA（低秩适应微调）训练垂直领域专属模型

你手上攒了几百上千条业务问答或工单记录，觉得模型答得不够「像自己人」，于是开始搜微调教程，结果满屏都是显存、rank、epoch 这些词，不知道从哪下手。这篇不灌概念，只讲参数微调这条路的判断标准、数据怎么整理、训练怎么跑、训完怎么验收，以及什么情况下你根本不该走这条路。

你手上攒了几百上千条业务问答或工单记录，觉得模型答得不够「像自己人」，于是开始搜微调教程，结果满屏都是显存、rank、epoch 这些词，不知道从哪下手。这篇不灌概念，只讲参数微调这条路的判断标准、数据怎么整理、训练怎么跑、训完怎么验收，以及什么情况下你根本不该走这条路。

先划清分工：如果你的核心诉求是「让模型知道更多事实、查得到最新资料」，那属于检索增强那条线，不是本篇范围。这篇只谈参数微调——也就是动手改模型权重，让它换个说话方式、换个输出格式、换个任务习惯。两条路经常一起用，但入门阶段先别混着上，一次只动一个变量，出问题才排得清。

先判断：你这个需求该不该上微调

微调不是万能钥匙，它是「调行为」的工具，不是「灌知识」的工具。很多人第一步就走错，把一堆新资料丢进去训，结果模型既没记住新知识，原来会的还退化了一点。所以先花十分钟做需求分类，比后面烧几天算力划算得多。

最实用的自测办法：把你打算用来训练的那批资料，塞进提示词里，写成一个详细的系统提示，然后跑十几条真实问题看效果。如果能达到你预期的八成，就先别训——提示词加上检索往往能撑很久，维护成本还低。

• 数据只有几十条：不够训，先去攒数据或走提示词路线
• 领域知识每天都在变：微调后面临反复重训，不划算
• 预算只够跑一次实验：没有迭代余地，训砸了没法救
• 只是想统一输出格式：先用输出约束和模板试两周再说

LoRA 到底改了什么，为什么省

大白话讲：原模型的权重全部冻住不动，在旁边挂两条很细的旁路矩阵，训练时只更新这两条小矩阵。前向计算时，原权重的结果加上旁路的结果，合在一起用。因为旁路很小，可训练参数数量大幅下降，显存占用和存储占用都跟着降。

冻结

原模型参数不参与更新，省下大量优化器状态显存

旁路矩阵

两三个小矩阵相乘，维度远小于原权重，只训这部分

适配文件

训练产物只是这个小文件，不动的还是原模型本体

秩

旁路矩阵的宽度，越大能表达的变化越多，也越容易过拟合

要认清边界：LoRA 改的是模型的「行为倾向」，比如习惯用什么句式、优先输出什么字段、遇到某类问题先做什么动作。它不会凭空学会数据里没有的知识。你如果指望它背下一整本手册，那方向就偏了，应该去做检索。反过来，如果只是要它稳定按某个格式回答，LoRA 往往比堆提示词更省心。

另一个常被忽略的点：适配文件是跟基座模型绑定的。换基座、换基座版本，这个文件基本不能直接复用，必须重新验证甚至重训。所以从第一天起就要把「基座标识 + 适配文件」当成一个整体来管，别只存一个小文件，后面自己都对不上。

数据准备：这一步决定八成结果

训练结果好不好，八成在数据上就定了。参数怎么调是后话。数据准备的核心不是数量，是「一致」——同一个问题不能出现两种互相矛盾的答案，否则模型学到的就是随机摇摆。

清洗有个推荐顺序，别跳步：先去重（相似度高的只留一条），再去隐私（人名、电话、账号一律替换），再去无意义短句（「好的」「收到」这类），最后切分训练集和验证集。验证集一定要提前切出来，不能训完再分，否则验收结果不可信。

• 起步量别贪：先攒够能覆盖主要任务类型的一小批，跑通再扩
• 正例为主，但要把典型错例也写成「正确回答」的样本，让模型知道边界
• 同一任务类型里最好有不同措辞的变体，避免模型死记某一句
• 每类任务留几条完全不出现在训练集里的样本，专供验收

常见坑：拿线上原始日志直接喂。日志里混着客服的道歉话术、错别字、半截对话，模型会照单全收。还有人把「模型原本就会答对」的样本也大量塞进去，等于白训，还挤占了真正需要学的样本比例。整理时多问一句：这条样本想教会模型什么？答不上来就删。

训练参数怎么设：先跑通再调优

新手最容易犯的错是一上来就纠结参数。正确姿势是先定一个能跑通的基线：少量数据、少轮次、默认参数，完整走一遍流程，看损失曲线和输出样例长什么样。流程通了，再逐个旋钮调。

1. 第一步：跑通拿一小批数据、少量轮次跑完整流程，确认数据加载、训练、保存、推理这条链路都通。看输出是不是至少没乱码。
2. 第二步：看损失训练损失稳步下降说明在学；验证损失早早开始上升说明过拟合了，该减轮次或减秩。
3. 第三步：调旋钮按学习率、训练轮次、秩、批次的顺序调，一次只动一个，动完重新看验证集输出，别一次全改。
4. 第四步：定基线把效果最好的一版参数和对应的适配文件记下来，作为下次迭代的对照基准。

几个关键旋钮各管什么：学习率太大容易训崩、太小等于没训；训练轮次多了会过拟合、少了学不到位；秩越大表达能力越强但越容易记死训练样本；批次大小受显存限制，放不下就先减它。设置顺序建议从保守值起步，宁可少训一点，也别一次冲太猛。

过拟合的早期信号很好认：训练损失一路往下掉，但验证集输出开始复读训练样本里的原句，甚至把你的样例问题原封不动背出来。看到这个就停，减轮次、减秩，或者加数据。别指望继续训会自己变好。

算力从哪来有三条路：本地单卡、按小时租卡、用托管微调服务。三者适用前提不同——本地方便调试小模型，租卡适合要跑大一点的基座，托管服务省运维但灵活度低。具体价格和算力档位会变，到站内 算力与微调服务页面（/price-watch） 核对当时的数字，别按老印象做预算。

训练过程要盯什么，出问题怎么排

训练跑起来之后，盯三样东西就够：损失曲线、显存占用、输出样例。出问题基本归为四类，按顺序排查能省很多时间，不要东一榔头西一棒子。

• 数据格式报错：先看样本字段名和拼接模板对不对，再看有没有空值或超长样本
• 显存不足：先确认是训练阶段还是推理阶段爆的，这两个解决方向不一样
• 损失不降：先确认学习率不是小到没效果，再看数据是不是本身就没规律
• 损失变 NaN：多半是学习率过大或数据里有异常值，先把学习率砍一档重跑

显存不够时，按处理代价从低到高来：先降批次大小，再缩短序列长度，然后上梯度累积（用小批次模拟大批次），最后才考虑换量化基座。每一步改完都重新看一眼输出质量，别一路降到底把效果也降没了。

训练中断的处理：中间产物要定期存，别只在最后存一次。想清楚你接受的重跑成本——是从头再来，还是能从最近的检查点续上。这个决定你多久存一次。租卡的场景尤其要注意，中断了时间就是钱。

训完怎么验收：别只看它会不会背

最常见的验收误区是：拿训练集里的问题去问微调后的模型，答得又顺又准，就以为成了。这叫背答案，不算数。正确的验收要拿完全没参与训练的真实任务来测，而且要做横向对照。

盲测的小办法：把原模型和微调后的输出随机打乱顺序，交给不了解情况的人挑更好的那个。自己给自己打分容易偏心，尤其是自己整理的数据、自己训的模型。有条件就找两三个人交叉评。

还要专门查一件事：能力退化。LoRA 虽然改动小，但训歪了照样会让模型在其他任务上变差。挑几条跟本次微调无关的任务跑一下，确认没退步，再决定上线。

训完之后：放哪跑、花多少钱、要不要反复迭代

训完之后要决定模型放哪跑。托管推理省心、起步快，适合调用量不大或还在验证阶段；自建部署在调用量上来之后更可控，但要自己管机器和运维。分界线不绝对，按你的调用量、响应时间要求和团队运维能力来定，别一上来就追求自建。

适配文件的版本管理容易被忽略。它跟基座模型版本绑死，换基座必须重新验证，不能直接搬。建议每次训练都记清楚：用哪批数据、哪套参数、对应哪个基座，存成一个可追溯的记录。否则过两个月你自己都不知道线上跑的是哪一版。

• 先上线收集真实反馈，攒一批再训第二轮，不要一次追求完美
• 第一轮重点看格式和语气是否到位，知识类问题交给检索
• 每轮训练前先明确这轮要修什么，别漫无目的地重训
• 版本记录跟上，避免线上和本地对不上号

迭代节奏上，先小步上线、收集真实差评，攒够一批再训下一轮，比关起门来一次训到完美现实得多。横向比价时到 工具目录（/tools/speed-test） 和 价格追踪页面（/price-watch） 看当时的数字，价格和可用算力变动很快，别沿用旧数据做决策。

这些情况请回到提示词或查资料那条路

有几种情况，微调真的不是首选，硬上只会浪费时间和算力。碰上了，及时掉头比坚持更明智。

• 知识型问答：答案来自会变的事实，检索更合适
• 超长文档理解：这是上下文处理能力问题，不是行为问题
• 需要实时更新的事实：训完就过时，维护成本高得离谱
• 纯粹想省钱：省不省取决于调用结构，先把提示词与检索优化到位再说

工程上更常见的做法是组合使用：先检索把相关资料找出来，再让微调过的模型按你的格式和语气产出。顺序很重要，反过来容易乱。入门阶段先把一条路走通，再加另一条。

判断口诀：改行为用微调，补知识用检索，改不了的就别硬训。