vLLM vs Ollama: qual escolher para servir modelos de IA?

vLLM vs Ollama: qual escolher?

Continue com Ollama para um notebook, um assistente privado ou um pequeno serviço interno que já responde rápido o suficiente. Escolha vLLM para um serviço compartilhado de GPU com requisições simultâneas constantes, ou quando precisar de controle explícito sobre a inferência distribuída. Ter um hostname de servidor, por si só, não justifica a troca.

Ollama reúne download, configuração e disponibilização de modelos em um fluxo enxuto. vLLM é um motor de inferência voltado ao escalonamento de muitas requisições e ao gerenciamento da memória de trabalho delas. Nenhum dos dois é o modelo em si: migrar a mesma aplicação entre eles muda a forma como o modelo é executado.

A decisão depende de quatro fatores: o pico de requisições simultâneas, a memória de GPU disponível, o artefato exato do modelo e a latência prometida aos usuários. O total de usuários cadastrados diz pouco sobre isso. Uma pequena equipe de programação que usa agentes pode gerar mais trabalho simultâneo do que um grupo muito maior que faz perguntas de vez em quando.

Custo do software e documentação verificados em 12 de outubro de 2026. Esta comparação se baseia na documentação e em uma análise de custos com cálculos demonstrativos; nenhum benchmark de inferência foi executado para este artigo. A página de preços do Ollama inclui uso local gratuito, e a licença do projeto vLLM permite o uso sem cobrança pelo software. Preços do Ollama, licença do vLLM.

Os recursos da tabela seguem a documentação de requisições simultâneas do Ollama, a visão geral dos recursos do vLLM e o guia de escalabilidade do vLLM. As escolhas são avaliações editoriais dessas capacidades documentadas, não um ranking de velocidade medida.

Como decidir pelo número de usuários, pelas GPUs e pelo tamanho do modelo

Use os cenários abaixo para decidir o que avaliar primeiro, sem tratá-los como garantias de capacidade. Aqui, “usuários” são pessoas ou agentes que geram trabalho simultâneo; as faixas servem como exemplos de planejamento. Um modelo 8B tem aproximadamente oito bilhões de parâmetros, os valores numéricos armazenados que o definem.

O tamanho do modelo, sozinho, não basta para decidir qual GPU comprar. Em um cálculo idealizado, um modelo denso 8B com 4 bits por peso exige no mínimo 4 GB só para os pesos; um modelo 70B exige 35 GB. A conta é parâmetros × bits ÷ 8, em bytes decimais. Metadados de quantização, tensores de maior precisão, o ambiente de execução e a memória das conversas aumentam esse mínimo. Nenhum desses valores é uma recomendação de VRAM.

Por isso, “o modelo carregou” é um critério de aceitação fraco. A máquina pode acomodar os pesos e ainda ficar sem espaço para as conversas que os usuários mantêm abertas. Primeiro, escolha o checkpoint com o guia de modelos locais para programação; depois, dimensione a carga de inferência.

Instalação e hardware: Ollama leva vantagem na primeira máquina

Ollama leva vantagem quando a prioridade é colocar um modelo útil para rodar no hardware que você já tem. Os aplicativos para desktop e o fluxo por linha de comando reduzem as decisões de implantação. No Linux, o instalador documentado é:

curl -fsSL https://ollama.com/install.sh | sh
ollama run llama3.2

Use ollama serve se o servidor ainda não estiver em execução. O guia para Linux também documenta um serviço de inicialização; um serviço persistente é mais adequado do que deixar um terminal aberto para atender às requisições de outras pessoas.

Ollama oferece aceleração por GPU da Apple via Metal, suporte a determinados dispositivos AMD via ROCm, GPUs NVIDIA e outros dispositivos Windows/Linux via Vulkan. A página sobre NVIDIA atualmente exige capacidade de computação 5.0 ou superior, com requisitos de driver que variam para placas mais antigas. Confira a placa e o sistema operacional exatos na lista de hardware do Ollama.

vLLM leva vantagem quando a instalação é o primeiro passo de um ambiente gerenciado de inferência. O guia atual de início rápido para NVIDIA usa um ambiente Python isolado. Com uv instalado e um driver de GPU compatível, a sequência documentada é:

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

Esses comandos vêm da documentação e não foram executados para esta comparação. As instalações para AMD e Intel seguem instruções de backend diferentes. Guia de início rápido do vLLM.

A instalação do vLLM para NVIDIA exige Linux e capacidade de computação 7.5 ou superior. Essa opção não oferece suporte nativo ao Windows; a documentação orienta quem usa Windows a recorrer ao WSL. NVIDIA não é a única opção de hardware: o índice de instalação também cobre AMD ROCm, Intel XPU, alternativas para CPU e Apple Silicon por meio do plugin vLLM-Metal, mantido pela comunidade. Requisitos de GPU, índice de instalação.

