推薦提示詞

Studio Ghibli style. Woman with blonde hair is walking on the beach, camera zoom out.,Studio Ghibli style. Woman dancing in the bar.,Studio Ghibli style. A young girl with short brown hair and curious eyes stands on a sunlit grassy hill, wind gently rustling her simple white dress.

推薦反向提示詞

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

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

推薦參數

samplers

UniPC, DPM++

steps

7 - 20

cfg

1 - 20

resolution

384x384, 768x416, 384x208

vae

wan_2.1_vae - 1.0

提示

使用 UniPC 取樣器獲得更佳的 2D 動畫效果。

應用 NAG 節點以便在較低 CFG(如 CFG=1)下啟用負面提示。

混合低解析視頻與高解析圖像數據集,有助同時學習動態與細節。

使用每秒 16 幀,最高 81 幀的視頻剪輯,以避免 RTX 3090 OOM。

重用剪輯片段的標題,無需重新標題可節省處理時間。

混合解析度數據集訓練提高泛化能力,且不需高 VRAM。

創作者贊助

OpenMuse

此 LoRA 為 OpenMuse 精選項目,致力於開源視頻 LoRA 及其激發的創意作品。聚焦 Wan2.1、LTX-Video 和 HunyuanVideo 等模型,OpenMuse 展示高品質工具與藝術品。根植於 Banodoco 社區,是開放協作 AI 藝術逐漸茁壯的基地,旨在激勵創作者並提供能自豪分享的作品,即使面對對 AI 藝術持懷疑態度者。

此 LoRA 為 OpenMuse 精選項目,致力於開源視頻 LoRA 及其激發的創意作品。聚焦 Wan2.1、LTX-Video 和 HunyuanVideo 等模型,OpenMuse 展現了生態系統中高品質的工具與藝術作品。根植於 Banodoco 社區,OpenMuse 是一個不斷壯大的開放協作 AI 藝術之家,旨在激發創作者靈感,喚起好奇心,並能自豪地分享,甚至面對質疑 AI 生成藝術者。

描述

我非常高興與大家分享我過去一個月一直在努力的 巔峰之作 LoRA,自 Wan 發佈以來一直在精進。這確實是我曾訓練過的最好的 LoRA 在 Civitai 上,我必須再次強調 - WanVideo 是一個了不起的模型。

LoRA 在 RTX 3090 上用 musubi-tuner 訓練約 90 小時,使用包含 240 段視頻和 120 張圖片的混合數據集。這本可以更快完成,但我執著於將極限推向 最先進 風格模型,是否成功就看你們判斷了。

用法

觸發詞為 Studio Ghibli style — 訓練數據的所有標題都以這句詞作為前綴。

我在畫廊發佈的所有剪輯均為使用基礎 Wan-T2V-14B 模型及此 LoRA 的原始輸出(最新視頻可能包含加速推理的自強制 LoRA,詳情見下),未經後期處理、升級或插值。

尚未測試與其他 LoRA 及 Wan-I2V 模型的兼容性。

每個視頻都包含嵌入的工作流(你可以直接下載並拖入 ComfyUI 打開)。示例:這是基於 Kijai 封裝的 JSON 工作流,使用由 自強制 LoRA (創作者 blyss)製作,從 lightx2v 的 Wan2.1-T2V-14B-StepDistill-CfgDistill 模型 提取。我選擇 blyss 的版本(而非 Kijai 的原版 LoRA),因為它最高兼容且僅加速推理,無額外細節或風格偏向。(這也是我堅持使用基礎 Wan 模型而非合併 AniWan 或 FusionX 的原因。)

我使用搭配 UniPC 取樣器(偶爾使用 DPM++)的加速 LoRA。我發現 UniPC 在 2D 動畫方面表現優於 LCM,後者偏向寫實效果,而我想避免此風格。通常我會使用 NAG 節點,以便在 CFG=1 低值下使用負面提示。初步測試顯示,相較於舊的 TeaCache 流程,除了速度大幅提升(RTX 3090 上渲染 640×480×81 幀 6 步剪輯約 1 分鐘,而非 6 分鐘),動態平滑與文本呈現亦稍有改善。

