Por que a Netflix Construiu sua Própria Stack de Serving de LLMs

A maioria das equipes consome LLMs via APIs hospedadas. A Netflix foi além—rodando a stack completa, do deployment à inferência, dentro do seu ambiente de produção existente. Isso não foi apenas para evitar vendor lock-in; foi para alcançar baixa latência, customização profunda e integração perfeita com a infraestrutura de ML da empresa.

A arquitetura da plataforma reflete um princípio chave: LLMs não devem ser tratados como casos especiais. Cada modelo, de ensembles XGBoost a LLMs de grande escala, é servido através de um sistema unificado baseado em JVM que lida com roteamento, testes A/B, feature fetching, inferência e logging. Essa abordagem unificada reutiliza bibliotecas de cliente, health checks e pipelines de deploy, reduzindo a complexidade operacional.

Mas construir essa plataforma veio com trade-offs difíceis. Quatro decisões a moldaram—escolha do engine, empacotamento de modelos, design de API e estratégia de deploy. Cada uma influenciou a próxima, e a produção revelou lições que as fases de design muitas vezes não antecipam.

Netflix GPU inference cluster with Triton and vLLM servers Dev Environment Setup

Principais Decisões de Design e suas Lições de Produção

1. Escolhendo vLLM como Engine Padrão

A Netflix inicialmente construiu em TensorRT-LLM, um engine performático integrado ao Triton. Em meados de 2025, engines open-source já tinham praticamente fechado a lacuna de performance, e a carga de trabalho se diversificou para incluir geração de embeddings, inferência prefill-only para ranking e retrieval, decodificação autoregressiva e modelos customizados. Após re-benchmarking, eles escolheram vLLM por:

  • Flexibilidade: Carrega arquiteturas customizadas sem compilação multi-etapa.
  • Extensibilidade: Hooks para lógica de decodificação customizada, essencial para decodificação restrita.
  • Debuggabilidade: Mais fácil inspecionar falhas do que engines compilados.
  • Familiaridade: Muitos praticantes de ML já usavam vLLM em pesquisa.

2. Empacotando Modelos: vLLM Backend vs. Python Backend

O Triton oferece duas formas de empacotar modelos, e a escolha impacta a manutenibilidade significativamente:

  • Python backend: O autor define especificações explícitas de tensores de I/O no momento do empacotamento. Essas especificações são congeladas no artefato e devem corresponder ao que o frontend espera. Cada upgrade de frontend que toca nas especificações de I/O exige mudanças coordenadas, ou as requisições falham em runtime.
  • vLLM backend: O artefato é apenas um JSON config apontando para os pesos do modelo e tokenizer. O Triton gera as especificações de I/O dinamicamente, permitindo que modelos e frontend evoluam independentemente.

O vLLM backend é o default arquiteturalmente correto, mas a produção expôs dois problemas:

  • Mismatch de versão: O vLLM backend do Triton é compilado contra uma API específica do vLLM. Quando eles divergem, o backend falha ao carregar. A plataforma precisa fixar versões compatíveis e impedir que autores de modelo sobrescrevam a versão.
  • Lógica de modelo customizada: Modelos que precisam de pré/pós-processamento customizado ou execução não padrão devem usar o Python backend para controle total. Esse escape hatch continua necessário para um subconjunto de modelos.

3. Frontend HTTP Compatível com OpenAI

Para evitar tratar LLMs como casos especiais, a Netflix expõe tanto gRPC quanto uma API compatível com OpenAI. A interface compatível com OpenAI se tornou o padrão de facto para o ecossistema de LLMs, então adotá-la permite uma transição perfeita de modelos hospedados para modelos self-hosted fine-tuned.

Por trás da API, a Netflix reutiliza o frontend compatível com OpenAI do Triton, mas corrigiu uma lacuna crítica: response_format era silenciosamente descartado antes de chegar ao vLLM, então requisições JSON prosseguiam sem decodificação guiada e podiam retornar JSON malformado sem erro. Agora eles traduzem response_format para os parâmetros de decodificação guiada do vLLM no momento da requisição.

4. Estratégias de Deploy: Red-Black vs. Versionado

Deploys de GPU demoram mais que serviços de CPU, e schemas de I/O podem mudar entre versões. A Netflix oferece duas estratégias:

  • Red-Black: Deploya uma nova versão ao lado da atual, muda o tráfego em fases e suporta rollback atômico. Ideal quando a interface do modelo é estável, mas falha quando mudanças de schema de I/O exigem atualizações coordenadas dos consumidores.
  • Versionado: Mantém deploys independentes para cada par (modelId, modelVersion). Consumidores podem esperar a nova versão ficar pronta antes de mudar, enquanto versões antigas continuam servindo tráfego legado. O trade-off é o custo temporário de GPU durante a transição.

