MiniMax H3 인물 LoRA 적용 방법
X에서 Michael Guo(@Michaelzsguo) 님
x.com
어제 꽤 흥미로운 MiniMax H3 LoRA 하나를 발견했다.
Playtime-AI라는 사용자가 MiniMax H3용 Sydney Sweeney 인물 LoRA를 공개했는데, 파일 크기가 겨우 155MB다. 실제 Hugging Face에 올라온 MM-H3 - Sydney Sweeney.safetensors 파일도 155MB로 확인된다.
이 LoRA를 MiniMax H3와 함께 로드하면 별도의 레퍼런스 이미지를 넣지 않고도 프롬프트에 Sydney Sweeney라는 이름을 적어 해당 인물의 외형적 특징을 반영한 영상을 만들 수 있다.
여기서 재미있는 질문이 생긴다.
한 사람의 얼굴은 어떻게 155MB짜리 파일 안에 들어갈 수 있을까?
그리고 왜 수십억 개의 파라미터를 가진 거대한 영상 모델이 작은 LoRA 하나를 붙였다는 이유만으로 특정 사람처럼 보이는 인물을 생성할 수 있을까?
이번 글에서는 인물 LoRA가 실제로 무엇을 저장하는지부터 MiniMax H3에 어떻게 연결되는지, 그리고 로컬에서 사용하면서 가장 헷갈리기 쉬웠던 부분까지 차례대로 정리해본다.
우선 요약하면
MiniMax H3가 영상 전체를 만들고, LoRA가 특정 인물의 얼굴 특징만 추가로 주입하는 구조입니다.
핵심은 이렇습니다.
- MiniMax H3 = 기본 영상 생성 모델
- 사람 움직임, 카메라, 조명, 표정, 장면 등을 생성.
- 인물 LoRA = 얼굴/정체성 플러그인
- 여러 장의 특정 인물 사진으로 학습.
- H3 전체를 재학습하지 않고 일부 레이어에 작은 추가 가중치만 학습.
- 그래서 파일이 약 155MB처럼 작을 수 있음.
- 학습할 때같은 관계를 학습시킴.
- Sydney Sweeney ↓ 이 이름 ↔ 이 얼굴 특징
- 생성할 때
- MiniMax H3 + Sydney Sweeney LoRA + "Sydney Sweeney walks into a hotel..." ↓ 특정 인물 특징을 가진 영상
- 그래서 참고 이미지를 매번 넣지 않아도 LoRA를 로드하고 이름을 프롬프트에 넣는 방식으로 인물 특징을 유지할 수 있음.
- LoRA 안에는 얼굴 사진 자체가 들어가는 것이 아니라,
- “H3의 생성 결과를 이 사람의 얼굴 방향으로 얼마나 변화시킬지”를 나타내는 작은 가중치 변화량이 저장됩니다.
한 문장으로
33B짜리 MiniMax H3가 영화 제작팀이라면, 155MB짜리 인물 LoRA는 ‘이번 영화의 주인공 얼굴은 이 사람’이라고 지정하는 캐스팅 파일입니다.
1. Sydney Sweeney LoRA는 영상 생성 모델이 아니다
먼저 가장 중요한 것부터 구분해야 한다.
영상 자체를 만드는 모델은 MiniMax H3다.
MiniMax 공식 자료에 따르면 H3의 핵심인 H3-Omni-Transformer는 약 33B 파라미터의 dense single-stream Transformer다. 영상과 오디오 latent를 동시에 예측하며 영상과 스테레오 오디오를 함께 생성하도록 설계돼 있다.
즉,
- 사람의 움직임
- 카메라 움직임
- 표정 변화
- 장면 구성
- 시간에 따른 영상 변화
- 오디오
같은 생성 능력의 대부분은 H3가 담당한다.
인물 LoRA는 이런 능력을 새로 만드는 모델이 아니다.
쉽게 비유하면 H3는 이미 영화 제작 능력을 갖춘 거대한 제작팀이다.
감독도 있고,
카메라 감독도 있고,
조명팀도 있고,
배우를 움직이는 능력도 있다.
인물 LoRA는 여기에 추가되는 일종의 캐스팅 정보다.
이번 장면의 주인공은 이런 얼굴이어야 한다.
라는 정보를 추가하는 것이다.
LoRA를 제거한다고 H3의 영상 생성 능력이 사라지지 않는다.
다른 인물 LoRA를 붙이면 같은 제작팀으로 다른 주인공을 촬영할 수 있다.
실제로 Playtime-AI의 Hugging Face 계정에는 현재 70개가 넘는 모델이 공개되어 있으며 여러 유명 인물을 대상으로 한 MiniMax H3 LoRA가 포함돼 있다.
즉 얼굴 하나가 하나의 작은 Identity Plugin처럼 분리되기 시작한 셈이다.
2. LoRA는 거대한 모델의 무엇을 바꾸는가
LoRA는 Low-Rank Adaptation의 약자다.
거대한 모델을 직접 다시 학습하는 대신 기존 가중치는 고정하고 작은 추가 행렬만 학습한다.
예를 들어 모델 내부에 거대한 가중치 행렬 W가 있다고 하자.
일반적인 full fine-tuning은 W 자체를 수정한다.
하지만 LoRA는 W를 그대로 둔 채 옆에 작은 두 행렬 A, B를 추가한다.
개념적으로는 다음과 비슷하다.
y = base(x) + scale * (x @ A.T) @ B.T
기존 모델:
x ───────────────→ W ───────────→ y
LoRA 적용:
┌── W ────────────────┐
x ──────────────────┤ ├──→ y
└── A → B → scale ───┘
학습하는 것은 A, B뿐이다.
기존 모델의 수십억 개 파라미터 대부분은 그대로 얼려둔다.
따라서 LoRA 파일에는 H3 자체가 들어 있는 것이 아니다.
들어 있는 것은 사실상
H3의 기존 동작을 어느 방향으로 조금 수정해야 하는가
라는 변화량이다.
그래서 수십 GB짜리 기반 모델 위에 100~200MB 정도의 LoRA만 추가하는 것이 가능하다.
3. 그렇다면 얼굴은 정확히 무엇으로 저장되는가
여기서 흔히 생기는 오해가 있다.
155MB 파일 안에 Sydney Sweeney 얼굴 사진이 압축되어 저장돼 있는 것은 아니다.
LoRA가 저장하는 것은 이미지가 아니라 가중치 변화의 방향이다.
예를 들어 학습 이미지에 특정 얼굴에서 반복적으로 등장하는 특징이 있다고 하자.
- 얼굴 윤곽
- 눈과 눈 사이의 비율
- 턱선
- 코와 입의 관계
- 헤어라인
- 피부 톤
- 표정에서 반복되는 형태
모델은 이런 정보를 픽셀 사진 그대로 외우는 방식이 아니라 내부 feature space에서 해당 인물의 특징을 생성하기 위한 방향을 학습한다.
따라서 우리가 프롬프트에 특정 trigger word를 입력하면 해당 LoRA의 변화량이 활성화되면서 생성 결과가 그 인물의 identity 방향으로 이동한다.
4. MiniMax H3에서 인물 LoRA가 학습되는 위치
MiniMax H3의 공식 Transformer 설정을 보면 메인 Transformer는 50개 layer, 별도의 refiner는 2개 layer로 구성돼 있다.
재미있는 부분은 모든 블록이 인물의 얼굴을 동일하게 담당하는 것이 아니라는 점이다.
MiniMax H3 LoRA 학습 도구인 Fizgig 프로젝트는 자체 분석 결과를 바탕으로 인물 likeness 학습에서 20~49번 블록을 주요 identity block으로 취급한다.
현재 Fizgig의 Optimised Likeness Learning 역시 사진을 이용한 인물 학습에서 20~49번 블록을 집중적으로 학습하는 방식을 사용한다.
이게 상당히 중요한 포인트다.
모델 전체가 한 사람의 얼굴을 기억하는 것이 아니다.
거대한 네트워크 안에서도
구도
동작
공간
스타일
캐릭터 identity
음성
와 관련된 기능이 서로 다른 정도로 분산되어 있다.
인물 LoRA는 그중 identity에 영향을 크게 주는 영역을 집중적으로 변경할 수 있다.
5. 실제 Sydney Sweeney LoRA 파일을 보면
[작성자 파일 분석]
해당 LoRA의 메타데이터와 tensor를 분석하면 다음과 같은 구조가 관찰됐다고 한다.
- LoRA rank: 16
- alpha: 16
- 기본 scale: 1.0
- H3의 attention 및 FFN 계열 projection에 LoRA 적용
- 50개 main block과 2개의 text refiner 관련 레이어 존재
특히 흥미로운 부분은 앞쪽 일부 블록의 LoRA B matrix가 실제 변화를 만들지 않도록 구성돼 있었다는 점이다.
이는 Fizgig이 현재 설명하는 H3의 likeness 학습 전략과도 방향성이 비슷하다.
Fizgig 문서에서도 인물 사진 학습 시 앞부분이 아닌 20~49 블록에 identity 학습을 집중시키는 방식을 사용하고 있다.
즉 인물 LoRA는 모델 전체를 억지로 특정 배우처럼 만드는 것이 아니라
인물 정체성에 중요한 영역만 선택적으로 미세 조정하는 방식
에 가깝다.
6. 한 사람을 LoRA로 만드는 과정
인물 LoRA 훈련은 대략 다음 흐름으로 진행된다.
① 데이터셋 준비
먼저 같은 인물의 여러 사진을 준비한다.
중요한 것은 사진 숫자뿐 아니라 다양성이다.
예를 들면
정면
45도
측면
웃는 얼굴
무표정
말하는 표정
실내
야외
강한 조명
부드러운 조명
클로즈업
상반신
전신
등이 필요하다.
한 각도의 사진만 반복하면 특정 사진은 잘 재현하더라도 새로운 카메라 앵글에서 identity가 쉽게 무너질 수 있다.
② Caption 작성
각 이미지에는 설명을 붙인다.
예를 들어:
Sydney Sweeney standing in a hotel lobby,
soft cinematic lighting,
medium close-up
여기서 Sydney Sweeney가 반복적으로 등장하면 이 문자열이 사실상 trigger token 역할을 하게 된다.
모델은
"Sydney Sweeney"
↓
특정 visual identity
라는 연결 관계를 학습한다.
③ 기반 모델 고정
MiniMax H3 전체를 다시 학습하지 않는다.
기존 H3 가중치는 고정한다.
MiniMax H3
████████████████████████
Frozen
그리고 작은 LoRA matrix만 학습한다.
LoRA
██
Trainable
그래서 학습 결과가 거대한 체크포인트가 아니라 작은 .safetensors 파일 하나로 끝날 수 있다.
7. Fizgig은 왜 소비자 GPU에서도 H3 LoRA를 학습할 수 있는가
MiniMax H3 자체는 33B 규모라 상당히 크다.
그런데 Fizgig은 H3 LoRA를 일반적인 소비자 GPU에서도 학습할 수 있도록 여러 최적화를 제공한다.
Fizgig 공식 문서에는 H3 LoRA 학습에
pruned int8 DiT
block swapping
LoRA
Optimised Likeness Learning
등을 조합하는 방법이 설명돼 있다.
현재 문서 기준으로 16GB급 GPU에서도 H3 LoRA 학습 경로가 제공된다.
기반 모델 전체를 업데이트하지 않기 때문에 가능한 접근이다.
8. Ref2VA와 FL2VA가 다른데 LoRA가 동작할 수 있는 이유
MiniMax H3에는 대표적으로 서로 다른 task family가 존재한다.
공식 저장소에서도
FL2VA
Ref2VA
체크포인트가 각각 제공된다.
Ref2VA는 reference 이미지·비디오·오디오 조건을 이용하는 계열이고, FL2VA는 다른 입력 조건을 사용하는 계열이다.
따라서 일반적으로 LoRA는 자신이 학습된 기반 모델과 구조가 맞아야 한다.
LoRA가 붙는 레이어의
module name
tensor shape
architecture
가 달라지면 사용할 수 없다.
하지만 동일한 MiniMax H3 계열에서 핵심 Transformer 구조가 동일하다면 특정 LoRA가 다른 H3 variant에서도 로딩 가능한 경우가 있다.
반대로
MiniMax H3 LoRA
↓
Wan
LTX
SDXL
Flux
처럼 완전히 다른 구조의 모델로 옮기는 것은 별개의 문제다.
LoRA는 모든 생성 모델에 통하는 범용 플러그인이 아니다.
9. ConvRot을 봤다고 LoRA를 다시 회전시키면 안 된다
[작성자 실험 및 코드 분석]
이 LoRA를 연결하면서 가장 헷갈렸던 부분 중 하나가 quantization이었다.
훈련에 사용된 기반 체크포인트 이름에는 int8_convrot 같은 표현이 들어간다.
처음 보면
기반 모델 weight가 회전됐다면 LoRA matrix도 같은 basis에 맞춰 변환해야 하지 않을까?
라고 생각하기 쉽다.
하지만 작성자가 Fizgig 구현을 추적한 결과 ConvRot 변환은 frozen base layer 내부에서 처리되고 LoRA 자체가 별도로 역회전될 필요는 없었다고 한다.
따라서 ConvRot, Hadamard 같은 이름을 발견했다고 해서 LoRA tensor를 임의로 변환하면 오히려 원래 정상적인 weight를 망가뜨릴 수 있다.
우선 해야 할 일은 LoRA를 변환하는 것이 아니라
모듈 이름
tensor shape
base architecture
가 맞는지 확인하는 것이다.
10. 실제 LoRA 다운로드
해당 LoRA는 Hugging Face에서 받을 수 있다.
hf download \
Playtime-AI/Minimax_H3-Sydney_Sweeney \
"MM-H3 - Sydney Sweeney.safetensors" \
--local-dir ./loras
파일 크기는 약 155MB다.
이후 사용하는 환경에 따라
- ComfyUI
- Python Diffusers pipeline
- 자체 H3 runtime
등에서 LoRA를 base model과 함께 로드한다.
개념적으로 필요한 것은 단순하다.
base_model = load_minimax_h3()
identity_lora = load_lora(
"MM-H3 - Sydney Sweeney.safetensors"
)
model = apply_lora(
base_model,
identity_lora,
scale=1.0
)
실제 API는 사용하는 runtime에 따라 달라진다.
11. 30 step이 항상 6 step보다 좋은 것은 아니다
[작성자 로컬 실험]
이번 테스트에서 가장 예상 밖이었던 부분이다.
처음에는 일반적인 생각대로 sampling step을 늘렸다.
6 step
↓
30 step
보통이라면 계산량을 늘렸으니 디테일이 좋아질 것이라고 생각하기 쉽다.
하지만 결과는 반대였다고 한다.
30 step에서는 영상이 회색빛을 띠고 얼굴이 흐릿해졌고, 6 step으로 변경하자 얼굴이 훨씬 선명해졌다.
원인을 추적하면서 few-step용 Turbo LoRA 및 distillation 계열 sampling 설정과의 조합이 핵심 변수였다고 판단했다.
Fizgig 역시 H3 Turbo LoRA를 활용한 6-step preview 설정을 문서에 제공하고 있으며, H3 자체도 공식적으로 CFG-distilled checkpoint를 제공한다.
여기서 중요한 교훈은 이것이다.
Sampling step은 단순한 품질 슬라이더가 아니다.
특히 distilled model이나 acceleration LoRA를 사용한다면 해당 adapter가 학습된 sampling regime과 맞춰야 한다.
무조건 step 수를 늘린다고 품질이 좋아지는 것은 아니다.
다만 이번 6 step > 30 step 결과는 특정 LoRA와 runtime 조합에서 나온 작성자의 로컬 실험 결과이며 모든 MiniMax H3 작업에 일반화할 수는 없다.
12. Trigger 이름은 정확하게 쓰는 것이 좋다
[작성자 실험]
이번 LoRA에서는
Sydney Sweeney
라는 이름이 trigger 역할을 했다.
작성자의 첫 테스트에서는 이름을
Sydney Sweeny
라고 잘못 작성했고 인물 유사성이 크게 약해졌다고 한다.
LoRA 학습 과정에서 특정 문자열과 visual identity가 함께 학습됐다면 정확한 trigger를 사용하는 것이 중요하다.
또 여러 shot을 연결할 때도
Shot 1:
Sydney Sweeney walks into a quiet hotel lobby.
Shot 2:
Close-up of Sydney Sweeney looking toward the window.
Shot 3:
Sydney Sweeney turns back and speaks softly.
처럼 각 shot에 trigger를 다시 넣는 방식이 identity 유지에 유리했다고 한다.
단순히
Shot 1: Sydney Sweeney ...
Shot 2: She ...
Shot 3: She ...
라고 작성했을 때보다 안정적이었다는 것이다.
13. 결국 155MB 안에는 무엇이 들어 있는가
다시 처음 질문으로 돌아가 보자.
사람의 얼굴이 정말 155MB 안에 들어 있는 걸까?
정확히 말하면 그렇지 않다.
155MB 안에 들어 있는 것은 얼굴 사진이 아니다.
MiniMax H3라는 거대한 생성 공간에서
어떤 텍스트 조건이 들어왔을 때
어떤 내부 feature를
어느 방향으로 얼마나 움직이면
특정 사람의 identity에 가까워지는가
를 나타내는 작은 weight delta다.
즉
33B MiniMax H3
=
세계와 영상을 생성하는 능력
+
155MB Character LoRA
=
특정 인물 방향으로 생성 결과를 이동시키는 정보
라고 이해하면 가장 쉽다.
14. 인물 LoRA를 사용할 때 먼저 확인할 것
MiniMax H3용 인물 LoRA를 사용할 때는 최소한 다음 항목을 확인하는 것이 좋다.
- LoRA가 정말 MiniMax H3용인지
- LoRA가 학습된 H3 variant와 현재 base의 구조가 호환되는지
- module name과 tensor shape가 맞는지
- Turbo 또는 다른 acceleration adapter가 필요한지
- 몇 step을 전제로 학습·테스트됐는지
- LoRA strength 권장값이 얼마인지
- trigger token이 무엇인지
- 멀티 shot이라면 각 shot에 trigger를 반복할 필요가 있는지
그리고
LoRA loaded successfully
라는 로그가 떴다는 사실만으로 설정이 맞았다고 판단해서는 안 된다.
모델은 설정이 완전히 틀리지 않는 한 오류 없이 영상을 끝까지 만들 수 있다.
문제는 그 결과가
흐릿하거나
identity가 약하거나
색이 이상하거나
표정이 무너지거나
하는 형태로 나타날 수 있다는 것이다.
따라서 LoRA가 정상적으로 load됐는데 결과가 이상하다면 weight 변환부터 시도하기보다는
sampling schedule
step
scheduler
turbo adapter
LoRA scale
trigger
을 먼저 확인하는 편이 안전하다.
15. 이제 ‘캐릭터’ 자체가 파일이 되는 시대
LoRA는 원래 거대한 AI 모델을 저렴하게 fine-tuning하기 위한 기술이었다.
그런데 이미지와 영상 생성 모델이 발전하면서 조금 다른 의미를 갖기 시작했다.
스타일을 LoRA로 만들 수 있고,
제품을 LoRA로 만들 수 있고,
게임 캐릭터를 LoRA로 만들 수 있고,
특정 인물의 외형적 특징 역시 LoRA로 만들 수 있다.
즉 과거에는 영상 제작 과정에서 사람이
배우를 캐스팅하고
촬영장에 데려오고
카메라 앞에서 촬영
해야 했다면 생성형 영상에서는 일부 identity 정보가
character.safetensors
라는 파일 형태로 유통될 수 있는 환경이 만들어지고 있다.
다만 여기에는 기술과 별개로 중요한 문제가 따라온다.
공개된 인물 LoRA의 경우
- 학습 데이터의 출처
- 이미지 저작권
- 초상·퍼블리시티 관련 권리
- 당사자의 동의
- 합성 영상의 오인 가능성
등을 별도로 검토해야 한다.
특히 이번 Hugging Face 페이지에서는 LoRA 파일과 예시는 확인할 수 있지만, 학습에 사용된 전체 이미지 데이터셋의 출처와 처리 과정까지 모두 공개된 것은 아니다.
따라서 기술적으로 다운로드할 수 있다는 사실과 특정 용도로 자유롭게 사용할 권리가 있다는 것은 별개의 문제다.
마무리
MiniMax H3 같은 33B 규모의 생성 모델은 영상이라는 거대한 세계를 만드는 능력을 담당한다.
그리고 LoRA는 그 거대한 모델 전체를 다시 만드는 대신 작은 weight delta를 추가한다.
그 결과 특정 캐릭터의 identity가 불과 수백 MB 수준의 파일 하나로 분리될 수 있다.
Base Model
+
Character LoRA
+
Style LoRA
+
Motion / Turbo Adapter
↓
Video
이 구조가 발전하면 앞으로는 하나의 모델을 새로 만드는 것보다
기본 생성 모델 위에 캐릭터·세계관·스타일·동작을 각각 작은 adapter로 조합하는 방식
이 훨씬 흔해질 가능성이 있다.
이번 사례에서 가장 흥미로운 것은 단순히 Sydney Sweeney의 얼굴을 생성할 수 있다는 사실이 아니다.
더 중요한 변화는 이것이다.
이제 영상 속 ‘인물의 정체성’ 자체가 모델에서 분리된 하나의 파일이 되고 있다.
33B 파라미터짜리 모델이 세계를 만들고,
100여 MB의 LoRA가 그 세계의 주인공을 정한다.
생성형 영상에서 캐릭터를 다루는 방식이 바뀌기 시작했다.
출처:
X에서 Michael Guo(@Michaelzsguo) 님
把 Sydney Sweeney 装进 MiniMax H3:人物 LoRA 的原理和本地使用
x.com