A opção para Apple usa MLX e modelos otimizados para MLX. Ela deve ser avaliada como um backend próprio, sem presumir que se comportará como um servidor CUDA. Para um fluxo centrado no Mac, Ollama continua sendo a recomendação inicial mais simples. Se a escolha for principalmente sobre o ambiente de trabalho no desktop, consulte a comparação entre Ollama e LM Studio.

Desempenho de vLLM e Ollama: as requisições simultâneas fazem a diferença

vLLM é o ponto de partida mais indicado para requisições simultâneas constantes porque seus recursos documentados de escalonamento atendem diretamente a essa carga. Throughput, ou vazão, é o total de trabalho concluído ao longo do tempo. É diferente da rapidez com que uma resposta isolada aparece.

Entre os recursos do vLLM estão continuous batching, que incorpora trabalho conforme as requisições em execução avançam, e PagedAttention, que gerencia o cache de chaves e valores usado durante a geração de texto. Esse cache, geralmente chamado de KV cache, é a memória de trabalho do modelo para os tokens da conversa. Visão geral dos recursos do vLLM.

Chunked prefill divide a leitura de um prompt longo em partes menores, que podem compartilhar o tempo de processamento com a geração de respostas em andamento. O cache de prefixos reaproveita o processamento de trechos iniciais idênticos dos prompts, como um prompt de sistema repetido. Ele ajuda no processamento do prompt; não elimina o trabalho de gerar novos tokens de resposta. Escalonamento e ajustes, limites do cache de prefixos.

Ollama já aceita requisições paralelas

Ollama documenta o uso de requisições paralelas por modelo e de vários modelos carregados ao mesmo tempo, desde que haja memória. OLLAMA_NUM_PARALLEL controla o primeiro caso; OLLAMA_MAX_LOADED_MODELS, o segundo. OLLAMA_MAX_QUEUE limita o trabalho em espera, e um servidor sobrecarregado pode retornar HTTP 503. O FAQ atual informa que o valor padrão de requisições paralelas é 1. Configurações de requisições simultâneas do Ollama.

Para um pequeno assistente de suporte, permitir mais requisições simultâneas pode bastar. Mas aumentar a fila não aumenta a capacidade de processamento: pode apenas prolongar a espera dos clientes pelo primeiro token. Ajuste a configuração para cumprir a meta de resposta, não para aceitar a maior fila possível.

O contexto pode consumir a memória que você reservou para mais usuários

Defina o contexto explicitamente antes de comparar os motores. A página específica de contexto do Ollama descreve valores padrão que dependem da memória, enquanto o FAQ ainda informa um valor fixo. Essa divergência na documentação é mais um motivo para conferir as configurações efetivas, sem presumir que notebook e servidor estão iguais. ollama ps mostra o contexto carregado e a distribuição entre CPU e GPU. Orientações do Ollama sobre contexto.

Em uma configuração ilustrativa, quatro conversas paralelas de 8,192 tokens reservam capacidade para 32,768 tokens de contexto. Em comparação com uma conversa de 4,096, isso representa oito vezes a capacidade total de contexto, não oito vezes a RAM total do processo. Os pesos do modelo e outras alocações não crescem na mesma proporção. A documentação de requisições simultâneas do Ollama explica esse multiplicador de contexto.

vLLM também esbarra no limite de memória. Seu guia de ajustes alerta que a falta de espaço para o KV cache pode causar preempção e recomputação, prejudicando a latência. Reduzir o número de sequências simultâneas ou o limite de tokens por lote é uma saída; adicionar GPUs é outra. Um escalonador mais capaz não cria memória que a máquina não tem.

O sinal para migrar é o descumprimento da meta do serviço sob uma carga representativa do pico, mesmo depois de ajustes razoáveis. Registre o tempo até o primeiro token, o tempo de conclusão da resposta, as requisições bem-sucedidas, o crescimento da fila e os erros. Compare um percentil de cauda além da mediana, porque os usuários percebem os casos mais lentos. vLLM disponibiliza métricas de produção para apoiar esse trabalho.

Mantenha equivalentes a revisão do modelo, a precisão, o tamanho dos prompts, os limites de saída e o padrão de tráfego. Comparar um modelo pequeno e quantizado no Ollama com um checkpoint maior e de alta precisão no vLLM é comparar implantações, não medir isoladamente os motores.

Formatos quantizados: migrar também envolve o modelo

