LM Studio vs Ollama vs llama.cpp: Which Runner for Plebs?

There is no wrong answer among these three. Every time a pleb asks which one to pick, a small civil war breaks out in the replies, and it’s mostly noise. llama.cpp, Ollama, and LM Studio are all excellent. They serve different plebs with different temperaments and different hardware.

Quick credit before we go further, because shoulders of giants is the whole game here. llama.cpp is the C++ inference engine Georgi Gerganov wrote, and it is the foundation that almost every local LLM runner you’ve ever heard of is built on top of. Ollama, shepherded by Michael Chiang and Jeffrey Morgan, wraps llama.cpp in a daemon, a CLI, and an HTTP API so it just works. LM Studio, built by the team at Element Labs, wraps the same core ideas in a polished desktop GUI that is especially sharp on Apple Silicon. Adjacent tools like vLLM and MLX matter too and we’ll touch them at the end, but they solve different problems.

This post helps you pick the right one in the next 15 minutes, not by declaring a winner, but by matching you to the tool that fits your life. If you’re building a sovereign AI stack for your own hardware, the runner is where this all starts.

The three at a glance

One table doesn’t decide it for you — but it narrows the conversation. Now to the honest breakdown of each.

llama.cpp — the foundation

What it is. llama.cpp is the inference engine. When Ollama runs a model, it’s running llama.cpp under the hood. When LM Studio runs a GGUF, it’s running code that descends from llama.cpp. When you see some new quantization format or CPU optimization land in the local-LLM world, it usually lands here first. Georgi Gerganov started this project as a “can I run LLaMA on my MacBook” experiment and it turned into the most important piece of infrastructure in consumer AI.

Who should pick it. Power plebs. The kind of pleb who already compiles their own Bitcoin node from source, who reads commit messages for fun, and who wants to be three days ahead of everyone else when a new model drops. Also: anyone running a dedicated inference server in their home Hashcenter who wants every last token per second. And anyone who might eventually contribute a quantization, a CPU intrinsic, or a bug fix back upstream.

Honest tradeoffs. This is the rawest experience of the three. No GUI. You will learn -ngl (GPU layers), -c (context size), --mmap, -b (batch), --rope-freq-base, and a dozen other flags. That is either rewarding or annoying depending on your personality. There is no curated model catalog — you hunt GGUF files on Hugging Face yourself and decide which quant level you want. Documentation is good but assumes you’re comfortable reading a README and filing your own issues.

Killer use case. A dedicated inference box. Custom build with the right CPU intrinsics for your silicon (AVX-512 on recent consumer Intel, AMX on Xeon Sapphire Rapids, NEON on ARM). Exotic quant experiments — trying IQ3_XXS on a 70B model to squeeze it onto 24 GB VRAM. Benchmarking new models before the wrappers have caught up. You can also stand up llama-server and it will happily serve an OpenAI-compatible API that any client can hit.

Gerganov’s work is the reason the rest of this post is possible. If you pick llama.cpp directly, you’re closest to that source. Respect the lineage and remember: quant file you download, tokenizer fix you benefit from, GPU kernel that got 12% faster last month — most of that was merged into llama.cpp first.

Ollama — the sweet spot for most plebs

What it is. Ollama takes llama.cpp and wraps it in three things that matter: a background daemon (runs as a service, auto-starts on boot), a friendly CLI, and an HTTP API that speaks OpenAI’s format. Plus a model registry so ollama pull llama3.1 just works. The team at Ollama Inc. — Michael Chiang, Jeffrey Morgan, and the contributors around them — spent their effort on the parts that make local LLM infrastructure feel like any other service on your network.

Who should pick it. Roughly 80% of plebs. Anyone who wants to run Open WebUI on top and have a ChatGPT-style interface for their whole household. Anyone who likes their services to live in systemd and behave. Anyone who wants to plug the same local endpoint into VS Code Continue, Home Assistant, a shell script, an n8n workflow, and a CLI chatbot, all at once. If you don’t have strong reasons to pick otherwise, pick Ollama.

