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

Ta LoRA jest prezentowana na OpenMuse, wyselekcjonowanej inicjatywie poświęconej otwartym LoRA wideo i twórczości, którą umożliwiają. Skupia się na modelach takich jak Wan2.1, LTX-Video i HunyuanVideo, OpenMuse promuje wysokiej jakości narzędzia i dzieła artystyczne z całego ekosystemu. Zakorzeniona w społeczności Banodoco, OpenMuse to rozwijający się dom dla otwartej, współpracującej sztuki AI, zaprojektowany by inspirować twórców, wzbudzać ciekawość i oferować coś, czym można się szczycić, nawet przed sceptykami sztuki generowanej przez AI.

Opis

Jestem bardzo szczęśliwy, mogąc podzielić się moją arcydziełem LoRA, nad którą pracowałem przez ostatni miesiąc, odkąd pojawił się Wan. To zdecydowanie najlepsza LoRA, jaką trenowałem na Civitai, i muszę powiedzieć (jeszcze raz) - WanVideo to niesamowity model.

LoRA była trenowana około 90 godzin na RTX 3090 z musubi-tuner korzystając z mieszanego zbioru 240 klipów i 120 obrazów. Mogło to być szybsze, ale byłem zafiksowany na przesuwaniu granic, by stworzyć model stylu na najwyższym poziomie. Ocenę, czy się udało, pozostawiam wam.

Użycie

Fraza wyzwalająca to Studio Ghibli style - wszystkie podpisy do danych treningowych zaczynały się od tych słów.

Wszystkie klipy publikowane w galerii są surowymi wynikami z wykorzystaniem LoRA na bazie modelu Wan-T2V-14B (choć najnowsze wideo mogą również zawierać self-forcing LoRA dla przyspieszenia inferencji, więcej poniżej), bez dalszej postprodukcji, skalowania czy interpolacji.

Kompatybilność z innymi LoRA oraz modelami Wan-I2V nie została przetestowana.

Workflowy są dołączone do każdego wideo (można je pobrać i przeciągnąć do ComfyUI, aby otworzyć). Przykładowo, tutaj jest JSON dla workflow (bazujący na wrapperze Kijai), który używa self-forcing LoRA (utworzonego przez blyss), wyodrębnionego z modelu Wan2.1-T2V-14B-StepDistill-CfgDistill lightx2v. Wybrałem wersję stworzoną przez blyss (a nie oryginalną LoRA Kijai), ponieważ z moich testów oferuje maksymalną kompatybilność i tylko przyspiesza inferencję, bez dodatkowego uszczegóławiania czy stylistycznych biasów. (To także powód, dla którego korzystam z bazowego modelu Wan i nie używam merge’ów jak AniWan lub FusionX.)

Używam LoRA przyspieszającej z samplerem UniPC (czasami DPM++). Z mojego doświadczenia UniPC lepiej sprawdza się w animacji 2D niż LCM, który skłania się bardziej ku realizmowi, którego chcę unikać. Zazwyczaj stosuję też węzeł NAG, by móc używać negatywnych promptów przy CFG=1. Wstępne testy pokazują, że w porównaniu do starszego workflow z TeaCache, oprócz ogromnego wzrostu prędkości (klip 640×480×81 z 6 krokami renderuje się w ~1 minutę zamiast 6 na RTX 3090), lekko poprawia też płynność ruchu i renderowanie tekstu.

Zaktualizowane LoRA lightx2v są również bardzo imponujące pod względem prędkości i zachowania jakości. Korzystam z LoRA rank 128, ale wersje 32 i 64 też dają świetne efekty. Oto przykład workflow w formacie JSON. Okazało się, że obniżenie siły LoRA lightx2v do 0.9, zwiększenie liczby kroków do 8 oraz użycie UniPC lub planera DPMPP daje bardzo dobre rezultaty.

A tutaj jest „stary” workflow w formacie JSON. Używany do generowania 90% filmów w galerii dla tej LoRA. Budowany na wrapperowych węzłach, zawiera wiele optymalizacji (więcej informacji tutaj), w tym fp8_e5m2 checkpointy + torch.compile, SageAttention 2, TeaCache, Enhance-A-Video, Fp16_fast, SLG i (czasami) Zero-Star (niektóre z tych elementów przeniesiono do nowego workflow), ale renderowanie klipu 640x480x81 nadal zajmowało około 5 minut (RTX 3090) w starszym workflow. Mimo że stary workflow wykazywał nieco wyższą jakość w niektórych obszarach (paleta, płynność), 5-krotne spowolnienie było istotną przeszkodą i głównym powodem migracji do wersji wspieranej przez lightx2v.