Ollama leva vantagem para quem já tem um pacote de modelo local funcionando; vLLM, para quem quer escolher um formato de inferência específico para o hardware. A quantização armazena os valores do modelo com precisão reduzida para diminuir a necessidade de memória. O formato do arquivo, o método de quantização e o backend de execução são questões distintas de compatibilidade.

Ollama documenta a importação de pesos em Safetensors e de modelos GGUF em arquivo único ou divididos em vários arquivos. GGUF é um formato de arquivo de modelo comum na inferência local; o guia atual do Ollama informa que a quantização de GGUF deve acontecer antes da importação, não durante ela. Separadamente, a API de criação cita nvfp4 como exemplo de quantização na importação. Isso não garante que todas as arquiteturas e GPUs aceitem essa opção. Guia de importação do Ollama, API de criação.

Ollama também lista f16, q8_0 e q4_0 para o KV cache. Essas são configurações do cache, não uma lista intercambiável de formatos dos pesos do modelo. O uso de cache quantizado exige Flash Attention. Documentação de cache do Ollama.

vLLM lista AWQ/GPTQ, FP8, INT8, INT4, MXFP4/MXFP8, NVFP4 e outras integrações de quantização. A matriz de suporte varia conforme a implementação e o hardware, portanto “aceita 4 bits” é uma informação insuficiente para orientar uma compra. Verifique a combinação exata de checkpoint e kernel. Documentação de quantização do vLLM, visão geral dos formatos.

Um tokenizador transforma texto nos IDs de tokens que o modelo entende. Mudar os pesos, o tokenizador, a formatação do chat ou a quantização pode alterar as respostas, as chamadas de ferramentas e o uso de memória. Reserve recursos para verificações de regressão mesmo que o nome da família do modelo continue igual.

Mellum2.1 mostra por que o formato de distribuição importa

O anúncio do Mellum2.1 pela JetBrains em 8 de outubro de 2026 ilustra o padrão de lançamento que prioriza servidores: o post dizia que as versões GGUF para Ollama, llama.cpp e LM Studio chegariam em breve. A página do modelo traz uma receita de inferência com vLLM, e as integrações de lançamento incluem vLLM e SGLang, outro servidor de inferência. Post de lançamento da JetBrains, página do lançamento.

Essa diferença de disponibilidade já diminuiu: o repositório oficial de GGUF da JetBrains contém arquivos quantizados para download, conforme a verificação de 12 de outubro. Não interprete o “em breve” do post de lançamento como a disponibilidade de hoje. A lição prática é conferir o artefato atual e a receita de inferência antes de trocar de motor só para usar um modelo novo. Arquivos GGUF oficiais.

Servidores compatíveis com OpenAI: mantenha o cliente e confira o contrato da API

Os dois documentam um servidor compatível com OpenAI, mas aceitar o mesmo formato de requisição não garante o mesmo comportamento. A URL base local do Ollama é http://localhost:11434/v1/; o exemplo do vLLM usa http://localhost:8000/v1. Se sua aplicação usa o endpoint nativo /api/chat do Ollama, a migração exige adaptar a API, não apenas trocar a porta. Compatibilidade do Ollama, documentação do servidor vLLM.

Por exemplo, após instalar vLLM em hardware compatível, este comando disponibiliza o modelo usado no exemplo documentado do servidor, com limite de contexto explícito e um nome para uso pela aplicação:

vllm serve NousResearch/Meta-Llama-3-8B-Instruct \
  --host 127.0.0.1 \
  --port 8000 \
  --max-model-len 8192 \
  --served-model-name app-model

Este é um exemplo de configuração, não o checkpoint equivalente ao comando anterior do Ollama nem uma recomendação de dimensionamento para produção. --served-model-name permite que o cliente mantenha um nome de modelo estável enquanto a implantação muda. Argumentos do motor vLLM.

Revise os templates de chat, que transformam os papéis das mensagens no formato de entrada do modelo, e defina os parâmetros de amostragem explicitamente. vLLM pode aplicar os padrões do arquivo generation_config.json de um repositório; --generation-config vllm desativa essa substituição. Compare a interpretação das chamadas de ferramentas, a saída estruturada, o streaming, o cancelamento e o tratamento de erros usando as requisições reais da aplicação.

Inclua a autenticação na migração. O exemplo de compatibilidade local do Ollama ignora o valor da chave de API do cliente. vLLM aceita uma chave de API, mas sua documentação de segurança alerta que ela não protege todos os endpoints. Mantenha o backend privado e aplique autenticação, TLS e restrições de rotas na camada de acesso ao serviço. Limitações da chave de API do vLLM.

