很多人第一次接触大模型微调，会把全量微调、LoRA、QLoRA、SFT、DPO、RLHF 全部背成一串名词。真正做项目时，这样理解很容易踩坑。因为这些词不是同一层面的“平行选项”：有些是在说怎么改参数，有些是在说模型要学什么目标。

一、微调不是第一选择

模型效果不理想时，第一反应不应该是立刻训练模型。微调要数据、显卡、评估和上线维护，一旦基础模型升级，旧的微调版本往往还要重新做。因此，微调更像“最后的定制加工”，不是“万能补丁”。

通常先试三件事：第一，Prompt 是否写清楚；第二，是否可以用 Few-shot 示例压住输出格式；第三，如果问题是知识缺失，是否可以用 RAG 或数据库实时查询。只有这些都不够稳定，才考虑微调。

• 适合微调：稳定风格、固定格式、内部术语、任务模式、小模型降本。

• 不适合微调：价格、库存、合同、政策、实时状态这类经常变化的事实知识。

• 最常见误区：把微调当知识库用。知识频繁更新时，应该走 RAG 或数据库。

二、微调方案要分两条线看

理解微调最关键的一步，是把“改哪些参数”和“学什么目标”分开。全量微调、LoRA、QLoRA 关注训练时改多少参数；SFT、DPO、RLHF 关注模型要学什么行为。两条线可以组合。

举个例子，LoRA 不是 SFT 的替代品，SFT 也不是 LoRA 的替代品。你可以用 LoRA 做 SFT，也可以用 QLoRA 做 SFT；也可以先做 LoRA + SFT，再继续做 LoRA + DPO。

三、改哪些参数：全量微调、LoRA、QLoRA

全量微调最直接：把模型所有参数都参与训练。它的上限高，但显存、算力和工程复杂度都高，而且容易出现灾难性遗忘。LoRA 则冻结原模型，只训练新加的低秩矩阵，成本低很多。QLoRA 进一步把基础模型量化到 4-bit，再训练 LoRA Adapter，让资源门槛进一步下降。

1. 全量微调：效果上限高，但成本高

全量微调适合资源充足、任务价值高、对最终效果要求极高的场景。它的优点是模型有最大自由度，缺点是训练和部署都重。尤其是大模型参数越大，优化器状态、梯度和激活值会把显存快速吃满。

如果只是让模型输出固定格式，或者学习少量业务术语，直接全量微调往往是“杀鸡用牛刀”。

2. LoRA：最常用的轻量微调

LoRA 的想法很简单：原始权重 W 保持冻结，在旁边加两个小矩阵 A 和 B，只训练这两个小矩阵。训练完成后，A 和 B 代表本次任务需要的“修正量”。这样既能保留基础模型能力，又能用很小的训练成本适配新任务。

LoRA 论文指出，它通过冻结预训练权重并向 Transformer 层注入可训练的低秩分解矩阵，显著减少下游任务需要训练的参数量。Hugging Face PEFT 文档也把 LoRA 归为参数高效微调方法，用两个低秩矩阵分解大矩阵，降低需要微调的参数规模。

3. QLoRA：资源紧张时的实用方案

QLoRA 可以理解为“量化底座 + LoRA 微调”。基础模型用 4-bit 量化保存并冻结，训练时梯度只更新 LoRA Adapter。它的目标不是让量化模型本身全部参与训练，而是把显存省下来，让更大的模型能在更小的显卡上微调。

QLoRA 论文提出，使用 4-bit 量化的预训练模型并通过 LoRA Adapter 反向传播梯度，可以显著降低内存占用；论文摘要中还提到可在单张 48GB GPU 上微调 65B 模型。

四、学什么目标：SFT、DPO 和 RLHF

“学什么目标”决定了训练数据长什么样。SFT 用的是“指令 → 标准回答”，主要让模型学会按指令回答、输出固定格式、掌握任务模式。DPO 用的是“同一个问题下，好回答 vs 差回答”，主要让模型学会偏好、语气和用户更喜欢的表达。

