Ollama vs vLLM: qual servidor LLM usar

Ollama vs vLLM, em um parágrafo

Ollama é um gerenciador de modelos com um servidor integrado: ele baixa pesos quantizados, carrega-os e responde em 127.0.0.1:11434, usando uma CPU se for tudo o que a máquina tiver. vLLM é um mecanismo de throughput: mantém uma GPU saturada com muitas solicitações executadas ao mesmo tempo e é a ferramenta errada em uma máquina sem GPU. Essa é toda a decisão. Uma pessoa conversando com um assistente local é um trabalho para Ollama. Um aplicativo atendendo uma equipe é um trabalho para vLLM.

Ambos oferecem uma API HTTP compatível com OpenAI, portanto o código do cliente pode ser alternado entre eles alterando a URL base. A API não é a diferença. A diferença está no que acontece quando uma segunda solicitação chega enquanto a primeira ainda está gerando tokens.

O que o Ollama realmente é

O Ollama é uma camada de conveniência. Ele fornece um registro de modelos (ollama pull llama3.1:8b), um armazenamento local de pesos, um prompt de chat, um serviço systemd e uma API HTTP com um único comando de instalação. Os modelos que ele disponibiliza são arquivos GGUF, geralmente 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 a inferência em CPU possível.

Seu executor é baseado no llama.cpp, a biblioteca de inferência em C++ que tornou prática a quantização GGUF em hardware comum. Desde então, o Ollama adicionou seu próprio mecanismo para algumas famílias de modelos mais recentes, mas o llama.cpp ainda é a base da maior parte do que ele disponibiliza. Portanto, quando as pessoas comparam o Ollama com o llama.cpp, na prática estão comparando uma camada de ergonomia com o componente que ela encapsula.

O objetivo do design é atender um usuário. Em julho de 2026, o valor padrão de OLLAMA_NUM_PARALLEL é 1. Isso significa que um modelo processa uma solicitação por vez, enquanto todas as outras aguardam em uma fila que contém 512 entradas por padrão (OLLAMA_MAX_QUEUE). Você pode aumentar a configuração de paralelismo, e a seção abaixo explica o custo disso. Se você ainda não executou o Ollama, comece por hospedar o Ollama em uma VPS e manter a porta 11434 fechada, pois a API não tem nenhum tipo de autenticação.

O que o vLLM realmente é

O vLLM é um servidor de inferência, e nada mais. Ele não gerencia uma biblioteca de modelos, não tem um prompt de chat e não baixa um modelo para você no momento da solicitação. Você informa um repositório do Hugging Face ao iniciar o servidor, ele carrega esse modelo e o disponibiliza até você interromper o processo.

O que você obtém com essa especialização é throughput. Dois mecanismos fazem esse trabalho. PagedAttention armazena o cache KV (cache de chave-valor, o estado de atenção por token que o modelo mantém para cada solicitação ativa) em blocos de tamanho fixo, como um sistema operacional pagina a memória. Uma solicitação deixa de precisar de uma grande reserva contígua dimensionada para o pior caso. Assim, a memória que antes permanecia reservada e sem uso fica disponível para mais solicitações simultâneas. O continuous batching permite que uma nova solicitação entre no batch em execução na próxima etapa de decodificação, em vez de esperar o batch atual terminar. Uma sequência concluída deixa o batch imediatamente, e seu slot é preenchido novamente.

O resultado prático: em uma única GPU, passar de um usuário simultâneo para trinta aumenta bastante o total de tokens por segundo, enquanto a velocidade por usuário cai muito menos do que seria esperado. Com o padrão do Ollama, passar de um usuário para trinta apenas faz vinte e nove pessoas esperarem.

O batching contínuo é toda a diferença

Considere cinco solicitações chegando a cada servidor ao mesmo tempo, em hardware idêntico.

Com as configurações padrão, o Ollama executa a primeira solicitação até a conclusão, depois a segunda e assim por diante. O quinto solicitante espera quatro gerações completas. A capacidade total de processamento é aproximadamente a velocidade de uma geração, porque o processador trabalha apenas em uma sequência por vez.

O vLLM decodifica as cinco no mesmo forward pass. Gerar um token para cinco sequências custa pouco mais do que gerar um token para uma sequência, porque a parte mais dispendiosa é ler os pesos do modelo da memória, e essa leitura é compartilhada por todo o batch. Esse é o mesmo fato sobre a largura de banda da memória que torna a inferência em CPU lenta: o custo está em mover os pesos, não na operação aritmética.

