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

Este LoRA está destacado en OpenMuse, una iniciativa seleccionada dedicada a LoRAs de video de código abierto y las obras creativas que permiten. Centrado en modelos como Wan2.1, LTX-Video y HunyuanVideo, OpenMuse resalta herramientas y obras de alta calidad de todo el ecosistema. Enraizado en la comunidad Banodoco, OpenMuse es un hogar en crecimiento para arte de IA abierto y colaborativo, diseñado para inspirar a los creadores, despertar curiosidad y ofrecer algo que te sientas orgulloso de compartir, incluso con alguien escéptico del arte generado por IA.

Descripción

Estoy muy feliz de compartir mi magnum opus LoRA, en la que he estado trabajando durante el último mes desde que salió Wan. Este es, sin duda, el mejor LoRA en Civitai que he entrenado, y debo decir (una vez más) que WanVideo es un modelo increíble.

El LoRA fue entrenado durante ~90 horas en una RTX 3090 con musubi-tuner usando un conjunto mixto de 240 clips y 120 imágenes. Esto podría haberse hecho más rápido, pero estaba obsesionado con llevar los límites para crear un modelo de estilo de última generación. Depende de ti juzgar si lo logré.

Uso

La frase desencadenante es estilo Studio Ghibli - todos los subtítulos de los datos de entrenamiento tenían estas palabras como prefijo.

Todos los clips que publico en la galería son salidas sin procesar usando un LoRA con un modelo base Wan-T2V-14B (aunque los videos más recientes también pueden incluir LoRA de auto-forzamiento para acelerar la inferencia, lee más abajo), sin procesamiento posterior, escalado o interpolación.

No se ha probado la compatibilidad con otros LoRAs ni con modelos Wan-I2V.

Los flujos de trabajo están embebidos con cada video (para que puedas simplemente descargar y arrastrar el video a ComfyUI para abrirlo). Como ejemplo, aquí está el JSON para flujo de trabajo (basado en el wrapper de Kijai), que usa el LoRA de auto-forzamiento (creado por blyss), extraído del modelo Wan2.1-T2V-14B-StepDistill-CfgDistill de lightx2v. Elegí la versión hecha por blyss (y no el LoRA original de Kijai), porque, según mis pruebas, ofrece máxima compatibilidad y solo acelera la inferencia, sin detallados adicionales o sesgos estilísticos. (Esta es también la razón por la cual me mantengo con el modelo base Wan y no uso merges como AniWan o FusionX.)

Uso el LoRA acelerador con el muestreador UniPC (y ocasionalmente DPM++). En mi experiencia, UniPC funciona mejor para animación 2D que LCM, que tiende hacia el realismo, algo que quiero evitar. Usualmente también aplico nodo NAG para usar prompts negativos con CFG=1. Según pruebas iniciales, comparado con el flujo de trabajo más antiguo con TeaCache, además de la gran ganancia de velocidad (un clip de 640×480×81 de 6 pasos se renderiza en ~1 minuto en lugar de 6 en una RTX 3090), también mejora ligeramente la suavidad del movimiento y el renderizado de texto.

Los LoRAs actualizados de lightx2v son también muy impresionantes en velocidad y conservación de calidad. Estoy usando un LoRA rango 128, pero las versiones de 32 y 64 también producen excelentes resultados. Aquí un ejemplo del flujo en formato JSON. Descubrí que bajar la fuerza del LoRA lightx2v a 0.9, aumentar el número de pasos a 8 y usar el planificador UniPC o DPMPP da resultados muy buenos.

Y aquí está el flujo de trabajo "legacy" en formato JSON. Fue usado para generar el 90 % de los videos en la galería para este LoRA. También fue construido sobre nodos wrapper e incluye muchas optimizaciones (más información aquí), incluyendo checkpoints fp8_e5m2 + torch.compile, SageAttention 2, TeaCache, Enhance-A-Video, Fp16_fast, SLG y (a veces) Zero-Star (algunos de estos también migraron al nuevo flujo), pero renderizar un clip de 640x480x81 todavía tomaba cerca de 5 minutos (RTX 3090) en el flujo antiguo. Aunque el flujo legacy muestra una calidad ligeramente superior en algunas áreas específicas (paleta, suavidad), el retraso de 5x es una desventaja significativa y decisiva, siendo esta la razón por la que migré a la versión potenciada por lightx2v.

Prompts

