llama.cpp vs Ollama: qual rodar em 2026?

llama.cpp puro se você quer o máximo de tokens/segundo e controle total; Ollama se você quer instalação de um comando e um servidor de API que funciona de cara. O Ollama não é um engine concorrente — é um serviço em Go que embute o llama.cpp como backend de inferência, adiciona gestão de modelos (ollama pull llama3.1) e serve uma API REST na porta 11434. Então a pergunta real não é “qual engine é mais rápido”, e sim “quanto controle você quer sobre os knobs desse engine”. Como o Ollama vem com defaults conservadores (quantização Q4_K_M, contexto modesto, sem flash attention até pouco tempo atrás), o mesmo hardware pode produzir números visivelmente diferentes. Abaixo: o que de fato difere, de onde vem a diferença de velocidade, o mesmo modelo rodando nos dois e uma tabela de decisão.

Qual é a diferença entre llama.cpp e Ollama?

llama.cpp é o engine de inferência: um projeto único em C/C++ do Georgi Gerganov, criador do GGUF, que roda modelos quantizados em CPU, GPU ou uma mistura dos dois. Ele traz o llama-cli para prompts pontuais e o llama-server — um servidor HTTP compatível com OpenAI — além de todas as flags de ajuste que o engine suporta: offload de camadas para a GPU, quantização do KV cache, speculative decoding, samplers customizados.

Ollama é um produto em camada sobre esse engine. Ele faz fork e vendora o llama.cpp, e o embrulha em:

• um registry de modelos (ollama pull, ollama list) com divisão automática dos pesos GGUF,
• um sistema de Modelfile (uma spec estilo Dockerfile para templates de prompt e parâmetros),
• um daemon em background que mantém modelos quentes na VRAM e expõe uma API REST própria,
• detecção automática de hardware com defaults seguros.

A consequência prática: com o Ollama você gerencia modelos; com o llama.cpp você gerencia inferência. Se você já quis mudar o formato de quantização, quantizar o KV cache, subir o contexto além do default ou fixar camadas específicas na GPU, isso é território llama.cpp. O Ollama esconde a maior parte desses knobs — de propósito.

	llama.cpp	Ollama
O que é	Engine de inferência (C/C++)	Serviço que embrulha o llama.cpp
Instalação	Build do fonte ou pacote	Instalador de uma linha, binário único
Rodar um modelo	llama-cli -m model.gguf + flags	ollama run llama3.1
API	Compatível com OpenAI (llama-server)	REST própria + endpoint compatível com OpenAI
Gestão de modelos	Você baixa os GGUF sozinho	Registry: pull/list/rm
Defaults	Você escolhe tudo	Seguros: Q4_K_M, contexto modesto
Atualizações do engine	No dia (upstream)	Atrasam em relação ao upstream
Profundidade de ajuste	Total (KV quant, spec decode, samplers)	Passthrough limitado
Melhor para	Performance, servidores, dispositivos de borda	Começar, notebooks de dev

O llama.cpp é mais rápido que o Ollama?

No mesmo arquivo GGUF, mesma quantização, mesmo contexto e mesma versão do llama.cpp — não, eles ficam dentro do ruído um do outro, porque o Ollama é o llama.cpp fazendo a matemática. Todo benchmark de “Ollama é 30% mais lento” que você vê é, na real, uma comparação de defaults. A diferença vem de três lugares:

1. Escolha de quantização. O registry do Ollama usa Q4_K_M por default. Rode o mesmo modelo em Q5_K_M ou Q6_K pelo llama.cpp e você ganha mais qualidade por token numa velocidade parecida — ou escolha Q4_0/IQ4 para velocidade bruta.
2. Flash attention e quantização do KV cache. --flash-attn mais -ctk q8_0 -ctv q8_0 encolhe o KV cache drasticamente, o que sobe os tokens/segundo em contexto longo e cabe contextos maiores na mesma VRAM. O Ollama expõe só uma parte disso.
3. Atraso de versão. O llama.cpp recebe otimizações de kernel semanalmente; o Ollama faz merge do upstream no próprio ritmo. Um build fresco do llama.cpp pode ser mensuravelmente mais rápido que um binário do Ollama com meses de idade na mesma máquina — até o Ollama alcançar.

