LM Studio vs Ollama on Linux: same model files, measured on an RTX 3090

LM Studio and Ollama both run local language models, and both serve an API that other programs can use. This page runs the same two Qwen3.5 GGUF files in both, in Docker, on one RTX 3090. It compares speed, GPU memory, load times, parallel requests and disk use. It also covers how to get LM Studio's Docker image onto an NVIDIA GPU, which the official image does not support yet, and how to remove it again.

Most "Ollama vs LM Studio" comparisons test on a Mac, where LM Studio can use Apple's MLX engine and Ollama runs a GGUF file, so the two tools run different model files, and their results do not carry over to Linux. On Linux with an NVIDIA card, both tools run llama.cpp. Here they loaded the exact same files, checked by SHA-256.

Facts about the tools link to the page they come from. Figures without a link were measured in this test.

The short answer

• Speed: once the answer started, Ollama wrote it about 10% faster with the 9B model (120.6 against 109.7 tokens per second) and about 5% faster with the 27B model (42.3 against 40.1). A second Ollama run after the LM Studio tests gave 120.1 and 41.2.
• Several requests at once: LM Studio's defaults handled four requests on the 27B model much better: 90 tokens per second in total, against 33 for Ollama with four parallel slots. The most likely cause is how each tool sizes the context for each slot.
• Memory: with its defaults, LM Studio used less GPU memory, because it starts with an 8,192-token context. Ollama starts with 32,768 tokens on a 24 GB card.
• Disk: LM Studio can use a GGUF file where it lies, through a link. Ollama copies the file into its own store, which cost 22.4 GB here.
• Server use: Ollama has an official Docker image that uses the GPU. LM Studio's Docker image is a preview that supports only the CPU; the GPU setup below works but is not supported by LM Studio.
• Licence: Ollama is open source under the MIT licence. The LM Studio app is closed source and free for home and work use; its lms command-line tool is MIT licensed.

For an always-on home server, Ollama is the simpler choice. LM Studio is the better choice on a desktop where you want a graphical app to find, download and try models, and it can serve several users at once with less tuning.

What was tested

The machine was a desktop with a Ryzen 9 5900X, 64 GB of RAM and an RTX 3090 with 24 GB, running Fedora 44. The models were the unsloth GGUF builds of Qwen3.5 9B and 27B at Q4_K_M, 5.7 GB and 16.7 GB on disk. Thinking was turned off in both tools, and the temperature was 0.

Each test sent one of two prompts. The short prompt was about 70 tokens and asked for a 512-token answer. The long prompt was about 4,120 tokens of text and asked for a 256-token summary. Before each measured run, the script waited until the GPU had cooled to 50 °C, and a random ID at the start of each prompt kept either tool from reusing a cached prompt. Each figure is the median of five runs. The LM Studio runs alternated between two setups in each round:

• LM Studio defaults: what lms load picks without options, an 8,192-token context with 4 parallel slots.
• LM Studio at 32k: a 32,768-token context with 1 slot, the same as Ollama's default on this card.

The Ollama figures come from a test run on the same machine with the same scripts four hours earlier. To rule out a change in the machine, Ollama was run again after the LM Studio tests: it gave 120.1 tokens per second on the 9B model and 41.2 on the 27B, against 120.6 and 42.3 four hours earlier.

Both run llama.cpp

Since version 0.30.0, Ollama runs GGUF models in a llama-server process from the llama.cpp project. LM Studio does the same: its CUDA runtime is a folder with llama.cpp libraries and a llama-server program, and LM Studio starts it for each loaded model. The two tools mainly differ in the llama.cpp build they ship and the options they start it with. Ollama vs llama.cpp shows the exact command Ollama starts and compares it with llama-server run on its own.

These are the options LM Studio passed for the 9B model with its defaults, read from the running process:

--ctx-size 8192 --parallel 4 --kv-unified --n-gpu-layers 999999
--flash-attn on --batch-size 2048 --ubatch-size 512 --threads 9
--cache-type-k f16 --cache-type-v f16 --load-mode mmap+mlock

Ollama started the same model with -c 32768 -np 1 --flash-attn auto -b 1024 -ub 1024. For the 27B model it used -b 512 -ub 512.

Speed with one request

Generation speed is the number of tokens per second while the model writes its answer, as reported by each tool. Time to first token was measured by the test script, from sending the request to the first word of the answer. The 512-token time is how long the whole short answer took.

• Ollama was faster at writing: about 10% with the 9B model and about 5% with the 27B. The five runs of each setup were within 2% of each other, so the gap is larger than the spread.
• Ollama also read the long prompt faster: its first token came about 0.1 s sooner with the 9B model and 0.36 s sooner with the 27B.
• LM Studio started answering a short prompt sooner, by about 20 ms with the 9B model and 100 ms with the 27B.
• LM Studio's context size and slot count made no difference to speed. Both LM Studio setups gave the same numbers, so the gap to Ollama comes from the llama.cpp build or the other start options. This test did not separate the two.