Promptowanie

Aby generować większość promptów, zazwyczaj stosuję następujący meta-prompt w ChatGPT (lub Claude, lub innym zdolnym LLM), który pomaga wzbogacić „surowe” opisy. Prompt bazuje na oficjalnym kodzie rozszerzania promptów od twórców Wan i wygląda tak:

Jesteś inżynierem promptów, specjalizującym się w przekształcaniu wejść użytkownika w wysokiej jakości prompt do generowania wideo w charakterystycznym stylu Studio Ghibli. Zapewniasz, że wynik odpowiada oryginalnemu zamysłowi, wzbogacając szczegóły dla jasności wizualnej i ruchowej.

Wymagania zadania:
- Jeśli wejście użytkownika jest zbyt krótkie, rozszerz je o rozsądne detale, tworząc bardziej żywą i kompletną scenę bez zmiany podstawowego znaczenia.
- Podkreśl kluczowe cechy takie jak wygląd postaci, wyrazy twarzy, ubrania, postawy i relacje przestrzenne.
- Zawsze utrzymuj estetykę wizualną Studio Ghibli – miękkie, akwarelowe tła, wyraziste lecz proste projekty postaci i ciepłą, nostalgiczną atmosferę.
- Wzmacniaj opisy ruchu i ruchów kamery dla naturalnego przepływu animacji. Uwzględnij delikatne, organiczne ruchy pasujące do stylu opowiadania Ghibli.
- Zachowaj oryginalny tekst w cytatach lub tytułach, zapewniając jednak, że prompt jest jasny, immersyjny i ma długość 80-100 słów.
- Wszystkie prompt zaczynają się od "Studio Ghibli style." Inne style sztuki nie są dozwolone.

Przykłady zmodyfikowanych promptów:
"Studio Ghibli style. Młoda dziewczyna z krótkimi brązowymi włosami i ciekawymi oczami stoi na oświetlonym słońcem pagórku trawy, wiatr delikatnie porusza jej prostą białą sukienkę. Obserwuje grupę ptaków szybujących po złotym niebie, bose stopy lekko zapadają się w miękką ziemię. Scena skąpana w ciepłym, nostalgicznym świetle, z bujnymi drzewami kołyszącymi się w oddali. Delikatna bryza niesie dźwięki natury. Ujęcie średnie, lekko z dołu, z powolnym, kinowym panoramowaniem uchwycającym spokojny ruch."
"Studio Ghibli style. Mała wioska o zachodzie słońca, latarnie miękko świecą pod okapami drewnianych domów. Młody chłopiec w niebieskim yukacie biegnie wąską kamienną ścieżką, jego sandały stukają o ziemię, goni ważkę. Jego podekscytowany wyraz twarzy odbija się w migoczącej rzece obok. Atmosfera bogata w ciepłe pomarańcze i chłodne błękity, budząca spokojny letni wieczór. Średnie ujęcie z płynnym ruchem podążającym za energicznymi krokami chłopca."
"Studio Ghibli style. Mistyczny las skąpany w porannej mgle, gdzie wysokie drzewa tworzą łuk nad ścieżką pokrytą mchem. Dziewczyna w prostym zielonym płaszczu delikatnie kładzie dłoń na grzbiecie ogromnego, łagodnego stworzenia przypominającego pradawnego jelenia. Jego futro lekko się mieni, gdy światło przebija się przez gęsty daszek, oświetlając unoszący się pyłek. Kamera powoli zbliża się, podkreślając ich ciche połączenie. Delikatny podmuch wiatru porusza liście, a małe świecące duchy zaglądają spod korzeni."

Instrukcje:
Teraz podam prompt do przepisania. Proszę rozwinąć i udoskonalić go po angielsku, upewniając się, że odpowiada estetyce Studio Ghibli. Nawet jeśli wejście to instrukcja, a nie opis, przeredaguj je na kompletny, wizualnie bogaty prompt, bez dodatkowych odpowiedzi czy cudzysłowów.

