À retenir
- Les modèles vidéo ouverts sont importants parce qu’ils permettent à plus de builders d’inspecter, de tester et d’améliorer les composants derrière la génération.
- La génération vidéo est plus difficile que la génération d’images, parce que le mouvement, l’identité, la physique et la cohérence temporelle doivent tous tenir ensemble.
- Les choix d’architecture et d’entraînement comptent plus que le plus beau clip de démonstration, surtout lorsqu’on évalue la fiabilité.
Regardez la vidéo!
La semaine dernière, j’étais à la GTC, l’événement annuel de Nvidia, et j’ai eu la chance de découvrir de nouvelles technologies incroyables. Une initiative a particulièrement attiré mon attention : un générateur vidéo entièrement open source appelé Open-Sora. L’équipe a réussi à entraîner un générateur vidéo de bout en bout, qui prend du texte et génère une courte vidéo, avec seulement 200 000 $. D’accord, 200 000 $, c’est beaucoup d’argent, mais c’est assez peu comparativement au coût de Sora d’OpenAI ou d’autres modèles de génération vidéo à l’état de l’art, comme Runway et ceux dont j’ai parlé sur ma chaîne, qui exigent des millions pour être entraînés et obtenir des résultats semblables.
Avant de voir comment l’équipe y est arrivée, commençons par comprendre le problème. La génération de texte vers vidéo ne ressemble pas à la génération d’une seule image à partir de texte. Il faut créer une séquence d’images qui s’enchaînent parfaitement dans le temps. Il faut non seulement capturer tous les détails spatiaux fins d’une scène, mais aussi assurer un mouvement fluide et réaliste au fil du temps. Cette dimension temporelle supplémentaire introduit une toute nouvelle couche de complexité et de coûts, principalement parce que ces systèmes d’IA ne comprennent pas le temps. Ils ne reçoivent que des tokens, qui représentent nos mots ou des pixels. Ils ne comprennent pas les lois de la physique comme les humains, qui les apprennent par essais et erreurs lorsqu’ils sont bébés. Leur seul accès à notre monde passe par des tokens, ce qui rend cette cohérence temporelle vidéo extrêmement difficile.
Il existe essentiellement deux approches pour s’attaquer à ce problème. La première consiste à entraîner directement un modèle à convertir du texte en vidéo. Le modèle doit donc apprendre en même temps à générer des images de grande qualité et à les assembler en un mouvement cohérent, sans aucun problème ni artefact. C’est évidemment la solution idéale et notre objectif final, mais elle comporte les défis que je viens de mentionner. La deuxième approche fait plutôt un détour et simplifie le problème en deux étapes : vous entraînez d’abord un modèle à générer une image de grande qualité à partir d’un prompt textuel, puis vous utilisez ce modèle et l’image générée comme signal de conditionnement pour produire une vidéo. Open-Sora 2.0 adopte cette deuxième approche, parce qu’elle tire parti de techniques matures de génération d’images au lieu d’entraîner tout un pipeline de bout en bout à partir de zéro. En commençant avec un solide modèle texte-vers-image préentraîné, le système peut ajouter la dimension du mouvement plus tard et se concentrer intensément sur chaque composant, une étape à la fois. Cette séparation facilite beaucoup la gestion de l’entraînement, réduit sa complexité globale et diminue considérablement les ressources de compute et de données nécessaires, comme nous allons le voir.
Voyons comment Open-Sora 2.0 est construit et entraîné.
Le pipeline d’entraînement n’est pas seulement divisé en deux étapes, mais bien en trois étapes distinctes. Chacune est soigneusement optimisée pour économiser du compute, réduire les coûts et offrir des performances à l’état de l’art.
Lors de la toute première étape, l’objectif est d’établir un modèle texte-vers-vidéo robuste à une faible résolution de 256×256 pixels. Il s’agit simplement d’arriver à produire quelque chose de prometteur. Au lieu de partir de zéro ou de seulement faire le fine-tuning d’un modèle d’image, l’équipe adopte une autre approche. Elle commence avec le modèle FLUX, un puissant modèle de diffusion texte-vers-image de 11 milliards de paramètres qui génère des images de grande qualité à partir de texte. FLUX encode les prompts textuels dans des représentations sémantiques profondes, qui conditionnent ensuite un processus de diffusion fondé sur un U-Net. Celui-ci débruite progressivement une image latente jusqu’à produire l’image finale.
Ce modèle FLUX initial possède déjà de solides capacités de compréhension visuelle, ce qui en fait une base parfaite. Cependant, générer des vidéos exige non seulement une cohérence spatiale, mais aussi une cohérence temporelle, donc un mouvement fluide et crédible. Pour ajouter efficacement cette dimension temporelle, Open-Sora utilise une architecture avancée inspirée de MM-DiT, ou Multimodal Diffusion Transformer.
En bref, MM-DiT traite l’information en deux grandes étapes. D’abord, il traite séparément le texte et les données visuelles grâce à des flux de transformeurs dédiés. Ce sont deux pipelines distincts, l’un pour le texte et l’autre pour les images ou les frames vidéo. Chacun se concentre indépendamment sur la meilleure représentation possible de ses données respectives. Pour l’encodage du texte, MM-DiT exploite trois puissants modèles de texte préentraînés : CLIP-L fournit un solide alignement de base entre le texte et le visuel, tandis que T5-XXL apporte une compréhension sémantique plus profonde, particulièrement utile pour capturer des contextes textuels détaillés et complexes. Open-Sora n’utilise pas CLIP-G, qui apparaît dans cette figure. Ces caractéristiques textuelles sont combinées à l’input visuel, le Noised Latent ici, qui représente des images ou des frames auxquelles du bruit a été ajouté. Le modèle le débruite progressivement pour générer du contenu visuel clair et cohérent.
Architecture de MM-DiT. (clairement illustrée dans la vidéo!)
Ensuite, MM-DiT introduit des blocs de transformeurs intégrés qui servent de ponts entre ces deux flux distincts. L’information peut ainsi circuler de façon bidirectionnelle et fluide : les données textuelles guident la génération visuelle, tandis que les caractéristiques visuelles influencent la compréhension du texte. C’est essentiellement comme si deux experts échangeaient leurs observations pour améliorer leur compréhension mutuelle.
Une caractéristique importante de MM-DiT est sa modulation apprise. Le modèle ajuste dynamiquement la mesure dans laquelle il se fie aux prompts textuels plutôt qu’aux indices visuels intermédiaires à chaque étape de génération de l’output. Cet ajustement dynamique améliore considérablement l’alignement entre ce que l’utilisateur écrit, donc les prompts textuels, et les résultats visuels, soit les images ou les vidéos générées. On obtient ainsi une meilleure qualité et une meilleure cohérence.
Pour les données d’entraînement de cette première étape, Open-Sora utilise un dataset substantiel et soigneusement sélectionné d’environ 70 millions de courts extraits vidéo, chacun d’une résolution de 256×256 pixels. Ce vaste dataset provient de plusieurs sources vidéo accessibles au public. Il a été filtré et traité rigoureusement pour assurer un contenu diversifié de grande qualité, adapté à un entraînement efficace. Il s’agit de l’étape la plus coûteuse, avec 2 240 jours-GPU et un peu plus de 100 000 $. Mais nous avons maintenant un modèle assez puissant qui prend un prompt et génère une belle vidéo en faible résolution!
La deuxième étape simplifie encore l’entraînement en passant de la génération texte-vers-vidéo à la génération image-vers-vidéo, toujours à 256×256 pixels. À cette étape, au lieu de dépendre seulement de prompts textuels, le modèle apprend à prolonger une seule image en une courte vidéo. Pour y arriver, l’équipe modifie sa méthode de conditionnement en encodant l’image initiale et en la concaténant comme information supplémentaire dans la représentation vidéo latente. Cet ajustement permet au modèle d’apprendre explicitement la génération du mouvement, indépendamment de la complexité de la création d’une scène. Puisque le modèle se concentre uniquement sur le mouvement et reçoit l’information d’une image générée au préalable par FLUX, l’entraînement devient plus rapide, exige moins de données et coûte beaucoup moins cher. Pour assurer sa robustesse, l’équipe introduit aussi intelligemment un mécanisme de dropout pour le conditionnement par image. Elle force parfois aléatoirement le modèle à générer des vidéos sans image initiale, ce qui préserve ses capacités texte-vers-vidéo et l’empêche de dépendre complètement de l’image prégénérée.
Pour cette étape, l’équipe exploite un dataset réduit qui contient environ 10 millions d’extraits vidéo soigneusement choisis et de grande qualité, toujours à une résolution de 256×256 pixels. Des étapes de prétraitement tout aussi rigoureuses et davantage de filtres assurent leur cohérence et leur qualité. En réutilisant les images précédemment générées par le modèle FLUX, l’équipe réduit aussi considérablement les besoins de calcul. Cette étape exige seulement environ 384 jours-GPU, soit 18 000 $.
La troisième et dernière étape consiste à raffiner le modèle et à le mettre à l’échelle pour produire des vidéos en haute résolution, plus précisément à 768×768 pixels. Passer directement à une haute résolution serait toutefois beaucoup trop coûteux. Open-Sora emploie donc une nouvelle architecture d’autoencodeur de compression vidéo profonde appelée Video DC-AE, inspirée de l’approche Deep Compression Autoencoder (DC-AE), initialement conçue pour les images et abordée dans notre vidéo sur les modèles de diffusion latente. Elle est ici adaptée aux vidéos par l’ajout d’une convolution en 3 dimensions plutôt que bidimensionnelle. Au départ, l’équipe utilisait le VAE open source de HunyuanVideo, qui atteint un taux de compression de 4 × 8 × 8. Cette approche restait efficace, mais elle exigeait encore de traiter environ 115 000 tokens par vidéo d’entraînement, ce qui entraînait des besoins de calcul considérables. Open-Sora a multiplié par 4 le taux de compression spatiale pour le porter à 32, tout en maintenant un taux de compression temporelle de 4. Cet ajustement réduit efficacement le nombre de tokens spatiaux traités, améliore grandement l’efficacité du calcul et préserve les caractéristiques essentielles du mouvement. Video DC-AE réduit donc radicalement les dimensions spatiales et temporelles grâce à une compression profonde. Il compresse les vidéos dans une représentation latente beaucoup plus petite et diminue énormément la charge de calcul.
Cette représentation latente compacte sert d’input au modèle de génération vidéo, qui traite efficacement les données textuelles et visuelles combinées sous cette forme compressée. Après avoir généré la vidéo dans cette représentation latente, un décodeur reconstruit la représentation compressée sous forme de frames vidéo cohérentes en haute résolution. L’output final conserve ainsi sa clarté visuelle et sa fluidité temporelle.
Architecture globale d’Open-Sora (clairement illustrée dans la vidéo!)
Pour maintenir la qualité vidéo à cette haute résolution, Open-Sora utilise une stratégie sophistiquée de classifier-free guidance, qui ajuste séparément la force avec laquelle les conditions textuelles et visuelles influencent le processus de génération. Plus précisément, le guidage par image exige habituellement une échelle plus faible pour éviter des outputs statiques, tandis que le guidage par texte profite d’une échelle plus élevée pour améliorer l’alignement sémantique. Afin d’optimiser davantage la qualité, Open-Sora introduit une approche de mise à l’échelle dynamique du guidage par image qui varie selon la frame vidéo et l’étape de débruitage. Au départ, les frames vers la fin de la vidéo exigent un guidage par image plus fort pour rester cohérentes. Les étapes plus tardives du débruitage, lorsque le contenu vidéo est presque entièrement formé, en demandent moins. Cette approche équilibrée, combinée à une oscillation du guidage qui alterne ses échelles à différentes étapes, aide à maintenir la stabilité visuelle et à réduire le scintillement. Open-Sora modélise aussi explicitement l’intensité du mouvement avec un paramètre dédié de score de mouvement. En ajustant ce score pendant l’inférence, les utilisateurs peuvent contrôler précisément le dynamisme de la vidéo et atteindre l’équilibre souhaité entre un mouvement minimal et très fidèle et des scènes plus dynamiques et énergiques. Je n’avais jamais vu cela auparavant et je trouve l’idée plutôt géniale!
Pour cette dernière étape, l’équipe réduit encore son dataset à environ 5 millions d’extraits vidéo soigneusement choisis et de grande qualité, à une résolution de 768 pixels et avec encore plus de filtres. Cette étape exige environ 1 536 jours-GPU, soit 73 000 $.
Pipeline de traitement des données (image tirée du rapport d’Open-Sora 2.0).
En divisant ainsi l’entraînement, d’abord en partant des forces et des approches existantes en texte-vers-image, ensuite en passant à une modélisation efficace du mouvement à faible résolution, puis en raffinant le résultat à haute résolution, Open-Sora 2.0 atteint une qualité de génération vidéo à l’état de l’art comparable à celle de modèles beaucoup plus coûteux, pour une fraction de leur coût.
La présentation d’Open-Sora 2.0 à la GTC portait entièrement sur son efficacité en matière de coûts. Je dois admettre que les résultats semblaient plutôt impressionnants par rapport à ce que nous avons l’habitude d’entendre en ligne. Ils m’ont donné envie d’en apprendre plus et de créer cette vidéo. Alors que l’entraînement de modèles comparables comme MovieGen et Step-Video-T2V coûte généralement plusieurs millions de dollars, Open-Sora 2.0 a atteint des performances très semblables avec un coût d’entraînement de « seulement » 200 000 $, en louant des GPU H200 à 2 $ l’heure pendant un total de 4 160 heures. Évidemment, obtenir un modèle puissant et en être propriétaire reste coûteux, mais l’équipe a tout de même réussi à diviser ce coût par dix et nous a montré comment elle y est arrivée.
Mieux encore, le projet est entièrement open source. Tout le monde peut donc participer à cette révolution passionnante de la génération vidéo. J’ai placé tous les liens dans les références ci-dessous si vous voulez l’essayer ou en apprendre davantage.
Merci d’avoir lu!
J’espère que vous avez trouvé cet article intéressant. On se retrouve dans le prochain!
Toutes les références;
Rapport d’Open-Sora 2.0 : https://arxiv.org/pdf/2503.09642v1
Github d’Open-Sora : https://github.com/hpcaitech/Open-Sora
Article d’Open-Sora 1 : https://arxiv.org/pdf/2412.20404
Modèle HF d’Open-Sora : https://huggingface.co/hpcai-tech/Open-Sora-v2
Flux : https://github.com/black-forest-labs/flux
HunyanVideo : https://arxiv.org/pdf/2412.03603v1
Présentation d’Open-Sora 2.0 à la GTC : https://register.nvidia.com/flow/nvidia/gtcs25/ap/page/catalog/session/1727765669275001cZgX
FAQ
Qu’est-ce qu’Open-Sora 2.0?
Open-Sora 2.0 est un projet ouvert de génération vidéo axé sur l’architecture, l’entraînement et l’objectif de rendre les modèles vidéo plus faciles à étudier.
Pourquoi la génération vidéo est-elle plus difficile que la génération d’images?
Le modèle doit garder les objets, le mouvement, l’identité et la structure de la scène cohérents dans le temps, pas seulement produire une belle image.
Que faut-il observer dans les démonstrations de modèles vidéo?
Ne vous arrêtez pas au meilleur exemple. Vérifiez la cohérence du mouvement, les artefacts, la dérive de l’identité, le respect du prompt et la façon dont le modèle gère ses échecs.
Comment les modèles vidéo ouverts peuvent-ils aider les développeurs?
Les poids ouverts et les détails d’entraînement facilitent l’inspection indépendante de l’architecture, de l’évaluation, de l’adaptation et des limites.
Pourquoi les caractéristiques textuelles et visuelles doivent-elles échanger de l’information?
Le prompt doit guider ce qui apparaît, tandis que le contexte visuel généré doit rester cohérent à mesure que le mouvement se développe.
Pourquoi Open-Sora a-t-il entraîné une étape d’image vers vidéo?
Le conditionnement sur une image initiale permet au modèle de se concentrer sur l’apprentissage du mouvement séparément de la création de la scène, ce qui réduit les besoins en données et en compute.