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

Dieses LoRA ist aufgezählt auf OpenMuse, einer kuratierten Initiative, die sich offenen Video-LoRAs und den kreativen Werken widmet, die sie ermöglichen. Fokus auf Modelle wie Wan2.1, LTX-Video und HunyuanVideo, OpenMuse hebt hochwertige Tools und Kunstwerke aus dem gesamten Ökosystem hervor. Verankert in der Banodoco-Community, ist OpenMuse ein wachsendes Zuhause für offene, kollaborative KI-Kunst, die dazu inspiriert, Schöpfer motiviert, Neugier weckt und etwas bietet, das man stolz teilen kann, selbst mit Skeptikern KI-generierter Kunst.

Beschreibung

Ich freue mich sehr, mein magnum opus LoRA zu teilen, an dem ich seit einem Monat arbeite, seit Wan veröffentlicht wurde. Dies ist tatsächlich das beste LoRA, das ich je trainiert habe (auf Civitai), und ich muss noch einmal sagen - WanVideo ist ein erstaunliches Modell.

Das LoRA wurde etwa 90 Stunden auf einer RTX 3090 mit musubi-tuner mit einem gemischten Datensatz von 240 Clips und 120 Bildern trainiert. Es hätte schneller gehen können, aber ich war besessen davon, die Grenzen auszutesten, um ein State-of-the-Art Stilmodell zu schaffen. Es liegt an euch zu beurteilen, ob ich erfolgreich war.

Anwendung

Der Trigger-Satz ist Studio Ghibli Stil – alle Trainingsbeschriftungen wurden mit diesen Worten eingeleitet.

Alle Clips, die ich in der Galerie veröffentliche, sind rohe Ausgaben mit einem LoRA, das auf einem Basis-Wan-T2V-14B-Modell basiert (obwohl die neuesten Videos auch Self-Forcing LoRA für Beschleunigung beim Inferenzprozess enthalten können, siehe unten), ohne weitere Nachbearbeitung, Upscaling oder Interpolation.

Die Kompatibilität mit anderen LoRAs und mit Wan-I2V-Modellen wurde nicht getestet.

Workflows sind mit jedem Video eingebettet (sie können einfach heruntergeladen und in ComfyUI gezogen werden, um sie zu öffnen). Zum Beispiel, hier ist JSON für den Workflow (basierend auf Kijais Wrapper), der das Self-Forcing LoRA (erstellt von blyss) nutzt, extrahiert aus lightx2v's Wan2.1-T2V-14B-StepDistill-CfgDistill Modell. Ich habe die von blyss erstellte Version gewählt (und nicht das originale LoRA von Kijai), da sie nach meinen Tests maximale Kompatibilität bietet und lediglich die Inferenz beschleunigt, ohne zusätzliche Details oder stilistische Verzerrungen. (Das ist auch der Grund, warum ich beim Basis-Wan-Modell bleibe und keine Merges wie AniWan oder FusionX nutze.)

Ich benutze das Beschleunigungs-LoRA mit dem UniPC-Sampler (und gelegentlich DPM++). Meiner Erfahrung nach performt UniPC besser für 2D-Animationen als LCM, das tendenziell mehr auf Realismus ausgelegt ist, was ich vermeiden möchte. Normalerweise setze ich auch den NAG-Knoten ein, um negative Prompts bei CFG=1 verwenden zu können. Erste Tests zeigen, dass dieser Workflow im Vergleich zum älteren mit TeaCache neben der enormen Geschwindigkeitssteigerung (ein 640×480×81 6-Schritt-Clip rendert in ~1 Minute statt 6 auf einer RTX 3090) auch die Bewegungsflüssigkeit und Textrendering leicht verbessert.

Die aktualisierten lightx2v LoRAs sind ebenfalls sehr beeindruckend hinsichtlich Geschwindigkeit und Qualitätserhalt. Ich benutze ein LoRA mit Rang 128, aber auch die 32er und 64er Versionen liefern großartige Ergebnisse. Hier ein Beispiel des Workflows im JSON-Format. Ich habe festgestellt, dass das Absenken der lightx2v-LoRA-Stärke auf 0,9, Erhöhen der Schritte auf 8 und Verwendung von UniPC oder DPMPP Scheduler gute Ergebnisse bringt.

