← Blog

Helios: Un Modelo de Generación de Vídeo Largo en Tiempo Real Que Evita Todos los Atajos

Helios genera vídeos de un minuto a 19,5 FPS en una sola H100, sin KV-cache, atención dispersa ni ninguno de los trucos de aceleración habituales. Esto es lo que lo hace diferente.

9 min read

Tengo una lista mental de cosas que asumo que los modelos de generación de video necesitan: KV-cache para velocidad, atención dispersa para memoria, muestreo de fotogramas clave para evitar la deriva. Helios de PKU-YuanGroup descarta todo eso — y aun así alcanza 19.5 FPS en una sola H100. Esa contradicción fue lo que me hizo dejar de hacer scroll.

Soy Dora. Pasé los últimos días leyendo el artículo de Helios y su repositorio, ejecutando lo que pude localmente, e intentando entender por qué este enfoque funciona cuando la sabiduría convencional dice que no debería. Esto no es una reseña de benchmarks. Es más bien un conjunto de notas de alguien que ha sido engañado suficientes veces por afirmaciones “revolucionarias” como para querer pruebas.

Qué Es Realmente Helios

Helios es un modelo de generación de video autoregresivo que produce 33 fotogramas por fragmento, encadenando fragmentos para crear videos a escala de minutos — hasta 1.452 fotogramas a 24 FPS, lo que equivale a aproximadamente 60 segundos de metraje continuo.

Eso solo no es impactante. Lo inusual es la lista de cosas que no utiliza:

  • Sin KV-cache
  • Sin enmascaramiento causal
  • Sin atención dispersa o lineal
  • Sin TinyVAE
  • Sin programaciones de ruido progresivo
  • Sin cuantización
  • Sin self-forcing, bancos de errores ni muestreo de fotogramas clave (el kit estándar antidesviación)

Leer esa lista fue como que alguien describiera un automóvil que funciona sin motor. Cada una de esas técnicas existe porque la generación de video es costosa, consume mucha memoria y es propensa a la degradación de calidad en secuencias largas. Helios esquiva todo eso y aun así logra inferencia en tiempo real. La pregunta no es si funciona — las demos están ahí afuera — sino cómo.

El Pipeline de Entrenamiento en Tres Etapas

Helios incluye tres variantes de modelo, cada una correspondiendo a una etapa de entrenamiento. Entender las etapas ayuda a explicar la lógica del diseño.

Etapa 1: Helios-Base

La base. Aquí es donde aterrizan las innovaciones arquitectónicas centrales:

  • Inyección de Historial Unificada — el modelo se condiciona en fragmentos anteriores sin las penalizaciones habituales de acumulación de errores
  • Antiderivación Fácil — una estrategia durante el entrenamiento que reemplaza los trucos en tiempo de inferencia (self-forcing, bancos de errores) en los que la mayoría de los modelos de video autoregresivos confían
  • Parchificación de Memoria Multi-Término — un enfoque eficiente en memoria para manejar contexto temporal largo

Helios-Base usa predicción-v con guía estándar libre de clasificador. Produce la mayor calidad bruta de las tres variantes, pero también es la más pesada en tiempo de inferencia — 50 pasos de difusión por fragmento.

Etapa 2: Helios-Mid

Un punto de control intermedio que introduce el Corrector Predictor Unificado en Pirámide para compresión de tokens. Aquí es donde el modelo comienza a intercambiar calidad marginal por ganancias de velocidad significativas. Usa CFG-Zero*, que elimina la necesidad de evaluaciones de modelos incondicionales durante la inferencia.

Si has trabajado con modelos de difusión, sabes que CFG típicamente duplica tu cómputo porque ejecutas el modelo dos veces por paso — una con el prompt, otra sin él. Eliminar ese requisito es una ganancia de eficiencia significativa.

Etapa 3: Helios-Distilled

La variante final usa Destilación Jerárquica Adversarial para colapsar 50 pasos de difusión a 3. Cambia de predicción-v a predicción-x0 con un programador personalizado (HeliosDMDScheduler) y elimina completamente el requisito de CFG.

Esta es la variante que alcanza 19.5 FPS. Tres pasos, sin CFG, sin trucos de aceleración — solo un modelo que ha sido entrenado para hacerlo bien a la primera.

Por Qué Importa el Enfoque de “Sin Atajos”

La mayoría del trabajo de aceleración en generación de video es aditivo. Construyes un modelo, es demasiado lento, así que le agregas KV-cache. Sigue usando demasiada memoria, así que añades atención dispersa. La calidad se desvía en secuencias largas, así que añades muestreo de fotogramas clave. Cada solución introduce sus propios modos de fallo y complejidad.

Helios toma el camino opuesto: hacer el modelo base lo suficientemente eficiente para que no necesites los complementos. El pipeline de entrenamiento hace el trabajo pesado que los trucos en tiempo de inferencia suelen manejar.

Hay una consecuencia práctica aquí que es fácil pasar por alto. Menos piezas en movimiento significa menos cosas que romper. Si alguna vez has depurado un problema de corrupción de KV-cache o visto a la atención dispersa crear artefactos en límites específicos de fotogramas, conoces el coste que esos sistemas imponen. Helios no paga ese coste.

La historia de la memoria es igualmente llamativa. El artículo afirma que pueden ajustar cuatro modelos de 14B parámetros dentro de 80 GB de memoria GPU durante el entrenamiento, usando tamaños de lote a escala de difusión de imágenes. Esa es una compresión agresiva de lo que suele ser un uso de recursos extenso.

