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

Este LoRA está em destaque no OpenMuse, uma iniciativa curada dedicada a LoRAs de vídeo open-source e às obras criativas que possibilitam. Focada em modelos como Wan2.1, LTX-Video e HunyuanVideo, o OpenMuse destaca ferramentas e trabalhos artísticos de alta qualidade em todo o ecossistema. Enraizado na comunidade Banodoco, o OpenMuse é um lar crescente para arte colaborativa em IA aberta, projetado para inspirar criadores, despertar curiosidade e oferecer algo que você se orgulharia de compartilhar, mesmo com alguém cético em relação à arte gerada por IA.

Descrição

Estou muito feliz em compartilhar meu LoRA magnum opus, no qual venho trabalhando no último mês desde o lançamento do Wan. Este é, de fato, o melhor LoRA no Civitai que já treinei, e preciso dizer (mais uma vez) - WanVideo é um modelo incrível.

O LoRA foi treinado por cerca de 90 horas em um RTX 3090 usando musubi-tuner com um conjunto de dados misto de 240 clipes e 120 imagens. Isso poderia ter sido feito mais rápido, mas estava obcecado em ultrapassar os limites para criar um modelo de estilo state-of-the-art. Cabe a você julgar se consegui.

Uso

A frase de disparo é estilo Studio Ghibli - todas as legendas dos dados de treinamento foram prefixadas com essas palavras.

Todos os clipes que publico na galeria são saídas brutas usando um LoRA com um modelo base Wan-T2V-14B (embora os vídeos mais recentes também possam incluir LoRA de auto-força para aceleração da inferência, leia mais abaixo), sem pós-processamento, upscaling ou interpolação adicionais.

A compatibilidade com outros LoRAs e com modelos Wan-I2V não foi testada.

Os fluxos de trabalho estão incorporados em cada vídeo (para que você possa apenas baixar e arrastar o vídeo para o ComfyUI para abri-lo). Como exemplo, aqui está o JSON para o fluxo de trabalho (baseado no wrapper de Kijai), que usa o LoRA de auto-força (criado por blyss), extraído do modelo Wan2.1-T2V-14B-StepDistill-CfgDistill de lightx2v. Escolhi a versão feita por blyss (e não o LoRA original do Kijai), porque, pelos meus testes, oferece máxima compatibilidade e apenas acelera a inferência, sem detalhamento adicional ou viés estilístico. (Esta é também a razão pela qual me mantenho no modelo base Wan e não uso merges como AniWan ou FusionX.)

Eu uso o LoRA de aceleração com o sampler UniPC (e ocasionalmente DPM++). Na minha experiência, UniPC funciona melhor para animação 2D do que LCM, que tende a inclinar-se mais para o realismo, o que desejo evitar. Geralmente também aplico o nó NAG para poder usar prompts negativos com CFG=1. Nos testes iniciais, comparado ao fluxo de trabalho antigo com TeaCache, além do enorme ganho de velocidade (um clipe 640×480×81 com 6 passos renderiza em ~1 minuto em vez de 6 no RTX 3090), também melhora ligeiramente a suavidade do movimento e a renderização de texto.

Os LoRAs atualizados do lightx2v também são muito impressionantes em termos de velocidade e preservação da qualidade. Estou usando um LoRA rank 128, mas as versões 32 e 64 também produzem ótimos resultados. Aqui está um exemplo do fluxo em formato JSON. Descobri que reduzir a força do LoRA lightx2v para 0.9, aumentar o número de passos para 8 e usar UniPC ou DPMPP como scheduler gera saídas muito boas.

E aqui está o fluxo "legado" em formato JSON. Foi usado para gerar 90% dos vídeos na galeria para este LoRA. Também foi construído com nós wrapper e incluía muitas otimizações (mais informações aqui), incluindo checkpoints fp8_e5m2 + torch.compile, SageAttention 2, TeaCache, Enhance-A-Video, Fp16_fast, SLG e (às vezes) Zero-Star (alguns destes também migraram para o fluxo novo), mas a renderização de um clipe 640x480x81 ainda levava cerca de 5 minutos (RTX 3090) no fluxo antigo. Embora o fluxo legado demonstre qualidade ligeiramente superior em algumas áreas específicas (paleta, suavidade), a lentidão 5x é uma desvantagem significativa e decisiva, sendo essa a razão para a migração para a versão alimentada pelo lightx2v.

Prompting