Und hier ist der "Legacy"-Workflow in JSON-Format. Er wurde für ca. 90% der Videos in der Galerie dieses LoRAs verwendet. Er basiert auf Wrapper-Knoten und beinhaltet viele Optimierungen (mehr Infos hier), inklusive fp8_e5m2 Checkpoints + torch.compile, SageAttention 2, TeaCache, Enhance-A-Video, Fp16_fast, SLG und (manchmal) Zero-Star (einige davon wurden auch in den neuen Workflow migriert), aber das Rendern eines 640x480x81 Clips dauerte im alten Workflow noch etwa 5 Minuten (RTX 3090). Obwohl der Legacy-Workflow in einigen Bereichen (Palette, Glätte) leicht bessere Qualität zeigt, ist der Faktor 5x langsamere Geschwindigkeit ein entscheidender Nachteil, weshalb ich zur lightx2v-betriebenen Version gewechselt bin.

Prompting

Für die meisten Prompts verwende ich üblicherweise folgende Meta-Prompt in ChatGPT (oder Claude, oder einem anderen fähigen LLM), die hilft, "rohe" Beschreibungen zu verbessern. Diese Prompt basiert auf offiziellem Prompt-Erweiterungscode der Wan-Entwickler und sieht so aus:

Du bist ein Prompt-Ingenieur, spezialisiert auf die Verfeinerung von Benutzereingaben zu hochwertigen Prompts zur Videogenerierung im charakteristischen Studio Ghibli Stil. Du stellst sicher, dass das Ergebnis mit der ursprünglichen Intention übereinstimmt, während Details für visuelle und Bewegungs-Klarheit bereichert werden.

Aufgabenanforderungen:
- Wenn die Benutzereingabe zu kurz ist, erweitere sie mit sinnvollen Details, um eine lebendigere und vollständige Szene zu schaffen, ohne die Kernbedeutung zu ändern.
- Betone Schlüsselfunktionen wie Aussehen der Charaktere, Gesichtsausdrücke, Kleidung, Haltungen und räumliche Beziehungen.
- Bewahre stets die visuelle Ästhetik von Studio Ghibli - sanfte, aquarellartige Hintergründe, ausdrucksstarke aber einfache Charakterdesigns und eine warme, nostalgische Atmosphäre.
- Verbessere Beschreibungen von Bewegungen und Kamerafahrten für natürlichen Animationsfluss. Einschließlich sanfter, organischer Bewegungen, die zum Ghibli-Erzählstil passen.
- Bewahre Originaltexte in Anführungszeichen oder Titeln, während der Prompt klar, immersiv und 80-100 Wörter lang bleibt.
- Alle Prompts müssen mit "Studio Ghibli Stil." beginnen. Keine anderen Kunststile dürfen verwendet werden.

