AI 微调：全参微调和 LoRA 怎么选

大模型微调选全参还是 LoRA，判断顺序应该反过来：先算显存，再算数据，再谈效果上限。显存不够，全参连一个训练批次都跑不起来；数据不够，全参只会把少量样本背下来。多数团队的实际答案是先用 LoRA 跑通评测，再决定要不要加码。

先算显存，再谈效果

全参微调要更新的参数和底座一样多。训练时除了权重，还要存梯度和优化器状态，显存占用通常是权重本身的数倍；参数量越大，这个倍数带来的绝对差越明显。LoRA 冻结底座，只训练一小块附加参数，优化器状态跟着变小，单卡能跑的空间就出来了。

但 LoRA 省的不是全部。前向传播的激活值仍然和序列长度、批次大小相关，上下文拉长、批次开大，显存照样吃紧。所以“LoRA 能单卡跑”有前提：序列长度控制在任务需要的范围内，别一上来就塞满上下文窗口。

两种方法改的到底是什么

全参微调改的是每一层原有的权重，模型行为整体平移。LoRA 不动原权重，在旁边加一对低秩矩阵，把这次任务需要的偏移记在这对矩阵里。前者像重写整本书，后者像在书页边上贴便签。

机制差异带来三个后果。可逆：LoRA 模块卸掉，底座回到原样；全参微调回不去，除非留了原始权重。可叠加：一个底座挂多个 LoRA，按请求切换；全参要为每个任务存一份完整模型。有上限：低秩矩阵能表达的偏移有限，任务和底座差异很大时，LoRA 容易学不到位。

数据量决定下限，任务数决定结构

几千条以内的数据，LoRA 更稳。参数少，过拟合风险低，小数据上的波动也小。数据到了几十万条这个量级，全参的优势才开始显现，因为它有足够样本去调整所有层，而不是只调整一条旁路。

这里的数据量指高质量、标注一致的样本，不是原始条数。一千条口径统一的样本，胜得过一万条互相矛盾的样本。标注前先定规则：同一个问题，两个人标出来是否一致；不一致的地方，就是规则没写清的地方。

任务数量影响的是结构选择。一个底座要服务五六个下游任务，LoRA 的多模块方案省显存也省部署；只有一个任务、且效果要求高，全参更直接。中间情况可以混着来：主干用 LoRA 试，效果不够再解冻部分层。

五个维度对照

这张表的使用顺序是从上往下：显存过不了，后面几行不用看；显存过了，再比数据和任务数。

微调解决不了知识更新

想让模型记住新政策、新产品、新价格，微调是笨办法。知识会变，微调一次就要重训一次；训练进权重的事实也很难核验来源，错了查不出来。这类需求用检索增强更合适，把资料放在外部、每次请求时取回，改一处就全局生效。

两者的分工可以这样看：要改的是说话方式、输出格式、判断口径，用微调；要补的是具体事实、文档内容、最新数据，用检索。分不清的时候先做检索，成本低、可回滚；微调和检索增强的分工里有更细的判断线。

评测没做，等于没调

微调前后必须用同一套题对比，否则无法判断提升来自训练还是随机波动。评测集要单独留，不能和训练集重叠；重叠了，分数一定好看，上线一定难看。

题目分两类：一类考格式，比如是否稳定输出 JSON、字段是否齐全；一类考判断，比如同类问题换一种表述后结论是否一致。格式类可以自动打分，判断类需要人工看几十条。两类都过，才算调通。

还要留一组“不该变”的题。微调经常把模型在其他任务上的能力带偏，这组题就是用来发现带偏的。分数掉了，说明学习率太高或者数据太窄。

从 LoRA 转到全参的路径

先用 LoRA 把数据、格式、评测流程跑通，再决定是否加码。转到全参时，数据可以复用，评测集必须复用，学习率要重新调，通常比 LoRA 小。LoRA 阶段积累的错误样本，正好是全参阶段要重点补的部分。

秩的选择别照抄别人的数字。常见档位从 8 到 64 都有人用，任务越接近底座已有能力，越小的秩就够；任务偏移越大，秩要往上加。LoRA 的秩怎么取讲的是同一件事：先小后大，用评测说话。

如果最终要私有化部署，还要算推理成本。LoRA 合并进底座后，推理不增加层数；以适配器形式分离部署时，每次请求多一次旁路计算。这个差别在低并发时看不出来，高并发时会影响单机吞吐。部署形态的选择，和自部署与调 API 的取舍是同一笔账。

选型速查

• 单卡放不下训练状态：LoRA
• 数据几千条以内：LoRA；几十万条且效果不达标：再评估全参
• 下游任务三个以上：LoRA 多模块
• 要补新知识：先做检索，不要微调
• 没有独立评测集：先补评测，再谈方法

选型的答案不在方法本身，在你的显存、数据和验收标准。把这三样写下来，选择通常只剩一个。