peft

ed396a69 - [`core`] PEFT refactor + introducing `inject_adapter_in_model` public method (#749)

[`core`] PEFT refactor + introducing `inject_adapter_in_model` public method (#749) Refactors a bit the internals of some PEFT models and introduces a new method inject_adapter_in_model for users that want to pass a bare model and a peft config to inject adapters in-place into the model. These changes are totally BC with the previous PEFT versions. This PR makes things easier for the PEFT integration in transformers huggingface/transformers#25077 The main goal of the PR is to expose a new API for advanced users that want to integrate PEFT method without the need to use the PeftModel wrapper. A simple use case could be someone that wants to inject adapters into a model and wants to keep the original class of the model without having to offload that to peft that will create a PeftModel. I have faced this issue in huggingface/transformers#25077 Among other things, this PR refactors some internals of PEFT library, while keeping it fully backward compatible. To tackle the main motivation I propose to differentiate things between two type of adapters 1- adapters that are injectable (LoRA, AdaLoRA, IA3) 2- adapters that are not injectable (the rest) As a first iteration this API would be supported only for the scenario 1- / therefore I decided to create 2 abstract classes to make things easy to be able to determine if the adapter layer (e.g. LoraLayer) / adapter module (e.g. LoraModel) does follow the minimal requirement (i.e. needed attributes, etc.) Other related changes: 1- Creates a new property method is_prompt_learning to avoid importing PromptLearningConfig all the way down 2- Introduces a new object TUNERS_MAPPING, which is a mapping of supported pluggable adapters 3- Creates two abstract classes 3.1- BaseTunerLayer: a mixin to check for minimal required attributes that a tuner layer should have active_adapter / _is_plugable 3.2- BaseTuner: a higher level module mixin that should be used for any injectable adapters in the future. --------- Co-authored-by: Benjamin Bossan <BenjaminBossan@users.noreply.github.com> Co-authored-by: Patrick von Platen <patrick.v.platen@gmail.com>