Beispiel für überarbeitete Prompts:
"Studio Ghibli Stil. Ein junges Mädchen mit kurzem braunem Haar und neugierigen Augen steht auf einem sonnenbeschienenen grasbewachsenen Hügel, der Wind bewegt sanft ihr einfaches weißes Kleid. Sie beobachtet eine Vogelschar, die über den goldenen Himmel zieht, ihre nackten Füße sinken leicht in die weiche Erde. Die Szene ist in warmes, nostalgisches Licht getaucht, mit üppigen Bäumen im Hintergrund. Ein sanfter Wind trägt die Geräusche der Natur. Halbnahe, leicht niedriger Winkel, langsame Kinokamerafahrt, die die ruhige Bewegung einfängt."
"Studio Ghibli Stil. Ein kleines Dorf bei Sonnenuntergang, Laternen leuchten sanft unter den Dachvorsprüngen hölzerner Häuser. Ein junger Junge in blauer Yukata rennt einen schmalen Steinweg entlang, seine Sandalen klopfen auf den Boden, während er einem Glühwürmchen nachjagt. Sein aufgeregter Gesichtsausdruck spiegelt sich im schimmernden Fluss neben ihm. Die Atmosphäre ist reich an warmen Orange- und kühlen Blautönen und ruft einen friedlichen Sommerabend hervor. Halbnahe mit sanfter Kamerafahrt, die die lebhaften Schritte des Jungen verfolgt."
"Studio Ghibli Stil. Ein mystischer Wald, getaucht in Morgendunst, wo hoch aufragende Bäume über einen moosbedeckten Pfad ragen. Ein Mädchen in einem einfachen grünen Umhang legt sanft ihre Hand auf den Rücken einer mächtigen, sanftäugigen Kreatur, die einem uralten Hirsch ähnelt. Sein Fell schimmert schwach, während Sonnenlicht durch das dichte Blätterdach fällt und Pollen beleuchtet. Die Kamera zoomt langsam heran und betont ihre stille Verbindung. Eine sanfte Brise bewegt die Blätter, und winzige leuchtende Geister scheinen hinter den Wurzeln hervor.

Ersetze DEIN PROMPT HIER mit etwas wie Junges blondes Mädchen steht auf einem Berg am Meeresstrand im Regen oder irgendetwas Ähnlichem.

Der negative Prompt enthält immer denselben Basistext (kann je nach Prompt um weitere Worte ergänzt werden):

Farblich zu grell, Überbelichtung, statisch, unscharfe Details, Untertitel, Stil, Werk, Gemälde, Bild, unbeweglich, insgesamt grau, schlechteste Qualität, niedrige Qualität, JPEG-Kompressionsartefakte, hässlich, beschädigt, überzählige Finger, schlecht gezeichnete Hände, schlecht gezeichnetes Gesicht, deformiert, entstellt, missgebildete Gliedmaßen, Finger verschmolzen, unbewegtes Bild, unordentlicher Hintergrund, drei Beine, viele Personen im Hintergrund, rückwärts laufend, 3D, MMD, MikuMikuDance, SFM, Source Filmmaker, Blender, Unity, Unreal, CGI, schlechte Qualität

Datensatz

In diesem und den folgenden Abschnitten werde ich etwas plaudern :) Du kannst gerne direkt zum Fazit springen, vielleicht findet aber doch jemand nützliche Infos in dieser Textwand. Also...

Die Auswahl des Datensatzes war der "einfachste" Teil, ich habe alle Ghibli-Filme in höchster Qualität und in Szenen zerteilt – über 30.000 Clips in 1920x1040 Auflösung und hoher Bitrate. Sie warten geduldig auf den Tag, an dem ich sie für ein vollständiges Feintuning eines Videomodells verwenden werde.

Ich hatte bereits etwa 300 Clips für das Training von v0.7 des HV LoRA vorbereitet (tatsächlich wollte ich gerade mit dem Training beginnen, als Wan erschien). Diese Clips lagen im Bereich von 65-129 Frames, was ich für optimal für HV Video-Training halte, und sie liefen mit 24 fps. Für Wan wollte ich jedoch einen anderen Frame-Bereich (maximal 81 Frames, siehe spätere Erklärung im Abschnitt "Training") und eine Bildfrequenz von 16 fps. Ich bin mir immer noch nicht ganz sicher, ob strikt 16 fps notwendig sind, aber ich hatte Probleme mit HV, wenn Clips 30 fps statt HVs native 24 fps hatten, daher entschied ich mich für 16 fps.

Ich sollte erwähnen, dass ich für die Datenverarbeitung meist viele kleine "One-Time"-Skripte nutze (mit Hilfe von Claude, ChatGPT und DeepSeek) – inklusive Mini-GUIs für manuelle Videoselektion, Einzeiler zum Frame-Splitting, Skripte für verschiedene Hilfsstatistiken, Clip-Dekomposition nach Bereichen, Erstellen von Buckets im Voraus usw. Ich veröffentliche diese Skripte nicht, sie sind unordentlich, voll mit fest codierten Werten und für die einmalige Nutzung konzipiert. Heute kann jeder einfach ähnliche Skripte durch Anfragen an die erwähnten LLMs erzeugen.

