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, um prompt de chat, um serviço systemd e uma API HTTP a partir de um único comando de instalação. A maioria dos modelos que serve 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 reduz a memória necessária para a inferência no CPU. Em Macs com Apple Silicon, também pode executar modelos baseados em safetensors através de um motor MLX. Desde a v0.40.0 (setembro de 2026), as arquiteturas suportadas são executadas automaticamente em MLX.

O executor GGUF é baseado no llama.cpp, a biblioteca de inferência C++ que tornou prática a quantização GGUF em hardware comum. Em outubro de 2026, o Ollama suporta dois motores: llama.cpp e MLX. As compilações para Linux também suportam inferência MLX com CUDA. O guia de desenvolvimento ativa esse backend com cmake -B build . -DOLLAMA_MLX_BACKENDS=cuda_v13, com CUDA 13+ e cuDNN 9+ como pré-requisitos. Por isso, quando as pessoas comparam o Ollama com o llama.cpp, estão sobretudo a comparar uma camada de ergonomia com a tecnologia que ela encapsula.

O objetivo de conceção é um utilizador. Em outubro 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 aguardam numa fila com 512 entradas por predefinição (OLLAMA_MAX_QUEUE). Pode aumentar a definição de paralelismo. 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 local não requer autenticação.

O que o vLLM realmente é

vLLM é um servidor de inferência e nada mais. Ele não gere uma biblioteca de modelos, fornece um cliente vllm chat para um servidor em execução e não baixa um modelo para você no momento da solicitação. Você informa um repositório do Hugging Face ao iniciar o processo, ele carrega esse modelo e o disponibiliza até você parar o processo.

O que você obtém com essa especialização é throughput. Dois mecanismos fazem o trabalho. PagedAttention armazena o cache KV (cache key-value, o estado de atenção por token que um modelo mantém para cada solicitação ativa) em blocos de tamanho fixo, como um sistema operacional pagina a memória. Uma solicitação já não precisa de uma única reserva contígua grande, dimensionada para o pior caso. Assim, a memória que antes ficava reservada e sem uso fica disponível para mais solicitações simultâneas. O Continuous batching permite que uma nova solicitação entre no lote em execução na próxima etapa de decodificação, em vez de esperar o lote atual terminar. Quando uma sequência termina, ela sai imediatamente do lote e o seu espaço é preenchido novamente.

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

O batching contínuo é a diferença decisiva

Imagine cinco pedidos a chegar a cada servidor ao mesmo tempo, em hardware idêntico.

Com as definições predefinidas, o Ollama executa o primeiro pedido até ao fim, depois o segundo, e assim por diante. O quinto cliente espera por quatro gerações completas. O débito total é aproximadamente a velocidade de uma 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 facto relativo à largura de banda da memória que torna a inferência em CPU lenta: o custo principal está em mover os pesos, não nos cálculos.

Pode definir OLLAMA_NUM_PARALLEL=4 e obter parte deste comportamento. O custo é a memória. Cada slot paralelo precisa da sua própria cache KV, e o Ollama multiplica a alocação de contexto em vez de a dividir: a sua FAQ indica que a RAM necessária aumenta por OLLAMA_NUM_PARALLEL vezes OLLAMA_CONTEXT_LENGTH. Assim, quatro pedidos paralelos para um modelo configurado para 8192 tokens mantêm 8192 tokens cada, mas o servidor tem de guardar cache para 32768 tokens no total. 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 cabem. A cache paginada do vLLM evita reservar antecipadamente a janela completa para cada slot, porque os blocos são alocados a um pedido à medida que este cresce. Em qualquer dos casos, o limite de quantas pessoas um único servidor 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 parecia suficiente para uma pessoa fica lento com cinco.

Instale e disponibilize 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 a velocidade real, em tokens por segundo, nesse servidor. Dê-lhe prioridade sobre qualquer valor publicado. Uma leitura obtida com um único prompt é um ponto de partida, não uma medida de capacidade. Por isso, medir os tokens por segundo durante uma variação de concorrência mostra se o servidor aguenta 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, 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 indica a situação real. 100% CPU significa que não há 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 num servidor com pouca atividade, 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 um período de inatividade, que pode durar até meia hora, volte a pagar todo o tempo de carregamento. Se os seus períodos de inatividade forem mais longos, defina um valor maior.

