3. 参数高效微调概述：全量微调 vs 参数高效微调（PEFT）、主流方法对比
当我们准备将大语言模型（LLM）适配到特定业务场景时，首先面临的核心决策是：采用全量微调（Full Fine-tuning）还是参数高效微调（Parameter-Efficient Fine-Tuning, PEFT）。全量微调虽然效果上限高，但需要为每个任务维护一份完整的模型副本，训练和推理成本极高。而PEFT技术通过冻结预训练模型的大部分参数，仅训练少量新增或选中的参数，在显著降低计算与存储开销的同时，力求保持甚至提升任务性能。本章将系统对比全量微调与PEFT的差异，并深入剖析Adapter、Prefix-Tuning、Prompt-Tuning、LoRA这四种主流PEFT方法的原理、适用场景与工程权衡。
3.1 全量微调与PEFT的核心原理与本质差异
核心原理
全量微调是指对预训练模型的所有参数（包括注意力层、前馈网络、层归一化等）进行梯度更新。以LLaMA-7B为例，全量微调需要更新约70亿个参数，每个训练步的显存占用通常需要4-8张A100-80G显卡（取决于批次大小与序列长度）。其数学本质是：θ* = argmin_θ L(θ; D_task)，其中θ为全部模型参数。
PEFT的核心思想是冻结预训练参数θ0，仅优化一小部分额外参数Δθ，即：θ* = θ_0 + Δθ*，其中Δθ的参数量通常不足总参数的1%。这带来三个直接收益：显存占用降低（仅需存储梯度与优化器状态的一小部分）、训练速度提升（反向传播仅计算部分层）、部署灵活（每个任务只需保存一个小的增量文件）。
判断方法：何时选择全量微调，何时选择PEFT
| 决策维度 | 选择全量微调 | 选择PEFT |
|---|---|---|
| 数据规模 | 任务数据量 > 10万条高质量标注 | 数据量在几千到几万条之间 |
| 算力资源 | 拥有多卡A100/H100集群 | 单卡或消费级GPU（如RTX 4090） |
| 任务类型 | 领域差异极大（如医疗诊断）且数据充足 | 通用指令遵循、风格迁移、轻量知识注入 |
| 部署需求 | 单一任务，可接受大模型体积 | 多任务多租户，需快速切换 |
| 灾难性遗忘风险 | 风险较高，需正则化 | 风险低，冻结原参数天然保护通用能力 |
案例拆解：一个客服意图识别任务的成本对比
假设某电商平台需要将LLaMA-7B微调为客服意图分类器，训练数据为2万条对话样本。使用全量微调需要4张A100-80G，训练耗时约6小时，单次训练成本约120元（按云服务每小时5元计算），且每次更新需重新部署7GB模型。改用LoRA（秩r=8）后，仅需1张RTX 4090（24G显存），训练耗时2.5小时，成本约15元，增量文件仅14MB。更重要的是，LoRA训练后原模型保持不变，可以同时服务多个不同任务的LoRA增量，切换时间从分钟级降至毫秒级。
常见误区与复盘
- 误区一：认为PEFT效果一定不如全量微调。实际上在中等规模数据下，LoRA在多项基准上可达到全量微调95%-99%的性能。
- 误区二：忽略优化器状态显存。即使只训练少量参数，如果使用AdamW，优化器状态仍会占用约3倍于训练参数的显存。
- 误区三：全量微调后模型通用能力下降。这是灾难性遗忘的典型表现，而PEFT天然规避了此问题。
3.2 主流PEFT方法深度对比
核心原理：四种方法的机制拆解
Adapter（Houlsby et al., 2019）在Transformer的每个子层（注意力层和前馈层）之后插入一个瓶颈结构：先降维到dbottleneck（通常为原隐藏维度的1/16），经过非线性激活，再升维回原始维度。训练时仅更新Adapter模块和层归一化参数。其优势在于结构灵活，但会增加推理延迟（约5%-10%）。
Prefix-Tuning（Li & Liang, 2021）在每一层的Key和Value矩阵前拼接一组可训练的前缀向量。例如，对于12层Transformer，每层前缀长度为20，隐藏维度768，则总参数量为12×2×20×768≈36.8万。前缀向量通过独立的MLP进行参数化，以增强训练稳定性。
Prompt-Tuning（Lester et al., 2021）仅在输入层添加可训练的软提示（soft prompt）向量。与Prefix-Tuning不同，它不修改每一层的内部表示，而是将提示向量与输入嵌入拼接后送入模型。参数量极小（通常只有几千到几万），但效果对模型规模敏感——模型越大，效果越好。
LoRA（Hu et al., 2021）基于低秩分解思想，将权重更新量ΔW分解为两个低秩矩阵的乘积：ΔW = BA，其中B∈Rd×r，A∈Rr×k，秩r远小于d和k。训练时冻结原始权重W0，前向计算变为h = W0x + BAx。推理时可将BA合并到W0中，实现零额外延迟。
| 方法 | 参数量占比 | 推理延迟 | 显存占用 | 适用场景 | 关键超参数 |
|---|---|---|---|---|---|
| Adapter | 0.5%-5% | 增加5%-10% | 低 | 多任务共享底座 | bottleneck维度、层位置 |
| Prefix-Tuning | 0.1%-2% | 增加2%-5% | 中 | 生成任务、长文本 | 前缀长度、重参数化MLP |
| Prompt-Tuning | 0.01%-0.1% | 几乎无 | 极低 | 大模型（>10B） | 提示长度、初始化方式 |
| LoRA | 0.1%-1% | 无（可合并） | 低 | 通用首选、多任务 | 秩r、alpha缩放、目标模块 |
判断方法：如何根据任务选择最优方法
- 任务复杂度评估：如果任务仅需调整输出风格（如让模型更幽默），Prompt-Tuning即可胜任；如果任务需要新的推理能力（如数学解题），应选择LoRA或Adapter。
- 模型规模考量：对于7B以下模型，Prompt-Tuning效果不稳定，建议使用LoRA；对于70B以上模型，Prompt-Tuning性价比最高。
- 推理延迟敏感度：在线服务对延迟要求高，应选择LoRA（推理时可合并权重）或Prompt-Tuning（仅增加少量输入）。
- 多任务部署需求：如果需要在一个底座上服务多个任务，Adapter和LoRA都支持动态加载，但LoRA的增量文件更小，切换更轻量。
案例拆解：LoRA在代码生成任务中的调优实战
某金融科技公司需要将CodeLlama-7B微调为SQL生成模型，训练数据为5万条“自然语言→SQL”对。初始使用LoRA（r=8, alpha=16），在验证集上准确率为78%。分析发现，模型在涉及多表JOIN的复杂查询上表现不佳。进一步诊断：将秩r提升至16，并同时微调注意力层的q_proj和v_proj矩阵，准确率提升至84%。随后调整alpha为32（保持alpha/r=2），并增加训练轮次至5轮（原3轮），最终准确率达到87%。整个调优过程仅耗时4小时，显存占用稳定在18GB。复盘发现，秩r的增大有效提升了模型对复杂关系的建模能力，而alpha的同步调整避免了训练不稳定。
常见误区与总结复盘
- 误区一：将LoRA应用于所有线性层。实际上，仅微调注意力层的q_proj和v_proj通常就能达到较好效果，微调全部线性层会带来约2倍训练开销。
- 误区二：忽略Prefix-Tuning的序列长度限制。前缀向量会占用输入序列长度，对于长文本任务需谨慎设置前缀长度。
- 误区三：Adapter的放置位置随意。经验表明，放置在层归一化之前比之后效果更好，且不应在Embedding层添加Adapter。
- 误区四：Prompt-Tuning的提示向量初始化使用随机值。使用预训练词嵌入（如特定任务的种子词）初始化，可提升收敛速度和最终效果。