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

Questo LoRA è presente su OpenMuse, un'iniziativa curata dedicata ai video LoRA open source e alle opere creative che rendono possibili. Concentrato su modelli come Wan2.1, LTX-Video e HunyuanVideo, OpenMuse mette in evidenza strumenti e opere d'arte di alta qualità provenienti da tutto l'ecosistema. Nato nella comunità Banodoco, OpenMuse è una casa in crescita per l'arte AI aperta e collaborativa, pensata per ispirare creatori, suscitare curiosità e offrire qualcosa di cui essere orgogliosi da condividere, anche con chi è scettico sull'arte generata dall'AI.

Descrizione

Sono molto felice di condividere il mio magnum opus LoRA, a cui ho lavorato nell'ultimo mese da quando è uscito Wan. Questo è davvero il miglior LoRA su Civitai che abbia mai addestrato, e devo dire (ancora una volta) che WanVideo è un modello straordinario.

Il LoRA è stato addestrato per circa 90 ore su una RTX 3090 con musubi-tuner utilizzando un dataset misto di 240 clip e 120 immagini. Avrei potuto farlo più velocemente, ma ero ossessionato dal superare i limiti per creare un modello di stile all'avanguardia. Sta a voi giudicare se ho avuto successo.

Utilizzo

La frase trigger è stile Studio Ghibli - tutte le didascalie per i dati di addestramento iniziavano con queste parole.

