Ollama ou vLLM: qual servidor LLM usar?

Ollama vs vLLM, em um parágrafo

Ollama é um gestor de modelos com um servidor integrado: descarrega pesos quantizados, carrega-os e responde em 127.0.0.1:11434, usando a CPU se for tudo o que o servidor tiver. vLLM é um motor de throughput: mantém uma GPU ocupada com muitos pedidos em execução ao mesmo tempo e é a ferramenta errada numa máquina sem GPU. Essa é toda a decisão. Uma pessoa a falar com um assistente local é um trabalho para o Ollama. Uma aplicação que atende uma equipa é um trabalho para o vLLM.

Ambos disponibilizam uma API HTTP compatível com OpenAI, por isso o código cliente pode passar de um para o outro alterando a URL base. A API não é a diferença. A diferença está no que acontece quando chega um segundo pedido enquanto o primeiro ainda está a gerar tokens.

O que o Ollama realmente é

O Ollama é uma camada de conveniência. Ele fornece um registo de modelos (ollama pull llama3.1:8b), um armazenamento local de pesos, uma interface de prompt de chat, um serviço systemd e uma API HTTP, através de um único comando de instalação. Os modelos que disponibiliza são ficheiros GGUF, normalmente quantizados para 4 bits. Por isso, um modelo 7B ou 8B ocupa cerca de 5 GB em disco, em vez de 16 GB. A quantização é o que torna possível executar inferência na CPU.

O runner é baseado no llama.cpp, a biblioteca de inferência em C++ que tornou prática a quantização GGUF em hardware comum. Entretanto, o Ollama adicionou o seu próprio motor para algumas famílias de modelos mais recentes, mas o llama.cpp continua a ser a base da maior parte do que disponibiliza. Por isso, quando as pessoas comparam o Ollama com o llama.cpp, estão sobretudo a comparar uma camada de ergonomia com o componente que ela encapsula.

O objetivo do design é servir um utilizador. Em julho de 2026, o valor predefinido de OLLAMA_NUM_PARALLEL é 1. Isto significa que um modelo processa um pedido de cada vez e que todos os restantes ficam numa fila com 512 entradas por predefinição (OLLAMA_MAX_QUEUE). Pode aumentar a definição de execução em paralelo, e a secção abaixo explica o custo dessa alteração. Se ainda não executou o Ollama, comece por alojar o Ollama num VPS e manter a porta 11434 fechada, porque a API não tem qualquer tipo de autenticação.

O que o vLLM é na prática

O vLLM é apenas um servidor de inferência. Não gere uma biblioteca de modelos, não inclui um prompt de chat e não descarrega um modelo no momento do pedido. Indica um repositório do Hugging Face ao iniciar o processo. O vLLM carrega esse modelo e disponibiliza-o até o processo ser interrompido.

A vantagem dessa especialização é o débito. Dois mecanismos fazem esse trabalho. PagedAttention armazena a cache KV (cache de chave-valor, o estado de atenção por token que o modelo mantém para cada pedido ativo) em blocos de tamanho fixo, tal como um sistema operativo pagina a memória. Um pedido já não precisa de uma reserva contígua grande, dimensionada para o pior caso. Assim, a memória que antes ficava reservada e inutilizada pode ser usada por mais pedidos simultâneos. Continuous batching permite que um novo pedido entre no lote em execução no passo seguinte de descodificação, sem esperar que o lote atual termine. Quando uma sequência termina, sai imediatamente do lote e a sua posição é reutilizada.

Na prática, numa única GPU, passar de 1 utilizador simultâneo para 30 aumenta bastante o total de tokens por segundo, enquanto a velocidade de cada utilizador diminui muito menos do que seria esperado. Com a configuração predefinida do Ollama, passar de 1 utilizador para 30 apenas faz com que 29 pessoas fiquem à espera.

O batching contínuo é a diferença fundamental

Considere cinco pedidos a chegar a cada servidor ao mesmo tempo, com hardware idêntico.

Com as definições predefinidas, o Ollama processa o primeiro pedido até ao fim, depois o segundo, e assim sucessivamente. O quinto utilizador espera por quatro gerações completas. O débito total é aproximadamente o de uma única geração, porque o processador só trabalha numa sequência de cada vez.

O vLLM descodifica os cinco pedidos na mesma passagem forward. Gerar um token para cinco sequências custa pouco mais do que gerar um token para uma sequência, porque a parte dispendiosa é ler os pesos do modelo da memória, e essa leitura é partilhada por todo o batch. Este é o mesmo princípio de largura de banda da memória que torna a inferência no CPU lenta: o custo está em mover os pesos, não na operação aritmética.

