Ollama ou llama.cpp no VPS: qual usar?

Ollama vs llama.cpp: que camada você quer executar?

Ollama e llama.cpp não são concorrentes da forma implícita na pergunta. llama.cpp é o mecanismo de inferência: carrega um arquivo de modelo e transforma um prompt em tokens. Ollama é um gerenciador de modelos, um daemon em segundo plano e uma API HTTP executada sobre esse mecanismo. O README do Ollama ainda lista llama.cpp como o backend de inferência (verificado em 2 August 2026). Portanto, a questão real é qual camada você quer operar no seu VPS, e não qual é mais rápida.

Use Ollama quando quiser um serviço que obtenha modelos pelo nome e continue funcionando sem intervenção. Execute llama.cpp diretamente quando o servidor for pequeno e você precisar escolher o arquivo de modelo exato, o tamanho exato do contexto e a quantidade exata de threads, porque, em um VPS pequeno, cada uma dessas configurações consome memória que você não tem.

O que cada projeto é na prática

llama.cpp é uma implementação em C e C++ de inferência de transformers baseada na biblioteca ggml. Lê ficheiros GGUF. GGUF (GGML universal file format) é um contentor de ficheiro único que contém os pesos, o tokenizador e os metadados necessários 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 uma versão semântica. A tag atual é b10224, publicada em 2 de agosto de 2026, e é publicada uma nova tag na maioria dos dias úteis.

Ollama é um programa escrito 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 a versão v0.32.5 foi publicada em 27 de julho de 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 é a diferença principal. Ollama escolhe por si a quantização, o template e o tamanho do contexto, e dá-lhe um único nome para memorizar. llama.cpp não escolhe nada e disponibiliza 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 carregar um modelo com 8 mil milhões de parâmetros na RAM de um VPS comum. A nomenclatura GGUF é legível quando se conhece o padrão: Q4_K_M significa quantização K de 4 bits, com tamanho médio. Um número mais alto 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 August 2026 e convertidos de bytes para GiB. Existem 6 builds de um modelo, e o menor tem 2.96 GiB, contra 7.95 GiB do maior. A opção predefinida mais comum, Q4_K_M, tem 4.58 GiB. Num VPS com 4 GiB, essa escolha determina se o modelo consegue sequer ser carregado.

Com llama.cpp, indica-se o nome do ficheiro, por isso escolhe essa linha manualmente.

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 é inferido automaticamente.

Com Ollama, a quantização acompanha a tag que descarrega, e ollama ls mostra o que está efetivamente armazenado no disco. Quando o registry não contém o build pretendido, importe um GGUF manualmente. Escreva um Modelfile:

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

Depois, faça o build e confirme o resultado:

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

O comprimento do contexto é a definição que mais causa problemas. Ollama escolhe o valor predefinido com base na VRAM disponível, e um servidor sem GPU fica no menor escalão: 4096 tokens. Se lhe enviar um documento com 20,000 tokens, os tokens adicionais são descartados antes de o modelo os processar. A resposta pode então estar errada, com confiança, sobre um ficheiro que o modelo leu apenas parcialmente. 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 fiável. Defina -c explicitamente e saiba qual foi o valor configurado.

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

O ficheiro do modelo não representa todo o custo. A cache KV (cache de chave/valor) mantém uma entrada por camada e por token de contexto. O seu tamanho aumenta à medida que a conversa cresce.

Faça as contas para o Llama 3.1 8B. O modelo tem 32 camadas, 8 cabeças de chave/valor e uma dimensão de cabeça de 128. Cada token armazena uma chave e um valor, com 2 bytes cada em f16. Assim, 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 custa, portanto, 512 MiB. Um contexto de 32,768 tokens custa 4 GiB.

Assim, um modelo Q4_K_M 8B num 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 consome sozinha toda a margem disponível. Monitorize o consumo em tempo real com free -h enquanto o modelo está carregado. Não confie numa estimativa que não tenha medido. Se estiver a dimensionar um modelo muito acima de 8B, a mesma aritmética aplicada a um modelo de 27B numa VPS apenas com CPU mostra o que cada nível entre 8 e 64 GB consegue realmente suportar.

O Ollama multiplica este consumo. OLLAMA_NUM_PARALLEL tem o valor predefinido de 1. A memória necessária para o modelo aumenta proporcionalmente a esse número multiplicado pelo comprimento do contexto. Se aumentar ambos ao mesmo tempo, o daemon passa silenciosamente a pedir várias vezes mais RAM do que esperava. A mesma aritmética define o limite de utilizadores simultâneos, porque cada pedido concorrente precisa da sua própria parte da cache KV. É por isso que um servidor que funciona bem para uma pessoa bloqueia com cinco.

Eixo 2: o daemon que tem de administrar

O script de instalação do Ollama escreve uma unidade systemd, cria um utilizador de sistema ollama e ativa o serviço. Obtém 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 ambiente. Por predefinição, os modelos ficam 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, portanto uma recarga de 4.58 GiB transforma uma resposta de dois segundos numa resposta de trinta segundos num armazenamento lento. Um keep-alive longo elimina a latência e ocupa permanentemente a RAM. Ambos são 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 de recarga, mas também impede recuperar a memória sem parar o serviço. Se ainda não estiver familiarizado com a escrita de unidades, este é o mesmo padrão usado para executar os seus próprios serviços com systemd num VPS.