Para gerar a maioria dos prompts, geralmente aplico o seguinte meta-prompt no ChatGPT (ou Claude, ou qualquer outro LLM capaz), que ajuda a enriquecer as descrições "cruas". Este prompt é baseado no código oficial de extensão de prompt dos desenvolvedores do Wan e se apresenta assim:

Você é um engenheiro de prompt, especializado em refinar entradas de usuário em prompts de alta qualidade para geração de vídeo no estilo distinto Studio Ghibli. Você assegura que a saída esteja alinhada com a intenção original enquanto enriquece os detalhes para clareza visual e de movimento.

Requisitos da Tarefa:
- Se a entrada do usuário for muito breve, expanda-a com detalhes razoáveis para criar uma cena mais vívida e completa sem alterar o significado principal.
- Enfatize características-chave como aparências dos personagens, expressões, roupas, posturas e relações espaciais.
- Sempre mantenha a estética visual Studio Ghibli - fundos suaves como aquarela, designs de personagens expressivos porém simples, e uma atmosfera calorosa e nostálgica.
- Melhore as descrições de movimento e movimentos de câmera para fluxo de animação natural. Inclua movimentos suaves e orgânicos que correspondam ao estilo narrativo de Ghibli.
- Preserve o texto original em citações ou títulos enquanto assegura que o prompt seja claro, imersivo e tenha entre 80-100 palavras.
- Todos os prompts devem começar com "estilo Studio Ghibli." Nenhum outro estilo de arte deve ser usado.

Exemplos de Prompts Revisados:
"Estilo Studio Ghibli. Uma jovem garota com cabelo castanho curto e olhos curiosos está em uma colina gramada iluminada pelo sol, o vento mexendo suavemente seu vestido branco simples. Ela observa um grupo de pássaros voando pelo céu dourado, seus pés descalços afundando levemente na terra macia. A cena é banhada por uma luz quente e nostálgica, com árvores exuberantes balançando ao fundo. Uma brisa suave leva os sons da natureza. Plano médio, ângulo levemente baixo, com uma panorâmica cinematográfica lenta capturando o movimento sereno."
"Estilo Studio Ghibli. Uma pequena vila ao pôr do sol, lanternas brilhando suavemente sob os beirais de casas de madeira. Um menino jovem em um yukata azul corre por um caminho estreito de pedra, suas sandálias batendo no chão enquanto persegue um vaga-lume. Sua expressão animada reflete no rio cintilante ao seu lado. A atmosfera é rica em laranjas quentes e azuis frios, evocando uma noite de verão pacífica. Plano médio com um movimento de rastreamento suave seguindo os passos enérgicos do menino."
"Estilo Studio Ghibli. Uma floresta mística banhada por névoa matinal, onde árvores imponentes arqueiam sobre um caminho coberto de musgo. Uma garota com um manto verde simples coloca gentilmente sua mão nas costas de uma criatura enorme e dócil, parecida com um cervo antigo. Sua pelagem brilha levemente enquanto a luz do sol penetra pela densa copa, iluminando o pólen que flutua. A câmera dá um zoom lento, enfatizando a conexão silenciosa entre eles. Uma brisa suave agita as folhas, e pequenos espíritos luminosos espreitam atrás das raízes."

Instruções:
Eu agora fornecerei um prompt para você reescrever. Por favor, expanda e refine-o em inglês garantindo que adira à estética Studio Ghibli. Mesmo que a entrada seja uma instrução e não uma descrição, reescreva-a em um prompt completo e visualmente rico sem respostas adicionais ou aspas.

O prompt é: "YOUR PROMPT HERE".

Substitua YOUR PROMPT HERE por algo como Jovem garota loira está na montanha perto da praia sob chuva ou o que quiser.

O prompt negativo sempre inclui o mesmo texto base (mas pode ter palavras adicionais dependendo do prompt específico):

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

Conjunto de Dados

Nesta e nas próximas seções, vou falar um pouco :) Fique à vontade para pular direto e ler apenas a Conclusão, mas talvez alguém ache algumas informações úteis nesse texto longo. Então...

A etapa de seleção do conjunto de dados foi a parte mais "fácil", já que eu tenho todos os filmes Ghibli na mais alta qualidade possível e divididos em cenas - mais de 30.000 clipes em resolução 1920x1040 e alto bitrate. Eles aguardam pacientemente o dia em que farei um fine-tune completo em algum modelo de vídeo.

