迪图
发布于 2026-10-20 / 12 阅读
0
0

大模型微调完全指南:全参、LoRA、QLoRA、DoRA、GaLore 选型

大模型微调完全指南:全参、LoRA、QLoRA、DoRA、GaLore 选型

参数高效微调能以全参微调 90-98% 的效果,成本降到几十分之一。这篇给出可执行的选型决策。

先回答:什么时候该微调

微调的理由经常被误解。不是"为了让模型更聪明",而是这三类具体需求:

需求

更适合的方案

融合新知识

RAG(更新知识不该动权重)

固化输出格式/风格

微调

提升复杂指令执行能力

微调

降低推理成本

微调(蒸进权重,省掉长提示词)

最后一条经常被忽略:微调不一定为了"更强",也可以为了"更便宜"。把固定的长提示词蒸进权重,是把运营成本换成一次性投入。

三个前置条件

数据充足 —— 微调需要的数据规模通常比提示词示例和 RAG 知识库更大。收不到足够数据,微调效果有限且容易过拟合。

评测集包含原始能力项 —— 见下文"灾难性遗忘"。

目标明确 —— 微调不能用来教模型它没见过的事实,那是 RAG 的活。

显存墙:为什么全参微调不可行

要理解 PEFT 为什么存在,先算清全参微调要多少显存。

以 70B 模型为例,每个参数需要四份状态:

状态

精度

70B 所需

静态模型权重

BF16/FP16(2 字节/参数)

140 GB

梯度缓冲

BF16/FP16(2 字节/参数)

140 GB

AdamW 优化器状态

FP32(12 字节/参数)

840 GB

激活缓存

取决于上下文长度

50–200 GB

合计

超过 1120 GB

AdamW 优化器状态是主要瓶颈。 它要存一阶动量(4 字节)、二阶非中心化方差动量(4 字节)、FP32 主权重副本(4 字节),共 12 字节/参数。

1120 GB 意味着 16 张 A100/H100 80GB。这就是全参微调在 70B 规模上的现实。

方法对比矩阵

方法

基座精度

可训练比例(70B)

优化器显存(70B)

70B 显存需求

主要框架

全参微调

BF16

100%(70B)

~840 GB

~1120 GB(16 卡)

PyTorch FSDP, DeepSpeed ZeRO-3, Megatron-LM

LoRA

BF16/FP16 冻结

~0.25%(r=16 时约 175M)

~2.1 GB

165–180 GB(2 卡)

HF PEFT, Axolotl, Unsloth, Lit-GPT

QLoRA

4-bit NF4 双重量化

~0.25%(约 175M)

~0.5–2.1 GB

42–48 GB(单卡)

bitsandbytes, HF PEFT, Unsloth

DoRA

BF16 或 4-bit NF4

~0.26%(约 182M 含 m-vector)

~2.2 GB

44–50 GB(单卡)

HF PEFT(use_dora=True), Torchtune

GaLore

BF16/FP16

100%(低秩梯度)

~210 GB(SVD)

180–220 GB(3 卡)

galore-torch, HF Transformers

(显存数据基于 batch=1、序列长度 2048/4096、开启激活检查点)

7B 模型视角(更直观)

方法

可训练参数

显存

每任务磁盘

全参微调(FP16)

~70 亿(100%)

~70 GB

~14 GB

LoRA(r=16)

2000万–1亿( "我们花了 6 周整理 3000 条数据,又花 2 周训练。如果当初花 2 周整理数据、6 周训练,结果会更差。数据质量压倒一切。"

数据集的四条要求

要求

说明

一致性

格式统一——有的用要点有的用编号,模型会不一致

多样性

覆盖生产环境会遇到的完整输入分布

长度匹配

训练样本长度应匹配目标输出长度

正确切分

80/10/10,测试集必须完全留出且代表生产分布

永远不要污染测试集。

训练阶段的监控

训练损失下降 + 验证损失上升  →  过拟合,立即停止
训练损失和验证损失都下降     →  正常,继续
训练损失和验证损失都不降     →  学习率有问题

验证损失上升时停下来,不要因为"再训一轮可能更好"而继续。

多适配器服务:一个基座,多个变体

这是 LoRA 相对全参微调的一个被低估的优势:

一份基座模型(显存占用大头)
   ├── adapter-客服话术   (50 MB)
   ├── adapter-法律摘要   (50 MB)
   ├── adapter-代码审查   (50 MB)
   └── adapter-数据分析   (50 MB)

按请求类型加载对应适配器。用一个基座的显存开销,服务几十个专用模型。

vLLM 的 multi-LoRA 支持让这件事在生产环境成为可能——对 dense 和 MoE 层都支持。

选型决策

任务需求是什么?
│
├─ 融合新知识 / 知识常变 ──────────────► RAG
├─ 输出格式、风格、话术固化 ────────────► LoRA
├─ 需要极致成本效率 ──────────────────► QLoRA(单卡可行)
├─ 微调 3B 以下小模型 ─────────────────► 全参(LoRA 开销占比过高)
├─ 任务与基座分布差异极大(换语言)────► 全参或高 rank LoRA
├─ 需要真正全模型更新 + 显存受限 ─────► GaLore
└─ 相对 LoRA 有质量缺口(已验证)──────► DoRA 或全参

默认起点:LoRA r=16 + q_proj/v_proj。 大多数团队从 QLoRA 起步。

参考资料

  • Hu et al., *LoRA: Low-Rank Adaptation of Large Language Models* — https://arxiv.org/abs/2106.09685

  • Dettmers et al., *QLoRA: Efficient Finetuning of Quantized LLMs* — https://arxiv.org/abs/2305.14314

  • Liu et al., *DoRA: Weight-Decomposed Low-Rank Adaptation* — https://arxiv.org/abs/2402.09353

  • Zhao et al., *GaLore: Memory-Efficient LLM Training by Gradient Low-Rank Projection* — https://arxiv.org/abs/2403.03507

  • Hugging Face PEFT 文档 — https://huggingface.co/docs/peft/index


评论