Pode definir OLLAMA_NUM_PARALLEL=4 e obter parte deste comportamento. O custo é memória. Cada slot paralelo precisa da sua própria cache KV, e o Ollama divide a janela de contexto pelos slots. Assim, quatro pedidos paralelos contra um modelo configurado para 8192 tokens deixam 2048 tokens de contexto para cada pedido. Esse valor de 8192 também é uma escolha, não um valor fixo. Por isso, aumentar num_ctx e dimensionar a RAM necessária é o passo que determina se quatro slots são utilizáveis. A cache paginada do vLLM evita esta troca, porque os blocos são atribuídos a um pedido à medida que este cresce. Em qualquer dos casos, o limite de quantas pessoas uma única máquina consegue atender em simultâneo depende do tamanho da cache KV, do custo do prefill e da profundidade da fila. É por isso que um servidor que funcionava bem para uma pessoa fica lento com cinco.

Instalar e servir com Ollama

curl -fsSL https://ollama.com/install.sh | sh
ollama pull llama3.1:8b
ollama run --verbose llama3.1:8b "Write two sentences about Linux."

O script de instalação cria um utilizador de sistema ollama, instala o binário e regista ollama.service associado a 127.0.0.1:11434. A linha eval rate apresentada por --verbose indica os tokens por segundo reais nessa máquina. Confie nesse valor em vez de qualquer valor publicado. Uma medição com um único prompt é um ponto de partida, não uma medida de capacidade. Por isso, medir os tokens por segundo durante um teste com vários níveis de concorrência permite saber se a máquina suporta a carga esperada e se alugar uma GPU é mais vantajoso do que pagar por token.

Para aumentar a concorrência, use um drop-in do systemd. Assim, uma atualização não substitui a alteração:

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_NUM_PARALLEL=4"
Environment="OLLAMA_KEEP_ALIVE=30m"

sudo systemctl restart ollama
ollama ps

ollama ps mostra o que está carregado, e a coluna PROCESSOR indica a situação real. 100% CPU significa que não há nenhuma GPU envolvida. Essa é a explicação correta para a maioria dos casos em que o Ollama está lento. A linha OLLAMA_KEEP_ALIVE=30m nesse drop-in é igualmente importante numa máquina com pouca carga, porque a configuração predefinida descarrega o modelo após cinco minutos sem pedidos. Manter o modelo residente entre pedidos evita que o primeiro prompt depois de uma hora de inatividade volte a pagar todo o tempo de carregamento.

Instale e sirva com vLLM

O vLLM requer Linux e Python 3.10 a 3.13. Instale-o no seu próprio ambiente virtual, porque ele instala uma compilação específica do PyTorch:

uv venv --python 3.12 --seed
source .venv/bin/activate
uv pip install vllm --torch-backend=auto

Depois, sirva um modelo. O nome é um ID de repositório do Hugging Face, não uma tag curta:

vllm serve Qwen/Qwen2.5-1.5B-Instruct

A inicialização é lenta na primeira vez, porque o vLLM descarrega os pesos e depois cria um perfil da GPU para determinar quantos blocos de cache KV cabem. O serviço escuta na porta 8000. Verifique-o antes de escrever código cliente:

curl http://localhost:8000/v1/models
curl http://localhost:8000/v1/chat/completions \
    -H "Content-Type: application/json" \
    -d '{"model": "Qwen/Qwen2.5-1.5B-Instruct", "messages": [{"role": "user", "content": "Who won the world series in 2020?"}]}'

Se o Docker já estiver instalado no servidor, a imagem oficial evita o trabalho de configurar a dependência CUDA:

docker run --runtime nvidia --gpus all \
    -v ~/.cache/huggingface:/root/.cache/huggingface \
    --env "HF_TOKEN=$HF_TOKEN" \
    -p 8000:8000 \
    --ipc=host \
    vllm/vllm-openai:latest \
    --model Qwen/Qwen3-0.6B

--ipc=host é necessário, não é decorativo: o PyTorch passa tensores entre processos através da memória partilhada, e a alocação predefinida de memória partilhada do Docker é demasiado pequena para inferência com paralelismo de tensores.

As flags mais importantes em produção são --max-model-len (a janela de contexto pela qual está disposto a pagar), --gpu-memory-utilization (a fração da GPU que o vLLM pode utilizar, 0.92 por predefinição em julho de 2026), --tensor-parallel-size para dividir um modelo por várias GPUs e --api-key.

Autenticação é uma opção no vLLM e está ausente no Ollama

O vLLM exige um token bearer se você fornecer um:

