Studio Ghibli 🎥 Wan2.1-T2V-14B

このLoRAは、オープンソースの動画LoRAとそれらが可能にする創造的ワークを専門に扱うキュレーションプロジェクトである_OpenMuse_で紹介されています。Wan2.1、LTX-Video、HunyuanVideoなどのモデルに焦点を当て、_OpenMuse_はエコシステム全体から高品質なツールとアートを紹介しています。Banodocoコミュニティを基盤とし、_OpenMuse_はオープンで協働的なAIアートの成長するホームであり、クリエイターを刺激し、疑念を持つ人にも誇らしく共有できるような作品を生み出すことを目的としています。

説明

Wanがリリースされてから過去1か月間、私はこのマグナム・オプスLoRAの開発に取り組んできました。これはこれまで私がCivitaiでトレーニングした中で最高のLoRAであり、改めて言わせていただきます——WanVideoは本当に素晴らしいモデルです。

このLoRAはRTX 3090を使ってmusubi-tunerで約90時間トレーニングされ、240のクリップと120の画像から成る混合データセットを使用しました。より速く完了することも可能でしたが、私は「最先端のスタイルモデル」を生み出すために限界を押し広げることに夢中になりました。私が成功したかどうかは、あなた次第です。

使用方法

トリガー文はStudio Ghibli styleです。トレーニングデータのすべてのキャプションにはこの言葉が前置されています。

ギャラリーに公開しているすべてのクリップは、ベースモデルとしてWan-T2V-14BとこのLoRAを使用したままの出力です（最新の動画では推論加速のため、自己強制LoRAも併用している場合があります。後述）。さらに後の処理、アップスケーリング、補間は一切行っていません。

他のLoRAやWan-I2Vモデルとの互換性は検証されていません。

ワークフローは各動画に埋め込まれています（ComfyUIに動画をドラッグするだけで開くことができます）。例として、こちらにJSONがあります（Kijaiのラッパーに基づく）。このワークフローは、lightx2vのWan2.1-T2V-14B-StepDistill-CfgDistillモデルから抽出された自己強制LoRA（blyss作成）を使用しています。私はKijaiのオリジナルLoRAではなく、blyssが作成したバージョンを選択しました。私のテストでは、このバージョンが最大の互換性を提供し、推論速度だけを加速する一方で、追加の細部やスタイル的なバイアスを一切導入しないからです。（これが、私はベースのWanモデルに固執し、AniWanやFusionXのようなマージを使用しない理由でもあります。）

私はUniPCサンプラー（ときどきDPM++）でこの加速LoRAを使用しています。私の経験では、2DアニメーションではLCMよりもUniPCの方が優れており、LCMは現実的さに傾きすぎます。通常、私はNAGノードも適用し、CFG=1でネガティブプロンプトを使用しています。初期テストによると、以前のTeaCacheワークフローと比較して、この新しいワークフローは驚くほどのスピード向上（RTX 3090で640×480×81の6ステップクリップを約1分でレンダリング、以前は6分）だけでなく、モーションの滑らかさとテキストのレンダリングもわずかに改善しています。

更新されたlightx2v LoRAも、スピードと品質保持に関して非常に印象的です。私はランク128のLoRAを使用していますが、ランク32や64のバージョンでも素晴らしい結果が得られます。以下にワークフローのJSON形式の例を示します。lightx2v LoRAの強度を0.9に下げ、ステップ数を8に増やし、UniPCまたはDPMPPスケジューラを使用すると、非常に良い出力が得られることに気づきました。明らかなデメリットは、出力がWanのデフォルトの「リアルな3Dスタイル」に傾きやすいことです。これを補うには、ステップ数を増やし、加速LoRAの強度を下げ、スタイルLoRAの強度を上げてください。また、lightx2v LoRAの代わりにrCM LoRAを使用してみると、モーションが若干改善される場合があります。

そしてこちらに、このLoRAのギャラリーの90%の動画を生成するために使用した「レガシー」ワークフローのJSON形式を示します。このワークフローはラッパーノードに基づいて構築され、fp8_e5m2チェックポイント＋torch.compile、SageAttention 2、TeaCache、Enhance-A-Video、Fp16_fast、SLG、（一部では）Zero-Starなどの最適化を多数含んでいました（これらの一部は新しいワークフローにも移行されています）。しかし、レガシー版では640×480×81クリップのレンダリングにまだ約5分かかっていました（RTX 3090）。レガシー版は一部の領域（パレット、滑らかさ）でわずかに優れた品質を示しましたが、5倍の遅延は決定的な欠点であり、私がlightx2vベースのバージョンに移行した主な理由です。

