Ollama ou llama.cpp em um VPS: qual escolher

Ollama vs llama.cpp: em que camada pretende executar?

Ollama e llama.cpp não são concorrentes da forma sugerida pela pergunta. llama.cpp é o mecanismo de inferência: carrega um ficheiro de modelo e transforma um prompt em tokens. Ollama é um gestor de modelos, um daemon em segundo plano e uma API HTTP executados sobre esse mecanismo. O README do Ollama ainda lista llama.cpp como o seu backend de inferência (verificado em 2 August 2026). Portanto, a verdadeira questão é qual camada pretende operar no seu VPS, não qual é mais rápida.

Execute Ollama quando quiser um serviço que obtenha modelos pelo nome e continue a funcionar sem intervenção. Execute llama.cpp diretamente quando o servidor for pequeno e precisar de escolher o ficheiro de modelo exato, o tamanho exato do contexto e o número exato de threads, porque num VPS pequeno cada uma dessas definições consome memória que não está disponível.

O que cada projeto é, na prática

llama.cpp é uma implementação em C e C++ para inferência de transformers, baseada na biblioteca ggml. Lê ficheiros GGUF. GGUF (GGML universal file format) é um contentor num único ficheiro que contém os pesos, o tokenizador e os metadados de que o motor precisa para executar o modelo. O projeto disponibiliza binários separados para tarefas diferentes. llama-server é um servidor HTTP, llama-cli é um prompt interativo e llama-bench mede o débito. As releases são identificadas pelo número da compilação, e não por versões semânticas. A tag atual é b10224, publicada em 2 August 2026, e uma nova tag é publicada na maioria dos dias úteis.

Ollama é um programa em Go. Um daemon em segundo plano, iniciado com ollama serve, carrega modelos e responde a pedidos HTTP, enquanto um cliente de linha de comandos comunica com esse daemon. Por trás de ambos existe um registry em ollama.com que contém modelos pré-empacotados. Ollama usa versões semânticas, e v0.32.5 foi publicada em 27 July 2026. ollama pull obtém um ficheiro GGUF juntamente com um template de prompt e um conjunto de parâmetros predefinidos, e depois armazena-o em /usr/share/ollama/.ollama/models no Linux.

Essa forma de empacotamento é toda a diferença. Ollama escolhe por si a quantização, o template e o comprimento do contexto, e dá-lhe um único nome para memorizar. llama.cpp não escolhe nada e dá-lhe flags.

Eixo 1: controlo do modelo e da quantização

A quantização reduz cada peso de 16 ou 32 bits para 4, 5 ou 8 bits. É isso que permite que um modelo com 8 mil milhões de parâmetros caiba na RAM de um VPS normal. A nomenclatura GGUF torna-se clara quando se conhece o padrão: Q4_K_M significa quantização K de 4 bits, com tamanho médio. Um número maior preserva mais precisão e consome mais memória.

[
  {
    "label": "Q2_K",
    "file_size_gib": 2.96
  },
  {
    "label": "Q3_K_M",
    "file_size_gib": 3.74
  },
  {
    "label": "Q4_K_M",
    "file_size_gib": 4.58
  },
  {
    "label": "Q5_K_M",
    "file_size_gib": 5.34
  },
  {
    "label": "Q6_K",
    "file_size_gib": 6.14
  },
  {
    "label": "Q8_0",
    "file_size_gib": 7.95
  }
]

Estes são os tamanhos publicados dos ficheiros no repositório bartowski/Meta-Llama-3.1-8B-Instruct-GGUF do Hugging Face, consultados em 2 de agosto de 2026 e convertidos de bytes para GiB. São 6 builds de um modelo, e o menor ocupa 2.96 GiB, contra 7.95 GiB do maior. O padrão mais usado, Q4_K_M, ocupa 4.58 GiB. Num VPS com 4 GiB, essa escolha determina se o modelo consegue ou não ser carregado.

Com llama.cpp, indica o nome do ficheiro, por isso escolhe diretamente essa linha.

llama-server -m ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf \
  -c 4096 -t 4 --host 127.0.0.1 --port 8080

-c é o tamanho do contexto em tokens, -t é o número de threads e -ngl define quantas camadas são transferidas para uma GPU (0 num servidor apenas com CPU). Nada é escolhido automaticamente por si.

Com Ollama, a quantização vem associada à tag que descarrega, e ollama ls mostra o que tem efetivamente no disco. Quando o registry não disponibiliza o build pretendido, importe diretamente um GGUF. Escreva um Modelfile:

FROM ./Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf
PARAMETER num_ctx 4096

Depois, crie-o e confirme o resultado:

ollama create llama31-q4 -f ./Modelfile
ollama ls