更新的 lightx2v LoRA 速度和質量保持同樣令人印象深刻。我用的是 rank 128 LoRA,但 32 和 64 版本同樣表現優異。這是工作流的示例 JSON 格式。我發現將 lightx2v LoRA 強度降到 0.9、步數增至 8,使用 UniPC 或 DPMPP 調度器,就能產出很棒的結果。

此處是「傳統」工作流 JSON 格式。它生成了本 LoRA 畫廊中約 90% 的視頻。基於封裝節點並包含多項優化(詳見 此處),包括 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,或其他能勝任的大型語言模型)中使用以下元提示,幫助豐富「原始」描述。此提示基於 Wan 開發人員的官方 提示擴展代碼,內容如下:

你是一名提示詞工程師,專精於將用戶輸入優化為適合以獨特吉卜力風格生成視頻的高品質提示詞。你確保輸出符合原意,同時豐富細節以增強視覺與動態清晰度。

任務要求:
- 若用戶輸入過於簡短,合理擴充細節,創造更生動完整的場景,不改變核心含義。
- 強調角色外貌、表情、服裝、姿態及空間關係等關鍵特徵。
- 永遠維護吉卜力視覺美學,包含柔和水彩風背景、富表情但簡潔的人物設計,及溫馨懷舊氛圍。
- 強化動態和鏡頭運動描述,造就自然動畫流暢度,包含溫柔有機動作,符合吉卜力敘事風格。
- 保留引號或標題中的原文,同時確保提示詞清晰沉浸,長度為 80~100 字。
- 所有提示詞必須以「Studio Ghibli style.」開頭,不得使用其他藝術風格。

示例修訂提示詞:
"Studio Ghibli style. 一位短棕髮、目光好奇的年輕女孩站在陽光灑落的草坡上,微風輕拂她簡單的白色洋裝。她凝視著一群鳥兒飛過金色天空,赤足微陷於柔軟土壤。場景籠罩於溫暖懷舊的光線,遠處樹木搖曳生姿。微風帶來自然聲音。中景稍微低角度,慢速電影式平移捕捉寧靜移動。"
"Studio Ghibli style. 黃昏時分的小村莊,燈籠軟光映襯木屋簷下。穿藍色浴衣的小男孩沿狹窄石路奔跑,拖鞋敲擊地面追逐螢火蟲。他興奮的表情映於閃爍河流旁。氛圍充滿溫暖橙與涼爽藍的交織,讓人聯想到平靜夏夜。中景平滑追蹤男孩活力步伐。"
"Studio Ghibli style. 神秘森林籠罩晨霧,高聳樹木覆蓋苔蘚小徑。穿著簡單綠色披風的女孩輕輕將手放在一頭巨大、目光溫柔似古老鹿的生物背上。陽光穿透厚厚樹冠,照亮飄散花粉,毛皮微光閃爍。鏡頭緩慢拉近,強調他們靜謐連結。輕風攪動葉片,小光靈藏於根部後方窺視。"

說明:
我現在將給你一個提示詞,請用符合吉卜力美學的英文完整且富視覺感提示詞擴充和潤飾它。即使輸入是指令而非描述,也請將其改寫成完整且生動的提示詞,無需附加回應或使用引號。

提示詞是:「YOUR PROMPT HERE」。

將 YOUR PROMPT HERE 替換為類似 年輕金髮女孩站在海岸邊山上雨中的表述。

負面提示詞總包含相同基底文本(視具體提示詞可加入額外詞):

色調艷麗,過曝,靜態,細節模糊不清,字幕,風格,作品,畫作,畫面,靜止,整體發灰,最差質量,低質量,JPEG壓縮殘留,醜陋的,殘缺的,多餘的手指,畫得不好的手部,畫得不好的臉部,畸形的,毀容的,形態畸形的肢體,手指融合,靜止不動的畫面,雜亂的背景,三條腿,背景人很多,倒著走, 3D, MMD, MikuMikuDance, SFM, Source Filmmaker, Blender, Unity, Unreal, CGI, bad quality

數據集

以下及後續章節會有些嘮叨 :) 可跳過直接看 結論,但也許有人能從中獲得有用信息。那麼...

數據集選擇階段是相對「簡單」的部分,我已有所有吉卜力電影的最高質量版本,並分割成場景——超過 30,000 段 1920x1040 高碼率剪輯,靜待我最終用於視頻模型的全面微調。

