Ollama vs llama.cpp: qual escolher em 2026 ?

#A relação real entre Ollama e llama.cpp

llama.cpp é o projeto C/C++ de Georgi Gerganov que executa modelos de linguagem no formato GGUF em CPU e GPU, sem dependência de Python nem de PyTorch. É o componente de inferência de referência de todo o ecossistema local: LM Studio, KoboldCpp, Jan e Ollama se apoiam nele, diretamente ou por meio de um fork.

Ollama não é, portanto, um concorrente do llama.cpp no sentido estrito: é uma camada sobre ele. Inclui seu próprio motor derivado do llama.cpp e acrescenta um gerenciador de modelos, um daemon em segundo plano e uma API. Quando você digita `ollama run qwen3`, é o código proveniente do llama.cpp que gera os tokens. A pergunta não é «qual é o mais rápido» — com quantização e hardware iguais, o desempenho é muito próximo — mas «qual nível de abstração é adequado para você».

#O que o Ollama realmente acrescenta como camada sobre o llama.cpp

Compilar e executar o llama.cpp manualmente significa gerenciar por conta própria o download dos GGUF, os caminhos dos arquivos e uma longa linha de opções. O Ollama cuida de tudo isso. Veja, na prática, o que ele oferece além do motor básico:

Registro e pull

`ollama pull qwen3:8b` baixa o modelo do ollama.com, escolhe uma quantização padrão (geralmente Q4_K_M) e o armazena em um repositório de blobs. Não há busca pelo arquivo correto no Hugging Face.

Daemon persistente

Um serviço roda em segundo plano e escuta em http://localhost:11434. O modelo permanece carregado na memória entre duas requisições (keep-alive) e é descarregado automaticamente após um período de inatividade.

Offload automático para a GPU

O Ollama estima a VRAM disponível e distribui as camadas entre GPU e CPU sem que você precise ajustar `-ngl`. Prático, mas às vezes conservador demais.

Modelfile

Um arquivo declarativo (como um Dockerfile) que fixa um modelo base, um prompt de sistema, uma temperatura e um template de chat sob um nome reutilizável.

API compatível com OpenAI

Um endpoint /v1/chat/completions pronto para uso, além da API nativa /api/generate. Qualquer cliente OpenAI pode se conectar a ele apenas alterando a URL base.

Por outro lado, o llama.cpp permite que você faça tudo — mas você precisa fazer tudo. Você baixa o GGUF por conta própria, escreve a linha de comando e gerencia o ciclo de vida do processo. É o preço do controle total, que o restante deste comparativo entre llama.cpp e Ollama vai detalhar.

#Pré-requisitos

O único fator que realmente determina o que você poderá rodar é a memória (RAM ou VRAM em uma GPU dedicada). Esses valores de referência em Q4_K_M valem para as duas ferramentas, já que o motor é o mesmo:

3B ≈ 2 GB

Cabe em quase qualquer configuração, incluindo uma RTX 3060 de 12 GB com uma enorme margem de memória.

7B ≈ 5 GB

Confortável a partir de 8 GB de VRAM (RTX 3060, 4060)

14B ≈ 9 GB

Cabe inteiramente em uma RTX 3060 de 12 GB ou em uma 4070 de 12 GB.

32B ≈ 19 GB

Requer uma RTX 4090 de 24 GB, ou um offload parcial CPU/GPU em 16 GB.

70B ≈ 40 GB

Requer múltiplos GPUs, um Mac com memória unificada (M4 Pro 48 GB) ou offload agressivo.

#Instalar e iniciar os dois

1. 01
   Instalar Ollama

   O script oficial instala o daemon e a CLI em um único comando no Linux; no macOS e no Windows, um instalador gráfico é fornecido no ollama.com. Após a instalação, o serviço escuta em http://localhost:11434.
2. 02
   Iniciar um modelo com Ollama

   `ollama run qwen3:8b` baixa o modelo na primeira chamada e depois abre uma sessão de chat. Nada mais precisa ser configurado: o offload para a GPU, o contexto e o template são gerenciados automaticamente.
