Ollama ou llama.cpp: qual usar em um VPS?

Ollama vs llama.cpp: em 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: ele carrega um arquivo de modelo e converte um prompt em tokens. Ollama é um gerenciador de modelos, um daemon em segundo plano e uma API HTTP sobre esse mecanismo. O README do Ollama ainda lista o llama.cpp como seu 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 o Ollama quando quiser um serviço que obtenha modelos pelo nome e continue funcionando sem intervenção. Execute o llama.cpp diretamente quando o servidor for pequeno e você precisar escolher o arquivo de modelo exato, o tamanho exato do contexto e o número exato de threads, porque, em um VPS pequeno, cada uma dessas configurações consome memória que você não tem.

O que cada projeto realmente é

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 de ficheiro único 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 build, e não por uma versão semântica. A tag atual é b10224, publicada em 2 de agosto de 2026, e é criada 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 v0.32.5 foi disponibilizado 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. Esses ficheiros ficam no disco raiz e ocupam vários gigabytes cada um. Por isso, numa VPS com um volume raiz de 25 GB, é importante saber o que o pull deixa para trás e como mover o diretório dos modelos para outro local antes que o terceiro download o preencha.

Essa forma de empacotamento é toda a diferença. 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 decide 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 uma VPS comum. Os nomes GGUF são fáceis de interpretar 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, lidos em 2 August 2026 e convertidos de bytes para GiB. Há 6 builds de um modelo, e o menor tem 2.96 GiB, contra 7.95 GiB do maior. O padrão mais comum, Q4_K_M, tem 4.58 GiB. Numa VPS de 4 GiB, essa escolha determina se o modelo chega sequer a carregar. O tamanho é apenas metade da decisão, porque uma linha que consegue pagar não é automaticamente uma linha que vale a pena usar, e o custo real de Q4, Q8 e fp16 na qualidade das respostas é o que mostra se os gigabytes adicionais compram alguma melhoria percetível.

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

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 sistema apenas com CPU). Nada é escolhido automaticamente por si.

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

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

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

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

O tamanho do contexto é a definição que mais frequentemente causa problemas. O Ollama escolhe o valor predefinido com base na VRAM disponível, e um sistema sem GPU fica no grupo mais pequeno: 4096 tokens. Se lhe enviar um documento com 20,000 tokens, os tokens excedentes são eliminados antes de o modelo os receber. A resposta pode então estar errada com confiança sobre um ficheiro que o modelo leu apenas parcialmente. Aumente esse valor com OLLAMA_CONTEXT_LENGTH no daemon ou com PARAMETER num_ctx num Modelfile. Se apenas uma tarefa precisar de uma janela maior, num_ctx pode ser definido por pedido em vez de ser aplicado a todo o servidor, evitando que a cache adicional seja usada por todas as outras tarefas executadas pelo daemon. O llama.cpp também não tem um valor predefinido em que seja prudente confiar. Defina -c explicitamente e confirme o valor configurado.

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

O ficheiro do modelo não representa o custo total. A cache KV (cache de chave/valor) armazena uma entrada por camada e por token de contexto e cresce à medida que a conversa avança.

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, e um contexto de 32,768 tokens custa 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, além do próprio runtime. Não cabe em 4 GiB de RAM. Cabe em 8 GiB, com margem para funcionar. Se aumentar o contexto para 32k nessa mesma máquina com 8 GiB, a cache consumirá sozinha toda a margem disponível. Observe o consumo em tempo real com free -h enquanto o modelo está carregado e não confie numa estimativa que não tenha medido. Se estiver a dimensionar uma máquina para algo 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 alojar.

O Ollama multiplica esse consumo. OLLAMA_NUM_PARALLEL tem o valor predefinido 1, e a memória necessária para um modelo aumenta proporcionalmente a esse número multiplicado pelo tamanho do contexto. Se aumentar ambos ao mesmo tempo, o daemon solicitará silenciosamente 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 parcela da cache KV. É por isso que um servidor que funciona bem para uma pessoa bloqueia com cinco.

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 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 ler novamente o ficheiro completo do disco antes de responder, pelo que um carregamento de 4.58 GiB transforma uma resposta de dois segundos numa resposta de trinta segundos em armazenamento lento. Um keep-alive prolongado elimina a latência e ocupa permanentemente a RAM. Ambos são custos reais. Escolha o que causar menos impacto. Se decidir que o modelo deve permanecer sempre residente, configurar keep_alive para que sobreviva a períodos de inatividade e reinícios requer apenas algumas linhas e evita ter de aquecer manualmente o modelo sempre que o servidor reinicia.

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 tempo de execução. Nada é descarregado durante os períodos de inatividade, o que elimina surpresas causadas por novos carregamentos, mas também impede recuperar a memória sem parar o serviço. Se nunca escreveu unidades, o padrão é o mesmo de 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. Agora, ambos os projetos usam o formato de chat da OpenAI, por isso a maioria das bibliotecas cliente funciona com qualquer um deles depois de alterar apenas a URL base.