Honest tradeoffs. Fewer tuning knobs than raw llama.cpp. You can set context length, temperature, num_gpu layers, and a handful of other parameters via Modelfiles, but you are not getting every flag. Support for brand-new models usually lags llama.cpp itself by two to ten days — Ollama maintainers need to update their runner, test, and cut a release. The model registry is Ollama-curated, though you can always ollama create from any GGUF on disk, so that ceiling is soft.

Killer use case. Daily-driver home LLM server. You install it once on a repurposed mining rig turned Hashcenter or a spare workstation, point Open WebUI at it, and every device on your LAN now has access to a private model. It plays well with multi-GPU setups — recent versions auto-distribute across your cards without much fuss. It plays well with reverse proxies and Tailscale, so you can reach your model from your phone when you’re not home without exposing anything to the clear web.

If you are reading this post at all, Ollama is probably the answer. Start with the 10-minute install guide and see if it sticks. If it does, you’re done. If it doesn’t, you’ll know precisely why, which makes picking the next tool easy.

LM Studio — GUI-first, Mac-excellent

What it is. LM Studio is a desktop application, built on Electron, for browsing local models, chatting with them, and optionally running an OpenAI-compatible server. It’s the closest thing to “ChatGPT but installed on your laptop” in the local-LLM world. The LM Studio team has been quietly shipping polish while the rest of the ecosystem argues about config files.

Who should pick it. Plebs who think in GUIs. Plebs who want to evaluate a lot of models quickly — “does this 13B write code well? how about this 14B? how about this merge?” — without cycling through a dozen CLI commands. And most of all, Mac Silicon users. LM Studio is well-tuned for Apple hardware, with first-class MLX support on recent versions alongside the GGUF path. If you own a MacBook with 64 GB or more of unified memory, LM Studio is one of the most pleasant ways to use it.

Honest tradeoffs. The app itself is proprietary (though free for personal use, with a business tier), which some plebs will rule out on principle and that’s fine. Model discovery happens inside its built-in Hugging Face browser, which is convenient but funnels you toward what’s easy to find rather than what’s best. You can always sideload any local GGUF, but most users won’t. It’s also less scriptable than Ollama — LM Studio does expose a server, but the server isn’t the product, the app is.

Killer use case. You have a MacBook Pro with an M4 Max and 64 GB of RAM. You’ve heard about Llama 3.1 70B at Q4, and you want to see if it actually runs on your machine and whether it’s any good. With LM Studio: open the app, click the search icon, type the model name, pick a quant, click download, click load, start typing. Total elapsed time: 10 minutes, mostly download. No terminal. No configuration files. That’s a genuine superpower for exploration.

Respect the LM Studio team for shipping that polish. Building a cross-platform desktop app that stays current with a fast-moving ecosystem is real work, and they’ve done it quietly and well.

When to use more than one

Nothing stops you from using all three. A common setup in a pleb Hashcenter:

• Ollama runs as a systemd service on your main inference box. It’s the always-on endpoint. Everything in the house that needs a local LLM talks to it.
• llama.cpp compiled from source on the same box, or on a second machine, for specific experiments — a new quant, a model Ollama hasn’t packaged yet, a benchmark.
• LM Studio on your MacBook or desktop for casual chatting, model browsing, and showing non-technical family members what this is about without explaining curl.

GGUF files can be shared across tools if you’re careful. All three can read GGUF from a shared directory; Ollama stores its blobs by content-hash in its own directory (~/.ollama/models), while LM Studio and llama.cpp read plain .gguf files from whatever path you point them at. You can symlink between them or just keep two copies — disk is cheap, your time isn’t.

Adjacent tools (briefly)

vLLM. Server-focused, batched inference, GPU-heavy, production-grade. If you’re serving many concurrent users out of a single Hashcenter — a small team, an internal tool at a company, a community of sovereign Bitcoiners sharing one rig — vLLM starts to win on throughput. It’s not a pleb daily-driver. It’s what you graduate to when Ollama’s single-request loop becomes your bottleneck.

