Studio Ghibli 🎥 Wan2.1-T2V-14B - v1.0

Ce LoRA est présenté sur OpenMuse, une initiative sélectionnée dédiée aux LoRA vidéo open-source et aux œuvres créatives qu'ils permettent. Axé sur des modèles comme Wan2.1, LTX-Video et HunyuanVideo, OpenMuse met en avant des outils et œuvres de haute qualité de l'écosystème. Ancré dans la communauté Banodoco, OpenMuse est un foyer croissant pour l'art IA ouvert et collaboratif, conçu pour inspirer les créateurs, susciter la curiosité, et offrir quelque chose dont on serait fier de partager, même avec quelqu'un sceptique à l'égard de l'art généré par IA.

Description

Je suis très heureux de partager mon LoRA magnum opus, sur lequel je travaille depuis un mois depuis la sortie de Wan. C'est en effet le meilleur LoRA sur Civitai que j'ai jamais entraîné, et je dois dire (une fois de plus) - WanVideo est un modèle incroyable.

Le LoRA a été entraîné environ 90 heures sur un RTX 3090 avec musubi-tuner utilisant un ensemble mixte de 240 clips et 120 images. Cela aurait pu être plus rapide, mais j'étais obsédé par le fait de repousser les limites pour créer un modèle de style à la pointe. À vous de juger si j'ai réussi.

Usage

La phrase déclencheuse est style Studio Ghibli - toutes les légendes des données d'entraînement étaient préfixées par ces mots.

Tous les clips que je publie en galerie sont des sorties brutes utilisant un LoRA avec un modèle de base Wan-T2V-14B (bien que les dernières vidéos peuvent inclure un LoRA d'auto-poussée pour accélération d'inférence, lire ci-dessous), sans post-traitement, suréchantillonnage ou interpolation supplémentaire.

La compatibilité avec d'autres LoRAs et avec les modèles Wan-I2V n'a pas été testée.

Les workflows sont intégrés à chaque vidéo (vous pouvez donc simplement télécharger et glisser la vidéo dans ComfyUI pour l'ouvrir). Par exemple, voici un JSON pour le workflow (basé sur le wrapper de Kijai), qui utilise le LoRA d'auto-poussée (créé par blyss), extrait du modèle Wan2.1-T2V-14B-StepDistill-CfgDistill de lightx2v. J'ai choisi la version faite par blyss (et non le LoRA original de Kijai), car d'après mes tests, elle offre une compatibilité maximale et accélère uniquement l'inférence, sans ajout de détails ou biais stylistiques. (C'est aussi la raison pour laquelle je reste sur le modèle Wan de base et ne utilise pas de merges comme AniWan ou FusionX.)

J'utilise le LoRA d'accélération avec le sampler UniPC (et parfois DPM++). D'après mon expérience, UniPC performe mieux pour l'animation 2D que LCM, qui tend vers un réalisme plus prononcé, ce que je souhaite éviter. J'applique aussi généralement le nœud NAG, ce qui me permet d'utiliser des prompts négatifs avec CFG=1. Lors des premiers tests, par rapport à l'ancien workflow avec TeaCache, en plus du gain de vitesse énorme (un clip 640×480×81 en 6 étapes s'encode en ~1 minute au lieu de 6 sur RTX 3090), cela améliore aussi légèrement la fluidité du mouvement et le rendu du texte.

Les LoRA lightx2v mis à jour sont également impressionnants en termes de vitesse et de conservation de la qualité. J'utilise un LoRA rang 128, mais les versions 32 et 64 produisent aussi d'excellents résultats. Voici un exemple de workflow au format JSON. J'ai constaté qu'en réduisant la force du LoRA lightx2v à 0.9, en augmentant le nombre d'étapes à 8 et en utilisant UniPC ou un scheduler DPMPP, on obtient d'excellents résultats.

