Ollama vs vLLM: qual runtime LLM para produção?

Escolher entre Ollama e vLLM significa ponderar a simplicidade de implantação e a taxa bruta de processamento sob carga concorrente. Essa comparação orienta hoje grande parte das decisões de infraestrutura auto-hospedada para LLMs com pesos abertos, seja para atender um agente interno ou expor uma API multi-tenant. Vamos comparar aqui os dois runtimes em termos de arquitetura, taxa de processamento mensurável em GPUs NVIDIA, gestão de memória (cache KV, PagedAttention), licenças e formatos suportados e custos operacionais, e terminaremos com recomendações por tamanho de modelo e uma FAQ técnica. Nosso objetivo: permitir que um engenheiro de plataforma tome uma decisão em menos de quinze minutos de leitura.

Arquitetura e filosofia: dois runtimes, dois mundos

Ollama é um wrapper de llama.cpp, escrito em Go, que expõe uma API HTTP simples e gerencia o download, o cache e o carregamento dinâmico dos modelos GGUF. Seu público-alvo histórico: máquinas de desenvolvedores (Macs da série M, PCs desktop com RTX) e implantações leves single-tenant. O runtime subjacente faz offload para a CPU de forma transparente, o que permite rodar um Qwen 2.5 72B Instruct (VRAM Q4 ~42 GB) em uma RTX 4090 de 24 GB, usando a RAM do sistema para offload, à custa da taxa de processamento.

vLLM, publicado pela UC Berkeley, é um servidor Python otimizado para atender a muitas requisições simultâneas. Sua principal contribuição é PagedAttention, que gerencia o KV cache como a memória virtual de um sistema operacional: blocos de tamanho fixo, paginação, compartilhamento entre requisições. Concretamente, onde um runtime básico desperdiça 60 a 80% do KV cache por fragmentação, o vLLM cai abaixo de 4%. O resultado é um throughput agregado de 2x a 24x superior conforme a carga, mas com um custo de entrada: sem quantização GGUF nativa, dependência estrita de CUDA, modelo inteiro na VRAM.

Para entender melhor a diferença de abordagem entre llama.cpp e vLLM no que diz respeito ao serving, consulte nosso guia completo llama.cpp vs vLLM.

Throughput e latência: o que os números dizem

As medições públicas convergem em um ponto: sob carga concorrente, o vLLM leva ampla vantagem. Em um Llama 3.3 70B Instruct (70B, ctx 128 000) servido em FP8 em 4× A100 80 GB, observa-se tipicamente (a confirmar conforme o tamanho do batch):

A diferença se acentua ainda mais nos modelos MoE como Mixtral 8x22B Instruct (141B, Apache 2.0, ctx 64K), nos quais o vLLM aproveita o paralelismo de tensores entre várias GPUs com uma eficiência que o llama.cpp tem dificuldade em alcançar. Para os modelos MoE muito grandes, como DeepSeek V3 671B ou Qwen 3 235B-A22B, vLLM continua sendo a única opção realista para produção multiusuário, especialmente graças ao suporte nativo ao paralelismo de especialistas.

Por outro lado, para uma carga de fluxo único com quantização agressiva (Q4_K_M, Q5_K_M), o Ollama é competitivo em relação à latência do primeiro token (TTFT), que às vezes é menor em modelos 7B-13B graças à leveza do runtime. Para um benchmark detalhado em GPUs voltadas ao consumidor, veja nosso comparativo RTX 4090 vs RTX 5090 para LLM.

Quantização, formatos e VRAM real

É aqui que os dois runtimes divergem radicalmente. O Ollama utiliza exclusivamente GGUF (Q2_K até Q8_0, mais FP16). Essa flexibilidade permite colocar um Llama 3.1 70B (~40 GB em Q4) em uma única RTX A6000 de 48 GB. O vLLM aceita pesos nativos do HuggingFace (FP16, BF16) e agora suporta AWQ, GPTQ e FP8, mas não GGUF em produção estável.

Algumas referências de VRAM em Q4 do catálogo QualLLM :

Para implantações de menor porte, gpt-oss 120B e Mistral Small 4 oferecem um equilíbrio razoável: tamanho gerenciável, licença permissiva, suporte para os dois runtimes. Consulte nossa ficha Mistral Small 4 para benchmarks detalhados.

Licenças e conformidade

A escolha do runtime não afeta as condições de licença — é o modelo que estabelece as condições. Casos típicos em produção europeia:

Para um panorama completo, ver nosso guia das licenças de LLM open-source e o acompanhamento comunitário em Modelos do HuggingFace.

Casos de uso: qual escolher para cada finalidade?

Escolha Ollama se: - Você implanta um assistente interno em um computador de desenvolvedor ou em uma única estação com GPU - Você quer iterar rapidamente com vários modelos (troca a quente via API) - Sua carga é < 5 usuários simultâneos - Você pretende usar uma RTX 3090/4090/5090 ou um Mac Studio M3 Ultra - Você quer testar dots.llm1 Instruct (142B, MIT, Rednote) ou Hunyuan-A13B Instruct sem configurar um cluster

