Helios : Un modèle de génération de vidéos longues en temps réel qui évite tous les raccourcis

Je garde mentalement une liste de choses que j’estime indispensables aux modèles de génération vidéo : le KV-cache pour la vitesse, l’attention creuse pour la mémoire, l’échantillonnage de keyframes pour éviter la dérive. Helios, de PKU-YuanGroup, jette tout ça à la poubelle — et atteint quand même 19,5 FPS sur un seul H100. C’est cette contradiction qui m’a fait stopper mon défilement.

Je m’appelle Dora. J’ai passé les deux derniers jours à lire le papier Helios et son dépôt, à exécuter ce que je pouvais en local, et à tenter de comprendre pourquoi cette approche fonctionne alors que la sagesse conventionnelle dit qu’elle ne devrait pas. Ce n’est pas une revue de benchmarks. C’est plutôt un ensemble de notes de quelqu’un qui a été assez souvent trahi par des affirmations « révolutionnaires » pour vouloir des preuves.

Ce qu’est vraiment Helios

Helios est un modèle de génération vidéo autorégressif qui produit 33 frames par chunk, en enchaînant les chunks pour créer des vidéos à l’échelle de la minute — jusqu’à 1 452 frames à 24 FPS, ce qui correspond à environ 60 secondes de séquence continue.

Ça en soi n’est pas surprenant. Ce qui est inhabituel, c’est la liste de ce qu’il n’utilise pas :

Pas de KV-cache
Pas de masquage causal
Pas d’attention creuse ou linéaire
Pas de TinyVAE
Pas de planification progressive du bruit
Pas de quantification
Pas de self-forcing, d’error-banks ni d’échantillonnage de keyframes (la boîte à outils anti-dérive standard)

Lire cette liste, c’est comme entendre quelqu’un décrire une voiture qui roule sans moteur. Chacune de ces techniques existe parce que la génération vidéo est coûteuse, gourmande en mémoire, et sujette à la dégradation de qualité sur de longues séquences. Helios contourne tout cela et parvient tout de même à une inférence en temps réel. La question n’est pas de savoir si ça fonctionne — les démos sont disponibles — mais comment.

Le pipeline d’entraînement en trois étapes

Helios propose trois variantes de modèle, chacune correspondant à une étape d’entraînement. Comprendre ces étapes aide à expliquer la logique de conception.

Étape 1 : Helios-Base

Le fondement. C’est là qu’atterrissent les innovations architecturales fondamentales :

Unified History Injection — le modèle se conditionne sur les chunks précédents sans les pénalités habituelles d’accumulation d’erreurs
Easy Anti-Drifting — une stratégie appliquée à l’entraînement qui remplace les hacks à l’inférence (self-forcing, error-banks) sur lesquels s’appuient la plupart des modèles vidéo autorégressifs
Multi-Term Memory Patchification — une approche efficace en mémoire pour gérer le contexte temporel long

Helios-Base utilise la v-prediction avec le guidage classique sans classifieur. Il produit la meilleure qualité brute des trois variantes, mais c’est aussi le plus lourd à l’inférence — 50 étapes de diffusion par chunk.

Étape 2 : Helios-Mid

Un checkpoint intermédiaire qui introduit le Pyramid Unified Predictor Corrector pour la compression de tokens. C’est là que le modèle commence à troquer une qualité marginale contre des gains de vitesse significatifs. Il utilise CFG-Zero*, ce qui élimine le besoin d’évaluations inconditionnelles du modèle lors de l’inférence.

Si vous avez travaillé avec des modèles de diffusion, vous savez que le CFG double généralement votre calcul parce que vous exécutez le modèle deux fois par étape — une fois avec le prompt, une fois sans. Supprimer cette exigence représente un gain d’efficacité considérable.

Étape 3 : Helios-Distilled

La variante finale utilise la Adversarial Hierarchical Distillation pour réduire 50 étapes de diffusion à 3. Elle passe de la v-prediction à la x0-prediction avec un planificateur personnalisé (HeliosDMDScheduler) et abandonne complètement le CFG.

C’est la variante qui atteint 19,5 FPS. Trois étapes, pas de CFG, pas d’astuces d’accélération — juste un modèle entraîné pour réussir du premier coup.

Pourquoi l’approche « zéro raccourcis » est importante

La plupart des travaux d’accélération en génération vidéo sont additifs. On construit un modèle, il est trop lent, alors on y greffe un KV-cache. Toujours trop de mémoire, alors on ajoute l’attention creuse. La qualité dérive sur les longues séquences, alors on ajoute l’échantillonnage de keyframes. Chaque correctif introduit ses propres modes de défaillance et sa propre complexité.

Helios emprunte le chemin inverse : rendre le modèle de base suffisamment efficace pour ne pas avoir besoin de greffes. Le pipeline d’entraînement fait le gros du travail que les astuces à l’inférence gèrent habituellement.

Il y a une conséquence pratique facile à manquer. Moins de pièces mobiles signifie moins de choses qui peuvent casser. Si vous avez déjà débogué un problème de corruption de KV-cache ou regardé l’attention creuse créer des artefacts à des limites de frames spécifiques, vous connaissez la taxe que ces systèmes imposent. Helios ne la paie pas.

L’histoire de la mémoire est tout aussi frappante. Le papier affirme qu’ils peuvent faire tenir quatre modèles à 14 milliards de paramètres dans 80 Go de mémoire GPU pendant l’entraînement, en utilisant des tailles de batch à l’échelle de la diffusion d’images. C’est une compression agressive de ce qui est habituellement un encombrement de ressources considérable.

