Model Gallery
The model gallery is a curated collection of models configurations for LocalAI that enables one-click install of models directly from the LocalAI Web interface.
A list of the models available can also be browsed at the Public LocalAI Gallery.
LocalAI to ease out installations of models provide a way to preload models on start and downloading and installing them in runtime. You can install models manually by copying them over the models directory, or use the API or the Web interface to configure, download and verify the model assets for you.
Note
The models in this gallery are not directly maintained by LocalAI. If you find a model that is not working, please open an issue on the main LocalAI repository.
Note
GPT and text generation models might have a license which is not permissive for commercial use or might be questionable or without any license at all. Please check the model license before using it. The official gallery contains only open licensed models.
Useful Links and resources
- Open LLM Leaderboard - here you can find a list of the most performing models on the Open LLM benchmark. Keep in mind models compatible with LocalAI must be quantized in the
ggufformat.
How it works
Navigate the WebUI interface in the “Models” section from the navbar at the top. Here you can find a list of models that can be installed, and you can install them by clicking the “Install” button.
VRAM and download size estimates
When browsing the gallery or importing a model by URI, LocalAI can show estimated download size and estimated VRAM for models.
- Where they appear: In the model gallery table (Size / VRAM column), in the model detail modal, and after starting an import from URI (in the success message).
- How they are computed: GGUF models use file size (HTTP HEAD or local stat) and optional GGUF metadata (HTTP Range) for KV cache and overhead; other formats use Hugging Face file sizes and optional config when available. If metadata is unavailable, a size-only heuristic is used.
- Hardware fit indicator: When your system reports GPU or RAM capacity, the gallery shows whether the estimated VRAM fits (green) or may not fit (red) using a 95% headroom rule.
- Estimates are best-effort and may be missing if the server does not support HEAD/Range or the request times out.
Add other galleries
You can add other galleries by:
Using the Web UI: Navigate to the Runtime Settings page and configure galleries through the interface.
Using Environment Variables: Set the
GALLERIESenvironment variable. TheGALLERIESenvironment variable is a list of JSON objects, where each object has anameand aurlfield. Thenamefield is the name of the gallery, and theurlfield is the URL of the gallery’s index file, for example:
- Using Configuration Files: Add galleries to
runtime_settings.jsonin theLOCALAI_CONFIG_DIRdirectory.
The models in the gallery will be automatically indexed and available for installation.
API Reference
Model repositories
You can install a model in runtime, while the API is running and it is started already, or before starting the API by preloading the models.
To install a model in runtime you will need to use the /models/apply LocalAI API endpoint.
By default LocalAI is configured with the localai repository.
To use additional repositories you need to start local-ai with the GALLERIES environment variable:
For example, to enable the default localai repository, you can start local-ai with:
where github:mudler/localai/gallery/index.yaml will be expanded automatically to https://raw.githubusercontent.com/mudler/LocalAI/main/index.yaml.
Note: the url are expanded automatically for github and huggingface, however https:// and http:// prefix works as well.
Using Local Gallery Files
You can also use local gallery index files by using the file:// prefix. For security reasons, local gallery files must be located within your models directory (the directory specified by MODELS_PATH or the default models/ directory).
Example:
Important notes:
- The
file://prefix is required for local paths - The file path must be absolute (starting with
/on Unix systems) - The resolved path must be within your models directory for security
- If you try to access files outside the models directory, LocalAI will block the request
Valid example (assuming MODELS_PATH=/opt/localai/models):
Invalid example (file outside models directory):
This will be rejected with a security error.
Note
If you want to build your own gallery, there is no documentation yet. However you can find the source of the default gallery in the LocalAI repository.
List Models
To list all the available models, use the /models/available endpoint:
To search for a model, you can use jq:
How to install a model from the repositories
Models can be installed by passing the full URL of the YAML config file, or either an identifier of the model in the gallery. The gallery is a repository of models that can be installed by passing the model name.
To install a model from the gallery repository, you can pass the model name in the id field. For instance, to install the bert-embeddings model, you can use the following command:
where:
localaiis the repository. It is optional and can be omitted. If the repository is omitted LocalAI will search the model by name in all the repositories. In the case the same model name is present in both galleries the first match wins.bert-embeddingsis the model name in the gallery (read its config here).
Model variants
Some gallery entries offer several builds of the same model: different
quantizations, or the same weights served by a different engine. Such an entry
carries a variants list, and installing it normally lets LocalAI choose:
- variants whose backend cannot run on this machine are dropped;
- variants that do not fit the available memory are dropped. That budget is VRAM on a discrete-GPU host, and system RAM otherwise — including on unified-memory machines such as Apple Silicon, where the GPU shares system RAM and reports no separate VRAM pool;
- the entry’s own build is never dropped. It competes with whatever survived rather than waiting for everything else to fail, so an entry that is itself the largest build that fits keeps its own payload;
- among the remaining builds the engine this machine prefers wins first: a vLLM build on an NVIDIA or AMD host, an MLX build on Apple Silicon, llama.cpp otherwise. The native accelerated runtime is worth more than a bigger download, so preference is settled before size;
- the largest build on the preferred engine then wins, because a bigger footprint means a higher quality build of the same model. A machine with no preferred engine picks purely by size;
- a build whose size could not be measured ranks below the entry’s own build, so an unreadable size never quietly displaces the payload the entry ships;
- if nothing else survives, the entry’s own build is installed. The entry is always installable, on any machine.
Because the entry’s own build competes like every other candidate, the order of
the list means nothing and a variants list may offer smaller builds, larger
ones, or both.
Sizes are measured from the model’s weights rather than downloaded, and cached.
The gallery listing only flags which entries offer variants, with a
has_variants field. It deliberately does not describe them: measuring a
variant is a network round trip per referenced build, so describing every
entry inline would make one listing request cost as many round trips as the
whole page has variants.
Collapsing the listing to one row per model
By default the listing returns every entry, including the individual builds a
parent entry offers as variants, so one model can occupy several rows. Pass
collapse_variants=true for the deduplicated view: every entry that is
installable in its own right, with nothing shown twice.
An entry is hidden only when another entry already offers it as a variant, so it stays reachable by installing that entry. Entries that declare variants are always kept, and so is any entry nobody references. The filter is applied before pagination, so page counts stay correct.
Searching respects the collapse. term is matched against every entry the
gallery holds, builds another entry offers included, so nothing becomes
unfindable. The collapse then decides how a match is reported: a hit on a build
another entry offers comes back as that entry, since that is the row installable
in its own right. Looking a model up by name must not answer “not found” for an
entry the gallery holds, and must not answer with a row the requested view has
no place for either. A term that is empty or only whitespace does not count as a
search:
A parent appears once however many of its builds match, and once when it matches in its own right as well. The substitution runs before the count and the page math, so both describe the rows actually handed out.
term, tag and backend are all applied before the substitution, so each is
judged against the build that really carries the name, tag or backend rather
than against a parent that merely offers it. The consequence is worth knowing:
filtering by a backend only one variant declares returns that variant’s parent,
whose own backend field may say something else. The alternative would be to
claim the gallery holds no such build.
The web UI requests the collapsed view by default and has a toggle for the other one. The parameter stays on the API, off by default, for clients that want either view.
Ask for the description one entry at a time, as the web UI does when you open a model’s variant menu:
auto_selected is what installing without a choice would pick right now. fits
is whether auto-selection would consider that variant on this machine, and
is_base marks the entry’s own build. memory_bytes is omitted entirely, as on
the second entry above, when the size could not be measured; read a missing
memory_bytes as unknown rather than as a free build.
An entry that declares no variants carries no has_variants field and answers
this endpoint with an empty list, so a client never has to ask about it.
To install a specific one, pass its name as variant:
An explicit choice is honored even when the machine looks too small for it, so
you can deliberately install a build LocalAI would not have picked. A variant
the entry does not declare fails the install and names what was requested; it
never quietly falls back to auto-selection. The choice is recorded, so a later
reinstall or upgrade of the same model stays on the variant you picked.
The same option exists on the CLI:
The install_model MCP tool takes the same variant argument, so an assistant
managing installs conversationally can pick a build too.
Entries without a variants list are unaffected by any of this and install
exactly as they always have.
Artifact-backed models
Gallery models with an artifacts declaration are fully materialized during
installation. Their operation progresses through these phases:
The admin Operations Bar and GET /api/operations expose currentBytes and
totalBytes as raw transport bytes. Cancelling an active download leaves its
partial files in place so a retry can resume. A verification failure never
exposes a completed snapshot, while a retry or another installation reuses an
already verified content-addressed snapshot.
Deleting a model configuration does not delete its content-addressed snapshot bytes. This allows another configuration or a later reinstall to reuse the cache; safe cache garbage collection is deferred.
How to install a model not part of a gallery
If you don’t want to set any gallery repository, you can still install models by loading a model configuration file.
In the body of the request you must specify the model configuration file URL (url), optionally a name to install the model (name), extra files to install (files), and configuration overrides (overrides). When calling the API endpoint, LocalAI will download the models files and write the configuration to the folder used to store models.
An example that installs hermes-2-pro-mistral can be:
The API will return a job uuid that you can use to track the job progress:
For instance, a small example bash script that waits a job to complete can be (requires jq):
To preload models on start instead you can use the PRELOAD_MODELS environment variable.
To preload models on start, use the PRELOAD_MODELS environment variable by setting it to a JSON array of model uri:
Note: url or id must be specified. url is used to a url to a model gallery configuration, while an id is used to refer to models inside repositories. If both are specified, the id will be used.
For example:
or as arg:
or in a YAML file:
YAML:
Note
You can find already some open licensed models in the LocalAI gallery.
If you don’t find the model in the gallery you can try to use the “base” model and provide an URL to LocalAI:
Override a model name
To install a model with a different name, specify a name parameter in the request body.
For example, to install a model as gpt-3.5-turbo:
Additional Files
To download additional files with the model, use the files parameter:
Overriding configuration files
To override portions of the configuration file, such as the backend or the model file, use the overrides parameter:
Examples
Embeddings: Bert
To test it:
Image generation: Stable diffusion
URL: https://github.com/EdVince/Stable-Diffusion-NCNN
While the API is running, you can install the model by using the /models/apply endpoint and point it to the stablediffusion model in the models-gallery:
You can set the PRELOAD_MODELS environment variable:
or as arg:
or in a YAML file:
YAML:
Test it:
Audio transcription: Whisper
URL: https://github.com/ggerganov/whisper.cpp
You can set the PRELOAD_MODELS environment variable:
or as arg:
or in a YAML file:
YAML:
Note
LocalAI will create a batch process that downloads the required files from a model definition and automatically reload itself to include the new model.
Input: url or id (required), name (optional), files (optional)
An optional, list of additional files can be specified to be downloaded within files. The name allows to override the model name. Finally it is possible to override the model config file with override.
The url is a full URL, or a github url (github:org/repo/file.yaml), or a local file (file:///path/to/file.yaml).
Warning
Local file security restriction: When using file:// URLs, the file path must be within your models directory (specified by MODELS_PATH). Files outside this directory will be rejected for security reasons.
The id is a string in the form <GALLERY>@<MODEL_NAME>, where <GALLERY> is the name of the gallery, and <MODEL_NAME> is the name of the model in the gallery. Galleries can be specified during startup with the GALLERIES environment variable.
Returns an uuid and an url to follow up the state of the process:
To see a collection example of curated models definition files, see the LocalAI repository.
Get model job state /models/jobs/<uid>
This endpoint returns the state of the batch job associated to a model installation.
Returns a json containing the error, and if the job is being processed: