为 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/ -k <name-of-test>

这应该会更快地完成，并允许更快的迭代。但是，您仍然应该在创建 PR 之前运行整个测试套件，因为您的更改可能会无意中破坏乍一看无关的测试。

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

可能会发生这种情况：当您正在处理 PR 时，由于其他更改被合并，底层代码库会发生更改。如果发生这种情况——尤其是在存在合并冲突时——请使用最新更改更新您的分支。这可以是合并或变基，一旦 PR 准备好，我们将压缩并合并它。

PR 描述

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

如果您的代码进行了一些非平凡的更改，添加代码注释来解释这些更改可能也是一个好主意。例如，如果您不得不多次迭代您的实现，因为最明显的方法不起作用，那么这表明需要代码注释。

Bug 修复

请描述导致该 Bug 的情况。如果存在现有问题，请链接到它（例如，“解决 #12345”）。

理想情况下，当提供 Bug 修复时，它应该伴随着一个针对该 Bug 的测试。该测试应该在当前代码中失败，并在修复 Bug 后通过。在测试中添加一条注释，引用该问题或 PR。如果没有测试，则将来更难以防止回归。

添加新的微调方法

新的参数高效微调方法不断涌现。如果您想将一种新的有前景的方法添加到 PEFT，请遵循以下步骤。

1. 在开始实施新方法之前，请在 GitHub 上打开一个问题，提出您的建议。这样，维护者就可以为您提供一些早期反馈。
2. 请添加指向该方法来源（通常是论文）的链接。应该在那里提供一些证据，证明人们普遍有兴趣使用该方法。我们不会添加新发布但没有证据表明需求的方法。
3. 在实现该方法时，寻找已经存在的现有实现作为指导是有意义的。此外，在构建代码时，请从其他 PEFT 方法中汲取灵感。例如，如果您的方法类似于 LoRA，那么以类似的方式构建代码甚至在有意义的地方重用一些函数或类是有意义的（一些代码重复是可以的，但不要过度）。
4. 理想情况下，除了新方法的实现之外，还应该有示例（笔记本、脚本）、文档和一个广泛的测试套件来证明该方法适用于各种任务。但是，这可能更具挑战性，因此只提供实现和至少一个工作示例是可以接受的。文档和测试可以在后续的 PR 中添加。
5. 一旦您拥有看起来有效的东西，即使它还没有处于可合并状态，也请不要犹豫创建草稿 PR。维护者很乐意在此过程中为您提供反馈和指导。

添加其他功能

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

新功能通常应伴随着测试和文档或示例。如果没有后者，用户将难以发现您酷炫的新功能。

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