Studio Ghibli 🎥 Wan2.1-T2V-14B

이 LoRA는 _OpenMuse_에서 추천되었습니다. _OpenMuse_는 오픈소스 비디오 LoRA 및 이를 통해 가능해지는 창작물을 중심으로 한 기획 프로젝트입니다. Wan2.1, LTX-Video, HunyuanVideo와 같은 모델에 집중하며, _OpenMuse_는 생태계 전반에서 나오는 고품질 도구와 예술 작품을 조명합니다. Banodoco 커뮤니티를 기반으로 하는 _OpenMuse_는 개방적이고 협업적인 AI 예술을 위한 성장 중인 공간으로, 창작자들을 영감을 주고 호기심을 자극하며, AI 생성 아트에 회의적인 사람에게도 자랑스럽게 공유할 수 있는 작품을 제공하도록 설계되었습니다.

설명

Wan이 출시된 이래로 지난 한 달 동안 제작해 온 제 거작 LoRA를 공유하게 되어 매우 기쁩니다. 이 LoRA는 제가 지금까지 Civitai에서 훈련한 최고의 LoRA이며, 다시 한번 말해야 합니다 — WanVideo는 놀라운 모델입니다.

이 LoRA는 RTX 3090과 musubi-tuner를 사용해 240개의 클립과 120개의 이미지로 구성된 혼합 데이터셋을 기반으로 약 90시간 동안 훈련되었습니다. 더 빠르게 할 수도 있었지만, _최신 수준_의 스타일 모델을 만들기 위해 한계를 밀어붙이는 데 집착했습니다. 제가 성공했는지는 여러분의 판단에 달려 있습니다.

사용법

트리거 문구는 Studio Ghibli style입니다. 훈련 데이터의 모든 캡션은 이 단어로 시작됩니다.

갤러리에 게시한 모든 클립은 기본 모델로 Wan-T2V-14B를 사용한 LoRA의 원본 출력입니다(최신 영상은 추론 가속을 위한 자기 강제 LoRA를 포함할 수 있음, 아래 참고). 추가적인 후처리, 업스케일링, 보간은 적용하지 않았습니다.

다른 LoRA 및 Wan-I2V 모델과의 호환성은 테스트되지 않았습니다.

작업 흐름은 각 영상에 내장되어 있습니다(ComfyUI에 영상을 드래그하여 바로 열 수 있음). 예시로, 이 JSON은 Kijai의 랩퍼를 기반으로 한 작업 흐름이며, 자기 강제 LoRA(blyss가 생성)를 사용합니다. 이 LoRA는 lightx2v의 Wan2.1-T2V-14B-StepDistill-CfgDistill 모델에서 추출되었습니다. 저는 Kijai의 원본 LoRA가 아닌 blyss가 만든 버전을 선택했습니다. 저의 테스트 결과에 따르면, 이 버전이 최대한의 호환성을 제공하며 추가적인 디테일이나 스타일적 편향 없이 단순히 추론 속도만 가속하기 때문입니다. (이것이 제가 기본 Wan 모델에 고집하고 AniWan이나 FusionX 같은 병합 모델을 사용하지 않는 이유이기도 합니다.)

저는 UniPC 샘플러(가끔 DPM++)와 가속 LoRA를 사용합니다. 제 경험에 따르면, UniPC는 LCM보다 2D 애니메이션에 더 나은 성능을 보입니다. 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 등 많은 최적화를 포함하고 있었습니다(이 중 일부는 새 작업 흐름으로 이전됨). 그러나 이전 작업 흐름에서는 640x480x81 클립을 렌더링하는 데 약 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

데이터셋

이후 섹션에서 잠시 말이 많아질 예정입니다 :) 빠르게 결론만 읽으셔도 좋지만, 이 긴 텍스트 중 유용한 정보도 있을 수 있습니다. 그러니...

데이터셋 선택 단계는 가장 "쉬운" 부분이었습니다. 이미 모든 기브리 영화를 최고 품질로 보유하고 있으며, 장면 단위로 분할했습니다. 해상도 1920x1040, 고비트레이트로 총 30,000개 이상의 클립이 있습니다. 이 클립들은 언젠가 제가 이 데이터로 완전한 비디오 모델을 미세 조정할 날을 기다리고 있습니다.

