Model Widgets
Last updated
Last updated
Many model repos have a widget that allows anyone to run inferences directly in the browser!
Here are some examples:
using .
using BOINC AI
using .
using .
You can try out all the widgets .
A widget is automatically created for your model when you upload it to the Hub. To determine which pipeline and widget to display (text-classification
, token-classification
, translation
, etc.), we analyze information in the repo, such as the metadata provided in the model card and configuration files. This information is mapped to a single pipeline_tag
. We choose to expose only one widget per model for simplicity.
For most use cases, we determine the model type from the tags. For example, if there is tag: text-classification
in the , the inferred pipeline_tag
will be text-classification
.
For some libraries, such as π€ Transformers
, the model type should be inferred automatically based from configuration files (config.json
). The architecture can determine the type: for example, AutoModelForTokenClassification
corresponds to token-classification
. If youβre interested in this, you can see pseudo-code in .
You can always manually override your pipeline type with pipeline_tag: xxx
in your . (You can also use the metadata GUI editor to do this).
You can specify the widget input in the model card metadata section:
Copied
You can provide more than one example input. In the examples dropdown menu of the widget, they will appear as Example 1
, Example 2
, etc. Optionally, you can supply example_title
as well.
For example, allow users to choose from two sample audio files for automatic speech recognition tasks by:
Copied
Note that you can also include example files in your model repository and use them as:
Copied
But even more convenient, if the file lives in the corresponding model repo, you can just use the filename or file path inside the repo:
Copied
or if it was nested inside the repo:
Copied
As an extension to example inputs, for each widget example, you can also optionally describe the corresponding model output, directly in the output
property.
This is useful when the model is not yet supported by the Inference API (for instance, the model library is not yet supported or the model is too large) so that the model page can still showcase how the model works and what results it gives.
Copied
The output
property should be a YAML dictionary that represents the Inference API output.
For a model that outputs text, see the example above.
Copied
Finally, for a model that outputs an image, audio, or any other kind of asset, the output should include a url
property linking to either a file name or path inside the repo or a remote URL. For example, for a text-to-image model:
Copied
We can also surface the example outputs in the BOINC AI UI, for instance, for a text-to-image model to display a gallery of cool image generations.
Here are some links to examples:
For example, if you want to specify an aggregation strategy for a NER task in the widget:
Copied
Or if youβd like to change the temperature for a summarization task in the widget:
Copied
Copied
Moreover, you can specify non-text example inputs in the model card metadata. Refer for a complete list of sample input formats for all widget types. For vision & audio widget types, provide example inputs with src
rather than text
.
We provide example inputs for some languages and most widget types in . If some examples are missing, we welcome PRs from the community to add them!
For instance, for an model:
For a model that outputs labels (like a model for instance), output should look like this:
You can find all the supported tasks .
text-classification
, for instance
token-classification
, for instance
question-answering
, for instance
translation
, for instance
summarization
, for instance
conversational
, for instance
text-generation
, for instance
fill-mask
, for instance
zero-shot-classification
(implemented on top of a nli text-classification
model), for instance
table-question-answering
, for instance
sentence-similarity
, for instance
Generally, the Inference API for a model uses the default pipeline settings associated with each task. But if youβd like to change the pipelineβs default settings and specify additional inference parameters, you can configure the parameters directly through the model card metadata. Refer for some of the most commonly used parameters associated with each task.
The Inference API allows you to send HTTP requests to models in the Hugging Face Hub, and itβs 2x to 10x faster than the widgets! β‘β‘ Learn more about it by reading the . Finally, you can also deploy all those models to dedicated .