Tutti i clip che pubblico in galleria sono output grezzi usando un LoRA con modello base Wan-T2V-14B (anche se gli ultimi video possono includere LoRA self-forcing per accelerare l'inferenza, leggi più sotto), senza ulteriori post-processing, upscaling o interpolazione.

La compatibilità con altri LoRA e con modelli Wan-I2V non è stata testata.

I workflow sono integrati con ogni video (quindi puoi semplicemente scaricarli e trascinare il video in ComfyUI per aprirlo). Come esempio, qui c'è il JSON del workflow (basato sul wrapper di Kijai), che usa il LoRA self-forcing (creato da blyss), estratto dal modello Wan2.1-T2V-14B-StepDistill-CfgDistill di lightx2v. Ho scelto la versione fatta da blyss (e non il LoRA originale di Kijai), perché, dai miei test, offre la massima compatibilità e accelera solo l'inferenza, senza ulteriori dettagli o bias stilistici. (Questo è anche il motivo per cui uso il modello base Wan e non merge come AniWan o FusionX.)

Uso il LoRA di accelerazione con il sampler UniPC (e occasionalmente DPM++). Dalla mia esperienza, UniPC si comporta meglio per animazioni 2D rispetto a LCM, che tende a privilegiare un realismo che voglio evitare. Di solito applico anche il nodo NAG, così posso usare prompt negativi con CFG=1. Dai primi test, rispetto al workflow precedente con TeaCache, oltre al grande guadagno di velocità (un clip 640×480×81 a 6 step si rende in ~1 minuto invece di 6 su RTX 3090), migliora leggermente anche la fluidità del movimento e il rendering del testo.

I LoRA aggiornati lightx2v sono anche molto impressionanti per velocità e qualità preservata. Sto usando un LoRA rank 128, ma anche quelli da 32 e 64 danno ottimi risultati. Ecco un esempio del workflow in formato JSON. Ho scoperto che abbassare la forza del LoRA lightx2v a 0.9, aumentare i passaggi a 8 e usare UniPC o DPMPP produce output molto buoni.

E qui un workflow “legacy” in formato JSON. È stato usato per generare il 90% dei video in galleria per questo LoRA. Era costruito su nodi wrapper e includeva molte ottimizzazioni (più info qui), fra cui checkpoint fp8_e5m2 + torch.compile, SageAttention 2, TeaCache, Enhance-A-Video, Fp16_fast, SLG e (qualche volta) Zero-Star (alcuni di questi migrati nel nuovo workflow), ma il rendering di un clip 640x480x81 richiedeva circa 5 minuti (RTX 3090) nel workflow più vecchio. Seppur il workflow legacy dimostri una qualità leggermente superiore in alcuni aspetti specifici (palette, fluidità), il rallentamento 5x è un notevole svantaggio e motivo per cui sono passato alla versione powered lightx2v.

Prompting

Per generare la maggior parte dei prompt, di solito applico il seguente meta-prompt in ChatGPT (o Claude, o qualsiasi altro LLM capace), che aiuta a migliorare le descrizioni “grezze”. Questo prompt si basa sul codice ufficiale di estensione prompt degli sviluppatori Wan e funziona così:

Sei un prompt engineer, specializzato nel perfezionare input utente in prompt di alta qualità per generazione video nello stile distintivo Studio Ghibli. Assicuri che l'output rispecchi l'intento originale arricchendo dettagli per chiarezza visiva e del movimento.

Requisiti del compito:
- Se l'input utente è troppo breve, espandilo con dettagli ragionevoli per creare una scena più vivida e completa senza alterare il significato centrale.
- Enfatizza caratteristiche chiave come aspetto dei personaggi, espressioni, abbigliamento, posture e relazioni spaziali.
- Mantieni sempre l'estetica visiva Studio Ghibli - sfondi morbidi simili ad acquerelli, design dei personaggi espressivi ma semplici, e un'atmosfera calda e nostalgica.
- Migliora le descrizioni di movimento e movimenti di camera per un flusso animato naturale. Includi movimenti gentili e organici che si adattano allo stile narrativo di Ghibli.
- Conserva il testo originale tra virgolette o titoli garantendo che il prompt sia chiaro, immersivo e lungo 80-100 parole.
- Tutti i prompt devono iniziare con "Studio Ghibli style." Nessun altro stile artistico deve essere usato.

Esempi di prompt revisionati:
"Studio Ghibli style. Una giovane ragazza con capelli castani corti e occhi curiosi sta su una collina erbosa illuminata dal sole, il vento muove delicatamente il suo semplice vestito bianco. Osserva un gruppo di uccelli volare nel cielo dorato, con i piedi nudi che affondano leggermente nella terra morbida. La scena è immersa in una luce calda e nostalgica, con alberi rigogliosi che oscillano in lontananza. Una brezza leggera porta i suoni della natura. Inquadratura media, angolazione leggermente bassa, con una lenta panoramica cinematografica che cattura il movimento sereno."
"Studio Ghibli style. Un piccolo villaggio al tramonto, lanterne che brillano dolcemente sotto le grondaie delle case di legno. Un ragazzo in yukata blu corre lungo un sentiero di pietra stretto, i sandali che battono a terra mentre inseguono una lucciola. La sua espressione eccitata si riflette nel fiume scintillante accanto a lui. L'atmosfera è ricca di arancioni caldi e blu freschi, evocando una serata estiva tranquilla. Inquadratura media con movimento di tracking fluido che segue i passi energici del ragazzo."
"Studio Ghibli style. Una foresta mistica immersa nella nebbia mattutina, con alberi imponenti che si arcuano su un sentiero coperto di muschio. Una ragazza con un semplice mantello verde posa delicatamente la mano sul dorso di una creatura massiccia con occhi gentili che somiglia a un antico cervo. Il suo pelo scintilla lievemente mentre la luce penetra attraverso la fitta chioma illuminando il polline fluttuante. La camera fa uno zoom lento, enfatizzando la loro connessione silenziosa. Una brezza leggera muove le foglie, e piccole creature luminose spuntano da dietro le radici."

Istruzioni:
Ora ti fornirò un prompt da riscrivere. Per favore espandilo e perfezionalo in inglese assicurandoti che rispetti l'estetica Studio Ghibli. Anche se l'input è un'istruzione invece che una descrizione, riscrivilo in un prompt completo e visivamente ricco senza risposte aggiuntive o virgolette.

Il prompt è: "YOUR PROMPT HERE".

Sostituisci YOUR PROMPT HERE con qualcosa come Giovane ragazza bionda in piedi sulla montagna vicino alla spiaggia sotto la pioggia o altro a piacere.

Il prompt negativo include sempre lo stesso testo base (ma può avere parole aggiunte in base al prompt specifico):

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

Dataset

In questa e nelle sezioni seguenti farò un po' di chiacchiere :) Sentitevi liberi di saltare subito alla Conclusione, ma magari qualcuno troverà qualche informazione utile in questo muro di testo. Quindi...

La fase di selezione del dataset è stata la parte “più facile”, avevo già tutti i film Ghibli nella massima qualità possibile divisi in scene - oltre 30.000 clip in risoluzione 1920x1040 e bitrate elevato. Stanno pazientemente aspettando il giorno in cui finalmente farò un fine-tuning completo di qualche modello video con essi.

Avevo anche già preparato circa 300 clip per addestrare la v0.7 di HV LoRA (in realtà stavo per iniziare l’addestramento quando è uscito Wan). Questi clip erano nel range 65-129 frame, che considero ottimale per addestrare HV su video, e tutti a 24 fps. Per Wan, invece, volevo un range differente (non superiore a 81 frame, spiegazione più avanti nella sezione "Training"). Inoltre servivano a 16 fps. Non sono ancora completamente sicuro se 16 fps rigorosi siano necessari, ma avevo avuto problemi con HV quando i clip erano a 30 fps invece dei suoi 24 nativi, quindi ho deciso di restare a 16 fps.

Devo menzionare che per elaborare il dataset di solito creo molti piccoli script "una tantum" (con l’aiuto di Claude, ChatGPT e DeepSeek) - includono mini-GUI per selezione manuale dei video, one-liner per dividere i frame, script per output di vari stats helper, sezionare clip per range, creare bucket in anticipo, ecc. Non pubblico questi script perché sono disordinati, pieni di valori hardcoded e pensati per un uso una tantum. Ormai chiunque può facilmente crearne di simili facendo richieste ai sopracitati LLM.

Convertire tutti i clip a 16 fps ha ristretto il range di frame in ogni video da 65-129 a circa 45-88 frame, scombinando i range pianificati meticolosamente e perfetti per i frame bucket impostati per l’addestramento. Per fortuna non è stato un grosso problema perché avevo alcune regole in fase di selezione per gestire queste situazioni.

Prima di tutto, la scena non deve avere transizioni rapide durante la sua durata. Serve perché non potevo prevedere la durata esatta (in frame) dei bucket frame che l’addestratore stabilirà - la dimensione modello, VRAM, e altri fattori influenzano questo. Per esempio: potrei voler usare un singolo clip lungo 81 frame per addestrare, ma non potrei farlo per OOM sulla RTX 3090. Quindi bisogna scegliere una strategia di estrazione dei frame, in base alla quale il clip potrebbe essere diviso in più parti più brevi (qui c’è un’ottima spiegazione delle varie strategie). E la coerenza semantica potrebbe essere rotta (per esempio, nel primo frammento di clip una ragazza potrebbe aprire bocca, ma dal frammento clippato diventerebbe ambiguo se piangerà o riderà), e questo tipo di incoerenza contestuale potrebbe far sentire triste l’encoder UMT5 di Wan.

Un altro aspetto è che volevo poter riutilizzare le didascalie per qualsiasi frammento del clip originale senza occuparmi di ricaptarle e ricacharle tramite l’encoder testuale. Il captioning dei video richiede molto tempo, ma se una scena cambia drasticamente nel suo range, la didascalia originale potrebbe non adattarsi a tutti i frammenti, riducendo la qualità dell’addestramento. Seguendo le regole "il clip non deve contenere transizioni rapide di contesto" e "il clip deve essere autosufficiente, cioè non deve contenere eventi che non possono essere capiti dal clip stesso", anche se una scena è divisa in sub-frammenti, le didascalie (entro un margine di errore accettabile) si adatteranno a ogni frammento.

Dopo la conversione ho controllato tutti i clip e li ho ridotti a 240 (ho semplicemente eliminato quelli con troppe transizioni o, viceversa, troppo statici), che hanno formato la prima parte del dataset.

Ho deciso di usare un dataset misto di video e immagini. La seconda parte del dataset è composta da 120 immagini (a risoluzione 768x768), prese da screenshot di vari film Ghibli.

Esiste un approccio alternativo dove si addestra prima su immagini e poi si fa fine-tuning su video (è stato applicato con successo dal creatore di questo LoRA), ma penso personalmente che non sia valido quanto fare mixing in un singolo batch (anche se non ho numeri precisi a supporto). A conferma delle mie supposizioni, ecco un ottimo LoRA che usa lo stesso approccio misto per l’addestramento (ed è stato fatto pure su GPU da 24 GB, se non erro).

Per permettere un effective video training su dataset misti e GPU consumer-level ho dovuto trovare il giusto equilibrio tra risoluzione, durata e tempo di addestramento, e ho deciso di farlo mixando video a bassa risoluzione e lunga durata con immagini ad alta risoluzione - darò più dettagli in sezione Training.

Per quanto riguarda il captioning: le immagini del dataset sono in realtà state riutilizzate da alcuni miei dataset HV, con didascalie fatte in precedenza usando il mio “coltellino svizzero” VLM per il captioning dataset (solo SFW), conosciuto come Qwen2-VL-7B-Instruct. Ho usato il seguente prompt di captioning:

Crea una descrizione molto dettagliata di questa scena. Non usare liste numerate né interruzioni di linea. IMPORTANTE: la descrizione output DEVE SEMPRE iniziare con la frase invariata 'Studio Ghibli style. ', seguita dalla tua descrizione dettagliata. La descrizione deve 1) descrivere il contenuto principale della scena, 2) descrivere l’ambiente e i dettagli di illuminazione, 3) identificare il tipo di inquadratura (es. ripresa aerea, primo piano, inquadratura media, campo lungo), e 4) includere l’atmosfera della scena (es. accogliente, tesa, misteriosa). Ecco un template che DEVI usare: 'Studio Ghibli style. {Azione/Descrizione soggetto primario}. {Dettagli ambiente e illuminazione}. {Stile e specifiche tecniche}'.