Prompt brzmi: "TU WSTAW SWÓJ PROMPT".

Zamień TU WSTAW SWÓJ PROMPT na coś w rodzaju Młoda blondynka stoi na górze przy plaży nad morzem pod deszczem lub cokolwiek innego.

Negatywny prompt zawsze zawiera ten sam bazowy tekst (choć mogą być dodane kolejne słowa w zależności od konkretnego promptu):

Kolorystyka jaskrawa, prześwietlenie, statyka, rozmyte detale, napisy, styl, dzieło, malowidło, obraz, nieruchomy, ogólne szarzenie, najgorsza jakość, niska jakość, artefakty kompresji JPEG, brzydki, uszkodzony, nadmiar palców, źle namalowane dłonie, źle namalowana twarz, zdeformowany, zniekształcony, zdeformowane kończyny, zlewanie palców, nieruchome ujęcie, chaotyczne tło, trzy nogi, tłum ludzi w tle, chodzenie tyłem, 3D, MMD, MikuMikuDance, SFM, Source Filmmaker, Blender, Unity, Unreal, CGI, zła jakość

Zbiór danych

W tej i kolejnych sekcjach trochę sobie gadaniny :) Śmiało pomiń i przeczytaj tylko Podsumowanie, ale może ktoś znajdzie tu przydatne informacje. Więc...

Wybór zestawu danych był „najłatwiejszą” częścią, mam już wszystkie filmy Ghibli w najwyższej możliwej jakości, podzielone na sceny – ponad 30 000 klipów w rozdzielczości 1920x1040 i wysokim bitrate. Cierpliwie czekają, aż w końcu zrobię pełne dostrojenie jakiegoś modelu wideo przy ich użyciu.

Przygotowałem już około 300 klipów do treningu v0.7 HV LoRA (właściwie miałem zacząć trening, gdy pojawił się Wan). Klipy miały od 65 do 129 klatek, co uważam za optymalne dla treningu HV na wideo, a wszystkie były 24 fps. Dla Wan chciałem jednak inny zakres klatek (nie przekraczający 81 klatek, wyjaśnienie w sekcji „Trening”). Potrzebowałem też 16 fps. Nadal nie jestem pewien, czy ścisłe 16 fps jest konieczne, ale miałem problemy z HV, gdy klipy były 30 fps zamiast natywnych 24, więc postanowiłem trzymać się 16 fps.

Warto wspomnieć, że do przetwarzania datasetu zwykle tworzę wiele małych „jednorazowych” skryptów (z pomocą Claude, ChatGPT i DeepSeek) – w tym mini-GUI do ręcznego wyboru wideo, jednowierszowe skrypty do dzielenia klatek, skrypty generujące różne statystyki pomocnicze, rozcinanie klipów na zakresy, tworzenie bucketów z wyprzedzeniem itd. Nie publikuję tych skryptów, bo są niechlujne, pełne na sztywno wpisanych wartości i przeznaczone tylko do jednorazowego użytku. Obecnie każdy może łatwo stworzyć podobne, robiąc zapytania do wymienionych LLM.

Konwersja wszystkich klipów do 16 fps zmniejszyła zakres klatek wideo z 65-129 do około 45-88, co zburzyło dokładnie zaplanowane, perfekcyjne zakresy bucketa klatek do treningu. Na szczęście nie był to problem, bo miałem zasady wyboru wideo do treningu, które uwzględniały takie sytuacje.

Po pierwsze, scena nie powinna mieć gwałtownych przejść w czasie trwania. Potrzebowałem tego, bo nie mogłem przewidzieć dokładnej długości (w klatkach) bucketów do treningu – rozmiar modelu, VRAM i inne czynniki na to wpływają. Przykład: mogę chcieć użyć klipu 81 klatek do treningu, ale nie da się tego zrobić, bo dostanę OOM na RTX 3090. Trzeba więc dobrać strategię ekstrakcji klatek, która może podzielić klip na kilka krótszych części (świetne omówienie różnych strategii). Może to naruszyć spójność semantyczną (np. w pierwszym fragmencie klipu dziewczyna otwiera usta, ale z wyciętego fragmentu nie wiadomo, czy zamierza płakać czy się śmiać), co może powodować, że WAN-owy encoder UMT5 będzie smutny.