E eu já havia preparado cerca de 300 clipes para o treinamento da v0.7 do HV LoRA (na verdade, eu estava prestes a começar o treinamento quando Wan foi lançado). Esses clipes tinham de 65 a 129 frames, o que considero ideal para treinar HV em vídeos, todos a 24 fps. Para Wan, entretanto, queria que estivessem em uma faixa diferente de frames (não excedendo 81 frames, explicação mais adiante na seção "Treinamento"). Também precisavam estar a 16 fps. Ainda não tenho certeza completa se 16 fps estrito é necessário, mas tive problemas com HV quando os clipes estavam a 30 fps em vez dos 24 fps nativos de HV, então decidi ficar com 16 fps.

Devo mencionar que, para processar o conjunto de dados, costumo criar muitos pequenos scripts "one-time" (com a ajuda do Claude, ChatGPT e DeepSeek) - isso inclui mini-GUIs para seleção manual de vídeos, comandos únicos para dividir frames, scripts para output de várias estatísticas auxiliares, dissecar clipes por intervalos, criar buckets antecipadamente, etc. Não publico esses scripts porque são bagunçados, cheios de valores fixos e projetados para uso único. Atualmente, qualquer um pode criar scripts similares fazendo pedidos aos LLMs mencionados.

Converter todos os clipes para 16 fps reduziu a faixa de frames em cada vídeo de 65-129 para cerca de 45-88 frames, o que desorganizou os intervalos meticulosamente planejados para os buckets de frames configurados para o treinamento. Felizmente, não foi um grande problema porque eu tinha regras para selecionar vídeos para treinamento para lidar com situações assim.

Antes de tudo, a cena não deveria ter transições rápidas durante sua duração. Isso porque eu não podia prever a duração exata (em frames) dos buckets de frames que o trainer estabeleceria para o treinamento - o tamanho do modelo, VRAM e outros fatores influenciam isso. Por exemplo: poderia querer usar um clipe único de 81 frames para treinamento, mas não conseguiria pois daria erro OOM no RTX 3090. Então teria que escolher alguma estratégia de extração de frames, dependendo da qual um clipe poderia ser dividido em várias partes menores (aqui há um ótimo detalhamento das várias estratégias). E sua coerência semântica poderia ser quebrada (por exemplo, no primeiro fragmento do clipe, uma garota poderia abrir a boca, mas só com o fragmento o contexto fica ambíguo se ela vai chorar ou rir), e esse tipo de incoerência pode deixar o codificador UMT5 do Wan triste.

Outra coisa a considerar é que eu queria reutilizar as legendas para qualquer fragmento do clipe original sem precisar re-legendar ou recalcular embeddings pelo codificador de texto. Legendar vídeos leva tempo, mas se a cena muda drasticamente ao longo do clipe, a legenda original pode não servir para todos os fragmentos, reduzindo a qualidade do treinamento. Seguindo as regras "o clipe não deve conter transições rápidas de contexto" e "o clipe deve ser auto-contido, ou seja, não conter eventos que não possam ser compreendidos de dentro do próprio clipe", mesmo que o clipe fosse dividido em subfragmentos, as legendas ainda se aplicariam a cada fragmento com margem de erro aceitável.

Após a conversão, revisei todos os clipes e reduzi o total para 240 (removi alguns clipes que realmente tinham muitas transições ou eram muito estáticos), que formaram a primeira parte do conjunto de dados.

Decidi usar um conjunto misto de vídeos e imagens. A segunda parte do conjunto consistiu em 120 imagens (resolução 768x768), retiradas de screenshots de vários filmes Ghibli.

Existe uma abordagem alternativa que é treinar primeiro com imagens e depois ajustar com vídeos (foi aplicada com sucesso pelo criador de este LoRA), mas pessoalmente acho que não é tão boa quanto misturar em um único lote (embora eu não tenha números concretos para comprovar). Para sustentar minhas suposições, aqui está um excelente LoRA que usa a mesma abordagem mista de treinamento (e foi feito em GPU de 24 GB, se não me engano).

Para viabilizar o treinamento eficaz de vídeo em conjuntos mistos em GPUs consumer-level, tive que encontrar o equilíbrio entre resolução, duração e tempo de treinamento, escolhendo misturar vídeos de baixa resolução e alta duração com imagens de alta resolução - darei mais detalhes na seção Treinamento.

Considerando a legenda: as imagens para o conjunto foram reutilizadas de alguns dos meus conjuntos HV, e foram legendadas anteriormente usando meu "canivete suíço" VLM para legenda de datasets (SFW apenas), também conhecido como Qwen2-VL-7B-Instruct. Usei o seguinte prompt para legenda:

