O que é o vLLM 0.28.0

vLLM é uma biblioteca open source para inferência e serving de modelos de linguagem. Em termos simples, ela transforma um modelo em um serviço que recebe requisições e devolve respostas com foco em throughput, uso de memória e operação contínua.

O projeto foi desenvolvido originalmente no Sky Computing Lab da UC Berkeley e cresceu com contribuições de instituições acadêmicas e empresas. A versão 0.28.0 foi publicada em 26 de agosto de 2026 e reúne 584 commits de 270 contribuidores, sendo 76 pessoas novas no projeto.

Ela está em alta porque colocar um LLM em produção exige mais do que carregar pesos e chamar um método. Filas, cache, paralelismo, streaming, quantização e limites de hardware definem o custo real de cada resposta. O vLLM concentra boa parte dessa infraestrutura em uma camada que pode ser usada localmente ou em servidores.

Como funciona

O caminho começa quando um cliente envia uma requisição HTTP para o servidor do vLLM. O motor organiza as solicitações, separa o processamento de entrada da geração de tokens e escolhe como ocupar os recursos disponíveis da GPU ou da CPU.

Um dos conceitos centrais é o PagedAttention, que administra a memória usada pelo mecanismo de atenção em blocos. A ideia lembra um sistema operacional que distribui páginas de memória conforme a necessidade, evitando reservar grandes regiões contínuas para cada conversa.

O vLLM também usa continuous batching. Em vez de esperar que um lote inteiro termine para começar outro, o servidor pode incluir e retirar requisições enquanto a geração avança. Isso ajuda a manter o hardware ocupado, mas o ganho depende do modelo, do tamanho dos prompts e da configuração escolhida.

💡
Dica

Meça tokens por segundo e tempo até o primeiro token no seu cenário. Um resultado de benchmark feito com prompts curtos não representa automaticamente uma aplicação com contexto longo.

Principais recursos

A versão 0.28.0 amplia o foco em modelos grandes e em ambientes heterogéneos. Há trabalho em decodificação especulativa, Model Runner V2, cache KV em camadas, quantização e execução distribuída, além de suporte a novos modelos e caminhos multimodais.

Na camada de API, a release adiciona recursos como prioridade por cabeçalho HTTP, identificação de sessão, contagem de tokens de raciocínio e suporte a partes de conteúdo no endpoint de geração. Também há uma frente Rust com renderer independente e inferência multimodal por gRPC.

Há mudanças práticas para quem atualiza um ambiente existente. O valor padrão de max_num_batched_tokens passou de 8192 para 16384, o prefix caching passou a vir habilitado por padrão para modelos Mamba e o suporte a bitsandbytes foi movido para um plugin externo.

  • Streaming de respostas para clientes que precisam exibir tokens progressivamente.
  • Paralelismo de tensor, pipeline, dados, experts e contexto conforme o hardware.
  • Integração com modelos compatíveis com o ecossistema Hugging Face.
  • Opções de cache e offloading para lidar com restrições de memória.

Como começar: instalação ou acesso passo a passo

O caminho mais direto é testar em uma máquina Linux com GPU compatível e um ambiente Python isolado. O comando de instalação publicado para a distribuição CUDA padrão é simples, mas a compatibilidade entre driver, versão CUDA, modelo e memória da placa precisa ser conferida antes.

Crie o ambiente, instale o pacote e suba um servidor local. O exemplo abaixo usa um modelo público do ecossistema Hugging Face. Na primeira execução, os pesos podem ocupar bastante espaço e o tempo de download depende da rede.

Python -m venv .venv; source .venv/bin/activate; pip install vllm; vllm serve Qwen/Qwen3-8B --host 0.0.0.0 --port 8000

A release também oferece artefatos para CUDA 13.0, CUDA 12.9, ROCm, CPU e XPU, incluindo imagens Docker específicas. Se você não tem uma GPU NVIDIA compatível, escolha o artefato correspondente ao ambiente em vez de copiar o primeiro comando sem validar os requisitos.

⚠️
Atenção

Não exponha a porta de desenvolvimento diretamente na internet. Coloque autenticação, limite de requisições e um proxy reverso antes de oferecer o endpoint a usuários reais.

Exemplo prático

Imagine uma equipe brasileira que quer criar um assistente interno para consultar procedimentos. O serviço pode rodar em uma máquina da empresa, receber perguntas pela aplicação web e devolver a resposta em streaming sem enviar o texto para um provedor externo.

Com o servidor ativo na porta 8000, um cliente Python pode usar a interface compatível com o formato de chat. A chave abaixo é apenas um valor local de exemplo; ela não representa autenticação pronta para produção.

from openai import OpenAI; client = OpenAI(base_url='http://localhost:8000/v1', api_key='local'); resposta = client.chat.completions.create(model='Qwen/Qwen3-8B', messages=[{'role': 'user', 'content': 'Explique PagedAttention em duas frases.'}]); print(resposta.choices[0].message.content)