Qué Puede Hacer

Helios admite cuatro modos de generación en las tres variantes:

  • Texto a Video — prompt dentro, video afuera
  • Imagen a Video — primer fotograma más prompt
  • Video a Video — transferencia de estilo, re-temporización, modificación
  • Modo interactivo — refinamiento iterativo

Las matemáticas de fotogramas son específicas: trabajas en múltiplos de 33 fotogramas por fragmento. ¿Quieres aproximadamente 30 segundos? Son 22 fragmentos = 726 fotogramas. ¿Un minuto completo? 44 fragmentos = 1.452 fotogramas. El límite del fragmento es donde ocurren los traspasos autoregresivos, y según las demos que he visto, las uniones son notablemente limpias.

Ese último punto merece énfasis. Los modelos de video autoregresivos suelen mostrar su peor comportamiento en los límites de fragmentos — movimiento entrecortado, cambios de color, deriva de objetos. La estrategia de entrenamiento “Antiderivación Fácil” parece abordar esto genuinamente, aunque querría ver casos de prueba más diversos antes de declarar el problema resuelto.

Integración y Ecosistema

Helios ya admite múltiples backends de inferencia:

  • Hugging Face Diffusers — integración ModularPipeline
  • vLLM-Omni — servicio disagregado con arquitectura de grafo basada en etapas
  • SGLang-Diffusion — pipeline unificado con kernels optimizados
  • Ascend NPU — soporte de hardware desde el Día 0 (~10 FPS en Ascend)

La integración con Diffusers es la más accesible. La ruta vLLM-Omni es interesante para despliegues en producción donde quieres separar las etapas de prefill y decodificación en hardware diferente. SGLang-Diffusion parece la opción orientada al futuro — está diseñada para el tipo de servicio en lotes y canalizado que hace factibles las aplicaciones en tiempo real.

El soporte de Ascend NPU es una señal estratégica. El soporte desde el Día 0 para hardware que no es NVIDIA sugiere que esto no fue una ocurrencia de último momento. Con ~10 FPS en Ascend, es más lento que la ruta H100 pero sigue siendo utilizable para muchas aplicaciones.

HeliosBench

El equipo construyó su propio benchmark — HeliosBench — diseñado específicamente para evaluar la generación de video largo en tiempo real. Esto vale la pena señalarlo porque la mayoría de los benchmarks de video existentes se centran en clips cortos (4–16 segundos) y no capturan los modos de fallo que emergen a escala de minutos: deriva temporal, degradación del movimiento, fallos de persistencia de objetos.

Tener un benchmark de propósito específico no garantiza objetividad, pero sí significa que al menos están midiendo las cosas correctas. Me gustaría ver evaluaciones independientes usando HeliosBench para validar la metodología.

En Lo Que Sigo Pensando

Calidad en los extremos. El diseño de fragmentos de 33 fotogramas es elegante, pero 44 pasos autoregresivos consecutivos son muchas oportunidades para que se acumule el error. Las demos lucen limpias, pero las demos siempre lucen limpias. Quiero ver prompts adversariales — movimiento de cámara complejo, muchos objetos interactuando, cambios dramáticos de iluminación a lo largo de un minuto completo.

La compensación de la destilación. Pasar de 50 pasos a 3 es agresivo. Los modelos destilados generalmente sacrifican diversidad y detalle fino por velocidad. La variante Helios-Base existe por una razón — cuando la calidad importa más que la velocidad, pagas 17 veces el cómputo. Esa es una brecha amplia entre los dos puntos de operación.

Madurez del ecosistema. El modelo es de código abierto (Apache 2.0), lo que es estupendo. Pero los modelos de video de código abierto necesitan herramientas comunitarias para volverse prácticos — nodos de ComfyUI, scripts de entrenamiento para fine-tuning, soporte de LoRA. Ese ecosistema tarda en desarrollarse, y ahora mismo Helios es completamente nuevo.

Requisitos de hardware. Tiempo real en una H100 es impresionante. Pero las H100 no están inactivas en el escritorio de la mayoría de las personas. La pregunta más relevante para muchos usuarios es: ¿cuál es la experiencia en una 4090? ¿En una A100? El artículo es claro sobre el rendimiento en H100 y Ascend — menos claro sobre la larga cola de hardware.

Por Qué Esto Destaca

He visto muchos anuncios de generación de video durante el último año. La mayoría son incrementales: mejores puntuaciones FID, clips ligeramente más largos, inferencia marginalmente más rápida. Helios se siente diferente porque desafía una suposición que no me di cuenta de haber interiorizado — que la generación de video largo en tiempo real requiere una torre de optimizaciones de inferencia apiladas unas sobre otras.

La respuesta que propone Helios es: ¿y si simplemente entrenas mejor el modelo? Empuja la complejidad hacia el pipeline de entrenamiento, no hacia la pila de inferencia. Haz el modelo intrínsecamente eficiente en lugar de añadir eficiencia después del hecho.

Si ese enfoque escala, se generaliza y sobrevive el contacto con cargas de trabajo en producción es una pregunta abierta. Pero la dirección es convincente. Menos piezas en movimiento, arquitectura más limpia y números de rendimiento que hablan por sí mismos.

El código y los pesos están en GitHub. Apache 2.0. Si tienes una H100 y una tarde libre, vale la pena echarle un vistazo.