¿Por Qué Netflix Construyó su Propio Stack de Serving de LLMs?

La mayoría de los equipos consumen LLMs a través de APIs hospedadas. Netflix fue más allá—ejecutando todo el stack, desde el despliegue hasta la inferencia, dentro de su entorno de producción existente. Esto no fue solo para evitar vendor lock-in; fue para lograr baja latencia, personalización profunda e integración perfecta con la infraestructura de ML de la empresa.

La arquitectura de la plataforma refleja un principio clave: los LLMs no deben ser tratados como casos especiales. Cada modelo, desde ensembles XGBoost hasta LLMs de gran escala, se sirve a través de un sistema unificado basado en JVM que maneja enrutamiento, pruebas A/B, feature fetching, inferencia y logging. Este enfoque unificado reutiliza bibliotecas de cliente, health checks y pipelines de despliegue, reduciendo la complejidad operativa.

Pero construir esta plataforma vino con trade-offs difíciles. Cuatro decisiones la moldearon—elección del motor, empaquetado de modelos, diseño de API y estrategia de despliegue. Cada una influyó en la siguiente, y la producción reveló lecciones que las fases de diseño a menudo no anticipan.

Netflix GPU inference cluster with Triton and vLLM servers Algorithm Concept Visual

Decisiones Clave de Diseño y sus Lecciones de Producción

1. Eligiendo vLLM como Motor Predeterminado

Netflix inicialmente construyó sobre TensorRT-LLM, un motor de alto rendimiento integrado con Triton. Para el verano de 2025, los motores de código abierto habían cerrado en gran medida la brecha de rendimiento, y la carga de trabajo se diversificó para incluir generación de embeddings, inferencia prefill-only para ranking y retrieval, decodificación autoregresiva y modelos personalizados. Después de re-benchmarking, eligieron vLLM por:

  • Flexibilidad: Carga arquitecturas personalizadas sin compilación de múltiples pasos.
  • Extensibilidad: Hooks para lógica de decodificación personalizada, esencial para decodificación restringida.
  • Depurabilidad: Más fácil inspeccionar fallos que motores compilados.
  • Familiaridad: Muchos practicantes de ML ya usaban vLLM en investigación.

2. Empaquetando Modelos: vLLM Backend vs. Python Backend

Triton ofrece dos formas de empaquetar modelos, y la elección impacta significativamente el mantenimiento:

  • Python backend: El autor define especificaciones explícitas de tensores de I/O en el empaquetado. Estas especificaciones se congelan en el artefacto y deben coincidir con lo que el frontend espera. Cada actualización de frontend que toca las especificaciones de I/O requiere cambios coordinados, o las solicitudes fallan en runtime.
  • vLLM backend: El artefacto es solo un JSON config apuntando a los pesos del modelo y tokenizer. Triton genera las especificaciones de I/O dinámicamente, permitiendo que modelos y frontend evolucionen independientemente.

El vLLM backend es el default arquitectónicamente correcto, pero la producción expuso dos problemas:

  • Desajuste de versión: El vLLM backend de Triton está compilado contra una API específica de vLLM. Cuando divergen, el backend falla al cargar. La plataforma debe fijar versiones compatibles y evitar que los autores de modelos sobrescriban la versión.
  • Lógica de modelo personalizada: Modelos que necesitan pre/post-procesamiento personalizado o ejecución no estándar deben usar el Python backend para control total. Este escape hatch sigue siendo necesario para un subconjunto de modelos.

3. Frontend HTTP Compatible con OpenAI

Para evitar tratar los LLMs como casos especiales, Netflix expone tanto gRPC como una API compatible con OpenAI. La interfaz compatible con OpenAI se ha convertido en el estándar de facto para el ecosistema de LLMs, por lo que adoptarla permite una transición perfecta de modelos hospedados a modelos self-hosted fine-tuned.

Detrás de la API, Netflix reutiliza el frontend compatible con OpenAI de Triton, pero corrigió una brecha crítica: response_format se descartaba silenciosamente antes de llegar a vLLM, por lo que las solicitudes JSON procedían sin decodificación guiada y podían devolver JSON malformado sin error. Ahora traducen response_format a los parámetros de decodificación guiada de vLLM en el momento de la solicitud.

4. Estrategias de Despliegue: Red-Black vs. Versionado

Los despliegues de GPU toman más tiempo que los servicios de CPU, y los esquemas de I/O pueden cambiar entre versiones. Netflix ofrece dos estrategias:

  • Red-Black: Despliega una nueva versión junto a la actual, cambia el tráfico en fases y soporta rollback atómico. Ideal cuando la interfaz del modelo es estable, pero falla cuando los cambios de esquema de I/O requieren actualizaciones coordinadas de los consumidores.
  • Versionado: Mantiene despliegues independientes para cada par (modelId, modelVersion). Los consumidores pueden esperar a que la nueva versión esté lista antes de cambiar, mientras las versiones antiguas siguen sirviendo tráfico heredado. El trade-off es el costo temporal de GPU durante la transición.