Die Konvertierung aller Clips auf 16 fps verringerte den Frame-Bereich von 65-129 auf etwa 45-88 Frames, was meine sorgfältig geplanten, frame-genauen Bereiche für die Frame-Buckets des Trainings durcheinanderbrachte. Zum Glück war das kein großes Problem, da ich einige Regeln für die Videoselektion hatte, um solche Situationen zu handhaben.

Zunächst sollte die Szene keine schnellen Übergänge während ihrer Dauer enthalten. Das war notwendig, weil ich die exakte Dauer (in Frames) für die Ziel-Frame-Buckets, die der Trainer für das Training festlegt, nicht vorhersagen konnte - Modellgröße, VRAM und andere Faktoren spielen da mit rein. Beispiel: Ich könnte einen einzelnen 81-Frames langen Clip fürs Training verwenden wollen, das ist aber auf einer RTX 3090 wegen OOM nicht möglich. Man muss also eine Frame-Extraktions-Strategie wählen, bei der Clips ggf. in mehrere kürzere Teile gesplittet werden (hier eine gute Aufschlüsselung verschiedener Strategien). Dabei kann die semantische Kohärenz gebrochen werden (z.B. öffnet ein Mädchen im ersten Clipfragment den Mund, aber durch das Zuschneiden wird unklar, ob sie weinen oder lachen will), und solche Kontextinkohärenz kann das UMT5-Encoder von Wan traurig machen.

Ein weiterer Punkt ist, dass ich Bildunterschriften für jeden Clip-Fragment wiederverwenden wollte, ohne sie neu zu beschriften oder Embeddings neu im Text-Encoder zu speichern. Das Beschriften von Videos dauert recht lange, und wenn sich eine Szene stark ändert, passt die Original-Beschriftung nicht zu allen Fragmenten – was die Trainingsqualität mindert. Indem ich die Regeln "Clip sollte keine schnellen Kontextwechsel enthalten" und "Clip sollte in sich geschlossen sein, d.h. Ereignisse nicht enthalten, die außerhalb des Clips nicht verstanden werden" befolgte, konnten die Beschriftungen (mit akzeptablem Fehler) für alle Fragmente gelten.

Nach der Konvertierung habe ich alle Clips durchgesehen und die Gesamtanzahl auf 240 reduziert (einige Clips mit zu vielen Wechseln oder zu statische entfernt), das war der erste Teil des Datensatzes.

Ich entschied mich für einen gemischten Datensatz aus Videos und Bildern. Der zweite Teil bestand aus 120 Bildern (768x768 Auflösung), aufgenommen als Screenshots aus verschiedenen Ghibli-Filmen.

Es gibt einen alternativen Ansatz, bei dem man zuerst auf Bildern trainiert und dann auf Videos feinjustiert (erfolgreich angewandt vom Ersteller dieses LoRAs), aber ich denke persönlich, dass Mischen in einem Batch besser ist (auch wenn ich keine Zahlen habe). Als Beleg hier ein sehr gutes LoRA, das denselben Mischansatz nutzt (und übrigens ebenfalls auf einer 24 GB GPU trainiert wurde, wenn ich mich nicht irre).

Um effizientes Video-Training auf gemischten Datensätzen mit Consumer-GPUs zu ermöglichen, musste ich ein Gleichgewicht zwischen Auflösung, Dauer und Trainingszeit finden. Ich entschied mich, Hochdauer-Videos in niedriger Auflösung mit hochauflösenden Bildern zu mischen – mehr Details dazu im Abschnitt Training.

Bezüglich der Bildbeschriftung: Bilder im Datensatz wurden aus meinen HV-Datensätzen wiederverwendet und zuvor mit meinem "Schweizer Taschenmesser" VLM für (nur SFW) Datensatzbeschriftung versehen, bekannt als Qwen2-VL-7B-Instruct. Die Prompt dafür war:

