Deployment de vLLM em Produção: Construindo Arquitetura de Serving de Inferência de Alta Performance

Atualizado em 11 de dezembro de 2025

Atualização de dezembro de 2025: Stripe obtendo redução de 73% nos custos de inferência via migração para vLLM (50M de chamadas de API diárias com 1/3 da frota de GPUs). PagedAttention eliminando 60-80% do desperdício de memória da fragmentação do KV cache. vLLM entregando throughput de 2-24x versus serving convencional. Sendo usado em produção na Meta, Mistral AI, Cohere, IBM. APIs compatíveis com OpenAI simplificando a adoção.

A equipe da plataforma de ML do Stripe viu seus custos de inferência caírem 73% após migrar do Hugging Face Transformers para vLLM, processando as mesmas 50 milhões de chamadas de API diárias com um terço da frota de GPUs.¹ O segredo por trás da eficiência do vLLM reside no PagedAttention, um algoritmo que trata a memória da GPU como memória virtual em sistemas operacionais, eliminando a fragmentação que desperdiça 60-80% da memória em sistemas de inferência tradicionais.² Organizações executando workloads de LLM em produção descobrem que o vLLM oferece melhorias de throughput de 2-24x sobre frameworks de serving convencionais, transformando a economia de deployment de large language models em escala.³

O cenário de serving de inferência se fragmenta em dezenas de opções: TensorRT-LLM promete otimização máxima para NVIDIA, Hugging Face TGI oferece integração familiar, e Ollama simplifica o deployment local. No entanto, o vLLM emergiu como a escolha dominante para workloads de produção, alimentando inferência na Meta, Mistral AI, Cohere e IBM.⁴ A combinação do framework entre PagedAttention, continuous batching e APIs compatíveis com OpenAI cria uma experiência de deployment que equilibra performance bruta com simplicidade operacional. Entender a arquitetura do vLLM e padrões de deployment separa organizações que alcançam inferência custo-efetiva daquelas que afogam em contas de GPU.

PagedAttention transforma o gerenciamento de memória

A inferência tradicional de LLM aloca um bloco de memória contíguo para o cache key-value (KV) de cada sequência, reservando espaço para o comprimento máximo possível de sequência independentemente do uso real. Um sistema configurado para 4.096 tokens aloca essa memória completa mesmo para respostas de 100 tokens, desperdiçando 97% da capacidade reservada. Multiplique por centenas de requisições simultâneas e a memória da GPU se enche com reservas vazias enquanto sequências reais ficam em fila aguardando recursos.

PagedAttention reimagina essa arquitetura dividindo a memória da GPU em páginas de tamanho fixo, tipicamente 16 tokens cada.⁵ Cada sequência mantém uma lista de referências de páginas em vez de uma alocação contígua, habilitando várias capacidades revolucionárias:

Armazenamento não-contíguo permite que blocos de KV cache se espalhem pela memória disponível da GPU. O sistema não precisa mais de regiões contíguas grandes, eliminando a fragmentação que assola alocadores tradicionais. Uma sequência de 2.000 tokens armazena seu cache em 125 páginas distribuídas onde quer que exista espaço.

Alocação dinâmica provisiona memória apenas conforme as sequências crescem. O primeiro token aloca uma página. O décimo sétimo token dispara a alocação de uma segunda página. O consumo de memória rastreia o uso real em vez de máximos teóricos, melhorando dramaticamente a capacidade efetiva.

Compartilhamento de memória permite que prefixos de prompt idênticos compartilhem páginas de KV cache entre requisições. Dez usuários fazendo variações do mesmo prompt de sistema compartilham uma única cópia em cache desse prefixo, reduzindo o consumo de memória em 90% para padrões comuns. Sistemas de produção com prompts padronizados veem melhorias de utilização excedendo 400%.⁶

Desperdício quase zero elimina a fragmentação interna comum na alocação estática. Sistemas tradicionais desperdiçam em média 4,1 tokens por sequência em blocos parcialmente preenchidos. A granularidade em nível de página do PagedAttention reduz o desperdício para frações de uma página, tipicamente menos de 8 tokens por sequência independentemente do comprimento.

