我了解微调之后首先意识到的是微调不是首选而是最后手段。大多数问题先把 Prompt 写好、加 Few-shot 示例或者用 RAG 接外部知识基本都能解决。面试官来讲讲大模型微调的方案有哪些♂️我微调方案有全量微调、LoRA、QLoRA、SFT、DPO 这些工业界常用 LoRA。面试官……你这是把名词都背了一遍但没说清楚关系。LoRA 和 SFT 是同一个层面的东西吗SFT 和 DPO 又是什么关系为什么要分这么多名字♂️我呃应该都是不同的微调方法吧面试官完全错。这些名词其实分两个维度。一个维度是「改哪些参数」全量微调 vs LoRA vs QLoRA另一个维度是「学什么目标」SFT vs DPO。这两个维度是正交的可以组合你可以用 LoRA 做 SFT也可以用 LoRA 做 DPO。这层关系搞不清楚就讲不出选型逻辑。♂️我哦原来是两个维度。面试官那再问你一个问题什么时候真的需要微调是不是模型表现不好就该上微调♂️我嗯应该是吧面试官典型的新人思维。微调是「最后手段」不是「第一选择」。能用 Prompt Few-shot 解决的问题绝对不要上微调因为微调的成本和维护代价远比想象大。「什么时候该微调、什么时候不该」是这道题的关键判断点。回去搞清楚再来。这道题我开始还以为是把 LoRA、SFT、RLHF 这些名词背一遍就行问到这里才反应过来真正考的是两条正交的轴改哪些参数、学什么目标外加一条前置判断「这个需求到底该不该微调」。 简要回答我了解微调之后首先意识到的是微调不是首选而是最后手段。大多数问题先把 Prompt 写好、加 Few-shot 示例或者用 RAG 接外部知识基本都能解决。真正需要微调的场景是模型需要以特定风格持续输出、需要学会稳定的任务格式、或者需要大幅降低成本用小模型替代大模型。方案上LoRA/QLoRA 是最常用的因为它只训练一小部分参数普通 GPU 上就能跑不需要全量更新所有权重SFT 是微调的目标形式让模型从续写模式变成指令回答模式有偏好对齐需求的话DPO 比 RLHF 简单得多、效果也不差。选模型不是看谁排行榜最高选微调方案也是同理核心是看资源约束和实际需求。 详细解析先回答一个前置问题什么时候才真的需要微调很多人一遇到「模型表现不好」就想上微调这其实是新人的本能反应。但工业界踩过坑的人都知道微调是最后手段不是第一选择。为什么因为微调的成本远比想象大。需要准备高质量数据集光是标注就可能花几万到几十万、需要 GPU 资源少说几张 A100、需要工程经验调参、防过拟合、防灾难性遗忘。最坑的是维护成本底层基础模型一升级比如 Llama 3 出来要换 Llama 4你之前微调的版本基本就废了得重新微调一遍。那什么时候才该上微调我自己总结的判断标准是这样的。如果只是想让模型回答某种特定格式比如必须是 JSON先试 Prompt Few-shot写清楚格式要求 给 3-5 个示例大模型基本能搞定。如果想让模型回答某种特定风格比如公司客服的口吻先试 System Prompt 描述风格 几个对话示例多数情况也能行。如果想让模型懂某个领域知识先试 RAG检索增强把领域知识库挂上让模型实时查比硬塞进参数里灵活得多。只有当上面这些都试过、效果还是不达标的时候才认真考虑微调。具体来说下面三种场景微调才是真的值得做第一种是模型需要持续以一种特殊风格输出Prompt 控制不住比如生成特定格式的代码、特定语气的文案第二种是需要模型稳定掌握某类任务模式或内部术语表达第三种是想用小模型替代大模型省成本用 7B 微调模型替代 70B 通用模型推理成本能省很多。这里要特别提醒如果需求是「补充经常变化的事实知识」微调通常不是好选择。比如产品价格、政策条款、库存状态、合同原文这些内容应该放进 RAG 或数据库里实时查。微调更适合学行为、格式、风格和任务模式不适合当一个会频繁更新的知识库。理清「该不该微调」之后再来看「微调有哪些方案」。这里有一个特别容易踩的坑很多人把「全量微调、LoRA、QLoRA、SFT、DPO」都当成同一类的「不同微调方法」来背。其实它们分两个完全不同的维度。微调的两个正交维度改哪些参数 vs 学什么目标微调本质上是回答两个问题。第一个问题是「改哪些参数」。模型有几十亿到几百亿参数你是要全部改还是只改一小部分这一维度上有三个主流方案全量微调全改、LoRA改一小部分、QLoRA改一小部分 量化基础模型。第二个问题是「学什么目标」。模型要学的是「按指令回答」还是「学会哪种回答更好」这一维度上有两个主流方案SFT学指令格式、DPO学偏好对齐。这两个维度是正交的可以任意组合。比如用全量微调做 SFT用 LoRA 做 SFT用 QLoRA 做 SFT用 LoRA 做 DPO用 QLoRA 做 DPO每种组合都是合法的「微调方案」。理解这两个维度的正交关系是回答这道题的钥匙。下面分别看这两个维度上的方案。「改哪些参数」维度从全量微调到 QLoRA全量微调Full Fine-tuning所有参数都改最朴素的方案就是把模型所有参数都拿出来在新数据上继续训练让所有层都重新适配新任务。效果通常是最好的因为模型有最大的自由度去调整。但代价大到吓人。一个 7B 模型的全量微调不光要存权重本身FP16 大约 14GB还要存梯度14GB、优化器状态Adam 的两个矩约 56GB加起来一次训练 80GB 起步普通研究者根本玩不动。70B 的模型更夸张要几十张 A100 组集群才能训。更糟的是「灾难性遗忘」Catastrophic Forgetting。模型在新任务上学得好了原本预训练学到的通用能力反而下降。这是因为所有参数都在被改写新数据分布有偏的话模型会忘记原本的「通用知识」。所以全量微调虽然效果上限高但实际能用的团队凤毛麟角。绝大多数情况下业界都在用更轻量的方案最流行的就是 LoRA。LoRALow-Rank Adaptation只改一小部分参数LoRA 的核心洞见特别巧妙。它发现一个事实模型参数的「更新量」即 ΔW W微调后 - W原始虽然维度很大比如 4096×4096但真正有意义的变化只发生在一个低维子空间里。换句话说权重的更新具有「内在低秩性」不需要每个维度都去改。基于这个洞见LoRA 的做法是冻结原始权重 W 不动在 W 旁边新增两个小矩阵 A 和 B维度分别是 d×r 和 r×d其中 r 远小于 d通常 r8 或 16训练时只更新这两个小矩阵。推理时把 B·A 加回到 W 上等价于一个全量微调过的模型但训练时显存和算力开销是全量微调的几十分之一。打个比方全量微调像是把一本厚厚的教科书全部重写一遍LoRA 像是在书的空白处贴便利贴原书一字不动便利贴上写着新增的修正和补充。看书的时候原文 便利贴一起看效果叠加。参数量对比很直观。一个 4096×4096 的权重矩阵原本有 1600 万参数LoRA r16 只需要 4096×16 16×4096 13 万参数参数量降到 1/120。整个 7B 模型的可训练参数从 70 亿降到 2000 万左右显存需求从 80GB 降到 20GB 量级一张 A100 就能搞定。LoRA 已经是 2023 年之后最主流的微调方案几乎所有开源社区的微调项目都在用。QLoRA消费级 GPU 的入场券LoRA 解决了「不用 80GB 显存也能微调」的问题但对个人开发者来说20GB 显存还是有门槛4090 是 24GB刚刚够 7B 模型的 LoRA。QLoRA 把这个门槛进一步往下打。QLoRA 的核心思路是先把基础模型用 4-bit 量化一种叫 NF4 的格式专为模型权重的近似高斯分布设计把 7B 模型的显存占用从 14GB 压到 4GB 左右然后在量化后的基础模型上套 LoRA。这样整个微调过程的显存占用降到 10GB 以内一张 409024GB就能微调 7B 甚至 13B 模型。QLoRA 的精度损失非常小实测效果和全精度 LoRA 几乎没差别。这一招直接让微调民主化了无数个人开发者用 QLoRA 训出了自己的领域模型。Alpaca、Vicuna 这些早期开源指令模型基本都是用 QLoRA 训出来的。到这里「改哪些参数」维度的三个方案就清楚了。下面看另一个维度。「学什么目标」维度SFT 和 DPO「改哪些参数」回答的是「怎么改」的问题但还有一个更核心的问题没回答改的目标是什么让模型学会做什么这一维度上有两个主流方案。SFTSupervised Fine-Tuning监督微调让模型学会「按指令回答」预训练模型本质是「文本续写机器」给一段文字就接着往下写根本不知道「问问题」是什么意思。SFT 的目标就是把模型从「续写模式」切换到「对话模式」。它的训练数据格式是 (指令期望回答) 的对比如「请介绍一下北京 → 北京是中国的首都位于华北平原……」。模型在这样的数据上继续训练慢慢学会「看到这种格式就该给一个完整回答不要无限续写下去」。SFT 是一个「目标」不是「方法」。具体怎么实现可以用全量微调做 SFT、可以用 LoRA 做 SFT、也可以用 QLoRA 做 SFT。在工业界最常见的组合是QLoRA SFT 数据性价比最高。SFT 数据的关键是质量大于数量。Llama 2 用了大约 100 万条 SFT 数据但每条都是精心标注的。AlpacaFarm 的研究还发现一个反直觉结论几千条高质量数据训出来的效果比几十万条粗糙数据要好。DPODirect Preference Optimization直接偏好优化让模型学会「哪种回答更受欢迎」SFT 之后模型已经会按指令回答了但回答风格不一定是用户喜欢的可能太啰嗦、太简洁、有时候说话不得体。这时候需要更进一步的「偏好对齐」告诉模型「同样合格的回答里哪种用户更喜欢」。早期做偏好对齐的标配方案是 RLHFReinforcement Learning from Human Feedback流程是收集人类偏好数据 → 训一个奖励模型 → 用 PPO 算法优化主模型。但 RLHF 流程长、要同时维护好几个模型、训练不稳定能驾驭它的团队不多。DPO 是斯坦福 2023 年提出的简化方案。它发现一个数学上的等价转换RLHF 的优化目标可以推导成纯监督学习的损失函数完全绕过奖励模型也不需要 PPO。直接拿 (问题好回答差回答) 三元组训练让模型直接学会「好回答的概率要比差回答提升得多」。DPO 训练简单、稳定、工程门槛低所以开源社区的偏好对齐阶段大量使用 DPO 或它的变体。但这里别说得太绝对不同模型的 post-training 流程差异很大。比如 Llama 2-Chat 公开流程主要是 SFT、拒绝采样和 PPO/RLHF很多社区模型为了降低成本才会把偏好优化换成 DPO。DPO 也是一个「目标」不是「方法」。它可以用全量微调实现也可以用 LoRA 实现。最常见的工业组合是LoRA DPO资源友好。实战选型怎么落地理解了两个维度的方案之后实战选型其实就清楚了。如果你是个人开发者或资源受限的小团队最经济的选择是QLoRA SFT。一张 4090 就能训 7B 模型几千条精心标注的指令-回答数据就能让模型学会你的领域任务。绝大多数实际项目走这条路就够了。如果你是中小企业、有几张 A100 但没有大集群可以选LoRA SFT。比 QLoRA 精度略好一点因为基础模型不量化训练速度也更快。如果你的需求是「让模型的回答风格更符合用户偏好」不只是格式正确还要好听可以在 SFT 之后再加一步LoRA DPO。先用 SFT 让模型学会回答格式再用 DPO 让回答风格对齐用户偏好。很多社区 Instruct 模型走的是 SFT - DPO 这条轻量路线而 Llama 2-Chat 这类大厂公开模型可能会用拒绝采样、PPO/RLHF 等更重的组合。如果你是大厂、有充足 GPU 资源、追求最高效果可以考虑全量微调 SFT甚至 RLHF。但要承担得起几十张 A100 的成本和工程复杂度。OpenAI 早期的 ChatGPT、Anthropic 的 Claude 都是走的这条最贵也最强的路。一个常见误区是「方案越重越好」。其实工程上恰恰相反能用轻量方案搞定的需求一定不要上重的。原因有三训练成本指数级上升、调参难度也上升、维护成本基础模型升级后要重新微调也上升。所以实战中绝大多数项目都在用 QLoRA SFT 这种最轻量的组合只有真的需求够特殊才会往上加方案。 面试总结回到开头那段对话问到大模型微调方案最重要的不是把名词列一遍而是讲清楚两件事。第一件事是前置判断微调是最后手段不是第一选择。能用 Prompt Few-shot 解决就别上微调能用 System Prompt 控制风格就别上微调能用 RAG 接知识库就别上微调。只有这些都试过不行再考虑微调。这一句说出来面试官就知道你不是「为了微调而微调」的新人。第二件事是两个正交维度「改哪些参数」全量微调 / LoRA / QLoRA和「学什么目标」SFT / DPO是两个独立的维度可以任意组合。能说出「LoRA 是方法、SFT 是目标可以用 LoRA 做 SFT也可以用 LoRA 做 DPO」比把这五个名词当作并列项罗列要深刻得多。讲清楚这两点之后再补一下实战选型经验。个人开发者用 QLoRA SFT有点资源用 LoRA SFT DPO社区主流大厂追求顶级用全量微调 RLHF。能说出这种「按资源 需求选组合」的工程视角就是面试加分项。最关键的一句话是绝大多数项目能用 QLoRA SFT 搞定没必要上更重的方案。这种「克制」的工程态度面试官会觉得你真的踩过微调的坑而不是只会堆方案。