Avevo dubbi se ricaptare o no perché la struttura del caption target era pensata specificamente per HunyuanVideo, e temevo che Wan potesse aver bisogno di un approccio completamente diverso. Li ho lasciati così, senza modificarli, e non so se sia stata la scelta giusta, ma in generale gli encoder testuali moderni sono abbastanza potenti da ignorare queste limitazioni. Come sappiamo, modelli come Flux e altri possono anche essere addestrati senza didascalie (anche se credo che farlo con didascalie sia sempre meglio - ma solo se sono rilevanti per il contenuto).

Per il captioning dei video ho testato molti modelli locali in grado di generare didascalie direttamente da contenuti video:

• CogVLM2-Video-Llama3-Chat (di solito è la mia opzione preferita per il captioning clip)

• MiniCPM-V 2.6

• Apollo-LMMs-Apollo-7B-t32

• LLaVA-Onevision

• VideoChat-Flash-2B

• VideoLLaMA 3

• Ovis2-16B (questo sembra davvero ottimo! Ma avevo già fatto il captioning del dataset quando l’ho trovato, quindi lo userò per futuri LoRA)

Ci sono altri modelli, ma questi sono quelli che ho testato. Per questo LoRA ho scelto di usare Apollo-7B. Ho usato questo semplice prompt VLM:

