Principais conclusões
- Gratuito e de código aberto sob licença Apache 2.0, originado no Sky Computing Lab da UC Berkeley
- O PagedAttention gerencia o cache KV em blocos não contíguos de tamanho fixo para reduzir o desperdício de memória da GPU
- O continuous batching processa muitas requisições simultâneas em vez de um lote fixo por vez
- Traz embutido um servidor de API compatível com OpenAI, iniciado com o comando
vllm serve - Suporta formatos de quantização como AWQ, GPTQ e FP8
- Suporta serving com paralelismo de tensores e de pipeline em múltiplas GPUs
- O hardware principal e mais bem suportado são GPUs NVIDIA; backends AMD, Intel e outros existem, mas com cobertura mais estreita
- Não é um app de desktop de usuário único — sem instalador gráfico, e não é voltado para CPU-only ou Apple Silicon como llama.cpp e Ollama
📍 Em uma frase
vLLM é uma biblioteca gratuita, sob licença Apache 2.0, originada no Sky Computing Lab da UC Berkeley, que usa PagedAttention e continuous batching para atender com eficiência muitas requisições de LLM simultâneas a partir de uma GPU, e traz embutido um servidor de API compatível com OpenAI.
💬 Em termos simples
Em vez de um app de chat de desktop, o vLLM é software de servidor: você o aponta para um modelo e ele expõe uma API que muitas pessoas ou aplicações podem chamar ao mesmo tempo, aproveitando a memória da GPU com mais eficiência do que um esquema simples de uma requisição por vez.
📌Nota: Este artigo se baseia no repositório oficial no GitHub do vLLM e em sua documentação pública, não em benchmarks próprios. Números específicos de desempenho ou latência não são incluídos porque não foram medidos de forma independente para este artigo e variam muito conforme a GPU, o modelo, o tamanho do lote e a versão do vLLM.
O que é vLLM?
vLLM é uma biblioteca e servidor gratuitos, sob licença Apache 2.0, para executar inferência de grandes modelos de linguagem em escala. Surgiu como projeto de pesquisa no Sky Computing Lab da UC Berkeley e desde então cresceu até se tornar um dos motores de serving de LLM open source mais usados, com contribuições de milhares de desenvolvedores de organizações acadêmicas e da indústria. Diferente de ferramentas construídas principalmente para um único usuário conversando com um modelo na própria máquina, o vLLM é projetado para atender muitas requisições simultâneas — de múltiplos usuários ou aplicações — da forma mais eficiente possível a partir de capacidade de GPU compartilhada.
- Originado no Sky Computing Lab da UC Berkeley, hoje um projeto open source governado pela comunidade
- Sob licença Apache 2.0: o código-fonte está disponível publicamente para uso, modificação e redistribuição conforme os termos da licença
- Carrega modelos no formato compatível com Hugging Face Transformers, dando ampla cobertura de arquiteturas — Llama, Mistral, Qwen, DeepSeek e muitas outras famílias de modelos — sem uma etapa separada de conversão para a maioria dos modelos
- Construído para atender com eficiência muitas requisições simultâneas, não apenas para rodar rápido uma única conversa
- Um dos projetos de serving de LLM open source mais referenciados no GitHub
O que é PagedAttention, e por que isso importa?
PagedAttention é a técnica de gerenciamento de memória pela qual o vLLM é mais conhecido. Durante a geração, um modelo transformer armazena um cache de chave-valor (KV) de atenção para cada token de cada requisição ativa — normalmente esse cache é alocado como um único bloco contíguo grande por requisição, dimensionado para o comprimento máximo possível da requisição, o que desperdiça memória da GPU sempre que uma requisição termina antes ou é mais curta que o máximo reservado. O PagedAttention, em vez disso, divide o cache KV em blocos pequenos de tamanho fixo (páginas) que podem ser alocados de forma não contígua e compartilhados entre requisições, tomando emprestada uma ideia de como sistemas operacionais gerenciam memória virtual.
- Reduz o desperdício de memória por reservar em excesso espaço de cache KV para requisições que acabam sendo mais curtas que seu máximo
- Permite compartilhar blocos de memória entre requisições que compartilham um prefixo comum, como o mesmo prompt de sistema
- Permite que a GPU mantenha o cache KV de mais requisições simultâneas na mesma quantidade de memória em comparação a uma alocação contígua ingênua
- Funciona junto com o continuous batching, que permite ao vLLM adicionar e remover requisições de um lote em andamento conforme elas chegam e terminam, em vez de esperar um lote fixo terminar por completo antes de começar o próximo
Que hardware o vLLM precisa?
O alvo principal e mais bem suportado do vLLM são GPUs NVIDIA com CUDA, e a maioria dos deployments de produção roda em hardware NVIDIA. O projeto também documenta backends adicionais, mas a cobertura e o desempenho não são iguais em todos eles.
GPUs NVIDIA (CUDA)
- Detalhes:
- O alvo principal e mais maduro. O serving com paralelismo de tensores e de pipeline em múltiplas GPUs NVIDIA é bem documentado e amplamente usado em produção.
GPUs AMD (ROCm)
- Detalhes:
- Documentado como backend suportado para hardware AMD via ROCm, com adoção real e cobertura da comunidade mais estreitas que o caminho CUDA.
GPUs Intel e aceleradores Gaudi
- Detalhes:
- Backends adicionais documentados pelo projeto para hardware Intel; considere como um caminho de deployment menor e menos testado que GPUs NVIDIA.
TPUs do Google
- Detalhes:
- Um backend documentado para hardware TPU do Google Cloud, voltado a times que já operam nessa infraestrutura.
CPU (x86 / ARM / PowerPC)
- Detalhes:
- Existe um backend somente CPU, mas não é o caso de uso alvo do vLLM — o projeto é construído para serving em GPU, e a execução em CPU é documentada como substancialmente mais lenta que os backends de GPU.
Apple Silicon (Mac)
- Detalhes:
- Não é um caminho oficial de primeira classe. Projetos mantidos pela comunidade (como um plugin de backend Metal) adicionam suporte parcial a Apple Silicon, mas a cobertura e a maturidade ficam muito atrás do suporte a GPU NVIDIA do vLLM.
Se o objetivo é rodar um modelo em um único Mac ou uma máquina somente com CPU, o vLLM não é a ferramenta feita para isso — llama.cpp e ferramentas construídas sobre ele, como Ollama e LM Studio, miram diretamente hardware CPU e Apple Silicon e se encaixam melhor nesse cenário.
Quais formatos de quantização o vLLM suporta?
O vLLM suporta servir modelos com precisão numérica reduzida para diminuir o uso de memória e, em muitos casos, aumentar o desempenho, usando vários formatos de quantização estabelecidos em vez de um único formato proprietário.
AWQ
- Detalhes:
- Activation-aware Weight Quantization, um método de quantização de pesos em 4 bits amplamente usado, com modelos pré-quantizados publicados pela comunidade no Hugging Face.
GPTQ
- Detalhes:
- Um método de quantização pós-treinamento comumente distribuído como checkpoints de modelos pré-quantizados, também tipicamente em precisão de 4 bits.
FP8
- Detalhes:
- Precisão de ponto flutuante de 8 bits, suportada em gerações mais novas de GPUs NVIDIA com suporte de hardware a FP8, trocando alguma precisão por menor uso de memória e execução mais rápida que FP16/BF16.
INT8 / INT4
- Detalhes:
- Caminhos de quantização inteira de menor precisão documentados pelo projeto junto com AWQ e GPTQ para redução adicional de memória.
Este artigo não inclui números de perda de qualidade medidos de forma independente para cada formato — eles variam conforme a arquitetura do modelo e a tarefa. Comparar saídas de alguns formatos com seus próprios prompts é a forma mais confiável de avaliar o trade-off para o seu caso de uso.
O que o servidor compatível com OpenAI do vLLM oferece?
Executar vllm serve inicia um servidor HTTP que implementa o protocolo da API da OpenAI, de modo que aplicações e SDKs já construídos sobre a API da OpenAI muitas vezes podem apontar para uma instância vLLM auto-hospedada mudando apenas a URL base e o nome do modelo.
- Endpoints compatíveis com OpenAI para chat completions e completions, utilizáveis como substituto direto de código cliente baseado na API da OpenAI
- Host e porta configuráveis (o servidor escuta por padrão em
http://localhost:8000) - Flags do motor para o tamanho do paralelismo de tensores, a meta de utilização de memória da GPU e o formato de quantização, definidos ao iniciar o servidor
- Suporte para servir vários adaptadores LoRA sobre um mesmo modelo base carregado
- Suporte a saídas estruturadas e chamadas de função/ferramenta para formatos de requisição compatíveis
Como instalar e executar o vLLM?
O vLLM é distribuído como pacote Python e normalmente instalado com pip em um ambiente Python com uma GPU NVIDIA disponível e drivers CUDA compatíveis.
- 1Confirme que você tem uma GPU NVIDIA suportada com drivers CUDA atuais instalados (ou consulte a documentação do projeto para instruções de instalação específicas de AMD/Intel/TPU se for usar um desses backends).
- 2Crie um ambiente virtual Python e instale o vLLM:
pip install vllm. - 3Inicie o servidor compatível com OpenAI com um modelo do Hugging Face, por exemplo:
vllm serve meta-llama/Llama-3.1-8B-Instruct. - 4Para um modelo pré-quantizado, passe a flag correspondente, por exemplo:
vllm serve TheBloke/Llama-2-13B-AWQ --quantization awq. - 5Para serving multi-GPU, adicione uma flag de paralelismo de tensores, por exemplo:
vllm serve <model> --tensor-parallel-size 2para dividir o modelo entre duas GPUs. - 6Por padrão o servidor escuta em
http://localhost:8000; envie uma requisição ao endpoint/v1/chat/completionscom qualquer biblioteca cliente compatível com a API da OpenAI, oucurl. - 7Aponte código cliente OpenAI existente para o seu servidor auto-hospedado mudando apenas a URL base e o nome do modelo.
Preciso de uma GPU para executar o vLLM?
Para qualquer uso além de testes, sim — o alvo principal e mais bem suportado do vLLM são GPUs NVIDIA. Existe um backend somente CPU, mas é documentado como substancialmente mais lento e não é o foco do projeto.
Posso executar o vLLM com um modelo quantizado?
Sim — o vLLM suporta formatos como AWQ, GPTQ e FP8, e muitos modelos pré-quantizados nesses formatos estão publicados no Hugging Face e podem ser servidos com a flag --quantization correspondente.
Como o vLLM se compara ao Ollama e ao LM Studio?
Ollama e LM Studio miram um problema diferente do vLLM: dar rápida e simplesmente a uma pessoa um modelo para conversar na própria máquina. O vLLM mira atender muitos usuários ou aplicações simultâneos da forma mais eficiente possível a partir de capacidade de GPU compartilhada. As duas categorias de ferramentas não são substitutas próximas para a maioria dos casos de uso.
- Ollama e LM Studio costumam ser construídos sobre llama.cpp ou motores similares e o formato de modelo GGUF, otimizados para uso de usuário único em hardware de consumo, incluindo máquinas somente com CPU e Apple Silicon
- O vLLM é construído sobre PagedAttention e continuous batching, otimizado para serving em GPU de alta concorrência em vez de responsividade de usuário único em hardware modesto
- O Ollama se instala com um comando sem exigir GPU; o vLLM espera um ambiente Python, uma GPU NVIDIA na maioria dos deployments, e configuração via linha de comando
- O LM Studio adiciona uma interface gráfica de chat de desktop; o vLLM não tem interface gráfica — o acesso é via sua API compatível com OpenAI ou flags de linha de comando
- Tanto o vLLM quanto ferramentas baseadas em llama.cpp podem expor uma API compatível com OpenAI, então ferramentas de front-end construídas para essa API costumam funcionar com qualquer uma delas
Como o vLLM se compara ao TGI e ao TensorRT-LLM?
vLLM, o Text Generation Inference (TGI) da Hugging Face, e o TensorRT-LLM da NVIDIA miram todos o mesmo trabalho amplo — serving de LLM em produção em escala —, mas com designs e trade-offs diferentes.
vLLM
- Detalhes:
- Sob licença Apache 2.0, baseado em Python, construído em torno de PagedAttention e continuous batching. Carrega diretamente modelos compatíveis com Hugging Face Transformers, com ampla cobertura de arquiteturas e suporte a backends de GPU multi-fornecedor (NVIDIA principal; AMD, Intel, TPU documentados).
TGI
- Detalhes:
- O motor de serving próprio da Hugging Face, sob licença Apache 2.0, também suportando continuous batching e vários formatos de quantização. Fortemente integrado ao Hugging Face Hub e seu ecossistema.
TensorRT-LLM
- Detalhes:
- O motor da NVIDIA, construído especificamente para GPUs NVIDIA. Os modelos são compilados antecipadamente em um motor TensorRT otimizado para a GPU alvo, o que pode gerar bom desempenho naquele hardware específico, ao custo de uma etapa de compilação e menos flexibilidade entre hardwares que o vLLM ou o TGI.
Este artigo não comparou de forma independente esses três motores entre si e não afirma que um seja universalmente mais rápido — o desempenho depende muito do modelo, do hardware, das características dos lotes e da versão de cada motor. Veja o guia de servidores de inferência empresarial para uma comparação mais detalhada de deployment e licenciamento dos três.
Para quem o vLLM é indicado?
O vLLM se encaixa em times que servem um modelo para muitos usuários ou aplicações simultâneos em infraestrutura de GPU, não em pessoas buscando a forma mais rápida de conversar com um modelo no próprio computador.
vLLM vs. alternativas em resumo
Essas ferramentas se posicionam em pontos diferentes do espectro entre uso de usuário único e serving em produção.
vLLM
- Interface e instalação:
- Pacote Python instalado via pip; servidor de API compatível com OpenAI iniciado com
vllm serve. Exige uma GPU NVIDIA e CUDA na maioria dos deployments. - Melhor para:
- Serving de GPU de alto desempenho e múltiplos usuários em produção.
Ollama
- Interface e instalação:
- CLI e API REST, comumente relatado como rodando sobre llama.cpp como backend na maioria das plataformas. Um comando instala; um comando baixa e roda um modelo.
- Melhor para:
- O caminho mais rápido para um modelo local funcionando para um único usuário, sem etapa de build ou GPU exigida.
LM Studio
- Interface e instalação:
- App gráfico de desktop para Mac, Windows e Linux. Baixar, instalar, depois procurar e baixar um modelo dentro do app.
- Melhor para:
- Usuários não técnicos que querem um app de chat local para clicar.
llama.cpp
- Interface e instalação:
- CLI, interface web embutida e API compatível com OpenAI via llama-server. Compilar do código-fonte ou usar um binário pré-compilado; roda em CPU ou GPU.
- Melhor para:
- Controle direto no nível do motor, deployment embarcado/edge, e hardware CPU ou Apple Silicon.
Este artigo não comparou de forma independente a velocidade ou a qualidade das saídas dessas ferramentas e não afirma que uma seja tecnicamente superior — a comparação acima cobre apenas fatos documentados de arquitetura, instalação e modelo de acesso. Para números de desempenho por hardware, veja a comparação llama.cpp vs. Ollama vs. vLLM e o guia de servidores de inferência empresarial.
O que este artigo não cobre?
Este é um artigo explicativo construído a partir da documentação pública e do repositório do vLLM, não um relatório de benchmarks prático.
- Sem números de desempenho, latência ou requisições por segundo medidos de forma independente — esses dependem muito da GPU, do modelo, da composição dos lotes e da versão do vLLM
- Sem percentuais de perda de qualidade verificados de forma independente para formatos de quantização específicos — esses variam conforme a arquitetura do modelo e a tarefa
- Sem auditoria de segurança linha a linha do código do vLLM — ele é open source e sob licença Apache 2.0, então o código em si está disponível para revisão
- Sem cobertura completa de cada backend de hardware suportado, flag do motor ou opção de orquestração de deployment (Kubernetes, configurações específicas de nuvem) — este artigo foca nos conceitos e flags que a maioria dos times avalia primeiro
- Sem cobertura de acordos de suporte comercial ou ofertas de hospedagem gerenciada do vLLM, já que o vLLM em si é um projeto open source comunitário, não um produto de fornecedor com contrato de suporte
Erros comuns ao experimentar o vLLM
A maior parte do atrito com o vLLM vem de tratá-lo como uma ferramenta de desktop de usuário único em vez de software de servidor de produção.
Perguntas frequentes
O que é vLLM?
vLLM é uma biblioteca e servidor gratuitos, sob licença Apache 2.0, para inferência de LLM de alto desempenho, originados no Sky Computing Lab da UC Berkeley. Usa PagedAttention e continuous batching para atender com eficiência muitas requisições simultâneas a partir de uma GPU.
O vLLM é gratuito?
Sim. O vLLM é software gratuito e de código aberto lançado sob a licença Apache 2.0, sem exigência de assinatura ou conta para executá-lo você mesmo.
O que é PagedAttention?
PagedAttention é a técnica do vLLM para gerenciar o cache KV de atenção em pequenos blocos não contíguos de tamanho fixo em vez de uma única alocação contígua grande por requisição, reduzindo o desperdício de memória da GPU e permitindo compartilhar memória entre requisições com um prefixo comum.
O vLLM precisa de uma GPU?
Para qualquer carga de trabalho real, sim — o alvo principal e mais bem suportado do vLLM são GPUs NVIDIA. Existe um backend somente CPU, mas é documentado como substancialmente mais lento e não é o foco do projeto, e o suporte a Apple Silicon se limita a extensões mantidas pela comunidade em vez de um caminho de primeira classe.
Quais formatos de quantização o vLLM suporta?
O vLLM suporta vários formatos, incluindo AWQ, GPTQ, FP8 e INT8/INT4, com muitos modelos pré-quantizados nesses formatos publicados no Hugging Face.
O vLLM é melhor que o Ollama?
"Melhor" depende do trabalho: o vLLM é construído para serving de GPU de produção com alta concorrência, enquanto o Ollama é construído para o caminho mais rápido a um modelo local de usuário único sem exigir GPU. Para a maioria dos casos de uso, não são substitutos próximos — veja a tabela comparativa acima.
O vLLM pode servir modelos em várias GPUs?
Sim. O vLLM suporta serving com paralelismo de tensores e de pipeline em várias GPUs, configurável com flags como --tensor-parallel-size ao iniciar o servidor.
O vLLM tem uma API compatível com OpenAI?
Sim. Executar vllm serve inicia um servidor que implementa o protocolo da API da OpenAI, de modo que muitas aplicações construídas para a API da OpenAI podem apontar para uma instância vLLM auto-hospedada mudando apenas a URL base e o nome do modelo.
Como o vLLM difere do TensorRT-LLM?
O TensorRT-LLM é o motor da NVIDIA, que compila os modelos antecipadamente em um motor otimizado para uma GPU NVIDIA específica. O vLLM carrega diretamente modelos compatíveis com Hugging Face Transformers sem uma etapa de compilação prévia, e documenta suporte a backends além das GPUs NVIDIA, ao custo de menos otimização específica de hardware, mas com mais flexibilidade e iteração mais rápida.