O comprimento do contexto é a definição que costuma causar problemas. O Ollama escolhe o valor predefinido com base na VRAM disponível, e um servidor sem GPU fica no grupo mais pequeno: 4096 tokens. Se lhe enviar um documento com 20.000 tokens, os tokens excedentes são descartados antes de o modelo os processar. A resposta fica errada, embora pareça confiante, porque o modelo só leu parte do ficheiro. Aumente o valor com OLLAMA_CONTEXT_LENGTH no daemon ou com PARAMETER num_ctx num Modelfile. O llama.cpp também não tem um valor predefinido suficientemente fiável. Defina -c explicitamente e confirme o valor configurado.

A aritmética da memória que quase ninguém mostra

O ficheiro do modelo não representa o custo total. A cache KV (cache de chaves/valores) mantém uma entrada por camada para cada token do contexto e cresce à medida que a conversa aumenta.

Calculemos o valor para o Llama 3.1 8B. O modelo tem 32 camadas, 8 cabeças de chaves/valores e uma dimensão de cabeça de 128. Cada token armazena uma chave e um valor, com 2 bytes cada em f16, portanto 2 x 8 x 128 x 2 = 4096 bytes por camada. Nas 32 camadas, isso corresponde a 128 KiB por token. Um contexto de 4096 tokens ocupa, portanto, 512 MiB, e um contexto de 32,768 tokens ocupa 4 GiB.

Assim, um modelo Q4_K_M 8B com um contexto de 4k precisa de aproximadamente 4.58 GiB para os pesos, mais cerca de 0.5 GiB para a cache e a memória do próprio runtime. Não cabe em 4 GiB de RAM. Cabe em 8 GiB, com margem para trabalhar. Se aumentar o contexto para 32k nessa mesma máquina com 8 GiB, a cache sozinha consome toda a margem disponível. Monitorize o consumo em tempo real com free -h enquanto o modelo está carregado e não confie numa estimativa que não tenha medido.

O Ollama multiplica este consumo. OLLAMA_NUM_PARALLEL tem o valor predefinido 1, e a memória necessária para um modelo aumenta proporcionalmente a esse número e ao comprimento do contexto. Se aumentar ambos ao mesmo tempo, o daemon pode pedir silenciosamente várias vezes mais RAM do que esperava.

Eixo 2: o daemon que tem de operar

O script de instalação do Ollama escreve uma unidade systemd, cria um utilizador de sistema ollama e ativa o serviço. Obtém a gestão do ciclo de vida sem ter de escrever nada disso. A configuração é feita através do systemd:

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_KEEP_ALIVE=30m"

sudo systemctl daemon-reload
sudo systemctl restart ollama
journalctl -e -u ollama

OLLAMA_KEEP_ALIVE é mais importante num VPS com CPU do que em qualquer outro contexto. Por predefinição, os modelos permanecem na memória durante 5 minutos e depois são descarregados. O pedido seguinte tem de voltar a ler o ficheiro inteiro do disco antes de responder, por isso um recarregamento de 4.58 GiB transforma uma resposta de dois segundos numa resposta de trinta segundos em armazenamento lento. Um keep-alive longo elimina a latência e ocupa permanentemente a RAM. Ambos têm custos reais. Escolha o que causar menos impacto.

O llama.cpp não fornece um daemon, por isso tem de escrever a unidade manualmente como /etc/systemd/system/llama-server.service:

[Unit]
Description=llama.cpp server
After=network-online.target

[Service]
ExecStart=/usr/local/bin/llama-server -m /srv/models/model-Q4_K_M.gguf -c 4096 -t 4 --host 127.0.0.1 --port 8080
Restart=always
RestartSec=3
User=llama

[Install]
WantedBy=multi-user.target

Ative-a com sudo systemctl enable --now llama-server. O processo mantém o modelo durante todo o seu ciclo de vida. Nada é descarregado quando fica inativo, o que elimina surpresas durante recarregamentos, mas também impede recuperar a memória sem parar o serviço. Se ainda não estiver familiarizado com a escrita de unidades, o padrão é o mesmo utilizado para executar os seus próprios serviços com systemd num VPS.

Eixo 3: a API com que a sua aplicação vai comunicar

Este eixo ficou muito mais limitado. Atualmente, ambos os projetos utilizam o formato de chat da OpenAI, por isso a maioria das bibliotecas cliente funciona com qualquer um dos dois depois de alterar apenas a URL base.

O Ollama escuta em 127.0.0.1:11434. A sua rota compatível com a OpenAI é http://localhost:11434/v1/chat/completions, e mantém também uma API nativa em /api/chat. Também existe uma rota compatível com a Anthropic documentada.

curl -X POST http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "llama31-q4", "messages": [{"role": "user", "content": "Say this is a test"}]}'