Crea una descrizione molto dettagliata di questo video. IMPORTANTE: la descrizione output DEVE SEMPRE iniziare con la frase invariata 'Studio Ghibli style. ', seguita dalla tua descrizione dettagliata.

Allego il dataset completo che ho usato come appendice al modello. Sebbene contenga materiale protetto da copyright, credo che rientri nel fair use. Questo dataset è fornito solo per ricerca e valutazione educativa delle capacità del modello e per trasparenza riguardo al processo di addestramento. Non dovrebbe essere usato per ridistribuzione o sfruttamento commerciale.

Addestramento

Se a qualcuno interessa, ecco la lista dei trainer che ho considerato per addestrare WanVideo:

• diffusion-pipe - OG per l’addestramento HV, ma permette anche addestramento memory-efficient Wan; basato su config, ha GUI di terze parti e template runpod (leggi di più qui e qui). L’ho usato esclusivamente per HV. Per Windows richiede WSL.

• Musubi Tuner - Mantenuto da sviluppatore responsabile e cordiale. Basato su config, ha comunità accogliente e molte opzioni. È la mia scelta attuale per addestrare Wan.

• AI Toolkit - Il mio trainer preferito per Flux recentemente ha supporto per Wan. È veloce, facile da usare, config-driven, ha anche UI ufficiale (che però non uso 🤷), ma attualmente supporta solo addestramento 14B senza didascalie, motivo principale per cui non lo uso.

