llama.cpp vs Ollama vs LM Studio: which local model runner fits your setup

In the llama.cpp vs Ollama vs LM Studio choice, llama.cpp is the open-source inference engine. Ollama is an MIT-licensed model manager and server that lists llama.cpp as its backend, and LM Studio is a proprietary desktop app that runs llama.cpp (plus MLX on Apple silicon) behind a GUI. Pick llama.cpp for the widest hardware support, Ollama for a simple background service, and LM Studio for a point-and-click model browser. All three expose an OpenAI-compatible API, so switching later costs little.

What each project is and who maintains it

llama.cpp

llama.cpp (opens in a new tab) is LLM and VLM inference in plain C/C++, built on the ggml tensor library. It lives under the ggml-org GitHub organization, and the Ollama README credits Georgi Gerganov as its founder. The repository ships a library (llama.h) plus tools: an interactive CLI, a completion tool, a quantizer and llama-server.

The current README promotes a single llama command:

llama cli -hf ggml-org/Qwen3.5-0.8B-GGUF
llama serve -hf ggml-org/Qwen3.5-0.8B-GGUF

The docs list an install script (curl -LsSf https://llama.app/install.sh | sh, or irm https://llama.app/install.ps1 | iex on Windows). Package managers include Homebrew, winget, conda-forge, Nix and MacPorts. Docker images, pre-built release binaries and CMake builds from source are also documented.

Ollama

Ollama (opens in a new tab) is developed in the ollama GitHub organization. It installs as a background service, downloads models from its own library with ollama pull, and serves them over HTTP on port 11434. Its README lists llama.cpp under "Supported backends". Ollama also offers optional cloud-hosted models, which you can switch off with OLLAMA_NO_CLOUD=1.

LM Studio

LM Studio is a desktop app for downloading and running models locally, made by Element Labs, Inc. It has a chat interface, a Discover tab that searches Hugging Face, and a local API server. A headless build called llmster runs the same core as a daemon on servers or in CI, with no GUI.

Model formats: GGUF and where models come from

All three tools center on GGUF, the model file format from the llama.cpp project. They differ in how you find and fetch models.

llama.cpp loads a GGUF file from disk with -m path/to/model.gguf, or pulls one from Hugging Face with -hf user/repo[:quant]. When you leave out the quantization, -hf picks Q4_K_M if the repo has it. The repo also has convert_hf_to_gguf.py for converting Hugging Face weights and llama-quantize for shrinking them. Quantization levels run from 1.5-bit to 8-bit.

Ollama uses short names from its own library, such as gemma4 or qwen3:8b. To run something that is not in the library, write a Modelfile with FROM /path/to/file.gguf (or a Safetensors directory) and run ollama create. Ollama does not quantize GGUF files on import, so quantize first with llama.cpp.

LM Studio downloads from Hugging Face inside the app. Its docs explain that names like Q3_K_S or Q_8 are quantized copies of one model and suggest choosing 4-bit or higher if your machine can handle it. On Apple silicon it also runs MLX models.

Which APIs do llama.cpp, Ollama and LM Studio expose?

Each tool runs a local HTTP server, and each has OpenAI-style and Anthropic-style routes. The defaults differ. Sources: the llama-server README (opens in a new tab), Ollama's API docs and the LM Studio developer docs (opens in a new tab).

A few differences matter in practice. llama-server has a router mode: start it without a model and it loads and unloads models on demand through /models/load and /models/unload. Ollama's Responses API is stateless, so previous_response_id is not supported. LM Studio's docs show its Anthropic route working with Claude Code by setting ANTHROPIC_BASE_URL=http://localhost:1234.

To expose a server on your network, llama.cpp uses --host, Ollama uses the OLLAMA_HOST environment variable, and LM Studio uses lms server start --bind 0.0.0.0. LM Studio's docs recommend turning on authentication before binding beyond localhost.

GPU and platform support from the docs

llama.cpp

The llama.cpp README lists the widest backend set: Metal (Apple silicon), CUDA (NVIDIA), HIP (AMD), Vulkan, SYCL (Intel GPU), MUSA (Moore Threads), CANN (Ascend NPU), OpenCL (Adreno), Hexagon (Snapdragon), ZenDNN, BLAS and WebGPU, with OpenVINO in progress. On the CPU side it supports AVX, AVX2, AVX512 and AMX on x86, and several RISC-V extensions. It can split a model between CPU and GPU when the model is larger than your VRAM, controlled by -ngl (default auto).

Ollama

Ollama's docs list:

• macOS Sonoma (14) or newer: Apple M-series gets CPU and GPU (Metal), Intel Macs run on the CPU only.
• Windows 10 22H2 or newer, with NVIDIA and AMD Radeon GPU support.
• Linux on amd64 and arm64, with a separate ROCm package for AMD.
• NVIDIA GPUs from compute capability 5.0 with driver 550 or newer.
• Vulkan, enabled by default, as an extra path for AMD and other GPUs.

LM Studio

The LM Studio system requirements (opens in a new tab) say:

• macOS 14.0 or newer on Apple silicon (M1 to M4). Intel Macs are not supported. 16 GB of RAM or more is recommended.
• Windows on x64 (AVX2 required) and ARM (Snapdragon X Elite). The docs recommend at least 16 GB of RAM and 4 GB of dedicated VRAM.
• Linux on x64 and ARM64 as an AppImage, Ubuntu 20.04 or newer.

The system requirements page does not list which GPU vendors LM Studio supports on Windows and Linux. GPU offload is set per model or with lms load --gpu=max|auto|0.0-1.0.

Licences

If you need to read, patch or redistribute the runner itself, llama.cpp and Ollama allow that under MIT. LM Studio's app code is not open, so check its terms before you build a product around it.

Decision table: llama.cpp vs Ollama vs LM Studio by use case

Copy this table and mark the rows that describe your setup. The tool that appears most often in your marked rows is your starting point.

None of the project docs used here publish speed comparisons against the other two, so this table leaves performance out. Measure on your own hardware with the model you plan to use.