De 650 s a 72 s: referencia-a-vídeo en una sola RTX 4090

Cómo medimos

Todas las cifras salen de la tabla "Comprehensive Performance Comparison" del README del repositorio. El README indica que los vídeos se generaron en la misma NVIDIA GeForce RTX 4090 (24 GB), con el mismo prompt, la misma imagen de referencia del personaje, la misma semilla (981445682258077) y la misma resolución: 1344×768, 5,16 s a 24 fps (124 fotogramas).

Damos la primera ejecución (95 s) y una ejecución posterior en caliente (~72 s), tal como las recoge el README. El README recoge una configuración en una GPU: son mediciones de un solo montaje, no una distribución.

Las imágenes y los vídeos

Esta es la imagen de referencia y los dos vídeos de la tabla, tal como los publica el README. Los tiempos de cada clip son de la primera ejecución.

Generada con IA · persona sintética

Powered by MiniMax H3 (MiniMax). MiniMax H3 is licensed under the MiniMax H3 Community License Agreement. Not affiliated with MiniMax.

Todo el material de esta sección está generado con IA. La persona de la referencia es sintética, generada por nosotros con SDXL.

Dónde se iba el tiempo

Se acumulan dos cambios:

1. Menos pasos. Un LoRA Turbo de 4 pasos (fuerza 1,0) sustituye al calendario de 50 pasos. En la tabla, con atención densa, pasamos de ~650 s a ~190 s.
2. Atención dispersa sobre el vídeo generado. Sobre la base de 4 pasos, la atención de los tokens del vídeo generado se poda al 25 % de las teselas con más peso (75 % de dispersión). Eso lleva de ~190 s a ~72 s.

Con las cifras de la tabla: 650 → 190 es unas 3,4 veces; 190 → 72, unas 2,6; y 650 → 72, unas 9. Las bases son distintas, así que mira cuál citas. El 9× frente a H3 nativo es en caliente (650 / 72). El 2,24× frente a VDN-H3 del README es de primera ejecución (213,0 / 95,2). En caliente contra en caliente, VDN-H3 frente a VSA es 135 / 72, unas 1,9 veces.

Hay un dato que merece una pausa. Pasar de 50 a 4 pasos es 12,5 veces menos pasos, pero el tiempo solo bajó unas 3,4 veces. El README no lo desglosa, así que no lo explicamos aquí. Es el tipo de hueco que se encuentra al perfilar.

El método

La idea es la atención dispersa visual (Visual Sparse Attention, VSA), presentada para texto-a-vídeo por FastVideo. Los tokens de vídeo se agrupan en teselas espacio-temporales 3D de 4×4×4 (64 tokens). Una proyección de compuerta aprendida (to_gate_compress) decide a qué teselas atiende cada consulta, y se descarta entre el 75 y el 90 % de ellas. El coste baja porque la mayoría de las teselas de claves nunca se visitan.

La referencia-a-vídeo rompe la forma obvia de hacerlo. El modelo antepone segmentos de condición (latentes de imagen de referencia, latentes de audio de referencia y tokens de texto) delante del vídeo generado. Si teselas toda la secuencia sin cuidado, tokens de modalidades distintas caen en la misma tesela. Eso corrompe las máscaras de condicionamiento y daña la identidad del personaje, que es justo para lo que sirve un modelo de referencia.

El parche (Ref2VAVSAGatePatch) usa dos niveles:

• Prefijo denso y exento. Los tokens de texto, imagen de referencia y audio de referencia van en teselas "puras" por segmento. Esas teselas no se podan: la referencia siempre se atiende de forma densa.
• Dispersión solo en el vídeo. La poda top-k se aplica únicamente a las teselas de claves del vídeo generado.
• Trasplante de compuertas. Las 50 matrices to_gate_compress aprendidas se copian sobre el modelo base Ref2VA (minimax_h3_ref2va_pruned_int8_convrot.safetensors). El archivo de compuertas se distribuye aparte, y tools/extract_vsa_gate.py puede extraerlo de un checkpoint FastH3 VSA.

