Ollama vs llama.cpp vs LM Studio: same engine, different defaults

Ollama and LM Studio both run GGUF models on llama.cpp, the engine you can also run on its own, so the work done for each token comes from the same code. When one of them feels slower, the cause is usually a default: how long a context it reserves, how many requests share that memory, or who decides what goes on the GPU. On a 24GB card, for example, Ollama starts Qwen3 32B at 32k, which in CanRun's calculation pushes part of it into system RAM (ollama ps shows the split), while llama.cpp's own server shortens an unset context so the model stays on the GPU. CanRun's estimates are calculated for llama.cpp, and we have no side-by-side speed measurements of the three tools, so this guide compares settings, not winners.

One engine, three front ends

llama.cpp is an open-source engine, under the MIT license, that loads a GGUF file and runs it on NVIDIA, AMD, Intel or Apple GPUs or on the CPU. It comes as a set of command-line programs. llama-server serves a chat page in the browser and an OpenAI-compatible API, and llama-bench measures speed. On Windows you download a ready-made build from its GitHub releases page and point it at a GGUF file, or let -hf fetch one from Hugging Face.

Ollama is a background service with a command-line tool, a desktop app and its own model library, also under the MIT license. Since version 0.30 it runs GGUF models by starting llama.cpp's llama-server, which it ships in its install folder, with a short list of flags. The llama.cpp build it ships is named in a file called LLAMA_CPP_VERSION in its source. On Apple Silicon it also has an MLX engine for some models. Its library names files by tag: on Ollama's tag list, qwen3:14b is the same file as qwen3:14b-q4_K_M.

LM Studio is a desktop app with a model browser, a local server and a command-line tool called lms. LM Studio says the app is free to use at home and at work. It runs GGUF models with its llama.cpp engine, in separate builds for CUDA, Vulkan, ROCm and the CPU, and on a Mac it adds an MLX engine. LM Studio calls these engines runtimes and by default updates them on its own; you can switch between them in its runtimes tab or with lms runtime.

A change in llama.cpp reaches Ollama and LM Studio only when they update the llama.cpp build they ship. All three read the same GGUF files and offer an OpenAI-compatible API, so a chat app or coding tool that speaks that API can usually work with any of them. The weights and KV cache a model needs at a given context length and KV cache type are also the same in all three; only the compute buffer, the runtime's working memory, depends on a batch setting that Ollama picks differently (see the list below and, for how memory adds up, How much VRAM do local LLMs need? 8–32 GB tiers (2026)). CanRun's numbers describe llama.cpp running a GGUF file. Models that a Mac runs on the MLX engine do not go through llama.cpp and are outside this guide.

The defaults that differ

With the same file on the same card, the three tools still start from different settings. These are the ones that change memory or speed:

• Context length. Ollama picks its default context length from the GPU memory it finds: 4k tokens below 24 GiB, 32k tokens from 24 to 48 GiB, and 256k tokens at 48 GiB or more (Ollama docs, checked 2026-09-29). Its server log shows the value it picked on a line containing vram-based default context. llama-server started without -c takes the training context stored in the GGUF file, usually the model's maximum. Its fit option, on by default, then shortens that context if the model would not fit in free VRAM, down to a floor of 4k, before it moves any weights off the GPU. Passing -c 0 asks for the full length and turns that shortening off. LM Studio takes the context from its load settings or lms load --context-length; its documentation does not give a default, so read the value in the load panel.
• When the context fills up. Ollama drops the oldest messages and keeps going (see Ollama slow or forgetting your prompt? Context length defaults). llama-server has context shift off by default: a request longer than the context gets an error, and a reply stops when the context is full. LM Studio lets you choose between stopping at the limit, cutting out the middle of the chat and keeping a rolling window.
• KV cache type. All three start with f16, and all three can quantize it. Ollama quantizes the KV cache only when the server starts with OLLAMA_KV_CACHE_TYPE (f16, q8_0 or q4_0) and flash attention on; the setting applies to every model the server runs (Ollama docs, checked 2026-09-29). In llama-server you set it per launch with --cache-type-k and --cache-type-v. LM Studio's load settings include a K cache and a V cache type, and its SDK reference notes that the V cache type needs flash attention.
• Flash attention. llama-server defaults to auto, and Ollama's FAQ says it uses flash attention automatically when the backend and devices support it. LM Studio has a flash attention switch in each model's load settings.
• Batch size. llama-server processes prompts in chunks of 512 tokens (-ub) by default. Recent Ollama versions raise that to 1024 or 2048 for contexts above 4k when VRAM allows, unless you set num_batch. That speeds up prompt processing and takes a larger compute buffer.
• Parallel requests. Ollama serves one request per model at a time unless you raise OLLAMA_NUM_PARALLEL. llama-server opens four slots that share one KV cache, and LM Studio 0.4 and later does the same. The section on parallel requests below shows what that means for memory.
• GPU placement. llama-server works out the number of GPU layers itself (-ngl auto). Ollama passes no layer count unless you set num_gpu, so llama.cpp decides there too. LM Studio picks the GPU offload automatically when you do not set it.