Você pode configurar OLLAMA_NUM_PARALLEL=4 e obter parte desse comportamento. O custo é memória. Cada slot paralelo precisa de seu próprio cache KV, e o Ollama divide a janela de contexto entre os slots. Assim, quatro solicitações paralelas para um modelo configurado para 8192 tokens deixam 2048 tokens de contexto para cada solicitação. O cache paginado do vLLM evita essa troca, porque os blocos são alocados para uma solicitação conforme ela realmente cresce.

Instalar e disponibilizar 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 usuário do sistema ollama, instala o binário e registra ollama.service vinculado a 127.0.0.1:11434. A linha eval rate exibida por --verbose mostra a quantidade real de tokens por segundo nesse servidor. Confie nesse valor, não em números publicados.

Para aumentar a simultaneidade, use um drop-in do systemd para que uma atualização não substitua 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 informa o valor real. 100% CPU significa que nenhuma GPU está envolvida. Essa é a explicação correta para a maioria dos relatos de que o Ollama está lento.

Instalar e disponibilizar com vLLM

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

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

Em seguida, disponibilize 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 sistema baixa 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 qualquer código de 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 do 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 é obrigatório, não meramente decorativo: o PyTorch transfere tensores entre processos por meio da memória compartilhada, e a alocação padrão de memória compartilhada do Docker é pequena demais para inferência com paralelismo de tensores.

Os parâmetros mais importantes em produção são --max-model-len (a janela de contexto que você aceita pagar), --gpu-memory-utilization (a fração da placa que o vLLM pode usar, 0.92 por padrão em julho de 2026), --tensor-parallel-size para dividir um modelo entre várias GPUs e --api-key.

A autenticação é uma flag no vLLM e está ausente no Ollama

O vLLM exige um bearer token 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 justifica publicar a porta 8000 em uma interface pública, porque o vLLM não tem limitação de taxa e um token HTTP simples pode ser lido durante o trânsito. No entanto, isso significa que o servidor tem um conceito de chamador.

O Ollama não tem nenhum mecanismo de autenticação. Não há chave, login nem lista de permissões. Qualquer processo que consiga acessar a porta 11434 pode executar, baixar ou excluir modelos. Mantenha o serviço no loopback e acesse-o por meio de uma VPN WireGuard hospedada por você, ou por meio de um proxy reverso com autenticação que encerre o TLS (segurança da camada de transporte).

Hardware: o que cada um exige

Ollama é executado na CPU. Um modelo quantizado em 4 bits consome aproximadamente meio gigabyte de RAM por bilhão de parâmetros, além de cerca de um gigabyte de sobrecarga de execução e de mais memória para o contexto. Portanto, um modelo 3B precisa de cerca de 4 GB livres, e um modelo 8B, de cerca de 8 GB. A velocidade em uma vCPU compartilhada fica entre um dígito e os baixos dois dígitos de tokens por segundo. Isso é uma limitação da largura de banda da memória, não uma configuração incorreta, e nenhuma flag corrige esse problema.

vLLM pressupõe o uso de uma GPU. O caminho padrão fornece pesos não quantizados com precisão de 16 bits, o que corresponde a aproximadamente 2 GB por bilhão de parâmetros. Um modelo 8B precisa de cerca de 16 GB de memória de vídeo apenas para os pesos, antes do cache KV que fornece a concorrência para a qual você instalou o vLLM. Em uma placa de 24 GB, isso deixa espaço suficiente para um cache utilizável. Em uma placa de 16 GB, não deixa. Nesse caso, você precisa escolher um modelo menor ou passar --quantization com um checkpoint quantizado. Existe um backend para CPU, mas os wheels padrão não são compilados para ele, e seu uso elimina o motivo para executar o vLLM.

Portanto, na maior parte dos casos, a pergunta sobre o hardware responde à pergunta sobre o software. Sem GPU, use o Ollama. Uma GPU alugada operando a 5 por cento de utilização porque as solicitações estão sendo serializadas é um caso para usar o vLLM.

Qual é a opção para sua carga de trabalho

