Lightning-AI/litgpt项目中LoRA微调权重合并路径优化探讨

背景介绍

在Lightning-AI/litgpt项目中，模型微调是一个核心功能，目前支持两种微调方式：全参数微调(full.py)和LoRA微调(lora.py)。这两种方式在保存模型权重时采用了不同的命名约定，导致用户在后续操作时需要特别注意文件路径的差异，增加了使用复杂度。

现有问题分析

当前版本中存在以下文件命名不一致的情况：

1. 全参数微调(full.py)生成的权重文件命名为lit_model_finetuned.pth
2. LoRA微调(lora.py)生成的权重文件命名为lit_model_lora_finetuned.pth
3. 合并LoRA权重脚本(merge_lora.py)输出的文件命名为lit_model.pth

这种命名差异给用户带来了不必要的困扰，特别是在以下场景：

• 将微调后的模型转换回HuggingFace格式时
• 进行多轮微调时
• 文档说明和教程编写时

解决方案讨论

项目维护者提出了几种优化方案：

方案一：统一输出文件名

建议将merge_lora.py的输出文件名改为lit_model_finetuned.pth，使其与全参数微调的输出命名一致。这样可以使后续操作更加统一，简化文档说明。

方案二：采用更灵活的目录结构

在最新开发中，项目已改为将所有最终检查点放在"final"目录下，并使用统一的lit_model.pth文件名。这种结构具有以下优势：

• 目录结构更加清晰
• 文件名统一，便于脚本处理
• 支持多轮微调而无需重命名文件

方案三：LoRA权重特殊处理

考虑到LoRA微调的特殊性（只保存适配器权重而非完整模型），提出了更细致的处理方案：

1. 修改lora.py脚本，默认输出lit_lora_weights.pth而非lit_model.pth
2. 添加--merge_lora_weights标志，支持在微调时直接合并权重
3. 保持merge_lora.py脚本作为独立工具

技术实现考量

在讨论过程中，开发者们还深入探讨了几个关键技术点：

1. 权重合并时机：是否应该在加载模型时自动合并LoRA权重，而不是要求用户显式执行合并步骤。这可以简化用户操作，但需要确保合并过程的可靠性。

2. LoRA超参数保存：计划将LoRA相关超参数(如rank、alpha等)自动保存到检查点中，避免因参数不匹配导致的合并错误。

3. 推理性能优化：合并后的权重通常能提供更好的推理性能，而分开保存则节省存储空间，需要权衡这两方面需求。

最佳实践建议

基于讨论结果，对于使用Lightning-AI/litgpt进行模型微调的用户，建议：

1. 关注项目更新，及时了解文件命名和目录结构的变化
2. 对于LoRA微调，考虑是否需要合并权重以获得更好的推理性能
3. 在多轮微调场景下，利用统一的文件命名规范简化工作流程
4. 注意保存完整的配置信息，确保模型可复现性

未来发展方向

项目维护者计划进一步优化微调流程，包括：

• 实现自动化的权重合并机制
• 完善检查点元数据保存
• 简化不同微调方式间的操作差异
• 提供更清晰的文档和示例

这些改进将使Lightning-AI/litgpt在保持灵活性的同时，提供更加一致和用户友好的体验。