The starting context and what it costs

The KV cache, the memory that holds the conversation so far, grows with the context, so the starting context explains most of the memory difference between the tools. The table gives the f16 KV cache at three lengths that matter here. 4k is Ollama's default below 24GB of VRAM and 32k its default on 24GB and 32GB cards. 128k is where llama-server starts for Llama 3.1 8B and Gemma 3 12B, whose maximum is 128k; the Qwen3 models support less, so their 128k cells show a dash.

Add the weights and a compute buffer, and Llama 3.1 8B at Q4_K_M, a 4-bit quant, needs 5.7 GB at 4k but 23.5 GB at its full 128k. Here is where each tool starts on two common cards.

On an 8GB GeForce RTX 4060, which can use 7.4 GB:

• Ollama starts at 4k, and the model sits fully on the GPU.
• llama-server without -c starts from 128k and shortens it. In CanRun's calculation 8k with an f16 KV cache still fits, but 16k already sends part of the weights to system RAM. By our numbers, the context it settles on falls between the two. Its own reading of free VRAM decides, and the startup log prints the result on a line containing llama_context: n_ctx.
• LM Studio uses whatever its Context Length setting says.

On the GeForce RTX 5060 Ti 16GB, which can use 15.4 GB, Ollama still starts at 4k. Llama 3.1 8B fits fully at 64k with an f16 KV cache, which needs 14.3 GB. At 128k the f16 KV cache alone takes 17.2 GB, more than the card can use, so CanRun's calculation runs that setting on the CPU only. llama-server therefore lands between 64k and 128k on this card by our numbers, many times the context Ollama gives the same model by default.

Neither default is wrong. A short context keeps memory low but drops the start of a long chat. A long one keeps the chat, costs memory and slows generation a little as it fills, because every new token reads the whole KV cache. To get the same behavior from all three, set the context yourself: OLLAMA_CONTEXT_LENGTH, num_ctx or the context length slider in the app's settings in Ollama, -c in llama-server, and the Context Length setting or --context-length in LM Studio. What each length costs for other models is in KV cache explained: how context length eats VRAM.

Why Ollama can be slower on a 24GB card

The gap between the defaults matters most on 24GB cards. Ollama picks its default context length from the GPU memory it finds: 4k tokens below 24 GiB, 32k tokens from 24 to 48 GiB, and 256k tokens at 48 GiB or more (Ollama docs, checked 2026-09-29). Ollama's code sets that cut-off slightly lower than its docs, so a 24GB GeForce RTX 4090 lands on 32k. Take Qwen3 32B, a dense model that reads every weight for every token, at Q4_K_M. At 8k it needs 22.0 GB, inside the 23.4 GB the card can use, and it Runs great. At 32k with an f16 KV cache it needs 28.7 GB.

Ollama hands that 32k to llama-server as a fixed -c value. llama.cpp's fit option does not touch a context the caller set, so it moves layers to system RAM instead, and ollama ps shows a CPU/GPU split under PROCESSOR. Ollama lowers its automatic context only when a load fails outright for lack of memory, and a model that loads with a split keeps the 32k. In CanRun's table the 32k f16 cell is a partial offload, with a much lower speed band than 8k.

llama-server started with only the model does the opposite. It starts from the model's own context, sees that it does not fit and shortens it until the whole model stays on the GPU. On this card, 16k with an f16 KV cache already spills in CanRun's calculation, so by our numbers it settles between 8k and 16k and keeps full-GPU speed. The engine and the file are the same, but the results are opposite: Ollama keeps the context and loses speed, and llama-server keeps the speed and shortens the context.

To keep Qwen3 32B on the GPU in Ollama, shorten the context or quantize the KV cache; the table shows which settings stay fully on the GPU, and both fixes are walked through in Ollama slow or forgetting your prompt? Context length defaults. To get Ollama's behavior from llama-server instead, pass -c 32768 yourself. The GeForce RTX 3090 has the same 24GB and the same default.

Parallel requests and MoE models

One context per request, or one shared cache

When several requests reach the same model at once, the three tools divide memory differently.