llama-server escuta em 127.0.0.1:8080 e disponibiliza /v1/chat/completions, /v1/completions e /v1/embeddings, além do seu próprio endpoint /completion e de uma interface web integrada. Também expõe rotas operacionais que o Ollama não disponibiliza: /health para uma verificação de prontidão, /props para as definições do modelo carregado, /slots para indicar o que cada slot de pedidos está a executar e /metrics no formato Prometheus. Se planeia monitorizar este serviço, essa diferença é provavelmente o fator decisivo.

Nenhum dos servidores ativa a autenticação automaticamente. Por uma boa razão, ambos utilizam loopback por predefinição. Aceda a eles através de um túnel SSH ou por trás de um reverse proxy. Nunca exponha 11434 ou 8080 à internet.

O que um VPS sem GPU pode fazer de forma realista

Um VPS apenas com CPU executa modelos pequenos lentamente. Esse é o resumo honesto, e o mais importante é saber onde está o limite. Faça medições antes de criar uma solução dependente desse ambiente:

llama-bench -m ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -p 512 -n 128

A coluna pp indica a velocidade de processamento do prompt e a coluna tg indica a velocidade de geração de tokens, ambas em tokens por segundo. Num plano com vCPU partilhada, um modelo 8B com Q4_K_M normalmente fica nos poucos dígitos para tg. O processamento do prompt é a parte mais penalizadora: o prompt completo é processado antes de aparecer o primeiro token da resposta, por isso um prompt de sistema longo acrescenta um tempo de espera a cada pedido.

Um uso viável em CPU é um modelo de 1B a 4B para classificação, extração, resumos curtos ou encaminhamento. As respostas chegam em segundos e a memória cabe num plano normal. Não é viável em CPU usar chat interativo à velocidade de leitura, assistentes de programação, processamento de documentos longos ou qualquer solução com um ciclo de agente que faça muitas chamadas em sequência. Um ciclo que faça doze chamadas de quatro segundos cada demora um minuto antes de produzir qualquer resultado.

Há duas alternativas quando os números não são suficientes. Se o problema for a simultaneidade, com vários utilizadores a acederem ao mesmo modelo ao mesmo tempo, a escolha do motor muda, e a comparação entre Ollama e vLLM para servir pedidos simultâneos aborda esse tema. Se o problema for a velocidade bruta, a resposta é um VPS com uma GPU associada, onde -ngl começa a ter significado. Antes de qualquer uma das opções, obtenha uma linha de base do próprio hardware, porque a largura de banda do disco e da memória influencia o tempo de carregamento tanto quanto a CPU. Um benchmark reproduzível de VPS justifica a hora investida.

Instale o llama.cpp com uma compilação fixada

Ambos os projetos evoluem semanalmente, por isso registe a versão que instalou. O comando de uma linha disponibilizado pelo projeto instala a compilação atual:

curl -LsSf https://llama.app/install.sh | sh
llama serve -hf ggml-org/Qwen3.5-0.8B-GGUF

Para fixar uma compilação específica, utilize o arquivo tar pré-compilado disponível na página de releases. A compilação b10224 é a tag atual em 2 August 2026:

curl -LO https://github.com/ggml-org/llama.cpp/releases/download/b10224/llama-b10224-bin-ubuntu-x64.tar.gz
tar xf llama-b10224-bin-ubuntu-x64.tar.gz
find . -type f -name 'llama-server'

Também pode compilar essa mesma tag a partir do código-fonte:

sudo apt update && sudo apt install -y build-essential cmake git libssl-dev
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
git checkout b10224
cmake -B build
cmake --build build --config Release -j $(nproc)

libssl-dev é a dependência documentada para as funcionalidades HTTPS. A compilação demora vários minutos e requer mais RAM do que os planos mais pequenos disponibilizam. Por isso, compile numa máquina maior e copie os binários se a máquina pequena ficar sem memória.

Instalar o Ollama com uma versão fixa

curl -fsSL https://ollama.com/install.sh | OLLAMA_VERSION=0.32.5 sh
ollama -v

O script lê OLLAMA_VERSION, para que possa fixar uma versão conhecida e estável em vez de instalar o que foi lançado esta manhã. A versão v0.32.5 foi publicada em 27 July 2026. Também existe um procedimento manual se preferir não encaminhar um script para uma shell:

sudo rm -rf /usr/lib/ollama
curl -fsSL https://ollama.com/download/ollama-linux-amd64.tar.zst | sudo tar x -C /usr
ollama -v

O procedimento manual não cria a unidade systemd nem o utilizador do serviço. Por isso, terá de os criar manualmente. O guia completo do Ollama numa VPS explica passo a passo como configurar esse serviço.

Modos de falha e mensagens apresentadas

Ollama recusa-se a carregar o modelo. ollama run devolve uma linha com este formato:

Error: model requires more system memory (5.6 GiB) than is available (3.2 GiB)