In practice, the difference is about 0.4 s on a 512-token answer from the 9B model. You would notice it in long answers, and hardly in chat.

Several requests at once

This test sent four requests at the same time, each asking for 256 tokens, and measured the total tokens per second. It ran three rounds, and the table shows the median. GPU memory was read while the requests ran. LM Studio with 1 slot means its default 8,192-token context with --parallel 1. The Ollama figures come from the Ollama vs llama.cpp test with OLLAMA_NUM_PARALLEL set to 1 (the default) and to 4.

With one slot, both tools answer the four requests one after another, so the total is about the speed of a single request. With four slots they run together, and in three of the four cases the total rose to more than twice that.

The 27B model shows the difference in how the tools size the context. The Ollama FAQ says the memory needed grows with OLLAMA_NUM_PARALLEL multiplied by the context length. With four slots, Ollama started the model with a 131,072-token context, four times its 32k default. That no longer fit in 24 GB: ollama ps showed 16% of the model on the CPU, and the total speed fell below the speed of a single slot. LM Studio's four slots share one 8,192-token context, so the model stayed on the GPU and the total speed more than doubled. A smaller context in Ollama, set with OLLAMA_CONTEXT_LENGTH, should avoid the spill, but this test did not try it.

The cost of LM Studio's default is a short context. Four slots that share 8,192 tokens leave little room for long documents or long chats. Load the model with a larger context if you need one:

lms load qwen3.5-27b --context-length 32768 --parallel 1

GPU memory, context and load times

At the same context size, the two tools used about the same GPU memory. LM Studio's lower default figure comes from its smaller context.

LM Studio loads a model when the first API request names it, which its docs call just-in-time loading. With the 9B model, LM Studio reported a load time of 2.2 s for that first request. The load times in the table were timed around the lms load command, so they are slightly longer. Ollama also loads on the first request. The two differ in when they unload: Ollama frees the memory after 5 minutes without requests, and LM Studio keeps a model loaded through the API for 60 minutes. Both can be changed: OLLAMA_KEEP_ALIVE or keep_alive in Ollama, and --ttl or a ttl field in the request in LM Studio.

With no model loaded, the LM Studio container used 472 MiB of RAM and 219 MiB of GPU memory.

Model files and disk space

Both tools can use a GGUF file that you already have, but they store it differently.

• Ollama imports a GGUF file through a Modelfile with a FROM line and ollama create, and stores a copy in its blob folder. The copies of the two test models took 22.4 GB, on top of the original files.
• LM Studio imports with lms import. By default the command moves the file into LM Studio's models folder. With -l it creates a symbolic link instead, and with -L a hard link. The test used links, so the two models took no extra space.

lms import /models/Qwen3.5-9B-Q4_K_M.gguf -l --user-repo unsloth/Qwen3.5-9B-GGUF -y

Ollama names each blob after the SHA-256 of the file, so you can check that both tools load the same file. Here the 9B blob was sha256-03b74727…, the same checksum as the file LM Studio linked to.

The same GGUF file can serve both tools at once, but each tool that loads it uses its own GPU memory. On a 24 GB card, the 27B model fits only once.

Running Ollama in Docker

Ollama's official image supports NVIDIA GPUs through the NVIDIA Container Toolkit. The command from the Ollama docs:

docker run -d --gpus=all -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama

Pin a version tag such as ollama/ollama:0.40.15 instead of the default latest if you want updates only when you choose them. The OpenClaw with Ollama guide shows this setup used by another program.

Running LM Studio in Docker on an NVIDIA GPU

LM Studio has a headless version for servers, called llmster, added in LM Studio 0.4.0. Its Docker image, lmstudio/llmster-preview, is marked as a technical preview, and its description says it has "CPU-only support on x86 systems". It is not mentioned in the LM Studio docs.

The steps below made the image use the RTX 3090. They are not a setup LM Studio supports: the image could change in a way that breaks them, and LM Studio's own hardware check reports no GPU until the CUDA runtime is added by hand. Use them for testing, or install the LM Studio app or llmster directly on the host for a supported setup.

1. Start the container with the GPU. Run on the Docker host, with the NVIDIA Container Toolkit installed:

   mkdir -p ~/lmstudio-data
   docker run -d --name lmstudio --gpus all \
     -e EXTS=llm-llama-cuda -e LMS_SERVER_HOST=0.0.0.0 \
     -p 127.0.0.1:1234:1234 \
     -v ~/lmstudio-data:/root/.lmstudio \
     -v /path/to/your/gguf:/models:ro \
     lmstudio/llmster-preview:cpu

   The image's start script reads EXTS and tells the daemon that CUDA is allowed when the value contains cuda. LMS_SERVER_HOST=0.0.0.0 makes the API listen on all interfaces inside the container. Without it, the API answered inside the container but not on the published port, because lms server start binds to 127.0.0.1 by default. The 127.0.0.1: in -p keeps the port off your network. The API was ready 4.7 s after docker run.