• Ollama gives each parallel request its own full context. It starts llama-server with the context length times OLLAMA_NUM_PARALLEL, and its FAQ says the memory needed grows with both. The default is one request, so a default install reserves one context.
• llama-server opens four slots by default with one shared ("unified") KV cache sized by the context. One request can use the whole cache, and requests that run at the same time share it, so the KV cache does not grow with the number of slots.
• LM Studio 0.4 and later works the same way: its Max Concurrent Predictions setting defaults to four, with Unified KV Cache on, which LM Studio says should add no memory overhead.

Raising OLLAMA_NUM_PARALLEL is where this matters. At 8k, Qwen3 14B's KV cache takes 1.3 GB, and the whole model fits on a 12GB RTX 3060, with less than a gigabyte to spare. With OLLAMA_NUM_PARALLEL=4 and the same 8k per request, Ollama reserves four of those, as much KV cache as one 32k context (5.4 GB). In CanRun's calculation a 32k context no longer fits fully on that card, and part of the weights move to system RAM. CanRun's tables assume one request at a time.

Who places the MoE experts

A mixture-of-experts (MoE) model reads only a few of its experts for each token, so the experts that do not fit in VRAM can sit in system RAM while the rest of the model stays on the GPU. The breakdown below shows the split CanRun calculates for Qwen3 30B-A3B (2507) on the GeForce RTX 5060 Ti 16GB. The model needs 19.8 GB, more than the 15.4 GB the card can use, so the experts of some layers go to system RAM.

In this setup it Runs well, a theoretical estimate (±30%). llama.cpp's fit option makes the same kind of split by default. It puts the non-expert weights on the GPU first and moves experts to system RAM only as far as it has to. One catch: this model does not fit on the card even at 4k, so llama-server without -c first cuts the context to its 4k floor and only then moves experts, and Ollama starts at 4k on a 16GB card anyway. Pass -c 8192 or set OLLAMA_CONTEXT_LENGTH yourself; in CanRun's calculation 32k still Runs well here, a theoretical estimate. Ollama gets the same kind of split because it leaves the layer count to llama.cpp. A num_gpu value left in a Modelfile or a client changes that: Ollama then passes a fixed layer count, and llama.cpp splits whole layers instead of experts.

LM Studio's GPU offload setting moves whole layers. For MoE models it adds "Force Model Expert Weights onto CPU", which, as its release notes describe it, moves all expert weights to system RAM, like llama.cpp's --cpu-moe. On a card with room for some experts, that leaves VRAM unused, and CanRun's speed band does not describe that setting. LM Studio's documentation does not say whether its automatic offload splits experts the way llama.cpp's fit does. How much system RAM the larger MoE models need is covered in Running MoE models bigger than your GPU: gpt-oss-120b with system RAM.

Running all three on the same settings

To compare the tools on your own PC, take the defaults out of the picture. Use the same GGUF file, the same context and KV cache type, one request at a time, and the whole model on the GPU. The commands below load Qwen3 14B at Q4_K_M from the Hugging Face repository our combo pages use, at 8k. On a 16GB RTX 5060 Ti that fits fully on the GPU.

llama.cpp: from the GitHub releases page, take the CUDA build and the matching cudart file for an NVIDIA card (the Vulkan build for AMD or Intel), unzip both into one folder, open PowerShell there and run the line below. On macOS or Linux, type llama-server instead of .\llama-server.exe. -np 1 replaces the four default slots with one, like Ollama. Check that the startup log names your GPU; if it does not, the build is running on the CPU. After each reply, the console prints the generation speed on its eval time line.

.\llama-server.exe -hf unsloth/Qwen3-14B-GGUF:Q4_K_M -c 8192 -np 1 -ngl all -fa on

Ollama: either set the context length slider in the app's settings to 8k and leave the app running, or quit the app from the taskbar and start the server with the context you want. Then run the model from a second PowerShell window.

$env:OLLAMA_CONTEXT_LENGTH="8192"; ollama serve

ollama run hf.co/unsloth/Qwen3-14B-GGUF:Q4_K_M --verbose

--verbose prints timings after each reply, and "eval rate" is the generation speed. While the model is loaded, ollama ps should show 8192 under CONTEXT and 100% GPU under PROCESSOR. The hf.co/ name loads the same file as llama-server. A library tag such as qwen3:14b is a file Ollama packaged, so its size and contents can differ from another publisher's Q4_K_M. Ollama may also pick a larger batch at this context, which changes prompt speed but not generation speed, so compare generation speed.

LM Studio: open model search (the search button at the top right, or Ctrl+Shift+M), search for unsloth/Qwen3-14B-GGUF and download the Q4_K_M option. When you load it, set the context length to 8192, the GPU offload to the maximum and Flash Attention on to match -fa on. You can also load it from a terminal, using the name lms ls lists for the model:

