PEFT LoRA 适配器按任务切换的加载方案

PEFT 的 LoRA 适配器可以挂在同一个基础模型上，按任务名称切换，而不必为每个任务重新加载整套基础模型。实用做法是：启动时用 load_adapter() 把适配器放入模型，给每个适配器分配唯一名称；收到任务请求后调用 set_adapter()，生成前再用 active_adapters() 确认状态。这样客服、摘要、SQL 等任务可以共享一份基础模型，切换点也能被记录。

官方文档：https://huggingface.co/docs/peft/

先把基础模型和适配器名称固定下来

每个 LoRA 目录至少要能与基础模型匹配，并包含适配器配置和权重。文章示例使用占位路径，不表示已经在本机执行或代表某个公开模型。关键不是把目录字符串散落在业务代码里，而是维护一个任务到适配器名的白名单，例如 support、sql 和 summary。名称唯一，后面切换、审计和删除才不会互相覆盖。

用 load_adapter 预加载，再用 set_adapter 切任务

第一个适配器可以通过 PeftModel.from_pretrained 挂载，后续任务用 load_adapter 加载到同一个模型。加载完成后先不要假设它已经生效：官方接口说明新适配器不会自动成为 active adapter，必须显式调用 set_adapter。

from transformers import AutoModelForCausalLM, AutoTokenizer
from peft import PeftModel

base_id = "base-model-id"  # 这里放与 LoRA 训练时一致的基础模型
model = AutoModelForCausalLM.from_pretrained(base_id)
tokenizer = AutoTokenizer.from_pretrained(base_id)

model = PeftModel.from_pretrained(model, "./adapters/support", adapter_name="support")  # 首个适配器
model.load_adapter("./adapters/sql", adapter_name="sql")  # 载入 SQL 任务权重，名称必须唯一
model.load_adapter("./adapters/summary", adapter_name="summary")  # 载入摘要任务权重

task_to_adapter = {"客服": "support", "查询": "sql", "摘要": "summary"}  # 只允许白名单映射
task = "查询"
adapter_name = task_to_adapter[task]
model.set_adapter(adapter_name)  # 切换当前任务，未选中的适配器不参与这次生成
print(model.active_adapters())  # 记录激活名称，便于排查请求串任务

示例中的 base-model-id 和本地目录是占位符。生产环境应在启动阶段检查配置文件和权重是否完整；请求阶段只接收内部任务键，不直接把用户输入当作适配器路径，避免路径穿越和任意权重加载。

把切换放在请求边界，避免串任务

模型对象会保留当前激活状态，所以服务端若复用同一个实例，不能只在进程启动时切一次。应在每个请求进入生成函数前完成任务映射、set_adapter 和状态记录；未知任务直接拒绝或回退到基础模型。若要暂时不用 LoRA，可调用 disable_adapters()，恢复时再显式启用，而不是把某个适配器名称写成“空值”。

何时选择删除、卸载或 hotswap

如果任务集合小、适配器都常用，预加载后切换最直接，代价是它们会占用额外显存或内存。如果某个任务长期下线，使用 delete_adapter("sql") 释放该名称对应的适配器；若要彻底回到没有 PEFT 模块的模型，则使用 model = model.unload()，因为 unload() 不是原地操作。

高频替换且模型经过 torch.compile 时，可以考虑 hotswap：把新 LoRA 权重放进已有槽位，减少重复分配和重新编译。这里有两个边界：只讨论 LoRA，且所有待替换适配器的最大 rank 应在 enable_peft_hotswap(target_rank=...) 时预留；初始适配器最好覆盖最多目标层，否则换入更多目标层仍可能触发重新编译。

上线前的切换检查清单

1. 基础模型与每个适配器的训练基座一致，适配器类型也一致；不要把 LoRA 和另一种 tuner 当成同一个槽位。
2. 任务映射是白名单，适配器名唯一；每次生成前记录任务键、adapter_name 和 active_adapters()。
3. 未知任务有明确策略：返回参数错误、回退基础模型，或拒绝生成，不能沿用上一次请求的激活状态。
4. 若使用 hotswap，先统计所有 rank 和目标层，再决定 target_rank 与初始加载顺序。

常见问题

load_adapter 调用后为什么输出没有变化？

因为载入不等于激活。检查适配器名称是否唯一，并在生成前调用 set_adapter(name)，再读取 active_adapters()。

能不能每个请求都重新 load_adapter？

可以作为低频或临时方案，但会反复分配权重；固定任务更适合启动时预加载，编译模型的高频替换再评估 hotswap。

删除适配器后还能恢复吗？

delete_adapter 会移除该名称，恢复需要重新从目录或 Hub 加载。只是想暂时不用时，优先使用禁用或切换到其它适配器。