PEFT库中多LoRA适配器的modules_to_save重叠问题解析

在基于PEFT（Parameter-Efficient Fine-Tuning）库进行大语言模型微调时，开发者经常使用LoRA（Low-Rank Adaptation）适配器来实现高效参数微调。然而，当使用多个LoRA适配器时，一个关键的技术问题可能会影响模型的预期行为——即modules_to_save配置在多适配器场景下的不正确重叠问题。

问题现象

当开发者尝试为同一个基础模型加载多个LoRA适配器，且每个适配器配置了不同的modules_to_save参数时，会出现模块保存异常。具体表现为：后续加载的适配器会错误地继承先前适配器的modules_to_save配置，导致模块保存范围超出预期。

例如，假设：

• 适配器1配置modules_to_save=["lm_head"]
• 适配器2配置modules_to_save=["wte"]

在实际运行中，适配器2不仅会保存"wte"模块，还会错误地保存"lm_head"模块。这种非预期的行为可能导致模型微调效果偏离预期，并造成不必要的计算资源浪费。

技术原理分析

PEFT库中的modules_to_save机制设计用于在微调过程中保留指定模块的完整参数（而非低秩适配），这对于某些关键模块（如输出层）的微调尤为重要。在单适配器场景下，这一机制工作正常。但在多适配器场景中，问题出现在以下几个方面：

1. 状态维护不足：PEFT库在加载新适配器时，未能正确清除先前适配器的modules_to_save配置
2. 模块包装逻辑缺陷：ModulesToSaveWrapper类在处理多适配器时，错误地将所有适配器的保存模块合并而非隔离
3. 配置传播问题：适配器加载过程中，配置信息没有正确隔离，导致跨适配器污染

解决方案与修复

PEFT开发团队已经识别并修复了这一问题。核心修复点包括：

1. 适配器隔离机制：确保每个适配器的modules_to_save配置完全独立
2. 状态清理优化：在加载新适配器前，正确清理相关模块状态
3. 包装逻辑重构：改进ModulesToSaveWrapper对多适配器的处理逻辑

修复后的行为符合预期：

• 适配器1仅保存"lm_head"模块
• 适配器2仅保存"wte"模块
• 两者互不干扰，各自维护独立的模块保存状态

最佳实践建议

在使用PEFT多适配器时，开发者应注意：

1. 避免重复使用get_peft_model：对于多适配器场景，应使用add_adapter方法而非多次调用get_peft_model
2. 明确模块保存范围：仔细规划每个适配器需要保存的模块，避免功能重叠
3. 版本兼容性检查：确保使用的PEFT版本包含相关修复
4. 测试验证：在正式使用前，通过类似文中示例的测试代码验证模块保存行为

这一问题的解决显著提升了PEFT库在多适配器场景下的可靠性和预期行为一致性，为开发者提供了更精确的模型微调控制能力。