Introducing AutoPeftModelForxxx#694
Conversation
|
The documentation is not available anymore as the PR was closed or merged. |
BenjaminBossan
left a comment
There was a problem hiding this comment.
This looks quite good to me, I have only minor comments.
Admittedly, I'm not an expert in the concept of the Auto* models, so I can't comment on the overall design of this feature. Let's see what Sourab has to add to this.
| ) | ||
|
|
||
|
|
||
| class PeftAutoModelTester(unittest.TestCase): |
There was a problem hiding this comment.
The individual tests all look very similar. I wonder if they could be parametrized.
There was a problem hiding this comment.
Yeah they are quite similar however, to check if the models are effectively converted in bfloat16 for instance I check some custom module attributes for each case. Maybe let's keep that as it is
There was a problem hiding this comment.
I see. Those could be split into separate tests or could be parametrized via operator.attrgetter but it's not super important.
| ) | ||
|
|
||
|
|
||
| class PeftAutoModelTester(unittest.TestCase): |
There was a problem hiding this comment.
I see. Those could be split into separate tests or could be parametrized via operator.attrgetter but it's not super important.
src/peft/auto.py
Outdated
| ) | ||
|
|
||
| @classmethod | ||
| def from_pretrained(cls, pretrained_model_name_or_path, *peft_model_args, **kwargs): |
There was a problem hiding this comment.
Ah, I just noticed this distinction between *args and **kwargs now. IMHO it's not super intuitive that it works that way. Not sure what would be a better solution, but it should be at least documented what *peft_model_args are.
There was a problem hiding this comment.
As there are only 3 params adapter_name, adapter_name, config apart from the base model and peft model path that is already passed, and the fact that they are all the same across the supported tasks and are kwargs, would it make sense to just have them explicitly mentioned here too?
There was a problem hiding this comment.
Thanks for the valuable feedback, yes that would makes totally sense
src/peft/auto.py
Outdated
| _target_peft_class = None | ||
|
|
||
| def __init__(self, *args, **kwargs): | ||
| raise TypeError( |
There was a problem hiding this comment.
Oh, I see now that transformers uses EnvironmentError and that's why you used it. I still think it's the wrong error to raise, but maybe it should be used for consistency if there is some code somewhere that catches this error specifically??
There was a problem hiding this comment.
I see that makes sense, will revert it to EnvironmentError for consistency with transformers!
There was a problem hiding this comment.
Maybe add a comment that explains why.
There was a problem hiding this comment.
Sure, just added a comment
There was a problem hiding this comment.
Great work @younesbelkada, I really like the simplified UX ✨. I have a few queries based on the offline discussion.
- Methods such as LoRA, AdaLora, IA3, AdaptionPrompt etc are widely applicable to tasks other than those explicitly supported as they do inline changes to the modules, such as ASR, Image Captioning using BLIP, Stable DIffusion, etc. What are your thoughts on going about it as users might expect it to work for those too? Or do we restrict this API to only the explicitly supported NLP tasks?
- Left a comment
src/peft/auto.py
Outdated
| ) | ||
|
|
||
| @classmethod | ||
| def from_pretrained(cls, pretrained_model_name_or_path, *peft_model_args, **kwargs): |
There was a problem hiding this comment.
As there are only 3 params adapter_name, adapter_name, config apart from the base model and peft model path that is already passed, and the fact that they are all the same across the supported tasks and are kwargs, would it make sense to just have them explicitly mentioned here too?
younesbelkada
left a comment
There was a problem hiding this comment.
Hi @pacman100
Thanks for your review, regarding your first point, we could probably do a first version with only officially supported NLP tasks and do a second iteration to add a new auto mapping class that group the model classes based on modalities
pacman100
left a comment
There was a problem hiding this comment.
Thank you @younesbelkada for iterating, LGTM!
* working v1 for LMs * added tests. * added documentation. * fixed ruff issues. * added `AutoPeftModelForFeatureExtraction` . * replace with `TypeError` * address last comments * added comment.
* update to `prepare_model_for_kbit_training` from deprecated `prepare_model_for_int8_training` and add `use_gradient_checkpointing=args.gradient_checkpointing` to automatically follow the gradient checkpointing choice is also the workaround for huggingface#694 * workaround for gradient checkpointing issue calling model.gradient_checkpointing_enable() twice causes issues this workaround calls it in prepare_model_for_kbit_training and then changes the arg to false to make sure it isn't called again in huggingface trainer inner loop also changes stack_llama_2 sft trainer to use correct device map for ddp training so that you can test this issue
This PR introduces a new paradigm,
AutoPeftModelForxxxintended for users that want to rapidly load and run peft models.Currently a user needs to run all these steps:
to load a peft model from the Hub or locally, whereas now they could just do:
cc @pacman100 @BenjaminBossan
TODOs: