You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/source/en/guides/integrations.md
+20-5Lines changed: 20 additions & 5 deletions
Original file line number
Diff line number
Diff line change
@@ -143,13 +143,12 @@ your library, you should:
143
143
model. The method must download the relevant files and load them.
144
144
3. You are done!
145
145
146
-
The advantage of using [`ModelHubMixin`] is that once you take care of the serialization/loading of the files, you
147
-
are ready to go. You don't need to worry about stuff like repo creation, commits, PRs, or revisions. All
148
-
of this is handled by the mixin and is available to your users. The Mixin also ensures that public methods are well
149
-
documented and type annotated.
146
+
The advantage of using [`ModelHubMixin`] is that once you take care of the serialization/loading of the files, you are ready to go. You don't need to worry about stuff like repo creation, commits, PRs, or revisions. All of this is handled by the mixin and is available to your users. The Mixin also ensures that public methods are well documented and type annotated.
150
147
151
148
As a bonus, [`ModelHubMixin`] handles the model configuration for you. If your `__init__` method expects a `config` input, it will be automatically saved in the repo when calling `save_pretrained` and reloaded correctly by `load_pretrained`. Moreover, if the `config` input parameter is annotated with dataclass type (e.g. `config: Optional[MyConfigClass] = None`), then the `config` value will be correctly deserialized for you. Finally, all jsonable values passed at initialization will be also stored in the config file. This means you don't necessarily have to expect a `config` input to benefit from it. The big advantage of having a `config.json` file in your model repository is that it automatically enables the analytics on the Hub (e.g. the "downloads" count).
152
149
150
+
Finally, [`ModelHubMixin`] handles generating a model card for you. When inheriting from [`ModelHubMixin`], you can define metadata such as `library_name`, `tags`, `repo_url` and `docs_url`. Those fields will be reused to populate the modelcard of any model that use your class. This is very practical to make all models using your library easily searchable on the Hub and to provide some resource links for users landing on the Hub. If you want to extend the modelcard template, you can override the [`~ModelHubMixin.generate_model_card`] method.
151
+
153
152
### A concrete example: PyTorch
154
153
155
154
A good example of what we saw above is [`PyTorchModelHubMixin`], our integration for the PyTorch framework. This is a ready-to-use integration.
@@ -165,7 +164,15 @@ Here is how any user can load/save a PyTorch model from/to the Hub:
165
164
166
165
167
166
# Define your Pytorch model exactly the same way you are used to
0 commit comments