2. Check what LM Studio sees.

   docker exec lmstudio nvidia-smi -L
   docker exec lmstudio lms runtime survey

   nvidia-smi listed the RTX 3090, but the survey said "No GPUs detected", because the image ships only the CPU runtime.

3. Download the CUDA runtime. lms runtime get --list did not offer a CUDA runtime. With --allow-incompatible it listed CUDA, CUDA 12, CUDA 13, Vulkan and ROCm builds. The CUDA 12 build was a 750 MB download:

   docker exec lmstudio lms runtime get llama.cpp-linux-x86_64-nvidia-cuda12-avx2 --allow-incompatible -y
   docker exec lmstudio lms runtime select [email protected]
   docker exec lmstudio lms runtime survey

   After the switch, the survey listed "NVIDIA GeForce RTX 3090 (CUDA, Discrete)" with 23.61 GiB. The runtime's manifest asks for a driver that supports CUDA 12.4 or later.

4. Link your models and load one.

   docker exec lmstudio lms import /models/Qwen3.5-9B-Q4_K_M.gguf -l --user-repo unsloth/Qwen3.5-9B-GGUF -y
   docker exec lmstudio lms load qwen3.5-9b -y
   docker exec lmstudio lms ps

   lms ps shows the context and the number of parallel slots for each loaded model. nvidia-smi on the host then listed LM Studio's llama-server process with 5,732 MiB of GPU memory for the 9B model. To download a model instead, use lms get.

5. Ollama 0.30.0 release notes
6. Ollama source: llm/server.go
7. Ollama 0.40.15: pinned llama.cpp build
8. Ollama docs: API
9. Ollama licence (MIT)
10. LM Studio docs: LM Studio, llmster and lms
11. LM Studio docs: lms get
12. LM Studio docs: REST API
13. lmstudio-js SDK on GitHub
14. lmstudio-python SDK on GitHub
15. unsloth Qwen3.5-27B-GGUF on Hugging Face

The runtime and the model links live in the data folder, so they survive when you remove and recreate the container. After a new docker run with the same folder, the CUDA runtime was still selected.

Test the API from the host:

curl -s http://127.0.0.1:1234/api/v1/chat -H 'Content-Type: application/json' \
  -d '{"model":"qwen3.5-9b","input":"Say hi in five words.","reasoning":"off"}'

The answer includes a stats object with the tokens per second, the time to first token and, if the request loaded the model, the load time.

Remove the LM Studio container and its files

These steps were run after the test. They remove the container, the 1.5 GB data folder (with the 1.1 GB of runtimes in it) and the image. They do not touch your GGUF files, because the data folder holds only links to them.

1. Remove the container.

   docker rm -f lmstudio

2. Delete the data folder. A plain rm -rf ~/lmstudio-data fails with "Permission denied", because the container wrote the files as root. Use sudo, or let the same image delete them:

   sudo rm -rf ~/lmstudio-data

   or, without sudo:

   docker run --rm --entrypoint sh -v ~/lmstudio-data:/lmshome lmstudio/llmster-preview:cpu \
     -c 'rm -rf /lmshome/* /lmshome/.[!.]*'
   rmdir ~/lmstudio-data

3. Remove the image.

   docker rmi lmstudio/llmster-preview:cpu

4. Ollama 0.30.0 release notes
5. Ollama source: llm/server.go
6. Ollama 0.40.15: pinned llama.cpp build
7. Ollama docs: API
8. Ollama licence (MIT)
9. LM Studio docs: LM Studio, llmster and lms
10. LM Studio docs: lms get
11. LM Studio docs: REST API
12. lmstudio-js SDK on GitHub
13. lmstudio-python SDK on GitHub
14. unsloth Qwen3.5-27B-GGUF on Hugging Face

If you used lms import without -l or -L, LM Studio moved your GGUF files into the data folder, and step 2 deletes them. Move them out first.

API compatibility: OpenAI and Anthropic endpoints

• Ollama has its own API under /api/, such as /api/chat, and an OpenAI-compatible API under /v1/. Its responses include the load time, the prompt time and the generation time.
• LM Studio has an OpenAI-compatible API under /v1/, including /v1/chat/completions, /v1/responses and /v1/embeddings. It also has its own REST API under /api/v1/, which can load, unload and download models, and an Anthropic-compatible /v1/messages endpoint.