O teste fica mais útil quando você registra o tamanho do prompt, o tempo até o primeiro token, a duração total, o número de tokens gerados e o uso de memória. Depois, repita a medição com duas ou mais requisições simultâneas para observar o efeito do batching.

Comparação com alternativas

O vLLM não é a única opção para servir LLMs. O Transformers é excelente para experimentar modelos dentro de um programa Python, mas um serviço concorrente costuma exigir que você construa a camada de fila e otimização. O llama.cpp é atraente quando a prioridade é rodar modelos quantizados em CPU ou em máquinas menores.

Serviços gerenciados de inferência reduzem o trabalho de operação, porque você não precisa cuidar diretamente de driver, GPU, escalabilidade e disponibilidade. Em troca, o custo recorrente, a localização dos dados e a dependência do fornecedor entram na decisão.

Como regra prática, use vLLM quando você quer controlar o servidor e precisa atender várias requisições com um modelo compatível. Prefira uma solução local mais simples para um experimento individual e um serviço gerenciado quando a equipe não quer assumir a operação do hardware.

Pontos positivos e limitações

O principal ponto positivo é a combinação de desempenho e flexibilidade. O projeto oferece batching contínuo, streaming, cache, paralelismo e uma interface de serviço que se aproxima de clientes já conhecidos, sem obrigar a equipe a implementar todo o motor de inferência.

Outro benefício é a velocidade de evolução. A versão 0.28.0 cobre novas arquiteturas, caminhos de quantização, hardware AMD e Intel, além de otimizações para modelos específicos. Para quem acompanha o projeto, isso abre espaço para testar recursos recentes antes que eles cheguem a abstrações mais simples.

A limitação é a complexidade operacional. O resultado depende de driver, versão de bibliotecas, memória, quantização e parâmetros de execução. Atualizações também podem exigir revisão de integração, especialmente quando há mudanças incompatíveis como a migração do bitsandbytes para plugin externo.

🔴
Cuidado

Não use uma atualização em produção apenas porque o número da versão é novo. Reproduza os testes com o seu modelo, compare qualidade e latência e confirme o comportamento dos endpoints que a sua aplicação realmente usa.

Casos de uso reais

Uma startup pode usar vLLM para manter um assistente de suporte com um modelo aberto e controlar o custo por atendimento. O time define limites de contexto, registra métricas e troca o modelo sem redesenhar a aplicação cliente.

Uma empresa de software pode disponibilizar geração de texto dentro de um produto SaaS. O batching ajuda quando vários clientes fazem pedidos ao mesmo tempo, enquanto o isolamento de dados e as políticas de retenção continuam sendo responsabilidade do produto.

Uma equipe de pesquisa pode comparar quantização, cache e decodificação especulativa em um laboratório. O mesmo servidor pode atender testes offline e chamadas HTTP, desde que o ambiente de produção seja separado do ambiente de experimentação.

Também há espaço para aplicações multimodais e fluxos de reinforcement learning. A release 0.28.0 traz recursos para inferência de imagens por gRPC, controle de ciclo de vida em RL e novos caminhos para encoders de visão, mas cada combinação exige validação própria.

Dicas e boas práticas

Comece com um único modelo e um único fluxo de requisição. Só depois de medir uma linha de base ajuste batching, tamanho de contexto, cache e paralelismo. Essa ordem facilita descobrir se um ganho veio da ferramenta ou apenas de uma mudança no teste.

💡
Dica

Separe métricas de entrada e saída. Prompts longos podem aumentar muito o tempo até o primeiro token, enquanto respostas longas pesam mais na duração total.

Trate a API como qualquer serviço crítico. Use timeout, fila, limites por cliente, logs sem dados sensíveis e monitoramento de erros. Se a aplicação atende múltiplas empresas, valide tenant e autorização antes de encaminhar a solicitação ao modelo.

🚀
Pro tip

Teste o prefix caching e o cache KV em camadas com prompts que realmente se repetem. Se cada solicitação for completamente diferente, reservar memória para cache pode não trazer o retorno esperado.

Leia as notas de release antes de atualizar. Na 0.28.0, por exemplo, defaults foram alterados e algumas APIs antigas foram removidas. Fixar a versão no ambiente e manter um teste de fumaça para geração, streaming e structured outputs reduz surpresas.

Vale a pena?

Para quem precisa servir um modelo aberto com controle sobre infraestrutura, o vLLM 0.28.0 merece um teste. Ele é especialmente interessante quando há concorrência, uma GPU relevante e vontade de medir custo e latência com mais precisão.

Ele não é a escolha automática para todo projeto. Uma aplicação pequena pode começar com uma biblioteca local mais simples, enquanto uma equipe sem experiência em operação de GPU pode economizar tempo usando uma oferta gerenciada.

O próximo passo é montar um benchmark com o seu modelo, três tamanhos de prompt e diferentes níveis de concorrência. Compare qualidade, tempo até o primeiro token, tokens por segundo, memória e custo por resposta antes de decidir se a versão 0.28.0 entra no ambiente de produção.