# Running two Ollama models at once: memory and concurrency

Test two Ollama models together by separating loaded-model limits from request concurrency, then checking memory, retention and the actual queue.

Author: Retrivium team
Updated: 2026-11-01
Canonical URL: https://retrivium.ai/journal/ollama-two-models-parallel/
Language: en

Two Ollama models can operate together only when the selected configuration supports it and sufficient resources are available. Separate the number of models held in memory from the number of requests processed in parallel. Those are different limits and create different memory demands.

## Distinguish the two levels of parallelism

The official FAQ describes `OLLAMA_MAX_LOADED_MODELS` and `OLLAMA_NUM_PARALLEL`. One concerns loaded models; the other concerns concurrent work. Increasing both without measurements can change placement and queueing even when each model works correctly alone.

Record server settings where the background process actually receives them. A variable in a client terminal is not evidence that an existing service adopted it. Include the Ollama version and launch method so the same test can be reproduced after a restart.

## Establish an individual baseline

Load model A, send a short request and save placement from `ollama ps`. Repeat for model B with the same explicit context assumptions. Record exact tags, artifact variants and the memory occupied before loading.

If either model already uses a mixed CPU/GPU configuration alone, do not assume both will stay fully on the accelerator together. File sizes are not the complete requirement: cache, context, runtime allocations and other processes also matter.

## Test retention and the queue

Use an A, B, A request sequence. Observe whether A remains loaded, is evicted or needs another load before its second answer. Save timestamps and placement rather than inferring retention from a fast-looking browser response.

Next, submit two requests simultaneously and record submission time, first content and completion for each. A delayed second answer may reflect queueing rather than parallel execution. Keep the input and output limits fixed while investigating this distinction.

## Choose a useful operating schedule

Begin with moderate inputs and a small output allowance, then expand toward the real workload. Include requests after an idle period: a test conducted entirely while both models are warm does not describe an occasional-use application.

If the models are used sequentially and switching is acceptable, holding both may be unnecessary. If both must answer together, measure that exact case and check the rest of the machine remains usable. The useful result is a documented operating profile, such as one resident model or two with tested switching, rather than a claim based only on combined weight size.

## Turn the check into a practical next step

Two models being available in a catalogue does not prove they remain loaded together. Verify retention, concurrency and the resulting delay on the actual machine.

For the documented details, consult the [primary documentation](https://docs.ollama.com/faq); [configuration reference](https://docs.ollama.com/gpu). Continue with [ollama cpu gpu split](/journal/ollama-cpu-gpu-split/) and [ollama context length setting](/journal/ollama-context-length-setting/).