Instalar e servir com vLLM

As builds de vLLM para GPU precisam de Linux (macOS em Apple Silicon tem suporte apenas para CPU com um wheel pré-compilado na release 0.32.0, e a aceleração GPU nesses Macs é fornecida pelo vLLM-Metal, um plugin separado mantido pela comunidade e baseado em MLX). No Python, a release atual (0.32.0, outubro de 2026) aceita as versões 3.11 a 3.14, e o guia de instalação indica o mesmo intervalo. O suporte para Python 3.10 foi removido na versão 0.32.0, portanto 3.12, utilizada abaixo, é a opção segura. Instale-o no seu próprio ambiente virtual, porque ele instala uma build específica do PyTorch:

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

A última linha consta do guia de instalação NVIDIA do vLLM em outubro de 2026. Ela instala os kernels pré-compilados do FlashInfer. Sem eles, o vLLM descarrega e compila os kernels no arranque, o que, segundo o guia, pode acrescentar vários minutos em GPUs Hopper e mais recentes. Execute-a novamente depois de cada atualização do vLLM, porque o FlashInfer recusa-se a importar quando os kernels não correspondem.

Depois, sirva um modelo. O nome é um repository id do Hugging Face, não uma tag curta:

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

O primeiro arranque é lento, porque 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 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 as dependências 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 dá ao contentor acesso à memória partilhada do host; aumentar --shm-size é outra opção. O PyTorch transfere tensores entre processos através da memória partilhada, sobretudo na inferência com paralelismo de tensores.

Os 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 placa que o vLLM pode utilizar, 0.92 por predefinição em outubro de 2026), --tensor-parallel-size para distribuir um modelo por várias GPUs e --api-key.

A autenticação é uma flag no vLLM e está ausente na API local do Ollama

O vLLM exige um token bearer se lhe fornecer um:

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

O mesmo valor pode ser obtido da variável de ambiente VLLM_API_KEY. Um pedido para /v1 sem esse valor recebe HTTP 401. No entanto, a chave não protege todo o servidor. O guia de segurança do vLLM e o código de autenticação do código-fonte da versão 0.32.0 aplicam-na apenas aos endpoints sob os prefixos de caminho /v1, /v2, /inference e /cohere. O texto de ajuda de --api-key na página vllm serve lista apenas os três primeiros, mas o código verifica os quatro. Tanto o guia como o texto de ajuda indicam que os outros endpoints, sobretudo /invocations, que expõe a mesma inferência que /v1, não são autenticados. Isso é motivo suficiente para não publicar a porta 8000 numa interface pública. O guia de segurança do vLLM também deixa o controlo de limites de pedidos a cargo de um reverse proxy colocado à sua frente. Além disso, um token enviado por HTTP simples pode ser lido durante o trânsito. Ainda assim, a flag significa que o servidor tem um conceito de cliente.

A API local do Ollama não requer autenticação. Os modelos na cloud, a publicação de modelos e as transferências privadas de modelos requerem início de sessão. O acesso direto à API de ollama.com requer uma chave de API. Qualquer processo que consiga alcançar a porta 11434 pode executar, transferir ou eliminar modelos. Mantenha-a em loopback e aceda-lhe através de uma VPN WireGuard alojada por si, ou através de um reverse proxy com autenticação que termine o TLS (transport layer security).

Hardware: o que cada um exige

Ollama usa a CPU. Um modelo quantizado para 4 bits consome aproximadamente meio gigabyte de RAM por cada mil milhões de parâmetros, além de cerca de um gigabyte de sobrecarga do runtime e de 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 dígito e as dezenas baixas de tokens por segundo. Isto é uma limitação da largura de banda da memória, não uma configuração incorreta, e nenhum flag a corrige. Para observar estes cálculos 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 obter, a RAM ocupada depois do carregamento e se o modo apenas com CPU é suficientemente rápido para utilização diária.