Recomendación: Incorpore configuraciones variables (como formas de tensores) directamente en el modelo de inferencia para hacerlo agnóstico de versión, permitiendo el camino Red-Black más barato.

Notas Operativas: Secuencia de Arranque y Métricas

Dos detalles operativos tomaron por sorpresa a la producción:

  • Latencia de cold-start: Descargar LLMs grandes al inicio es lento. Netflix materializa modelos en Amazon FSx en el momento del anuncio, por lo que los warm starts usan un sistema de archivos de alto rendimiento.
  • Métricas unificadas: vLLM escribe métricas en PROMETHEUS_MULTIPROC_DIR como archivos .db; Triton reporta las suyas. El puente integrado expone solo 9 de 40+ métricas de vLLM. Netflix agregó un proxy HTTP ligero que fusiona ambos en un solo endpoint /metrics, por lo que los dashboards y alertas existentes funcionan sin modificación.

Developer monitoring LLM serving metrics and constrained decoding Programming Illustration

Inmersión Profunda: Decodificación Restringida a Escala

Algunas cargas de trabajo de producción requieren control fino sobre la generación de tokens. Netflix empuja restricciones dentro del bucle de decodificación usando la interfaz de custom logits processor de vLLM, modelando cada restricción como una máquina de estados. Esto garantiza que las salidas sean conformes por construcción, evitando validación post-inferencia costosa.

Por Qué la Primera Implementación No Escalaba

En vLLM V0, los custom logits processors se ejecutan por solicitud. La GPU produce logits para todo el batch, pero la CPU los procesa secuencialmente debido al GIL. El tiempo de CPU crece linealmente con el tamaño del batch, causando latencias de cola. Este cuello de botella es invisible en benchmarks de una sola solicitud, pero aparece bajo concurrencia realista.

vLLM V1: Diseño a Nivel de Batch

vLLM V1 movió el procesamiento de logits al nivel de batch. Netflix reescribió el procesador para operar en estructuras de datos de batch, y reimplementó el hot path en C++ con multi-threading para evitar el GIL. La API V1 requiere seguimiento explícito de cambios de membresía mediante update_state(batch_update), que es más complejo pero necesario para la corrección.

Endurecimiento Operativo

La lógica de restricción con estado introdujo dos problemas:

  • Prefills parciales: V1 realiza chunked prefill, por lo que una solicitud puede ser prefillada en múltiples pasos del motor. BatchUpdate carece de granularidad para saber si una solicitud fue total o parcialmente prefillada, por lo que agregaron seguimiento interno.
  • Preempción: Bajo presión de memoria, vLLM puede desalojar una solicitud parcialmente completada y reprogramarla después con un prompt diferente. Esto rompe la suposición de la máquina de estados de que la lista de tokens de salida crece monotónicamente. Detectan cuando el historial de tokens se encoge y reinicializan desde el nuevo prompt.

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

Limitaciones y Próximos Pasos

Aunque la plataforma es robusta, varias áreas permanecen en desarrollo activo:

  • Compresión de system prompt para reducir la longitud sin sacrificar calidad.
  • Programación asíncrona de vLLM V1 para mejor utilización de recursos.
  • Logits processors vectorizados ejecutándose como kernels GPU fusionados en lugar de código CPU.
  • Variantes de modelo de menor precisión para disminuir la huella de memoria y aumentar el throughput.

Netflix continuará colaborando con la comunidad de código abierto para evolucionar este espacio.

Conclusión

La plataforma de serving de LLMs de Netflix demuestra que ejecutar LLMs a escala requiere trade-offs cuidadosos e iteración constante. Las lecciones—version pinning, brechas silenciosas de API, trade-offs de empaquetado—destacan la importancia del feedback de producción en la formación de la arquitectura. Para equipos que consideran un camino similar, comienza con una capa de serving unificada y prioriza la observabilidad operativa desde el principio.

Para más sobre optimización de rendimiento en producción, consulta nuestra guía sobre insights de rendimiento de consultas via Vercel CLI. Y si estás explorando nuevos estándares de comercio, mira nuestro análisis del Universal Commerce Protocol.

Fuente original: Netflix Tech Blog

Este contenido fue redactado con la asistencia de herramientas de IA, basándose en fuentes confiables, y fue revisado por nuestro equipo editorial antes de su publicación. No reemplaza el asesoramiento de un profesional especializado.