Comando de benchmark rápido, agnóstico de engine — ele reporta avaliação de prompt e velocidade de geração:

./build/bin/llama-bench -m Llama-3.1-8B-Instruct-Q4_K_M.gguf -ngl 99 -fa 1

Rode contra o próprio arquivo de modelo do Ollama (~/.ollama/models/blobs/..., renomeado para .gguf) e normalmente você iguala exatamente os números do Ollama — depois os supera adicionando -ctk q8_0 em contexto 16k.

Como rodar o mesmo modelo nos dois?

Os dois consomem GGUF. O mínimo de ponta a ponta para cada:

# --- Caminho Ollama: instalar, puxar, servir ---
curl -fsSL https://ollama.com/install.sh | sh
ollama run llama3.1:8b        # baixa o Q4_K_M, carrega na VRAM, abre um chat

# a API dele, no estilo compatível com OpenAI:
curl -s http://localhost:11434/v1/chat/completions -d '{
  "model": "llama3.1:8b",
  "messages": [{"role": "user", "content": "Say hi in 5 words"}]
}'

# --- Caminho llama.cpp: build, baixar GGUF, servir ---
git clone https://github.com/ggml-org/llama.cpp && cd llama.cpp
cmake -B build -DGGML_CUDA=ON    # ou -DGGML_VULKAN=ON / -DGGML_HIP=ON
cmake --build build --config Release -j

huggingface-cli download bartowski/Meta-Llama-3.1-8B-Instruct-GGUF 
  Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf --local-dir models

./build/bin/llama-server -m models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf 
  -ngl 99 --ctx-size 16384 --flash-attn -ctk q8_0 -ctv q8_0 --port 8080

O llama-server expõe o schema OpenAI Chat Completions, então o mesmo curl contra http://localhost:8080/v1/chat/completions funciona sem mudança nenhuma. Qualquer ferramenta feita para a API OpenAI — scripts, editores, pipelines de RAG — pode apontar para qualquer um dos dois. As flags fazem o trabalho de verdade: -ngl 99 joga todas as camadas na GPU, --flash-attn com o par -ctk/-ctv mantém um contexto de 16k dentro de uma placa de 8 GB que os defaults do Ollama recusariam.

Para escolher o arquivo GGUF em si e o que os rótulos de quant significam, veja como rodar modelos GGUF localmente.

Quando o Ollama faz mais sentido?

A maioria das pessoas deveria começar pelo Ollama, e isso não é prêmio de consolação:

• Você quer funcionando hoje à noite. Um comando, modelo puxado, API de pé. O llama.cpp significa escolher backend (CUDA/Vulkan/HIP/Metal), compilar e baixar pesos na mão.
• Você alterna entre muitos modelos. O registry, o descarregamento automático e os Modelfiles ganham de gerenciar diretórios de GGUF na unha.
• Sua máquina é modesta. Os defaults do Ollama são conservadores por um motivo — quase sempre cabem e rodam.
• Você quer uma superfície de API estável. O daemon do Ollama gerencia o ciclo de vida dos modelos para o serviço de longa duração não precisar fazer isso.

Escolha llama.cpp puro quando estiver fazendo benchmark, servindo em qualquer escala, rodando num celular ou num Raspberry Pi, precisando de contexto longo em pouca VRAM ou querendo uma feature no dia em que ela entra no upstream. Usuários avançados frequentemente rodam os dois: Ollama para os modelos do dia a dia, um build pinado do llama.cpp para a única carga que precisa dos últimos 20%.

Se a sua comparação é entre apps de desktop com GUI, esse é outro eixo — veja Ollama vs LM Studio — e para a escolha de engine por tarefa, os melhores LLMs locais para código cobre o lado do modelo.

Qual você deve usar?

Decida por controle, não por velocidade. Os engines são os mesmos; os defaults não. Instale o Ollama se “rodar e servir uma API” é o objetivo — você perde alguns knobs que não ia girar de qualquer jeito. Compile o llama.cpp se tokens/segundo, tamanho de contexto ou controle de quantização são o objetivo — você ganha todos os knobs, ao custo de gerenciar os modelos sozinho. De qualquer forma, você roda os mesmos arquivos GGUF, e trocar depois custa uma tarde, não uma reescrita.