8000 ENH: Extend the regex for rank/alpha pattern by BenjaminBossan · Pull Request #2419 · huggingface/peft · GitHub
[go: up one dir, main page]

Skip to content

ENH: Extend the regex for rank/alpha pattern #2419

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conversation

BenjaminBossan
Copy link
Member
@BenjaminBossan BenjaminBossan commented Mar 11, 2025

Supersedes #2382

Right now, the regex used to match the keys passed for rank_pattern and alpha_pattern requires that either:

  1. The module name is identical to the key
  2. The module name having a prefix and then ending on the key

This is restrictive, since it doesn't allow to disambiguate between all cases. E.g. if we have a model with these attributes:

  • model.foo
  • model.bar.foo

Then we:

  • can target both by passing "foo" to the rank_pattern / alpha_pattern dict
  • can target only model.bar.foo by passing "bar.foo"
  • cannot target only model.foo

This PR makes it possible to pass "^foo" as a key. This way, only model.foo but not model.bar.foo is targeted, as the latter's name does not start with "foo".

As a general rule for users, if they intend to have a full match, they should pass the full name of the module preceded by a ^. This is the least ambiguous way.

When running the test case with the old code, all the test cases with ^ will fail, which is fine, since ^ was not working anyway. At the same time, all test cases not using ^ pass, which means they are backwards compatible.

Some changes related to this PR:

  • I renamed a function that tests rank_pattern / alpha_pattern to make it easier to find
  • I updated the docs to include a section on rank_pattern and alpha_pattern
  • Some PEFT method configs mention rank_pattern / alpha_pattern even though they are not supported. These are probably just copy-paste errors that slipped through review.
  • I updated some docstrings and help texts about rank_pattern / alpha_pattern that had syntax errors.
  • I updated LoHa and LoKr to use the same logic as LoRA for rank_pattern / alpha_pattern.

Supersedes huggingface#2382

Right now, the regex used to match the keys passed for rank_pattern and
alpha_pattern requires that either:

1. The module name is identical to the key
2. The module name having a prefix and then ending on the key

This is restrictive, since it doesn't allow to disambiguate between all
cases. E.g. if we have a model with these attributes:

- model.foo
- model.bar.foo

We cannot currently target just model.foo. (We can already target only
model.bar.foo by passing "bar.foo" as a key to the rank_pattern /
alpha_pattern dict).

This PR makes it possible to pass "^foo" as a key. This way,
model.bar.foo is not targeted, as the key does not start with "foo".

As a general rule for users, if they intend to have a full match, they
should pass the full name of the module preceded by a ^. This is the
least ambigious way.

When running the test case with the old code, all the test cases with ^
will fail, which is fine, since ^ was not working anyway. At the same
time, all test cases not using ^ pass, which means they are backwards
compatible.
@HuggingFaceDocBuilderDev

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

Some PEFT methods falsely claimed in docs that they support rank/alpha
pattern when they don't, this was just a copy paste error.
@BenjaminBossan
Copy link
Member Author

@sayakpaul @hlky After some internal discussion, Marian and I came up with this new solution which would replace the initial proposal of having "fully qualified" keys from #2382. With this suggestion, it should be enough to add the ^ prefix to a layer name to make it "fully qualified" while not requiring any flag to toggle the semantics of the keys. If you could check that this new solution works to solve the initial problem in huggingface/diffusers#10808, that would be great.

@sayakpaul
Copy link
Member

@BenjaminBossan thanks! Posted an update here.

TL;DR: works like a charm.

Copy link
Collaborator
@githubnemo githubnemo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks for the revision :)

@BenjaminBossan BenjaminBossan merged commit 2f063e6 into huggingface:main Mar 13, 2025
14 checks passed
@BenjaminBossan BenjaminBossan deleted the enh-rank-pattern-alpha-pattern-better-matching branch March 13, 2025 11:53
@BenjaminBossan
Copy link
Member Author

@sayakpaul it's merged. A new PEFT release will be happening soon (we aim for next week).

@sayakpaul
Copy link
Member

Thanks, @BenjaminBossan. Would be nice to get a nudge once that happens. I will get my PR out of DRAFT.

Guy-Bilitski pushed a commit to Guy-Bilitski/peft that referenced this pull request May 13, 2025
Supersedes huggingface#2382

Right now, the regex used to match the keys passed for rank_pattern and
alpha_pattern requires that either:

1. The module name is identical to the key
2. The module name having a prefix and then ending on the key

This is restrictive, since it doesn't allow to disambiguate between all
cases. E.g. if we have a model with these attributes:

- model.foo
- model.bar.foo

We cannot currently target just model.foo. (We can already target only
model.bar.foo by passing "bar.foo" as a key to the rank_pattern /
alpha_pattern dict).

This PR makes it possible to pass "^foo" as a key. This way,
model.bar.foo is not targeted, as the key does not start with "foo".

As a general rule for users, if they intend to have a full match, they
should pass the full name of the module preceded by a ^. This is the
least ambigious way.

When running the test case with the old code, all the test cases with ^
will fail, which is fine, since ^ was not working anyway. At the same
time, all test cases not using ^ pass, which means they are backwards
compatible.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants
0