• DiffSynth Studio - Non ho ancora avuto tempo di testarlo e non so se può addestrare modelli Wan con 24 GB VRAM. Però è mantenuto da ModelScope, quindi merita attenzione. Ho in programma di testarlo presto.

• finetrainers - Supporta addestramento Wan, ma sembra non funzionare ancora con GPU 24 GB.

• SimpleTuner - Ha ottenuto supporto per Wan la scorsa settimana, quindi non l’ho ancora provato. Merita attenzione perché lo sviluppatore principale è una persona davvero appassionata e competente.

• Zero-to-Wan - Supporta addestramento solo per modelli da 1.3B.

• WanTraining - Lo menziono perché è supportato da uno sviluppatore che ha fatto un lavoro impressionante, includendo LoRA guida-distilled e LoRA di controllo.

Quindi, ho usato Musubi Tuner. Per riferimento, ecco le mie specifiche hardware: i5-12600KF, RTX 3090, Windows 11, 64Gb RAM. I comandi e file di configurazione usati sono i seguenti.

• Per cachare i VAE latent (nulla di specifico, solo comando default)

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

• Per cachare gli output dell’encoder testuale (default):

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 

• Per lanciare l’addestramento:

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

Di nuovo, niente di speciale qui. Ho dovuto usare il parametro blocks_to_swap perché altrimenti, con la mia configurazione dataset (vedi sotto), incontravo limiti di 24 Gb di VRAM. Gli iperparametri sono stati lasciati per lo più di default. Non volevo rischiare nulla dopo una brutta esperienza - 60 ore di addestramento HV perse per essere stato troppo ambizioso con i valori di flow shift e ottimizzatori adattativi invece del classico adamw.

• File prompt per il sampling durante l’addestramento:

# prompt 1
Studio Ghibli style. Donna con capelli biondi cammina sulla spiaggia, zoom out della camera.  --w 384 --h 384 --f 45 --d 7 --s 20

# prompt 2
Studio Ghibli style. Donna che danza al bar. --w 384 --h 384 --f 45 --d 7 --s 20

• Configurazione dataset (la parte più importante; spiegherò il pensiero che mi ha portato a essa in seguito):