之前我已為 HV LoRA v0.7 預備約 300 段剪輯(且訓練即將開始時 Wan 發佈了),這些剪輯長度介於 65-129 幀,我認為這是 HV 視頻訓練的最佳範圍,且都是 24 fps。然而對 Wan,我希望剪輯長度不同(不超過 81 幀,後文「訓練」詳述),且需為 16 fps。我還 不確定嚴格的 16 fps 是否必要,但之前 HV 在 30 fps 而非其原生 24 fps 時出現過問題,因此我決定堅持 16 fps。

補充:處理數據集時,我通常寫許多小型「一次性」腳本(借助 Claude、ChatGPT 和 DeepSeek),包括手動選片的簡易 GUI、分解幀的一行命令、輸出輔助統計的腳本、根據區間拆分剪輯、提前製作桶等。這些腳本紊亂且硬編碼,且僅供一次性用故不公開。如今任何人皆可輕鬆利用上述 LLM 創建類似腳本。

將所有剪輯轉成 16 fps 後,幀數從 65-129 變為約 45-88,打亂了我精心規劃的訓練幀桶範圍。幸好選片時有規則應對此狀況。

首先,場景期間不應有快速轉換。因為我無法預測訓練器將為訓練設置的目標桶幀數(與模型大小、VRAM 等相關)。例如,我想用單個 81 幀長剪輯訓練,但 RTX 3090 會 OOM,必須選擇幀提取策略將剪輯拆分為多段(詳見幀提取策略,並有優秀解讀)。拆分可能破壞語義連貫(如剪輯首段女孩張口,剪裁後含糊是否哭或笑),令 Wan 的 UMT5 編碼器感到悲傷。

另一點是,我希望重複使用原始剪輯標題於各片段,避免重新標題與重新生成文本編碼。視頻標題生成耗時長,如場景變化劇烈,原始標題不適用於所有片段,降低訓練質量。因此依據「剪輯不含快速上下文轉換」和「剪輯自足,即不包含片內難以理解事件」規則,即使場景拆分成多段,標題仍可合理套用。

轉換後我篩選剪輯至 240 段(剔除過多轉換或過於靜態剪輯),作為數據集首部分。

我決定採用混合視頻與圖像數據集,數據集第二部分由 120 張 768x768 解析度圖片組成,為各吉卜力電影截屏。

另一個方法是先訓練圖片,再微調視頻(已被 該 LoRA 創作者成功採用),但我個人認為不如混合訓練(雖無硬數據支持)。佐證是此 優秀 LoRA亦同採混合方式訓練(據我所知亦用 24GB GPU)。

為讓消費級 GPU 能有效訓練混合數據集,我須在解析度、長度和訓練時間間找到平衡,決定結合低解析度長視頻與高解析度靜態圖像,更多細節見 訓練 章節。

就標題而言:圖像部分復用自部分 HV 數據集,使用我稱作 Qwen2-VL-7B-Instruct 的「瑞士軍刀」級 VLM 進行了(SFW 僅)標題生成。使用的標題提示如下:

對此場景創建極為詳盡的描述。不要使用編號清單或換行符。重要:輸出描述必須始終以不變的短語 “Studio Ghibli style. ” 開頭,後跟詳盡描述。描述應涵蓋 1) 場景主要內容,2) 環境和光照詳情,3) 鏡頭類型(如航拍、特寫、中景、遠景),4) 場景氛圍(如舒適、緊張、神秘)。必須使用此模板:‘Studio Ghibli style. {主要主體動作/描述}. {環境和光照細節}. {風格和技術規格}’。

我有疑慮是否應重新標題,因目標標題結構專為 HunyuanVideo 設計,憂慮 Wan 可能需完全不同策略。但我保持原樣,現代文本編碼器普遍能忽略這類限制。且據悉,Flux 等模型甚至可無需標題訓練(我認為有標題總比無好,前提標題與內容相關)。

對於視頻標題,我測試了多款本地模型:

還有其他模型,但這是我測試過的。最終本 LoRA 採用 Apollo-7B。我用了簡易 VLM 提示:

創建此視頻的極為詳盡描述。重要:輸出描述必須始終以不變短語 “Studio Ghibli style. ” 開頭,後接詳盡說明。

我隨模型附上完整訓練數據集。雖包含受版權保護內容,但我認為屬合理使用。此數據集僅用於研究與教育評估模型能力,並增強模型訓練過程的透明度,不得用於再分發或商業目的。

