Implantação de vLLM em Produção: Construindo Arquitetura de Inferência de Alta Vazão
Atualizado em 11 de dezembro de 2025
Atualização de Dezembro de 2025: Stripe alcançando 73% de redução nos custos de inferência via migração para vLLM (50M de chamadas de API diárias em 1/3 da frota de GPUs). PagedAttention eliminando 60-80% do desperdício de memória por fragmentação do KV cache. vLLM entregando 2-24x de vazão vs. serving convencional. Alimentando produção na Meta, Mistral AI, Cohere, IBM. APIs compatíveis com OpenAI simplificando adoção.
A equipe de plataforma de ML da Stripe observou seus custos de inferência caírem 73% após migrar do Hugging Face Transformers para vLLM, processando os mesmos 50 milhões de chamadas de API diárias em um terço da frota de GPUs.¹ O segredo por trás da eficiência do vLLM está 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 cargas de trabalho de LLM em produção descobrem que o vLLM entrega melhorias de vazão de 2-24x sobre frameworks de serving convencionais, transformando a economia de implantação de grandes modelos de linguagem 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 implantação local. No entanto, vLLM emergiu como a escolha dominante para cargas de trabalho de produção, alimentando inferência na Meta, Mistral AI, Cohere e IBM.⁴ A combinação do framework de PagedAttention, continuous batching e APIs compatíveis com OpenAI cria uma experiência de implantação que equilibra desempenho bruto com simplicidade operacional. Entender a arquitetura e os padrões de implantação do vLLM separa organizações que alcançam inferência custo-efetiva daquelas afogadas 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 de 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 de reservas vazias enquanto sequências reais ficam na fila esperando 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 dispersem pela memória de GPU disponível. O sistema não precisa mais de grandes regiões contíguas, 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 uma segunda alocação de página. O consumo de memória acompanha 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 em alocação estática. Sistemas tradicionais desperdiçam uma média de 4,1 tokens por sequência em blocos parcialmente preenchidos. A granularidade em nível de página do PagedAttention reduz o desperdício a 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 à 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 de memória física da GPU. A sobrecarga de tradução adiciona microssegundos a cada computação de atenção, mas economiza gigabytes de capacidade de memória.
Continuous batching maximiza a utilização de GPU
Static batching espera por um número fixo de requisições antes de processá-las juntas, criando picos de latência quando batches se preenchem parcialmente e queda de vazão quando requisições chegam desigualmente. Um tamanho de batch 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 baixo tráfego.
Continuous batching no vLLM elimina completamente os limites de batch.⁷ O scheduler opera em nível de iteração em vez de nível de requisição, tomando decisões a cada forward pass em vez de a cada batch. Quando uma sequência completa a geração, seu slot imediatamente aceita uma nova requisição sem esperar que sequências irmãs terminem. A GPU processa qualquer trabalho que exista em cada momento, preenchendo lacunas que o static batching 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 em espera reivindicam capacidade disponível, e a próxima iteração prossegue com um batch otimamente preenchido. A 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 evacuação de sequências. Requisições de menor prioridade fazem checkpoint do estado do seu KV cache e cedem memória de GPU para sequências de maior prioridade. Quando a capacidade retorna, sequências preemptadas retomam de seus checkpoints em vez de recomeçar 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 vazão de 793 tokens por segundo comparado aos 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
Implantações de vLLM em 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. O vLLM production-stack transforma o motor de inferência em um sistema de serving completo com quatro adições críticas.⁹
Roteamento de requisições direciona consultas de entrada 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últiplos turnos é roteada 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 via projeto LMCache. Backends compartilham blocos de KV cache computados através de interconexões de alta velocidade, habilitando cache hits mesmo quando requisições são roteadas para instâncias diferentes. Sistemas com cargas de trabalho repetitivas veem redução de latência de 3-10x e melhoria de vazão de 2-5x do compartilhamento de cache entre instâncias.¹⁰
Integração de observabilidade expõe métricas através do 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 ponta a ponta. Métricas por instância rastreiam utilização de GPU, pressão de memória, profundidade de fila e taxas de cache hit. Equipes de operações ganham visibilidade em gargalos de desempenho e dados de planejamento de capacidade.
Escalonamento horizontal adiciona e remove instâncias vLLM baseado em sinais de demanda. Implantações Kubernetes usam Horizontal Pod Autoscaler com métricas customizadas visando profundidade de fila ou percentis de latência. A camada de router automaticamente descobre novas instâncias e rebalanceia tráfego, habilitando capacidade elástica que acompanha a demanda real.
A implantação segue padrões Kubernetes padrão através de Helm charts:
# values.yaml for vLLM production-stack
replicaCount: 4
model:
name: "meta-llama/Llama-3.1-70B-Instruct"
tensorParallelism: 4
resources:
limits:
nvidia.com/gpu: 4
router:
enabled: true
prefixAwareRouting: true
observability:
prometheus: true
grafana: true
O stack implantado expõe uma API compatível com OpenAI através de um serviço Kubernetes, habilitando substituição direta para aplicações atualmente chamando endpoints OpenAI ou Azure OpenAI. Bases de código existentes requerem apenas mudanças de URL de endpoint para migrar de APIs de nuvem para inferência auto-hospedada.
Requisitos de infraestrutura moldam decisões de implantação
A eficiência de memória do vLLM habilita modelos maiores em configurações de GPU menores, mas a seleção de hardware ainda determina características de desempenho. Entender a relação entre tamanho do modelo, memória de GPU e vazão informa decisões de aquisição.
Memória de GPU restringe tamanho máximo do modelo e capacidade de batch concorrente. Um modelo de 70B parâmetros em FP16 requer 140GB apenas para pesos, necessitando tensor parallelism multi-GPU em qualquer hardware atual. O mesmo modelo em quantização INT4 cabe em 35GB, implantável em um único A100 80GB ou H100 com margem substancial para KV cache. A largura de banda de memória frequentemente limita a vazão mais que o compute bruto, tornando GPUs equipadas com HBM3 desproporcionalmente efetivas.
Tensor parallelism divide camadas do modelo através de múltiplas GPUs dentro de um nó, essencial para modelos excedendo memória de GPU única. vLLM suporta graus de tensor parallel correspondendo à contagem de GPUs, automaticamente fragmentando camadas de atenção e feed-forward. Um nó de 8 GPUs executando tensor parallelism de 8 serve um modelo de 405B parâmetros que de outra forma requereria múltiplos nós com pipeline parallelism mais lento.
Fabric de rede se torna crítico para implantações multi-nó. Pipeline parallelism através de nós requer interconexões de baixa latência e alta largura de banda entre estágios. Redes InfiniBand ou RoCE com largura de banda de 200-400Gbps suportam serving multi-nó eficiente, enquanto Ethernet padrão introduz latência que degrada substancialmente o time-to-first-token.
Vazão de armazenamento impacta desempenho de cold start ao carregar pesos do modelo. Um modelo de 70B em FP16 requer transferir 140GB do armazenamento para memória de GPU antes de servir as primeiras requisições. Armazenamento NVMe entregando 7GB/s carrega o modelo em 20 segundos; armazenamento conectado por rede a 500MB/s leva 5 minutos. Sistemas de produção ou mantêm instâncias warm standby ou implementam estratégias de cache de modelo para minimizar impacto de cold start.
A Introl ajuda organizações a projetar infraestrutura vLLM através da nossa área de cobertura global, correspondendo configurações de hardware a requisitos de carga de trabalho enquanto otimiza para eficiência de custo.¹¹ Nossos engenheiros implantaram infraestrutura de inferência servindo bilhões de requisições mensalmente, entendendo as nuances que separam implantações funcionais de sistemas altamente otimizados.
Comparando vLLM contra alternativas
O ecossistema de serving de inferência oferece múltiplos frameworks, cada um com pontos fortes distintos. Selecionar a ferramenta certa requer corresponder capacidades do framework a características da carga de trabalho.
TensorRT-LLM entrega desempenho máximo em hardware NVIDIA através de otimização agressiva de kernel e compilação de grafos. Benchmarks mostram TensorRT-LLM alcançando 10.000+ tokens de saída por segundo em H100 com quantização FP8, com time-to-first-token em torno de 100ms.¹² A contrapartida: setup complexo requerendo conversão de checkpoint, construção de engine e configuração extensiva através de TensorRT-LLM, tensorrtllm_backend e Triton Inference Server. Organizações com equipes dedicadas de infraestrutura de ML e implantações de modelo estáveis se beneficiam mais.
**Hugging Fa
[Conteúdo truncado para tradução]