[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

Il mio setup del dataset consiste di tre parti.

Inizio dalla ultima, che contiene l’array principale dei dati - 240 clip in risoluzione 1920x1040 e durata variabile tra 45 e 88 frame.

Ovviamente addestrare su clip a piena risoluzione 1920x1040 e durata piena su RTX 3090 era fuori questione. Dovevo trovare la minima risoluzione e durata frame che evitassero errori OOM mantenendo i frammenti bucket il più lunghi possibile. Frammenti più lunghi aiutano il modello ad apprendere movimento, timing e pattern spaziali (come tremolio capelli, onde dei tessuti, dinamiche liquidi ecc.) dello stile Ghibli - cosa impossibile con frame fissi.

Dall’addestramento HV ricordavo come buon riferimento per stima della risoluzione disponibile su GPU 24 Gb 512x512x33. Ho scelto il pattern di estrazione frame "uniform" assicurando che tutti i frammenti estratti fossero almeno 45 frame. Poiché, come scritto prima, dopo la conversione a 16 fps massimo 88 frame, questo approccio evitava di dividere i clip in più di due parti, cosa che avrebbe reso le epoche troppo lunghe. Allo stesso tempo una durata di 45 frame (~3s) dovrebbe bastare al modello per apprendere il flusso spaziale dello stile.

Con target fisso a 45 frame, ho testato diverse risoluzioni. Ho usato uno script per analizzare tutti i clip in una cartella e suggerire combinazioni di larghezza-altezza valide che mantenessero il rapporto d’aspetto originale (1920/1040 ≈ 1.85) e fossero divisibili per 16 (una richiesta del modello).

Alla fine ho trovato che usare [384, 208] per la dimensione bucket e impostare --blocks_to_swap 10 evitava errori OOM e spingere nella memoria condivisa (che portava a 160 s/it). Lo svantaggio era che la velocità di addestramento scendeva a circa 11-12 s/it. Col senno di poi abbassare la risoluzione a [368, 192] avrebbe potuto portare la velocità a ~8 s/it, ottimo risultato (vicino a quanto ottengo addestrando Flux a 1024p in AI Toolkit). Avrebbe risparmiato circa 20 ore di addestramento su 90 ore totali (~28000 step), anche se allora non pensavo sarebbe andato oltre 20K step.

Va detto che ho addestrato su Windows con monitor collegato alla GPU (e usavo il PC anche per programmare 😼). Su Linux (per esempio con diffusion-pipe) e usando la GPU interna per output monitor, forse si potrebbero usare risoluzioni spaziotemporali leggermente superiori senza incorrere in OOM o limiti di memoria condivisa (credo sia specifico di Windows).

Ora della prima parte (120 immagini a risoluzione 768x768). Inizialmente volevo addestrare su immagini 1024p, ma ho deciso sarebbe stato eccessivo e lento. Il piano era addestrare su immagini HD e video a bassa risoluzione simultaneamente per migliorare la generalizzazione. L’idea è che immagini ad alta risoluzione compensano la bassa risoluzione dei clip video. Inoltre il pretraining congiunto video + immagine è come è stato addestrato WAN, dunque pensavo questo approccio favorisse anche lo “style learning upstream”.

Infine la seconda parte, importante per la generalizzazione (di nuovo, non è un’assunzione scientifica ma pare sensata). L’idea era riutilizzare gli stessi clip della terza sezione ma addestrare solo sul primo frame e sui primi 21 frame. Questo approccio pensavo facilitasse apprendimento temporale delle feature di stile in movimento. Allo stesso tempo consentiva di aumentare la risoluzione per la seconda sezione a [768, 416].

In sostanza speravo di ottenere “cross-generalization” tra:

• Sezione 1 immagini ad alta risoluzione (768x768)

• Sezione 2 singoli frame e clip di 21 frame a media risoluzione (768x416)

• Sezione 3 clip a bassa risoluzione di 45 frame (384x208)

Inoltre, sia la seconda che la parte più grande della terza sezione condividono lo stesso frame iniziale, che pensavo fosse utile per l’uso del LoRA in scenari I2V. Tutto ciò sembrava il modo migliore per utilizzare al massimo il dataset senza superare i limiti hardware.

Sicuramente non sono il primo ad aver ideato questo approccio, ma è logico e ragionevole e spero più creatori capiscano che non serve un A100 per addestrare un LoRA video-based per Wan.

Curiosità: mi aspettavo che un’epoca consistesse in 1080 campioni: 120 immagini (1a sezione dataset) + 240 frame singoli (2a sezione, bucket frame "head"=1) + 240 clip da 21 frame ciascuno (2a sezione, bucket frame "head"=21) + 480 clip da 45 frame ciascuno (2a sezione, bucket uniform=45, campionato 2 volte). Però, iniziando l’addestramento, ho scoperto fossero in realtà 1078 campioni. Scavando, ho scoperto che due clip calcolati dai miei script (che usano il comando ffprobe di ffmpeg per contare frame) erano in realtà più corti di 45 frame, quindi difettosi nel conteggio. Non è stato un problema, ho semplicemente continuato l’addestramento senza questi due clip, ma ecco perché il numero di step per il LoRA finale sembrava sbagliato :)