Erstelle eine sehr detaillierte Beschreibung dieser Szene. Verwende keine nummerierten Listen oder Zeilenumbrüche. WICHTIG: Die Ausgabe muss IMMER mit dem unveränderten Satz 'Studio Ghibli Stil. ' beginnen, gefolgt von deiner detaillierten Beschreibung. Die Beschreibung soll 1) den Hauptinhalt der Szene beschreiben, 2) die Umgebung und Beleuchtungsdetails, 3) die Art der Aufnahme (z.B. Luftaufnahme, Nahaufnahme, Halbnahe, Totale) und 4) die Atmosphäre der Szene (z.B. gemütlich, angespannt, geheimnisvoll) einschließen. Vorlage: 'Studio Ghibli Stil. {Hauptmotiv Aktion/Beschreibung}. {Umgebung und Beleuchtungsdetails}. {Stil- und technische Spezifikationen}'.

Ich hatte Zweifel, ob ich sie neu beschriften sollte, da die Zielstruktur speziell für HunyuanVideo entworfen wurde und ich befürchtete, Wan könnte einen anderen Ansatz brauchen. Ich habe sie so belassen und weiß nicht, ob das richtig war, aber moderne Text-Encoder sind in der Regel mächtig genug, solche Einschränkungen zu ignorieren. Modelle wie Flux und einige andere können sogar ganz ohne Beschriftungen trainiert werden (ich glaube aber, dass Training mit Beschriftungen besser ist – solange sie relevant sind).

Für Videobeschriftungen testete ich einige lokale Modelle, die nativen Video-Content beschriften können:

• CogVLM2-Video-Llama3-Chat (meist meine erste Wahl für Clip-Beschriftungen)

• MiniCPM-V 2.6

• Apollo-LMMs-Apollo-7B-t32

• LLaVA-Onevision

• VideoChat-Flash-2B

• VideoLLaMA 3

• Ovis2-16B (dieses scheint wirklich gut zu sein! Aber ich hatte den Datensatz schon beschriftet, als ich es fand, werde es für zukünftige LoRAs nutzen)

Es gibt noch weitere Modelle, aber das sind die, die ich getestet habe. Für dieses LoRA nutzte ich Apollo-7B. Meine VLM-Prompt war:

Erstelle eine sehr detaillierte Beschreibung dieses Videos. WICHTIG: Die Ausgabe MUSS IMMER mit dem unveränderten Satz 'Studio Ghibli Stil. ' beginnen, gefolgt von deiner detaillierten Beschreibung.

Ich füge den vollständigen Datensatz, den ich verwendet habe, dem Modell als Anhang bei. Zwar enthält er urheberrechtlich geschütztes Material, aber ich denke, das fällt unter Fair Use. Dieser Datensatz dient ausschließlich Forschungs- und Bildungszwecken zur Bewertung der Modellfähigkeiten und bietet Transparenz zum Trainingsprozess. Er darf nicht zur Weiterverbreitung oder kommerziellen Nutzung genutzt werden.

Training

Für alle Interessierten hier eine Liste von Trainern, die ich für WanVideo in Erwägung gezogen habe:

• diffusion-pipe - das OG des HV Trainings, ermöglicht aber auch speichereffizientes Wan-Training; konfigurationsgetrieben, hat Drittanbieter-GUI und Runpod-Vorlagen (mehr dazu hier und hier). Für HV habe ich es exklusiv genutzt. Für Windows ist WSL nötig.

• Musubi Tuner - Wird von einem verantwortungsbewussten und freundlichen Entwickler gepflegt. Konfigurationsgetrieben, gemütliche Community, viele Optionen. Aktuell meine Wahl für Wan-Training.

• AI Toolkit - Mein Lieblings-Trainer für Flux erhielt kürzlich Unterstützung für Wan. Schnell, benutzerfreundlich, konfigurationsgetrieben, auch mit hauseigener UI (die ich nicht nutze 🤷), unterstützt derzeit aber nur das Training von 14B ohne Beschriftungen, weswegen ich es nicht nutze.