プロンプティング

ほとんどのプロンプトを生成する際、私はChatGPT（またはClaude、または他の能力のあるLLM）に以下のメタプロンプトを適用し、「生の」説明を強化します。このプロンプトはWan開発者が提供した公式のプロンプト拡張コードを基にしています：

あなたはプロンプトエンジニアであり、Studio Ghibliスタイルの動画生成に特化した高品質なプロンプトへユーザーの入力を洗練することを専門としています。出力は元の意図を保ちながら、視覚的および動作的な明確さを高めるよう洗練してください。

タスク要件：
- ユーザー入力が簡潔すぎる場合、核心的な意味を変更せずに、より鮮明で完全なシーンを構築するための合理的な詳細を追加してください。
- キャラクターの外見、表情、衣装、姿勢、空間的関係などの主要な特徴を強調してください。
- 常にStudio Ghibliのビジュアル美術を維持してください：ソフトな水彩風の背景、表現豊かでシンプルなキャラクターデザイン、温かくノスタルジックな雰囲気。
- 自然なアニメーションフローのために、動作とカメラの動きの記述を強化してください。Ghibliの物語スタイルに合った優しく有機的な動きを含めてください。
- 引用符やタイトル内の元のテキストを保持しつつ、プロンプトを明確で没入感があり、80〜100語の長さに保ってください。
- すべてのプロンプトは「Studio Ghibli style.」で始まります。他のアートスタイルは使用しないでください。

例：修正されたプロンプト
"Studio Ghibli style. 短い茶色の髪と興味深い目を持つ若い女の子が、陽の当たる草の丘の上に立っている。風が彼女のシンプルな白いドレスをそっと揺らしている。彼女は金色の空を舞う一団の鳥を眺め、裸足は柔らかな地面に少し沈んでいる。シーンは温かくノスタルジックな光に包まれ、遠くの茂った木々がそよいでいる。優しい風が自然の音を運んでいる。ミディアムショット、やや低めのアングルで、静かな動きを捉えるゆっくりとしたシネマティックなパン。

"Studio Ghibli style. 日暮れ時の小さな村。木造の家々の軒下に灯籠が優しく輝いている。青い浴衣を着た少年が狭い石の小道を駆け下り、螢を追いかけて足元の草履が地面を叩いている。彼の興奮した表情が横のきらめく川に反射している。大気は温かなオレンジと冷たい青で満ち、平和な夏の夕暮れを想起させる。少年の活発な足取りを追う滑らかなトラッキングショット。

"Studio Ghibli style. 朝もやに包まれた不思議な森。巨大な木々が苔むした小道を覆っている。シンプルなグリーンのマントを着た少女が、古くから伝わる鹿のような優しい目をした巨大な生き物の背中にそっと手を置いている。陽の光が濃い樹冠を突き抜けて、彼女の毛並みをわずかに輝かせ、浮遊する花粉を照らしている。カメラはゆっくりとズームインし、二人の静かな絆を強調する。優しい風が葉を揺らし、小さな光る精霊が根元の奥から顔を覗かせる。

指示：
これからあなたにプロンプトを提供します。Studio Ghibliの美術的スタイルに従って英語で拡張・洗練してください。入力が説明ではなく指示であっても、追加の返答や引用符なしで、視覚的に豊かな完全なプロンプトに書き換えてください。

プロンプトは： "YOUR PROMPT HERE"。

YOUR PROMPT HEREの部分を、_雨の降る海辺の丘の上に立つ若い金髪の女の子_などのような文で置き換えてください。

ネガティブプロンプトは常に以下のベーステキストを含みます（特定のプロンプトに応じて追加の単語が追加されることがあります）：

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

データセット

以下では、少々長話になります :) ここはスキップして結論だけ読んでも構いませんが、この長文の中に有用な情報が含まれているかもしれません。では……

データセット選定段階は「最も簡単」な部分でした。私はすべてのジブリ映画を可能な限り最高品質で持っています。シーンごとに分割済みで、1920×1040解像度かつ高ビットレートの30,000以上のクリップが、いずれかの日にこれらを使って完全な動画モデルをファインチューニングするのを待っています。

