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%였다. int8은 범인이 아니었다.

 

범인은 참조 이미지의 체크무늬 배경이었다. 의심했던 쪽이 무죄였고, 안 보던 쪽이 범인이었다. 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장이 나왔다. 스프라이트를 뽑는다면 참조에 크로마키 원본을 쓰는 것부터 시작해보자.