Eixo 3: a API com a qual a sua aplicação comunicará

Este eixo ficou muito mais estreito. Ambos os projetos agora usam o formato de chat da OpenAI, pelo que a maioria das bibliotecas cliente funciona com qualquer um deles após 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 também mantém uma API nativa em /api/chat. Existe também uma rota compatível com a Anthropic.

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 disponibiliza rotas operacionais que o Ollama não oferece: /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, esta diferença é provavelmente o fator decisivo.

Nenhum dos dois servidores ativa a autenticação automaticamente. Por uma boa razão, ambos escutam por predefinição apenas no loopback. Aceda-lhes 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 apenas com CPU pode fazer na prática

Um VPS apenas com CPU executa modelos pequenos lentamente. Esse é o resumo honesto. O ponto útil é saber onde está o limite. Faça medições antes de projetar qualquer solução à volta dele:

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 em 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 de saída, portanto um system prompt longo acrescenta um tempo de espera a cada pedido.

É 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: chat interativo à velocidade de leitura, assistentes de programação, trabalho com documentos longos ou qualquer tarefa com um ciclo de agente que faça muitas chamadas em sequência. Um ciclo com doze chamadas de quatro segundos cada demora um minuto antes de produzir qualquer resultado. Se a ideia já era usar um assistente de programação, indicar a um agente um modelo alojado por si explica quais tarefas um modelo local pequeno executa realmente bem e quais têm de continuar numa API alojada.

Existem duas alternativas quando os números não são suficientes. Se o problema for a concorrência, ou seja, muitos utilizadores a acederem simultaneamente ao mesmo modelo, a escolha do engine muda, e a comparação entre Ollama e vLLM para disponibilização concorrente aborda esse cenário. Se o problema for a velocidade bruta, a resposta é um VPS com uma GPU associada, onde -ngl começa a ter um valor relevante. 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 de VPS reproduzível vale o tempo necessário.

Instalar llama.cpp, fixado numa build

Ambos os projetos têm atualizações semanais, por isso registe a versão que instalou. O one-liner do projeto instala a build atual:

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

Para fixar uma build específica, use o tarball pré-compilado da página de releases. A build 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'

Em alternativa, compile 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. Compile numa máquina maior e copie os binários se a máquina pequena ficar sem recursos.

Instalar o Ollama com uma versão fixada

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

O script lê OLLAMA_VERSION, para que possa manter 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 adicionar manualmente. O guia completo do Ollama num VPS explica essa configuração do serviço passo a passo.

Modos de falha e as mensagens que verá

Ollama recusa-se a carregar o modelo. ollama run devolve uma linha deste tipo:

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 imediatamente e indica o motivo. Desça uma linha de quantização, reduza o comprimento do contexto ou escolha um modelo mais pequeno.

llama.cpp não falha; fica extremamente lento. Por predefinição, llama.cpp faz o mapeamento de memória do GGUF, por isso um ficheiro maior do que a RAM ainda é iniciado. O kernel passa então a paginar os pesos entre a memória e o disco a cada token, e a geração passa a demorar segundos por token, com o disco a 100 por cento. Passe --no-mmap para forçar uma alocação real, de modo que o processo falhe 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 forma alguma. Um GGUF criado para uma família de modelos mais recente do que o 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 faz bind 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 atrás de 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á a ser lido novamente do disco. ollama ps executado imediatamente antes do pedido não mostra nenhum modelo carregado, o que confirma o diagnóstico. Aumente OLLAMA_KEEP_ALIVE.

Então, qual deve executar?

Execute o Ollama quando quiser que os modelos sejam geridos automaticamente e precisar de um endpoint compatível com a API da OpenAI sem trabalho adicional. É a opção predefinida correta para a primeira implementação e para qualquer cenário em que a escolha do modelo continue a mudar.

Execute o llama.cpp diretamente quando a memória for suficientemente limitada para precisar de escolher manualmente a linha de quantização, quando quiser /health, /slots e /metrics para monitorização ou quando precisar de um sinalizador que o Ollama não disponibiliza. É a escolha adequada numa 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 o Ollama escolhe em seu nome.

É normal executar ambos. Use o Ollama para experiências e o llama.cpp para o único modelo colocado em produção, que não pretende alterar.

FAQ

O Ollama é apenas um wrapper à volta do llama.cpp?

É quase isso, mas o wrapper executa trabalho real. O README do Ollama lista o llama.cpp como o seu 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 descarga por inatividade 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 reportadas resultam de predefinições 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á listá-lo juntamente com os modelos transferidos do registo. É assim que pode usar uma quantização que o registo não disponibiliza.

De quanta RAM preciso para um modelo 8B?

Considere o tamanho do ficheiro, mais a cache KV, mais o runtime. Uma compilação Q4_K_M do Llama 3.1 8B ocupa cerca de 4.58 GiB em disco, e 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. A cache aumenta com o contexto: o mesmo modelo com um contexto de 32,768 tokens precisa de cerca de 4 GiB de cache por si só. Com o Ollama, lembre-se de que o requisito também aumenta com OLLAMA_NUM_PARALLEL.