また、HV LoRAのv0.7用にすでに約300クリップを準備していました（実際、Wanがリリースされた直後にトレーニングを開始しようとしていました）。これらのクリップは65〜129フレームの範囲で、これはHVを動画でトレーニングするうえで最適と考えていた長さであり、すべて24fpsでした。しかし、Wan用には別のフレーム範囲（81フレーム以内）が望ましく、また16fpsである必要がありました。16fpsが厳密に必要かどうかはまだ完全には確信がありませんが、HVのトレーニングで30fpsのクリップを使用した際、HVのネイティブな24fpsと異なり問題が発生したため、16fpsに固執することにしました。

ここで述べておきますが、データセット処理のため、私は通常Claude、ChatGPT、DeepSeekの助けを借りて、多数の小さな「一度限り」のスクリプトを作成します。それは、動画を手動で選択するためのミニGUI、フレームの分割用のワンライナー、各種補助統計出力用スクリプト、クリップの範囲別分解、あらかじめバケットの作成などです。これらのスクリプトは、ごちゃごちゃしていてハードコードされた値が多く、一度限り使用するため、公開していません。今は誰でも上記のLLMにリクエストすることで同様のスクリプトを簡単に作成できます。

すべてのクリップを16fpsに変換することで、各動画のフレーム範囲は65〜129フレームから約45〜88フレームに縮小され、私がトレーニング用に慎重に設定したフレームバケットのフレーム数がずれてしまいました。しかし幸い、トレーニング用に動画を選定する際に、このような状況に備えていくつかのルールを設けていました。

まず、シーンの途中で急激なカットオーバーが含まれてはいけません。理由は、トレーナーがトレーニング用に決定するターゲットフレームバケットの正確なフレーム数（時間）を事前に予測できなかったためです。モデルサイズ、VRAM、その他の要因がすべて影響します。たとえば、1つの81フレームのクリップをトレーニングに使いたいと思っても、RTX 3090でOOM（メモリ不足）が発生するため、実際には不可能です。そのため、フレーム抽出戦略を選び、クリップを複数の短い部分に分割する必要があります（この素晴らしい解説を参照）。そしてそのとき、セマンティックな整合性が崩れる可能性があります（例：クリップの最初の部分で女の子が口を開けたとしても、切り取られた最初の断片だけでは、彼女が泣いているのか笑っているのか曖昧になります）。このような文脈の不整合は、WanのUMT5エンコーダーを悲しませてしまうのです。

もう一つ考慮すべき点は、元のクリップの各断片に対してキャプションを再利用したいということです。文字エンコーダーによるキャプション付けと埋め込みの再キャッシュを避けるためです。動画のキャプション付けには時間がかかりますが、シーン全体で劇的な変化があると、元のキャプションがすべての断片に適さなくなり、トレーニング品質が低下します。したがって、「クリップには急速な文脈の転換を含まない」「クリップは自立している、つまりその中で理解できない出来事は含まれない」という二つのルールを守ることで、たとえシーンがサブ断片に分割されても、キャプションは（許容可能な誤差範囲内で）各断片に依然として適用できます。

変換後、すべてのクリップを確認し、過剰なトランジションを含むものや逆にあまりにも静的なものを除外して、総数を240に減らしました。これがデータセットの第1部を形成しました。

私は動画と画像の混合データセットを使用することにしました。そのため、データセットの第2部は、さまざまなスタジオジブリ映画のスクリーンキャプチャーから抽出した120枚の画像（解像度768×768）で構成されました。

画像で事前訓練し、その後動画でファインチューニングするという代替アプローチがあります（このLoRAの作成者が成功させました）。しかし、個人的には、単一のバッチで混合して訓練する方が優れていると考えています（ただし、これを裏付ける明確な数値は持っていません）。私の仮説を補強するために、同じ混合訓練アプローチを採用した非常に優れたLoRAを紹介します（ちなみに、間違えなければ、これは24GBのGPUで実行されました）。

消費者向けGPUで混合データセットに対して効果的な動画訓練を実現するには、解像度、動画長さ、訓練時間のバランスを適切に調整する必要がありました。そのため、低解像度で長時間の動画と高解像度の画像を組み合わせることにしました。この点については、訓練セクションでさらに詳しく説明します。

キャプションについて：データセットの画像は、以前に作成したHVデータセットから再利用したものであり、それらのキャプションは、私の「スイスアーミーナイフ」VLM（SFWのみ対応）であるQwen2-VL-7B-Instructを用いて既に生成していました。以下のキャプションプロンプトを使用しました：