3. 03
   Compilar llama.cpp

   Fazemos o clone do repositório ggml-org/llama.cpp e compilamos com CMake. A opção de backend GPU depende do seu hardware: CUDA para NVIDIA, Metal (ativado por padrão) no Mac, ROCm ou Vulkan para AMD.
4. 04
   Iniciar um GGUF com llama.cpp

   `llama-cli` carrega um arquivo .gguf especificado explicitamente, com todas as configurações na linha de comando: número de camadas na GPU (`-ngl`), tamanho do contexto (`-c`), threads da CPU (`-t`). Nada é adivinhado por você.

# Installer (Linux) puis lancer un modèle
curl -fsSL https://ollama.com/install.sh | sh
ollama run qwen3:8b

# Vérifier le daemon et lister les modèles
curl http://localhost:11434/api/tags
ollama list

# Cloner et compiler avec le backend CUDA (NVIDIA)
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j

# Lancer un GGUF avec 35 couches sur le GPU et 8192 de contexte
./build/bin/llama-cli -m ./qwen3-8b-Q4_K_M.gguf -ngl 35 -c 8192 -p "Bonjour"

#Benchmark simples dos dois no mesmo GGUF

O melhor jeito de encerrar os debates: medir os dois no mesmo arquivo, na mesma máquina. O llama.cpp fornece `llama-bench`, uma ferramenta dedicada que isola a taxa de geração (tokens por segundo) e o processamento do prompt (prompt processing).

# Débit brut du moteur sur le GGUF, tout GPU
./build/bin/llama-bench -m ./qwen3-8b-Q4_K_M.gguf -ngl 99
# Sortie : colonnes pp (prompt) et tg (génération) en tok/s

# Importer le GGUF dans Ollama sans le re-télécharger
printf 'FROM ./qwen3-8b-Q4_K_M.gguf\n' > Modelfile
ollama create qwen3-local -f Modelfile

# Chronométrer une génération (--verbose affiche les tok/s)
ollama run qwen3-local --verbose "Explique la photosynthèse en 200 mots"

O resultado típico em 2026, com GGUF idêntico e camadas inteiramente na GPU: a taxa de geração é quase idêntica, com uma diferença de poucos por cento. Isso é lógico: o núcleo de cálculo é o mesmo. As diferenças observadas vêm quase sempre de configurações implícitas diferentes, não do motor:

Camadas transferidas (offload)

Ollama pode deixar algumas camadas no CPU por precaução com VRAM, enquanto `llama-bench -ngl 99` coloca tudo no GPU. Resultado: Ollama parece mais lento, embora seja apenas uma escolha de distribuição.

Tamanho do contexto

Um contexto maior reserva mais VRAM para o cache KV e reduz o espaço para os pesos. Compare com contexto igual.

Flash Attention e cache KV

Ativados ou não, quantizados ou não, esses ajustes alteram a taxa de geração. No llama.cpp, você os define; no Ollama, eles dependem da versão e de variáveis de ambiente.

#Configurações avançadas acessíveis apenas no llama.cpp

É aqui que a comparação entre llama.cpp e Ollama pende claramente para um lado. Ao expor diretamente as flags do motor, o llama.cpp dá acesso a ajustes que o Ollama oculta ou expõe apenas parcialmente. Para uso avançado, esses ajustes mudam tudo:

Offload cirúrgico (-ngl)

Você decide, com precisão de uma camada, quantas camadas vão para a GPU. Com VRAM apenas suficiente, ganhar 2 ou 3 camadas em relação ao Ollama pode fazer um modelo passar de “lento” a “fluido”.

Cache KV quantizado (-ctk/-ctv)

Quantizar o cache KV em q8_0 reduz quase à metade a memória do contexto, permitindo janelas muito mais longas com a mesma quantidade de VRAM — um recurso pouco acessível no Ollama.

Flash attention (--flash-attn)

Ativação explícita da atenção otimizada, com impacto direto na velocidade e na memória de contextos longos.

Decodificação especulativa (--model-draft)

Conectar um pequeno modelo “de rascunho” para acelerar um modelo grande. O ganho pode ser considerável ao gerar código, e esse recurso é nativo no llama.cpp.