El workflow del benchmark queda así: UNETLoader (Ref2VA INT8) → LoRA Turbo de 4 pasos → Ref2VAVSAGatePatch (dispersión 0,75) → desplazamiento de sigma (vídeo 12, audio 3) → planificador simple de 4 pasos con sampler euler.

Una decisión de diseño que nos gusta: la ruta CUDA exige BF16 y dimensión de cabeza 128, y el código lanza un error en otro caso en lugar de caer en silencio a la atención eager cuadrática. Un fallback silencioso sería más lento (no hemos medido cuánto), y acabarías culpando a otra cosa.

Límites y compromisos

• Una GPU, un montaje. Todas las cifras son de una RTX 4090. El README incluye tarjetas de 24 GB como RTX 3090, A5000 y L40S entre los requisitos, pero no publica tiempos para ellas. No sabemos qué velocidad dan.
• El nodo es experimental. Su nombre en pantalla lo dice. El cableado del README usa dispersión 0,75; el valor por defecto del nodo es 0,70 y su descripción sugiere empezar entre 0,50 y 0,70 y comparar con la misma semilla en denso. Hazlo.
• La calidad no está puntuada. El README muestra los vídeos de la ejecución VSA y de VDN-H3, y puedes verlos más arriba, en «Las imágenes y los vídeos». No publica una métrica de calidad ni incluye la salida nativa de 50 pasos para comparar. Por eso no afirmamos "misma calidad". La calidad no se mide en el README: comprueba cualquier coste de fidelidad con tus casos.
• Atribución de la VRAM. El README da el pico por pipeline (22,5 → 13,5 GB), no cuánto aporta cada cambio. No lo leas como "la dispersión ahorra 9 GB".
• Dependencias. Necesita un ComfyUI reciente con soporte nativo de MiniMax-H3, comfy-kitchen compilado con sol_attn en CUDA y los checkpoints del README. Los mensajes de error del nodo remiten además a una pull request de ComfyUI (#15958) para el atributo de compuerta.
• El modelo tiene su propia licencia. El código del nodo es Apache 2.0. El README no dice nada de la licencia de los pesos de MiniMax H3, que es aparte y puede limitar usos o territorios. Léela antes de usar el modelo.

Qué se traslada a otros pipelines

Nada de esto es exclusivo del vídeo. Los hábitos:

1. Perfila antes de optimizar. Lo de los pasos recuerda que lo que crees que domina el tiempo puede no hacerlo. Reparte el tiempo por etapa primero.
2. Fija la prueba. Los dos vídeos del README (VSA y VDN-H3) comparten GPU, prompt, referencia, semilla y resolución. Si no, comparas ruido.
3. Separa frío y caliente. 95 s la primera vez y 72 s en caliente son ciertos los dos. Tus usuarios pueden vivir en cualquiera.
4. Mide memoria, no solo tiempo. El pico de VRAM decide si el trabajo cabe en la tarjeta.
5. Un cambio por fila. La tabla mueve una palanca cada vez (pasos, luego atención), así se ve qué compró cada una.
6. Falla en voz alta. Protege la ruta rápida para que un error de configuración no ejecute la lenta sin avisar.
7. Pon la comprobación de calidad junto a la cifra de velocidad. Misma semilla, lado a lado, con tus casos reales.

Esto lo hacemos para equipos

Sección comercial. Grawwww, el estudio que escribió este nodo, vende este servicio.

Diagnóstico de tu sistema, 300 € + IVA, una semana, se descuenta si seguimos → https://grawwww.xyz/equipos/

Nos envías un caso real de tu propio pipeline y tus modelos. En una semana recibes un informe por escrito: qué medimos, dónde se pierde tiempo, dinero o calidad, cuánto se puede ganar y un presupuesto cerrado para hacerlo. Si no hay ganancia que merezca la pena, el informe lo dice con números.

Es optimización y diagnóstico de tu propio pipeline, no un servicio de generación alojado.