Crie uma descrição muito detalhada desta cena. Não use listas numeradas ou quebras de linha. IMPORTANTE: A descrição DEVE SEMPRE começar com a frase não alterada 'Estilo Studio Ghibli. ', seguida da sua descrição detalhada. A descrição deve 1) descrever o conteúdo principal da cena, 2) descrever o ambiente e detalhes de iluminação, 3) identificar o tipo de plano (ex: plano aéreo, close-up, plano médio, plano geral), e 4) incluir a atmosfera da cena (ex: aconchegante, tensa, misteriosa). Use este modelo OBRIGATÓRIO: 'Estilo Studio Ghibli. {Ação/Descrição do Assunto Principal}. {Detalhes do Ambiente e Iluminação}. {Estilo e Especificações Técnicas}'.

Tive dúvidas se deveria re-legendar, pois a estrutura da legenda alvo foi projetada especificamente para HunyuanVideo, e temi que Wan precisasse de abordagem totalmente diferente. Deixei como estava, e não sei se foi a decisão correta, mas, de modo geral, codificadores de texto modernos são potentes o bastante para ignorar essas limitações. Como sabemos, modelos como Flux e alguns outros podem até ser treinados sem legendas (embora eu acredite que treinar com legendas seja sempre melhor, mas só se forem relevantes para o conteúdo).

Para legendar vídeos testei vários modelos locais que legendam conteúdo de vídeo nativamente:

• CogVLM2-Video-Llama3-Chat (geralmente minha opção preferida para legendas de clipes)

• MiniCPM-V 2.6

• Apollo-LMMs-Apollo-7B-t32

• LLaVA-Onevision

• VideoChat-Flash-2B

• VideoLLaMA 3

• Ovis2-16B (este parece muito bom! Mas eu já tinha legendado o conjunto quando o encontrei, então vou usar em futuros LoRAs)

Existem mais modelos, mas estes foram os testados. Para este LoRA, acabei usando Apollo-7B. Usei este simples prompt VLM:

Crie uma descrição muito detalhada deste vídeo. IMPORTANTE: A descrição DEVE SEMPRE começar com a frase não alterada 'Estilo Studio Ghibli. ', seguida da sua descrição detalhada.

Anexo o conjunto de dados completo que usei como apêndice do modelo. Embora contenha material com direitos autorais, acredito que isso se enquadre em uso justo. Este conjunto de dados é fornecido somente para pesquisa e avaliação educacional das capacidades do modelo e para oferecer transparência sobre o processo de treinamento. Não deve ser usado para redistribuição ou exploração comercial.

Treinamento

Se alguém se interessar, aqui está a lista de treinadores que considerei para treinar o WanVideo:

• diffusion-pipe - OG do treinamento HV, mas também permite treinamento eficiente em memória Wan; guiado por config, possui GUI de terceiros e templates runpod (leia mais aqui e aqui). Eu o usei exclusivamente para HV. Requer WSL no Windows.

• Musubi Tuner - Mantido por desenvolvedor responsável e amigável. Guiado por config, tem comunidade acolhedora, muitas opções. Minha escolha atual para treinamento Wan.

• AI Toolkit - Meu treinador favorito para Flux recebeu suporte para Wan recentemente. É rápido, fácil de usar, guiado por config, também tem UI oficial (que não uso 🤷), mas atualmente suporta treino só para 14B sem legendas, razão principal para não utilizá-lo.

• DiffSynth Studio - Ainda não tive tempo de testar e não sei se pode treinar modelos Wan com 24 GB VRAM. Mas é mantido pela ModelScope, vale conferir. Pretendo testar em breve.

• finetrainers - Tem suporte para treino Wan, mas parece não funcionar com GPUs de 24 GB (ainda)

• SimpleTuner - Ganhou suporte para Wan na semana passada, ainda não testei. Merece atenção pois o principal dev é realmente apaixonado e conhecedor.

• Zero-to-Wan - Suporta treino apenas para modelos 1.3B.

• WanTraining - Preciso mencionar este projeto, apoiado por um dev que fez trabalhos impressionantes, incluindo LoRA guidada por distilação e LoRA de controle.

Então, usei o Musubi Tuner. Para referência, hardware: i5-12600KF, RTX 3090, Windows 11, 64Gb RAM. Os comandos e arquivos de config foram os seguintes.

• Para cachear latentes do VAE (comando padrão, nada específico)

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

• Para cachear embeddings do codificador de texto (padrão):

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 

• Para iniciar o treinamento:

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