Et ici se trouve le workflow "hérité" au format JSON. Il a été utilisé pour générer 90 % des vidéos en galerie pour ce LoRA. Il était aussi construit avec des nœuds wrapper et inclut de nombreuses optimisations (plus d'informations ici), notamment checkpoints fp8_e5m2 + torch.compile, SageAttention 2, TeaCache, Enhance-A-Video, Fp16_fast, SLG, et (parfois) Zero-Star (certains ont migré vers le nouveau workflow également), mais le rendu d'un clip 640x480x81 prenait encore environ 5 minutes (RTX 3090) dans l'ancien workflow. Bien que ce workflow hérité démontre une qualité légèrement supérieure dans quelques domaines spécifiques (palette, fluidité), le ralentissement par 5 est un inconvénient majeur qui m'a poussé à migrer vers la version propulsée par lightx2v.

Prompting

Pour générer la plupart des prompts, j'applique généralement la méta-prompt suivante dans ChatGPT (ou Claude, ou tout autre LLM capable), qui aide à enrichir les descriptions "brutes". Cette prompt est basée sur le code officiel d'extension de prompt par les développeurs Wan et ressemble à ceci :

Vous êtes un ingénieur de prompt, spécialisé dans la refinement des entrées utilisateurs en prompts de haute qualité pour la génération vidéo dans le style distinct de Studio Ghibli. Vous assurez que la sortie correspond à l'intention originale tout en enrichissant les détails pour la clarté visuelle et du mouvement.

Exigences de la tâche:
- Si l'entrée utilisateur est trop brève, l'élargir avec des détails raisonnables pour créer une scène plus vive et complète sans altérer le sens central.
- Mettre en avant des caractéristiques clés telles que l'apparence, les expressions, les vêtements, les postures et les relations spatiales des personnages.
- Maintenir toujours l'esthétique visuelle Studio Ghibli - fonds doux semblables à l'aquarelle, designs de personnages expressifs mais simples, et une atmosphère chaleureuse et nostalgique.
- Améliorer les descriptions du mouvement et des mouvements de caméra pour un flux naturel de l'animation. Inclure des mouvements doux et organiques qui correspondent au style narratif de Ghibli.
- Préserver le texte original entre guillemets ou titres tout en assurant que le prompt soit clair, immersif et contienne entre 80 et 100 mots.
- Tous les prompts doivent commencer par "Studio Ghibli style." Aucun autre style artistique ne doit être utilisé.

Exemples de prompts révisés:
"Studio Ghibli style. Une jeune fille aux cheveux bruns courts et aux yeux curieux se tient sur une colline herbeuse baignée de soleil, le vent agitant doucement sa robe blanche simple. Elle regarde un groupe d'oiseaux traverser le ciel doré, ses pieds nus s'enfonçant légèrement dans la terre douce. La scène est baignée d'une lumière chaude et nostalgique, avec des arbres luxuriants qui bougent au loin. Une brise légère transporte les sons de la nature. Plan moyen, angle légèrement bas, avec un panoramique cinématographique lent capturant le mouvement serein."
"Studio Ghibli style. Un petit village au coucher du soleil, des lanternes brillent doucement sous les avant-toits des maisons en bois. Un jeune garçon en yukata bleu court sur un chemin étroit en pierre, ses sandales tapant le sol tandis qu'il poursuit une luciole. Son expression excitée se reflète dans la rivière scintillante à côté de lui. L'atmosphère est riche en oranges chauds et bleus frais, évoquant une soirée d'été paisible. Plan moyen avec un mouvement de suivi fluide suivant les pas énergiques du garçon."
"Studio Ghibli style. Une forêt mystique baignées de brume matinale, où d'imposants arbres s'arquent au-dessus d'un sentier couvert de mousse. Une fille en cape verte simple pose doucement sa main sur le dos d'une créature massive aux yeux doux ressemblant à un ancien cerf. Son pelage scintille faiblement tandis que la lumière du soleil traverse la dense canopée, illuminant le pollen flottant. La caméra zoome lentement, soulignant leur connexion silencieuse. Une douce brise agite les feuilles, et de petites esprits lumineux se cachent derrière les racines."

Instructions:
Je vais maintenant fournir un prompt à réécrire. Veuillez l'élargir et le raffiner en anglais tout en respectant l'esthétique Studio Ghibli. Même si l'entrée est une instruction plutôt qu'une description, réécrivez-la en un prompt complet et visuellement riche sans réponses supplémentaires ni guillemets.

Le prompt est : "VOTRE PROMPT ICI".

Remplacez VOTRE PROMPT ICI par quelque chose comme Jeune fille blonde debout sur la montagne près d'une plage marine sous la pluie ou autre.

Le prompt négatif inclut toujours le même texte de base (mais peut comporter des mots supplémentaires selon le prompt spécifique) :

色调艳丽，过曝，静态，细节模糊不清，字幕，风格，作品，画作，画面，静止，整体发灰，最差质量，低质量，JPEG压缩残留，丑陋的，残缺的，多余的手指，画得不好的手部，画得不好的脸部，畸形的，毁容的，形态畸形的肢体，手指融合，静止不动的画面，杂乱的背景，三条腿，背景人很多，倒着走, 3D, MMD, MikuMikuDance, SFM, Source Filmmaker, Blender, Unity, Unreal, CGI, bad quality

Jeu de données

Dans cette section et les suivantes, je vais un peu bavarder :) N'hésitez pas à passer directement à la Conclusion, mais peut-être que certains trouveront des informations utiles dans ce pavé de texte. Alors...

