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

Ollama vs llama.cpp: em qual camada você quer operar?

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 transforma 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 llama.cpp como seu backend de inferência (verificado em 27 October 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 baixe modelos pelo nome e continue funcionando sem intervenção. Use 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 realmente é

llama.cpp é uma implementação em C e C++ de inferência de transformers baseada na biblioteca ggml. Ele lê arquivos GGUF. GGUF (GGML universal file format) é um contêiner de arquivo único que contém os pesos, o tokenizador e os metadados necessários para executar o modelo. O projeto fornece binários separados para tarefas diferentes. llama-server é um servidor HTTP, llama-cli é um prompt interativo e llama-bench mede a vazão. O projeto agora publica versões que seguem versionamento semântico (MAJOR.MINOR.PATCH), e v0.7.0, publicada em 15 October 2026, era a mais recente em 27 October 2026. As tags nightly numeradas por build continuam sendo publicadas junto com elas, várias por dia, e a mais recente em 27 October 2026 era b11913.

Ollama é um programa em Go. Um daemon em segundo plano, iniciado com ollama serve, carrega modelos e responde a solicitações HTTP, enquanto um cliente de linha de comando se comunica com esse daemon. Por trás dos dois existe um registro em ollama.com que contém modelos pré-empacotados. Ollama usa versões semânticas. v0.32.5 foi publicada em 27 July 2026, e v0.40.12 foi lançada em 27 October 2026 às 00:07 UTC. ollama pull baixa um arquivo GGUF junto com um template de prompt e um conjunto de parâmetros padrão, e depois o armazena em /usr/share/ollama/.ollama/models no Linux. Esses arquivos ficam no disco raiz e podem ocupar vários gigabytes cada, portanto, em um VPS com um volume raiz de 25 GB, é importante saber o que o pull deixa para trás e como mover o diretório de modelos para outro local antes que o terceiro download o preencha.

Essa forma de empacotamento é toda a diferença. Ollama decide a quantização, o template e o tamanho do contexto por você, e fornece um único nome para memorizar. llama.cpp expõe essas escolhas como flags, com valores padrão automáticos para as configurações que você não definir.

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

A quantização armazena os pesos com menos bits do que os 16 ou 32 bits do modelo original, e as compilações GGUF comuns usam, em média, cerca de 4, 5 ou 8 bits por peso. A precisão não é uniforme em todo o ficheiro. No código-fonte do quantizador do llama.cpp (consultado em 27 October 2026), uma compilação Q4_K_M mantém a maioria dos tensores em 4 bits, mas usa Q6_K de 6 bits na camada de saída e nos tensores de valores da atenção e de redução do feed-forward em cerca de metade das camadas. Tensores pequenos, como as normas, não são quantizados. É isso que permite colocar um modelo com 8 billion parameters na RAM de um VPS comum. A nomenclatura GGUF torna-se 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 maior mantém mais precisão e requer 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 dos ficheiros publicados no repositório bartowski/Meta-Llama-3.1-8B-Instruct-GGUF no Hugging Face, consultados em 2 August 2026 e convertidos de bytes para GiB. 6 compilações de um modelo, sendo que a menor ocupa 2.96 GiB e a maior ocupa 7.95 GiB. A opção predefinida comum, Q4_K_M, ocupa 4.58 GiB. Num VPS de 4 GiB, esta escolha determina se o modelo chega a ser carregado. O tamanho é apenas metade da decisão, porque uma linha que cabe no orçamento não é automaticamente uma linha que valha a pena usar, e o custo real de Q4, Q8 e fp16 na qualidade das respostas é que indica se os gigabytes adicionais trazem alguma melhoria percetível.

Com o llama.cpp, indica o ficheiro pelo nome, 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 numa máquina apenas com CPU). As definições não especificadas usam valores predefinidos, e --fit está ativado por predefinição para ajustar os argumentos não especificados à memória do dispositivo.

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

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

Depois, compile-o e verifique o resultado:

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

O tamanho do contexto é a definição que mais costuma causar problemas. O Ollama escolhe o valor predefinido com base na VRAM disponível, e uma máquina sem GPU fica no escalão mais pequeno: 4096 tokens. Se lhe enviar um documento com 20,000 tokens, os tokens adicionais são descartados antes de o modelo os ver, e a resposta fica errada com confiança sobre um ficheiro que leu apenas pela metade. 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, mantendo a cache adicional fora de todas as outras tarefas que o daemon tiver de executar. O llama.cpp também não tem um valor predefinido em que seja prudente confiar. Defina -c explicitamente e saiba o que definiu.

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 você precisa operar