Novamente, nada de mais aqui. Precisei usar o parâmetro blocks_to_swap porque, caso contrário, com minha config do dataset (abaixo), enfrentaria limitações de 24 Gb VRAM. Os hiperparâmetros foram maiormente mantidos nos padrões. Não quis arriscar após uma má experiência - 60 horas de treino HV perdidas por ser ambicioso demais com valores de flow shift e otimizadores adaptativos em vez do bom e velho adamw.

• Arquivo de prompts para amostragem durante o treinamento:

# prompt 1
Estilo Studio Ghibli. Mulher com cabelo loiro caminhando na praia, câmera dá zoom out.  --w 384 --h 384 --f 45 --d 7 --s 20

# prompt 2
Estilo Studio Ghibli. Mulher dançando no bar. --w 384 --h 384 --f 45 --d 7 --s 20

• Configuração do conjunto de dados (a parte mais importante; explicarei depois os pensamentos que me levaram a ela):

[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

Minha configuração do conjunto de dados é composta por três partes.

Começarei pela última, que inclui o principal conjunto de dados - 240 clipes em resolução 1920x1040 e duração variando de 45 a 88 frames.

Obviamente, treinar com clipes em resolução total 1920x1040 e duração completa em RTX 3090 estava fora de questão. Precisava encontrar a resolução e duração mínima que evitassem erros OOM mantendo os fragmentos de bucket o mais longos possível. Fragmentos mais longos ajudam o modelo a aprender movimento, temporização e padrões espaciais (como mexer de cabelo, balanço de tecido, dinâmica de líquidos etc) do estilo Ghibli - algo que não se consegue com frames fixos.

Do treinamento HV, lembro que um bom ponto inicial para estimar resolução em GPU de 24 Gb é 512x512x33. Decidi pelo padrão de extração de frames "uniforme", garantindo que todos os fragmentos extraídos tivessem no mínimo 45 frames. Como, após conversão para 16fps, o máximo eram 88 frames, essa abordagem evitou dividir os clipes em mais de dois fragmentos, o que deixaria as épocas muito longas. Ao mesmo tempo, 45 frames (~3s) são suficientes para o modelo aprender o fluxo espacial do estilo.

Com o alvo fixado em 45 frames, comecei a testar várias resoluções. Usei um script para analisar todos os clipes em uma pasta e sugerir combinações válidas de largura-altura mantendo a proporção original (1920/1040 ≈ 1.85) e múltiplos de 16 (uma exigência do modelo).

Por fim, descobri que usar [384, 208] para o tamanho do bucket e configurar --blocks_to_swap 10 evitava erros OOM e uso da memória compartilhada (que causava tempo 160 s/it). A desvantagem foi que a velocidade de treinamento caiu para cerca de 11-12 s/it. Em retrospecto, reduzir para [368, 192] poderia aumentar a velocidade para ~8 s/it, o que seria ótimo (próximo do que obtenho treinando Flux em 1024p com AI Toolkit). E isso teria salvo cerca de 20 horas de treino nas 90 horas totais (~28000 passos), embora eu não esperasse ultrapassar 20K passos na época.

Deve-se notar que treinei no Windows com meu monitor conectado à GPU (e ao mesmo tempo usava o PC para programar 😼). Em Linux (por exemplo, com diffusion-pipe) e usando GPU interna para saída do monitor, pode ser possível usar resoluções espaciotemporais um pouco maiores sem problemas de OOM ou memória compartilhada (algo que acredito ser específico do Windows).

Agora sobre a primeira parte (120 imagens em resolução 768x768). Inicialmente queria treinar com imagens 1024p, mas achei exagerado e lento. Meu plano era treinar simultaneamente em imagens HD e vídeos de baixa resolução para garantir melhor generalização. A ideia é que as imagens de alta resolução compensariam a menor resolução dos clipes. Treinar combinado vídeo + imagem é como WAN foi treinado mesmo, então imaginei que essa abordagem favoreceria o aprendizado upstream do estilo.

Por fim, a segunda parte, também importante para generalização (novamente, não é uma suposição “científica”, mas parece razoável). A ideia era reutilizar os mesmos clipes da terceira seção, mas agora treinar apenas o primeiro frame e os primeiros 21 frames. Essa abordagem, esperava, facilitaria o aprendizado das características de movimento temporal do estilo. Ao mesmo tempo, permitiu aumentar a resolução para a segunda seção para [768, 416].

Como resultado, esperava alcançar "cross-generalização" entre:

• Seção 1 com imagens de alta resolução (768x768)

• Seção 2 com frames únicos e clipes de 21 frames em resolução média (768x416)

• Seção 3 com clipes de 45 frames e baixa resolução (384x208)

Além disso, tanto a segunda quanto a maior parte da terceira seção compartilhavam o mesmo frame inicial, o que eu acreditava beneficiar o uso do LoRA em cenários I2V. Tudo isso parecia a melhor forma de usar todo o conjunto sem atingir limites de hardware.

Claro, não fui o primeiro a usar essa abordagem, mas parece lógica e espero que mais criadores percebam que você não precisa de uma A100 para treinar um LoRA baseado em vídeo para Wan.

Curiosidade: esperava uma época com 1080 amostras: 120 imagens (seção 1) + 240 frames únicos (seção 2, bucket "head"=1) + 240 clipes de 21 frames cada (seção 2, bucket "head"=21) + 480 clipes de 45 frames cada (seção 2, bucket "uniform"=45, amostrados 2 vezes). Porém, ao iniciar o treinamento, descobri que eram, na verdade, 1078 amostras. Ao investigar, descobri que dois clipes contados pelos meus scripts (que usam ffprobe do ffmpeg para contar frames) eram mais curtos que 45 frames, havia um problema de arredondamento. Isso não foi um grande problema, continuei sem esses dois, mas foi o motivo pelo qual o número de passos do LoRA final parecia estranho :)