Inną rzeczą było to, że chciałem ponownie używać podpisów do jakichkolwiek fragmentów oryginalnego klipu bez konieczności ponownego podpisywania i ponownego cache’owania embeddingów przez enkoder tekstowy. Opisywanie wideo zajmuje dużo czasu, ale jeśli scena mocno zmienia się w trakcie, oryginalne podpisy mogą się nie pasować do wszystkich fragmentów, obniżając jakość treningu. Przestrzegając zasad „klip nie powinien zawierać gwałtownych przejść kontekstu” i „klip powinien być samouwierzytelniający się, tzn. nie powinien zawierać zdarzeń, których nie da się zrozumieć z samego klipu”, nawet jeśli podzielimy scenę na podfragmenty, podpisy (z dopuszczalnym marginesem błędu) nadal będą do nich pasować.

Po konwersji przejrzałem wszystkie klipy i zmniejszyłem ich liczbę do 240 (usunąłem te zbyt dynamiczne lub zbyt statyczne), co tworzy pierwszą część zbioru danych.

Zdecydowałem się użyć mieszanego zbioru wideo i obrazów. Druga część to 120 obrazów (768x768), wyciętych ze screenów różnych filmów Ghibli.

Istnieje alternatywne podejście polegające na trenowaniu najpierw na obrazach, a potem na wideo (z powodzeniem zastosowane przez twórcę tej LoRA), ale osobiście uważam, że mieszanie w jednej partii jest lepsze (choć nie mam twardych danych na potwierdzenie). Potwierdzeniem moich założeń jest też świetna LoRA, która korzysta z tego samego podejścia mieszania (i nota bene też trenowana na GPU 24 GB, jeśli się nie mylę).

By efektywnie trenować LoRA na mieszanym zbiorze na sprzęcie konsumenckim, musiałem znaleźć odpowiednią równowagę między rozdzielczością, długością i czasem treningu, więc postanowiłem mieszać niską rozdzielczość długich wideo i wysoką rozdzielczość obrazów – więcej szczegółów w sekcji Trening.

Co do podpisów: obrazy w zbiorze danych zostały reuse’owane z moich zestawów HV i opisane wcześniej za pomocą mojego "szwajcarskiego scyzoryka" VLM do (tylko SFW) podpisywania datasetów, znanego jako Qwen2-VL-7B-Instruct. Użyłem następującego promptu do podpisywania:

Stwórz bardzo szczegółowy opis tej sceny. Nie używaj list numerowanych ani podziałów na linie. WAŻNE: opis MUSI ZAWSZE zaczynać się od niezmienionej frazy 'Studio Ghibli style. ', po której następuje szczegółowy opis. Opis powinien: 1) opisać główną zawartość sceny, 2) opisać środowisko i oświetlenie, 3) określić typ ujęcia (np. z lotu ptaka, zbliżenie, średnie, długie) oraz 4) uwzględnić atmosferę sceny (np. przytulną, napiętą, tajemniczą). Użyj szablonu: 'Studio Ghibli style. {Główna akcja/opis}. {Szczegóły środowiska i oświetlenia}. {Styl i specyfikacje techniczne}'.

Miałem wątpliwości, czy powinienem ponownie podpisać te obrazy, bo ich struktura podpisów została zaprojektowana specjalnie dla HunyuanVideo i obawiałem się, że Wan może potrzebować zupełnie innego podejścia. Zostawiłem je bez zmian i nie mam pojęcia, czy to była dobra decyzja, ale ogólnie nowoczesne enkodery tekstu są na tyle potężne, że ignorują takie ograniczenia. Wiadomo, że modele jak Flux i inne mogą być trenowane nawet bez podpisów (choć uważam, że zawsze lepiej z podpisami – jeśli są adekwatne).

Do podpisywania wideo testowałem kilka lokalnych modeli, które natywnie opisują zawartość wideo:

• CogVLM2-Video-Llama3-Chat (zwykle mój wybór do podpisywania klipów)

• MiniCPM-V 2.6

• Apollo-LMMs-Apollo-7B-t32

• LLaVA-Onevision

• VideoChat-Flash-2B

• VideoLLaMA 3

• Ovis2-16B (ten wydaje się naprawdę dobry! Ale zestaw danych miałem już podpisany, więc użyję go w przyszłych LoRA)