Para generar la mayoría de los prompts, usualmente aplico el siguiente meta-prompt en ChatGPT (o Claude, o cualquier otro LLM capacitado), que ayuda a enriquecer descripciones "en bruto". Este prompt está basado en el código oficial de extensión de prompts por los desarrolladores de Wan y se ve así:

Eres un ingeniero de prompts, especializado en refinar entradas de usuario en prompts de alta calidad para generación de video en el estilo distintivo de Studio Ghibli. Aseguras que la salida se alinee con la intención original mientras enriqueces detalles para claridad visual y de movimiento.

Requisitos de la tarea:
- Si la entrada del usuario es muy breve, amplíala con detalles razonables para crear una escena más vívida y completa sin alterar el significado central.
- Enfatiza características clave como apariencias, expresiones, ropa, posturas y relaciones espaciales de los personajes.
- Siempre mantiene la estética visual de Studio Ghibli - fondos suaves tipo acuarela, diseños expresivos pero simples de personajes, y una atmósfera cálida y nostálgica.
- Mejora descripciones de movimientos y movimientos de cámara para un flujo de animación natural. Incluye movimientos suaves y orgánicos que coincidan con el estilo narrativo de Ghibli.
- Conserva el texto original en comillas o títulos mientras aseguras que el prompt sea claro, inmersivo, y tenga entre 80 y 100 palabras.
- Todos los prompts deben comenzar con "estilo Studio Ghibli." No se deben usar otros estilos artísticos.

Ejemplos de prompts revisados:
"Estilo Studio Ghibli. Una joven con cabello corto y castaño y ojos curiosos está en una colina cubierta de hierba iluminada por el sol, el viento mueve suavemente su vestido blanco simple. Observa un grupo de pájaros que vuelan por el cielo dorado, sus pies descalzos se hunden ligeramente en la tierra blanda. La escena está bañada en luz cálida y nostálgica, con árboles frondosos moviéndose a lo lejos. Una brisa suave lleva los sonidos de la naturaleza. Plano medio, ángulo ligeramente bajo, con un paneo cinematográfico lento que captura el movimiento sereno."
"Estilo Studio Ghibli. Un pequeño pueblo al atardecer, faroles que brillan suavemente bajo los aleros de las casas de madera. Un niño con yukata azul corre por un camino estrecho de piedra, sus sandalias hacen ruido al perseguir a una luciérnaga. Su expresión emocionada se refleja en el río brillante a su lado. La atmósfera está llena de naranjas cálidos y azules fríos, evocando una tranquila noche de verano. Plano medio con un movimiento de seguimiento suave que sigue los enérgicos pasos del niño."
"Estilo Studio Ghibli. Un bosque místico bañado en la niebla matinal, donde árboles imponentes arquean sobre un camino cubierto de musgo. Una chica con una capa verde simple coloca suavemente su mano en la espalda de una criatura enorme de ojos gentiles que parece un ciervo antiguo. Su pelaje brilla débilmente mientras la luz del sol atraviesa el denso dosel, iluminando el polen en suspensión. La cámara hace un zoom lento, enfatizando su conexión tranquila. Una brisa suave mueve las hojas y diminutos espíritus brillantes asoman detrás de las raíces."

Instrucciones:
Ahora te proveeré un prompt para que reescribas. Por favor, amplíalo y refínalo en inglés mientras aseguras que se adhiera a la estética de Studio Ghibli. Aunque la entrada sea una instrucción en lugar de una descripción, reescríbela en un prompt completo, visualmente rico, sin respuestas adicionales ni comillas.

El prompt es: "YOUR PROMPT HERE".

Reemplaza YOUR PROMPT HERE con algo como Joven rubia está en la montaña cerca de la playa bajo la lluvia o lo que sea.

El prompt negativo siempre incluye el mismo texto base (aunque puede tener palabras adicionales según el prompt específico):

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

Conjunto de datos

En esta y las siguientes secciones, voy a hablar un poco :) Siéntete libre de saltar y solo leer la Conclusión, pero tal vez alguien encuentre información útil en este texto. Entonces...

La selección del conjunto fue la parte "más fácil", ya tengo todas las películas de Ghibli en la mejor calidad posible divididas en escenas: más de 30,000 clips en resolución 1920x1040 y alto bitrate. Están esperando pacientemente el día en que finalmente haga un fine-tune completo de algún modelo de video con ellas.