Create a very detailed description of this scene. Do not use numbered lists or line breaks. IMPORTANT: The output description MUST ALWAYS start with the unaltered phrase 'Studio Ghibli style. ', followed by your detailed description. The description should 1) describe the main content of the scene, 2) describe the environment and lighting details, 3) identify the type of shot (e.g., aerial shot, close-up, medium shot, long shot), and 4) include the atmosphere of the scene (e.g., cozy, tense, mysterious). Here's a template you MUST use: 'Studio Ghibli style. {Primary Subject Action/Description}. {Environment and Lighting Details}. {Style and Technical Specifications}'.

ターゲットのキャプション構造がHunyuanVideo用に特化されていることから、Wanにはまったく異なるアプローチが必要な可能性があり、再キャプションすべきか迷いました。しかし、そのまま使用することにしました。これが正しい判断だったのかはわかりませんが、現代のテキストエンコーダーは十分に強力で、このような制限を無視できると考えています。Fluxなどのモデルは、キャプションなしでも訓練可能であることが知られています（ただし、キャプションがコンテンツと関連している限り、キャプション付きで訓練する方が常に優れていると思います）。

動画のキャプション生成には、ネイティブで動画内容をキャプション生成できる複数のローカルモデルを試しました：

• CogVLM2-Video-Llama3-Chat（通常、クリップキャプションにはこれが私の選択肢です）

• MiniCPM-V 2.6

• Apollo-LMMs-Apollo-7B-t32

• LLaVA-Onevision

• VideoChat-Flash-2B

• VideoLLaMA 3

• Ovis2-16B（これは非常に優れているようですが、発見した時にはすでにデータセットのキャプション化が完了していたため、今後のLoRAで使用する予定です）

他にも多数のモデルがありますが、これらが私が試したものです。このLoRAでは、最終的にApollo-7Bを使用しました。以下のシンプルなVLMプロンプトを使いました：

Create a very detailed description of this video. IMPORTANT: The output description MUST ALWAYS start with the unaltered phrase 'Studio Ghibli style. ', followed by your detailed description.

私はこのモデルの追加資料として、使用した完全なデータセットを添付します。このデータセットには著作権で保護されたコンテンツを含んでいますが、フェアユースの範囲内であると考えています。このデータセットは、モデルの機能に関する研究・教育的評価と、訓練プロセスの透明性を確保するためにのみ提供されます。再配布や商用利用には使用しないでください。

訓練

興味のある方のために、WanVideoの訓練に検討したトレーナーのリストを以下に示します：

• diffusion-pipe - HV訓練の元祖であり、メモリ効率の良いWan訓練も可能。設定ファイル駆動で、サードパーティ製GUIとRunpodテンプレートも用意されている（こちらとこちらを参照）。HV訓練にはこれを唯一使用。WindowsではWSLが必要。

• Musubi Tuner - 責任感がありフレンドリーな開発者によって保守されている。設定ファイル駆動で、親しみやすいコミュニティと豊富なオプションを備えている。現在、Wan訓練の私の選択肢。

• AI Toolkit - 最近、Fluxのための私の好みのトレーナーがWanに対応しました。高速で使いやすく、設定ファイル駆動で、公式UIも備えています（私は使用しません 🤷）。ただし、現在はキャプションなしでの14Bのみの訓練をサポートしており、これが私が使用しない主な理由です。

• DiffSynth Studio - 試す時間が取れていませんが、24GB VRAMでWanモデルを訓練できるか不明です。ただし、ModelScopeが保守しているため、注目価値は十分にあります。近い将来、試してみる予定です。

• finetrainers - Wan訓練をサポートしていますが、24GB GPUでは動作しないようです（現時点では）。

• SimpleTuner - 先週Wanに対応したので、まだ試していません。主要開発者が非常に情熱的で知識豊富であるため、注目に値します。

• Zero-to-Wan - 1.3Bモデルのみの訓練をサポート。

• WanTraining - このプロジェクトに言及しなければなりません。開発者がガイドアンス・ディスティルLoRAやコントロールLoRAなど、非常に印象的な成果を上げているからです。

そこで、私はMusubi Tunerを使用しました。参考までに、私のハードウェア環境は以下の通りです：i5-12600KF、RTX 3090、Windows 11、64GB RAM。使用したコマンドと設定ファイルは以下の通りです。

• VAEの潜在変数のキャッシュ（特別な設定なし、デフォルトコマンドのみ）

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

• テキストエンコーダーの埋め込みのキャッシュ（デフォルト）：

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 

• 訓練の起動：

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