訓練

若有興趣,以下是我考慮用於 WanVideo 訓練的工具列表:

  • diffusion-pipe — HV 訓練元老,也支持記憶體高效 Wan 訓練;配置驅動,擁第三方 GUI 與 runpod 範本(更多見 )。HV 我獨用此工具。Windows 需 WSL 運行。

  • Musubi Tuner — 由負責且友善開發者維護。配置驅動,社區溫馨,選項豐富。目前我選擇此作 Wan 訓練用。

  • AI Toolkit — 我最近喜愛的 Flux 訓練器增添 Wan 支持。快速易用,配置驅動,含官方 UI(我不使用 🤷),但目前只支持無標題 14B 訓練,故未用。

  • DiffSynth Studio — 尚未有時間測試,不確定其能否用 24 GB VRAM 訓練 Wan。由 ModelScope 維護,值得關注,計劃稍後測試。

  • finetrainers — 支持 Wan 訓練,但似乎不支持 24 GB GPU(目前)。

  • SimpleTuner — 上周獲得 Wan 支持,尚未試用。主開發者熱情且知識豐富,值得關注。

  • Zero-to-Wan — 僅支持 1.3B 模型訓練。

  • WanTraining — 由曾為此付出卓越努力的開發者支持,例如其 引導蒸餾 LoRA控制 LoRA

我採用 Musubi Tuner。硬件參數參考:i5-12600KF, RTX 3090, Windows 11, 64GB RAM。以下是我用的命令與配置文件。

  • VAEs 潛在空間緩存(無特別,默認命令):

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 限制。超參數基本默認。之前失敗經驗讓我不敢冒進——60 小時 HV 訓練耗盡,源於過於激進的流位移與自適應優化器,最後還是回到傳統 adamw

  • 用於訓練時取樣的提示詞文件:

# prompt 1
Studio Ghibli style. 步行於海灘的金髮女子,鏡頭拉遠。  --w 384 --h 384 --f 45 --d 7 --s 20

# prompt 2
Studio Ghibli style. 在酒吧跳舞的女子。 --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

我的數據集配置分三部分。

最後一部分開始,主數據陣列含 240 段 1920x1040 解析度、幀數在 45 至 88 範圍內。

當然 RTX 3090 不堪重負,無法對全解析度全長度進行訓練。我須找到避免 OOM 且保持桶中片段盡可能長度的最低解析度和時長。片段越長,有助模型學習吉卜力風格的動態、節奏與空間模式(如毛髮跳動、布料飄揚、液體動態等),而靜態單幀達不到此效果。

根據過去 HV 訓練經驗,24 GB GPU 可用解析度範圍估計起點約為 512x512x33。我選用「uniform」幀提取方式,保證所有提取片段不短於 45 幀。轉成 16 fps 後最大約 88 幀,此法防止剪輯被切分為超過兩段,避免單輪訓練過長。同時約 45 幀(約 3 秒)足夠讓模型學習風格時空流動。

固定目標 45 幀後,我測試多種解析度,使用腳本分析資料夾中所有剪輯並建議符合原始寬高比(1920/1040 ≈ 1.85)且可被 16 整除的寬高組合(模型要求)。

最終,我發現使用 [384, 208] 當桶大小並設置 --blocks_to_swap 10 能防止 OOM 錯誤與共用記憶體堵塞(導致約 160 秒/次運算)。弊端是訓練速度降低至約 11-12 秒/次。回頭看,將解析度降至 [368, 192] 可能令速度提升至約 8 秒/次(相當於我在 AI Toolkit 訓練 Flux 1024p 的速度),可節省約 20 小時的 90 小時總訓練時長(約 28000 步),儘管當時不預期超過 2 萬步。

需注意的是我在 Windows 上監視器連 GPU,且同時用於寫程式 😼。Linux(如 diffusion-pipe)且監視器使用內建 GPU 輸出,或許能使用稍高時空解析度且不易碰到 OOM 或共用記憶體限制(我認為這是 Windows 專屬問題)。

關於第一部分,為 768x768 解析度的 120 張圖片。起初我想用 1024p 圖片訓練,但認為過於奢侈影響速度。計劃同時用高清圖片和低解析視頻訓練,確保泛化能力。高清圖片彌補視頻解析度不足。這其實是 WAN 訓練方式,我認為有助上游風格學習。