También había preparado alrededor de 300 clips para entrenar la v0.7 del HV LoRA (de hecho, estaba por empezar el entrenamiento cuando salió Wan). Estos clips tenían entre 65 y 129 frames, que considero óptimo para entrenar HV en videos, y todos eran a 24 fps. Para Wan, quería que estuvieran en un rango diferente (no superar los 81 frames, ver explicación en "Entrenamiento" más adelante). También necesitaba que fueran a 16 fps. Todavía no estoy del todo seguro si 16 fps estrictos es necesario, pero tuve algunos problemas con HV cuando clips eran a 30 fps en lugar del nativo 24 de HV, así que decidí mantener 16 fps.

Debo mencionar que para procesar el conjunto, suelo hacer muchos pequeños scripts "de una vez" (con ayuda de Claude, ChatGPT y DeepSeek) - incluyendo mini-GUIs para selección manual de videos, comandos para dividir cuadros, scripts para estadísticas auxiliares, disecar clips por rangos, crear buckets por adelantado, etc. No publico estos scripts porque son desordenados, con valores codificados y diseñados para un solo uso. Hoy en día cualquiera puede crear scripts similares solicitándolos a los LLM mencionados.

Convertir todos los clips a 16 fps redujo el rango de frames de 65-129 a alrededor de 45-88 frames, lo que alteró mis rangos meticulosamente planeados para buckets de cuadros para entrenamiento. Afortunadamente, no fue gran problema porque tenía reglas para seleccionar videos específicamente para manejar estas situaciones.

En primer lugar, la escena no debe tener transiciones rápidas durante su duración. Esto es porque no puedo predecir la duración exacta (en frames) de los buckets que el entrenador establecerá para el entrenamiento - tamaño del modelo, VRAM y otros factores afectan esto. Por ejemplo, podría querer usar un solo clip de 81 frames para entrenar, pero no podría hacerlo por OOM en RTX 3090. Por lo tanto, elegiré alguna estrategia de extracción de cuadros, que podría dividir el clip en partes más cortas (aquí hay un excelente desglose de diversas estrategias). Y su coherencia semántica podría romperse (por ejemplo, en el primer fragmento una chica abre la boca, pero al fragmentar el clip se vuelve ambiguo si va a llorar o reír), y esa incoherencia puede entristecer al codificador UMT5 de Wan.

Otra cosa a considerar es que quería reutilizar los subtítulos para cualquier fragmento del clip original sin recaptionar ni recachear embeddings mediante el codificador de texto. Subtitular videos toma tiempo, pero si la escena cambia drásticamente en su rango, el subtítulo no encajaría en todos los fragmentos y disminuiría la calidad. Siguiendo las reglas "el clip no debe contener transiciones rápidas de contexto" y "el clip debe ser autocontenido, es decir, no debe mostrar eventos no entendibles desde dentro del clip", incluso si una escena se divide en subfragmentos, los subtítulos aplicarían (con un margen aceptable) a cada fragmento.

Tras la conversión, revisé todos los clips y reduje el total a 240 (eliminé algunos que contenían demasiadas transiciones o que, por el contrario, eran muy estáticos), formando la primera parte del conjunto.

Decidí usar un conjunto mixto de videos e imágenes. La segunda parte se formó con 120 imágenes (a resolución 768x768), tomadas de capturas de pantalla de varias películas de Ghibli.

Existe un enfoque alternativo donde primero entrenas con imágenes y luego haces fine-tune con videos (aplicado con éxito por el creador de este LoRA), pero personalmente creo que no es tan bueno como mezclar en un solo batch (aunque no tengo datos duros que lo respalden). Para apoyar mis suposiciones, aquí hay un muy buen LoRA que usa el mismo método mixto para entrenamiento (y por cierto también se hizo en una GPU de 24 GB, si no me equivoco).

Para habilitar un entrenamiento efectivo en videos en GPUs convencionales tuve que encontrar el balance correcto entre resolución, duración y tiempo de entrenamiento, decidiendo mezclar videos de baja resolución y alta duración con imágenes de alta resolución - daré más detalles en la sección Entrenamiento.

Sobre los subtítulos: las imágenes para el conjunto fueron reutilizadas de algunos de mis datasets HV, y ya estaban subtituladas usando mi "navaja suiza" VLM para subtitulado de conjuntos SFW, conocido como Qwen2-VL-7B-Instruct. Usé este prompt para subtitulado:

