llama.cpp vs ollama performance is a category error

No — Ollama is not slower than llama.cpp in any way worth a benchmark. It is the same engine on a slower release train. You're choosing a warranty, not a speed.

Ninety-two builds separated Ollama's engine pin from upstream on October 6. That was the whole story then. This week both trains sped up: upstream llama.cpp now tags versioned releases (v0.7.0, around Oct 15) and pushes build after build on the same morning, while Ollama's v0.40.5 notes record the pinned engine moving too. What didn't change is the physics: the wrapper doesn't compute your tokens. Thread count, quantization and context length do.

Benchmarking one against the other for speed is drag-racing a car against the same car in a new paint job, then publishing a review of the paint.

The gap, re-measured

Our October 6 ledger caught the pin mid-stride. Here is the same measurement today.

date	upstream llama.cpp	ollama's pin	gap
2026-10-06	b11443	b11351	92 builds
2026-10-14	—	"updated llama.cpp" (v0.40.5 notes, ships Nemotron 3.5 support)	pin moves on their train
2026-10-21	b11778 (03:37 UTC)	build number unverified	this post's open question

Ollama isn't slower llama.cpp. It's last month's llama.cpp with a warranty. Call it the warranty gap — the builds you trade away for a setup that survives.

Two trains, one morning

The cadence is the real spec. Drawn from each project's releases feed, nothing estimated.

Three llama.cpp builds landed between 03:04 and 03:37 UTC on October 21. Ollama's three releases took five days. Neither number is a criticism — they are different products with different jobs.

Where the speed question actually lives

If the engine is shared, the remaining differences are the ones worth shopping for.

axis	llama.cpp	ollama	the pick
the engine	this morning's build	their pinned build, bumped per release	tie (same code)
defaults under update	they move: v0.7.0 moved the server port and our setup refused connections until we followed	no surprise moves on record this week	ollama, if updates scare you
API surface	raw HTTP server you wire yourself	OpenAI-compatible Responses, plus new renderer/parser/template_source fields in ollama show and the API (v0.40.7)	ollama, for app glue
cloud routing	nothing leaves your box	can route to ollama.com models; since v0.40.7 remote requests cancel when your client disconnects	llama.cpp, if phone-home is a dealbreaker
receipts	tested 2026-10-20 on an ephemeral CPU microVM: 1 ms refusal on the stale port, ~41 ms from cold start to listening, banner b11669 printing "0.7.0-dev"	record-read only — the bench is still owed	—

The decision, three rules

1. You want this week's kernels, quants and fixes. Run llama.cpp and own the churn. The port move that broke our server on update is what churn means. The recovery is written up in "llama.cpp connection refused after update — the port moved".
2. You want tomorrow to look like today. Run Ollama. The pin lags on purpose, and a 3-releases-in-5-days week is how the warranty gets delivered.
3. You're hunting tokens per second. Shop your config instead of the wrapper. Start with threads and quantization. The engine is the same engine.

Receipts and honesty stamp

• Tested 2026-10-20, ephemeral CPU microVM: llama-server banner b11669 printing 0.7.0-dev; connection refused in 1 ms on the stale port; ~41 ms from launch to listening.
• Read, not run: Ollama v0.40.5 (Oct 14), v0.40.6 (Oct 16) and v0.40.7 (Oct 18) release notes; the llama.cpp releases feed (b11776/77/78, Oct 21, 03:04–03:37 UTC). Ollama's current engine build number is unverified — I've read the record, not run it.
• Framework from our October 6 take, "llama.cpp vs Ollama — which one should you run?" — that one measured the 92-build pin gap this table starts from.

The number I want: Ollama v0.40.7's exact llama.cpp build. If you run it, the first lines of ollama serve's log name it. Post the build number in the comments and the next ledger fills the gap column.

Second ask: which train bit you this week? The port move caught us mid-update. If a release broke your setup, I want that story too — the gap column stays open until then.