Switching LoRA Adapters in Ollama

Ollama has no command that swaps an adapter inside a loaded model. The unit it switches is the model name, so the way to run two adapters over one base is to build two named models that share it — and the sharing is real, not a copy.

You switch models, not adapters

This is the thing to get straight before writing any files. In llama.cpp you can pass --lora at process start and, through the server, change which adapters are active per request. Ollama exposes neither. Its ADAPTER instruction is a Modelfile directive, and Modelfiles are consumed by ollama create, which runs once and produces a named model in the local store. By the time you type ollama run, the decision about which adapter applies has already been made.

So “switching adapters at runtime” in Ollama means switching between two model names that were created from the same base with different adapters. That is not a workaround; it is how the tool is shaped, and it has one genuine advantage — each combination gets its own name, its own parameters and its own system prompt, rather than being a flag somebody forgot to pass.

Two Modelfiles over one base

The ADAPTER instruction takes an absolute path or a path relative to the Modelfile, and Ollama’s Modelfile reference documents two accepted forms: a GGUF adapter file, and a Safetensors adapter directory for a supported architecture. The reference names Llama, Mistral and Gemma families as the Safetensors-supported ones at the time of writing; a GGUF adapter converted with llama.cpp’s convert_lora_to_gguf.py avoids that restriction entirely.

# Modelfile.support
FROM llama3.1:8b
ADAPTER ./adapters/support-tone-f16.gguf
PARAMETER temperature 0.2
SYSTEM "You are the support desk. Answer in two sentences."

# Modelfile.legal
FROM llama3.1:8b
ADAPTER ./adapters/contract-clauses-f16.gguf
PARAMETER temperature 0
SYSTEM "You summarise contract clauses. Quote the clause number."

Both start from the same FROM line. That matters for the next section and it matters for correctness: an adapter trained against Llama 3.1 8B and applied over a different base will load, and will be wrong.

Create both, run either

1. Build the first: ollama create support -f Modelfile.support.
2. Build the second: ollama create legal -f Modelfile.legal. The base layer is already present, so this step only has to ingest the adapter.
3. Confirm both exist and note their reported sizes with ollama list.
4. Run one: ollama run support "the invoice is wrong". Run the other by name. Through the API it is the same switch — "model": "support" against "model": "legal" in the request body.
5. Run the unadapted base under its own name as a control, with the same prompt and temperature 0, and diff all three.

Step five is not optional if you care whether either adapter is doing anything. Two adapted models that differ from each other prove the adapters differ; only the base comparison proves either one is having an effect at all.

Inspecting what got built

Because the adapter decision is made at create time and then becomes invisible, it is worth knowing how to read it back off a model that already exists. Ollama can regenerate a Modelfile from a stored model:

ollama show --modelfile support

The output is the Modelfile as Ollama understood it, which is not always the Modelfile you wrote. The FROM line comes back as a resolved blob reference rather than the tag you typed, and the ADAPTER line comes back as the ingested adapter rather than your relative path. Both substitutions are the point: they tell you what the model is actually built from, after every tag and path was resolved.

If the ADAPTER line is absent from that output, the adapter is not in the model, and no amount of running it will change that. That is the single fastest check available, and it costs nothing. It is also the one to run after any Modelfile edit, because ollama createwith an unchanged name replaces the model silently — there is no prompt and no version history, so a typo in a path produces a successfully-created model with one fewer component than you intended.

What this costs on disk

Less than ollama list suggests. Ollama stores models as content-addressed blobs with a manifest per name, so two models built from one FROM line reference the same base blob and differ only in the adapter blob and the manifest. The listing reports the logical size of each model, which counts the shared base twice; the directory on disk holds it once.

The practical consequence is that adapter-per-tenant is cheap in storage and expensive in memory only if you run them concurrently. Each loaded model is its own resident copy of the base weights, so ten adapters served simultaneously is ten times the VRAM, not one base plus ten small deltas. Runtimes designed for multi-adapter serving solve that; Ollama does not try to.

The erratic-behaviour clause

Ollama’s documentation is unusually blunt here: if the base model is not the same as the base the adapter was tuned from, the behaviour will be erratic. Not an error — erratic. There is no checksum binding an adapter to a base, so a tag that has since been repointed to a newer revision will silently pair your adapter with weights it never saw.

The other quiet failure is path resolution: ADAPTER paths are relative to the Modelfile, not to your shell’s working directory. A Modelfile that works from one directory and fails from another is almost always this. And if the adapter file is missing entirely, you want that to be a hard error at create time rather than a model that runs and sounds slightly off — test the adapter deliberately rather than trusting that it loaded.