Ollama vs LM Studio vs llama.cpp Runners: VRAM and RAM, Measured

The VRAM/RAM difference between Ollama, LM Studio, and llama.cpp comes mostly not from the engine but from "defaults", and one decisive fact is that all three use the same inference engine (llama.cpp), so with the same GGUF, quant, and context the model+KV cache footprint is nearly identical, and the real differences are exactly three (default context num_ctx, model residency keep_alive, and wrapper overhead) — for example LM Studio's Electron GUI eats a measured 3.1GB of VRAM even at idle, 1.2GB more than Ollama (about 1.9GB).

In plain terms: the three runners are three cars on the same engine. The engine (efficiency) is the same, but the default seat count (context window), idling time (residency), and body weight (GUI overhead) differ, so real-world fuel (memory) diverges. The answer to "why is my VRAM so full?" is usually the runner's settings, not the model.

What differs between the three runners?#

A trade of convenience for overhead. llama.cpp is the bare engine with the lowest overhead and every knob in hand (also fastest at a measured 77.0 tok/s). Ollama is a thin wrapper that adds about 100MB RAM and ~1.9GB idle VRAM with convenient auto-offload (about 69.1 tok/s, ~10% slower). LM Studio is a GUI, the heaviest at about 500MB RAM and 3.1GB idle VRAM, but easy with sliders (76.8 tok/s). So minimal and predictable is llama.cpp, convenient is Ollama, GUI is LM Studio. The diagram below is the "same engine, different costume" structure.

Why does the default context drive memory?#

Because the context window sets the KV cache size. For the same model, raising context grows the KV cache linearly - 32K context on a 13B adds about 8GB. The diagram below is that linear context-to-KV-cache growth.

Ollama historically had a small default (2K-4K), breeding the "it forgets my chat" myth, but recent builds auto-scale by VRAM (4k under 24GB, 32k at 24-48GB, 256k at 48GB+). LM Studio caps at the model max (8-32K) with no sliding window. llama.cpp lets you set n_ctx directly. So carelessly raising context makes a model that fit cleanly spill out of VRAM - check context first (Ollama's ollama ps shows offload).

Why is VRAM full at idle?#

Because of model residency (keep_alive) and wrapper overhead. Ollama keeps a model in memory for 5 minutes by default (warm reuse), so VRAM stays occupied at idle - tune it with OLLAMA_KEEP_ALIVE, and loading two at once doubles RAM too. LM Studio evicts via Idle TTL and Auto-Evict, and the llama.cpp server holds it until the process exits. Add GUI overhead and LM Studio has the highest idle VRAM (3.1GB). Below is the idle-VRAM comparison and residency policy.

So the answer to "why won't VRAM free up while idle?" is residency policy plus the wrapper, not model size.

So which do you pick?#

The key is matching defaults to your purpose.

• Minimal, server, reproducible: llama.cpp directly (manual n_ctx and -ngl, lowest overhead). Good for scripts and production.
• Convenient, automatic: Ollama (auto-offload, keep_alive). Just know the default context and 5-minute residency and tune as needed.
• GUI, exploration: LM Studio (sliders, MLX). Accept the 3.1GB idle VRAM. Measure exact values on your own GPU, model, and version.

Related reading: 로컬 오픈 LLM VRAM·RAM 요구량, 직접 계산·실측, 노트북에서 돌리는 AI 모델 VRAM·RAM 요구량 실측

Reference links

• llama.cpp (shared inference engine)
• Ollama (wrapper, auto-offload)
• lms (LM Studio CLI, model load/TTL)
• llama-cpp-python (programmatic n_ctx)
• MLX (Apple Silicon backend)

Note: GB and tok/s figures are public 2026 measurements and many are single-hardware benchmarks, so treat them as directional (not permanent numbers). Runner defaults (especially Ollama's VRAM-scaled context) change by version, so check current docs before configuring, and measure exact memory on your own GPU, model, quant, and context (these numbers are only a start). Runners and models move fast, so this is reviewed quarterly.