또한, 이전에 HV LoRA의 v0.7 훈련을 위해 약 300개의 클립을 이미 준비해 뒀습니다(실제로 Wan이 출시되기 직전 훈련을 시작하려 했던 시기였죠). 이 클립들은 65~129프레임 범위였으며, HV 훈련에 최적이라고 생각한 길이였고, 모두 24fps였습니다. 그러나 Wan의 경우, 프레임 범위를 다르게 설정하고 싶었습니다(81프레임 미만, 아래 "훈련" 섹션에서 설명). 또한 16fps로 변환해야 했습니다. 저는 여전히 엄격한 16fps가 반드시 필요한지 확신하지 못합니다. 그러나 HV에서 클립이 30fps였을 때 24fps의 원래 프레임레이트와 충돌하는 문제가 발생했기 때문에 16fps를 고수하기로 결정했습니다.

모든 클립을 16fps로 변환하면서 각 비디오의 프레임 범위는 65-129에서 약 45-88프레임으로 줄었습니다. 이로 인해 훈련을 위해 철저히 계획했던 프레임 버킷 범위가 엉망이 되었습니다. 다행히, 이 문제가 커지지 않은 이유는 훈련용 영상을 선택할 때 이미 몇 가지 규칙을 설정해 놓았기 때문입니다.

우선, 장면 내에서 빠른 전환을 포함해서는 안 됩니다. 왜냐하면 트레이너가 훈련을 위한 프레임 버킷의 정확한 길이(프레임 수)를 예측할 수 없었기 때문입니다. 모델 크기, VRAM, 기타 요인들이 모두 영향을 미칩니다. 예를 들어, 저는 81프레임 길이의 단일 클립을 훈련용으로 사용하고 싶었지만, RTX 3090에서 OOM 오류가 발생했습니다. 그래서 프레임 추출 전략을 선택해야 했습니다. 이 전략에 따라 클립이 몇 개의 짧은 파트로 분할될 수 있습니다(여기에 다양한 전략에 대한 훌륭한 분석이 있습니다). 그리고 이때 장면의 의미적 일관성이 깨질 수 있습니다. 예를 들어, 클립의 첫 번째 부분에서 소녀가 입을 벌린다면, 이 부분만 잘라낸 후에는 그녀가 울고 있는지 웃고 있는지 모호해질 수 있습니다. 이러한 맥락 불일치는 Wan의 UMT5 인코더에게 슬픔을 줄 수 있습니다.

다른 고려 사항은 원본 클립의 모든 파트에 대해 캡션을 재사용하고 싶었다는 점입니다. 텍스트 인코더를 통해 캡션을 다시 작성하고 임베딩을 재캐시하는 것을 피하고 싶었습니다. 영상 캡션 작성은 매우 시간이 오래 걸리기 때문입니다. 하지만 장면이 전체적으로 극심하게 변한다면, 원본 캡션이 모든 파트에 적합하지 않을 수 있으며, 이는 훈련 품질을 떨어뜨립니다. 따라서 "클립은 빠른 맥락 전환이 없어야 한다"와 "클립은 자체적으로 완전해야 한다. 즉, 클립 내부만으로도 이해되지 않는 사건을 포함해서는 안 된다"는 규칙을 따르면, 장면이 서브파편으로 분할되더라도 캡션은 (허용 가능한 오차 범위 내에서) 각 파편에 여전히 적용됩니다.

변환 후, 모든 클립을 검토하여 총 클립 수를 240개로 줄였습니다(과도한 전환을 포함하거나 반대로 너무 정적인 클립을 제거했습니다). 이는 데이터셋의 첫 번째 부분을 구성했습니다.

저는 비디오와 이미지의 혼합 데이터셋을 사용하기로 결정했습니다. 따라서 데이터셋의 두 번째 부분은 다양한 지브리 영화의 화면 캡처에서 가져온 120장의 이미지(해상도 768x768)로 구성되었습니다.

이미지로 먼저 학습한 후 비디오로 미세 조정하는 대안적 접근법도 있습니다(이 LoRA의 제작자가 성공적으로 적용했습니다). 그러나 저는 개인적으로 단일 배치에 혼합하는 방식이 더 낫다고 생각합니다(이 가정을 뒷받침하는 확실한 수치는 없습니다). 내 가정을 뒷받침하기 위해, 동일한 혼합 학습 방식을 사용한 매우 우수한 LoRA를 참고로 제시합니다(혹시 기억이 맞다면, 이 모델도 24GB GPU에서 학습되었습니다).

소비자용 GPU에서 혼합 데이터셋으로 효과적인 비디오 학습을 수행하려면 해상도, 지속 시간 및 학습 시간 사이의 적절한 균형을 찾아야 했습니다. 저는 저해상도 고지속 시간 비디오와 고해상도 이미지를 혼합하여 이 균형을 찾기로 결정했습니다. 이에 대한 더 자세한 내용은 학습 섹션에서 설명하겠습니다.