Crea una descripción muy detallada de esta escena. No uses listas numeradas ni saltos de línea. IMPORTANTE: La descripción debe comenzar SIEMPRE con la frase sin alterar 'estilo Studio Ghibli. ', seguida por tu descripción detallada. La descripción debe 1) describir el contenido principal, 2) describir detalles de ambiente e iluminación, 3) identificar el tipo de toma (e.g., aérea, primer plano, plano medio, plano largo), y 4) incluir la atmósfera de la escena (e.g., acogedora, tensa, misteriosa). Usa esta plantilla obligatoriamente: 'estilo Studio Ghibli. {Acción/Descripción principal}. {Detalles de ambiente e iluminación}. {Estilo y especificaciones técnicas}'.

Tuve dudas sobre recaptionar porque la estructura objetivo fue diseñada para HunyuanVideo, y temía que Wan necesitara un enfoque distinto. Los dejé tal cual, sin embargo, los codificadores de texto modernos son suficientemente poderosos para ignorar tales limitaciones. Como sabemos, modelos como Flux y otros pueden incluso entrenarse sin subtítulos (aunque creo que entrenar con subtítulos siempre es mejor, pero solo si son relevantes para el contenido).

Para subtitular videos probé varios modelos locales que pueden subtitular video nativamente:

• CogVLM2-Video-Llama3-Chat (mi opción preferida para subtitular clips)

• MiniCPM-V 2.6

• Apollo-LMMs-Apollo-7B-t32

• LLaVA-Onevision

• VideoChat-Flash-2B

• VideoLLaMA 3

• Ovis2-16B (¡este parece realmente bueno! Pero ya tenía el conjunto subtitulado al encontrarlo, así que lo usaré en futuros LoRAs)

Hay más modelos, pero estos son los que probé. Para este LoRA, terminé usando Apollo-7B. Usé este simple prompt VLM:

Crea una descripción muy detallada de este video. IMPORTANTE: La descripción debe comenzar SIEMPRE con la frase sin alterar 'estilo Studio Ghibli. ', seguida por tu descripción detallada.

Adjunto el conjunto completo usado como anexo del modelo. Aunque contiene material con derechos de autor, creo que entra en uso justo. Este conjunto se ofrece solo para investigación y evaluación educativa de las capacidades del modelo y para ofrecer transparencia sobre el proceso de entrenamiento. No debe usarse para redistribución ni explotación comercial.

Entrenamiento

Si a alguien le interesa, aquí está la lista de entrenadores que consideré para entrenar WanVideo:

• diffusion-pipe - OG del entrenamiento HV, pero también permite entrenamiento Wan eficiente en memoria; basado en configuraciones, tiene GUI de terceros y plantillas runpod (más info aquí y aquí). Para HV lo usé exclusivamente. Requiere WSL para correr en Windows.

• Musubi Tuner - Mantenido por un desarrollador responsable y amigable. Basado en configuraciones, con una comunidad acogedora y muchas opciones. Actualmente mi elección para entrenar Wan.

• AI Toolkit - Mi entrenador favorito para Flux recientemente agregó soporte para Wan. Es rápido, fácil de usar, basado en configuraciones, también tiene UI oficial (que no uso 🤷), pero actualmente solo soporta entrenamiento 14B sin subtítulos, lo cual es la razón principal para no usarlo.

• DiffSynth Studio - No he tenido tiempo para probarlo todavía y no sé si puede entrenar Wan con 24 GB VRAM. Sin embargo, está mantenido por ModelScope, valdría la pena revisarlo. Planeo probarlo pronto.

• finetrainers - Tiene soporte para entrenamiento Wan, pero no parece funcionar con GPUs de 24 GB (aún)

• SimpleTuner - Obtuvo soporte para Wan la semana pasada, así que no he tenido chance de probarlo. Sin duda merece atención ya que el desarrollador principal es muy apasionado y conocedor.

• Zero-to-Wan - Soporta solo entrenamiento para modelos de 1.3B.

• WanTraining - Menciono este proyecto porque está soportado por un desarrollador que ha hecho un gran trabajo, incluyendo LoRA distilado con guía y LoRA de control.

Entonces, uso Musubi Tuner. Como referencia, estos son mis parámetros de hardware: i5-12600KF, RTX 3090, Windows 11, 64Gb RAM. Los comandos y archivos de configuración que usé fueron los siguientes.

• Para cacheo de latentes VAE (sin nada específico, comando por defecto)

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 cacheo de embeddings del codificador de texto (por defecto):

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 lanzar el entrenamiento:

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

