参数高效微调（PEFT）的核心思路是什么？列举 3 种典型方法
- 标签：大模型、AI、微调、PEFT
🏛 业务架构师
PEFT 的核心思路一句话：预训练模型已学到足够好的通用表征，微调只需要在"低维子空间"里做方向性微调，没必要动全部参数。
三种典型方法：
- LoRA（低秩适配）：在原模型的权重矩阵旁路加一对低秩矩阵 A×B（秩 r 常取 8~64），训练时冻结原权重、只更新这对小矩阵。数学假设是"微调引起的变化是低秩的"，实践证明成立。推理时可把 A×B 合并回原权重，零额外延迟。
- Prefix Tuning / P-Tuning：在每层输入前拼接一小段可学习的"虚拟 token"（连续提示向量），只训练这些向量。参数更少，但效果通常不如 LoRA，且占用上下文窗口。
- Adapter Tuning：在 Transformer 层间插入小型瓶颈网络（降维-升维），只训练插入模块。效果稳定但增加推理延迟，现多被 LoRA 取代。
业务翻译：这三种方法本质都是"给 pretrained 模型外挂一个小旋钮"——不动发动机，只调油门。差异在于旋钮装在哪：LoRA 装在权重上（性能最好）、Prefix 装在输入上（最轻）、Adapter 装在层间（最直白）。企业落地选 LoRA 即可，它已成为行业标准，工具链（Unsloth、PEFT 库）最成熟，人才最好找。
🏗 系统架构师
PEFT 核心思路：冻结预训练主干不动，在旁路注入少量可训练参数，把"适配任务"压缩到一个低维子空间里完成。理论支撑是预训练模型的任务适配具有低本征维度——微调时参数改变的自由度其实很小。
三种典型方法：
- LoRA（低秩适配）：对目标权重 W 冻结，学习增量 ΔW = B·A（A: d×r, B: r×d，r 常取 8~64）。前向变为
Wx + BAx。可训练参数量从 d² 降到 2dr（千分之一量级）；推理时 BA 可合并进 W，零额外推理延迟——这是它胜出的工程关键； - Prefix Tuning / P-Tuning：在每层（或输入层）注意力前拼接可学习的软提示向量（连续 prompt），只训这些向量。不动权重结构，但占用上下文长度，且对指令复杂任务效果略逊 LoRA；
- Adapter Tuning：在 Transformer 层间串联"降维-升维"瓶颈模块（bottleneck），只训模块。效果稳，但推理时多串行计算，有延迟代价——这也是 LoRA 出现后它式微的原因。
我的选型：默认 LoRA（显存紧/消费级卡用 QLoRA）；输出风格与 prompt 强相关的轻量适配可试 Prefix；要一份底座多业务复用、按需热插拔，LoRA 适配器仓库是标准架构。
💻 全栈开发专家
PEFT 核心思路就一句：预训练学到的特征已经足够好，适配新任务不需要改动整个权重矩阵，只需要在低维子空间里做增量。
三种典型方法：
- LoRA（低秩适配）：假设微调带来的权重变化 ΔW 是低秩的，用两个小矩阵乘积近似：
W' = W₀ + B·A（B 是 d×r，A 是 r×k，r=8~64）。只训 A、B，推理时可合并回 W 零开销。数学直觉：预训练权重本 身满秩但「任务间的差异」信息量小，低秩足够表达。 - Prefix Tuning：在每层输入前拼 k 个可训练的连续向量（虚拟 token），冻结模型全部参数。相当于学一段「任务提示软提示」，参数极少但表现弱于 LoRA，且占上下文长度。
- Adapter Tuning：在 Transformer 层间插入瓶颈 MLP（down-up 投影），只训这个插件。效果稳，但推理多两次矩阵乘，延迟增加——被 LoRA 的「可合并」特性比下去了。
工程对比：可训练参数量 Prompt < Prefix < Adapter ≈ LoRA；效果和通用性 LoRA 最好。我的默认就是 LoRA（目标模块 q/k/v/o_proj + FFN），分类小任务才考虑 Prefix。选 r 的经验：任务越「偏」（风格差异大）r 越大，16 起步，看训练 loss 再调。