LoRA 合并与多适配器部署

一句话定义

训练好的 LoRA 有两条出路：合并（把 BA 加回基座权重，得到无额外开销的独立模型）或多适配器服务（一个基座按请求热切换不同 LoRA），本节讲清两者的取舍与操作。

为什么重要

合并与否直接决定部署架构：合并后是「一个任务一个模型」，简单但基座显存翻倍占用；多适配器是「一个基座 N 个任务」，省显存、可热更新，但依赖服务层支持。选错路径会在上线前被迫重构，也常出现「合并后效果掉了」这种临门一脚的翻车。

前置知识

kp-005 的 W′ = W₀ + (α/r)·BA 合并公式；kp-006 的 alpha 语义。

核心概念

• 合并（merge）：W′ = W₀ + (α/r)·BA，产出与原模型同构的完整权重文件。
• 未合并推理：推理时保留独立分支 h = W₀x + (α/r)BAx，多一次小矩阵乘。
• 多 LoRA 服务：基座权重常驻显存共享，各请求按需换载自己的 adapter（vLLM、S-LoRA 支持）。
• 合并精度：合并加法建议在 fp32 下进行再转回 BF16，避免低精度舍入吃掉微调增量。

原理与机制

合并的数学是平凡的加法，工程风险在精度与缩放：LoRA 增量 (α/r)BA 的量级通常只有基座权重的百分之一量级，若在 BF16 下逐元素相加，舍入误差可能与增量同量级，表现为「合并后格式遵从率下降几个点」。因此规范流程是：加载基座为 fp32 → 载入 adapter → merge → 转回目标精度保存。

多适配器的价值来自共享率：LoRA 参数通常只占基座的 0.1%-0.6%，10 个任务的 adapter 加起来不到 1GB，而合并部署 10 个任务要 10 份完整基座。代价是服务层复杂度与换载延迟。混合策略也常见：主力任务合并成独立模型保延迟，长尾任务用多 LoRA 挂载。

图示

adapter (20MB) ──merge──► 完整模型 (15GB) ──► 单任务、零延迟、架构简单
      │
      └──多LoRA服务──► 基座(共享) + N×adapter ──► 省显存、热切换、依赖vLLM

直观类比

合并像把插件烧录进系统做成定制版安装盘（独立、快、改不了）；多适配器像系统保留插件机制，按用户加载不同插件（灵活、省磁盘，但依赖插件框架稳定）。

实例或案例

某 SaaS 需要为 30 个客户维护各自的语气微调：合并方案需 30×14G = 420G 显存，不可行；vLLM 多 LoRA 方案一个 14B 基座（约 28G）+ 30 个各 30MB 的 adapter，单卡 48G 即可服务，新增客户只需上传一个 adapter 文件，无需重启。

操作步骤

from peft import PeftModel
base = AutoModelForCausalLM.from_pretrained("base", torch_dtype=torch.float32)
model = PeftModel.from_pretrained(base, "adapter_dir")
model = model.merge_and_unload()          # fp32 下合并
model = model.to(torch.bfloat16)
model.save_pretrained("merged_out")

服务多 LoRA（vLLM）：

vllm serve base-model \
  --enable-lora \
  --lora-modules taskA=./adapters/taskA taskB=./adapters/taskB \
  --max-lora-rank 32

排错清单

• 合并后效果下降：检查合并是否在 fp32 下进行；核对 adapter 的 alpha/r 与训练配置一致；确认 tokenizer/config 一并保存。
• 合并后文件过大或结构异常：merge_and_unload 前确认模型是 PEFT 包装对象；保存时不要把 adapter 目录与合并目录混用。
• vLLM 加载 LoRA 报 rank 超限：--max-lora-rank 需 ≥ adapter 的 r。
• 切换 adapter 偶发错误：检查各 adapter 的目标模块与基座层名一致。

常见误区

• 合并必做：多任务/频繁迭代场景，不合并的多 LoRA 服务在显存与迭代速度上更优。
• 合并后与训练时行为应当完全一致：受合并精度影响可能有微小偏差，验收要用合并后的模型重跑评测（kp-025）。
• adapter 文件可以直接当模型分发：adapter 只含增量，必须配合原始基座（版本一致）才能使用。

与其他知识点的关系

量化导出的完整流程见 kp-028；推理服务化与压测见 kp-029；合并后要重跑回归评测见 kp-026。

延伸阅读

Han et al. 2023《S-LoRA: Serving Thousands of Concurrent LoRA Adapters》。

自测题

1. 为什么建议在 fp32 下执行合并？

答：LoRA 增量远小于基座权重，低精度逐元素相加的舍入误差可能吞掉增量，fp32 合并后再转目标精度可避免「合并掉点」。

1. 什么情况选多 LoRA 服务而不是合并？

答：多任务共享一个基座、任务频繁增删或迭代、显存预算不允许每个任务一份完整基座时。

1. 分发微调成果给别人，最少要带哪些文件？

答：若带 adapter：adapter 权重 + 适配器配置 + 明确的基座模型与版本号；若带合并模型：完整权重 + tokenizer/config。