La sélection du jeu de données a été la partie la plus "facile", je dispose déjà de tous les films Ghibli en qualité maximale découpés en scènes - plus de 30 000 clips en 1920x1040 et bitrate élevé. Ils attendent patiemment le jour où je pourrai enfin effectuer un fine-tuning complet d'un modèle vidéo avec eux.

J'avais déjà préparé environ 300 clips pour l'entraînement de la v0.7 de HV LoRA (en fait, j'étais juste sur le point de commencer l'entraînement lorsque Wan est sorti). Ces clips comportaient entre 65 et 129 frames, que je considère comme optimal pour entraîner HV sur des vidéos, et ils étaient tous à 24 fps. Pour Wan, cependant, je voulais qu'ils soient dans une plage différente (n'excédant pas 81 frames, plus d'explications dans la section « Entraînement »). Ils devaient aussi être à 16 fps. Je ne suis pas encore certain qu'un strict 16 fps soit nécessaire, mais j'ai eu des problèmes avec HV lorsque les clips étaient à 30 fps au lieu de 24 fps natifs de HV, donc j'ai décidé de rester à 16 fps.

Je devrais mentionner que pour traiter les datasets, je réalise généralement beaucoup de petits scripts "one-time" (avec l'aide de Claude, ChatGPT et DeepSeek) - cela inclut des mini-interfaces pour sélection manuelle de vidéos, des one-liners pour découper les frames, des scripts pour produire diverses statistiques d'aide, disséquer les clips par plages, créer des buckets en avance, etc. Je ne publie pas ces scripts car ils sont désordonnés, pleins de valeurs codées en dur, et conçus pour un usage unique. Et de nos jours, n'importe qui peut facilement créer des scripts similaires en faisant des requêtes aux LLM mentionnés.

Convertir tous les clips à 16 fps a réduit la plage des frames dans chaque vidéo de 65-129 à environ 45-88 frames, ce qui a perturbé mes plages méticuleusement planifiées, parfaites pour les buckets de frames que j'avais définis pour l'entraînement. Heureusement, ce n'était pas grave car j'avais mis en place des règles pour choisir les vidéos, notamment pour gérer ce genre de situations.

Premièrement, la scène ne doit pas avoir de transitions rapides pendant sa durée. Cela car je ne pouvais pas prédire la durée exacte (en frames) des buckets de frames cibles que le formateur établirait - la taille du modèle, la VRAM et d'autres facteurs influent. Par exemple : je pourrais vouloir utiliser un clip unique de 81 frames pour l'entraînement, mais ce n'est pas possible, car j'aurai un OOM sur RTX 3090. Il faudra donc choisir une stratégie d'extraction des frames, selon laquelle un clip sera découpé en plusieurs parties plus courtes (ici un excellent aperçu des diverses stratégies). Et la cohérence sémantique pourrait être rompue (exemple, dans le premier fragment du clip la fille pourrait ouvrir la bouche, mais découpé tel quel, il devient ambigu si elle va pleurer ou rire), ce genre d'incohérence contextuelle peut rendre triste l'encodeur UMT5 de Wan.

Autre point, je voulais réutiliser les légendes pour n'importe quel fragment du clip original sans devoir refaire les captions et cacher à nouveau les embeddings via l'encodeur texte. Captionner des vidéos prend du temps, mais si une scène change radicalement dans sa plage, la légende originale pourrait ne pas correspondre à tous les fragments, réduisant la qualité d'entraînement. En suivant les règles "le clip ne doit pas contenir de transitions rapides de contexte" et "le clip doit être autonome, c’est-à-dire ne pas contenir d’événements incompris depuis le clip lui-même", même si une scène est divisée en sous-fragments, les légendes s’appliqueraient (avec une marge d'erreur acceptable) à chaque fragment.

