💻 computer science

Video-Rate Streaming Stylization on a Vision-Aware MLLM-Conditioned Edit Diffusion: Asymmetric Batched Inference on a Distilled UNet + MLLM Text Encoder

Este artículo presenta un pipeline de estilización de transmisión a velocidad de video que supera el cuello de botella del codificador de texto en la difusión de edición condicionada por MLLM al combinar una U-Net destilada de 0.39B con un codificador Qwen3-VL de 2.13B, utilizando inferencia por lotes asimétrica y optimizaciones de grafo fusionadas para alcanzar hasta 74.1 fps en GPUs de consumo.

Autores originales: Yoshiyuki Ootani

Publicado 2026-06-05

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Yoshiyuki Ootani

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que tienes un estudio de arte mágico donde un robot pintor puede convertir instantáneamente cualquier video en una pintura al óleo. Normalmente, la parte más lenta de este proceso es el propio pintor (la "U-Net"), que tarda tiempo en mezclar colores y aplicar pinceladas.

Sin embargo, este artículo describe una nueva configuración donde el pintor ha sido superentrenado para trabajar increíblemente rápido, tan rápido que ya no son el cuello de botella. En su lugar, el nuevo "lento" es el Director de Arte (una IA masiva llamada MLLM). Antes de que el pintor pueda empezar, el Director de Arte tiene que observar el fotograma del video y las instrucciones del usuario (por ejemplo, "haz que parezca un Van Gogh") y escribir un informe detallado. Debido a que el Director de Arte es tan pesado y complejo, detiene toda la línea, incluso cuando el pintor ya está listo.

Los autores construyeron un sistema para resolver este problema específico: ¿Cómo mantener el flujo de video fluido cuando el Director de Arte es lento, pero el Pintor es rápido?

Así es como lo hicieron, utilizando tres trucos principales:

1. La línea de montaje de "dos vías" (Pipeline Asimétrico)

Imagina una fábrica con dos cintas transportadoras funcionando una al lado de la otra.

La Cinta Principal: El rápido Pintor trabaja en el fotograma actual.
La Cinta Lateral: El lento Director de Arte trabaja en las instrucciones del siguiente fotograma mientras el Pintor está ocupado.

Al ejecutar estas dos tareas al mismo tiempo en diferentes "vías" (streams de CUDA), el sistema oculta la lentitud del Director de Arte. Mientras el Pintor está ocupado pintando el Fotograma 1, el Director de Arte ya está leyendo las instrucciones para el Fotograma 2. Para cuando el Pintor termina, las instrucciones para el siguiente fotograma ya están listas. Esto mantiene la línea en movimiento sin detenerse.

2. La estrategia del "Informe Grupal" (Inferencia por Lotes)

El Director de Arte es lento, pero se vuelve más rápido si procesa a un grupo de personas a la vez en lugar de una por una.

En lugar de pedirle al Director de Arte que escriba un informe para solo un fotograma, el sistema reúne un lote de 8 o 16 fotogramas.
El Director de Arte escribe un informe masivo y eficiente que cubre todos ellos.
Este "descuento por volumen" en tiempo significa que el Director de Arte pasa menos tiempo por fotograma, aunque esté procesando más datos a la vez.

3. El programa de "Refresco Inteligente" (Condicionamiento Periódico)

A veces, las instrucciones no necesitan ser reescritas para cada fotograma. Si el video es solo una persona caminando, el "estilo de pintura al óleo" no necesita recalcularse cada milisegundo.

El sistema utiliza un "programa de refresco". Calcula las instrucciones de estilo detalladas una vez, luego reutiliza esa misma instrucción para varios fotogramas seguidos.
Solo se detiene para recalcular las instrucciones cuando la escena cambia significamente o después de un número determinado de fotogramas.
Esto ahorra una enorme cantidad de tiempo porque el sistema no desperdicia energía volviendo a hacerle la misma pregunta al Director de Arte una y otra vez.

Los Resultados: Un Flujo Rápido y Fluido

Los autores probaron esto en una sola tarjeta gráfica de consumo (una RTX 3090 Ti).

Velocidad: Lograron unos 27 a 30 fotogramas por segundo (FPS) constantes. Esto es lo suficientemente rápido como para ver un video en tiempo real sin tirones.
Latencia: Hay un ligero retraso (de 0.5 a 1 segundo) porque el sistema tiene que almacenar en búfer algunos fotogramas para que el sistema de "Dos Vías" funcione, pero el video se reproduce con fluidez una vez que comienza.
Calidad: El sistema funciona bien en videos que no ha visto antes (como diferentes tipos de danza o parkour) y puede manejar diferentes estilos artísticos, aunque le cuesta un poco lidiar con patrones muy complejos y de alto contraste, como los puntos de los cómics.

Lo que Intentaron (y Fallaron)

El artículo también enumera algunas ideas que no funcionaron, actuando como "lecciones preventivas" para otros:

