Share a custom model
Last updated
Last updated
The π Transformers library is designed to be easily extensible. Every model is fully coded in a given subfolder of the repository with no abstraction, so you can easily copy a modeling file and tweak it to your needs.
If you are writing a brand new model, it might be easier to start from scratch. In this tutorial, we will show you how to write a custom model and its configuration so it can be used inside Transformers, and how you can share it with the community (with the code it relies on) so that anyone can use it, even if itβs not present in the π Transformers library.
We will illustrate all of this on a ResNet model, by wrapping the ResNet class of the into a .
Before we dive into the model, letβs first write its configuration. The configuration of a model is an object that will contain all the necessary information to build the model. As we will see in the next section, the model can only take a config
to be initialized, so we really need that object to be as complete as possible.
In our example, we will take a couple of arguments of the ResNet class that we might want to tweak. Different configurations will then give us the different types of ResNets that are possible. We then just store those arguments, after checking the validity of a few of them.
Copied
The three important things to remember when writing you own configuration are the following:
you have to inherit from PretrainedConfig
,
the __init__
of your PretrainedConfig
must accept any kwargs,
those kwargs
need to be passed to the superclass __init__
.
The inheritance is to make sure you get all the functionality from the π Transformers library, while the two other constraints come from the fact a PretrainedConfig
has more fields than the ones you are setting. When reloading a config with the from_pretrained
method, those fields need to be accepted by your config and then sent to the superclass.
Defining a model_type
for your configuration (here model_type="resnet"
) is not mandatory, unless you want to register your model with the auto classes (see last section).
With this done, you can easily create and save your configuration like you would do with any other model config of the library. Here is how we can create a resnet50d config and save it:
Copied
This will save a file named config.json
inside the folder custom-resnet
. You can then reload your config with the from_pretrained
method:
Copied
As we mentioned before, weβll only write a loose wrapper of the model to keep it simple for this example. The only thing we need to do before writing this class is a map between the block types and actual block classes. Then the model is defined from the configuration by passing everything to the ResNet
class:
Copied
For the model that will classify images, we just change the forward method:
Copied
In both cases, notice how we inherit from PreTrainedModel
and call the superclass initialization with the config
(a bit like when you write a regular torch.nn.Module
). The line that sets the config_class
is not mandatory, unless you want to register your model with the auto classes (see last section).
If your model is very similar to a model inside the library, you can re-use the same configuration as this model.
Now that we have our model class, letβs create one:
Copied
In your own use case, you will probably be training your custom model on your own data. To go fast for this tutorial, we will use the pretrained version of the resnet50d. Since our model is just a wrapper around it, itβs going to be easy to transfer those weights:
Copied
This API is experimental and may have some slight breaking changes in the next releases.
First, make sure your model is fully defined in a .py
file. It can rely on relative imports to some other files as long as all the files are in the same directory (we donβt support submodules for this feature yet). For our example, weβll define a modeling_resnet.py
file and a configuration_resnet.py
file in a folder of the current working directory named resnet_model
. The configuration file contains the code for ResnetConfig
and the modeling file contains the code of ResnetModel
and ResnetModelForImageClassification
.
Copied
The __init__.py
can be empty, itβs just there so that Python detects resnet_model
can be use as a module.
If copying a modeling files from the library, you will need to replace all the relative imports at the top of the file to import from the transformers
package.
Note that you can re-use (or subclass) an existing configuration/model.
To share your model with the community, follow those steps: first import the ResNet model and config from the newly created files:
Copied
Then you have to tell the library you want to copy the code files of those objects when using the save_pretrained
method and properly register them with a given Auto class (especially for models), just run:
Copied
Next, letβs create the config and models as we did before:
Copied
Now to send the model to the Hub, make sure you are logged in. Either run in your terminal:
Copied
or from a notebook:
Copied
You can then push to your own namespace (or an organization you are a member of) like this:
Copied
Copied
It is also strongly encouraged to pass a commit hash as a revision
to make sure the author of the models did not update the code with some malicious new lines (unless you fully trust the authors of the models).
Copied
Note that when browsing the commit history of the model repo on the Hub, there is a button to easily copy the commit hash of any commit.
If you are writing a library that extends π Transformers, you may want to extend the auto classes to include your own model. This is different from pushing the code to the Hub in the sense that users will need to import your library to get the custom models (contrarily to automatically downloading the model code from the Hub).
As long as your config has a model_type
attribute that is different from existing model types, and that your model classes have the right config_class
attributes, you can just add them to the auto classes like this:
Copied
You can also use any other method of the class, like to directly upload your config to the Hub.
Now that we have our ResNet configuration, we can go on writing the model. We will actually write two: one that extracts the hidden features from a batch of images (like ) and one that is suitable for image classification (like ).
You can have your model return anything you want, but returning a dictionary like we did for ResnetModelForImageClassification
, with the loss included when labels are passed, will make your model directly usable inside the class. Using another output format is fine as long as you are planning on using your own training loop or another library for training.
Again, you can use any of the methods of , like or . We will use the second in the next section, and see how to push the model weights with the code of our model. But first, letβs load some pretrained weights inside our model.
Now letβs see how to make sure that when we do or , the code of the model is saved.
Note that there is no need to specify an auto class for the configuration (there is only one auto class for them, ) but itβs different for models. Your custom model could be suitable for many different tasks, so you have to specify which one of the auto classes is the correct one for your model.
On top of the modeling weights and the configuration in json format, this also copied the modeling and configuration .py
files in the folder custom-resnet50d
and uploaded the result to the Hub. You can check the result in this .
See the for more information on the push to Hub method.
You can use any configuration, model or tokenizer with custom code files in its repository with the auto-classes and the from_pretrained
method. All files and code uploaded to the Hub are scanned for malware (refer to the documentation for more information), but you should still review the model code and author to avoid executing malicious code on your machine. Set trust_remote_code=True
to use a model with custom code:
Note that the first argument used when registering your custom config to needs to match the model_type
of your custom config, and the first argument used when registering your custom models to any auto model class needs to match the config_class
of those models.