Programs that speak the OpenAI API can use either tool by changing the base URL and the model name.

Licence and source code

Ollama is open source under the MIT licence. The LM Studio app is closed source. Since July 2025, LM Studio is free to use at home and at work, and its terms allow personal and internal business use. The lms command-line tool and LM Studio's JavaScript and Python SDKs are MIT licensed. If you prefer open-source software on your server, that settles the choice.

Which one to run on a home server

• Choose Ollama for a server that runs all the time with one user or a few. It has an official GPU image, frees memory after 5 minutes without requests, is open source, and was the faster of the two in this test.
• Choose LM Studio on a desktop where you want a graphical app to find and try models, or when several people or programs send requests at the same time and you want that to work with the defaults. Its desktop app for Linux comes as an AppImage and a .deb package; this test used only the headless daemon.
• Use both if you like, with one set of GGUF files: link them into LM Studio and import them into Ollama. Ollama's copy of the two test models used 22.4 GB of extra disk space.

Neither tool is a good fit for a small server without a GPU if you want quick answers from models this size. The hardware guide covers what each type of machine can do.

Frequently asked questions

Is LM Studio faster than Ollama?

Not in this test. On an RTX 3090 with the same GGUF files, Ollama 0.40.15 generated about 10% faster with Qwen3.5 9B and about 5% faster with Qwen3.5 27B. LM Studio started short answers sooner, and with its defaults it handled four requests at once faster, most clearly on the 27B model (90 against 33 tokens per second).

Do LM Studio and Ollama use the same engine?

On Linux with GGUF models, yes. Both start llama.cpp's llama-server, but they ship different llama.cpp builds and start it with different options, such as context size, batch size and parallel slots.

Can LM Studio and Ollama share the same model files?

Yes. LM Studio can link to an existing GGUF file with lms import -l, and Ollama can import the same file through a Modelfile. Ollama stores a copy in its own folder, so the file takes disk space twice.

Can LM Studio run headless or in Docker?

Yes. Its headless daemon, llmster, runs without the app, and the lmstudio/llmster-preview Docker image is a preview that supports only the CPU. In this test it ran on an NVIDIA GPU after downloading the CUDA runtime with lms runtime get --allow-incompatible, which LM Studio does not support.

Why is LM Studio using the CPU instead of the GPU?

In the official Docker image, the only runtime is the CPU build of llama.cpp, so LM Studio reports "No GPUs detected". After a CUDA runtime was downloaded and selected with lms runtime select, LM Studio listed the RTX 3090 and the model ran on the GPU.

Is LM Studio open source?

No. The app is closed source but free for home and work use. Its lms command-line tool and SDKs are MIT licensed, and Ollama is open source under the MIT licence.

Sources

1. Ollama releases on GitHub
2. Ollama FAQ: keep_alive, parallel requests and model storage
3. Ollama docs: context length defaults
4. Ollama docs: importing a GGUF model
5. Ollama docs: Docker
6. Ollama docs: OpenAI compatibility
7. lmstudio/llmster-preview on Docker Hub
8. LM Studio docs: headless mode (llmster)
9. LM Studio 0.4.0 release post
10. LM Studio docs: lms server start
11. LM Studio docs: lms load
12. LM Studio docs: lms import
13. LM Studio docs: lms runtime
14. LM Studio docs: idle TTL and auto-evict
15. LM Studio docs: parallel requests
16. LM Studio docs: REST API chat endpoint
17. LM Studio docs: OpenAI-compatible endpoints
18. LM Studio docs: Anthropic-compatible endpoint
19. LM Studio download page
20. LM Studio blog: free for use at work
21. LM Studio app terms
22. lms command-line tool on GitHub
23. unsloth Qwen3.5-9B-GGUF on Hugging Face
24. Ollama 0.30.0 release notes
25. Ollama source: llm/server.go
26. Ollama 0.40.15: pinned llama.cpp build
27. Ollama docs: API
28. Ollama licence (MIT)
29. LM Studio docs: LM Studio, llmster and lms
30. LM Studio docs: lms get
31. LM Studio docs: REST API
32. lmstudio-js SDK on GitHub
33. lmstudio-python SDK on GitHub
34. unsloth Qwen3.5-27B-GGUF on Hugging Face
35. Ollama 0.30.0 release notes
36. Ollama source: llm/server.go
37. Ollama 0.40.15: pinned llama.cpp build
38. Ollama docs: API
39. Ollama licence (MIT)
40. LM Studio docs: LM Studio, llmster and lms
41. LM Studio docs: lms get
42. LM Studio docs: REST API
43. lmstudio-js SDK on GitHub
44. lmstudio-python SDK on GitHub
45. unsloth Qwen3.5-27B-GGUF on Hugging Face