H3를 직접 돌려봤다. Wan 2.2와 스프라이트 7모션 비교 (레고 로봇)

H3를 직접 돌려봤다. Wan 2.2와 스프라이트 7모션 비교 (레고 로봇)

지난 핑크팬더 글에서 이런 말을 남겼습니다. H3는 33B+32B 규모라 로컬 구동이 어려우니 Wan으로 대신한다고요. 그런데 8월 초, 미니맥스 H3가 오픈웨이트로 풀렸습니다. 게이트가 열려 있던 것이죠. 리모트 서버에 ComfyUI와 H3를 얹는 작업도 다른 세션에서 끝나 있었습니다.

 

"H3를 직접 쓰면 결과가 어떻게 다를까"가 궁금해졌습니다. 예전에 만든 레고 스타일 주황 로봇을 꺼내 7모션을 뽑았어요. 앞으로 걷기, 뒤돌기, 점프, 주저앉기, 총쏘기, 망치 휘두르기, 죽어서 부서지기. Wan 2.2와 같은 조건으로 돌려 비교했습니다. 지난번에 Wan으로 같은 파이프라인을 돌렸으니, 비교 기준이 이미 잡혀 있던 상황이었습니다.

 

H3 라이선스는 미국·EU·영국·한국 사용자에게 별도 신청서를 요구합니다. 사실 이 글을 준비하면서 가장 먼저 확인한 부분이기도 해요. 한국도 신청 대상이고, 모델 규모도 33B(Omni)에 32B(Qwen3VL) 수준입니다. 쓰기 전에 확인할 게 꽤 있는 모델이죠.

얹는 데까지

ComfyUI 0.34에 MiniMaxH3 ReferenceToVideo 노드를 올렸습니다. 모델은 ref2va pruned int8 convrot(33B)에 qwen3vl-32b int8을 곁들이고, 영상·오디오 VAE는 fp16/fp32로 얹었어요. 864×480(0.4MP), 9:16 세로로 돌렸습니다. 지난번 720p에 비하면 작지만, 스프라이트 원본으로는 차고 넘치는 크기입니다.

 

생성 설정은 20스텝 res_multistep에 5초짜리 124프레임입니다. 프레임 수는 수식이 알아서 계산해줘요. 생성 시간은 모션당 약 6분 안팎이었고, 모델 로드 후 순수 생성 기준으로 125~376초 걸렸습니다.

 

무게부터 다릅니다. H3는 두 GPU가 각각 46GB 안팎을 씁니다. Wan 720p 피크 46GB 하나와 비교하면 두 배죠. 모델이 둘이라 int8이 아니었다면 어땠을지, 상상만 해도 아찔합니다. 그래도 두 GPU int8로 끝났으니 그런 대로 다행입니다.

 

자동화는 API 그래프로 했습니다. 29노드짜리 그래프를 직접 구성했는데, 워크플로 템플릿을 API 포맷으로 손수 바꾸는 끈기 작업이었어요. 이게 준비의 절반은 차지했습니다. 한 번 만들어두면 재사용이라 두 번째 모션부터는 편했고, 일일이 눌러 만드는 것과는 격이 다릅니다.

실측 비교

핵심만 표로 정리했습니다.

 

항목	H3 (R2V int8)	Wan 2.2 (TI2V)
캐릭터 보존	탁월 — 원본 레고 로봇 그대로	좋음 — 핑크팬더
배경(크로마키) 지시	불안정 — 그린 지시를 절반만 지킴	확실 — 그린 스틸 기반
속도	약 6분/모션 (480p)	5.1분/모션 (720p)
오디오	함께 생성 (옴니)	없음
VRAM	약 46GB × 2 (int8)	46GB (bf16, 720p 피크)
핵심 차이	참조 이미지 기반 (Reference-to-Video)	첫 프레임 기반 (Image-to-Video)

 

캐릭터 보존은 H3가 단연 좋았습니다. 원본 레고 로봇이 그대로 살아나요. 핑크팬더 때의 Wan도 좋았지만, 이쪽은 기대를 저버리지 않습니다.

 

R2V와 TI2V의 차이는 크로마키에서 그대로 드러났습니다. 참조 이미지를 받는 H3는 배경 지시를 불안정하게 지켰고, 첫 프레임을 받는 Wan은 스틸의 그린을 그대로 물고 갑니다.

 