Ollama verifica o tamanho antes de carregar o modelo. Por isso, falha rapidamente e indica o motivo. Desça uma linha de quantização, reduza o tamanho do contexto ou escolha um modelo menor.

llama.cpp não falha: fica extremamente lento. Por predefinição, llama.cpp mapeia o GGUF na memória. Assim, um ficheiro maior do que a RAM ainda pode iniciar. Depois, o kernel pagina os pesos entre a memória e o disco a cada token. A geração pode passar a demorar vários segundos por token, com o disco a 100%. Passe --no-mmap para forçar uma alocação real. Assim, o processo falha imediatamente em vez de degradar o desempenho. Quando o kernel intervém, dmesg mostra o motivo:

Out of memory: Killed process 1234 (llama-server)

O ficheiro do modelo não carrega de todo. Um GGUF criado para uma família de modelos mais recente do que a suportada pelo seu engine devolve um erro que identifica a arquitetura desconhecida:

error loading model architecture: unknown model architecture: 'qwen3next'

A correção é atualizar o engine, não escolher outro ficheiro. Este é o custo de fixar versões e é por isso que deve registar o número da build. Precisa de saber a partir de que versão está a atualizar.

A API responde localmente, mas não a partir da sua aplicação. Ollama associa-se a 127.0.0.1:11434. Por isso, outro host recebe uma recusa de ligação. Defina OLLAMA_HOST=0.0.0.0:11434 através de systemctl edit ollama apenas quando a porta estiver protegida por uma firewall ou numa rede privada, porque a API não tem autenticação à frente.

A primeira resposta depois de uma pausa é muito lenta. O descarregamento após 5 minutos de inatividade ocorreu e o modelo está novamente a ser lido do disco. Executar ollama ps imediatamente antes do pedido não mostra nenhum modelo carregado, o que confirma a situação. Aumente OLLAMA_KEEP_ALIVE.

Então, qual deles deve executar?

Execute Ollama quando quiser que os modelos sejam geridos por si e precisar de um endpoint compatível com OpenAI sem configuração adicional. É a opção padrão mais adequada para uma primeira implementação e para qualquer cenário em que a escolha do modelo vá mudar regularmente.

Execute llama.cpp diretamente quando a memória for limitada ao ponto de precisar de escolher manualmente a linha de quantização, quando quiser /health, /slots e /metrics para monitorização ou quando precisar de uma flag que Ollama não disponibiliza. É a opção mais adequada num VPS onde o modelo ocupa quase toda a memória disponível, porque as definições que permitem executá-lo são precisamente as que Ollama escolhe por si.

É normal executar ambos. Use Ollama para experiências e llama.cpp para o modelo que colocar em produção e que não quiser alterar.

FAQ

O Ollama é apenas um wrapper em torno do llama.cpp?

Não exatamente, embora o wrapper faça trabalho real. O README do Ollama lista o llama.cpp como o backend de inferência (verificado em 2 August 2026). Além dele, o Ollama adiciona um registo de modelos, o template de prompt que transforma mensagens de chat num prompt, um conjunto de parâmetros de amostragem predefinidos, um daemon com descarregamento quando está inativo e uma API HTTP. Quando compara tokens por segundo com definições idênticas, está a comparar o mesmo motor consigo próprio. Na prática, a escolha é entre camadas de gestão.

Qual é mais rápido numa VPS apenas com CPU?

Partilham o mesmo motor. Por isso, com o mesmo ficheiro de modelo, quantização, tamanho de contexto e número de threads, os resultados ficam próximos. As diferenças normalmente resultam de definições predefinidas diferentes, sobretudo do comprimento do contexto e do número de threads, e não do motor. Meça com llama-bench -m <file> -p 512 -n 128 e compare a coluna tg no seu próprio servidor antes de confiar em qualquer valor publicado.

Posso usar o meu próprio ficheiro GGUF com o Ollama?

Sim. Coloque o ficheiro no servidor, escreva um Modelfile cuja primeira linha seja FROM ./your-model.gguf, adicione as linhas PARAMETER necessárias, como num_ctx, e execute ollama create your-name -f ./Modelfile. ollama ls irá apresentá-lo junto dos modelos obtidos do registo. É assim que pode usar uma quantização que não está disponível no registo.

De quanta RAM preciso para um modelo 8B?

Considere o tamanho do ficheiro, o cache KV e o runtime. Uma compilação Q4_K_M do Llama 3.1 8B ocupa cerca de 4.58 GiB em disco. Um contexto de 4096 tokens adiciona aproximadamente 512 MiB de cache. Por isso, 8 GiB de RAM são suficientes, mas 4 GiB não chegam. O cache aumenta com o contexto. O mesmo modelo com um contexto de 32,768 tokens precisa, por si só, de cerca de 4 GiB de cache. Com o Ollama, lembre-se de que o requisito também aumenta com OLLAMA_NUM_PARALLEL.