Ce qu’il sait faire

Helios prend en charge quatre modes de génération pour les trois variantes :

Texte vers vidéo — prompt en entrée, vidéo en sortie
Image vers vidéo — première frame plus prompt
Vidéo vers vidéo — transfert de style, re-timing, modification
Mode interactif — raffinement itératif

Le calcul des frames est précis : on travaille en multiples de 33 frames par chunk. Vous voulez environ 30 secondes ? C’est 22 chunks = 726 frames. Une minute entière ? 44 chunks = 1 452 frames. La limite de chunk est l’endroit où se produisent les transferts autorégressifs, et d’après les démos que j’ai vues, les raccords sont remarquablement propres.

Ce dernier point mérite d’être souligné. Les modèles vidéo autorégressifs montrent généralement leur pire comportement aux limites de chunk — saccades de mouvement, décalages de couleur, dérive des objets. La stratégie d’entraînement « Easy Anti-Drifting » semble véritablement y remédier, bien que je souhaiterais voir des cas de test plus diversifiés avant de déclarer le problème résolu.

Intégration et écosystème

Helios prend déjà en charge plusieurs backends d’inférence :

Hugging Face Diffusers — intégration ModularPipeline
vLLM-Omni — service désagrégé avec architecture de graphe basée sur les étapes
SGLang-Diffusion — pipeline unifié avec des kernels optimisés
Ascend NPU — support matériel dès le premier jour (~10 FPS sur Ascend)

L’intégration Diffusers est la plus accessible. La voie vLLM-Omni est intéressante pour les déploiements en production où l’on veut séparer les étapes de prefill et de décodage sur différents matériels. SGLang-Diffusion semble être l’option tournée vers l’avenir — elle est conçue pour le type de service par lots et en pipeline qui rend les applications en temps réel réalisables.

Le support Ascend NPU est un signal stratégique. Un support dès le premier jour pour du matériel non-NVIDIA suggère que ce n’était pas une réflexion après coup. À ~10 FPS sur Ascend, c’est plus lent que la voie H100, mais toujours utilisable pour de nombreuses applications.

HeliosBench

L’équipe a construit son propre benchmark — HeliosBench — spécifiquement conçu pour évaluer la génération vidéo longue en temps réel. Cela mérite d’être noté car la plupart des benchmarks vidéo existants se concentrent sur des clips courts (4 à 16 secondes) et ne capturent pas les modes de défaillance qui émergent à l’échelle de la minute : dérive temporelle, dégradation du mouvement, défaillances de persistance des objets.

Disposer d’un benchmark dédié ne garantit pas l’objectivité, mais cela signifie au moins qu’ils mesurent les bonnes choses. J’aimerais voir des évaluations indépendantes utilisant HeliosBench pour valider la méthodologie.

Ce à quoi je réfléchis encore

La qualité aux extrêmes. La conception en chunks de 33 frames est élégante, mais 44 étapes autorégressives consécutives représentent beaucoup d’opportunités pour des erreurs accumulées. Les démos semblent propres, mais les démos semblent toujours propres. Je veux voir des prompts adversariaux — mouvements de caméra complexes, nombreux objets en interaction, changements d’éclairage dramatiques sur une minute entière.

Le compromis de la distillation. Passer de 50 étapes à 3 est agressif. Les modèles distillés sacrifient généralement la diversité et les détails fins pour la vitesse. La variante Helios-Base existe pour une raison — quand la qualité importe plus que la vitesse, on paie 17 fois le calcul. C’est un écart important entre les deux points de fonctionnement.

La maturité de l’écosystème. Le modèle est open-source (Apache 2.0), ce qui est excellent. Mais les modèles vidéo open-source ont besoin d’outils communautaires pour devenir pratiques — des nœuds ComfyUI, des scripts d’entraînement pour le fine-tuning, le support LoRA. Cet écosystème prend du temps à se développer, et en ce moment Helios est tout nouveau.

Les exigences matérielles. Le temps réel sur un H100 est impressionnant. Mais les H100 ne restent pas inactifs sur les bureaux de la plupart des gens. La question plus pertinente pour beaucoup d’utilisateurs est : quelle est l’expérience sur une 4090 ? Sur une A100 ? Le papier est clair sur les performances H100 et Ascend — moins clair sur la longue traîne du matériel.

Pourquoi ça se démarque

J’ai suivi beaucoup d’annonces de génération vidéo au cours de l’année passée. La plupart sont incrémentales : de meilleurs scores FID, des clips légèrement plus longs, une inférence marginalement plus rapide. Helios semble différent parce qu’il remet en question une hypothèse que je n’avais pas réalisé avoir intériorisée — que la génération vidéo longue en temps réel nécessite une tour d’optimisations d’inférence empilées les unes sur les autres.

La réponse que propose Helios est : et si on entraînait simplement le modèle mieux ? Pousser la complexité dans le pipeline d’entraînement, pas dans la pile d’inférence. Rendre le modèle intrinsèquement efficace plutôt que de greffer l’efficacité après coup.

Si cette approche passe à l’échelle, se généralise et survit au contact des charges de travail en production est une question ouverte. Mais la direction est convaincante. Moins de pièces mobiles, une architecture plus propre, et des chiffres de performance qui parlent d’eux-mêmes.

Le code et les poids sont sur GitHub. Apache 2.0. Si vous avez un H100 et un après-midi de libre, ça vaut le coup d’y jeter un œil.