The llama.cpp vs Ollama question has a plainer answer than most comparisons, because Ollama's own repository says llama.cpp is its backend: the README lists it under supported backends, a file called LLAMA_CPP_VERSION pins the llama.cpp build each release ships, and llm/llama_server.go starts llama.cpp's llama-server as a subprocess. So the choice is between running that engine directly, with all its flags, and running it behind Ollama's model library, scheduler and APIs. I checked both projects' documentation and repositories on 12 November 2026, and I quote no speed numbers.
How Ollama and llama.cpp relate today
Ollama's README lists llama.cpp under Supported backends. The repository shows how. The update notes say LLAMA_CPP_VERSION pins the llama.cpp source, that Ollama applies its own compatibility patches under llama/compat/, and that llama-server's launch arguments, status payloads and logs are interfaces to review on every update. The top of llm/llama_server.go says it wraps the llama-server binary as a subprocess. It also says Ollama renders some prompts itself and calls /completion, while other GGUF models use llama-server's chat template handling through /v1/chat/completions, and that llama-server detects the GPU layer count, thread count and flash attention.
The pins show how closely Ollama follows. Ollama v0.40.6, released 16 October 2026, pins llama.cpp build b11669 from 15 October. Ollama v0.40.16, released 9 November, pins b12177 from 6 November and lists Updated llama.cpp in its notes. In both cases the pinned build was one to three days older than the release that shipped it, and llama.cpp itself was at b12307 on 12 November, 130 build numbers past the one in v0.40.16. So an Ollama release runs a recent llama.cpp plus Ollama's patches, and running llama.cpp directly lets you pick any build. Ollama's development guide also describes an optional MLX engine for Safetensors models, on by default on Apple silicon and chosen with OLLAMA_MLX_BACKENDS elsewhere, so llama.cpp is not the only code path in the repository.
What Ollama adds is the model library and ollama pull, the Modelfile, loading and unloading with a request queue, its own REST routes with OpenAI and Anthropic subsets, and integrations such as ollama launch. What llama.cpp ships itself is the CLI tools, a web UI served by the server, a router mode, official Docker images for several GPU stacks and every flag.
llama.cpp vs Ollama, row by row
llama.cpp (llama-server) | Ollama | |
|---|---|---|
| Install | An install script, Docker images such as ghcr.io/ggml-org/llama.cpp:server-cuda and server-cuda13, prebuilt binaries, or a source build | An install script, or the ollama/ollama Docker image |
| Model files | GGUF files: -m for a local file, or -hf user/model:quant to download from Hugging Face, Q4_K_M by default | A library of tags such as ollama pull qwen3-coder, plus imports of GGUF or Safetensors files through a Modelfile |
| Context | -c, default 0 which loads the model's own value, and --fit, on by default, adjusts unset arguments to fit device memory. KV cache types with -ctk and -ctv | OLLAMA_CONTEXT_LENGTH or num_ctx. Defaults by VRAM: 4k under 24 GiB, 32k from 24 to 48 GiB, 256k from 48 GiB. KV cache type with OLLAMA_KV_CACHE_TYPE |
| GPU layers | -ngl takes a number, auto (the default) or all. --device and --main-gpu pick cards | Automatic. The FAQ and GPU pages list no layer-count setting, ollama ps shows the CPU and GPU share and CUDA_VISIBLE_DEVICES limits the cards |
| Parallel requests | -np slots, auto by default, with continuous batching on by default and a unified KV buffer when slots are auto | OLLAMA_NUM_PARALLEL, default 1, and the context is multiplied by it. OLLAMA_MAX_QUEUE defaults to 512 |
| Several models | One model per server, or router mode, which loads on demand and keeps up to 4 by default | Loads and unloads on demand, up to 3 per GPU by default, and keep_alive sets how long one stays |
| Multi-GPU | --split-mode layer by default, tensor marked experimental and --tensor-split for uneven shares | Loads on one GPU when the model fits, otherwise spreads it across all |
| APIs | OpenAI-compatible chat, responses and embeddings routes, an Anthropic Messages route, /completion and a web UI | Its own /api routes, an OpenAI subset including a stateless /v1/responses, and an Anthropic subset |
| Updates | Numbered builds all day: more than 100 between 5 and 12 November. Semantic tags v0.1.0 (17 August) to v0.9.0 (4 November) | Re-run the install script, or set OLLAMA_VERSION. Releases v0.40.6 to v0.40.16 between 16 October and 9 November |
The sources, checked 12 November 2026, are the llama.cpp server README, Docker page, multi-GPU page and release page, and Ollama's context length, FAQ, import, OpenAI compatibility and Anthropic compatibility pages. The llama.cpp release page says GitHub holds only nightly builds, and that the semantic version tags reach users through the install script, package managers or a source checkout.
llama.cpp on a GPU server: Docker images and flags
The llama.cpp Docker documentation lists server-cuda built with CUDA 12 and server-cuda13 built with CUDA 13, next to ROCm, Vulkan, SYCL and MUSA variants, and says the GPU images are not tested by CI beyond being built. Take the CUDA image your driver supports, as the llama.cpp server guide shows, and use sudo docker. The GPU flags are -ngl and --fit, and with several cards --device restricts them while --tensor-split sets each card's share. Ollama's GPU page asks for an NVIDIA card with compute capability 5.0 or newer and driver 550 or newer, and its Docker image runs with --gpus=all.
Both projects read the same GGUF files, so the GGUF guide and the quantization guide apply to either. Ollama's import page says it does not quantize GGUF files during import, and the llama.cpp quantize README describes two phases: convert the model to GGUF, then quantize that file.
An Ollama alternative that is the same engine
If you want an Ollama alternative without the wrapper, llama-server is the same engine started directly. If the reason is concurrency for an API with many callers, the engines to compare are vLLM and SGLang. The vLLM vs Ollama page covers the first, vLLM vs llama.cpp covers the format and memory trade, and vLLM vs SGLang covers the two server-grade engines. The vLLM guide, the SGLang guide and the vLLM tuning guide cover running them.
Decision table
| If you need | Pick |
|---|---|
| One command, a model library and a chat interface | Ollama |
| Exact control of context, GPU layers, KV cache types and the multi-GPU split | llama.cpp |
| A specific llama.cpp build, or a model newer than the one Ollama pins | llama.cpp |
| Several models behind one endpoint, loaded on demand | Ollama by default, llama-server in router mode |
An existing Modelfile, or tools started with ollama launch | Ollama |
| Many users calling one API at once | Compare vLLM and SGLang first |
When each one wins
In the Ollama vs llama.cpp choice, the question is who picks the settings. Ollama wins when the job is a person chatting, or a tool calling a model, with the least setup. The install is one script, the model is one ollama pull, loading and unloading are automatic and the defaults are chosen for you, including a context length by VRAM tier. llama.cpp wins when you want to choose. It exposes the context size, the layer count, the KV cache types, the split mode and the speculative decoding flags, and it lets you run any build, including one newer than the build Ollama pins. The cost is that you set those flags yourself.
On DeployGPU
The Open WebUI and Ollama template gives you Ollama behind Open WebUI on a private link. llama.cpp is do-it-yourself on a plain GPU VM and reached through an SSH tunnel, and the Ollama guide and the llama.cpp server guide cover each. Both projects bind to 127.0.0.1 by default according to their documentation, the Ollama FAQ and the llama.cpp --host default, but their Docker examples publish the port on every interface, so use -p 127.0.0.1:PORT:PORT as the guides do.
Opens the deploy page on the cheapest 1x 48 GB GPUs offer at 2026-11-13 05:38 UTC: QuantaCloud, $0.48/hr. You can pick another GPU there before paying.
Frequently asked questions
Is Ollama built on llama.cpp?
Ollama's README lists llama.cpp as its supported backend, and its repository pins a llama.cpp build and starts llama-server as a subprocess. Ollama v0.40.16 pins build b12177.
Is llama.cpp faster than Ollama?
Ollama runs llama.cpp's server underneath, with its own patches, so the engine code is largely the same. The documented differences are in defaults such as context length and parallel requests, and in which llama.cpp build each one ships, so compare them with the same settings on your own model.
Can Ollama run a GGUF file I downloaded?
Yes. Put FROM and the file path in a Modelfile and run ollama create. Ollama does not quantize GGUF files during import, so quantize first.
Does llama.cpp have a model library like Ollama?
It loads GGUF files you point it at or download from Hugging Face with the hf flag, and its router mode can load several models from a directory or its cache. Its documentation describes no tag library like Ollama's.
Which one should I run on a rented GPU?
Ollama through the Open WebUI template for a browser chat, llama.cpp directly when you need its flags, and vLLM or SGLang when many users call an API.
How do I update each one?
Re-run Ollama's install script, or set OLLAMA_VERSION to pin a version. For llama.cpp, pull a newer image or binary and note the build number you ran, because it changes several times a day.