lms load <model> --context-length 8192 --gpu max

lms chat <model> --stats then prints the speed after each reply. Send each tool the same prompt, skip the first run while things warm up, and compare generation speed. If the numbers still differ, two things are left to check:

• The llama.cpp build. Ollama ships the build named in its LLAMA_CPP_VERSION file, LM Studio shows each runtime's version in its runtimes tab (Ctrl+Shift+R), and llama.cpp's own builds are numbered. A newer build can be faster or slower for a given model.
• The backend. CUDA and Vulkan builds of llama.cpp can run the same model at different speeds. Ollama names the library it picked on the inference compute line of its server log, and LM Studio's runtimes tab shows which one is selected.

For a number that does not depend on any front end, llama-bench runs a fixed test on the same file: by default it times prompt processing (-p 512) and generation (-n 128) on an empty context. Adding -d 8192 repeats the test with 8k already in the context, closer to a long chat.

Which one fits how you work

The tool does not change the weights and KV cache a model needs. Pick the model, quant and context by memory first, then pick the tool for the way you work.

• Ollama suits you if you want a service that runs in the background and serves other apps, with models pulled by a short tag. Set the context yourself on cards below 24GB, and remember that one KV cache type applies to every model on the server.
• llama.cpp suits you if you want every option and the newest build, and you are happy to manage files and command lines yourself. Its defaults lean toward keeping the model on the GPU, and it tells you with an error when a request is longer than the context.
• LM Studio suits you if you prefer a window to a terminal. You can browse Hugging Face, see a memory estimate and a warning before a load that is likely to run out of memory, and save settings per model. On a Mac it also runs MLX models.

How sure are these numbers?

The memory figures (weights, KV cache, compute buffer) are calculated from real GGUF file sizes and headers and each model's published configuration. The weights and KV cache are the same whichever tool loads the file; the compute buffer depends on the batch size. The speeds are estimates with a band and a confidence label. Calibrated means ±12% for dense models fully on an NVIDIA or AMD card, and ±20% for partial offload, MoE models and other hardware. Theoretical means ±30%, and it applies here to Qwen3 30B-A3B (2507) with its experts split between VRAM and system RAM.

CanRun models llama.cpp, and nearly all the public benchmarks it calibrates against were run on llama.cpp directly, not through Ollama or LM Studio. gpt-oss-20b on the RTX 5060 Ti 16GB is one of them: it Runs great there, and its speed comes from a public measurement rather than an estimate. That result comes from the llama.cpp project's own guide to running gpt-oss, measured with llama-bench.

We have no measurements of one model run through all three tools, so CanRun does not rank them. Differences that come from the llama.cpp build, the backend or the way each app reports speed are outside the estimate. Each runtime also keeps its own memory margin; llama.cpp's fit, for one, leaves some VRAM free on each device by default. A pair that fits with little headroom in our tables can therefore come out split on your machine. ollama ps and the llama-server startup log show what actually happened; in LM Studio, its own estimate (lms load --estimate-only) is a better guide for that app than ours. Our tables assume Windows with the card driving the display, 32GB of DDR5 system RAM, one model loaded and one request at a time.

Verdict names in the text refer to an 8k context with an f16 KV cache unless a sentence says otherwise. Qwen3 14B and Qwen3 32B think by default and gpt-oss-20b always thinks, so the stricter speed thresholds for thinking models apply to them (1.5× the speed, not shown in the legend below). The thresholds:

FAQ

Is Ollama slower than llama.cpp?

Not because of the engine: since version 0.30, Ollama runs GGUF models through llama.cpp's own llama-server. Check ollama -v first; versions before 0.30 used a different engine, and the 0.30 release notes list faster performance on NVIDIA cards. When a current Ollama is slower with the same file, check the defaults. The ones to check are a 32k context on a 24GB card, which pushes a dense model such as Qwen3 32B partly into system RAM, a leftover num_gpu value, a raised OLLAMA_NUM_PARALLEL and an older bundled llama.cpp build. ollama ps shows the context and the CPU/GPU split. CanRun has no side-by-side measurements, so it does not say which tool is faster.

Why does LM Studio show a different speed from Ollama for the same model?

Usually because something other than the tool differs: the file (an Ollama library tag or a Hugging Face GGUF), the context length, the KV cache type, flash attention, the GPU offload or the runtime (CUDA or Vulkan). Load the same file with the same settings, as in the section on running all three, and compare the generation speed after a warm-up run.

Which one should I use on an 8GB or 12GB card?