Są też inne modele, ale te testowałem. Do tej LoRA ostatecznie użyłem Apollo-7B. Użyłem prostego promptu VLM:

Stwórz bardzo szczegółowy opis tego wideo. WAŻNE: opis MUSI ZAWSZE zaczynać się od niezmienionej frazy 'Studio Ghibli style. ', po której następuje szczegółowy opis.

Dołączam pełny zestaw danych użyty do treningu jako załącznik do modelu. Choć zawiera pewne materiały chronione prawami autorskimi, uważam, że mieści się to w granicach dozwolonego użytku. Zestaw danych jest dostarczany wyłącznie dla potrzeb badań i edukacyjnej oceny możliwości modelu oraz zapewnienia przejrzystości procesu treningowego. Nie powinien być wykorzystywany do dystrybucji ani eksploatacji komercyjnej.

Trening

Jeśli kogoś interesuje, oto lista trenerów, które rozważałem do treningu WanVideo:

• diffusion-pipe – pierwowzór treningu HV, ale pozwala też na pamięciooszczędny trening Wan; skonfigurowany przez pliki, ma GUI od osób trzecich i szablony runpod (więcej tutaj i tutaj). Dla HV używałem go wyłącznie. Na Windows wymaga WSL.

• Musubi Tuner – rozwijany przez odpowiedzialnego i przyjaznego developera. Skonfigurowany przez pliki, przytulna społeczność, mnóstwo opcji. Obecnie mój wybór do treningu Wan.

• AI Toolkit – Mój ulubiony trener Flux ostatnio dodał wsparcie dla Wan. Szybki, łatwy w użyciu, konfiguracja plikowa, ma też UI oficjalne (którego nie używam 🤷), ale obecnie obsługuje tylko trening 14B bez podpisów, co jest głównym powodem, dla którego go nie używam.

• DiffSynth Studio – nie miałem jeszcze czasu testować, nie wiem czy działa z 24 GB VRAM przy treningu Wan. Mimo to jest rozwijany przez ModelScope, więc warto mu się przyjrzeć. Planuję testować.

• finetrainers – obsługuje trening Wan, ale chyba jeszcze nie działa na GPU 24 GB.

• SimpleTuner – dostał wsparcie Wan w zeszłym tygodniu, więc jeszcze nie próbowałem. Zasługuje na uwagę, bo główny developer jest bardzo zaangażowany i kompetentny.

• Zero-to-Wan – wspiera trening tylko modeli 1.3B.

• WanTraining – muszę wspomnieć, bo jest wspierany przez developera, który zrobił imponującą pracę, w tym guidance-distilled LoRA i control LoRA.

Wybrałem Musubi Tuner. Dla porządku, moje parametry sprzętowe: i5-12600KF, RTX 3090, Windows 11, 64Gb RAM. Komendy i pliki konfiguracyjne, których użyłem, wyglądały następująco.

• Do cache’owania VAE latents (nic specjalnego, domyślna komenda)

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

• Do cache’owania embeddingów enkodera tekstu (domyślnie):

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 

• Do uruchamiania treningu:

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

Znów, nic nadzwyczajnego. Musiałem użyć parametru blocks_to_swap, bo inaczej przy mojej konfiguracji danych (patrz poniżej) napotkałbym ograniczenia VRAM 24 GB. Hiperparametry pozostały w większości domyślne. Nie chciałem ryzykować po złych doświadczeniach - 60 godzin treningu HV straciłem wskutek zbytnich eksperymentów z wartościami flow shift i adaptacyjnymi optymalizatorami zamiast sprawdzonego adamw.

• Plik promptów do próbek podczas treningu:

# prompt 1
Studio Ghibli style. Kobieta z blond włosami chodzi po plaży, kamera oddala się.  --w 384 --h 384 --f 45 --d 7 --s 20

# prompt 2
Studio Ghibli style. Kobieta tańczy w barze. --w 384 --h 384 --f 45 --d 7 --s 20

• Konfiguracja zbioru danych (najważniejsza część; poniżej wyjaśnię moją logikę):

