llama.cpp vs Ollama: one engine, two amounts of engine to touch

■ space · the engine bay

■ the answer first

Ollama's repo root carries a file called LLAMA_CPP_VERSION pinning its engine — it runs llama.cpp, so raw speed is a near-tie for the same model file.

Upstream shipped b11443 on review morning; Ollama pins b11351 — the wrapper always trails the engine. Newer flags arrive in llama.cpp first.

Verdict from the record: Ollama for daily driving, llama.cpp when you need a flag the wrapper hides — plus vLLM as the escape hatch for GPU serving.

THE BAY

Same block under both doors. Set how much engine you want to touch — the shelves answer.

THE APPLIANCE · ollama

resident API :11434 + the MLX shelf for Apple Silicon

hardware auto-detect · context and offload decided for you

one-command pulls from the registry

llama.cpp — engine build b11351 (pinned)

THE ENGINE ROOM · llama.cpp

every flag yours — context, offload, samplers, backends

llama-server — OpenAI-compatible HTTP, point any client at it

the build you pin — b11438…b11443 landed on review morning alone

llama.cpp — engine build b11443 (latest)

how much engine do you want to touch?

the engine roomthe appliance

Full appliance. Pulls, detection and the resident API stay; the engine hums underneath at Ollama's pin. The GGUF file moves with you the day you outgrow it.

WHAT LLAMA.CPP ACTUALLY IS

130,473 stars, MIT licence, four releases on the morning of this review. llama.cpp started the run-local wave in March 2023. It introduced GGUF, the format the ecosystem trades in.

24,125 forks, 2,515 open issues, a top contributor at 2,011 commits. The release feed reads like a log: four builds by early afternoon (b11438 through b11443), each pinnable.

verify: curl -s http://127.0.0.1:11434/api/version → a running Ollama answers · llama-server --version → the build tag, e.g. b11443

IS OLLAMA ANYTHING MORE THAN A WRAPPER?

Yes — and the boundary is printed in the repository. Three version-pin files: LLAMA_CPP_VERSION (b11351 at review time), MLX_VERSION, MLX_C_VERSION. llm/llama_server.go starts the llama.cpp-derived server as a subprocess.

The dependency is a build input, not an open secret. What Ollama adds is service: registry pulls, auto-detection, a resident API on port 11434, MLX for Apple Silicon.

Ollama is model management and process hygiene wrapped around an engine it did not write.

92 builds separate Ollama's pin from upstream's morning release. Engine fixes land upstream first, then ride Ollama's train weeks later.

The September prompt-lookup-drafting speedup hit 89 points on Hacker News — weeks before Ollama shipped it. If a changelog line fixes your problem, the wrapper is the last to know.

SO WHICH ONE IS FASTER?

For the same model file, neither — the engine is shared. Claimed gaps usually compare different quantizations, context sizes, or engine builds.

Real gaps come from defaults and lag: Ollama picks context and offloads layers for you — the knobs behind VRAM surprises; llama.cpp makes you set them, and punishes forgetting.

The benchmark question hides a control question.

You are not choosing between two engines. You are choosing how much engine you want to touch.

WHAT THE RECORD SAYS AGAINST LLAMA.CPP

2,515 open issues and a siege pace. Four releases on one morning is throughput — it is also churn. Flags move, backends reorganize, and your pinned build script needs the same maintenance.
The community says it out loud. From the Hacker News thread on the September speedup (89 points), user rfgplk: "Frankly, llama.cpp is so badly written that these kind of speedups are trivial, and a hard fork (or a total rewrite) has been needed for the longest time." The same thread carries governance worry after Nvidia's Hugging Face deal put the core team's employer in play.
You do the chores. No registry, no auto-detect: you fetch GGUF files yourself, pass layer-offload flags yourself, and babysit the process.

FIND YOUR ROW

You want	Run	Why, from the record
One command and a chat window	Ollama	Model pulls, auto-detect, resident API — the appliance
Every flag and the newest build	llama.cpp	Pinned builds, llama-server, backends you choose
A desktop GUI	LM Studio	Same engine lineage with buttons
One GPU, many users	vLLM	Throughput serving — GGUF caveats apply

A practical seam: start on Ollama; when it fights you — missing flag, GPU detection gone wrong, a fix in a newer build — drop to llama.cpp for that job.

The model file moves with you; GGUF is the lingua franca. The appliance spares you the engine until the day the engine is the problem.

That day is why the second tool exists.

■ honest stamp I've read the record, not run it. Tested on: the public record — llama.cpp b11443 (four releases on review day) · Ollama v0.35.1 / LLAMA_CPP_VERSION b11351. Recorded 2026-10-06. Every number here comes from the two repositories, their release feeds and linked public threads — stars, forks, pin files, build numbers — not from my terminal and not from a bench.

end of the engine bay · nothing fetched · everything local