오디오는 이번 비교에서 가장 큰 차이였습니다. H3는 옴니 모델이라 소리까지 함께 생성하는데, 스프라이트만 보면 놓칠 뻔했습니다. 게임 자산으로 쓰려면 효과음 포함이 훨씬 매력적이죠.

그린이 갈렸습니다

그런데 이상한 게 있었습니다. 같은 int8 모델인데 모션마다 그린 지시를 지키는 비율이 갈렸어요. walk, hammer, turn은 75~86%가 그린으로 나왔습니다. 그런데 plop은 0.2%, shoot은 12%, jump는 38%였습니다. 그린을 거의 무시한 셈이죠. 퍼센트로 밝히기 민망한 수준도 있었습니다.

 

원인 후보는 셋이었어요. 참조 이미지 배경의 체크무늬, int8 퀀타이즈의 지시 순응 저하, 프롬프트. 제일 유력해 보인 건 int8이었습니다. 퀀타이즈가 지시를 녹인다고 보는 게 정설이니까요.

 

검증은 단순했습니다. 그린이 잘 나온 hammer 클립의 그린 프레임을 새 참조 이미지로 넘긴 것입니다. 실패했던 plop, shoot, jump를 동일 int8 모델 그대로 재생성했어요. 비용은 모션당 6분 안팎이니 셋이면 20분, 그냥 돌렸습니다. 결과는 셋 다 그린 84.8%였습니다. 여기서 고개가 갸웃해졌습니다.

 

 

범인은 참조 이미지의 체크무늬 배경이었습니다. 의심했던 쪽이 무죄였고, 안 보던 쪽이 범인이었죠. R2V 계열은 참조 이미지의 배경 성격을 강하게 따라갑니다. 크로마키를 쓸 거면 참조 스틸을 그린 배경 원본으로 만들어줘야 해요. 캐릭터 스틸을 그린 배경에 합성하고 그걸 R2V에 넘기는 식입니다.

 

turn은 반대 케이스였습니다. 그린은 반영됐는데 키가 잡히지 않았어요. 그린 음영 차이가 원인일 듯한데, 키랙 사전 적용 검증이 필요해서 남겨뒀습니다.

7모션 전부

이렇게 해서 7모션 전부가 나왔습니다. 스프라이트화까지 끝났어요. walk는 루프 시임이 잡혀 루프 1.01이고, turn은 360도 회전입니다. death는 마지막에 로봇이 부서집니다. 미리보기, 스프라이트 스트립, 애니메이션을 모션마다 세 장씩 붙였어요. 세 파일이 구실이 다릅니다. 미리보기는 완성된 스프라이트, 스트립은 키프레임 나열, 애니메이션은 움직이는 모습입니다. 크기도 원본 클립 그대로라, 세로 480×864 GIF는 실물과 같은 비율로 붙였습니다.

 

걷기부터.

 

 

 

 

뒤돌기. 캐릭터가 360도 돕니다.

 

 

 

 

점프.

 

 

 

 

주저앉기.

 

 

 

 

총쏘기.

 

 

 

 

망치 휘두르기.

 

 

 

 

죽어서 부서지기. 마지막 프레임에서 산산조각납니다.

 

 

 

결론

캐릭터 보존과 오디오에서는 H3가 Wan보다 위였습니다. 다만 스프라이트 파이프라인에서 H3를 쓰려면 그린 배경 제어가 전제예요. 지금 기준으로는 크로마키 파이프라인에서 Wan이 더 안정적이고, H3는 참조 스틸을 그린 원본으로 만들어주면 따라잡을 수 있습니다. 순서로 정리하면 캐릭터 스틸을 뽑고, 그린 배경에 합성하고, 그걸 참조로 넘기는 것입니다.

 

한국도 라이선스 신청 대상입니다. H3를 쓰고 싶다면 신청서부터 내야 해요.

 

실측 수치를 다시 적습니다. H3는 int8 864×480 20스텝 기준 모션당 약 6분, 모델 로드 후 125~376초. Wan은 720p 모션당 5.1분입니다. 캐릭터 보존과 소리에서는 H3가 위였고, 파이프라인 안정성에서는 Wan이 위였습니다. 캐릭터가 그대로 남아야 하면 H3, 절차가 단순해야 하면 Wan이에요.

 

레고 로봇으로 7모션, 21장이 나왔습니다. 스프라이트를 뽑는다면 참조에 크로마키 원본을 쓰는 것부터 시작해보세요.