O algoritmo se inspira diretamente na memória virtual de sistemas operacionais, aplicando décadas de pesquisa em gerenciamento de memória para inferência em GPU. Assim como sistemas operacionais modernos mapeiam endereços virtuais para páginas de memória física, PagedAttention mapeia posições lógicas de KV cache para blocos físicos de memória da GPU. O overhead de tradução adiciona microssegundos a cada computação de attention mas economiza gigabytes de capacidade de memória.

Continuous batching maximiza utilização da GPU

Batching estático espera por um número fixo de requisições antes de processá-las juntas, criando picos de latência quando lotes se preenchem parcialmente e throughput cai quando requisições chegam irregularmente. Um tamanho de lote de 32 significa que a 31ª requisição espera por mais uma chegada antes do processamento começar, potencialmente adicionando segundos de latência durante períodos de tráfego baixo.

Continuous batching no vLLM elimina fronteiras de lote inteiramente.⁷ O scheduler opera em nível de iteração em vez de nível de requisição, tomando decisões a cada passada forward em vez de a cada lote. Quando uma sequência completa a geração, seu slot imediatamente aceita uma nova requisição sem esperar as sequências irmãs terminarem. A GPU processa qualquer trabalho que existe a cada momento, preenchendo lacunas que o batching estático deixa vazias.

A implementação requer coordenação cuidadosa entre gerenciamento de memória e scheduling:

Scheduling em nível de iteração avalia a fila de requisições a cada passo do decoder. Sequências completadas liberam seus slots, requisições aguardando reclamam capacidade disponível, e a próxima iteração prossegue com um lote otimalmente preenchido. Variância de latência entre requisições é absorvida em vez de amplificada.

Tratamento de preempção gerencia situações onde pressão de memória força a remoção de sequências. Requisições de menor prioridade fazem checkpoint do estado do KV cache e cedem memória da GPU para sequências de maior prioridade. Quando a capacidade retorna, sequências preemptadas resumem de seus checkpoints em vez de reiniciar do zero.

Prefix caching identifica requisições compartilhando prefixos comuns e as roteia para instâncias já mantendo páginas de KV cache relevantes. Um sistema de suporte ao cliente onde cada requisição começa com o mesmo contexto de 500 tokens serve tokens subsequentes do estado em cache, eliminando computação redundante de prefixo.

Benchmarks demonstram o impacto: vLLM alcança throughput de 793 tokens por segundo comparado a 41 tokens por segundo do Ollama em configurações equivalentes, com latência P99 de 80ms versus 673ms.⁸ A arquitetura de continuous batching mantém essas vantagens através de níveis de concorrência de 1 a 256 usuários simultâneos.

Arquitetura de produção escala através de clusters

Deployments de vLLM de nó único lidam com tráfego substancial, mas sistemas de produção requerem orquestração em todo o cluster para confiabilidade, escala e eficiência. A vLLM production-stack transforma o engine de inferência em um sistema de serving completo com quatro adições críticas.⁹

Roteamento de requisições direciona consultas recebidas para instâncias de backend apropriadas baseado em chaves de roteamento, IDs de sessão ou correspondência de prefixo. Roteamento inteligente maximiza a reutilização de KV cache enviando requisições relacionadas para instâncias já mantendo contexto relevante. Uma conversa com múltiplas interações roteia consistentemente para o mesmo backend, evitando computação redundante de prefixo entre instâncias.

Compartilhamento de KV cache estende a eficiência de memória do PagedAttention através de múltiplas instâncias vLLM através do projeto LMCache. Backends compartilham blocos computados de KV cache sobre interconexões de alta velocidade, habilitando cache hits mesmo quando requisições roteiam para instâncias diferentes. Sistemas com workloads repetitivos veem redução de latência de 3-10x e melhoria de throughput de 2-5x do compartilhamento de cache entre instâncias.¹⁰

Integração de observabilidade expõe métricas através de Prometheus e visualização através de dashboards Grafana. Métricas por requisição capturam time-to-first-token (TTFT), time-between-tokens (TBT) e latência end-to-end. Métricas por instância rastreiam utilização da GPU, pressão de memória, profundidade da fila e taxas de cache hit. Equipes de operações ganham visibilidade em gargalos de performance e dados de planejamento de capacidade.

Escalabilidade horizontal adiciona e remove instâncias vLLM baseado em sinais de demanda. Deployments Kubernetes usam Horizontal Pod