• Uma pessoa usando uma VPS com CPU para redigir e resumir: Ollama. O ritmo é aceitável e nada é mais simples.
• Um assistente de programação ou um servidor MCP que conecta suas ferramentas a um modelo local, usado somente por você: Ollama. A concorrência de um é a carga de trabalho real.
• Comparar cinco modelos nesta semana: Ollama. Baixar e excluir modelos identificados por tags é exatamente o que ele faz bem, enquanto o vLLM exige reiniciar o processo para cada modelo.
• Um aplicativo interno, um produto de chat ou um pipeline de recuperação com usuários reais: vLLM. É nesse cenário 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 alto. A vazão é a única métrica relevante, e a latência por documento não é.
• Uma plataforma de agentes na qual vários agentes de IA auto-hospedados acessam o modelo ao mesmo tempo: vLLM, porque o tráfego dos agentes ocorre em rajadas e é paralelo por natureza.

Modos de falha, com as mensagens que você verá

O vLLM se recusa a iniciar com um erro de cache KV. A mensagem informa 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 que a memória disponível após o carregamento dos pesos. Reduza esse valor com --max-model-len 8192 ou aumente --gpu-memory-utilization se nenhum outro processo estiver usando a placa. Aumentar a utilização além de aproximadamente 0.95 tende a trocar esse erro de inicialização por uma falha de falta de memória da CUDA mais tarde, sob carga, o que é pior.

O Ollama exibe Killed durante a geração. O mecanismo de encerramento por falta de memória do Linux interrompeu o processo porque o modelo precisava de mais RAM do que o servidor possui. Confirme com sudo dmesg | grep -i oom. A correção é usar um modelo menor ou com quantização mais agressiva, não alterar uma configuração.

O Ollama responde normalmente sozinho, mas trava sob carga. Nenhum erro aparece. As solicitações simplesmente demoram mais à medida que há mais clientes, porque OLLAMA_NUM_PARALLEL=1 as serializa. Aumente esse valor e aceite um contexto menor por solicitação, ou mova a carga de trabalho para o vLLM.

O vLLM retorna 401 em todas as chamadas. Você o iniciou com --api-key, mas o cliente não envia o cabeçalho Authorization. A maioria das bibliotecas de cliente OpenAI envia o valor que você informar como chave. Portanto, defina a chave no cliente em vez de remover a opção.

O vLLM informa que o modelo não foi encontrado. O Ollama baixa modelos sob demanda, mas o vLLM não. O campo model no corpo da solicitação deve corresponder ao ID do repositório usado na inicialização ou ao valor de --served-model-name, se você tiver definido esse valor. 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 configuração comum usa o vLLM em uma instância com GPU para atender à aplicação, enquanto o Ollama fica no VPS comum ao lado, para scripts locais, tarefas do cron e testes de novos lançamentos de modelos. Ambos os endpoints são compatíveis com a API da OpenAI, portanto uma única biblioteca cliente e uma alteração na URL base são suficientes. O controle de custos é mais importante aqui do que qualquer um dos mecanismos, porque uma GPU ociosa custa o mesmo que uma GPU ocupada, e manter previsíveis os custos de agentes e inferência é uma disciplina separada da escolha do servidor.

FAQ

O vLLM é mais rápido que o Ollama?

Para uma única solicitação na mesma GPU, a diferença é modesta, pois ambos executam os mesmos cálculos. Para muitas solicitações simultâneas, o vLLM é muito mais rápido, pois o continuous batching decodifica cada sequência ativa em uma única passagem forward, enquanto a configuração padrão do Ollama as executa uma após a outra. Em uma máquina somente com CPU, a pergunta não se aplica: o Ollama é executado nesse ambiente, mas o vLLM praticamente não.

O vLLM pode ser executado sem uma GPU?

Não de forma útil. Os wheels padrão são destinados a GPUs NVIDIA ou AMD, e a razão de existir do vLLM — manter um acelerador ocupado com solicitações agrupadas — desaparece em uma CPU. Existe um backend de CPU para desenvolvimento. Para inferência real em CPU, use Ollama ou llama.cpp diretamente.

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

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

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

Com precisão de 16 bits, somente os pesos ocupam cerca de 16 GB, aproximadamente 2 GB por bilhão de parâmetros, e o cache KV precisa de espaço adicional. Uma placa de 24 GB oferece uma margem confortável. Uma placa de 16 GB exige um checkpoint quantizado ou um modelo menor. O vLLM reserva uma fração da memória da placa definida por --gpu-memory-utilization, que, em julho de 2026, tem o valor padrão 0.92.

Preciso alterar o código da aplicação para alternar entre eles?

Normalmente, apenas a URL base, a chave de API e o nome do modelo. O Ollama disponibiliza 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 você definir uma. Os nomes dos modelos têm formatos diferentes: llama3.1:8b para o Ollama e um ID completo de repositório, como Qwen/Qwen2.5-1.5B-Instruct, para o vLLM.