Any of them, once you set the context yourself, because the weights and KV cache a model needs are the same in all three. Ollama starts at 4k on these cards. That keeps a model such as Llama 3.1 8B fully on an 8GB card, but long chats lose their beginning quickly. llama-server shortens its starting context until the model fits, and LM Studio uses its Context Length setting. Pick the length from the context table on a combo page, such as our page for Qwen3 14B on the GeForce RTX 3060 12GB, and set it in whichever tool you use.

Can the three tools share one model file?

Yes, with one catch for disk space. llama-server opens any GGUF file where it is, with -m and the path. LM Studio's lms import moves a file into its models folder by default; add --hard-link or --symbolic-link to leave the original in place. Ollama builds a model from a file with a Modelfile line FROM followed by the path, then ollama create, and keeps its own copy in its models folder. CanRun's combo pages print the Hugging Face name of the file they assume, so the same quant can be loaded in each tool.

Sources

• llama.cpp: the engine, its license and supported hardware.
• llama.cpp releases: Windows builds for CUDA, Vulkan and other backends, with separate cudart files for the CUDA builds.
• llama.cpp server README: -c (0 = from the model), --fit (on by default) and --fit-ctx (the shortest context fit may set, 4k by default), -ngl auto, -fa auto, -b and -ub (2048 and 512 by default), --cache-type-k and --cache-type-v, -np (auto), --kv-unified, --context-shift (off by default), -hf, the web UI and the OpenAI-compatible API.
• llama.cpp source: tools/server/server.cpp: automatic slots become four slots with a unified KV cache.
• llama.cpp source: common/fit.cpp and fit-params README: an unset context starts at the model's training context and is shortened before layers move, down to the 4k floor when the model does not fit even there, while a context the user set is left alone.
• llama.cpp source: tools/server/server-context.cpp: the error for a request longer than the context, stopping when the context is full with context shift off, and the eval time line printed after each reply.
• llama.cpp source: src/llama-context.cpp: the n_ctx startup log line.
• llama-bench README: default prompt and generation lengths, -d for a filled context.
• Ollama v0.30.0 release notes: Ollama runs models with llama.cpp, alongside its MLX engine on Apple Silicon, with faster performance on NVIDIA hardware.
• Ollama source: llm/llama_server.go: the flags Ollama passes to llama-server (-c as context times parallel requests, -np, no -ngl unless num_gpu is set, --flash-attn auto, --context-shift, the KV cache type, -b and -ub).
• Ollama source: server/routes.go and server/sched.go: the VRAM-tier default with cut-offs slightly below the documented tiers, its log line, lowering the automatic context only after a failed load, and the larger batch for contexts above 4k.
• Ollama source: LLAMA_CPP_VERSION and LICENSE: the bundled llama.cpp build and the MIT license.
• Ollama docs: context length: the context length slider in the app's settings.
• Ollama docs: OpenAI compatibility and LM Studio docs: OpenAI compatibility: the OpenAI-compatible APIs.
• Ollama FAQ: flash attention, OLLAMA_KV_CACHE_TYPE and its precision notes, OLLAMA_NUM_PARALLEL and memory, ollama ps.
• Ollama docs: importing a model: a GGUF file with a Modelfile FROM line and ollama create.
• Ollama library: qwen3 tags: qwen3:14b is the same file as qwen3:14b-q4_K_M.
• Hugging Face: using Ollama with GGUF models on the Hub: the ollama run hf.co/user/repo:quant form.
• LM Studio 0.4.0 release notes and blog post: parallel requests, four slots with Unified KV Cache by default, the llama.cpp engine, and the new model search (Ctrl+Shift+M).
• LM Studio 0.3.2 release notes: the KV cache back to f16 by default.
• LM Studio 0.3.9 release notes: the CPU, CUDA, Vulkan, ROCm and Metal llama.cpp runtimes, their automatic updates and the runtimes tab.
• LM Studio 0.3.23 release notes: Force Model Expert Weights onto CPU.
• LM Studio 0.3.27 release notes: memory estimates and out-of-memory warnings before loading.
• LM Studio docs: lms load, lms chat, lms import and lms runtime: --context-length, --gpu, --estimate-only, --stats, import modes and runtime updates.
• LM Studio docs: per-model defaults: saved load settings, including flash attention.
• LM Studio SDK: load configuration and prediction configuration: K and V cache quantization types and the context overflow choices.
• LM Studio: free for work: free use at home and at work.
• llama.cpp discussion #15396: running gpt-oss with llama.cpp: the measured gpt-oss-20b result on the RTX 5060 Ti 16GB, taken with llama-bench.