Mezclar pintura vieja: Intentar mezclar la pintura del fotograma anterior directamente en el nuevo hizo que el video se convirtiera en una mancha borrosa de un solo color.
Saltarse al pintor: Intentar adivinar el siguiente fotograma simplemente deformando el anterior (saltándose al pintor por completo) resultó en un video tembloroso y de baja calidad.
Recortar gastos: Eliminar partes de las instrucciones del Director de Arte para ahorrar tiempo en realidad empeoró el video, demostrando que esas instrucciones eran necesarias.

La Conclusión

Este artículo no trata sobre hacer al robot pintor más rápido; trata sobre reorganizar la fábrica para que el lento Director de Arte no detenga al rápido Pintor. Al ejecutar las tareas en paralelo, agrupar las instrucciones y reutilizarlas sabiamente, lograron transmitir la estilización de video de alta calidad en tiempo real en una sola computadora doméstica.

Resumen Técnico: Estilización de Transmisión a Velocidad de Video en un Modelo de Difusión de Edición Condicionado por un MLLM con Conciencia Visual

Planteamiento del Problema
La traducción de video en tiempo real utilizando modelos de difusión ha dependido tradicionalmente de pilas de difusión de imagen condicionadas por texto, donde el denoiser U-Net es el cuello de botella computacional por cuadro, y el codificador de texto es una red ligera de clase CLIP (~125M de parámetros). Sin embargo, la destilación agresiva del denoiser (reduciéndolo a estudiantes de 4 pasos o 1 paso) invierte este cuello de botella. En la difusión de edición "con conciencia visual", donde el sistema debe procesar tanto una imagen fuente como una instrucción textual, el codificador de texto es reemplazado por un Modelo de Lenguaje Grande Multimodal (MLLM) pesado, como Qwen3-VL (2.13B de parámetros).

En este régimen de "Denoiser Pequeño Destilado más Codificador MLLM Pesado" (SDD-MTE), el codificador de texto MLLM se convierte en la ruta crítica. Las técnicas de transmisión estándar diseñadas para pipelines dominados por el denoiser fallan aquí porque:

Latencia del Codificador: El codificador MLLM es significativamente más grande que el denoiser y contiene puntos de sincronización intrínsecos entre CPU y GPU (por ejemplo, en los embeddings de posición rotatorios) que impiden un despacho simple de flujo único.
Sobrecarga de Consistencia Temporal: Los adaptadores temporales existentes como ControlNet-LLLite dependen de ramas de Python y verificaciones de identidad de tensores que rompen la captura de grafos de torch.compile, causando que las implementaciones ingenuas corran ~3.5× más lento que el U-Net base.
Inestabilidad Numérica: Los outputs de amplio rango del MLLM (std=37, max=1160) desbordan los mecanismos de atención FP16, dejando unavailable los caminos de TensorRT (en los que confían sistemas como StreamDiffusion).

El artículo aborda el desafío de lograr un rendimiento de transmisión a velocidad de video dentro de este régimen de cuello de botella invertido en una sola GPU de consumo.

Metodología
Los autores proponen un pipeline de transmisión construido alrededor de tres mecanismos de ingeniería específicos diseñados para el régimen SDD-MTE, instanciados en un U-Net destilado de 0.39B (DreamLite-mobile) emparejado con un codificador Qwen3-VL de 2.13B.

Pipelining Asimétrico de Flujo Lateral / Flujo Principal:
- El pipeline se divide en dos flujos CUDA concurrentes. El Flujo Principal maneja la denoisación U-Net compilada y la decodificación VAE para el lote actual ( $n$ ).
- El Flujo Lateral procesa concurrentemente la codificación de texto (TE) del MLLM y la codificación VAE para el próximo lote ( $n+1$ ).
- Este diseño oculta la latencia de sincronización intrínseca del codificador MLLM detrás de la computación del U-Net.
- Amortización de Lotes: El sistema amortiza $B$ cuadros (por ejemplo, $B=8$ o $16$) antes de cada llamada al pipeline. Dado que el codificador MLLM escala de forma sublineal con el tamaño del lote (sublinealidad $s \approx 0.226$ en $B=8$ ) mientras que el U-Net compilado escala casi linealmente ( $s \approx 0.77$ ), el agrupamiento reduce significativamente el costo de TE por cuadro sin aumentar proporcionalmente el costo del U-Net.
- Caché de Prompt Estático (Opcional): Para flujos con instrucciones fijas, el sistema puede codificar un cuadro representativo único y transmitir sus tensores clave/valor al resto del lote, o refrescar la codificación solo cada $N$ lotes.
Reformulación de ControlNet-LLLite Compatible con Compilación:
- Para permitir la optimización torch.compile, los autores refactorizan el adaptador ControlNet-LLLite para eliminar las ramas de Python y los cambios de identidad de tensores que anteriormente forzaban la recompilación de Dynamo en cada cuadro.
- Los cambios clave incluyen el registro de los embeddings de condición como buffers de tamaño fijo con actualizaciones in-place, la eliminación de rutas exclusivas de entrenamiento (dropout, verificaciones de dtype) y la exposición de un método forward_inference dedicado.
- Esto permite que todo el stack U-Net + adaptador se pliegue en un solo grafo fusionado, logrando una aceleración de 4.75× sobre la implementación de referencia en modo eager.
Refresco Periódico de Condicionamiento y Subconjunto de Hooks:
- Calendario de Refresco: En lugar de recomputar el embedding de condicionamiento LLLite (derivado del cuadro anterior deformado/warped) para cada lote, el sistema lo reconstruye cada $N$ lotes (por ejemplo, $N=8$ ). Esto amortiza el costo del CNN de condicionamiento, que domina el tiempo de ejecución del camino LLLite.
- Subconjunto de Hooks: El subset completo de 108 hooks se reduce a un subconjunto de 38 hooks ubicados solo en los down_blocks. Esto reduce la carga de trabajo del codificador de condicionamiento en aproximadamente un 65%, mientras recupera la nitidez espacial perdida al usar los 108 hooks (que tienden a producir un artefacto de "púrpura suave").
- Flujo Asíncrono: El cálculo del flujo óptico de Farneback se ejecuta en un hilo y se lanza de forma asíncrona durante el prefetch para solaparse con el siguiente slot del flujo lateral.

