Ollama, LM Studio, llama.cpp Runners: Common Pitfalls and Fixes

If running local LLMs with Ollama, LM Studio, or llama.cpp keeps hitting "I clearly changed the setting - why is it unchanged," start with the key 2026 fact: all three runners use the same engine (llama.cpp). Ollama and LM Studio are both llama.cpp underneath. So the problem is usually not the model but the wrapper's "defaults" and "version lag". The most notorious example: Ollama ignores a model's advertised 128k context and loads just 4k by default, and when you overflow it silently drops the oldest messages with no error. To the user, "the model suddenly forgot." This guide walks the runner-specific traps as symptom -> cause -> fix, with numbers.

In plain terms: runners are three cars on the same engine. The engine (llama.cpp) is identical; the dashboard and default settings (the wrapper) differ. For "simplicity," Ollama ships with the side mirrors folded in (4k context), and if you drive without noticing, you can't see behind you (lost context). And all three lag on engine firmware updates (version lag), sometimes mishandling the newest models.

Why does Ollama lose your conversation?

Because the context window (num_ctx) is still at its default - not the advertised max. Even if Gemma3 supports 131,072, Ollama loads only 2,048-4,096 by default (dynamic by VRAM). The danger is it fails silently: once cumulative tokens exceed num_ctx, instead of an error it quietly drops the leading messages. The fix and common re-mistakes: (1) at runtime ollama run <model> --num-ctx 16384, or permanently a Modelfile PARAMETER num_ctx 32768 - but the Modelfile uses an underscore (num_ctx); a hyphen (num-ctx) is silently ignored. (2) The env var is OLLAMA_CONTEXT_LENGTH, not the legacy OLLAMA_NUM_CTX. (3) Precedence is API > env var > Modelfile > default. (4) Check the real loaded value with ollama ps, not ollama show (which shows the architectural max). (5) Mind tags: yi:6b-200k is long-context, but the base yi:34b is 4k. And your system prompt eats the budget too - a 2,000-token system prompt burns half of a 4,096 window.

Why do num_gpu and disk cause trouble?

Partial offload creates a performance cliff, and Ollama duplicates disk usage. num_gpu is the number of layers to put on the GPU, but offloading only some (partial offload) actually gets dramatically slower - on an RTX 4060 8GB, num_gpu 25 cuts VRAM from 7.2 to 4.8GB but collapses speed from 40.58 to 8.62 tok/s, 4.7x slower (per-layer CPU<->GPU transfer overhead). So when it fits, num_gpu 99 (offload all) is the rule, and auto-detection ignores the KV cache so it misjudges when VRAM is tight. It's also baked into the model definition, so changing it means rebuilding the model. Disk: Ollama can't reuse existing GGUFs because of its own blob format, re-downloading and repackaging (and multi-file split GGUFs aren't supported). If you import a GGUF directly (FROM ./model.gguf + ollama create), template auto-detection often fails and stop tokens get ignored, so copy the base template from ollama show --modelfile.

Which is fastest, and which should you pick?

The speed gap comes from wrapper overhead and version lag, not the model - all three are hardware-bound. In a July 2026 single-GPU benchmark, LM Studio was within ±2% of llama.cpp (essentially a tie), while Ollama trailed 8-14% on every category (~10% tax). On Apple it widens: on a Mac Studio M3 Ultra, Gemma 3 1B ran at LM Studio 237 t/s vs Ollama 149 t/s. The hidden real cause is version lag in the bundled llama.cpp build - llama.cpp pushes performance commits weekly (sometimes daily), but neither Ollama nor LM Studio tracks HEAD in real time, so new-model params like Qwen 3.5's MoE routing may not work in the wrappers yet (the direct llama.cpp server handles them). Picking: ==API/headless = Ollama, GUI/quick switching = LM Studio, max control/embedding = llama.cpp. But for a casual user the 10% tax shouldn't decide it - getting running in 2 minutes beats an afternoon of flag-tuning==.

So what's a safe runner setup?

The key is don't trust the defaults - verify the actual loaded value with your eyes.

• Ollama: set context explicitly (OLLAMA_CONTEXT_LENGTH or per-request num_ctx) and confirm the real load with ollama ps. Underscore in the Modelfile; mind the tags.
• GPU/memory: no partial offload (num_gpu 99 when it fits); when raising context, budget the KV cache too - overflow VRAM and you drop 20-50x. Use KV quantization (q8_0) if needed.
• Runner choice: headless = Ollama, GUI = LM Studio, control = llama.cpp. If a new model misbehaves, suspect bundled version lag and cross-check with the latest llama.cpp server. A/B every setting at your real model and context, then lock it in.

Related reading: Ollama·LM Studio·llama.cpp 실행기, 2026년에는 무엇을 고를까?, 로컬 코딩 보조 모델 2026: 직접 돌려보고 고른 현황과 추천

Related reading: Ollama·LM Studio·llama.cpp 실행기 VRAM·RAM 실측, Ollama·LM Studio·llama.cpp 실행기, 2026 현황과 추천

Reference links

• llama.cpp (local inference engine, server)
• Ollama (local runner, Modelfile)
• Ollama context length official docs
• LM Studio (GUI, OpenAI-compatible server)
• Ollama local GGUF import request issue

Note: figures like the default context (2048-4096), speed tax (+10%, ±2%), partial offload (40.58->8.62 tok/s), M3 Ultra (237 vs 149 t/s), and the drop (20-50x) are 2026 public and community-measured numbers that vary by hardware, build, model, and quantization (not permanent; many individual benchmarks). Ports, flags, and defaults change across runner versions (e.g., OLLAMA_NUM_CTX -> OLLAMA_CONTEXT_LENGTH), and num_gpu multi-GPU behavior differs by version and config, so verify on your own setup. After configuring, verify with ollama ps and nvidia-smi. Runner practice moves fast, so this is reviewed quarterly.