Utiliser le context packing des frames d’entrée dans un modèle de prédiction de frame suivante pour la génération vidéo
(lllyasviel.github.io)- FramePack est une approche basée sur la prédiction de frame suivante, conçue pour permettre à un modèle de diffusion vidéo 13B de générer de longues vidéos même avec 6 Go de mémoire GPU sur un ordinateur portable
- Au lieu de traiter toutes les frames d’entrée avec la même longueur, elle varie le patchifying kernel selon chaque frame afin d’allouer davantage de ressources GPU aux frames importantes, proches de la cible à prédire
- Avec HunyuanVideo, une frame 480p peut passer d’environ 1536 tokens avec
(1, 2, 2)à 192 tokens avec(2, 4, 4), et la complexité de calcul en streaming est de O(1) - Le FramePack Scheduling ajuste l’importance des frames et le taux de compression, et dans le cas de l’image-vers-vidéo, il permet aussi un scheduling qui considère les frames initiales comme également importantes
- Pour réduire le drifting causé par l’accumulation d’erreurs dans la génération de longues vidéos, la méthode utilise un échantillonnage bidirectionnel qui brise la causalité ; l’inverted anti-drifting sampling convient à l’image-vers-vidéo
Context packing des frames d’entrée dans FramePack
- FramePack est une méthode où un modèle de prédiction de frame suivante ou de section de frame suivante prend plusieurs frames d’entrée et génère par diffusion de nouvelles frames
- Les objectifs de performance et les conditions d’utilisation sont les suivants
- génération de plusieurs milliers de frames à 30 fps avec un modèle 13B sur un GPU de portable avec 6 Go de mémoire
- fine-tuning d’un modèle vidéo 13B avec une batch size de 64 sur un unique nœud 8xA100/H100
- génération à 2,5 s/frame avant optimisation sur une RTX 4090 personnelle, et à 1,5 s/frame avec teacache
- sans distillation des timesteps
- L’idée centrale consiste à ne pas simplement concaténer les images des frames d’entrée, mais à disposer différemment la longueur de contexte de chaque frame dans une disposition logique de la mémoire GPU
- La longueur de contexte par frame est contrôlée via différents patchifying kernels
- dans HunyuanVideo, une frame 480p représente environ 1536 tokens avec un patchifying kernel
(1, 2, 2) - avec un patchifying kernel
(2, 4, 4), elle descend à 192 tokens par frame
- dans HunyuanVideo, une frame 480p représente environ 1536 tokens avec un patchifying kernel
- Les frames plus importantes, comme celles proches de la frame suivante à prédire, reçoivent un contexte plus long
- La complexité de calcul en streaming est O(1), et non O(nlogn) ni O(n)
Scheduling et prévention du drifting
- Le FramePack Scheduling prend en charge les cas où l’importance des frames ne suit pas un motif simple, où le taux de compression varie, ou encore où l’utilisateur veut donner plus d’importance à certaines frames
- Dans l’image-vers-vidéo, la première frame est importante ; on peut donc utiliser un scheduling qui donne la même importance aux frames de départ
- Tous les schedulings sont en O(1), et l’évaluation de plusieurs schedulings est incluse dans le Paper
- Dans les modèles de prédiction de frame suivante, le drifting, c’est-à-dire la dégradation de la qualité à mesure que la vidéo s’allonge, est un problème courant
- si l’on réinjecte en boucle la dernière frame générée pour produire une longue vidéo, le résultat se dégrade rapidement après 5 à 6 itérations et peut être fortement détérioré après environ 10 itérations
- ce problème est aussi appelé accumulation d’erreurs ou exposure bias
- Des expériences sur des méthodes existantes comme history noise augmentation, special cfg guidance et rolling diffusion timesteps sont également incluses dans l’article
- Pour traiter le drifting à la racine, il faut briser la causalité et rendre l’échantillonnage bidirectionnel
- seul le vanilla sampling est causal
- l’anti-drifting sampling et l’inverted anti-drifting sampling sont des approches bidirectionnelles
- l’inverted anti-drifting sampling traite la première frame comme cible approximative dans toute l’inférence, ce qui le rend adapté à l’image-vers-vidéo
Conditions de démo et ressources
- Les résultats de démonstration ont été calculés avec un ordinateur portable RTX 3060 6 Go et une variante HY 13B
- image-to-5-seconds : 30 fps, 150 frames
- image-to-60-seconds : 30 fps, 1800 frames
- les vidéos ont été compressées en h264crf18 pour correspondre au dépôt GitHub
- Les ressources associées incluent le Paper, le Code et FramePack-P1 Preview
1 commentaires
Commentaires sur Hacker News
Cette personne est un génie. Tout le monde ne le sait peut-être pas, mais ControlNet aussi, c’est elle qui l’a créé.
C’est très significatif, car il s’agit du premier modèle de génération vidéo réellement exploitable qui tourne sur du matériel grand public, et j’espère que la prise en charge des poses ControlNet arrivera bientôt.
Les grandes entreprises ont dû lui faire des offres énormes ; son talent est vraiment exceptionnel.
C’est drôle de voir qu’il tient absolument à faire danser les gens. Même une personne assise pour une interview se met à danser tout en restant assise.
Dans les images statiques, on cherche toujours les yeux ; dans les vidéos, on finit toujours par chercher la danse.
Les exemples sont assez impressionnants, alors que les ressources utilisées pour les produire sont en réalité presque dérisoires. On dirait que l’inférence pourrait tourner même sur du matériel grand public de génération précédente.
J’aimerais un jour voir les chiffres de débit d’inférence sur une 5090.
Est-ce qu’on pourrait faire la même chose dans la dimension spatiale ? Par exemple, au lieu de générer une image d’un seul coup, la générer de haut en bas ?
Pourrait-on utiliser cela pour de l’interpolation vidéo plutôt que pour de l’extrapolation ?
Impressionnant. Avec davantage de ressources, comme de la RAM, est-ce que cela pourrait aller plus vite ? Je me demande aussi si l’on pourrait obtenir encore plus de vitesse sur des H100 ou H200.
On dirait que la seule action possible, en pratique, c’est la danse.