PEFT

PEFT 是 Parameter-Efficient Fine-Tuning，即只训练较少参数的微调方法族，而不是“性能估计和建模”。

方法族

  • 低秩更新：LoRA、QLoRA
  • Adapter：在网络中加入小型可训练模块
  • Soft prompt：Prompt Tuning、Prefix Tuning、P-Tuning

边界

LoRA 不是 prompt tuning。标准 LoRA 直接学习低秩更新矩阵，不需要先对原始权重做 SVD。

取舍

  • 优点：训练参数少、优化器状态小、可保存多个 adapter。
  • 代价：能力上限、target modules、rank、数据质量和部署方式仍需实验决定。
  • 部署时要区分 adapter 单独加载、动态多 adapter 与 merge 后模型。

PEFT 究竟减少了什么

冻结基座后，训练参数和对应的梯度、优化器状态大幅减少；但前向仍要经过完整基座，激活、通信、序列长度和推理 KV cache 并不会因为 adapter 很小而自动消失。可把资源链拆成：

1
2
3
4
可训练参数 ↓
→ grad/optimizer state ↓
→ 训练显存与 checkpoint ↓
但 activation、base weight 读取、通信与推理成本仍在

方法选择顺序

  1. 先判断是否需要改变大量内部表示；需要更大容量时提高 LoRA rank 或考虑全参微调。
  2. 再看显存瓶颈来自权重还是激活：权重受限可看 QLoRA，激活受限仍要做序列/检查点/批大小优化。
  3. 最后按部署形态选择 adapter 独立、多 adapter 路由还是 merge；这会改变延迟、回滚和多租户隔离。

验收至少包含：目标模块命中率、可训练参数比例、训练前后基座回归集、adapter 合并前后 logits/生成一致性。

同一个“参数少”可能解决不同瓶颈

LoRA 主要减少需要更新的权重、梯度和 optimizer state；Prefix/Prompt Tuning 通过可学习 token 改变输入条件；Adapter 在层间增加可训练变换。三者的可训练参数都可能很少，但激活、前向 FLOPs、序列长度和部署形态不同。若 OOM 发生在长序列 backward，换 LoRA 可能几乎没用；若问题是多个租户共享一份大基座，adapter 独立加载反而更合适。

选择方法时先回答三个具体问题：任务是否需要修改 attention/FFN 内部表示？一个租户是否要挂多个 adapter？最终是合并成单模型，还是运行时按请求切换？前者决定注入位置和 rank，后两者决定权重布局、热加载和延迟。不能用“PEFT 显存更省”替代这些工程边界。

合并并不总是无损

理论上 LoRA merge 是把 W+sBA 写回基座；量化基座、低精度 kernel、权重转置和 tied embedding 会让 merge 前后的算子路径不完全一致。验收时固定一组 logits 输入，比较 adapter 模式、merged FP 模式和部署导出模式的最大误差，再测目标任务。多 adapter 并存时，还要确认切换请求不会把上一个租户的增量留在 cache 或持久化权重里。