vLLM pressupõe uma GPU. Por predefinição, serve pesos não quantizados com precisão de 16 bits, o que corresponde aproximadamente a 2 GB por cada 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 fornece a simultaneidade para a qual instalou o vLLM. Numa placa de 24 GB, resta espaço suficiente para uma cache utilizável. Numa placa de 16 GB, não resta, por isso deve escolher um modelo mais pequeno, passar --quantization (com um checkpoint quantizado ou para quantizar os pesos de precisão total durante o carregamento) ou transferir parte dos pesos para a RAM do sistema com --cpu-offload-gb. Esta última opção mantém a precisão dos pesos, mas é mais lenta, porque os pesos atravessam para a GPU em cada passagem forward. Existe um backend de CPU, com wheels próprias e separadas, mas ele elimina a razão para executar vLLM.

Por isso, na maioria dos casos, a questão do hardware responde à questão do software. Sem GPU, use Ollama. Uma GPU alugada 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 que irá ver

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

ValueError: To serve at least one request with the model's max seq len (32768), (4.00 GiB KV cache is needed, which is larger than the available KV cache memory (1.00 GiB). Based on the available memory, the estimated maximum model length is 8192. Try increasing `gpu_memory_utilization` (which also controls CPU memory on the CPU backend) or decreasing `max_model_len` when initializing the engine. See https://docs.vllm.ai/en/latest/configuration/conserving_memory/ for more details.

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 nada mais estiver a utilizar a placa.

O Ollama apresenta Killed durante a geração. O mecanismo de encerramento por falta de memória do Linux parou o processo porque o modelo precisava de mais RAM do que o sistema tem. Confirme com sudo dmesg | grep -i oom. A correção é usar um modelo menor ou mais fortemente quantizado, não alterar uma definição.

O Ollama responde corretamente sozinho, mas fica bloqueado sob carga. Não aparece nenhum erro. Os pedidos simplesmente demoram mais à medida que aumenta o número de clientes, porque OLLAMA_NUM_PARALLEL=1 os serializa. As respostas longas agravam a fila, porque um cliente que ocupa a única posição até o modelo decidir parar bloqueia todos os seguintes. Por isso, limitar a resposta com num_predict estabelece um limite para o tempo que cada interação pode ocupar o servidor. Aumente a definição de paralelismo e aceite a RAM adicional consumida pelo contexto de cada posição, ou transfira a carga de trabalho para o vLLM.

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

O vLLM indica que o modelo não foi encontrado. O Ollama transfere modelos quando 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 essa variável. 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 que o Ollama?

Para uma única solicitação na mesma GPU, a diferença é pequena, pois ambos fazem os mesmos cálculos. Para muitas solicitações simultâneas, o vLLM é muito superior, porque o continuous batching decodifica todas as sequências ativas em uma única passagem forward, enquanto a configuração padrão do Ollama executa cada uma em sequência. Em uma máquina somente com CPU, ambos têm caminhos de inferência compatíveis, e o vLLM usa wheels separadas para CPU.

O vLLM pode funcionar sem uma GPU?

Sim, por meio do seu backend de CPU. As wheels padrão são voltadas para GPUs NVIDIA ou AMD, e o motivo de existir do vLLM — manter um acelerador ocupado com solicitações agrupadas — deixa de existir em uma CPU. Existe um backend de CPU, com wheels separadas para x86 e Arm. 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 é o formato quantizado dos pesos. O Ollama usa o llama.cpp para inferência com GGUF e adiciona um registro de modelos, downloads com tags, gerenciamento de modelos e uma unidade systemd. O Ollama também inclui um mecanismo MLX que executa modelos baseados em safetensors no Apple Silicon e oferece builds CUDA no Linux, portanto os dois nem sempre são idênticos internamente.

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

Com precisão de 16-bit, apenas 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 modelo quantizado, um modelo menor ou --cpu-offload-gb para mover parte dos pesos para a RAM do sistema, com perda de velocidade. O vLLM reserva a fração da memória da placa definida por --gpu-memory-utilization, que assume o valor padrão 0.92 em outubro de 2026.

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

Normalmente, basta alterar 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 nas rotas /v1 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.