MLX. Apple’s native machine learning framework. If you are all-Apple-all-the-time and your machine is recent Silicon, MLX can beat GGUF-based runners on some workloads. LM Studio already exposes this path for you. If you’re on Linux or Windows, MLX is not relevant.

KoboldCpp. A niche fork of llama.cpp with its own server and UI, historically focused on long-context creative writing and role-playing. Has a dedicated community and some features upstream doesn’t. If you’re in that community you already know why.

text-generation-webui (oobabooga). The Swiss Army knife. Multiple backends, a Gradio web UI, many extensions, popular in the creative / roleplay scene. Heavier setup than Ollama, more customizable. If you want every knob in a browser, this is your thing. For most plebs it’s more than they need.

Decision matrix: which should I pick?

Four profiles. Pick the one that sounds most like you.

“I just want a ChatGPT on my own hardware — daily driver, reliable service, kids and partner use it too”

Pick: Ollama + Open WebUI.

This is the default answer. Install once, runs as a service, survives reboots, speaks OpenAI’s API format so every client in the world works with it. Put Open WebUI in front of it and now your household has a private ChatGPT clone with zero telemetry and zero monthly fee. Start with the 10-minute Ollama install and build from there.

“I’m on a Mac and I want to experiment with lots of models quickly”

Pick: LM Studio.

Especially on Apple Silicon. The download-browse-chat loop is unbeatable for exploration. If you eventually want to pipe your Mac into a broader household stack, LM Studio’s server mode will get you there, but the primary reason to pick it is: you want to try a lot of models with minimal friction, and you like GUIs.

“I want the bleeding edge, maximum tunability, maybe contribute a quant format back”

Pick: llama.cpp from source. Keep Ollama as your stable fallback.

Clone the repo. Read the Makefile. Compile with the right flags for your CPU and GPU. Run llama-server when you want an API, llama-cli when you want a REPL, or use the Python bindings if you’re building something custom. Keep Ollama installed on the same box as your boring-always-works path for when you just want to chat and not think about build flags. The two coexist fine — different ports, different processes. Bonus: understanding llama.cpp directly makes you far better at debugging the wrappers when something goes wrong.

“I’m serving a household or small team with a 4-GPU rig”

Pick: Ollama now. Plan an upgrade path to vLLM when you outgrow it.

Ollama’s multi-GPU support has matured and it will happily split models across four cards automatically. For a household or a small team (say, ten or fewer concurrent requests), it’s plenty. The day you notice queue delays during peak hours — several people hitting it simultaneously, long prompts piling up — that’s your signal to evaluate vLLM as the serving layer while keeping Ollama as your model manager. You’ll likely also want to think about quantization choices at that scale, because memory matters more when you’re serving many.

Three tools, three correct answers

There is no winner here. llama.cpp is the foundation Georgi Gerganov built and that the entire local-LLM ecosystem rests on. Ollama, from Michael Chiang, Jeffrey Morgan, and their team, is the wrapper that makes that foundation feel like any other service on your network. LM Studio, from the team at Element Labs, is the polished desktop app that lowers the barrier to exploration, especially on Apple Silicon. Three projects. Three philosophies. Three correct answers for three different plebs.

Pick based on temperament and infrastructure, not tribal allegiance. A terminal pleb running a Linux Hashcenter is going to land on Ollama or raw llama.cpp. A MacBook-toting pleb exploring the space is going to land on LM Studio. A contributor-minded pleb is going to land on llama.cpp itself. All three are self-sovereign. All three keep your data on your hardware. That’s what matters.

For the full stack context — runner plus UI plus models plus heating-with-inference plus the broader sovereign AI manifesto — head back to the Pleb’s Guide to Self-Hosted AI. Pick your runner. Plug it into your Hashcenter. Stack sats. Stack tokens. Stay sovereign.

External references:
– llama.cpp: github.com/ggerganov/llama.cpp
– Ollama: ollama.com
– LM Studio: lmstudio.ai
– vLLM: github.com/vllm-project/vllm
– MLX: developer.apple.com/machine-learning/mlx
– text-generation-webui: github.com/oobabooga/text-generation-webui