Repository navigation
Guard target_parameters use for peft<0.17.0 - #7119
Merged
Merged
Conversation
|
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. |
Member
|
LGTM, thanks.
|
qgallouedec
approved these changes
Sep 9, 2026
1 task done
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
LoraConfig.target_parametersonly exists from peft 0.17.0, but TRL uses it unconditionally in three places. With the floor atpeft>=0.13.0(#7102), 0.13 to 0.16 are supported versions on which those paths raise.Motivation
get_peft_configintrl/trainer/utils.pypassestarget_parameters=toLoraConfigon every call, sotrl <cmd> --use_peftraisesTypeError: LoraConfig.__init__() got an unexpected keyword argument 'target_parameters'on peft below 0.17. This hits all seven CLI scripts (sft,dpo,grpo,rloo,kto,reward,distillation), whether or not the user asked for--lora_target_parameters.default_config.target_parametersbefore testing the peft version, so passing a pre-wrapped LoRAPeftModelraisesAttributeError: 'LoraConfig' object has no attribute 'target_parameters'. Reordering alone does not fix it: the existing< 0.20.0test is true on 0.13 to 0.16, so the attribute access still runs. The check needs a lower bound as well.LoraConfig(target_parameters=[...])under a bare@require_peft, so they error at construction instead of skipping.Changes
get_peft_configpassestarget_parametersonly when the user set--lora_target_parameters. No version comparison is needed: the field defaults toNonein peft, so omitting it is behaviour-identical on 0.17+.Version("0.17.0") <= Version(peft.__version__) < Version("0.20.0"), with the field read last. Applied identically in all four copies, comment included.require_peft_target_parametersintests/testing_utils.py, following the existingrequire_response_parsingpattern, replaces@require_pefton the six affected tests. Thenot is_peft_available() or ...ordering matters, sincepeftis imported underif is_peft_available():and a skipif condition is evaluated at import time.The
< 0.20.0upper bound is unchanged and stays: it encodes peft#3340, fixed by peft#3350 in 0.20.0, where a second adapter alongsidetarget_parametersbecame possible. Only the lower bound is new, and it exists solely because the floor sits below 0.17.Verification
The introducing version is counted at the release tags rather than inferred from dates. Occurrences of
target_parametersinsrc/peft/tuners/lora/config.py:Run against a peft 0.16.0 install, each failure reproduced before the change and gone after:
get_peft_configconstructionTypeError: unexpected keyword argument 'target_parameters'get_peft_configLoraConfigidentical to the old outputAttributeError: 'LoraConfig' object has no attribute 'target_parameters'False, so the ref adapter is added as beforerequire_peft_target_parametersget_peft_configequivalence was checked field by field on the resultingLoraConfigfor the default case, for--lora_target_parametersset, and for--lora_target_modulesset. The four affected tests that do not need vLLM pass at peft 0.20.1, confirming the decorator swap did not silently disable them.Note
Low Risk
Compatibility guards and test skips only; behavior on peft ≥ 0.17 without
lora_target_parametersstays the same.Overview
Fixes crashes on peft 0.13–0.16 where
LoraConfig.target_parametersdoes not exist, while keeping the existing 0.17 ≤ peft < 0.20 reference-adapter workaround.get_peft_confignow passestarget_parameterstoLoraConfigonly when--lora_target_parametersis set, so default CLI--use_peftno longer raisesTypeErroron older PEFT.DPO, GRPO, KTO, and RLOO tighten the ref-adapter guard to
0.17.0 <= peft < 0.20.0before readingdefault_config.target_parameters, avoidingAttributeErrorwhen a pre-wrappedPeftModelis passed on peft < 0.17.Tests add
require_peft_target_parameters(peft ≥ 0.17) and apply it to the six MoE tests that constructLoraConfig(target_parameters=...).Reviewed by Cursor Bugbot for commit 5f2b9f7. Bugbot is set up for automated code reviews on this repo. Configure here.