Gramáticas GBNF (--grammar)

Restringir a saída a uma gramática formal (JSON estrito, enumeração, formato próprio). Essencial para saída estruturada confiável e muito mais granular que o modo JSON do Ollama.

RoPE e escalonamento do contexto

Ajustar `--rope-freq-base` e `--rope-freq-scale` para expandir o contexto além do treinamento original, controlando a degradação.

Ollama expõe parte desses ajustes por meio dos parâmetros do Modelfile ou de variáveis de ambiente, mas raramente com a mesma granularidade e muitas vezes com atraso em relação às novidades do llama.cpp. Se a sua necessidade for “o contexto mais longo possível com a minha VRAM” ou “JSON com validade garantida”, o motor usado diretamente permite ajustes que a camada adicional deixou inacessíveis.

#Servidor API: Ollama vs llama-server

Os dois sabem servir um modelo via HTTP. Ollama expõe seu daemon em http://localhost:11434 com uma API nativa (/api/generate, /api/chat) e um endpoint compatível com OpenAI (/v1/chat/completions). Por sua vez, llama.cpp fornece `llama-server`, um binário que inicia uma API compatível com OpenAI e uma pequena interface web incluída.

# API OpenAI-compatible sur le port 8080, tout GPU
./build/bin/llama-server -m ./qwen3-8b-Q4_K_M.gguf -ngl 99 -c 8192 --port 8080
# Interface web : http://localhost:8080  ·  API : /v1/chat/completions

Vários modelos sob demanda

Ollama carrega/descarrega automaticamente vários modelos de acordo com as requisições. `llama-server` serve um modelo por processo — mais fácil de entender, menos mágico.

Controle de flags

Com o llama-server, cada ajuste do motor (contexto, cache KV, Flash Attention) é um flag de inicialização explícito. Ideal para fixar uma configuração de produção reprodutível.

Ecossistema

A API do Ollama na porta 11434 tornou-se um padrão de fato: Open WebUI, editores de código e integrações se conectam diretamente a ela. Isso é uma vantagem real em termos de praticidade.

#Veredito por perfil: iniciante, desenvolvedor, homelab

Como o motor é compartilhado, a avaliação não se refere à performance, mas ao seu perfil e à sua tolerância à linha de comando.

Iniciante → Ollama

Um comando para instalar, um para iniciar, um modelo que 'funciona' sem precisar configurar nada. Não há motivo para compilar C++ para conversar com um LLM. Continue com o Ollama, talvez com o Open WebUI como interface.

Desenvolvedor → os dois

Ollama para prototipar rapidamente e ter acesso imediato à API OpenAI; llama.cpp quando você precisa de gramáticas GBNF, decodificação especulativa ou controle exato do cache KV. A transição de um para o outro é tranquila, e o GGUF é compartilhado.

Homelab / auto-hospedagem → llama.cpp (llama-server)

Para aproveitar ao máximo uma VRAM limitada, fixar uma configuração reprodutível e ampliar o contexto, usar o motor diretamente leva vantagem. A contrapartida — compilar, definir os flags, gerenciar os processos — é exatamente o que você busca dominar.

Em uma frase: Ollama é o melhor ponto de partida e basta para a imensa maioria dos usos; você passa a usar o llama.cpp diretamente quando um ajuste preciso — contexto, cache KV, gramática, offload com precisão de uma camada — se torna o fator limitante. Não se trata de uma substituição, mas de um aumento do controle.

#Para se aprofundar

Esses guias complementam esse comparativo, desde a instalação até os ajustes finos:

Iniciar com Ollama

« Instalar Ollama em 5 minutos (Windows, macOS, Linux) » aborda a instalação do daemon e do primeiro modelo, com foco na simplicidade.

Servir sem Ollama

“llama-server: uma API OpenAI local com llama.cpp” detalha o controle preciso do offloading das camadas e a interface web incluída, no que diz respeito ao controle.

Escolher a quantização

« Quantização GGUF em 2026: Q4_K_M vs Q5_K_M vs Q6_K » ajuda a escolher o arquivo .gguf correto, comum às duas ferramentas.