Après conversion, j'ai parcouru tous les clips et réduit leur nombre total à 240 (en retirant certains clips avec trop de transitions ou, au contraire, trop statiques), formant ainsi la première partie du dataset.

J'ai décidé d'utiliser un dataset mixte de vidéos et images. La deuxième partie du dataset était donc formée de 120 images (en résolution 768x768), extraites de captures d'écran de divers films Ghibli.

Il existe une approche alternative où on entraîne d'abord sur images puis on affine sur vidéos (appliquée avec succès par le créateur de ce LoRA), mais je pense personnellement que ce n'est pas aussi efficace que le mélange en un seul lot (même si je n'ai pas de chiffres précis pour appuyer). Pour étayer mes hypothèses, voici un très bon LoRA qui utilise la même approche mixte pour l'entraînement (et d'ailleurs, c'était également fait sur un GPU 24 Go, si je ne m'abuse).

Pour permettre un entraînement vidéo efficace sur dataset mixte avec des GPUs grand public, j'ai dû trouver le juste équilibre entre résolution, durée et temps d'entraînement, et j'ai décidé de le faire en mélangeant des vidéos basse résolution à longue durée et des images haute résolution - je donnerai plus de détails à ce sujet dans la section Entraînement.

Concernant les captions : les images du dataset ont en fait été réutilisées de certains de mes datasets HV, et elles avaient été captionnées plus tôt avec mon "couteau suisse" VLM pour captionnage de dataset (SFW uniquement), aussi appelé Qwen2-VL-7B-Instruct. J’ai utilisé la prompt de captionnage suivante :

Créez une description très détaillée de cette scène. N’utilisez pas de listes numérotées ni de sauts de ligne. IMPORTANT : la description générée DOIT TOUJOURS commencer par la phrase non modifiée 'Studio Ghibli style. ', suivie de votre description détaillée. La description doit 1) décrire le contenu principal de la scène, 2) décrire les détails de l’environnement et de l’éclairage, 3) identifier le type de plan (ex : plan aérien, gros plan, plan moyen, plan large), et 4) inclure l’atmosphère de la scène (ex : cosy, tendue, mystérieuse). Voici un modèle OBLIGATOIRE : 'Studio Ghibli style. {Action/Description sujet principal}. {Détails environnement et éclairage}. {Style et spécifications techniques}'.