De nuevo, nada fuera de lo común. Tuve que usar el parámetro blocks_to_swap porque, de lo contrario, con mi configuración de dataset (ver más abajo) enfrentaba limitaciones de 24 Gb VRAM. Los hiperparámetros quedaron mayormente por defecto. No quise arriesgar tras una mala experiencia - 60 horas de entrenamiento HV perdidas por ser demasiado ambicioso con valores flow shift y optimizadores adaptativos en lugar del buen adamw clásico.

• Archivo de prompts para muestras durante el entrenamiento:

# prompt 1
Estilo Studio Ghibli. Mujer rubia camina en la playa, zoom de cámara hacia afuera.  --w 384 --h 384 --f 45 --d 7 --s 20

# prompt 2
Estilo Studio Ghibli. Mujer bailando en el bar. --w 384 --h 384 --f 45 --d 7 --s 20

• Configuración del dataset (la parte más importante; luego explicaré el razonamiento):

[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

Mi configuración de dataset tiene tres partes.

Comenzaré con la última, que incluye el conjunto principal de datos - 240 clips en resolución 1920x1040 con duración de 45 a 88 frames.

Obviamente, entrenar videos completos en 1920x1040 en una RTX 3090 era inviable. Necesitaba encontrar la resolución mínima y duración de clips para evitar errores OOM, manteniendo los fragmentos lo más largos posible. Fragmentos largos ayudan al modelo a aprender el movimiento, el tiempo y patrones espaciales (movimiento de cabello, telas, dinámica de líquidos, etc.) del estilo Ghibli – algo inalcanzable con cuadros fijos.

Del entrenamiento de HV recordaba que un buen punto inicial para estimar resolución disponible en GPU de 24 Gb es 512x512x33. Elegí el patrón "uniform" para extracción de cuadros, asegurando fragmentos extraídos no fueran menores a 45 frames. Dado que, como mencioné, tras convertir a 16 fps el máximo fue 88 frames, esto evitó dividir clips en más de dos partes, lo cual habría alargado las épocas demasiado. Al mismo tiempo, 45 frames (~3s) deberían ser suficientes para que el modelo aprenda flujo espacial del estilo.

Con objetivo fijo en 45 frames, probé diferentes resoluciones. Usé un script para analizar todos los clips en una carpeta y sugerir combinaciones válidas de ancho-alto que mantuvieran la relación de aspecto original (1920/1040 ≈ 1.85) y fueran divisibles por 16 (un requisito del modelo).

Finalmente, encontré que usar [384, 208] como tamaño del bucket y poner --blocks_to_swap 10 evitaba errores OOM y push a memoria compartida (que generaba 160 s/it). La desventaja fue que la velocidad bajó a ~11-12 s/it. Luego supe que bajar resolución a [368, 192] hubiera aumentado la velocidad a ~8 s/it, lo que habría sido genial (similar a entrenar Flux a 1024p en AI Toolkit). Esto me habría ahorrado 20 horas de entrenamiento en las 90 horas totales (~28000 pasos), aunque no esperaba superar 20K pasos entonces.

Y hay que notar que entrené en Windows con mi monitor conectado a la GPU (y usaba mi PC para programar 😼). En Linux (por ejemplo con diffusion-pipe) y usando la GPU interna para salida de monitor, podría ser posible usar resoluciones espacio-temporales un poco mayores sin errores OOM o limitaciones de memoria compartida (creo que es algo específico de Windows).

Ahora sobre la primera parte (120 imágenes a 768x768). Inicialmente quería entrenar en imágenes 1024p, pero decidí que sería exagerado y ralentizaría todo. Mi plan era entrenar imágenes en HD y videos en baja resolución simultáneamente para asegurar mejor generalización. La idea era que imágenes en alta resolución compensaran la baja resolución de los clips. Además, el preentrenamiento combinado video + imagen es como WAN fue entrenado, así que pensé que beneficiaría el aprendizaje de estilo "ascendente".

Finalmente, la segunda parte, también importante para generalización (aunque es una suposición no tan "científica", parece razonable). La idea era reutilizar los mismos clips de la tercera sección, pero entrenar sólo en el primer cuadro y los primeros 21 cuadros. Esperaba con esto facilitar el aprendizaje de características de movimiento temporal del estilo. A la vez, permitió aumentar la resolución para la segunda sección a [768, 416].

Como resultado, esperaba lograr "generalización cruzada" entre:

• Sección 1 imágenes en alta resolución (768x768)

• Sección 2 cuadros individuales de resolución media y clips de 21 cuadros (768x416)

• Sección 3 clips en baja resolución de 45 cuadros (384x208)

Además, la segunda y la mayor parte de la tercera sección compartían el mismo cuadro inicial, lo que creía beneficiaría el uso del LoRA en escenarios I2V. Todo esto parecía la mejor forma de usar mi conjunto sin superar límites de hardware.

Por supuesto, no soy el primero en usar este enfoque, pero es lógico y espero que más creadores comprendan que no se necesita una A100 para entrenar un LoRA basado en video para Wan.

Dato curioso: esperaba que una época consistiera en 1080 muestras: 120 imágenes (1ª sección del dataset) + 240 cuadros individuales (2ª sección, bucket "head"=1) + 240 clips de 21 cuadros (2ª sección, bucket "head"=21) + 480 clips de 45 cuadros (2ª sección, bucket "uniform"=45, muestreados 2 veces). Pero tras empezar a entrenar, descubrí que eran 1078 muestras. Investigando encontré que dos clips reportados por mis scripts (que usan ffprobe de ffmpeg para contar cuadros) eran realmente menos de 45 frames, por un problema de redondeo. No fue grave, así que continué sin esos dos clips, pero esa es la razón por la que el número de pasos del LoRA final parecía raro :)