実際には特に目立ったことはありません。私のデータセット設定（下記参照）では、blocks_to_swapパラメータを使用しなければ、24GB VRAMの制約に達してしまったため、このパラメータを用いました。ハイパーパラメータはほとんどデフォルトのままにしました。過去に悪い経験（flow shift値やアダプティブオプティマイザの過剰な設定により、60時間のHV訓練を無駄にした）があったため、リスクを避けるためです。

• 訓練中のサンプリング用プロンプトファイル：

# prompt 1
Studio Ghibli style. Woman with blonde hair is walking on the beach, camera zoom out.  --w 384 --h 384 --f 45 --d 7 --s 20

# prompt 2
Studio Ghibli style. Woman dancing in the bar. --w 384 --h 384 --f 45 --d 7 --s 20

• データセット構成（最も重要な部分；その後にその思考プロセスを説明します）：

[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

私のデータセット構成は3つの部分で構成されています。

まず最後の部分から説明します。これは主なデータ配列であり、1920x1040解像度の240クリップで、フレーム数は45〜88フレームと異なります。

RTX 3090でフル解像度の1920x1040、フル長のクリップを訓練することは不可能でした。OOMエラーを回避しつつ、バケットのフラグメントを可能な限り長く保つ最小解像度とフレーム長を見つける必要がありました。長いフレグメントは、モデルがジブリのスタイルにおける運動、タイミング、空間パターン（髪の動き、布の揺れ、液体の動きなど）を学習するのに役立ちます。これは静止画では実現できません。

HV訓練の経験から、24GB GPUで利用可能な解像度範囲の目安は512x512x33だと覚えていました。そこで、「uniform」フレーム抽出方式を採用し、抽出されたフラグメントが最低45フレーム以上になるようにしました。前述のように、16fpsに変換した後、最大88フレームまでしかなかったため、このアプローチによりクリップが2つ以上のスパンに分割されることを防ぎ、エポックが長くなりすぎることを避けました。同時に、45フレーム（約3秒）の時間枠は、スタイルの空間的流れをモデルに学習させるのに十分であると考えました。

ターゲットを45フレームに固定した後、さまざまな解像度をテストしました。フォルダ内のすべてのクリップを分析し、元のアスペクト比（1920/1040 ≈ 1.85）を維持しつつ、16で割り切れる幅と高さの組み合わせ（モデル要件）を提案するスクリプトを使用しました。

その結果、[384, 208]のバケットサイズを使用し、--blocks_to_swap 10を設定することで、OOMエラーと共有メモリへの侵入（最終的に160秒/イテレーションに至る）を回避できました。ただし、訓練速度は約11〜12秒/イテレーションまで低下しました。振り返ると、解像度を[368, 192]に下げれば、速度は約8秒/イテレーションに向上し、より理想的だったでしょう（AI Toolkitで1024pでFluxを訓練するときの速度に近い）。これにより、90時間の全訓練（約28,000ステップ）のうち、約20時間の訓練時間を節約できたでしょう。しかし、当時は20,000ステップを超えるとは思っていませんでした。

また、Windows上でモニターをGPUに接続し、同時にコードを書く環境で訓練したことに注目すべきです。Linux（たとえばdiffusion-pipe）でモニター出力を内部GPUに設定すれば、OOMや共有メモリの制限に達せずに、わずかに高い空間・時間解像度で訓練できた可能性があります。これはWindows特有の制限であると考えられます。

次に最初の部分（768x768解像度の120枚の画像）について説明します。当初は1024pの画像で訓練しようと考えていましたが、過剰で遅くなると判断してやめました。私の計画は、HD画像と低解像度動画を同時に訓練することで、より良い汎化を実現することでした。高解像度画像がクリップの低解像度を補うだろうと考えました。また、WANの訓練方法自体が動画＋画像の混合事前訓練であるため、このアプローチは「上流」スタイルの学習にも有利であると考えました。

最後に、一般化にも重要（再び、これは「科学的」な仮定ではないが、合理的に思える）な第2部である。このアイデアは、第3部と同じクリップを再利用し、今度は最初の1フレームと最初の21フレームのみで訓練することだった。このアプローチにより、時間的なスタイルの動き特徴の学習が促進されると期待した。同時に、第2部の解像度を[768, 416]に引き上げることも可能になった。

その結果、以下のような「クロス一般化」を達成できることを期待した：

• 第1部の高解像度画像（768x768）

• 第2部の中解像度の単一フレームと21フレームのクリップ（768x416）

• 第3部の低解像度の45フレームのクリップ（384x208）

さらに、第2部と第3部の大部分は同じ開始フレームを共有しており、これはI2VシナリオにおけるLoRAの利用に有利だと信じていた。これらすべてが、ハードウェアの限界に達することなく、自分のデータセットを最大限に活用する最良の方法のように思えた。

もちろん、このアプローチを思いついたのは私だけではない[1]が、論理的かつ合理的に思えるため、もっと多くのクリエイターが、Wan用のビデオベースのLoRAを訓練するのにA100が必要ではないことに気づいてくれることを願っている。

面白い事実： 1エポックは1080サンプルで構成されると予想していた：120枚の画像（第1データセット部）＋240枚の単一フレーム（第2データセット部、「head」フレームバケット=1）＋240個の21フレームごとのクリップ（第2データセット部、「head」フレームバケット=21）＋480個の45フレームごとのクリップ（第2データセット部、「uniform」フレームバケット=45、2回サンプリング）。しかし、訓練を開始したところ、実際には1078サンプルだった。調査したところ、私のスクリプト（ffmpegのffprobeコマンドを使用してフレーム数をカウント）が報告した2つのクリップが実際には45フレームより短く、丸め誤差が発生していた。これは大きな問題ではなかったため、これらの2つのクリップを除外して訓練を継続したが、それが最終的なLoRAのステップ数が異常に見えた理由だった :)