Contribuciones Clave

Arquitectura del Sistema: Una novedosa estrategia de pipelining asimétrico que trata al codificador MLLM como una carga de trabajo separada y concurrente para superar el cuello de botella invertido en regímenes SDD-MTE.
Optimización del Compilador: Una implementación de ControlNet-LLLite refactorizada compatible con torch.compile, permitiendo la ejecución de grafo fusionado para adaptadores temporales.
Mecanismos de Eficiencia: Una combinación de amortización de TE por lotes, refresco periódico de condicionamiento y selección de subconjunto de hooks que colectivamente reducen la latencia por cuadro sin una degradación significativa de la calidad.
Validación Empírica: Evaluación exhaustiva en hardware de consumo (RTX 3090 Ti, 4090, 5090) demostrando un throughput sostenido y consistencia temporal a través de escenarios in-domain y cross-dataset.

Resultados
Evaluado en una sola RTX 3090 Ti a resolución 512×512 con un tamaño de lote de $B=8$ e inferencia de 1 paso ( $K=1$ ):

Throughput: El pipeline mantiene 27.4 FPS (latencia p50 ~0.5s) y 29.6 FPS con $B=16$ (latencia p50 ~1.0s) durante una ejecución de 480 cuadros.
Escalabilidad de Hardware: El rendimiento escala a 54.9 FPS en RTX 4090 y 74.1 FPS en RTX 5090.
Calidad: La configuración "champion" (subconjunto de hooks de down_blocks + refresco periódico) logra un error de deformación ( $\epsilon_w$ ) de 18.34, una reducción del 20% en el parpadeo (flicker) comparado con una línea base sin LLLite (22.97), mientras mantiene el detalle espacial (puntuación Sobel 4.74 vs. 5.10 de la línea base).
Generalización: El adaptador temporal liberado se generaliza bien a 19 secuencias no utilizadas de DAVIS-2017 y 15 clips de 7 fuentes no-DAVIS con métricas de rendimiento dentro del ruido in-clip del champion in-domain.
Generalización de Prompts: El modelo maneja bien estilos no vistos (ej. Van Gogh), aunque el rendimiento decae para estilos con texturas de alta frecuencia fuera del manifold de entrenamiento (ej. medio tono de cómic).

Significancia y Reivindicaciones
El artículo se posiciona como un estudio de sistemas más que una reivindicación de superioridad de benchmarks. Establece explícitamente que no pretende ser superior a los sistemas de clase StreamDiffusion (que usan codificadores CLIP), sino que sitúa sus números frente a una ejecución del mismo stack de StreamDiffusion para dar contexto.

La principal significancia radica en demostrar que la transmisión a velocidad de video es alcanzable en una sola GPU de consumo incluso cuando el codificador de texto es un MLLM pesado, siempre que el sistema se rediseñe para acomodar el cuello de botella invertido. Los autores enfatizan que las técnicas estándar de aceleración de denoiser son insuficientes para este régimen y que los mecanismos propuestos (pipelining asimétrico, adaptadores compatibles con compilación y condicionamiento amortizado) son necesarios para desbloquear el rendimiento en tiempo real.

El artículo también sirve como guía para profesionales al documentar resultados negativos (ej. mezcla de latentes ingenua, fallos de FP16 en TensorRT con outputs de MLLM y las trampas de usar solo el error de deformación como métrica para artefactos de suavizado) para evitar errores de ingeniería comunes en este dominio específico.