[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

Mój zestaw danych składa się z trzech części.

Zacznę od ostatniej, zawierającej główną tablicę danych – 240 klipów w rozdzielczości 1920x1040 i długości od 45 do 88 klatek.

Oczywiście trening na pełnej rozdzielczości 1920x1040 i pełnej długości na RTX 3090 nie wchodził w grę. Musiałem znaleźć minimalną rozdzielczość i czas trwania klatek, które unikną przepełnienia pamięci, zachowując jak najdłuższe fragmenty bucketów. Dłuższe fragmenty pomagają modelowi uczyć się ruchu, timingu i wzorców przestrzennych (np. trzepotanie włosów, kołysanie tkanin, dynamikę cieczy) w stylu Ghibli – czego nie da się osiągnąć na statycznych klatkach.

Z treningu HV pamiętałem, że dobrym punktem startu dla szacowania dostępnego zakresu rozdzielczości na 24 GB GPU jest 512x512x33. Wybrałem wzorzec ekstrakcji klatek „uniform”, gwarantujący, że wyciągane fragmenty mają co najmniej 45 klatek. Skoro po konwersji do 16 fps maksymalna długość to 88 klatek, to podejście zapobiega dzieleniu klipów na więcej niż dwa fragmenty, co wydłużałoby epoki. Jednocześnie 45 klatek (~3s) powinno wystarczyć, by model nauczył się przepływu przestrzennego stylu.

Przy celu 45 klatek testowałem różne rozdzielczości. Użyłem skryptu do analizowania wszystkich klipów w folderze i proponowania validnych szerokości i wysokości zachowujących oryginalny proporcje (1920/1040 ≈ 1,85) i podzielnych przez 16 (wymaganie modelu).

W końcu znalazłem, że użycie [384, 208] dla bucketu i ustawienie --blocks_to_swap 10 zapobiegło OOM i przeskakiwaniu do pamięci współdzielonej (co dawało 160 s/iterację). Minusem był spadek szybkości treningu do około 11-12 s/iterację. Z perspektywy czasu obniżenie rozdzielczości do [368, 192] mogłoby podnieść szybkość do ~8 s/iteracji, co byłoby świetne (blisko prędkości treningu Fluxa w 1024p w AI Toolkit). Zaoszczędziłby to około 20 godzin treningu na pełnym 90-godzinnym przebiegu (~28000 kroków), choć wtedy nie spodziewałem się przekroczyć 20K kroków.

Warto zauważyć, że trenowałem na Windows z monitorem podłączonym do GPU (i korzystałem z komputera do kodowania w tym samym czasie 😼). Na Linuxie (np. z diffusion-pipe) i korzystając z wewnętrznego GPU do wyświetlania, można użyć nieco wyższych rozdzielczości czasowo-przestrzennych bez OOM lub ograniczeń pamięci współdzielonej (co uważam za problem specyficzny dla Windows).

Teraz o pierwszej części (120 obrazów 768x768). Początkowo chciałem trenować na obrazach 1024p, ale uznałem to za przesadę i spowolnienie procesu. Planowałem trenować obrazy HD i niską rozdzielczość wideo równocześnie, by uzyskać lepszą generalizację. Idea była taka, że wysokorozdzielcze obrazy zrekompensują niską rozdzielczość klipów. Wspólne wstępne trenowanie wideo + obrazów to właśnie sposób trenowania WAN, więc ta metoda powinna sprzyjać też nauce stylu „upstream”.

Na koniec druga część, również ważna dla generalizacji (choć nie jest to podejście „naukowe”, wydaje się sensowne). Plan był taki, by ponownie użyć tych samych klipów z trzeciej części, ale trenować tylko na pierwszej klatce i pierwszych 21 klatkach. Dzięki temu chciałem ułatwić naukę ruchomych cech stylu czasowego. Jednocześnie pozwoliło to podnieść rozdzielczość dla drugiego segmentu do [768, 416].

W efekcie chciałem osiągnąć „cross-generalizację” pomiędzy:

• sekcją 1 – obrazami wysokiej rozdzielczości (768x768)

• sekcją 2 – pojedynczymi klatkami i 21-klatkowym klipami w średniej rozdzielczości (768x416)

• sekcją 3 – niskorozdzielczymi 45-klatkowymi klipami (384x208)

Dodatkowo zarówno druga, jak i większa część trzeciej dzieliły tę samą pierwszą klatkę, co powinno poprawić użyteczność LoRA w scenariuszach I2V. To wydawało się najlepszym sposobem na pełne wykorzystanie mojego zbioru danych bez problemów sprzętowych.

Oczywiście nie jestem pierwszym z tym pomysłem, ale wydaje się on logiczny i rozsądny. Mam nadzieję, że więcej twórców zauważy, że nie potrzebujesz A100 do trenowania wideo LoRA dla Wan.

Zabawna ciekawostka: spodziewałem się, że epoka będzie składać się z 1080 próbek: 120 obrazów (sekcja 1) + 240 pojedynczych klatek (sekcja 2, bucket "head"=1) + 240 klipów 21-klatkowych (sekcja 2, bucket "head"=21) + 480 klipów 45-klatkowych (sekcja 2, bucket "uniform"=45, próbkowanych 2 razy). Po rozpoczęciu treningu odkryłem, że to w rzeczywistości 1078 próbek. Po zagłębieniu się okazało się, że dwa klipy miały mniej niż 45 klatek według ffprobe z ffmpeg, skutkiem czego było zaokrąglenie. To nie był duży problem, więc kontynuowałem bez tych dwóch klipów, a to wyjaśniało nieoczekiwaną liczbę kroków dla ostatecznej LoRA :)