訓練自体はスムーズに進んだ。損失グラフは公開しない（恥ずかしいし、意味があるとは思っていないため）。主に、エポックごとの損失分布が似すぎていないかをチェックするために使用しており、それが過学習の兆候だと判断する。

28,000ステップまで訓練した後、数日かけて最良のチェックポイントを選択した。もう少し改善できていたと思うのは、各エポックの終了時だけでなく、その途中でもチェックポイントを保存することだった。1エポックは1078ステップなので、私が最終的に選んだチェックポイントより優れたものが途中で失われていた可能性がある。

訓練パイプラインに検証損失の推定を組み込むことを検討している（詳しくは[ここ]を参照）。しかし、まだ実装していない。

これを簡略化できるだろうか？おそらく可能だ。次回のLoRAでは、第1部の追加画像データセットが冗長だったかどうかを検証するつもりだ。単に別途のデータセットセクションを設定して、高解像度のクリップの最初のフレームだけを使うこともできた。しかし、私はデータセットを可能な限り多様にしたかったため、クリップとは異なるシーンからのスクリーンキャプチャを使用し、この意味ではそれらは冗長ではなかった。

第2部自体が本当に必要だったのかも不明だ。WAN自体（その[技術レポート]によれば）192pxのクリップで事前学習されているため、約352x192x45での訓練は効果的であり、ハードウェアを最大限に活用できるはずだ。理想的には、5秒のクリップ（16fps×5秒＋1＝81フレーム）を使いたいが、RTX 3090では積極的なブロックスワッピングなしには現実的ではない。

結論

楽しいことや何十万もの信じられないほど素晴らしいクリップの他、このLoRAの訓練から得られたいくつかの知見を紹介する。これらはすべて私の個人的な経験と観察に基づくものであり、効果を厳密に分析した証拠はなく、これまでスタイル訓練のみを試してきた。すぐにコンセプト訓練も試して、他の仮説が適用できるかどうかを確認する予定だ。

• 消費者向けGPUを使ってWan-14Bを動画で訓練することは可能だ。368x192x45は堅実な出発点である。

• 低解像度動画での動き指向スタイル学習の不足を、高解像度画像を使って補い、より良い一般化を実現する。

• 同じデータセット上でさまざまなフレーム抽出手法を組み合わせ、効果とハードウェア利用を最大化する。

このLoRAの構築に至るまでに学んだことの多く（あるいはすべて）は、数え切れないほどのr/StableDiffusionの投稿、Banodoco Discordでの24時間の監視、Civitai上のすべてのWanVideoモデルのNSFWクリップをひとつずつ開いてコメントを読む、そしてmusubi-tuner、diffusion-pipe、Wan2.1 など、あらゆるリポジトリの問題を掘り下げることから得られたものだ。😽

P.S.

このモデルは、現代の動画生成システムの可能性を示す技術的ショーケースであり、元のクリエイターの権利を害したり侵害したりすることを意図したものではありません。むしろ、このモデルの原動力となったアーティストたちの素晴らしい作品への賛辞です。