vLLM: o que é, para quem é e quando usá-lo ?

#vLLM em três frases

vLLM é uma biblioteca Python e um servidor de inferência criados em 2023 no Sky Computing Lab da Universidade de Berkeley e publicados sob a licença Apache 2.0, uma licença permissiva que autoriza a reutilização comercial sem restrições. Ele carrega um modelo no formato Hugging Face, geralmente em safetensors, em uma ou mais GPUs e o expõe por uma API HTTP compatível com a API da OpenAI, o que permite conectar qualquer cliente já escrito para a API da OpenAI sem alterar uma linha do código da aplicação, apenas a URL base. Sua razão de ser se resume a uma palavra: vazão, isto é, o número total de tokens produzidos por segundo pela GPU quando dez, cinquenta ou duzentas requisições diferentes chegam ao mesmo tempo e todas precisam receber uma resposta rápida.

#O problema que o vLLM resolve

Quando um LLM gera texto, ele mantém em memória um registro de tudo o que já leu e escreveu: o cache KV. Esse cache cresce a cada token, e seu tamanho final é imprevisível, pois não se sabe de antemão se a resposta terá vinte palavras ou duas mil. Os servidores de inferência de primeira geração, portanto, reservavam, para cada requisição, um bloco contíguo de memória dimensionado para o pior caso.

O resultado numérico está descrito explicitamente no artigo fundador do vLLM (Kwon et al., SOSP 2023) e é retomado pela própria equipe do projeto: nos sistemas existentes, de 60 a 80% da memória reservada para o cache KV era simplesmente desperdiçada, devido à reserva excessiva por precaução e à fragmentação que deixa espaços inutilizáveis entre os blocos alocados. Menos memória efetivamente útil disponível significa, por consequência direta, menos requisições atendidas em paralelo na mesma placa e, portanto, uma GPU de vários milhares de euros que, no fim, opera a uma fração ínfima de sua capacidade teórica, mesmo que a conta de eletricidade e a amortização do equipamento permaneçam iguais.

#PagedAttention e batching contínuo

vLLM se baseia em duas ideias. A primeira, PagedAttention, vem dos sistemas operacionais: em vez de um grande bloco contíguo por requisição, o cache KV é dividido em pequenas páginas de tamanho fixo, alocadas sob demanda e armazenadas em qualquer lugar da memória. Uma tabela faz a correspondência entre a ordem lógica dos tokens e a localização física das páginas, exatamente como a memória virtual de um computador. O desperdício cai para menos de 4%, segundo os autores.

A segunda ideia é o batching contínuo, complementar à primeira. Um servidor clássico agrupa as requisições em lotes e espera que todas as requisições de um mesmo lote sejam concluídas antes de iniciar outro: a requisição curta, que poderia ter sido liberada imediatamente, espera desnecessariamente atrás da longa, que ainda monopoliza a GPU. Já o vLLM recompõe inteiramente o lote a cada token gerado, em cada etapa de decodificação. Assim que uma resposta termina, seu lugar no lote é imediatamente atribuído a uma requisição que aguarda na fila, e a GPU nunca fica trabalhando em vão com preenchimento inútil. É a combinação dessa reutilização contínua dos lugares no lote com a memória paginada que produz a maior parte do ganho de vazão observado em comparação com os motores de inferência projetados para um único usuário por vez.

Prefixos compartilhados

Quando várias requisições começam exatamente com o mesmo texto (um prompt de sistema, um documento comum), as páginas correspondentes são calculadas uma única vez e compartilhadas entre essas requisições. Isso é o prefix caching.

Paralelismo tensorial

Um modelo muito voluminoso para caber em uma única placa é distribuído automaticamente em vários GPUs de uma mesma máquina com apenas uma opção de inicialização, --tensor-parallel-size.

Quantização no lado do servidor

vLLM lê os formatos AWQ, GPTQ e FP8, projetados para cálculo GPU em lote. O GGUF é suportado apenas experimentalmente.

API compatível com OpenAI

As rotas /v1/chat/completions e /v1/completions respondem exatamente como as de OpenAI: uma aplicação já existente muda apenas a URL de base, sem precisar reescrever uma única linha de código de negócio.

#O que vLLM carrega em memória

Essa é a surpresa mais comum para quem vem do Ollama e espera manter os mesmos hábitos. O Ollama baixa por padrão um GGUF quantizado em 4 bits, pensado para caber em uma placa voltada ao consumidor comum. O vLLM, por sua vez, carrega por padrão os pesos exatamente como são publicados no Hugging Face, geralmente em BF16 (precisão de 16 bits), ou seja, cerca de 2 GB por bilhão de parâmetros do modelo. O mesmo modelo ocupa, portanto, aproximadamente três vezes mais memória no vLLM do que no Ollama, antes mesmo de contar o cache KV, que cresce com cada conversa em andamento. Isso explica por que uma placa suficiente para o Ollama pode ter memória muito abaixo da necessária para o vLLM se o formato dos pesos não for alterado.

A solução mais comum consiste em servir uma versão já quantizada para GPU em vez dos pesos originais completos: um modelo AWQ ou GPTQ em 4 bits ocupa aproximadamente a mesma quantidade de memória que um GGUF Q4 equivalente, e o formato FP8 reduz aproximadamente à metade o tamanho do BF16 nas placas recentes que o suportam nativamente. A grande maioria dos modelos realmente populares já está publicada em um desses formatos no Hugging Face, muitas vezes no mesmo dia de seu lançamento oficial.

#Hardware e sistemas suportados

#Colocá-lo em execução em cinco minutos

Em uma máquina Linux com uma GPU NVIDIA e drivers atualizados, a instalação completa cabe em poucas linhas em um ambiente Python limpo, sem precisar escrever previamente uma configuração complexa. O comando vllm serve baixa o modelo indicado do Hugging Face na primeira execução, carrega-o na memória e abre imediatamente a API na porta 8000 por padrão, pronta para receber requisições no formato padrão da OpenAI.

python -m venv vllm-env && source vllm-env/bin/activate
pip install vllm

vllm serve Qwen/Qwen3-8B --max-model-len 8192

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "Qwen/Qwen3-8B", "messages": [{"role": "user", "content": "Bonjour"}]}'

Vale a pena definir explicitamente a opção --max-model-len já na primeira execução: sem ela, o vLLM dimensiona o cache KV para a janela de contexto máxima anunciada pelo modelo, às vezes 128.000 tokens ou mais nos modelos recentes, e simplesmente se recusa a iniciar se a memória disponível na placa não comportar esse dimensionamento padrão, um erro frequente na primeira tentativa. A entrada em produção propriamente dita, com contêiner Docker, autenticação das chamadas, monitoramento contínuo e aumento gradual da carga, é abordada em um guia separado e mais detalhado.

• Implantar vLLM em produção: Docker, segurança, monitoramento
• Documentação oficial do vLLM
• O artigo PagedAttention (Kwon et al., 2023)
• Fonte: anúncio oficial do vllm-metal (22/09/2026)
• Fonte: repositório oficial do projeto vLLM no GitHub

#Para quem é indicado e para quem não é

• llama.cpp vs vLLM vs ExLlama : três motores, três usos
• llama.cpp: o que é e vale a pena abandonar o Ollama?
• Calcular a VRAM necessária para o seu modelo

#FAQ