El entrenamiento fue fluido. No mostraré gráficas de pérdida porque soy demasiado tímido no creo que tengan mucho significado. Usualmente las uso para ver si la distribución de pérdidas empieza a parecerse mucho entre épocas, señal de sobreajuste posiblemente.

Entrené hasta 28000 pasos y luego pasé varios días seleccionando el mejor checkpoint. Otra cosa que creo podría haber hecho mejor es tomar checkpoints no solo al final de época, sino también intermedios. Cada época tiene 1078 pasos, es posible que un checkpoint aún mejor se haya perdido en medio.

Estoy considerando integrar estimación de pérdida de validación en mi pipeline de entrenamiento (más info aquí), pero aún no lo hago.

¿Se podría simplificar esto? Probablemente sí. En mi próximo LoRA probaré si la sección de imágenes extra fue redundante. Podría haber sólo configurado una sección separada del dataset y reutilizado el primer frame de clips pero con alta resolución. Por otro lado, quería que el dataset fuera lo más variado posible, así que usé capturas de escenas distintas a los clips, por lo que no fueron redundantes.

No estoy seguro ni siquiera si la segunda sección fue necesaria. WAN mismo (según su informe técnico) fue preentrenado en clips de 192px, entrenar con aprox. 352x192x45 debería ser efectivo y aprovechar al máximo mi hardware. Idealmente usaría clips de 5 segundos (16 fps * 5s + 1 = 81 frames), pero eso no es factible en RTX 3090 sin swap agresivo de bloques.

Conclusión

Aparte de la diversión y los cientos miles de clips increíblemente buenos, aquí algunos conocimientos obtenidos entrenando este LoRA. Debo mencionar que estas prácticas son basadas en experiencia y observación personal, no tengo evidencia analítica estricta y sólo he probado entrenamiento de estilo hasta ahora. Planeo explorar pronto entrenamiento por concepto para probar otras suposiciones y ver si aplican también.

• Se puede entrenar Wan-14B en GPUs convencionales usando videos. 368x192x45 parece un buen punto de partida.

• Compensa el aprendizaje de estilo basado en movimiento en videos de baja resolución con imágenes en alta resolución para mejor generalización.

• Combina distintos métodos de extracción de cuadros en el mismo dataset para maximizar efectividad y uso de hardware.

Mucho, si no todo, lo que aprendí para hacer este LoRA viene de leer innumerables publicaciones en r/StableDiffusion, acechar 24/7 en el genial Discord Banodoco, leer comentarios y abrir cada clip NSFW para cada modelo WanVideo aquí en Civitai, y sumergirme en cada issue encontrado en musubi-tuner, diffusion-pipe, Wan2.1 y otros repositorios. 😽

P.D.

Este modelo es una muestra tecnológica de las capacidades de los sistemas modernos de generación de video. No tiene intención de dañar o infringir derechos de los creadores originales. Más bien, sirve como tributo al trabajo notable de los artistas cuyas creaciones inspiraron este modelo.