1. SFT：让模型学会按指令回答

SFT 是监督微调。它用人工整理好的输入和输出对来训练模型，让模型从“文本续写机器”变成“指令响应助手”。如果你要模型稳定生成客服回复、固定 JSON、代码解释、摘要模板，SFT 是最常见的目标。

OpenAI 文档把 SFT 描述为提供正确回答示例来引导模型行为，适合分类、特定格式生成、修正指令跟随失败等任务。

2. DPO：让模型知道哪种回答更好

SFT 解决“会不会答”，DPO 更偏向解决“答得好不好、风格是不是更符合偏好”。DPO 数据通常是一组三元组：prompt、chosen、rejected。模型通过训练提高 chosen 的概率、压低 rejected 的概率。

DPO 论文提出可以绕开传统 RLHF 中的奖励模型和 PPO 流程，用更简单的分类损失来做偏好优化。Hugging Face TRL 文档也说明，DPO 用同一 prompt 下的偏好回答对训练模型，不需要显式奖励模型。

3. RLHF / RFT：更重的对齐训练

RLHF 的典型流程是收集人类偏好、训练奖励模型、再用强化学习优化主模型。它能处理更复杂的对齐问题，但工程成本高、训练更不稳定。现在很多开源项目会用 DPO 作为更轻量的替代方案，但这不代表 RLHF 过时，只是适合的团队和任务不同。

OpenAI 的模型优化文档中把 SFT、DPO、RFT 列为不同的优化方法，并强调训练后仍要通过 evals 评估效果。

五、工程流程：别只会训练，还要会评估和回滚

生产环境里，微调不是一个训练脚本，而是一条完整流水线。训练前要有目标和评测集；训练中要记录数据版本、模型版本、超参数；训练后要看离线评估、灰度效果和用户反馈；上线失败时要能快速回滚。

• 数据：清洗重复样本、低质样本、冲突答案、敏感信息。

• 训练：先小数据集验证，再扩大数据规模；先 LoRA/QLoRA，再考虑更重方案。

• 评估：格式通过率、任务准确率、拒答率、幻觉率、成本和延迟都要看。

• 上线：保留基座模型、Adapter、数据集和配置，避免出现“训练了但复现不了”。

六、怎么选：不同场景的推荐组合

如果你是个人开发者或资源有限的小团队，最现实的路线通常是 QLoRA + SFT。数据不需要一开始就几十万条，先把 1000 到 5000 条高质量样本做好，往往比堆大量低质量数据更有效。

如果你已经有稳定业务数据、有几张高显存 GPU，可以考虑 LoRA + SFT；如果 SFT 后回答能用但“不够像人、不够符合偏好”，再加 DPO。如果你是大厂或研究团队，才需要认真考虑全量微调、RLHF/RFT 这种高成本路线。

七、微调常见坑

微调最怕的是把脏数据喂给模型，或者只看训练 loss 就上线。训练 loss 下降不等于真实效果变好；小样本里被模型记住的格式，也不一定能泛化到真实用户输入。

• 不要把微调用来记住高频变化的事实知识。

• 不要只用训练集样本做效果展示，必须准备独立测试集。

• 不要忽略基础模型升级带来的重训成本。

• 不要让一个 Adapter 承担太多互相冲突的业务风格。

• 不要把用户隐私、合同原文、敏感日志直接丢进训练集。

八、最后总结

微调这件事可以用一句话概括：先判断需不需要，再区分怎么改参数和学什么目标。全量微调、LoRA、QLoRA 是“怎么改”；SFT、DPO、RLHF 是“学什么”。绝大多数项目不需要一上来就全量微调，先用 Prompt、Few-shot、RAG 和轻量微调组合，才是更稳的工程路线。

真正能落地的微调方案，不是名词堆得多，而是能说清楚：为什么要训、训什么数据、用什么方法、怎么评估、怎么上线、失败怎么回滚。