O treinamento em si foi tranquilo. Não vou mostrar gráficos de perda pois sou tímido não acho que sejam muito úteis. Eu os uso principalmente para verificar se a distribuição das perdas começa a ficar muito parecida entre as épocas - sinal de possível overfitting.

Treinei até 28000 passos, depois passei alguns dias escolhendo o melhor checkpoint. Outra coisa que acho que poderia ter feito melhor foi salvar checkpoints não apenas no fim de cada época, mas também no meio delas. Como cada época tem 1078 passos, é possível que um checkpoint com resultados ainda melhores tenha sido perdido no meio do caminho.

Estou pensando em integrar estimativa de perda de validação ao meu pipeline de treinamento (mais sobre isso aqui), mas ainda não fiz.

Será que isso poderia ser simplificado? Provavelmente sim. No meu próximo LoRA, vou testar se a seção extra de imagens era redundante. Eu poderia ter criado uma seção separada de conjunto de dados e reutilizado o primeiro frame dos clipes, mas em alta resolução. Por outro lado, queria que o conjunto fosse o mais variado possível, então usei screenshots de cenas diferentes das dos clipes, nesse sentido, não eram redundantes.

Nem tenho certeza se a segunda seção era necessária. Já que o WAN (segundo seu relatório técnico) foi pré-treinado em clipes 192px, treinar por volta de 352x192x45 deveria ser eficaz e tirar o máximo proveito do hardware. Idealmente, usaria clipes de 5 segundos (16 fps * 5s + 1 = 81 frames), mas isso não é viável na RTX 3090 sem trocar blocos agressivamente.

Conclusão

Além da diversão e dos milhares centenas de clipes incríveis, aqui estão alguns insights que ganhei ao treinar este LoRA. Devo mencionar que essas práticas se baseiam na minha experiência pessoal e observações, não tenho evidências estritamente analíticas para comprovar a eficácia, e só testei treinamento de estilo até agora. Pretendo explorar treinamento de conceito em breve para testar outras suposições e ver se podem ser aplicadas também.

• Você pode treinar Wan-14B em GPUs consumer-level usando vídeos. 368x192x45 parece um ótimo ponto inicial.

• Compense o aprendizado de estilo focado em movimento em vídeos de baixa resolução usando imagens de alta resolução para melhor generalização.

• Combine vários métodos de extração de frames nos mesmos conjuntos para maximizar eficiência e uso de hardware.

Muito, senão tudo, do que aprendi para fazer este LoRA veio de ler inúmeros posts no r/StableDiffusion, ficar 24/7 no incrível Discord Banodoco, ler comentários e abrir cada clipe NSFW de todo modelo WanVideo aqui no Civitai, e mergulhar em todas as issues que encontrei nos repositórios musubi-tuner, diffusion-pipe, Wan2.1 e outros. 😽

P.S.

Este modelo é uma vitrine tecnológica das capacidades dos sistemas modernos de geração de vídeo. Não tem intenção de prejudicar ou infringir direitos dos criadores originais. Serve como tributo ao trabalho notável dos artistas cujas criações inspiraram este modelo.