Sam trening przebiegał sprawnie. Nie pokazuję wykresów strat, bo jestem zbyt nieśmiały nie sądzę, by wiele mówiły. Przeważnie służą mi do sprawdzania, czy rozkład strat nie staje się zbyt podobny pomiędzy epokami – to sygnał potencjalnego przeuczenia.

Trenowałem do 28000 kroków, potem kilka dni wybierałem najlepszy checkpoint. Myślę też, że mógłbym robić checkpointy nie tylko na koniec epoki, ale też w trakcie, bo możliwe, że lepszy punkt mógł się gdzieś zgubić.

Myślę o włączeniu oceny strat walidacyjnych do mojego procesu treningowego (więcej tutaj), ale na razie jeszcze tego nie zrobiłem.

Czy można to uprościć? Pewnie tak. W następnej LoRA sprawdzę, czy dodatkowy zbiór obrazów z sekcji 1 nie był zbędny. Mogłem po prostu ustawić osobną sekcję datasetu i reuse’ować pierwszą klatkę klipów, ale w wysokiej rozdzielczości. Z drugiej strony chciałem, by zbiór był maksymalnie zróżnicowany, więc screenshoty pochodziły z innych scen niż klipy, więc nie były redundantne.

Nawet nie jestem pewien, czy sekcja 2 była potrzebna. WAN sam raport techniczny był wstępnie trenowany na klipach 192px, więc trening na około 352x192x45 powinien być efektywny i wykorzystać sprzęt jak najlepiej. Idealnie byłoby używać 5-sekundowych klipów (16 fps × 5 s + 1 = 81 klatek), ale na RTX 3090 bez agresywnego block swappingu to nierealne.

Podsumowanie

Poza zabawą i setkami tysiącami niesamowitych klipów, oto kilka spostrzeżeń z treningu tej LoRA. Praktyki oparte są na moim osobistym doświadczeniu i obserwacjach, nie mam twardych dowodów analitycznych na ich skuteczność. Dotąd trenowałem tylko style, niedługo planuję wypróbować trening konceptualny, by zweryfikować inne założenia.

• Można trenować Wan-14B na sprzęcie konsumenckim używając wideo. 368x192x45 to solidny punkt startowy.

• Kompensuj naukę ruchu stylu niskorozdzielczymi wideo, stosując wysokorozdzielcze obrazy dla lepszej generalizacji.

• Łącz różne metody ekstrakcji klatek w tym samym zbiorze danych, by zmaksymalizować efektywność i wykorzystanie sprzętu.

Wiele, jeśli nie wszystko, czego się nauczyłem do tej LoRA pochodzi z czytania niezliczonych postów na r/StableDiffusion, całodobowego czatowania na wspaniałym Banodoco Discord, czytania komentarzy i odtwarzania każdego NSFW klipu do każdego modelu WanVideo na Civitai oraz zagłębiania się w zgłoszenia na musubi-tuner, diffusion-pipe, Wan2.1 i innych repozytoriach. 😽

P.S.

Ten model to technologiczna prezentacja możliwości nowoczesnych systemów generowania wideo. Nie ma na celu szkodzić ani naruszać praw oryginalnych twórców. Pełni rolę hołdu dla wyjątkowej twórczości artystów, które zainspirowały ten model.