J'avais des doutes sur le fait de recaptionner car la structure cible de la caption était conçue spécifiquement pour HunyuanVideo, et je craignais que Wan ait besoin d'une approche complètement différente. Je les ai laissées telles quelles, et je n'ai aucune idée si c'était la bonne décision, mais globalement, les encodeurs texte modernes sont assez puissants pour ignorer ces limitations. Comme nous le savons, certains modèles comme Flux peuvent même être entraînés sans captions (bien que je pense que l'entraînement avec captions est toujours préférable, mais seulement si elles sont pertinentes).

Pour captionner les vidéos, j’ai testé plusieurs modèles locaux capables de captionner nativement du contenu vidéo :

• CogVLM2-Video-Llama3-Chat (généralement mon option préférée pour captionner les clips)

• MiniCPM-V 2.6

• Apollo-LMMs-Apollo-7B-t32

• LLaVA-Onevision

• VideoChat-Flash-2B

• VideoLLaMA 3

• Ovis2-16B (celui-ci semble vraiment bon ! Mais j'avais déjà captionné le dataset quand je l'ai trouvé, donc je l'utiliserai dans de futurs LoRA)

Il y a plus de modèles, mais ce sont ceux que j'ai testés. Pour ce LoRA, j’ai finalement utilisé Apollo-7B. J’ai utilisé cette simple prompt VLM :

Créez une description très détaillée de cette vidéo. IMPORTANT : La description générée DOIT TOUJOURS commencer par la phrase non modifiée 'Studio Ghibli style. ', suivie de votre description détaillée.

Je joins le dataset complet utilisé en annexe du modèle. Bien qu'il contienne du contenu protégé par droit d'auteur, je pense que cela relève de l'usage équitable. Ce dataset est fourni uniquement à des fins de recherche et d'évaluation éducative des capacités du modèle et pour offrir une transparence quant au processus d'entraînement. Il ne doit pas être utilisé pour une redistribution ou exploitation commerciale.

Entraînement

Pour ceux qui sont intéressés, voici la liste des formateurs que j’ai considérés pour entraîner WanVideo :

• diffusion-pipe - l’OG de l’entraînement HV, permet aussi un entraînement mémoire-efficace de Wan ; piloté par config, dispose d’une interface tierce et de templates runpod (lire plus ici et là). Je l’ai utilisé exclusivement pour HV. Nécessite WSL sur Windows.

• Musubi Tuner - Maintenu par un développeur responsable et sympathique. Piloté par config, communauté chaleureuse, énormément d’options. Actuellement mon choix pour l’entraînement Wan.

• AI Toolkit - Mon formateur préféré pour Flux a récemment ajouté le support de Wan. Rapide, facile à utiliser, piloté par config, dispose aussi d’une UI officielle (que je n’utilise pas 🤷), mais supporte pour l’instant uniquement l’entraînement 14B sans captions, ce qui est la raison principale de mon non-usage.

• DiffSynth Studio - Je n’ai pas eu le temps de le tester et ne suis pas sûr qu’il puisse entraîner des modèles Wan avec 24 Go VRAM. Cependant, maintenu par ModelScope, il mérite d’être examiné de près. Je prévois de le tester bientôt.

• finetrainers - Supporte l’entraînement Wan, mais ne semble pas fonctionner avec GPUs 24 Go (pour l’instant)

• SimpleTuner - A obtenu le support de Wan la semaine dernière, donc je n’ai pas encore eu l’occasion de l’essayer. Il mérite certainement l’attention car le développeur principal est passionné et compétent.

• Zero-to-Wan - Supporte l’entraînement uniquement pour des modèles 1.3B.

• WanTraining - Je dois mentionner ce projet, soutenu par un développeur qui a fait un travail impressionnant, y compris LoRA distillé par guidage et LoRA contrôle.

J’ai donc utilisé Musubi Tuner. Pour référence, voici mes paramètres matériels : i5-12600KF, RTX 3090, Windows 11, 64 Go RAM. Les commandes et fichiers de config que j’ai utilisés sont les suivants.

• Pour mettre en cache les latents VAE (rien de spécifique ici, juste la commande par défaut)

python wan_cache_latents.py --dataset_config G:/samples/musubi-tuner/_studio_ghibli_wan14b_v01_dataset.toml --vae G:/samples/musubi-tuner/wan14b/vae/wan_2.1_vae.safetensors

• Pour mettre en cache les embeddings de l'encodeur texte (par défaut) :

python wan_cache_text_encoder_outputs.py --dataset_config G:/samples/musubi-tuner/_studio_ghibli_wan14b_v01_dataset.toml --t5 G:/samples/musubi-tuner/wan14b/tenc/models_t5_umt5-xxl-enc-bf16.pth --batch_size 16 

• Pour lancer l’entraînement :

accelerate launch --num_cpu_threads_per_process 1 --mixed_precision bf16 wan_train_network.py ^
    --task t2v-14B ^
    --dit G:/samples/musubi-tuner/wan14b/dit/wan2.1_t2v_14B_bf16.safetensors ^
	--vae G:/samples/musubi-tuner/wan14b/vae/wan_2.1_vae.safetensors ^
	--t5 G:/samples/musubi-tuner/wan14b/tenc/models_t5_umt5-xxl-enc-bf16.pth ^
	--sdpa ^
	--blocks_to_swap 10 ^
	--mixed_precision bf16 ^
	--fp8_base ^
	--fp8_scaled ^
	--fp8_t5 ^
	--dataset_config G:/samples/musubi-tuner/_studio_ghibli_wan14b_v01_dataset.toml ^
    --optimizer_type adamw8bit ^
	--learning_rate 5e-5 ^
	--gradient_checkpointing ^
    --max_data_loader_n_workers 2 ^
	--persistent_data_loader_workers ^
    --network_module networks.lora_wan ^
	--network_dim 32 ^
	--network_alpha 32 ^
    --timestep_sampling shift ^
	--discrete_flow_shift 3.0 ^
	--save_every_n_epochs 1 ^
	--seed 2025 ^
    --output_dir G:/samples/musubi-tuner/output ^
	--output_name studio_ghibli_wan14b_v01 ^
	--log_config ^
	--log_with tensorboard ^
	--logging_dir G:/samples/musubi-tuner/logs ^
	--sample_prompts G:/samples/musubi-tuner/_studio_ghibli_wan14b_v01_sampling.txt ^
	--save_state ^
	--max_train_epochs 50 ^
	--sample_every_n_epochs 1

Encore une fois, rien d’exceptionnel ici. J’ai dû utiliser le paramètre blocks_to_swap car sinon, avec ma config de dataset (voir ci-dessous), je faisais face à des contraintes de VRAM 24 Go. Les hyperparamètres sont restés majoritairement par défaut. Je ne voulais pas prendre de risques après une mauvaise expérience - 60 heures d’entraînement HV perdues à cause de valeurs trop ambitieuses pour flow shift et optimisateurs adaptatifs au lieu du bon vieux adamw.

• Fichier de prompts pour l’échantillonnage durant l’entraînement :

# prompt 1
Studio Ghibli style. Femme aux cheveux blonds marche sur la plage, zoom arrière de la caméra.  --w 384 --h 384 --f 45 --d 7 --s 20

# prompt 2
Studio Ghibli style. Femme dansant au bar. --w 384 --h 384 --f 45 --d 7 --s 20

• Configuration du dataset (partie la plus importante ; je vais expliquer la réflexion derrière après) :

[general]
caption_extension = ".txt"
enable_bucket = true
bucket_no_upscale = true

[[datasets]]
image_directory = "H:/datasets/studio_ghibli_wan_video_v01/images/768x768"
cache_directory = "H:/datasets/studio_ghibli_wan_video_v01/images/768x768/cache"
resolution = [768, 768]
batch_size = 1
num_repeats = 1

[[datasets]]
video_directory = "H:/datasets/studio_ghibli_wan_video_v01/videos/1920x1040"
cache_directory = "H:/datasets/studio_ghibli_wan_video_v01/videos/1920x1040/cache_1"
resolution = [768, 416]
batch_size = 1
num_repeats = 1
frame_extraction = "head"
target_frames = [1, 21]

[[datasets]]
video_directory = "H:/datasets/studio_ghibli_wan_video_v01/videos/1920x1040"
cache_directory = "H:/datasets/studio_ghibli_wan_video_v01/videos/1920x1040/cache_2"
resolution = [384, 208]
batch_size = 1
num_repeats = 1
frame_extraction = "uniform"
target_frames = [45]
frame_sample = 2

Ma configuration de dataset se compose de trois parties.

Je commence par la dernière, qui contient le tableau principal de données - 240 clips en résolution 1920x1040 et durée variant de 45 à 88 frames.

Évidemment, entraîner sur des clips pleine résolution 1920x1040 et pleine durée sur un RTX 3090 était exclu. Je devais trouver la résolution et la durée minimales pour éviter les erreurs OOM tout en gardant les fragments de buckets aussi longs que possible. Des fragments longs aident le modèle à apprendre le mouvement, le timing et les motifs spatiaux (comme les tremblements de cheveux, le balancement des tissus, les dynamiques des liquides, etc.) du style Ghibli - ce que l’on ne peut pas obtenir avec des images fixes.

En formant HV, je me souvenais qu’un bon point de départ pour estimer la résolution disponible sur GPU 24 Go est 512x512x33. J’ai choisi le pattern d’extraction « uniforme » des frames, assurant que tous les fragments extraits font au moins 45 frames. Puisque, comme écrit plus haut, on plafonne à 88 frames après conversion à 16 fps, cela empêche que les clips soient divisés en plus de deux morceaux, ce qui rallongerait trop les époques. En même temps, une plage de 45 frames (~3s) devrait suffire pour que le modèle apprenne le flux spatial du style.

Avec une cible fixée à 45 frames, j’ai testé plusieurs résolutions. J’ai utilisé un script pour analyser tous les clips dans un dossier et suggérer des combinaisons largeur-hauteur valides respectant le ratio original (1920/1040 ≈ 1,85) et divisibles par 16 (exigence modèle).

Finalement, j’ai trouvé qu’utiliser [384, 208] pour la taille du bucket et configurer --blocks_to_swap 10 empêchait les erreurs OOM et le passage en mémoire partagée (qui menait à 160 s/it). Le revers était que la vitesse d’entraînement tombait à environ 11-12 s/it. Rétrospectivement, baisser la résolution à [368, 192] aurait pu monter la vitesse à ~8 s/it, ce qui aurait été parfait (proche de ce que j’obtiens en entraînant Flux en 1024p dans AI Toolkit). Cela m’aurait permis d’économiser environ 20 heures d’entraînement sur les 90 heures (~28000 steps), même si à l’époque je ne pensais pas dépasser 20k steps.

À noter que j’ai entraîné sous Windows avec mon écran connecté au GPU (et utilisé mon PC pour coder en même temps 😼). Sur Linux (par exemple avec diffusion-pipe) et en utilisant le GPU interne pour l’affichage, il serait peut-être possible d’augmenter un peu la résolution spatiotemporelle sans rencontrer d’Erreur OOM ou limites de mémoire partagée (ce qui semble spécifique à Windows).

Passons à la première partie (120 images en résolution 768x768). Initialement, je voulais entraîner sur des images 1024p, mais c’eût été trop lourd et lent. Mon plan était d’entraîner sur images HD et vidéos basse résolution simultanément pour assurer une meilleure généralisation. L’idée était que les images haute résolution compenseraient la résolution plus basse des clips. De plus, un pré-entraînement mixte vidéo + image est d’ailleurs la méthode utilisée pour entraîner WAN, donc je pensais que cela favoriserait aussi l’apprentissage du style « en amont ».

Enfin, la deuxième partie, aussi importante pour la généralisation (ceci n’est pas une supposition « scientifique » mais cela semble raisonnable). L’idée était de réutiliser les mêmes clips de la troisième section mais en entraînant seulement sur la première frame et les 21 premières frames. Cette approche, je l’espérais, faciliterait l’apprentissage des caractéristiques de mouvement temporel du style. En même temps, cela me permettait d’augmenter la résolution de la deuxième section à [768, 416].

Au final, je cherchais à obtenir une "généralisation croisée" entre :

• Section 1 : images haute résolution (768x768)

• Section 2 : frames uniques moyenne résolution et clips de 21 frames (768x416)

• Section 3 : clips basse résolution de 45 frames (384x208)

De plus, la deuxième et la grande partie de la troisième section partageaient la même frame de départ, ce qui, je pensais, serait bénéfique pour l’usage du LoRA en mode I2V. Tout cela semblait la meilleure manière d’exploiter pleinement mon dataset sans dépasser les limites matérielles.

Bien sûr, je ne suis pas le premier à proposer cette approche, mais elle paraît logique et raisonnable, et j’espère que plus de créateurs comprendront que vous n’avez pas besoin d’une A100 pour entraîner un LoRA vidéo pour Wan.

Fait amusant : je pensais qu’une époque comporterait 1080 échantillons : 120 images (section 1) + 240 frames uniques (section 2, bucket "head"=1) + 240 clips de 21 frames (section 2, bucket "head"=21) + 480 clips de 45 frames (section 2, bucket "uniform"=45, échantillonnés 2 fois). Mais, après le début, j’ai découvert qu’il y en avait en fait 1078. En creusant, j’ai vu que deux clips comptés par mes scripts (qui utilisent ffprobe de ffmpeg) étaient en fait plus courts que 45 frames, causant un arrondi. Ce n’était pas grave, j’ai juste continué sans ces deux clips, mais c’est pourquoi le nombre de steps du LoRA final semblait décalé :)

L’entraînement s’est bien passé. Je ne montrerai pas les graphiques de perte car je suis trop timide ne pense pas qu’ils soient très parlants. Je m’en sers surtout pour vérifier si la distribution des pertes devient trop similaire entre les époques - ce qui est un signal possible de sur-apprentissage.

J’ai entraîné jusqu’à 28000 steps, puis passé plusieurs jours à choisir le meilleur checkpoint. Une autre chose que j’aurais pu faire mieux est de prendre des checkpoints non seulement à la fin de chaque époque, mais aussi en cours d’époque. Étant donné qu’une époque fait 1078 steps, il se peut qu’un checkpoint avec de meilleurs résultats que celui final se soit perdu entre temps.

Je considère intégrer une estimation de la perte de validation dans mon pipeline d’entraînement (plus de détails ici), mais ce n’est pas encore fait.

Peut-on simplifier ? Probablement, oui. Dans mon prochain LoRA, je testerai si les images en section 1 étaient redondantes. J’aurais pu simplement configurer une autre section et réutiliser la première frame des clips, mais en haute résolution. D’un autre côté, je voulais que le dataset soit varié, donc j’ai pris des captures d’autres scènes que celles des clips, donc pas redondant selon moi.

Je ne suis même pas sûr que la section 2 soit nécessaire. WAN lui-même (d’après son rapport technique) a été préentraîné sur clips 192px, donc entraîner autour de 352x192x45 devrait être efficace et optimiser mon matériel. Idéalement, j’utiliserais des clips de 5 secondes (16 fps * 5s + 1 = 81 frames), mais ce n’est pas faisable sur un RTX 3090 sans échanger agressivement des blocs.

Conclusion

Au-delà du plaisir et des centaines de milliers de clips incroyables, voici quelques leçons tirées de l’entraînement de ce LoRA. Je précise que ces pratiques sont basées sur mon expérience personnelle et observations, sans preuves analytiques strictes, et je n’ai testé pour l’instant que l’entraînement de style. Je prévois d’explorer bientôt l’entraînement conceptuel pour tester d’autres hypothèses et voir si elles s’appliquent également.

• Vous pouvez entraîner Wan-14B sur des GPUs grand public avec des vidéos. 368x192x45 semble un bon point de départ.

• Compensez l’apprentissage ciblé du style sur vidéos basse résolution par des images haute résolution pour une meilleure généralisation.

• Combinez diverses méthodes d’extraction de frames sur les mêmes datasets pour maximiser l’efficacité et l’utilisation matérielle.

Beaucoup, sinon tout, ce que j’ai appris pour créer ce LoRA vient de la lecture sans fin de posts sur r/StableDiffusion, de ma veille 24/7 sur l’incroyable Discord Banodoco, de la lecture des commentaires et de l’ouverture de chaque clip NSFW sur chaque modèle WanVideo ici sur Civitai, et d’exploration de chaque issue trouvée sur les dépôts musubi-tuner, diffusion-pipe, Wan2.1 et autres. 😽

P.S.

Ce modèle est une vitrine technologique des capacités des systèmes modernes de génération vidéo. Il n’est pas destiné à nuire ni à violer les droits des créateurs originaux. Il sert plutôt d’hommage au travail remarquable des artistes dont les créations ont inspiré ce modèle.