Há outro custo de migração se sua aplicação troca de modelo base com frequência: o FAQ do vLLM descreve o uso de instâncias separadas de servidor e uma camada de roteamento para trabalhar com vários modelos base. Um alias de API não carrega outro modelo. A capacidade do Ollama de gerenciar vários modelos carregados pode oferecer um fluxo mais conveniente para uma ferramenta interna pouco usada. Limitação do vLLM para múltiplos modelos.

Diferença de preço: mesma carga, outro custo de operação

Nenhum dos motores leva vantagem por cobrar menos por token em infraestrutura própria: não há cobrança de tokens pelo motor. Os planos pagos de nuvem do Ollama são um serviço à parte, não um requisito para disponibilizar modelos locais. O guia de preços do Ollama explica essa diferença; para consultar as ofertas atuais de nuvem, use a página do fornecedor citada acima.

Com hardware próprio, o custo mensal inclui eletricidade, a parcela do custo do equipamento atribuída ao serviço e seu tempo. Com hardware alugado, comece pelas horas-máquina cotadas e acrescente armazenamento, rede e operação. Uma inferência mais eficiente só economiza dinheiro quando reduz os recursos provisionados, encurta o tempo de execução faturável ou gera um benefício mensurável para o negócio.

Exemplo de orçamento com a mesma base de comparação

Os valores a seguir são premissas explícitas de orçamento, não preços de fornecedores nem resultados de benchmark: uma GPU a $1 por hora, 730 horas por mês e 100,000 tarefas concluídas com sucesso. Cada tarefa tem 2,000 tokens de prompt e 1,000 tokens de saída, com o mesmo modelo, quantização, nível de qualidade e meta de latência nos dois motores.

Se ambos atenderem aos requisitos com uma GPU alugada continuamente, cada um custará $730 por mês em computação, ou $0.0073 por tarefa bem-sucedida e por 1,000 tokens de saída. O cálculo por tokens de saída mantém constante o trabalho com o prompt; não é um preço combinado de entrada e saída.

Agora acrescente duas horas de operação por mês para a implantação com vLLM, a um valor hipotético de $100 por hora, mais quatro horas de migração pagas uma única vez:

• Implantação de referência com Ollama: $730 recorrentes, antes dos custos comuns aos dois.
• vLLM no mesmo hardware: $930 recorrentes, ou $0.0093 por 1,000 tokens de saída.
• Primeiro mês de vLLM, incluindo a migração: $1,330, ou $0.0133 por 1,000 tokens de saída.

Essas horas são variáveis que você deve substituir pela própria estimativa, não uma afirmação sobre quanto tempo uma migração leva. O trabalho operacional comum, o armazenamento, os custos de rede e os impostos ficam fora dos dois lados da conta.

Quando a opção mais barata muda

Com esse valor por hora, vLLM precisa economizar mais de 200 horas de GPU por mês para compensar o custo adicional de operação assumido. Recuperar todos os $400 da migração no primeiro mês eleva o limite para mais de 600 horas de GPU economizadas.

Em um exemplo de serviço sempre ativo, suponha que seu próprio teste de carga mostre que Ollama precisa de duas réplicas de GPU idênticas, enquanto vLLM precisa de uma para atender à mesma carga e à mesma meta de resposta. A computação do Ollama passa a custar $1,460; a computação do vLLM somada à operação adicional continua em $930. Sob essas condições, a economia é de $530 por mês, recuperando os $400 da migração em cerca de 0.75 meses.

Esse é um cálculo do ponto de equilíbrio, não uma afirmação de que vLLM reduz pela metade sua necessidade de GPUs. Se ambos precisarem do mesmo hardware e nenhum outro benefício justificar a mudança, a comparação de custos de software nunca passa a favorecer vLLM. Não há um número universal de usuários a partir do qual a troca se justifique.

Checklist rápido para migrar do Ollama para o vLLM

Migre um conjunto validado de modelo e contrato de API por uma rota que permita voltar atrás. Os pesos baixados são apenas uma parte daquilo de que seus usuários dependem.

Adie a troca se Ollama já atende à meta do serviço, se o modelo necessário não tem uma opção validada no vLLM ou se a migração apenas substituiria um pacote funcional por um backend desconhecido. Manter Ollama nos notebooks e vLLM em um servidor compartilhado também pode fazer sentido, desde que você teste as diferenças, sem presumir que desenvolvimento e produção são idênticos. Para ampliar a lista de opções, veja as alternativas ao Ollama.

O próximo passo é concreto: registre uma carga representativa do período mais movimentado, defina o tempo de resposta aceitável e reproduza essa carga no servidor proposto antes de comprar mais capacidade.

Perguntas frequentes

Use o checklist de auditoria de fluxos de trabalho com IA para empresas para escolher qual fluxo privado merece um servidor de modelos compartilhado e assine a newsletter para acompanhar as próximas mudanças nas ferramentas.