한 모델이 함께 만들어내는 오픈 옴니모달 생성기b7227fa · TrendShift Daily #1)
H(Hailuo, MiniMax의 영상 브랜드) + 3(3세대) = "하이루 3세대 영상 모델"MiniMax-H3는 텍스트·이미지·영상·오디오가 뒤섞인 입력을 하나로 이해하고, 거기서 네이티브 스테레오 오디오가 붙은 영상(최대 15초·24fps·기본 768p, API로는 2K)을 생성하는 오픈웨이트 옴니모달 확산(디퓨전) 모델이다. 사용자는 "1번 영상의 카메라 워크를 참고해, 2번 이미지 속 인물이 3번 오디오 목소리로 노래하게 해줘"처럼 모달리티 사이의 관계를 자연어로 서술하면 되고, 그 복잡한 조합을 모델이 알아서 처리한다.
여기서 반드시 구분할 것. H3는 "영상만 만들고 소리는 나중에 붙이는" 흔한 파이프라인이 아니다. 영상 잠재값(latent)과 오디오 잠재값을 같은 트랜스포머가 동시에 예측해서, 입술 움직임과 대사, 화면과 효과음이 처음부터 맞물려 나온다. 그래서 모든 모드 이름이 ...VA(Video+Audio)로 끝난다: T2VA(텍스트→영상+오디오), I2VA(이미지→), FL2VA(첫·끝 프레임→), Ref2VA(레퍼런스→).
예전 생성모델은 텍스트→이미지 전문가, 이미지 편집 전문가, 목소리 전문가, 효과음 전문가, 텍스트→영상 전문가가 제각각 다른 모델이었다. 결과물을 이어 붙이려면 사람이 중간에서 조율해야 했다.
H3는 이 경계를 지우고 "영상이든 오디오든, 생성이든 편집이든, 레퍼런스든 — 전부 하나의 모델이 자연어 지시로 처리"하도록 설계됐다. 감독 한 명에게 "이런 느낌으로"라고 말로 설명하면 완성본이 나오는 셈이다.
H3의 전체 시스템은 3개 모듈로 이뤄지는데, 이 저장소로 공개된 건 그중 가운데 하나(H3-Base, 768p 생성)뿐이다. 입력을 정제하는 H3-Context-IR(품질의 핵심)과 2K로 끌어올리는 H3-Regenerate-2K는 아직 오픈되지 않았고 유료 API로만 제공된다. 즉 로컬 오픈웨이트만으로는 헤드라인의 "2K" 품질을 그대로 재현할 수 없다. (자세한 3모듈 구조는 §3·§4)
AI 영상 생성은 2026년 현재 Sora 2(OpenAI)·Veo 3.1(Google)·Kling 3.0·Seedance 2.0 같은 클로즈드 소스 모델들이 주도하고 있었다. 대형 언어모델(LLM) 판이 오픈웨이트로 빠르게 민주화된 것과 달리, 영상 쪽은 가중치가 잠겨 있어 커뮤니티가 뜯어보거나 파인튜닝하기 어려웠다. H3가 Daily #1까지 치고 올라온 건 바로 그 잠긴 문을 프론티어급 성능으로 열어젖혔기 때문이다. (TrendShift의 굵은 숫자는 별 수가 아니라 사회적 언급 모멘텀 점수다.)
| 항목 | 흔한 클로즈드 영상 모델 | MiniMax-H3 |
|---|---|---|
| 가중치 | 비공개(API/앱만) | 오픈웨이트(맞춤형 커뮤니티 라이선스) |
| 오디오 | 대개 무음 또는 별도 모델로 후처리 | 네이티브 스테레오 — 대사·효과음·음악을 영상과 조인트 생성 |
| 입력 모달리티 | 주로 텍스트·이미지 | 텍스트+이미지+영상+오디오를 레퍼런스로(Ref2VA) |
| 편집 방식 | 태스크별 전용 기능 | 자연어로 참조·편집 관계를 서술 |
| 가격(공식 주장) | 기준 | 2K 기준 초당 단가가 주류의 1/3 미만, 768p는 주류 720p의 1/2 미만 |
대부분의 영상 모델에서 소리는 사후 작업이다. H3는 학습 단계부터 음성·효과음·음악을 구분 없이 함께 모델링했고(모든 오디오 출력이 네이티브 스테레오), 오디오를 입력으로도 받는다 — 예컨대 Ref2VA에서 참조 오디오를 넣으면 목소리 음색 복제나 배경음악 재사용이 된다. "영상+오디오를 동시에, 양방향으로" 다루는 게 경쟁 모델과의 가장 선명한 차별점이다.
MiniMax는 이전에 Hailuo 01(밑바닥부터 구축)·Hailuo 02(효율·데이터·규모 개선)를 만들었다. H3의 출발점은 "왜 T2I·이미지편집·레퍼런스·모션참조가 다 따로 놀아야 하는가"라는 문제의식이었다. 이 조각난 태스크들이 창작의 자유와 모델의 일반화를 모두 막는다고 봤고, 그래서 언어(자연어)를 일반화의 다리로 삼아 모든 태스크를 "서술 가능한 하나의 형태"로 통합했다. 아키텍처 트릭보다 "태스크 일반화"를 앞세운 것이 H3의 정체성이다.
MiniMax는 H3를 "산업급 가성비"로 포지셔닝했다. 네이티브 2K를 기본 제공하면서도 초당 단가를 낮췄다고 주장한다(위 표). 또한 다양한 AI 하드웨어와의 호환을 설계 초기부터 고려했다고 밝혔는데, 이는 오픈 생태계·커뮤니티 파인튜닝을 염두에 둔 포석이다.
지금까지의 오픈 영상 모델들(HunyuanVideo·Wan·CogVideoX 등)이 "소리 없는 흑백 무성영화 카메라"를 오픈소스로 나눠준 것이라면, H3는 "소리까지 함께 찍히는 유성영화 카메라"를, 그것도 프론티어급으로 오픈한 것에 가깝다. 게다가 "이 배우 목소리로, 저 영상 카메라 워크로"라고 말로 지시하는 감독용 인터페이스까지 딸려 왔다 — 이 조합의 신선함이 트렌딩의 동력이다.
H3-Base의 내부 5대 컴포넌트 · (C) 이걸 돌리는 실행·서빙 스택H3의 스택을 이해하는 열쇠는 "전체 시스템 = 3모듈인데, 그중 가운데 하나만 오픈됐다"는 구조다. 그 오픈된 하나(H3-Base)를 다시 열어보면 인코더·VAE·트랜스포머·스케줄러가 들어 있다. 마지막으로 이걸 실제로 구동하는 외부 프레임워크들이 있다. 하나씩 지도를 그려보자.
| 모듈 | 역할 | 공개 여부 |
|---|---|---|
| H3-Context-IR | 자유로운 멀티모달 입력을 구조화된 "컨텍스트 중간표현(Context Intermediate Representation)"으로 정제. 여러 호스티드 모델에 의존. README가 "최종 품질에 결정적"이라고 명시. | 비공개(API로만 재현) |
| H3-Base | 이 저장소. Context-IR을 받아 768p 영상+오디오를 생성하는 오픈 모델. | 오픈 |
| H3-Regenerate-2K | 768p 결과 + 원본 컨텍스트를 H3-Base에 다시 넣어 2K로 "인컨텍스트 재생성"(전통적 super-resolution 모듈이 아님). | 비공개(추후 공개 예정) |
| 컴포넌트 | 정체 | 규모 / 특징 |
|---|---|---|
| H3-Encoder | 텍스트·시각 인코더 = Qwen3-VL-32B(풀 멀티모달 LLM) | 33.36B. 64개 층 중 50번째 층의 hidden state를 트랜스포머에 넘김. 이미지/영상 레퍼런스도 이 인코더를 통과 |
| H3-VisualVAE | 영상 오토인코더 | 5.21B. f16t4d24(공간 16×·시간 4× 압축·잠재 24채널), 디코더는 별도 학습된 ViT 기반 |
| H3-AudioVAE | 오디오 오토인코더 | 인코더=DAC 계열, 디코더=BigVGAN. 32kHz→40Hz 잠재, 잠재 32채널, 좌·우 채널 독립 처리 후 스테레오 재결합 |
| H3-Omni-Transformer | 본체 = 33B 단일 스트림 DiT | 영상 잠재와 오디오 잠재를 한 트랜스포머에서 조인트로 예측. 3D MM-RoPE. 상세는 §4 |
| Scheduler | 확산 샘플링 스케줄러 | 영상·오디오에 서로 다른 timestep shift(영상 12.0 / 오디오 3.0). flow-matching 계열 |
보통 영상/이미지 확산 모델의 텍스트 인코더는 T5나 CLIP처럼 상대적으로 작다. H3는 Qwen3-VL-32B라는 풀 비전-언어 모델 전체를 인코더로 쓴다. 그래서 "인코더"만 33B이고, 여기에 33B DiT와 5.21B 영상 VAE가 더해진다. 이미지·영상 레퍼런스가 텍스트와 같은 인코더를 지나기 때문에, "1번 영상처럼"이라는 자연어 참조가 성립한다.
| 도구 / 의존성 | 역할 |
|---|---|
torch >= 2.4.0 | 기반 딥러닝 프레임워크 |
diffusers (minimax-h3 브랜치) | 파이프라인 클래스(MiniMaxH3ModularPipeline 등)의 실체. README는 pip install "git+...diffusers.git@minimax-h3" 권장 — 정식 릴리스가 아닌 브랜치 설치 |
transformers >= 4.45.0 | Qwen3-VL 인코더 로딩 |
accelerate >= 0.34.0 | 33B 트랜스포머·VAE의 device_map/멀티 GPU 로딩 |
| SGLang / vLLM | 프로덕션 서빙(전용 쿡북·레시피 제공). FL2VA/·Ref2VA/ 원본 체크포인트 포맷 사용 |
| ComfyUI | 공식 튜토리얼 + T2V/R2V 워크플로 템플릿(노코드 실행 경로) |
soundfile · imageio-ffmpeg · av | 오디오·영상 입출력(WAV/MP4 인코딩) |
저장소를 열면 같은 모델이 두 포맷으로 나란히 들어 있다. 루트의 diffusers ModularPipeline 포맷(파이썬으로 조립·연구용)과, FL2VA/·Ref2VA/ 폴더의 원본 체크포인트 포맷(trust_remote_code로 자체 .py를 실어 SGLang·vLLM으로 서빙). 둘은 토크나이저 blob(7MB)까지 통째로 중복돼 있어 파일 수가 많아 보이지만, 실제 실행 코드(디퓨전 루프)는 외부 diffusers 브랜치·SGLang에 있고 저장소가 자체적으로 품은 실행 코드는 VAE 모듈과 curl 기반 .sh 요청 스크립트뿐이다.
핵심은 가운데다. 서로 다른 모달리티가 각자의 인코더/VAE를 거쳐 잠재값이 된 뒤, 하나의 시퀀스로 패킹돼 단일 트랜스포머에 들어가고, 그 트랜스포머가 영상과 오디오 잠재를 함께 뱉는다. "영상 먼저, 소리 나중"이 아니라 처음부터 한 몸이라는 게 이 구조의 전부다.
본체는 DiT(Diffusion Transformer)다. 저장소의 transformer/config.json이 드러내는 실제 수치는 이렇다.
| 설정 | 값 | 의미 |
|---|---|---|
hidden_size | 5376 | 모델 내부 차원 |
num_layers | 50 | 트랜스포머 블록 수(+ 텍스트 토큰 refiner 2층) |
num_attention_heads | 56 | 헤드당 128차원(56×128) |
ffn_dim | 14336 | 피드포워드 폭 |
in_channels / audio_in_channels | 24 / 32 | 영상 잠재 24채널 · 오디오 잠재 32채널(두 VAE와 정확히 일치) |
patch_size | [1, 2, 2] | (t,h,w) 패치화 → 공간을 추가로 2×2 압축 |
text_dim | 5120 | Qwen3-VL의 hidden(5120)을 그대로 받음 |
adaln_out_features | 96768 | = 18 × 5376. AdaLN 변조 분기가 매우 큼(≈13B) |
| 총 파라미터 | ≈ 33.14B | index.json의 total_size에서 역산(bf16) |
텐서 이름을 보면 아키텍처의 정체가 확정된다. attn.to_q/to_k/to_v/to_out + attn.norm_q/norm_k(QK 정규화), ff.net(피드포워드), 그리고 결정적으로 영상용 proj_in/proj_out과 별도로 오디오용 audio_proj_in/audio_proj_out이 따로 존재한다. 즉 어텐션·FFN 같은 본체는 영상·오디오가 공유하고, 모달리티별로 갈라지는 곳은 입출력 프로젝션과 AdaLN 분기뿐이다 — 이것이 "단일 스트림 조인트 생성"의 실체다.
MiniMax는 자사 LLM(MiniMax-01/M1)에서 lightning/linear attention으로 유명하다. 하지만 H3의 영상 DiT는 평범한 소프트맥스 dense 어텐션 + 3D MM-RoPE + QK-norm을 쓴다(텐서 이름이 증거). README는 "네이티브 sparse-attention 학습·추론을 지원하지만, 이번 첫 공개판은 full attention 추론만 제공한다"고 명시 — sparse 구현은 추후 공개다. H3에 라이트닝 어텐션이 쓰였다고 말하면 틀린다.
33B 중 약 13B가 AdaLN 관련 분기에 있다. README에 따르면 AdaLN 변조 출력은 미리 계산해 캐시할 수 있어, 추론만 할 거라면 이 파라미터를 로드할 필요가 없다 → 추론 시 유효 트랜스포머는 ≈20B. 33B 전체를 공개한 이유는 파인튜닝을 지원하기 위해서다. 게다가 공개 체크포인트는 CFG-distilled(classifier-free guidance 증류)라, 추론 시 guidance용으로 forward를 2번 돌릴 필요 없이 단일 forward로 끝난다.
DiT가 다루는 건 픽셀·파형이 아니라 잠재값(latent)이다. 그 압축·복원을 두 VAE가 맡는다.
| 구분 | H3-VisualVAE (영상) | H3-AudioVAE (오디오) |
|---|---|---|
| 압축 | f16t4d24: 공간 16× · 시간 4× · 잠재 24채널. DiT 패치화(1×2×2)까지 더하면 유효 공간 32× | 32kHz → 40Hz 잠재(32000÷800), 잠재 32채널 |
| 인코더 | 시간적 causal 3D-conv 인코더 | DAC(Descript Audio Codec) 계열, Snake 활성화 |
| 디코더 | 별도 학습된 ViT 디코더(36층) — 디코딩 비용↓·복원 품질↑ | BigVGAN 보코더, alias-free 업샘플, SnakeBeta |
| 스테레오 | — | 좌·우 채널을 같은 인코더/디코더로 독립 처리 후 재결합 |
영상은 데이터가 엄청 크다. VAE로 공간·시간을 크게 압축해 "짧은 잠재 시퀀스"로 만들면, 트랜스포머가 다뤄야 할 길이가 확 줄어 학습·추론 비용이 급감한다. MiniMax는 H3의 VAE(토크나이저)를 전면 개편해 "유효 시퀀스 길이 4배 이득"을 얻었고, 이것이 네이티브 2K를 가능케 한 핵심 기술이라고 밝혔다. 좋은 VAE = 좋은 영상 모델의 절반이다.
확산은 "노이즈 → 데이터"로 여러 스텝에 걸쳐 되돌리는 과정이다. H3의 MiniMaxH3Scheduler는 flow-matching 계열로 보이는데(shift/sigma 파라미터화), 흥미롭게도 영상 잠재와 오디오 잠재에 서로 다른 shift(영상 12.0 / 오디오 3.0)를 준다. 두 모달리티의 노이즈 특성이 달라 최적 스케줄이 다르기 때문이다. 한 시퀀스 안에서 두 스트림을 조인트로 디노이징하되, 시간 스케줄만 갈라주는 셈이다.
보통 고해상도는 별도 super-resolution 모듈로 키운다. H3는 다르다 — 768p 결과 + 원본 멀티모달 컨텍스트를 H3-Base에 다시 넣어 2K로 재생성한다(H3-Regenerate-2K). 장점은 두 가지: ① 이미 학습된 생성 능력을 최대한 재사용하고 ② 원본 컨텍스트를 다시 참고하므로, 전통적 초해상화가 "추측"만 하던 작은 글자·미세 디테일을 실제로 복원한다. 단, 이 모듈은 아직 비공개다.
FL2VA/·Ref2VA/) · 부속(스크립트·스킬·에셋). 가중치 자체는 git에 없다구조가 프로젝트의 성격을 요약한다. 루트의 diffusers 포맷과 FL2VA/·Ref2VA/의 원본 포맷은 "같은 모델을 두 방식으로 담은 것"이라, 토크나이저·인코더 인덱스가 여러 번 중복된다(그래서 파일 229개 중 상당수가 중복 blob). 실제로 로컬에서 "코드"로 존재하는 건 FL2VA/video_vae/·FL2VA/audio_vae/의 자체 완결형 .py들과 scripts/의 .sh뿐이고, 디퓨전 루프 본체는 외부 diffusers minimax-h3 브랜치·SGLang에 있다.
*.safetensors.index.json — 가중치는 없고 "지도"만 있다.gitignore가 *.safetensors를 통째로 무시하므로, 저장소엔 실제 가중치가 한 바이트도 없다(Hugging Face에 Git LFS로 별도). 대신 남는 건 각 텐서가 어느 샤드에 있는지 적은 index.json이다. 이 파일의 total_size를 2(bf16)로 나누면 파라미터 수가 나온다 — 본 문서의 33.14B·5.21B·33.36B가 그렇게 역산한 값이다.H3는 skills/에 설치형 에이전트 스킬 9개를 담았다. 프롬프트 작성 스킬(h3-prompt-writing) 1개 + 제품광고·3D애니·페이퍼크래프트 스톱모션·브랜드 홍보·뮤직비디오 자막 등 유즈케이스별 스킬 8개. .claude/skills·.agents/skills에도 복제돼 있어 Claude Code·Codex 같은 코딩 에이전트에 npx skills add로 바로 설치된다. "모델 + 그 모델을 잘 쓰는 방법(스킬)"을 함께 배포하는 요즘 흐름의 사례다.
H3는 4개 GPU가 있어야 로컬 추론이 되므로 대부분은 직접 못 돌린다. 하지만 config와 VAE 소스만 읽어도 "요즘 최고 수준의 영상+오디오 생성기가 무슨 부품으로 어떻게 짜이는가"를 통째로 배울 수 있다. 아래 7가지가 이 저장소에서 건지는 알짜다.
왜 영상과 오디오를 한 트랜스포머에서 함께 예측하는가, 그리고 그게 가능하려면 무엇이 필요한가(공유 본체 + 모달리티별 입출력 프로젝션·AdaLN 분기). "태스크마다 모델 하나"에서 "자연어로 서술하는 하나의 모델"로 가는 패러다임 전환을 실물로 본다.
U-Net을 대체한 DiT 구조, AdaLN 조건 주입, 3D MM-RoPE, 그리고 노이즈↔데이터를 잇는 flow-matching 스케줄. 영상/오디오에 shift를 달리 주는 실전 튜닝까지. Sora·Flux 이후 표준이 된 설계를 config 수치로 확인한다.
T5/CLIP 대신 Qwen3-VL-32B 전체를 텍스트·시각 인코더로 쓰고, 64층 중 50층의 hidden만 뽑아 쓰는 선택. "이해 잘하는 LLM을 앞단에 두면 지시 이행이 좋아진다"는 최근 흐름의 구체적 구현을 본다.
f16t4d24 시공간 압축, causal 인코더, 그리고 디코더를 별도 ViT로 학습해 품질·비용을 잡는 설계. "유효 시퀀스 길이를 줄이는 게 곧 비용·해상도"라는 영상 생성의 핵심 트레이드오프를 배운다.
DAC 인코더 + BigVGAN 보코더, Snake/SnakeBeta 활성화, alias-free 리샘플, 32kHz→40Hz 잠재, 좌우 채널 독립 처리 스테레오. 음성·효과음·음악을 구분 없이 한 잠재 공간에서 다루는 방식을 뜯어본다.
H3의 프롬프트는 한 줄 캡션이 아니라 integrated_multimodal_description / overall_soundscape / non_diegetic_music(Ref2VA는 6개 섹션)로 구조화된 대본이다. 대사는 <d>[English] ...</d>로 감싼다. "모델을 잘 쓰려면 입력을 어떻게 구조화하는가"라는, 코드 밖의 엔지니어링을 배운다.
4-GPU에 Ulysses 시퀀스 병렬(--ulysses-degree 4)로 긴 멀티모달 시퀀스를 쪼개고, CFG 증류로 forward를 반으로 줄이고, AdaLN precompute-cache로 로드할 파라미터를 줄인다. VAE 코드에는 tiling·temporal streaming·sequence parallel까지 들어 있다. "33B×여러 개를 어떻게 돌리나"의 실전 기법 모음이다.
가중치를 못 돌려도, config.json 몇 개와 FL2VA/video_vae/*.py·audio_vae/dac_*.py를 읽는 것만으로 인코더→VAE→DiT→스케줄러→디코더의 전 계통을 손으로 짚을 수 있다. 이 부품 목록과 연결 방식은 H3에만 국한되지 않는다 — Wan·HunyuanVideo 같은 다른 오픈 영상 모델을 읽을 때도 그대로 통하는 공통 문법이다. "무엇을 만드는가"보다 "무엇으로 어떻게 짜였는가"에 집중하면 가장 많이 남는다.
저장소는 공식 VRAM 수치를 명시하지 않는다. 대신 가중치 크기와 서빙 스크립트에서 현실적인 요구사항을 역산할 수 있다. SGLang 실행 예제가 --num-gpus 4 --ulysses-degree 4를 쓰고, 가중치 합이 태스크당 ~143GB(DiT 66.3 + Qwen3-VL 인코더 66.7 + 영상 VAE 10.4, bf16)라 4×80GB급 GPU가 전제임을 알 수 있다.
| 항목 | 필요한 것 / 유의점 |
|---|---|
| GPU | 서빙 예제 기준 4장 + Ulysses 시퀀스 병렬 4-way. 가중치 역산상 80GB급(A100/H100 계열) ×4가 현실적. (repo에 명시된 수치가 아니라 크기로부터의 추론) |
| 추론 최적화 | repo엔 양자화·오프로드·FSDP·TeaCache 언급이 없다. 있는 건 Ulysses/시퀀스·공간 병렬 + VAE tiling + (미공개) sparse attention + AdaLN 캐시 + CFG 증류뿐 |
| 소프트웨어 | torch>=2.4, diffusers는 정식 릴리스가 아닌 minimax-h3 브랜치를 소스 설치, transformers>=4.45(Qwen3-VL), accelerate>=0.34 |
| 출력 스펙 | 해상도 기본 768p(짧은 변 768; 2K는 API 전용 H3-Regenerate-2K) · 길이 4~15초 · 24fps · 오디오 32kHz 스테레오 · 대사 11개 언어 · 화면비 21:9~9:16 |
| 가중치 받기 | hf download MiniMaxAI/MiniMax-H3 --include "FL2VA/*" "Ref2VA/*" ... (Hugging Face). .safetensors는 수십~수백 GB |
| 손 안 대고 써보는 길 | ComfyUI 공식 워크플로, fal·hailuoai.video 앱·platform.minimax.io API — 로컬 4-GPU 없이 결과만 얻는 경로 |
H3는 서버급 멀티 GPU를 전제로 한 프론티어 모델이다. 33B DiT + 33B VL 인코더 + 5.2B 영상 VAE가 동시에 올라가야 하고, repo에는 소비자 GPU를 위한 양자화·오프로드 경로가 없다. 게다가 로컬 오픈 가중치로는 768p까지이고 2K는 비공개 API가 필요하다. "직접 돌리기"보다 구조를 공부하고, 실행은 ComfyUI·클라우드 API로 접근하는 게 대부분에게 맞다(§8 실습이 그 전제로 짜여 있다).
가중치 없이 transformer/config.json·vae/config.json·audio_vae/config.json만 받아, ① index.json의 total_size ÷ 2로 33.14B를 재현하고 ② 영상 압축비(공간 16× × 패치 2×2 = 유효 32×, 시간 4×) ③ 오디오 잠재율(32000 ÷ 800 = 40Hz)을 직접 확인하자. "숫자가 어디서 나오나"를 손으로 짚으면 아키텍처가 손에 잡힌다.
skills/h3-prompt-writing/references/base-en.txt를 참고해, integrated_multimodal_description([Shot 1]·At 00:04.500 같은 절대 타이밍 포함) → overall_soundscape → non_diegetic_music의 3섹션 대본을 직접 작성하자. 대사는 <d>[Korean] ...</d>로 감싼다. "캡션"과 "대본"의 차이를 체감하는 게 목표.
로컬 4-GPU 없이, ComfyUI 공식 H3 워크플로 템플릿이나 fal·MiniMax API로 텍스트→영상+오디오를 한 편 만들어보자. 같은 프롬프트를 대사 포함 / 미포함으로 나눠 돌려, 오디오가 실제로 영상과 동기화되는지(입술·효과음) 귀로 확인하는 게 핵심 관찰 포인트다.
h3-prompt-writing 스킬을 코딩 에이전트에 설치해 뜯어보기npx skills add https://github.com/MiniMax-AI/MiniMax-H3 --skill 'h3-prompt-writing'로 Claude Code·Codex에 설치하고, SKILL.md와 references/*.txt가 어떻게 모델 사용법을 구조화했는지 읽자. "모델을 배포할 때 사용법(스킬)을 함께 배포"하는 패턴을 자기 프로젝트에 어떻게 옮길지 메모해보면 좋다.
FL2VA/video_vae/*.py(또는 접근이 쉬운 다른 오픈 영상 VAE)를 이용해, 짧은 클립을 인코드→디코드하며 압축비에 따른 화질 손실을 눈으로 비교하자. "잠재 시퀀스가 짧아질수록(=압축이 셀수록) 트랜스포머 비용은 줄지만 복원 품질은?"이라는 트레이드오프를 직접 측정하면, §4-C의 ViT 디코더가 왜 필요한지 이해된다.
H3는 여러 분야가 겹쳐 있어 한 번에 다 삼키긴 어렵다. 확산 기초 → 영상 VAE → 멀티모달 인코더/조인트 생성 → 서빙 순으로 쌓으면 각 주차가 다음 주차의 벽돌이 된다.
| 주차 | 주제 | 핵심 질문 · 자료 |
|---|---|---|
| 1주차 | 확산 · flow-matching · DiT | 노이즈↔데이터를 잇는 flow-matching이란? DiT는 U-Net과 뭐가 다른가? → DiT/Flux 논문 + transformer/config.json의 AdaLN·RoPE 항목. |
| 2주차 | 영상 VAE · 잠재 영상 확산 | 시공간 압축(f16t4d24)이 왜 비용을 좌우하나? causal 인코더·ViT 디코더의 이유는? → FL2VA/video_vae/klvae.py·vae_vit.py. |
| 3주차 | 멀티모달 인코더 · 조인트 A/V | VLM(Qwen3-VL)을 인코더로 쓰면 뭐가 좋아지나? 영상·오디오를 한 트랜스포머에서 함께 내려면? → Qwen-VL 문서 + H3 README 아키텍처 절 + audio_vae/dac_*.py. |
| 4주차 | 서빙 최적화 · 컨텍스트 엔지니어링 | Ulysses 시퀀스 병렬·CFG 증류·AdaLN 캐시는 각각 뭘 아끼나? 구조화 프롬프트가 왜 품질을 견인하나? → SGLang/vLLM 레시피 + skills/h3-prompt-writing. |
먼저 확산·DiT로 "잠재값을 어떻게 만들어내나"를 잡아야 나머지가 의미를 갖는다(1주차). 그다음 VAE로 "픽셀·파형을 어떻게 잠재값으로 줄이나"(2주차). 이어 인코더·조인트 생성으로 "왜 영상·오디오가 한 트랜스포머에 들어가나"(3주차), 마지막에 서빙·프롬프트로 "이 거대한 걸 어떻게 실제로 돌리고 잘 쓰나"(4주차)를 채우면 그림이 닫힌다.
같은 "오픈 영상 확산" 결에서 위치를 잡아보자. Wan · HunyuanVideo · CogVideoX가 주로 "무음 영상"을 오픈으로 연 선배들이라면, H3는 거기에 네이티브 오디오 + 옴니모달 레퍼런스를 얹었다. 클로즈드 진영의 Sora 2 · Veo 3.1 · Kling 3.0 · Seedance 2.0과는 "오픈이냐/오디오를 1급으로 다루냐"로 갈린다. 또한 같은 회사의 MiniMax M-시리즈(LLM)와 나란히 보면, MiniMax가 "언어(LLM)의 이해력을 영상 생성의 다리로 삼는다"는 일관된 방향(향후 H-시리즈에 M-시리즈 능력 통합 예고)을 읽을 수 있다.
shift를 12.0/3.0으로 달리 준다.--ulysses-degree 4(4장)로 긴 멀티모달 시퀀스를 감당.| 구분 | 링크 / 위치 |
|---|---|
| GitHub 저장소 | github.com/MiniMax-AI/MiniMax-H3 |
| TrendShift | trendshift.io/repositories/103885 (Daily #1) |
| 모델 가중치 | huggingface.co/MiniMaxAI/MiniMax-H3 (LICENSE = MiniMax H3 Community License) |
| 공식 기술 블로그 | minimax.io/blog/minimax-h3 ("Breaking the Boundaries Between Tasks and Modalities") |
| 체험(제품) | hailuoai.video/tools/minimax-h3 · platform.minimax.io (API) · fal.ai/minimax-h3 |
| 노코드 실행 | ComfyUI 공식 H3 워크플로 · comfyui-wiki.com/en/models/minimax/minimax-h3 |
| 서빙 레시피 | SGLang 쿡북 · recipes.vllm.ai/MiniMaxAI/MiniMax-H3 · diffusers minimax-h3 브랜치 |
| 핵심 파일(구조) | transformer/config.json · vae/config.json · audio_vae/config.json · *.safetensors.index.json |
| 핵심 파일(코드) | FL2VA/video_vae/klvae.py · vae_vit.py · FL2VA/audio_vae/dac_*.py |
| 프롬프트/스킬 | skills/h3-prompt-writing/references/base-en.txt · ref-en.txt |
| 연관 개념 | DiT · flow-matching · MM-RoPE · AdaLN · CFG distillation · BigVGAN · DAC · Qwen3-VL · Ulysses sequence parallel |
| 이웃 오픈 영상 모델 | Wan · HunyuanVideo · CogVideoX (비교 학습용) |