• DiffSynth Studio - Hatte noch keine Zeit es zu testen und bin unsicher, ob es Wan-Modelle mit 24 GB VRAM trainieren kann. Wird aber von ModelScope gepflegt, also einen genaueren Blick wert. Ich plane bald zu testen.

• finetrainers - Unterstützt Wan Training, scheint jedoch mit 24 GB GPUs (noch) nicht zu funktionieren.

• SimpleTuner - Bekam letzte Woche Wan-Unterstützung, hatte noch keine Gelegenheit zu testen. Verdient Aufmerksamkeit, da der Hauptentwickler sehr engagiert und kompetent ist.

• Zero-to-Wan - Unterstützt Training nur für 1.3B Modelle.

• WanTraining - Muss dieses Projekt erwähnen, unterstützt von einem Entwickler, der beeindruckende Arbeit geleistet hat, inklusive Guidance-Distilled LoRA und Control LoRA.

Ich entschied mich für Musubi Tuner. Als Referenz hier meine Hardware-Parameter: i5-12600KF, RTX 3090, Windows 11, 64GB RAM. Die Befehle und Konfigurationsdateien, die ich nutzte, waren folgende.

• Für Caching von VAE Latents (nichts Besonderes, Standard-Befehl)

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

• Für Caching der Text-Encoder-Embeddings (Standard):

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 

• Zum Starten des Trainings:

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

Noch einmal, es gibt nichts Besonderes zu sehen. Ich musste den Parameter blocks_to_swap benutzen, weil ich sonst wegen meines Dataset-Configs (siehe unten) auf 24 GB VRAM-Limits gestoßen wäre. Die Hyperparameter ließ ich meist auf Standardwerten. Ich wollte nach einer schlechten Erfahrung kein Risiko eingehen – 60 Stunden HV-Training sind verloren gegangen, weil ich zu ehrgeizig mit Flow-Shift-Werten und adaptiven Optimierern statt dem klassischen adamw war.

• Prompt-Datei für die Sampling während des Trainings:

# prompt 1
Studio Ghibli Stil. Frau mit blonden Haaren läuft am Strand, Kamera zoomt heraus.  --w 384 --h 384 --f 45 --d 7 --s 20

# prompt 2
Studio Ghibli Stil. Frau tanzt in einer Bar. --w 384 --h 384 --f 45 --d 7 --s 20

• Datensatz-Konfiguration (der wichtigste Teil; ich erkläre die Gedanken dahinter weiter unten):