캡션 생성에 대해: 데이터셋의 이미지는 이전에 제 HV 데이터셋에서 재사용한 것이며, 이전에 "스위스 군용 나이프" VLM인 Qwen2-VL-7B-Instruct를 사용하여(SFW 전용) 캡션을 생성했습니다. 다음 캡션 프롬프트를 사용했습니다:

이 장면에 대한 매우 상세한 설명을 작성하세요. 번호 목록이나 줄 바꿈을 사용하지 마세요. 중요: 출력 설명은 반드시 변경되지 않은 문구 'Studio Ghibli style. '로 시작해야 하며, 그 뒤에 상세한 설명이 와야 합니다. 설명은 1) 장면의 주요 내용을 기술하고, 2) 환경 및 조명 세부사항을 설명하며, 3) 촬영 유형(예: 공중 촬영, 클로즈업, 미디엄 샷, 롱 샷)을 식별하고, 4) 장면의 분위기(예: 포근함, 긴장감, 신비로움)를 포함해야 합니다. 다음 템플릿을 반드시 사용하세요: 'Studio Ghibli style. {주요 주체 행동/설명}. {환경 및 조명 세부사항}. {스타일 및 기술적 사양}'.

이 캡션 구조가 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 프롬프트를 사용했습니다:

이 비디오에 대한 매우 상세한 설명을 작성하세요. 중요: 출력 설명은 반드시 변경되지 않은 문구 'Studio Ghibli style. '로 시작해야 하며, 그 뒤에 상세한 설명이 와야 합니다.

저는 모델에 첨부하기 위해 사용한 전체 데이터셋을 이어 붙였습니다. 이 데이터셋에는 일부 저작권이 있는 자료가 포함되어 있지만, 공정 사용 범위 내에 있다고 생각합니다. 이 데이터셋은 모델의 능력을 연구 및 교육적 평가하는 데만 사용되며, 모델 학습 과정의 투명성을 제공하기 위한 목적으로 제공됩니다. 재배포 또는 상업적 이용을 위한 목적으로는 사용되어서는 안 됩니다.

학습

관심 있는 분들을 위해, WanVideo 학습에 고려한 트레이너 목록을 아래에 제시합니다:

• diffusion-pipe - HV 학습의 원조이지만, 메모리 효율적인 Wan 학습도 지원합니다. 구성 기반이며, 제3자 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 제한에 걸렸기 때문에 이 매개변수를 사용했습니다. 하이퍼파라미터는 대부분 기본값을 그대로 사용했습니다. 이전에 흐름 시프트 값과 적응형 옵티마이저를 사용해 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

제 데이터셋 구성은 세 부분으로 이루어져 있습니다.

먼저 마지막 부분부터 설명하겠습니다. 이 부분은 메인 데이터 배열을 포함하며, 해상도 1920x1040, 프레임 수 45~88 프레임 사이로 구성된 총 240개의 클립입니다.

물론 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초/it로 속도가 저하되는 문제도 해결되었습니다. 단점은 학습 속도가 약 11~12초/it로 떨어졌다는 점이었습니다. 되돌아보면, 해상도를 [368, 192]로 낮추면 속도를 약 8초/it까지 끌어올릴 수 있었을 것이고, 이는 매우 좋았을 것입니다(예: AI Toolkit에서 1024p로 Flux를 학습할 때 얻는 속도와 유사). 이 경우 약 90시간(28,000단계)에 걸친 전체 학습에서 약 20시간을 절약할 수 있었을 것입니다. 당시 저는 20,000단계를 넘을 것이라고 예상하지 못했습니다.

또한, 저는 Windows에서 모니터를 GPU에 연결하고(동시에 코딩도 했습니다 😼) 학습했습니다. Linux(예: diffusion-pipe 사용 시)에서 모니터 출력을 내장 GPU로 전환한다면, OOM 또는 공유 메모리 한계에 걸리지 않고 약간 더 높은 공간-시간 해상도를 사용할 수 있을지도 모릅니다(이것은 Windows 전용 문제로 보입니다).

이제 첫 번째 부분(768x768 해상도의 120장의 이미지)에 대해 설명하겠습니다. 처음에는 1024p 이미지로 학습하려 했으나, 과도한 설정이 될 것이고 속도를 늦출 것이라 판단하여 포기했습니다.제 계획은 HD 이미지와 저해상도 비디오를 동시에 학습하여 더 나은 일반화를 달성하는 것이었습니다. 아이디어는 고해상도 이미지가 클립의 저해상도 단점을 보완할 것이라는 것이었습니다. 게다가 WAN은 이미 이렇게 학습되었습니다, 따라서 이 접근법이 "상류" 스타일 학습에도 유리할 것이라 판단했습니다.

