El stack vLLM y Triton de Netflix: 7 lecciones de producción
La versión viral de esta historia es sencilla: Netflix dejó de pagar a un proveedor de IA y lo construyó todo por su cuenta. La versión útil exige más precisión. Los equipos de AI Platform de Netflix describieron una vía interna para servir LLM con NVIDIA Triton y vLLM. Explicaron por qué encajaba con sus cargas, dónde falló bajo concurrencia real y qué tuvieron que construir alrededor.
Esa diferencia importa si estás decidiendo una arquitectura de inferencia. Copiar la lista de componentes te da software. Copiar los límites de decisión te da un modelo operativo. Este artículo extrae esos límites y deja el coste, la residencia de datos y el equilibrio general en su página propietaria: nuestra guía sobre cuándo compensa autoalojar un LLM en la UE.
¿Netflix usa OpenAI?
No es correcto concluir que Netflix nunca usa OpenAI. En otro sistema de Netflix, MediaFM, el equipo dice que utilizó text-embedding-3-large de OpenAI para texto temporizado y metadatos de títulos. El artículo de serving demuestra que Netflix opera una vía interna con vLLM y Triton para cargas seleccionadas. No demuestra una prohibición corporativa de modelos alojados.
La lección para un comprador es más fuerte que el titular absoluto: una cartera de IA madura puede usar distintas vías de inferencia para trabajos distintos. Las APIs alojadas sirven para experimentos rápidos o capacidades caras de reproducir. El serving interno sirve para modelos propios, reglas de decoding propietarias, carga predecible o mayor control. La arquitectura debe seguir el límite de la carga, no un eslogan para toda la empresa.
¿Cómo es la arquitectura de serving LLM de Netflix?
El diseño público tiene cuatro capas. Las aplicaciones existentes llaman por gRPC a un sistema de serving unificado sobre JVM. Ese sistema controla el routing, la asignación A/B, la obtención de features y el preprocesado y posprocesado. Los modelos grandes se delegan a Model Scoring Service, el backend común de inferencia. Debajo, NVIDIA Triton gestiona la carga de modelos y la ejecución en GPU, mientras vLLM es el motor preferente para las cargas LLM.
- Contrato del consumidor: los servicios usan la misma abstracción de scoring para ML clásico y LLM.
- Flujo de serving: routing, experimentos y preparación de datos quedan fuera del motor.
- Plano de control: despliegue, salud, autoscaling, versiones y rollout multirregión siguen siendo responsabilidades de plataforma.
- Plano de inferencia: Triton aloja los backends y vLLM controla scheduling, batching y decoding.
Las aplicaciones LLM nuevas también pueden usar un frontend HTTP compatible con OpenAI. Es una decisión de interfaz, no una prueba de que OpenAI aloje el modelo. Separar protocolo y proveedor permite conservar un cliente conocido mientras la plataforma cambia el motor que hay detrás.
¿Por qué eligió Netflix vLLM en vez de TensorRT-LLM?
Netflix empezó con TensorRT-LLM. Para el verano de 2025, su equipo consideró que los motores open source habían reducido la brecha de rendimiento para su mezcla de cargas. El encaje operativo pasó a decidir. vLLM cargaba arquitecturas propias sin el anterior proceso de compilación en varios pasos, ofrecía hooks para decoding propio, facilitaba inspeccionar estados intermedios y ya era conocido por los investigadores.
| Factor | Por qué importaba | Pregunta para tu equipo |
|---|---|---|
| Ritmo de cambio | Los modelos propios llegaban a serving sin otro flujo de artefactos compilados | ¿Con qué frecuencia cambian las capas o formas del modelo? |
| Depuración | El estado y los fallos eran más fáciles de inspeccionar | ¿Quién diagnostica una carga fallida a las 02:00? |
| Extensión del decoding | Los logits processors propios eran centrales | ¿Necesitas reglas que una API de salida estructurada no expresa? |
| Familiaridad | Los investigadores ya usaban vLLM | ¿Pueden reproducir el comportamiento de producción antes del handover? |
| Benchmark máximo | Importante, pero no decisivo de forma aislada | ¿Tu prueba refleja modelos, batches y restricciones reales? |
No es un veredicto universal sobre vLLM y TensorRT-LLM. Ambos proyectos siguen cambiando. Es un método repetible: mide tu carga real y después valora el camino de ingeniería entre investigación, despliegue, depuración y rollback. Unos tokens más por segundo no compensan una plataforma que tu equipo no puede cambiar con seguridad.
¿Por qué chocó el decoding restringido con el GIL de Python?
El decoding restringido impide tokens inválidos durante la generación en lugar de reparar una salida malformada después. Netflix modeló cada restricción como una máquina de estados que producía una máscara de tokens permitidos en cada paso. En vLLM V0, el procesador Python propio se ejecutaba por petición. La GPU producía logits en batch y después la lógica de CPU procesaba cada petición en serie. El tiempo de CPU crecía con el batch porque el Global Interpreter Lock de Python impedía paralelizar el camino crítico.
vLLM V1 añadió un modelo a nivel de batch. Netflix reescribió el procesador sobre estructuras de batch y llevó el camino crítico a C++ multihilo. La documentación actual de vLLM también define una interfaz de logits processors a nivel de batch cuya función apply recibe el tensor de logits completo.
La dificultad no desapareció. Los batches dinámicos requieren actualizaciones explícitas de estado. Un prefill dividido puede durar varios pasos. Bajo presión de memoria, la preemption puede expulsar el KV cache y reprogramar la petición con un historial más corto. Netflix añadió seguimiento del prefill parcial y reinició la máquina de estados cuando el historial se reducía. El tiempo plano llegó de un nuevo modelo de estado, no de cambiar de versión sin más.
Siete lecciones de producción que sí conviene copiar
1. Elige por encaje operativo y después mide
Usa modelos, concurrencia, longitud de prompts y respuestas y restricciones representativas. Mide time to first token, latencia entre tokens, throughput y cola de latencia. Incluye el tiempo de empaquetar, diagnosticar y actualizar. Un motor forma parte de un sistema de release.
2. Mantén el contrato del consumidor por encima del motor
Netflix no obligó a cada caller a entender vLLM. Su capa existente siguió controlando routing, experimentos y lógica de flujo. Un contrato interno estable permite cambiar de motor sin reescribir cada integración. El mismo principio aparece en nuestra arquitectura de producción para una plataforma LLM con estado: el comportamiento duradero del producto no debe depender de un runtime.
3. Fija todo el conjunto compatible
El backend vLLM de Triton depende de una superficie concreta de vLLM. Netflix informó de un backend que dejó de cargar cuando las versiones divergieron. NVIDIA publica una matriz de compatibilidad de Triton y vLLM. Trata imagen de Triton, versión de vLLM, CUDA, driver y plugins como una unidad probada. No permitas que un paquete de modelo sustituya una pieza por separado.
4. Prueba la semántica de API, no solo el código 200
Netflix descubrió que el frontend compatible con OpenAI aceptaba response_format, pero lo descartaba antes de vLLM. La llamada terminaba bien y la restricción prometida desaparecía. Netflix corrigió la traducción. La documentación del frontend OpenAI para Triton muestra cómo se compone con vLLM, pero tus contract tests deben verificar el efecto de cada campo del que dependa el producto.
5. Ajusta el rollout al riesgo de interfaz
Netflix usa Red-Black cuando la interfaz del modelo es estable. La versión nueva arranca junto a la anterior, supera health checks y recibe tráfico por fases. Un cambio de forma de tensor rompe esa coordinación. Los despliegues versionados mantienen ambas interfaces hasta que migren los consumidores. El coste temporal de GPU compra una ventana segura.
6. Coloca los pesos en una ruta de arranque asumible
Las descargas grandes desde object storage alargaban demasiado los cold starts, así que Netflix materializó modelos anunciados en Amazon FSx. AWS explica que un archivo de FSx for Lustre enlazado a S3 paga latencia en el primer acceso salvo que el equipo precargue su contenido. La regla general no depende del proveedor: la colocación de pesos forma parte del despliegue, se verifica antes de readiness y se mide en un nodo vacío.
7. Une la observabilidad del motor y del servidor
El bridge de Triton mostraba solo parte de las métricas vLLM que Netflix necesitaba. El equipo fusionó las métricas de Triton y los archivos Prometheus de vLLM en un endpoint. Tu panel mínimo debe conectar tasa, cola, time to first token, latencia entre tokens, throughput, uso del KV cache, prefix-cache hits, preemption, estado de carga, errores y saturación de GPU. Una GPU verde puede convivir con un camino de logits en CPU roto.
¿Debe tu empresa copiar a Netflix o usar una API alojada?
| Señal | Inferencia alojada o gestionada | Plataforma interna vLLM y Triton |
|---|---|---|
| Demanda | Baja, incierta o irregular | Estable para planificar capacidad GPU |
| Modelo | Modelos y funciones estándar | Arquitecturas, plugins o decoding propios |
| Cambios | El proveedor opera las actualizaciones | Un equipo fija, prueba y revierte el stack |
| Datos | El procesamiento contratado es aceptable | La inferencia queda en infraestructura controlada |
| Observabilidad | Las métricas del proveedor bastan | Necesitas evidencia de tokens, caché y scheduler |
| Fallos | Prefieres el failover del proveedor | Puedes operar varias versiones y guardias |
Elige una plataforma interna solo si al menos un requisito diferenciador sobrevive una evaluación seria de servicios gestionados. El decoding propio, una carga alta y estable o un límite estricto de datos pueden justificarla. No querer facturas por token no es, por sí solo, una arquitectura.
Un plan práctico de validación en 90 días
- Semanas 1 y 2, contrato: fija prompts, schemas, objetivos de latencia, evaluaciones y fallos. Registra el baseline alojado.
- Semanas 3 a 5, benchmark real: prueba motores con concurrencia, restricciones y variantes representativas. Incluye CPU y cold starts.
- Semanas 6 a 8, operaciones: fija imágenes, precarga pesos, unifica métricas y ensaya fallo de carga y rollback.
- Semanas 9 y 10, tráfico sombra: compara calidad, latencia y cumplimiento de schema sin respuestas visibles.
- Semanas 11 a 13, decisión comercial: compara el coste completo de plataforma con la factura alojada, incluyendo ingeniería, redundancia, soporte y upgrades.
Si la latencia es el problema principal, separa la arquitectura de serving de la propiedad del modelo. Nuestro análisis de una KV cache compartida que redujo el time to first token muestra cuánto puede aportar una mejora concreta sin sustituir toda la vía.
Preguntas sobre Netflix, vLLM y Triton
¿Netflix ejecuta toda su inferencia LLM internamente?
¿Por qué prefirió Netflix vLLM a TensorRT-LLM?
¿Qué causó el cuello de botella del decoding restringido?
¿Hace falta NVIDIA Triton para usar vLLM?
¿Cuándo debería una empresa menor autoalojar la inferencia?
El límite que debes poseer es el operativo
La mejor lección de Netflix no es una lista de marcas. Es el orden de propiedad: contrato estable, selección con cargas reales, runtime fijado, pruebas semánticas de API, rollout según riesgo, pesos en la ruta de despliegue y una vista común de CPU, caché, scheduler y GPU.
El trabajo de AI enablement y arquitectura de inferencia de Wavect cubre esa evaluación desde el benchmark hasta el handover. El caso Twinsoft AI muestra cómo convertimos decisiones de IA en un flujo de producto probado. Usa nuestra guía del prototipo a producción para dimensionar el resto de la plataforma, o solicita una revisión de arquitectura de inferencia con tus restricciones de tráfico, datos y modelos.