vllm serve Qwen/Qwen2.5-1.5B-Instruct --api-key token-abc123

O mesmo valor pode vir da variável de ambiente VLLM_API_KEY. Uma solicitação sem esse token recebe HTTP 401. Isso ainda não é motivo para publicar a porta 8000 em uma interface pública, porque o vLLM não tem limitação de taxa e um token transmitido por HTTP simples pode ser lido em trânsito. Mas isso significa que o servidor tem um conceito de chamador.

O Ollama não tem nada disso. Não existe chave, login ou lista de permissões. Qualquer processo que consiga acessar 11434 pode executar, baixar ou excluir modelos. Mantenha-o no loopback e acesse-o por uma VPN WireGuard hospedada por você, ou por um reverse proxy com autenticação que faça a terminação TLS (transport layer security).

Hardware: o que cada um precisa

Ollama funciona com CPU. Um modelo quantizado para 4 bits consome aproximadamente meio gigabyte de RAM por mil milhões de parâmetros, além de cerca de um gigabyte de overhead de execução e mais memória para o contexto. Assim, um modelo 3B precisa de cerca de 4 GB livres e um modelo 8B de cerca de 8 GB. A velocidade numa vCPU partilhada fica entre um e poucos tokens por segundo e valores baixos de dois dígitos. Isto é uma limitação da largura de banda da memória, não uma configuração incorreta, e nenhum parâmetro a corrige. Para observar este cálculo numa versão específica, em vez de usar uma regra geral, executar o Nemotron 3.5 Lightning numa VPS fixa a tag exata a descarregar, a RAM ocupada depois de o modelo ser carregado e se a execução apenas com CPU é suficientemente rápida para ser aceitável.

vLLM pressupõe a utilização de uma GPU. Por predefinição, disponibiliza pesos sem quantização com precisão de 16 bits, o que corresponde aproximadamente a 2 GB por mil milhões de parâmetros: um modelo 8B precisa de cerca de 16 GB de memória de vídeo apenas para os pesos, antes da cache KV que permite a simultaneidade para a qual instalou o vLLM. Numa placa de 24 GB, isso deixa espaço suficiente para uma cache funcional. Numa placa de 16 GB, não deixa, pelo que terá de escolher um modelo mais pequeno ou passar --quantization com um checkpoint quantizado. Existe um backend para CPU, mas os wheels padrão não são compilados para esse backend e a sua utilização elimina a razão principal para executar o vLLM.

Por isso, na maioria dos casos, a questão do hardware responde à questão do software. Sem GPU, use Ollama. Uma GPU alugada que permanece com 5 por cento de utilização porque os pedidos estão a ser serializados indica que deve usar vLLM.

Qual escolher para a sua carga de trabalho

• Uma pessoa, um VPS com CPU, para redigir e resumir: Ollama. O ritmo é aceitável e não há nada mais simples.
• Um assistente de programação ou um servidor MCP que liga as suas ferramentas a um modelo local, utilizado apenas por si: Ollama. A concorrência de uma ligação é a carga de trabalho real.
• Comparar cinco modelos esta semana: Ollama. Transferir e eliminar modelos identificados por tags é precisamente aquilo em que se destaca, enquanto o vLLM precisa de reiniciar o processo para cada modelo.
• Uma aplicação interna, um produto de chat ou um pipeline de recuperação com utilizadores reais: vLLM. É aqui que o batching justifica o custo da GPU.
• Um job em lote que avalia cem mil documentos durante a noite: vLLM, com um --max-num-seqs elevado. O throughput é a única métrica relevante, e a latência por documento não é.
• Uma plataforma de agentes em que vários agentes de IA autoalojados acedem ao modelo ao mesmo tempo: vLLM, porque o tráfego dos agentes é intermitente e, por natureza, paralelo.

Modos de falha e as mensagens apresentadas

O vLLM recusa iniciar com um erro de cache KV. A mensagem apresenta os dois números:

ValueError: The model's max seq len (32768) is larger than the maximum number of tokens that can be stored in KV cache (8192). Try increasing gpu_memory_utilization or decreasing max_model_len when initializing the engine.

O modelo declara uma janela de contexto maior do que a memória disponível depois de carregar os pesos. Reduza-a com --max-model-len 8192 ou aumente --gpu-memory-utilization se nenhum outro processo estiver a utilizar a GPU. Ultrapassar uma utilização de cerca de 0.95 tende a trocar este erro de arranque por uma falha posterior de falta de memória CUDA, sob carga. Esta segunda situação é pior.

