为 PEFT 做贡献

我们很高兴接受对 PEFT 的贡献。如果您计划贡献，请阅读本文档以使过程尽可能顺利。

安装

对于 PEFT 的代码贡献，您应该选择“从源码”安装方法。

如果您是第一次创建拉取请求，请遵循 GitHub 上的创建拉取请求指南。

测试和代码质量检查

无论贡献类型如何（除非只涉及文档），您都应在创建 PR 之前运行测试和代码质量检查，以确保您的贡献不会破坏任何内容并遵循项目标准。

我们提供了一个 Makefile 来执行必要的测试。运行以下代码进行单元测试

make test

运行以下命令之一，可以仅检查代码质量和样式，或检查并修复它们

make quality  # just check
make style  # check and fix

您还可以设置 pre-commit，使其作为 Git 提交钩子自动运行这些修复。

$ pip install pre-commit
$ pre-commit install

运行所有测试可能需要一些时间，因此在开发过程中，仅运行与您的更改相关的特定测试会更有效率，例如通过

pytest tests/<test-file-name> -k <name-of-test>

这将更快完成并允许更快的迭代。

如果您的更改特定于某种硬件设置（例如，需要 CUDA），请查看 tests/test_gpu_examples.py 和 tests/test_common_gpu.py，以确定是否有必要在那里添加测试。如果您的更改可能影响模型的保存和加载，请使用 --regression 标志运行测试以触发回归测试。

在您处理 PR 的过程中，底层代码库可能会因其他更改被合并而发生变化。如果发生这种情况——尤其是在出现合并冲突时——请用最新更改更新您的分支。这可以是一个合并或一个 rebase，一旦准备好，我们将压缩并合并 PR。如果可能，请避免强制推送以方便审查。

PR 描述

在打开 PR 时，请为您提议的更改提供一个良好的描述。如果它与其他问题或 PR 相关，请引用它们。提供一个好的描述不仅有助于审阅者更好更快地审查您的代码，还可以作为后续提交消息的基础，这有助于项目的长期维护。

如果您的代码进行了一些非平凡的更改，最好在代码中添加注释来解释这些更改。例如，如果您因为最显而易见的方式行不通而不得不多次迭代您的实现，这表明需要添加代码注释。

错误修复

请描述导致该错误的具体情况。如果已有相关 issue，请链接到它（例如，“解决 #12345”）。

理想情况下，提供错误修复时，应附带针对该错误的测试。该测试应在当前代码下失败，在修复后通过。在测试中添加注释，引用相关 issue 或 PR。没有测试，未来更难防止回归。

添加新的微调方法

新的参数高效微调方法层出不穷。如果您想向 PEFT 添加一种新的、有前景的方法，请遵循以下步骤。

1. 在开始实施新方法之前，请在 GitHub issue 中提出您的建议。这样，维护者可以给您一些早期反馈。
2. 请添加该方法的来源链接（通常是一篇论文）。论文应处于最终状态，以避免在开发过程中因审稿人反馈等原因导致需求变更。
3. 在实施该方法时，寻找现有的实现作为指导是有意义的。此外，在组织代码时，请参考其他 PEFT 方法。例如，如果您的方法与 LoRA 相似，那么类似地组织代码，甚至在合理的情况下重用一些函数或类都是有意义的（一些代码重复是可以接受的，但不要过度）。
4. 理想情况下，除了新方法的实现之外，还应该有
   • 示例（笔记本、脚本）
   • 文档
   • 详尽的测试套件，证明该方法能正确集成到 PEFT 中
   • 实验设置，以运行基准测试
5. 一旦您有了看起来可行的东西，即使它尚未处于可合并状态，也不要犹豫创建草稿 PR。维护者很乐意在此过程中为您提供反馈和指导。

添加其他功能

最好先在 GitHub 上开一个 issue，提出添加新功能的建议。这样，您可以在花费太多时间实施之前，与维护者讨论添加该功能是否合理。

新功能通常应附有测试和文档或示例。没有后者，用户将很难发现您酷炫的新功能。

对代码的更改应以向后兼容的方式实现。例如，现有代码在功能合并后应继续以同样的方式工作。