O script de instalação do Ollama grava uma unidade do systemd, cria um usuário de sistema ollama e habilita o serviço. Você obtém o gerenciamento do ciclo de vida sem precisar escrever nada disso. A configuração passa pelo 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 em uma VPS com CPU do que em qualquer outro ambiente. Por padrão, os modelos ficam na memória por 5 minutos e depois são descarregados. A próxima solicitação precisa carregar o arquivo inteiro novamente antes de responder. Se o kernel ainda mantiver o arquivo no page cache, isso será rápido, mas somente a RAM disponível o manterá ali. Quando outra carga de trabalho o remove do cache, o arquivo volta do disco, e um reload de 4.58 GiB transforma uma resposta de dois segundos em uma resposta de trinta segundos em armazenamento lento. Um keep-alive longo corrige a latência, mas consome a RAM permanentemente. Os dois são custos reais. Escolha o que causar menos impacto. Se decidir que o modelo deve permanecer residente, configurar keep_alive para que ele sobreviva a períodos de inatividade e reinicializações exige algumas linhas e evita aquecer o modelo manualmente toda vez que o servidor reiniciar.

O llama.cpp não fornece daemon nem usuário de serviço, então você precisa configurar os dois. A partir do diretório llama.cpp que você compilou, instale o binário e as bibliotecas em /usr/local, crie um usuário llama e forneça a ele uma cópia do modelo:

sudo cmake --install build
sudo ldconfig
sudo useradd --system --no-create-home --shell /usr/sbin/nologin llama
sudo install -d -o llama -g llama /srv/models
sudo install -o llama -g llama -m 644 ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf /srv/models/model-Q4_K_M.gguf

Se você usou o release archive em vez de compilar, aponte ExecStart para o llama-server dentro dele, porque o arquivo mantém as bibliotecas ao lado do binário. Depois, escreva a unidade 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

Habilite-a com sudo systemctl enable --now llama-server. O processo então mantém o modelo durante todo o seu ciclo de vida. Por padrão, nada é descarregado quando fica ocioso, mas adicionar --sleep-idle-seconds habilita o descarregamento e o carregamento automáticos sem interromper o serviço. Se escrever unidades for algo novo para você, este é o mesmo padrão de executar seus próprios serviços com systemd em uma VPS.

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

Este eixo estreitou-se bastante. Ambos os projetos suportam agora 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.

Ollama escuta em 127.0.0.1:11434. A rota compatível com OpenAI é http://localhost:11434/v1/chat/completions, e o serviço também mantém uma API nativa em /api/chat. Também está documentada uma rota compatível com Anthropic. Nenhuma dessas rotas permite que o modelo pesquise informações por conta própria. Se a sua aplicação precisar de respostas mais recentes do que os dados de treino do modelo, planeie integrar a pesquisa na web através da API do Ollama, do Open WebUI ou de um ciclo curto de ferramentas.

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"}]}'

Iniciado com as flags acima, llama-server escuta em 127.0.0.1:8080. Sem essa configuração, passa a usar por predefinição a porta 9931 (verificado em 27 October 2026), por isso mantenha --port na linha de comandos se a sua aplicação esperar a porta 8080. O serviço 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 expõe: /health para uma verificação de prontidão, /props para as definições do modelo carregado, /slots para mostrar o que cada slot de pedidos está a executar e /metrics no formato Prometheus depois de adicionar --metrics, porque esse endpoint está desativado por predefinição. Se planear monitorizar este serviço, essa diferença será provavelmente o fator decisivo.

Nenhum dos dois servidores ativa a autenticação por si só. Ambos usam loopback por predefinição, por uma boa razão. Aceda-lhes através de um túnel SSH ou por trás de um reverse proxy e nunca exponha 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 criar 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. A coluna tg indica a velocidade de geração de tokens. Ambas são expressas em tokens por segundo. Num plano com vCPU partilhada, um modelo 8B em Q4_K_M normalmente fica nos poucos tokens por segundo em tg. O processamento do prompt é a parte mais lenta. 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 metade do custo que pode controlar diretamente. A três tokens por segundo, um modelo que gere 600 tokens mantém o servidor ocupado durante 200 segundos. São mais de três minutos apenas de geração. Por isso, limitar a saída com num_predict é a forma mais barata de impedir que uma resposta demasiado longa cause um timeout.

Utilizável com 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 necessária cabe num plano normal. Para um exemplo concreto desse tamanho, em vez de um intervalo de tamanhos, Nemotron 3.5 Lightning transferido e medido num VPS apresenta a tag exata, a RAM que realmente necessita e a velocidade que mantém sem GPU. Não utilizável com CPU: conversação interativa à velocidade de leitura, assistentes de programação, processamento de documentos longos ou qualquer tarefa com um loop de agente que faça muitas chamadas em sequência. Um loop com doze chamadas a quatro segundos cada demora um minuto antes de produzir qualquer resultado. Se o plano era usar um assistente de programação, apontar um agente para um modelo alojado por si explica quais as tarefas em que um modelo local pequeno é realmente eficaz e quais têm de continuar numa API alojada.