Escolha o vLLM se: - Você disponibiliza uma API por trás de um balanceador de carga com mais de 20 requisições por segundo - Você usa paralelismo de tensores em 2, 4 ou 8 GPUs - Você quer aproveitar PagedAttention, decodificação especulativa e processamento contínuo em lotes - Você pretende usar modelos MoE de grande escala: DeepSeek V3.2 (685B), Mistral Large 3 675B, Llama 3.1 405B Instruct, Ring-1T (1000B) - Você precisa de Llama 4 Scout 109B com seu contexto de 10 milhões de tokens em um ambiente de inferência multi-tenant

Uma terceira opção merece menção: Text Generation Inference de HuggingFace, intermediário entre os dois, suportado nativamente para Mistral Medium 3.5 128B e a família Llama. Para orquestrar um cluster vLLM, Ray Serve permanece a referência.

Para recomendações por orçamento de GPU, consulte nosso guia do configurador e a página melhor LLM para servidor GPU.

Custos operacionais e observabilidade

Ollama ganha em simplicidade operacional: um único binário, telemetria mínima, atualização do modelo com um único comando. O custo oculto é a ausência de métricas detalhadas (sem Prometheus nativo nas versões estáveis recentes, a confirmar). vLLM expõe nativamente um endpoint Prometheus com tempo até o primeiro token, taxa de geração por requisição, uso do cache KV, e se integra diretamente ao Grafana.

Quanto ao custo de GPU, um cluster vLLM bem ajustado reduz o custo por milhão de tokens por um fator de 3 a 8 em comparação com uma implantação equivalente do Ollama em múltiplas instâncias — a diferença vem do processamento contínuo em lotes e da quase ausência de fragmentação KV. No Qwen3-Coder-Next 80B-A3B (MoE, Apache 2.0), nossos leitores relatam (a confirmar) ~14.000 tokens/s agregados em 2× H100 com vLLM, contra ~80 tokens/s em fluxo único com Ollama e um RTX 6000 Ada.

Para ir mais longe no tuning, veja o blog oficial do vLLM e nosso comparação vLLM vs TGI.

FAQ

P: Ollama pode servir vários usuários simultaneamente em produção?

Tecnicamente sim, mas com limitações. Ollama trata várias requisições por meio de uma fila interna, sem batching contínuo eficaz. Acima de 3 a 5 usuários simultâneos em um modelo de 70B como Llama 3.3 70B Instruct, a latência p95 piora muito. Para uma operação séria em produção com múltiplos tenants, vLLM ou TGI continuam sendo as escolhas tecnicamente justificadas.

P: O vLLM suporta quantificações agressivas como Q4 GGUF?

Não em GGUF nativo. O vLLM prioriza FP8, AWQ e GPTQ, que oferecem um equilíbrio diferente entre qualidade e VRAM. Em DeepSeek R1 671B, existe uma versão oficial em AWQ de 4 bits no HuggingFace que roda com vLLM. Para usar estritamente GGUF Q4_K_M, continue com Ollama ou llama.cpp diretamente — esse é o ponto forte deles.

Q: Qual runtime usar para um MoE como Qwen 3 235B-A22B?

vLLM, sem dúvidas. Os modelos MoE se beneficiam muito do paralelismo de especialistas e do batching contínuo que o vLLM implementa nativamente. Qwen 3 235B-A22B (Apache 2.0, ctx 131K) atinge uma taxa de processamento agregada da qual o Ollama não consegue nem se aproximar, mesmo em um cluster 8× H100. Ver nossa ficha Qwen 3 235B-A22B.

P: É possível usar Ollama em um cluster Kubernetes?

Sim, existem charts Helm comunitários, mas Ollama não foi projetado para escalar horizontalmente sem estado. Cada pod recarrega os modelos, o cache GGUF não é compartilhado. Para integração nativa com Kubernetes, o vLLM se integra melhor via KServe e seu operador dedicado.

P: Qual runtime escolher para Llama 4 Scout 109B e seu contexto 10M?

vLLM com atenção esparsa ativada. O contexto 10M de Llama 4 Scout 109B exige um gerenciamento do cache KV que só o PagedAttention torna economicamente viável. Tecnicamente, o Ollama pode carregar o modelo, mas o cache KV para 10M de tokens ultrapassa a capacidade da VRAM sem paginação. Reservar para vLLM ou TGI.

P: Existe uma alternativa aos dois para os Mac Apple Silicon?

Sim: MLX da Apple é otimizado para Metal e supera o Ollama no M3 Ultra para modelos como DeepSeek R1 Distill Llama 70B. Mas servir modelos a vários usuários no Mac continua sendo um uso de nicho. Veja nosso guia LLM para Mac M3 Ultra.

Conclusão

A escolha entre Ollama e vLLM depende da carga de trabalho prevista: Ollama para prototipagem, uso individual e Macs; vLLM quando se trata de APIs multi-tenant, modelos MoE massivos ou paralelismo tensorial. Para identificar a combinação de modelo/runtime adequada à sua VRAM e à licença desejada, inicie nosso configurador ou explore os 249 modelos indexados no catálogo QualLLM.

Artigo publicado em por Mohamed Meguedmi · Fonte de dados: /api/models.json · Licença de conteúdo: CC BY 4.0.

Algum erro ou alguma atualização para informar? Contribuir.