Skip to main content
PromptQuorumBuilt for humans. Structured for AI.
Início/LLMs locais avançados
Overview & Reference

vLLM explicado: serving de LLM de alto desempenho com PagedAttention (2026)

·13 min de leituraPor Hans Kuepper · Fundador do PromptQuorum · Mecanismo de descoberta de IA de pesos abertos e código aberto

vLLM é uma biblioteca gratuita e de código aberto (Apache 2.0) para inferência e serving de LLM de alto desempenho, originada no Sky Computing Lab da UC Berkeley e hoje mantida por uma grande comunidade open source. Seu principal diferencial técnico é o PagedAttention, que gerencia o cache KV de atenção em blocos não contíguos de tamanho fixo — de forma parecida com um sistema operacional gerenciando memória virtual —, permitindo que uma GPU mantenha o estado de muito mais requisições simultâneas sem reservar memória em excesso para cada uma. Combinado com o continuous batching, isso permite que o vLLM atenda muitos usuários simultâneos a partir de uma GPU (ou uma configuração multi-GPU com paralelismo de tensores) com menos memória desperdiçada do que um loop de serving ingênuo. O vLLM traz embutido um servidor de API compatível com OpenAI (vllm serve), suporta formatos de quantização como AWQ, GPTQ e FP8, e é construído para serving de produção e multi-tenant — não para o caso de uso de usuário único ao clicar que ferramentas como Ollama e LM Studio miram.

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.

Ler em:
🇺🇸en🇩🇪de🇫🇷fr🇯🇵ja🇨🇳zh🇪🇸es🇧🇷pt🇸🇦ar🇰🇷ko

vLLM é uma biblioteca gratuita, sob licença Apache 2.0, para inferência e serving de LLM, originada no Sky Computing Lab da UC Berkeley e hoje mantida por uma grande comunidade open source. Sua principal contribuição técnica é o PagedAttention, uma técnica de gerenciamento de memória para o cache de chave-valor (KV) de atenção que permite a uma GPU atender muito mais requisições simultâneas a partir da mesma memória do que implementações de atenção ingênuas, combinada com continuous batching, que mantém a GPU ocupada com muitas requisições simultâneas em vez de processá-las em lotes fixos. O vLLM traz embutido um servidor de API compatível com OpenAI e mira o serving de produção multiusuário — uma ferramenta diferente de apps de desktop de usuário único como Ollama ou LM Studio.

vLLM explicado: serving de LLM de alto desempenho com PagedAttention (2026)

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.

  1. 1
    Confirme 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).
  2. 2
    Crie um ambiente virtual Python e instale o vLLM: pip install vllm.
  3. 3
    Inicie o servidor compatível com OpenAI com um modelo do Hugging Face, por exemplo: vllm serve meta-llama/Llama-3.1-8B-Instruct.
  4. 4
    Para um modelo pré-quantizado, passe a flag correspondente, por exemplo: vllm serve TheBloke/Llama-2-13B-AWQ --quantization awq.
  5. 5
    Para serving multi-GPU, adicione uma flag de paralelismo de tensores, por exemplo: vllm serve <model> --tensor-parallel-size 2 para dividir o modelo entre duas GPUs.
  6. 6
    Por padrão o servidor escuta em http://localhost:8000; envie uma requisição ao endpoint /v1/chat/completions com qualquer biblioteca cliente compatível com a API da OpenAI, ou curl.
  7. 7
    Aponte 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).
Artigos sobre vLLM (9)

+84 mais não exibidos

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.
Artigos sobre TensorRT-LLM (6)

Também mencionado em:

+1 mais não exibidos

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.

Use o vLLM se

  • Você está implantando um LLM atrás de uma API que muitos usuários ou serviços a jusante chamarão simultaneamente
  • Você tem acesso a uma ou mais GPUs NVIDIA (ou um deployment suportado de AMD/Intel/TPU) e quer maximizar o desempenho e a capacidade de requisições simultâneas desse hardware
  • Você quer um servidor de API compatível com OpenAI auto-hospedado em vez de depender de um provedor de API terceiro
  • Você precisa de serving multi-GPU com paralelismo de tensores para um modelo grande demais para caber em uma única GPU
  • Você se sente confortável com um ambiente Python, configuração via linha de comando e configuração de GPU/CUDA

Evite o vLLM se

  • Você quer rodar um modelo no seu próprio notebook ou desktop para chat pessoal de usuário único — Ollama ou LM Studio se encaixam muito melhor
  • Você não tem uma GPU suportada — o backend de CPU do vLLM não é seu foco, e não há suporte relevante a Apple Silicon como no llama.cpp ou Ollama
  • Você quer uma interface gráfica para clicar em vez de um servidor de API e flags de linha de comando
  • Você não se sente confortável resolvendo problemas de drivers CUDA, conflitos de dependência do Python ou configuração de memória de GPU

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.
Artigos sobre vLLM (9)

+84 mais não exibidos

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.
Artigos sobre Ollama (10)

+310 mais não exibidos

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.
Artigos sobre LM Studio (10)

+146 mais não exibidos

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.
Artigos sobre llama.cpp (10)

+167 mais não exibidos

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.

Comparar no diretório

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.

Erro 1: tentar rodá-lo em um notebook sem GPU dedicada

O backend de CPU do vLLM existe, mas não é seu foco, e não há suporte relevante a Apple Silicon como no llama.cpp ou Ollama. Tentar rodá-lo em um notebook somente com CPU ou um Mac com Apple Silicon geralmente leva a desempenho ruim ou atrito de instalação que uma ferramenta local feita para isso evitaria completamente.

Erro 2: esperar um instalador gráfico ou uma janela de chat

O vLLM não tem um instalador para clicar e não tem uma UI de chat embutida. Ele é instalado com pip e acessado através de sua API compatível com OpenAI — um front-end separado (construído por você, ou uma UI de chat de terceiros que fale a API da OpenAI) é necessário para ter uma janela de chat.

Erro 3: dimensionar a memória da GPU só para o modelo, não para as requisições simultâneas

Uma GPU com memória apenas suficiente para carregar uma cópia de um modelo deixa pouca folga para o cache KV de várias requisições simultâneas. Dimensionar para a carga simultânea esperada — não apenas para os pesos do modelo caberem na VRAM — evita erros de memória insuficiente sob tráfego real.

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.

Fontes

← Voltar para LLMs locais avançados

MCP