Há 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 servir pedidos concorrentes aborda esse caso. 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 destas opções, obtenha uma linha de base do próprio hardware. A largura de banda do disco e da memória influencia o tempo de carregamento tanto como a CPU. Um benchmark de VPS repetível justifica o tempo necessário.

Instale o llama.cpp, fixado numa compilação

Ambos os projetos avançam semanalmente, portanto registe a versão que implantou. 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 releases. O projeto agora também publica releases com versionamento semântico: v0.7.0 era a versão mais recente em 27 October 2026, e a respetiva página de release aponta para a nightly b11669 dos binários. A v0.8.0 foi lançada em 28 October 2026, e a respetiva página de release aponta para a nightly b11960 dos binários. Os comandos abaixo usam b10224, a tag atual em 2 August 2026; substitua-a pela tag que testou:

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, portanto 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 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 as strings que você verá

Ollama se recusa a carregar o modelo. Releases mais antigos do Ollama verificavam o tamanho antes de carregar, e ollama run retornava uma linha neste formato:

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

O código-fonte atual do Ollama não traz mais essa mensagem (verificado em 27 October 2026). Agora o Ollama delega o carregamento ao llama-server, então um modelo que não cabe aparece como uma falha do runner, com erros que começam assim:

llama-server reported out-of-memory during startup
llama-server process has terminated

De qualquer forma, a correção é a mesma. Desça uma linha de quantização, reduza o tamanho do contexto ou escolha um modelo menor.

llama.cpp não falha, ele fica extremamente lento. Por padrão, o llama.cpp mapeia o GGUF na memória, então um arquivo maior que a RAM ainda é iniciado. O kernel então pagina os pesos para dentro e para fora da memória a partir do disco a cada token, e a geração cai para segundos por token, com o disco fixado em 100 por cento. Passe --load-mode none para desativar o mapeamento de memória. Essa opção substituiu --no-mmap, que está documentada como obsoleta na build b10224 fixada e não aparece mais nas builds atuais (verificado em 29 October 2026). Quando o kernel intervém, dmesg mostra o motivo:

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

O arquivo do modelo não carrega de forma alguma. Um GGUF criado para uma família de modelos mais nova que o seu engine gera um erro informando a arquitetura que ele não conhece, em que <arch> é o nome armazenado nos metadados do arquivo:

llama_model_load: error loading model: unknown model architecture: '<arch>'

A correção é atualizar o engine, não usar outro arquivo. Esse é o custo de fixar uma versão, e é por isso que você anota o número da build. Você precisa saber a partir de qual versão está atualizando.

A API responde localmente, mas não a partir do seu aplicativo. O Ollama faz bind em 127.0.0.1:11434, então outro host recebe uma recusa de conexão. Defina OLLAMA_HOST=0.0.0.0:11434 por meio de systemctl edit ollama somente quando a porta estiver atrás de um firewall ou em uma rede privada, porque a API não tem autenticação na frente dela.

A primeira resposta depois de uma pausa é muito lenta. O descarregamento após 5 minutos de inatividade aconteceu, e o modelo está sendo carregado novamente, a partir do disco se o cache de páginas não o tiver mantido. ollama ps executado imediatamente antes da solicitação não mostra nada carregado, o que confirma isso. 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 uma camada de encapsulamento sobre o llama.cpp?

Quase, mas a camada de encapsulamento executa trabalho real. O README do Ollama lista o llama.cpp como backend de inferência (verificado em 27 October 2026). Além dele, o Ollama adiciona um registro de modelos, o template de prompt que transforma mensagens de chat em um prompt, um conjunto de parâmetros de amostragem padrão, um daemon que descarrega modelos inativos e uma API HTTP. Quando você compara tokens por segundo com configurações idênticas, está comparando o mesmo mecanismo consigo próprio. Na prática, a escolha é entre as camadas de gerenciamento.

Qual é mais rápido em uma VPS somente com CPU?

Eles compartilham o mesmo mecanismo. Portanto, usando o mesmo arquivo de modelo, quantização, tamanho de contexto e número de threads, os resultados ficam próximos. As diferenças relatadas geralmente vêm de configurações padrão diferentes, principalmente do tamanho de contexto e do número de threads, e não do mecanismo. 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 meu próprio arquivo GGUF com o Ollama?

Sim. Coloque o arquivo 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 vai listá-lo junto com os modelos obtidos do registro. É assim que você usa uma quantização que o registro não oferece.

Quanta RAM é necessária para um modelo 8B?

Considere o tamanho do arquivo, 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, e um contexto de 4096 tokens adiciona aproximadamente 512 MiB de cache. Portanto, 8 GiB de RAM oferecem uma margem confortável, mas 4 GiB não são suficientes. O 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.