O Ollama apresenta Killed durante a geração. O killer de falta de memória do Linux parou o processo porque o modelo precisava de mais RAM do que o servidor tem. Confirme com sudo dmesg | grep -i oom. A correção é utilizar um modelo menor ou com uma quantização mais agressiva, não alterar uma definição.

O Ollama responde corretamente sozinho, mas fica bloqueado sob carga. Não aparece nenhum erro. Os pedidos demoram simplesmente mais tempo à medida que aumenta o número de clientes, porque OLLAMA_NUM_PARALLEL=1 os serializa. Respostas longas agravam a fila. Um cliente que ocupa o único slot até o modelo decidir parar bloqueia todos os pedidos seguintes. Por isso, limitar a resposta com num_predict define um limite para o tempo durante o qual cada pedido pode ocupar o servidor. Aumente a definição de execução paralela e aceite um contexto menor por pedido, ou transfira a carga para o vLLM.

O vLLM devolve 401 em todas as chamadas. Iniciou-o com --api-key, mas o cliente não envia o cabeçalho Authorization. A maioria das bibliotecas de cliente OpenAI envia como chave o valor que lhes é fornecido. Defina-a no cliente em vez de remover a flag.

O vLLM indica que o modelo não foi encontrado. O Ollama faz o pull conforme necessário; o vLLM não. O campo model no corpo do pedido tem de corresponder ao ID do repositório com que iniciou o serviço ou ao valor de --served-model-name, se tiver definido um. Confirme a string exata com curl http://localhost:8000/v1/models.

Executar ambos é uma resposta razoável

Eles não são mutuamente exclusivos. Uma arquitetura comum usa vLLM numa instância com GPU para servir a aplicação, e Ollama no VPS comum ao lado para scripts locais, tarefas cron e testes de novas versões de modelos. Ambos os endpoints são compatíveis com a API da OpenAI, por isso uma biblioteca cliente e a alteração da URL base são suficientes para alternar entre eles. O controlo de custos é mais importante neste caso do que a escolha de qualquer um dos motores, porque uma GPU parada tem o mesmo custo de uma GPU ocupada, e manter previsíveis os custos dos agentes e da inferência é uma disciplina diferente da escolha do servidor.

FAQ

O vLLM é mais rápido do que o Ollama?

Para um único pedido na mesma GPU, a diferença é pequena, porque ambos fazem os mesmos cálculos. Para muitos pedidos simultâneos, o vLLM é muito mais rápido, porque o continuous batching descodifica todas as sequências ativas numa única passagem forward, enquanto a configuração predefinida do Ollama as processa uma após outra. Numa máquina apenas com CPU, a questão não se aplica: o Ollama funciona nesse ambiente, mas o vLLM, na prática, não.

O vLLM funciona sem uma GPU?

Não de forma útil. Os wheels padrão destinam-se a GPUs NVIDIA ou AMD, e a razão de existir do vLLM, manter um acelerador ocupado com pedidos agrupados, desaparece numa CPU. Existe um backend de CPU para desenvolvimento. Para inferência real em CPU, use o Ollama ou o llama.cpp diretamente.

Qual é a diferença entre o Ollama e o llama.cpp?

O llama.cpp é a biblioteca de inferência, e o GGUF é o seu formato de pesos quantizados. O runner do Ollama é baseado nele e acrescenta as partes que o llama.cpp deixa a cargo do utilizador: um registo de modelos, descarregamento automático, um servidor residente, uma unidade systemd e um endpoint compatível com OpenAI. O Ollama adicionou o seu próprio engine para algumas famílias de modelos mais recentes, por isso os dois já não são internamente idênticos.

De quanta memória GPU o vLLM precisa para um modelo 8B?

Com precisão de 16 bits, só os pesos ocupam cerca de 16 GB, aproximadamente 2 GB por cada mil milhões de parâmetros, e é necessário reservar espaço adicional para a cache KV. Uma placa de 24 GB oferece margem suficiente. Uma placa de 16 GB exige um checkpoint quantizado ou um modelo mais pequeno. O vLLM usa a fração da memória da placa definida por --gpu-memory-utilization, que, em julho de 2026, tem o valor predefinido de 0.92.

Tenho de alterar o código da aplicação para mudar entre os dois?

Normalmente, apenas o URL base, a chave da API e o nome do modelo. O Ollama disponibiliza a sua interface compatível com OpenAI em http://127.0.0.1:11434/v1 e ignora a chave, enquanto o vLLM disponibiliza http://localhost:8000/v1 e exige a chave se configurar uma. Os nomes dos modelos têm formatos diferentes: llama3.1:8b no Ollama e um id completo de repositório, como Qwen/Qwen2.5-1.5B-Instruct, no vLLM.