参数高效微调（PEFT）如何减少计算成本？
- 标签：大模型、AI、微调
🏛 业务架构师
PEFT 降低计算成本的机制，我从三个层面拆：
1. 反向传播的参数砍量：训练时显存大头是"参数梯度+优化器状态"，且与可训练参数量成正比。PEFT 冻结主干，梯度和 Adam 优化器状态（约为参数量的 2 倍内存）只需覆盖那不到 1% 的增量参数——训练状态显存从几十 GB 降到几百 MB 级。
2. 量化叠加（QLoRA 的杠杆）：QLoRA 把冻结的基座量化到 4bit 存储（显存再降 4~8 倍），只对 LoRA 旁路保留高精度计算，还配合分页优化器防峰值溢出——综合效果：7B 模型微调从"8×A100 集群"降到"1 张消费级显卡"，硬件门槛降两个数量级。
3. 存储与分发的成本：全量微调每个任务保存完整模型（GB 级）；PEFT 只保存适配器（几十 MB），版本管理、多场景热插拔、云端分发都轻量化。
业务翻译：训练一次微调实验的边际成本从"万元级"降到"百元级"，这意味着业务团队可以高频试错——以前一个季度验证一个想法，现在一周验证五个。试错速度才是 AI 业务进化的核心变量，PEFT 本质上买到的不是省钱的模型，而是更快的迭代频率。
🏗 系统架构师
PEFT 降计算成本的机理，我从显存、算力、存储三本账讲，全部源于"可训练参数 <1%"这一个事实：
显存账（决定能否训得动）：训练显存 = 权重 + 梯度 + 优化器状态。Adam 全量微调时优化器状态是权重的 2 倍（两份动量），7B 模型 bf16 下训练态约 70GB+；LoRA 冻结主干——梯度只对 A/B 小矩阵存在，优化器状态也只有它们的，显存降到 ~20GB 级；QLoRA 再进一步（主干 4bit 量化），7B 压到单卡 24GB、70B 压到 48GB 可训。硬件门槛从多机降到单卡，成本差 1~2 个数量级。
算力账：反向传播只经过需要梯度的路径计算，冻结参数不存激活图、不更新，计算量（FLOPs）和训练时间显著下降——同任务 LoRA 比 Full FT 快 2~3 倍是常态。
存储与部署账：产物是几十 MB 的适配器而非几十 GB 的完整模型，多业务场景一份底座 + N 个 LoRA 文件，存储、分发、回滚成本都降一个量级；推理端 vLLM multi-LoRA 支持共享底座动态挂载，GPU 利用率最大化。
本质：PEFT 是把"任务适配"这个低本征维度问题从"全参数空间"里解耦出来——不为 1% 的需求付 100% 的训练成本。
💻 全栈开发专家
PEFT 减少计算成本要从三个账本看：
1. 训练态显存账（大头）。全量微调每参数要存：权重 FP16(2B) + 梯度 FP16(2B) + Adam 动量和方差 FP32(8B) ≈ 12~16 字节/参数。7B 就是 100GB+。LoRA 冻结主干后：主干权重前向时加载即可（no grad，无优化器状态）、梯度只存在于 BA 小矩阵、优化器状态随可训练参数缩千倍——7B 的 LoRA 训练显存能压到 20GB 内，QLoRA（基座 4bit）再压到 10GB 级。
2. 反向传播计算账：反向传播只对 LoRA 分支和必要路径计算梯度，冻结层跳过大部分梯度计算，单步 FLOPs 明显下降；配合梯度检查点（gradient checkpointing）还能再换时间省显存。
3. 存储与推理账：每个任务存几十 MB 适配器 vs 14GB 全量权重；LoRA 推理前 merge 回主干，零额外推理延迟；生产上一个基座 + N 个 LoRA 热加载（vLLM --enable-lora --max-lora-rank 64），多租户共享同一份基座显存，这个成本差是数量级的。
一句话总结：PEFT 把「微调门槛」从「多卡 A100 集群」降到「一张 4090」，把「多任务部署」从「N 份完整模型」变成「1 份基座 + N 个插件」——这正是它成为工业默认的原因。