마지막으로, 일반화에 있어서도 중요한 두 번째 부분입니다(여기서도 ‘과학적인’ 가정은 아니지만, 합리적으로 보입니다). 이 아이디어는 세 번째 섹션에서 사용했던 클립을 그대로 재사용하면서, 첫 번째 프레임과 처음 21개 프레임만으로 학습하는 것이었습니다. 이 방식을 통해, 시공간적 스타일 모션 특징을 더 잘 학습할 수 있기를 기대했습니다. 동시에, 이를 통해 두 번째 섹션의 해상도를 [768, 416]로 높일 수 있었습니다.

결과적으로, 다음과 같은 ‘교차 일반화’를 달성하고자 했습니다:

• 섹션 1의 고해상도 이미지(768x768)

• 섹션 2의 중해상도 단일 프레임 및 21프레임 클립(768x416)

• 섹션 3의 저해상도 45프레임 클립(384x208)

또한, 두 번째 및 세 번째 섹션의 대다수 클립은 동일한 시작 프레임을 공유했는데, 이는 I2V 시나리오에서 LoRA 활용에 유리할 것이라 믿었습니다. 이 모든 전략은 하드웨어 한계에 도달하지 않으면서도 내 데이터셋을 최대한 활용하는 가장 좋은 방법이라고 생각했습니다.

물론, 이 접근법을 처음 생각한 사람은 아닙니다. 하지만 논리적이고 합리적으로 보이므로, 더 많은 창작자들이 Wan을 위한 비디오 기반 LoRA를 학습할 때 A100이 필요하지 않다는 사실을 깨닫기를 바랍니다.

재미있는 사실: 한 에포크는 총 1080개의 샘플로 구성될 것이라 예상했습니다: 120장의 이미지(첫 번째 데이터셋 섹션) + 240개의 단일 프레임(두 번째 데이터셋 섹션, “head” 프레임 버킷=1) + 각각 21프레임인 240개의 클립(두 번째 데이터셋 섹션, “head” 프레임 버킷=21) + 각각 45프레임인 480개의 클립(두 번째 데이터셋 섹션, “uniform” 프레임 버킷=45, 2회 샘플링). 그러나 학습을 시작한 뒤, 실제로는 1078개의 샘플이라는 것을 알게 되었습니다. 조사해보니, 제가 사용한 스크립트(ffmpeg의 ffprobe 명령어로 프레임 수를 계산)가 보고한 두 개의 클립이 실제로 45프레임보다 짧았고, 이는 반올림 오류 때문이었습니다. 큰 문제는 아니었기 때문에, 그 두 클립을 제외한 채 학습을 계속했습니다. 그러나 이것이 최종 LoRA의 스텝 수가 예상과 너무 다르게 나온 이유였습니다 :)

학습 자체는 매끄럽게 진행되었습니다. 손실 그래프는 공개하지 않겠습니다. 제가 너무 부끄러워서라기보다, 그 그래프들이 큰 의미가 없다고 생각하기 때문입니다. 주로 에포크 간 손실 분포가 지나치게 유사해지는지 확인하는 데 사용합니다. 이는 과적합의 신호입니다.

28,000 스텝까지 학습한 뒤, 몇 일 동안 최고의 체크포인트를 선택했습니다. 제가 더 잘했을 수 있었던 또 다른 점은 각 에포크 끝이 아니라, 에포크 중간에도 체크포인트를 저장하는 것이었습니다. 한 에포크는 1078스텝이므로, 제가 최종적으로 선택한 체크포인트보다 더 나은 성능을 가진 체크포인트가 중간에 사라졌을 가능성도 있습니다.

학습 파이프라인에 검증 손실 추정을 통합하려고 고민 중입니다(자세한 내용은 여기에서 확인하세요). 하지만 아직 구현하지 못했습니다.

이 과정을 단순화할 수 있을까요? 아마도 그렇습니다. 다음 LoRA에서는 섹션 1의 추가 이미지 데이터셋이 불필요했는지 테스트해볼 계획입니다. 단순히 고해상도로 설정된 별도의 데이터셋 섹션을 만들고, 클립의 첫 프레임을 재사용했어도 충분했을 겁니다. 하지만 저는 데이터셋을 가능한 한 다양하게 만들고 싶었기 때문에, 클립과 다른 장면에서 스크린캡처한 이미지를 사용했습니다. 따라서 이 이미지들은 불필요하지 않았습니다.

심지어 두 번째 섹션이 필요했는지도 확신이 서지 않습니다. 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.

이 모델은 현대 비디오 생성 시스템의 가능성에 대한 기술적 시연입니다. 원작자의 권리를 해치거나 침해하기 위한 것이 아니며, 이 모델의 영감을 준 예술가들의 놀라운 작업에 대한 경의를 담고 있습니다.