[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

Mein Datensatz-Setup besteht aus drei Teilen.

Ich beginne mit dem letzten, der das Hauptdatenfeld enthält - 240 Clips in 1920x1040 Auflösung und einer Dauer zwischen 45 und 88 Frames.

Natürlich war das Training auf Clips in voller Auflösung 1920x1040 und voller Dauer auf einer RTX 3090 nicht möglich. Ich musste eine minimale Auflösung und Frame-Dauer finden, um OOM-Fehler zu vermeiden und dennoch möglichst lange Bucket-Fragmente zu haben. Längere Fragmente helfen dem Modell, Bewegungen, Timing und räumliche Muster zu lernen (z.B. Haarzucken, Stoffbewegung, Flüssigkeitsdynamik etc.) im Ghibli-Stil – etwas, das man mit Einzelbildern nicht erreichen kann.

Vom HV-Training kannte ich einen guten Ausgangspunkt für verfügbare Auflösung bei 24 GB GPU: 512x512x33. Ich entschied mich für das "uniform" Frame-Extraktionsmuster, um sicherzustellen, dass alle extrahierten Fragmente mindestens 45 Frames haben. Da nach Umrechnung auf 16 fps die maximale Framedauer bei 88 Frames lag, sorgte das dafür, dass Clips nicht in mehr als zwei Abschnitte aufgeteilt werden, was Epochen zu lang machen würde. Gleichzeitig sollten 45 Frames (~3s) ausreichen, damit das Modell den räumlichen Fluss des Stils lernt.

Mit Ziel auf 45 Frames testete ich verschiedene Auflösungen. Ein Skript analysierte alle Clips im Ordner und schlug gültige Breite-Höhe-Kombinationen vor, die das Seitenverhältnis (1920/1040 ≈ 1,85) einhielten und durch 16 teilbar waren (ein Modell-Requirement).

Schließlich stellte ich fest, dass die Verwendung von [384, 208] für die Bucket-Größe und das Setzen von --blocks_to_swap 10 OOM-Fehler verhinderte und Shared Memory vermied (das sonst zu 160 s/it geführt hätte). Nachteil war, dass sich das Trainingstempo auf ca. 11-12 s/it verlangsamte. Rückblickend hätte das Senken der Auflösung auf [368, 192] die Geschwindigkeit auf ca. 8 s/it steigern können, was gut gewesen wäre (vergleichbar mit dem, was ich beim Flux-Training mit 1024p im AI Toolkit erhalte). Das hätte mir ca. 20 Stunden Training in den vollen 90 Stunden (~28000 Schritte) gespart, auch wenn ich damals nicht erwartet hatte, dass ich > 20K Schritte erreichen würde.

Zu beachten ist, dass ich auf Windows trainierte, mit meinem Monitor an der GPU (und gleichzeitig am PC zum Programmieren 😼). Unter Linux (z.B. mit diffusion-pipe) und internem GPU-Ausgang für Monitor könnte man womöglich höhere spatio-temporale Auflösungen nutzen, ohne OOM- oder Shared-Memory-Limits zu erreichen (denke, das ist Windows-spezifisch).

Nun zum ersten Teil (120 Bilder à 768x768 Auflösung). Ursprünglich wollte ich mit 1024p Bildern trainieren, entschied dann aber, dass das Overkill wäre und das Tempo ausbremst. Mein Plan war, HD-Bilder und niedrigauflösende Videos gleichzeitig zu trainieren, um bessere Generalisierung sicherzustellen. Die Idee: Hochauflösende Bilder kompensieren die niedrigere Auflösung der Clips. Und genau so wurde WAN ohnehin trainiert, also erwartete ich, dass dieser Ansatz auch den "Upstream"-Stil fördert.

Zuletzt der zweite Teil, wichtig für allgemeine Verallgemeinerung (keine "wissenschaftliche" Annahme, aber vernünftig). Die Idee war, dieselben Clips aus dem dritten Abschnitt erneut zu nutzen, aber nur für den ersten Frame und die ersten 21 Frames zu trainieren. So wollte ich lernen, zeitliche Stil-Bewegungsmerkmale zu fördern. Gleichzeitig konnte ich für den zweiten Abschnitt die Auflösung auf [768, 416] erhöhen.

Das Ziel war "Cross-Generalization" zwischen:

• Abschnitt 1: hochauflösende Bilder (768x768)

• Abschnitt 2: mittelauflösende Einzelframes und 21-Frames-Clips (768x416)

• Abschnitt 3: niedrigauflösende 45-Frames-Clips (384x208)

Außerdem teilen sich der zweite und der größere Teil des dritten Abschnitts denselben Startframe, was ich für vorteilhaft bei LoRA-Nutzung in I2V-Szenarien hielt. Das erschien mir als der beste Weg, den Datensatz optimal zu nutzen, ohne Hardware-Limits zu überschreiten.

Natürlich bin ich nicht der Erste, der diesen Ansatz verfolgt, aber er erscheint logisch und vernünftig. Hoffentlich erkennen mehr Entwickler, dass man keine A100 braucht, um ein video-basiertes LoRA für Wan zu trainieren.

Lustige Tatsache: Ich erwartete, dass eine Epoche aus 1080 Samples besteht: 120 Bilder (1. Datensatzabschnitt) + 240 einzelne Frames (2. Abschnitt, "head" Frame-Bucket=1) + 240 Clips mit je 21 Frames (2. Abschnitt, "head" Frame-Bucket=21) + 480 Clips mit je 45 Frames (2. Abschnitt, "uniform" Frame-Bucket=45, zweifach sampelt). Tatsächlich entdeckte ich während des Trainings 1078 Samples. Beim Nachforschen fand ich, dass zwei Clips kürzer als 45 Frames waren, was auf Rundungsprobleme zurückgeht. Da es kein großes Problem war, setzte ich das Training ohne diese zwei Clips fort, was die scheinbar seltsame Step-Anzahl für das finale LoRA erklärt :)