O Ollama escuta em 127.0.0.1:11434. A rota compatível com a OpenAI é http://localhost:11434/v1/chat/completions, e o Ollama 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 sonda 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 servidores ativa a autenticação por si só. Por predefinição, ambos ficam ligados ao loopback, por uma boa razão. Aceda-lhes através de um túnel SSH ou por trás de um reverse proxy. Nunca exponha as portas 11434 ou 8080 à Internet.

O que um VPS apenas com CPU consegue fazer de forma realista

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 basear qualquer projeto nisso:

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 tokens por segundo 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 uma espera a cada pedido. O comprimento da resposta é a parte dos custos que pode controlar diretamente, porque, a três tokens por segundo, um modelo que gere uma resposta prolixa de 600 tokens mantém o servidor ocupado durante três minutos. Por isso, limitar a saída com num_predict é a forma mais barata de impedir que uma resposta demasiado longa provoque um timeout.

É 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. Para um exemplo prático com esse tamanho, em vez de um intervalo, Nemotron 3.5 Lightning descarregado e medido num VPS apresenta a tag exata, a RAM que realmente necessita e a velocidade mantida sem GPU. 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 sequenciais. Um ciclo com doze chamadas a quatro segundos cada demora um minuto antes de produzir qualquer resultado. Se o plano era utilizar um assistente de programação, apontar um agente para um modelo alojado por si mostra quais as tarefas em que um modelo local pequeno é realmente vantajoso 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, com vários utilizadores a acederem ao mesmo modelo ao mesmo tempo, a escolha do motor muda. 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 dessas 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 justifica o tempo de uma hora.

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

Ambos os projetos mudam semanalmente, por isso registe a versão que implementou. 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, use o tarball pré-compilado da página de versões. 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. Se o servidor pequeno ficar sem memória, compile num servidor maior e copie os binários.

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 manter uma versão conhecida e estável em vez de instalar a versão que foi lançada hoje. A versão v0.32.5 foi publicada em 27 July 2026. Também existe um procedimento manual, caso prefira não enviar um script diretamente 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 essa configuração do serviço passo a passo.

Modos de falha e 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 rapidamente 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 usa memory mapping para o GGUF, por isso um ficheiro maior do que a RAM ainda pode iniciar. O kernel passa então a carregar e retirar pesos do disco a cada token, e a geração demora vários segundos por token, com o disco a 100 por cento de utilização. Passe --no-mmap para forçar uma alocação real, fazendo com que 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 todo. Um GGUF criado para uma família de modelos mais recente do que a suportada pelo seu motor devolve um erro que indica a arquitetura desconhecida:

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

A correção é atualizar o motor, não usar outro ficheiro. Este é o custo de fixar versões e o motivo para registar o número da compilação. 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 fica associado 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á a ser lido novamente do disco. ollama ps executado imediatamente antes do pedido não mostra nada carregado, o que confirma a situação. Aumente OLLAMA_KEEP_ALIVE.

Portanto, qual deve executar?

Execute Ollama quando quiser que os modelos sejam geridos automaticamente e precisar de um endpoint compatível com OpenAI sem trabalho adicional. É a escolha padrão para a primeira implementação e para qualquer cenário em que a escolha do modelo vá mudar com frequência.

Execute llama.cpp diretamente quando a memória for suficientemente limitada para precisar de escolher 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 escolha adequada num VPS em que o modelo ocupa quase toda a memória disponível, porque as definições que permitem que ele caiba são precisamente as que Ollama escolhe por si.

Executar ambos é normal. Ollama para experiências; llama.cpp para o modelo que colocar em produção e que nunca quiser substituir.

FAQ

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

É quase isso, mas o wrapper faz trabalho real. O README do Ollama lista o llama.cpp como o seu backend de inferência (verificado em 2 August 2026). Além disso, 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 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, o que escolhe é a camada 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 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 obtidos 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, a cache KV e 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.