Recomendação: Incorpore configurações variáveis (como shapes de tensores) diretamente no modelo de inferência para torná-lo agnóstico de versão, permitindo o caminho Red-Black mais barato.

Notas Operacionais: Sequência de Boot e Métricas

Dois detalhes operacionais pegaram a produção de surpresa:

  • Latência de cold-start: Baixar LLMs grandes no startup é lento. A Netflix materializa modelos no Amazon FSx no momento do anúncio, então warm starts usam um filesystem de alta performance.
  • Métricas unificadas: vLLM escreve métricas em PROMETHEUS_MULTIPROC_DIR como arquivos .db; Triton reporta as suas. A ponte embutida expõe apenas 9 de 40+ métricas do vLLM. A Netflix adicionou um proxy HTTP leve que mescla ambos em um único endpoint /metrics, então dashboards e alertas existentes funcionam sem modificação.

Developer monitoring LLM serving metrics and constrained decoding System Abstract Visual

Mergulho Profundo: Decodificação Restrita em Escala

Algumas cargas de trabalho de produção exigem controle fino sobre a geração de tokens. A Netflix empurra restrições para dentro do loop de decodificação usando a interface de custom logits processor do vLLM, modelando cada restrição como uma máquina de estados. Isso garante que as saídas sejam conformes por construção, evitando validação pós-inferência cara.

Por que a Primeira Implementação Não Escalava

No vLLM V0, custom logits processors rodam por requisição. A GPU produz logits para o batch inteiro, mas a CPU os processa sequencialmente devido ao GIL. O tempo de CPU cresce linearmente com o tamanho do batch, causando latências de cauda. Esse gargalo é invisível em benchmarks de requisição única, mas aparece sob concorrência realista.

vLLM V1: Design em Nível de Batch

O vLLM V1 moveu o processamento de logits para o nível de batch. A Netflix reescreveu o processador para operar em estruturas de dados de batch, e reimplementou o hot path em C++ com multi-threading para contornar o GIL. A API V1 exige tracking explícito de mudanças de membership via update_state(batch_update), que é mais complexo, mas necessário para correção.

Endurecimento Operacional

A lógica de restrição stateful introduziu dois problemas:

  • Prefills parciais: V1 faz chunked prefill, então uma requisição pode ser prefillada em múltiplos passos do engine. BatchUpdate não tem granularidade para saber se uma requisição foi total ou parcialmente prefillada, então eles adicionaram tracking interno.
  • Preempção: Sob pressão de memória, o vLLM pode despejar uma requisição parcialmente completada e re-agendá-la depois com um prompt diferente. Isso quebra a suposição da máquina de estados de que a lista de tokens de saída cresce monotonamente. Eles detectam quando o histórico de tokens encolhe e reinicializam a partir do novo prompt.

Architecture diagram of Netflix LLM serving platform with gRPC and HTTP paths Software Concept Art

Limitações e Próximos Passos

Embora a plataforma seja robusta, várias áreas permanecem em desenvolvimento ativo:

  • Compressão de system prompt para reduzir o comprimento sem sacrificar qualidade.
  • Agendamento assíncrono do vLLM V1 para melhor utilização de recursos.
  • Logits processors vetorizados rodando como kernels GPU fundidos em vez de código CPU.
  • Variantes de modelo de menor precisão para diminuir footprint de memória e aumentar throughput.

A Netflix continuará colaborando com a comunidade open-source para evoluir esse espaço.

Conclusão

A plataforma de serving de LLMs da Netflix demonstra que rodar LLMs em escala exige trade-offs cuidadosos e iteração constante. As lições—version pinning, lacunas silenciosas de API, trade-offs de empacotamento—destacam a importância do feedback de produção na formação da arquitetura. Para times considerando um caminho similar, comece com uma camada de serving unificada e priorize observabilidade operacional desde o início.

Para mais sobre otimização de performance em produção, veja nosso guia sobre insights de performance de query via Vercel CLI. E se você está explorando novos padrões de comércio, veja nossa análise do Universal Commerce Protocol.

Fonte original: Netflix Tech Blog

Este conteúdo foi elaborado com o auxílio de ferramentas de IA, com base em fontes confiáveis, e revisado pela nossa equipe editorial antes da publicação. Não substitui o aconselhamento de um profissional especializado.