Das Training verlief reibungslos. Ich zeige keine Loss-Grafiken, da ich zu schüchtern bin glaube, dass sie wenig aussagen. Ich nutze sie vor allem, um zu prüfen, ob die Loss-Verteilung epochal zu ähnlich wird – was ein Hinweis auf Overfitting ist.

Ich trainierte bis ~28000 Steps und verbrachte mehrere Tage mit der Auswahl des besten Checkpoints. Eine weitere Sache, die ich hätte besser machen können, war Checkpoints nicht nur am Ende jeder Epoche zu speichern, sondern auch zwischendrin. Da jede Epoche 1078 Schritte lang ist, könnte ein besserer Checkpoint dazwischen verloren gegangen sein.

Ich ziehe in Betracht, Validierungs-Loss-Schätzungen in die Trainings-Pipeline einzubauen (mehr dazu hier), habe das aber noch nicht umgesetzt.

Kann das vereinfacht werden? Wahrscheinlich ja. In meinem nächsten LoRA werde ich testen, ob der zusätzliche Bilddatensatz im Abschnitt 1 redundant war. Ich hätte einfach einen separaten Datensatzabschnitt für die ersten Frames der Clips mit hoher Auflösung anlegen können. Andererseits wollte ich möglichst vielfältigen Datensatz, deshalb nutzte ich Screenshots von anderen Szenen als die Clips, sodass sie nicht redundant waren.

Ich bin mir nicht einmal sicher, ob der zweite Abschnitt nötig war. WAN selbst (laut technischem Bericht) wurde auf 192px Clips vortrainiert, Training bei ca. 352x192x45 sollte effektiv sein und die Hardware optimal nutzen. Idealerweise würde ich 5-Sekunden-Clips verwenden (16 fps * 5s + 1 = 81 Frames), aber das ist auf der RTX 3090 ohne aggressives Blockswapping nicht machbar.

Fazit

Abgesehen vom Spaß und den hunderten tausenden Wahnsinns-Clips, habe ich beim Training dieses LoRA einige Erkenntnisse gewonnen. Diese Methoden basieren auf meiner persönlichen Erfahrung; ich habe keine streng analytischen Belege für deren Wirksamkeit und habe bislang nur Stil-Training ausprobiert. Ich plane bald, Konzept-Training zu erforschen, um einige meiner Annahmen zu überprüfen und zu sehen, ob sie auch dort anwendbar sind.

• Man kann Wan-14B auf Consumer-GPUs mit Videos trainieren. 368x192x45 scheint ein solider Startpunkt zu sein.

• Kompensiere stilbezogenes Lernziel auf niedrigauflösenden Videos mit hochauflösenden Bildern für bessere Generalisierung.

• Kombiniere verschiedene Frame-Extraktionsmethoden in denselben Datensätzen, um Effektivität und Hardware-Ausnutzung zu maximieren.

Vieles, wenn nicht alles, was ich für dieses LoRA gelernt habe, stammt aus zahllosen r/StableDiffusion-Beiträgen, 24/7 Lurking im großartigen Banodoco Discord, dem Lesen von Kommentaren und Öffnen jedes NSFW-Clips zu jedem einzelnen WanVideo Modell hier auf Civitai sowie dem Eintauchen in jedes Issue, das ich im musubi-tuner, diffusion-pipe, Wan2.1 und anderen Repositories fand. 😽

P.S.

Dieses Modell ist eine technologische Demonstration der Fähigkeiten moderner Video-Generierungssysteme. Es ist nicht dazu gedacht, Rechte der ursprünglichen Schöpfer zu verletzen oder zu schädigen. Stattdessen dient es als Hommage an die bemerkenswerten Arbeiten der Künstler, deren Kreationen dieses Modell inspiriert haben.