Studio Ghibli 🎥 Wan2.1-T2V-14B
详情
下载文件
模型描述
这个 LoRA 在 OpenMuse 上被推荐，OpenMuse 是一个专注于开源视频 LoRA 及其催生的创意作品的精选计划。该平台聚焦于 Wan2.1、LTX-Video 和 HunyuanVideo 等模型，突出展示来自整个生态系统的高质量工具与艺术作品。OpenMuse 植根于 Banodoco 社区，是一个不断成长的开放协作 AI 艺术家园，旨在激励创作者、激发好奇心，并提供让你即使面对对 AI 生成艺术持怀疑态度的人也愿意自豪分享的作品。
描述
我很高兴分享我历时一个月、自 Wan 发布以来一直潜心打造的“代表作”LoRA。这无疑是我迄今为止在 Civitai 上训练出的最出色的 LoRA，我必须再次强调——WanVideo 是一个令人惊叹的模型。
该 LoRA 使用 musubi-tuner 在 RTX 3090 上训练了约 90 小时，数据集包含 240 个视频片段和 120 张图像。虽然可以更快完成，但我沉迷于突破极限，力求打造一款“前沿级”风格模型。是否成功，由你评判。
使用方法
触发词为 Studio Ghibli style —— 所有训练数据的标题都以前缀“Studio Ghibli style”开头。
我在画廊中发布的所有片段均为原始输出，基于基础模型 Wan-T2V-14B 配合该 LoRA 生成（尽管最新视频也可能包含用于推理加速的自强制 LoRA，详见下文），未做任何后期处理、超分辨率或插值。
与其他 LoRA 或 Wan-I2V 模型的兼容性尚未测试。
每个视频都嵌入了工作流（你可以直接下载并拖入 ComfyUI 打开）。例如，这里是工作流的 JSON（基于 Kijai 的封装器），使用了 自强制 LoRA（由 blyss 创建），该 LoRA 从 lightx2v 的 Wan2.1-T2V-14B-StepDistill-CfgDistill 模型 中提取。我选择 blyss 版本（而非 Kijai 的原始 LoRA），是因为根据我的测试，它提供了最大程度的兼容性，仅加速推理，而不会引入额外的细节或风格偏向。（这也是我坚持使用基础 Wan 模型，而不使用如 AniWan 或 FusionX 等融合模型的原因。）
我使用加速 LoRA 配合 UniPC 采样器（偶尔使用 DPM++）。在我的经验中，UniPC 在 2D 动画上的表现优于 LCM，因为 LCM 更倾向于写实风格，而我想避免这一点。我通常还会应用 NAG 节点，以便在 CFG=1 时使用负向提示。根据初步测试，与旧版 TeaCache 工作流相比，新流程不仅大幅提速（在 RTX 3090 上，640×480×81 帧、6 步的片段渲染仅需约 1 分钟，而非 6 分钟），而且略微提升了动作流畅度和文字渲染效果。
更新后的 lightx2v LoRAs 在速度和质量保留方面也非常出色。我使用的是 rank 128 的 LoRA，但 32 和 64 版本也表现极佳。这里是该工作流的 JSON 示例。我发现，将 lightx2v LoRA 强度降至 0.9，将步数增至 8，并使用 UniPC 或 DPMPP 调度器，能获得相当不错的效果。明显的缺点是输出通常趋向于 Wan 默认的“写实 3D”风格。应对方法是增加步数、降低加速 LoRA 强度、提高风格 LoRA 强度。你也可以尝试用 rCM LoRA 替代 lightx2v LoRA，它有时能带来稍好的动作表现。
这里是“旧版”工作流的 JSON 格式。本工作流用于生成该 LoRA 画廊中约 90% 的视频。它同样基于封装节点，包含大量优化（详见此处），如 fp8_e5m2 检查点 + torch.compile、SageAttention 2、TeaCache、Enhance-A-Video、Fp16_fast、SLG，以及（有时）Zero-Star（其中部分已迁移至新工作流），但旧版工作流渲染一个 640x480x81 帧的片段仍需约 5 分钟（RTX 3090）。尽管旧版工作流在某些特定方面（如调色、流畅度）略胜一筹，但 5 倍的延迟是显著且决定性的缺点，这正是我转向 lightx2v 版本的原因。
提示词
为了生成大多数提示词，我通常会在 ChatGPT（或 Claude 或任何其他强大 LLM）中应用以下元提示，以增强“原始”描述。该提示基于 Wan 开发者官方的提示扩展代码，内容如下：
你是一位提示词工程师，专精于将用户输入优化为高质量的 Studio Ghibli 风格视频生成提示词。你确保输出在保留原意的同时，丰富视觉与动态细节。
任务要求：
- 如果用户输入过于简短，请合理扩展，构建更生动、完整的场景，但不改变核心含义。
- 强调关键特征：角色外貌、表情、服装、姿态及空间关系。
- 始终保持 Studio 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
数据集
在本节及以下部分，我将说些废话 :) 你可以直接跳到结论，但也许有人会从这段文字中找到有用的信息。所以……
数据集选择阶段是最“轻松”的部分，我已拥有所有吉卜力电影的最高质量版本，并按场景分割——超过 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 会因内存溢出而失败，因此我必须根据情况选择帧提取策略，将片段切分成若干较短部分（此处有详尽的策略解析）。而这样可能导致语义连贯性被破坏（如：片段开头女孩张开嘴，但被截断后，无法判断她是哭还是笑），这种上下文断裂会让 Wan 的 UMT5 编码器“难过”。
另一点要考虑的是，我希望复用原始片段的字幕，而不必重新标注或通过文本编码器重新缓存嵌入。视频标注耗时很长，但若场景在片段内剧烈变化，原始字幕可能无法适用于所有片段，降低训练质量。通过遵守“片段不应包含快速上下文切换”和“片段应为自包含，即不应包含无法从片段内理解的事件”这两条规则，即使片段被拆分为子片段，字幕仍大致适用于每个片段（容许一定误差）。
转换后，我浏览了所有片段，并将总数减少到240个（删掉了那些过渡过多或相反过于静态的片段），这些构成了数据集的第一部分。
我决定使用视频和图像的混合数据集。因此，数据集的第二部分由120张图像组成（分辨率为768x768），这些图像取自多部吉卜力电影的屏幕截图。
有一种替代方法：先用图像训练，再对视频进行微调（这个LoRA的作者成功应用了这种方法），但 personally 我认为在单批中混合训练效果更好（尽管我没有确凿数据支持这一点）。为了支持我的假设，这里有一个非常出色的LoRA，它同样采用了混合训练方式（顺便说一句，据我所知，它也是在24GB显存的GPU上完成的）。
为了在消费级GPU上有效训练混合数据集的视频，我必须在分辨率、时长和训练时间之间找到合适的平衡。我决定通过混合低分辨率、长时长视频和高分辨率图像来实现这一点——更多细节将在训练部分中说明。
关于标注：数据集中的图像实际上是复用自我之前的一些HV数据集，它们早已使用我的“瑞士军刀”VLM（仅限SFW）进行标注，即Qwen2-VL-7B-Instruct。我使用的标注提示如下：
创建对该场景的非常详细描述。不要使用编号列表或换行符。重要：输出描述必须始终以未修改的短语“Studio Ghibli style. ”开头，后接你的详细描述。描述应包含：1）场景的主要内容，2）环境与光照细节，3）镜头类型（如航拍、特写、中景、远景），4）场景氛围（如温馨、紧张、神秘）。你必须使用以下模板：“Studio Ghibli style. {主体动作/描述}。{环境与光照细节}。{风格与技术规格}”。
我曾犹豫是否应重新标注，因为目标标注结构是专为HunyuanVideo设计的，我担心Wan可能需要完全不同的方法。我最终保留了原标注，也不知道这是否正确，但总体而言，现代文本编码器足够强大，足以忽略此类限制。众所周知，像Flux等模型甚至可以在无标注的情况下训练（尽管我相信有相关标注的训练总是优于无标注——前提是标注内容与图像相关）。
对于视频标注，我测试了多个可原生标注视频内容的本地模型：
CogVLM2-Video-Llama3-Chat（通常是我视频片段标注的首选）
Ovis2-16B（这个似乎非常优秀！但我发现它时已完成了数据集标注，因此将在未来的LoRA中使用）
还有更多模型，但以上是我测试过的。对于本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 - 我尚未有时间测试，不确定它能否在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内存。我使用的命令和配置文件如下：
- 缓存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的限制。超参数大多保留默认值。我此前有过惨痛教训：因过于激进地使用流移值和自适应优化器，导致60小时的HV训练功亏一篑，所以我这次不敢冒险，坚持使用稳妥的adamw。
- 训练期间采样提示文件：
# 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
我的数据集设置分为三部分。
我先从最后一部分说起，它包含主要数据集——240个分辨率为1920x1040、帧数在45至88帧之间的视频片段。
显然，在RTX 3090上直接训练完整分辨率1920x1040、完整时长的片段是不可行的。我需要找到在避免OOM错误的同时尽可能保持片段长度的最低分辨率与帧数。较长的片段有助于模型学习吉卜力风格的运动、节奏与空间模式（如发丝抖动、布料飘动、液体动态等），而这些是静态图像无法提供的。
从训练HV的经验中，我回忆起24GB显存GPU的可用分辨率范围大致为512x512x33。我决定采用“uniform”帧提取模式，确保所有提取片段不少于45帧。正如我之前所说，转换为16fps后，最长片段为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分辨率下的速度），并可为整个90小时训练（约28000步）节省约20小时——尽管当时我并未预期训练会超过20K步。
还需指出，我在Windows系统上训练，显示器连接至该GPU（同时我还用这台电脑写代码 😼）。在Linux系统（如使用diffusion-pipe）且显示器使用集成显卡输出时，或许能在不触发OOM或共享内存限制的前提下使用略高的时空分辨率（我认为这很可能是Windows特有的限制）。
现在谈谈第一部分（768x768分辨率的120张图像）。我原本打算使用1024p图像训练，但最终认为这过于浪费且会拖慢速度。我的计划是同时训练高清图像与低分辨率视频，以确保更好的泛化能力。想法是：高分辨率图像可以弥补视频片段的低分辨率缺陷。此外，WAN最初的训练方式就是视频+图像联合预训练（参见WAN训练方式），因此我认为这种做法也有利于“上游”风格的学习。
最后，第二部分，这对泛化同样重要（再次强调，这并不是一个“科学”的假设，但看起来是合理的）。我的想法是复用第三部分的相同视频片段，但这次仅使用第一帧和前21帧进行训练。我希望这种方法能帮助模型更好地学习时序风格运动特征。同时，这也让我可以将第二部分的分辨率提升至 [768, 416]。
因此，我期望实现以下三部分之间的“跨泛化”：
第一部分 的高分辨率图像（768x768）
第二部分 的中等分辨率单帧和21帧片段（768x416）
第三部分 的低分辨率45帧片段（384x208）
此外，第二部分和第三部分的大部分内容共享相同的起始帧，我认为这将有益于在图像到视频（I2V）场景中使用 LoRA。这一切似乎是在不突破硬件限制的前提下，充分利用我的数据集的最佳方式。
当然，我不是第一个提出这种方法的人，但它看起来合乎逻辑且合理，因此我希望更多创作者意识到，你并不需要A100来训练一个适用于Wan的基于视频的LoRA。
有趣的事：我原以为一个epoch包含1080个样本：120张图像（第一数据集部分）+ 240个单帧（第二数据集部分，“头”帧桶=1）+ 240个21帧片段（第二数据集部分，“头”帧桶=21）+ 480个45帧片段（第二数据集部分，“均匀”帧桶=45，采样2次）。然而，开始训练后我发现实际只有1078个样本。深入探究后，我发现我脚本统计的两个片段（使用ffmpeg的ffprobe命令计算帧数）实际帧数少于45帧，存在四舍五入问题。这并不是大问题，所以我直接跳过了这两个片段继续训练，但这就是为什么最终LoRA的步数看起来有点偏差的原因 :)
训练过程本身非常顺利。我不会展示损失曲线图，因为我太害羞了，也不觉得它们有什么意义。我主要用它们来检查损失分布是否在各个epoch中变得过于相似——这是我判断可能出现过拟合的信号。
我训练到了28000步，然后花了几天时间挑选最佳检查点。我认为我本可以做得更好的一点是，不仅在每个epoch结束时保存检查点，也在中间阶段保存。由于每个epoch是1078步，很可能某个比最终选择效果更好的检查点就丢失在中间了。
我正考虑在训练流程中整合验证损失估算（更多细节见这里），但我还没实施。
这能简化吗？可能可以。在我的下一个LoRA中，我会测试第一部分的额外图像数据集是否冗余。我本可以只设置一个独立的数据集部分，复用视频片段的首帧，但以高分辨率实现。另一方面，我希望数据集尽可能多样化，因此我使用了与视频片段不同场景的屏幕截图，从这个角度看，它们并非冗余。
我甚至不确定第二部分是否必要。因为WAN本身（根据其技术报告）已在192px的视频片段上进行了预训练，因此在约352x192x45的分辨率下训练应该是有效的，并能充分利用我的硬件。理想情况下，我会使用5秒的视频片段（16 fps × 5s + 1 = 81帧），但这在RTX 3090上不进行激进的块交换是完全不可行的。
结论
除了乐趣和数十万条极其出色的视频片段外，我在训练这个LoRA的过程中获得了一些洞见。我必须说明，这些实践基于我个人的经验和观察，我目前没有严格的分析证据证明它们的有效性，而且我至今仅尝试了风格训练。我计划很快探索概念训练，以验证我的其他假设是否同样适用。
你可以使用消费级GPU在Wan-14B上进行视频训练。368x192x45似乎是一个扎实的起点。
通过使用高分辨率图像补偿低分辨率视频中针对运动的风格学习，以确保更好的泛化。
在同一数据集上结合多种帧提取方法，以最大化效果和硬件利用率。
我为制作这个LoRA所学到的大部分（甚至全部）知识，都来自于阅读无数 r/StableDiffusion 帖子、24/7潜伏在优秀的Banodoco Discord、阅读评论、打开Civitai上每一个WanVideo模型的NSFW片段，以及深入研究musubi-tuner、diffusion-pipe、Wan2.1等仓库中的每一个issue。😽
附注
本模型是现代视频生成系统能力的技术展示，其目的并非伤害或侵犯原作者的权利，而是向那些启发了本模型的艺术家们的卓越作品致以敬意。