Every "run LLMs locally" guide treats Ollama, LM Studio, and llama.cpp as interchangeable. They all wrap llama.cpp under the hood, so they should perform the same, right?
I ran the same quantized model (Qwen 2.5 Coder 13B, Q4_K_M, ~8.1 GB) through all three on the same machine (M-series laptop, 16 GB unified memory, nothing else running) and measured tokens/sec on identical prompts. The results were not close.
The numbers (avg of 5 runs, 512-token generations)
| Runner | Prompt processing (tok/s) | Generation (tok/s) | RAM footprint | Setup time |
|---|---|---|---|---|
llama.cpp (raw, -ngl 99) |
412 | 18.9 | 8.4 GB | ~10 min (build) |
| Ollama | 389 | 17.4 | 8.7 GB | ~2 min |
| LM Studio | 301 | 7.9 | 9.8 GB | ~3 min (GUI) |
LM Studio's GUI is genuinely pleasant — but it was 2.4x slower on generation than raw llama.cpp, and it held almost a gigabyte more RAM for the same model. My guess: default context size and the Electron shell. I couldn't find a config that closed the gap.
What I actually use now
# llama.cpp, one binary, no server, no daemon
./llama-cli -m qwen2.5-coder-13b-q4_k_m.gguf -ngl 99 -c 4096 \
-p "Refactor this function for readability:" -f snippet.py
- Raw llama.cpp for anything scripted/batch — fastest, smallest footprint, zero magic
- Ollama when I need an OpenAI-compatible endpoint for tools like Continue — 8% slower than raw, worth it for the ecosystem
- LM Studio — uninstalled
The uncomfortable conclusion
"Which local LLM runner should I use?" has a boring answer in 2026: whichever is closest to the metal. The friendly wrappers aren't free — they're paid for in tokens/sec, and on a 16 GB machine that difference is the line between "usable pair programmer" and "watch it type".
I wire the Ollama endpoint into my editor through MonkeyCode (free, open-source — the whole autocomplete stack costs $0): https://ly.cyberserval.tech/iIETXiF
Have you benchmarked your local setup, or are you trusting the wrapper defaults? Curious if the LM Studio gap reproduces on Windows/Linux.
Top comments (0)