最後是第二部分,也利於泛化(雖不是「科學」假設,但看似合理)。原理為復用第三部分相同剪輯,但只訓練首幀與 21 幀內片段,有助捕捉時間風格動態。同時提升第二部分解析度至 [768, 416]。

結果是我期望實現的「跨泛化」:

  • 第一部分高清圖片 (768x768)

  • 第二部分中等解析首幀和 21 幀片段 (768x416)

  • 第三部分低解析 45 幀片段 (384x208)

此外,第二和第三部分大多數起始幀相同,有助 I2V 用戶使用 LoRA。綜合看,我認為這是充分利用數據集且避免踩硬件瓶頸的最佳策略。

當然,我 不是第一個提這思路的人,卻很合理,希望更多創作者理解 Wan 視頻 LoRA 訓練未必需要 A100 卡。

趣事:我期待每輪訓練含 1080 樣本:120 張圖片(數據集第一節) + 240 幀單張(數據集第二節,"head" 桶=1) + 240 段 21 幀剪輯(數據集第二節,"head" 桶=21) + 480 段 45 幀剪輯(數據集第二節,"uniform" 桶=45,採樣兩次)。訓練開始後發現實際為 1078 樣本。調查後發現兩段用 ffprobe 計數幀數的剪輯不足 45 幀,存在四捨五入問題。無大礙,剔除兩段後繼續訓練,這解釋了最後 LoRA 步數看起來的偏差 :)

訓練進展順利。我不公開損失圖表,因 我太害羞 覺得它們意義不大,我主要用來檢查損失分布各輪是否過於相似,若如此代表可能過擬合。

我訓練至 28000 步,隨後數日選最佳檢查點。我也覺得可在每輪結束前後拍檢查點,因 1078 步長輪中可能遺失更佳結果。

考慮將驗證損失估計整合到訓練流程(詳見 此處),但尚未實施。

是否可簡化?應該可以。下一個 LoRA 我會測試第一節額外圖片數據集是否多餘。理論上可單獨設置一節數據集,重用剪輯首幀但用高清。另一方面我希望數據盡可能多元化,因此選擇了不同場景截屏,故非完全多餘。

我也不確定第二節是否必需。WAN 本身(依照其 技術報告)曾於 192px 剪輯預訓練,在 約 352x192x45 上訓練理當有效,且最大化利用我的硬件。理想狀況下,我想用 5 秒剪輯(16 fps × 5 秒 + 1 = 81 幀),但 RTX 3090 無強力塊交換難以實現。

結論

除了樂趣和 成百株 萬條超棒剪輯,以下是我訓練此 LoRA 獲得的見解。提醒這些經驗源自個人觀察與實踐,無嚴格分析證明,我目前只嘗試過風格訓練,不久將嘗試概念訓練驗證其他假設。

  • 你可在消費級 GPU 上使用視頻訓練 Wan-14B,368x192x45 是穩妥的起點。

  • 用高解析圖像補充低解析視頻動態風格學習,提升泛化能力。

  • 在相同數據集上結合多種幀提取方法,最大化訓練效能和硬件利用率。

大部分我做出此 LoRA 的所得,來自無數 r/StableDiffusion 討論,24/7 潛伏於精彩的 Banodoco Discord,閱讀評論,打開每個 NSFW 剪輯,並深入研究每個 WanVideo 模型和 musubi-tunerdiffusion-pipeWan2.1 與其他庫中發現的問題。😽

附言

此模型是現代視頻生成系統能力的技術展示。並非意圖傷害或侵犯原創者權利,而是向啟發本模型的藝術家卓越作品致敬。

上一個
Hands XL + SD 1.5 + FLUX.1-dev + Pony + Illustrious - Hand XL v5.5
下一個
Niji 可愛風格 - v2.0 - illustrious

模型詳情

模型類型

LORA

基礎模型

Wan Video 14B t2v

模型版本

v1.0

模型雜湊值

dd2fe1258d

訓練詞彙

Studio Ghibli style

創作者

討論

log in以發表評論。

吉卜力工作室 🎥 Wan2.1-T2V-14B - v1.0 的圖片

動畫 圖片

動畫 圖片

Ghibli 圖片

吉卜力工作室 圖片

風格 圖片