Video Rebirth réduit le modèle vidéo MiniMax-H3 de 31 à 14 milliards de paramètres

Lorsque vous développez un service de génération vidéo, l’attente à chaque essai devient vite un problème produit. L’utilisateur modifie le mouvement de caméra, obtient une prise ratée et doit de nouveau patienter. Video Rebirth a publié HyperFlow H3 Flash, une version allégée de MiniMax-H3 qui génère conjointement l’image et le son. Pour les développeurs, c’est l’occasion de vérifier si cette tâche peut s’exécuter sur leur propre carte graphique avec une latence acceptable.

L’équipe a réduit le transformeur principal d’environ 31 à 14 milliards de paramètres. Par défaut, la génération s’effectue en six étapes. Le code, les instructions et les intégrations sont disponibles dans le dépôt du projet. Il y a donc de quoi mener une expérimentation technique : monter un prototype et mesurer son comportement sur ses propres cas d’usage.

Ce qui a précisément été réduit

Plusieurs méthodes de compression ont été combinées. Certains blocs du modèle ont été supprimés, et de grandes opérations matricielles ont été remplacées par des opérations plus compactes. L’équipe a également appliqué l’INT8 : dans certaines couches, les calculs utilisent une représentation sur huit bits des poids et des valeurs intermédiaires. La réduction du nombre de paramètres et celle de la précision numérique constituent deux sources d’économie distinctes.

Un autre changement concerne les étapes de génération. Le modèle reçoit des informations sur le niveau de bruit actuel et sur l’état à atteindre à l’étape suivante. Autrement dit, on lui indique le point de départ et le point d’arrivée de chaque transition. La configuration publiée prévoit quatre, six ou huit étapes. Les mécanismes de compression sont décrits dans la fiche du modèle.

Imaginons une tâche : créer une courte scène dans laquelle un cuisinier pose un bol sur une table, tandis que la pluie se fait entendre dehors. Pour un prototype, il est pertinent de vérifier avec quel réalisme le modèle restitue simultanément les mouvements des mains, le contact du bol avec la table et l’ambiance sonore. Ce type d’exemple permet de voir rapidement si le résultat convient à votre fonctionnalité, même lorsque certaines démonstrations particulièrement soignées paraissent convaincantes.

Quel délai prévoir et quelle mémoire prendre en compte

Selon les mesures publiées par l’équipe, le paquet Python génère une vidéo de 5,2 secondes en 92 secondes sur une RTX 5090. La résolution indiquée est de 1344×768, avec six étapes ; la mesure comprend le traitement du texte, la génération et le décodage de la vidéo et du son. Il s’agit d’un point de repère fourni par les auteurs du projet, que nous n’avons pas vérifié de manière indépendante. Les configurations et les résultats figurent dans le tableau des performances.

Pour un produit, ce résultat correspond à un scénario bien concret : l’utilisateur soumet une tâche, puis revient récupérer sa vidéo. L’interface doit donc prévoir une file d’attente, un état d’avancement et un moyen simple de relancer un essai. La possibilité d’explorer rapidement plusieurs variantes doit être mesurée séparément : une seule génération réussie ne suffit pas à décrire le fonctionnement réel du processus.

Il est facile de se tromper sur la mémoire. Le fichier GGUF Q4_K_M occupe 9,1 Go, mais le système nécessite des composants supplémentaires, notamment un encodeur de texte et des décodeurs. La taille d’un seul fichier ne garantit pas que le modèle fonctionnera sur une carte graphique disposant d’autant de mémoire. Les auteurs indiquent avoir effectué des tests sur des cartes de 24 et 32 Go ; les cartes de 16 Go n’ont pas encore fait l’objet de mesures. Les besoins dépendent aussi du mode d’exécution choisi, comme le précisent les instructions sur les poids.

Ce qu’il faut vérifier avant l’intégration

La principale question en suspens concerne le coût de la compression en matière de qualité. Dans la discussion sur Hacker News, les lecteurs demandent des comparaisons directes avec le modèle d’origine et entre les différentes variantes de quantification. La vitesse annoncée ne prouve pas, à elle seule, que le résultat conservera le niveau de détail, les mouvements et la fidélité à la consigne dont vous avez besoin.

Je commencerais par un petit ensemble de scènes représentatives du futur produit. Pour chacune, il faudrait relever le temps d’attente, le nombre de nouvelles tentatives et la proportion de résultats utilisables sans retouche. On obtient alors un indicateur économique utile : le coût par vidéo validée. Un essai rapide peut revenir cher si presque tous les résultats doivent être écartés.

Avant l’intégration, il faut lire les conditions de distribution. Le code est publié sous Apache-2.0, tandis que les poids héritent de la MiniMax-H3 Community License, assortie de restrictions territoriales ; la fiche du projet le précise. La prochaine étape concrète consiste à monter un petit banc d’essai, à vérifier la qualité sur vos propres scènes, puis seulement à calculer la rentabilité du service.