L’addestramento è andato liscio. Non mostro grafici loss perché sono troppo timido non penso abbiano molto significato. Li uso soprattutto per vedere se la distribuzione loss diventa troppo simile tra epoche - quello indica potenziale overfitting.

Ho addestrato fino a 28000 step, poi ho passato alcuni giorni a selezionare il miglior checkpoint. Un’altra cosa che avrei potuto migliorare è fare checkpoint non solo a fine ogni epoca ma anche durante. Ogni epoca dura 1078 step, quindi è possibile che un checkpoint con risultati migliori sia stato perso nel mezzo.

Sto pensando di integrare stima loss di validazione nel mio pipeline di addestramento (di più qui), ma non l’ho ancora fatto.

Si poteva semplificare? Probabilmente sì. Nel prossimo LoRA testerò se la parte extra di immagini nella sezione 1 fosse ridondante. Avrei potuto creare una sezione dataset separata e riutilizzare solo il primo frame dei clip, ma ad alta risoluzione. D’altra parte volevo che il dataset fosse vario, perciò ho usato screenshot da scene diverse rispetto ai clip, quindi non erano ridondanti.

Non sono nemmeno certo se la seconda sezione fosse necessaria. Poiché WAN stesso (secondo il suo report tecnico) è stato pre-addestrato su clip da 192px, addestrare a circa 352x192x45 dovrebbe essere efficace e dare il massimo con il mio hardware. Idealmente userei clip da 5 secondi (16 fps * 5s + 1 = 81 frame), ma non è possibile con RTX 3090 senza swapping blocchi aggressivo.

Conclusione

Oltre al divertimento e alle centinaia migliaia di clip fenomenali, ecco qualche insight che ho guadagnato addestrando questo LoRA. Queste pratiche sono basate sulla mia esperienza personale e osservazioni, non ho prove analitiche rigorose della loro efficacia e finora ho provato solo lo style training. Prevedo di esplorare presto il concept training per testare altre mie supposizioni e vedere se sono applicabili.

• Puoi addestrare Wan-14B su GPU consumer-level usando video. 368x192x45 sembra un buon punto di partenza.

• Compensa l’apprendimento dello stile mirato al movimento su video a bassa risoluzione usando immagini ad alta risoluzione per migliorare la generalizzazione.

• Combina vari metodi di estrazione frame sugli stessi dataset per massimizzare efficacia e uso hardware.

Molto, se non tutto, ciò che ho imparato per creare questo LoRA deriva dalla lettura instancabile di innumerevoli post su r/StableDiffusion, dal lurking 24/7 sull’ottimo Banodoco Discord, dal leggere commenti e aprire ogni clip NSFW di ogni modello WanVideo qui su Civitai, e dallo scavare in ogni issue che trovavo sui musubi-tuner, diffusion-pipe, Wan2.1, e altri repository. 😽

P.S.

Questo modello è una vetrina tecnologica delle capacità dei moderni sistemi di generazione video. Non è destinato a danneggiare o violare i diritti degli autori originali. Piuttosto, è un omaggio al lavoro straordinario degli artisti le cui creazioni hanno ispirato questo modello.