MiniMax, 영상과 음향을 함께 만드는 33B 옴니모달 모델 H3 웨이트 공개 (단, 한국 사용 금지🫠)

9bow · 8월 4, 2026, 5:00오전

MiniMax H3 소개

MiniMax가 공개한 MiniMax H3 는 텍스트와 이미지, 영상, 음성을 하나의 컨텍스트로 함께 이해하고, 최대 2K 해상도에 최대 15초 길이의 영상을 네이티브 스테레오 음향(Native Stereo Sound) 과 함께 생성하는 범용 옴니모달 생성 모델입니다. 대사와 효과음, 배경음악이 영상 위에 나중에 얹히는 것이 아니라 같은 디노이징 루프에서 함께 나오는 것이 이 모델의 정체성입니다. 별도의 보코더도, 오디오 후처리 단계도 없습니다.

영상 생성 분야는 그간 대형 언어 모델 쪽과 달리 폐쇄형 모델이 주도해 왔고, 그만큼 반복 주기도 느리고 생태계도 좁았습니다. MiniMax는 이 격차를 좁히기 위해 H3의 가중치를 공개(Open Weights) 했고, 실제로 Hugging Face의 MiniMaxAI/MiniMax-H3 저장소에서 33B 규모의 Omni Transformer 체크포인트 두 종을 내려받아 로컬에서 돌릴 수 있습니다. 출시 첫날부터 SGLang과 vLLM, diffusers, ComfyUI의 네 개 서빙 스택이 모두 대응한 것도 눈여겨볼 만한 지점입니다. MiniMax는 앞서 에이전트 전용 언어 모델인 MiniMax M2를 공개한 바 있고, 영상 쪽에서는 Hailuo AI 서비스로 Hailuo 01과 Hailuo 02 두 세대를 운영해 왔습니다.

다만 한국 개발자에게는 반드시 먼저 확인해야 할 조건이 하나 붙습니다. H3의 가중치는 MiniMax H3 Community License로 배포되는데, 이 라이선스가 정의하는 적용 지역(Applicable Territory)에서 대한민국이 명시적으로 제외되어 있습니다. 유럽연합과 영국, 미국도 함께 제외 지역입니다.

라이선스 원문: LICENSE · MiniMaxAI/MiniMax-H3 at main
1. “Excluded Territories” means the European Union, the United Kingdom, the Republic of Korea and the United States of America.

즉, 국내에서 H3 모델의 가중치를 그대로 내려받아 배포하거나 운영하는 것은 현재 라이선스가 허용하는 범위 밖이며, MiniMax의 별도 승인을 받아야 합니다. 주의할 점은 저장소에 접근 게이트가 걸려 있지 않아 기술적으로는 국내에서도 파일이 그대로 내려온다는 것입니다. 다운로드가 되니 괜찮겠다고 판단할 여지가 있는데, 확인해야 하는 것은 오직 라이선스 문구입니다.

다만 이것이 영구적인 차단은 아닙니다. MiniMax는 제한 지역의 조직도 배포 시나리오를 검토받고 적절한 컴플라이언스 통제와 안전장치를 갖췄음이 확인되면 사용 승인을 받을 수 있다고 밝히면서 신청 양식을 함께 공개했습니다. 이 조건과 MiniMax가 밝힌 배경, 그리고 승인 절차는 아래 라이선스 절에서 따로 정리했습니다. 승인 절차를 밟지 않고 바로 쓸 수 있는 경로는 전 세계에서 제약 없이 열려 있는 API이므로, 국내에서는 API가 사실상 기본 선택지가 됩니다.

작업과 모달리티의 경계가 창작을 가로막았다는 진단

H3의 설계를 이해하려면 MiniMax가 앞선 두 세대에서 무엇을 문제로 봤는지부터 짚어야 합니다. Hailuo 01은 시스템을 처음부터 구축하는 단계였고, Hailuo 02는 아키텍처 효율과 데이터 품질, 규모 같은 핵심 구성 요소를 개선하는 데 집중했습니다. 그리고 H3를 설계하면서 MiniMax는 기존 생성 모델들이 작업 경계(Task Boundary) 에 갇혀 있다는 점을 근본적인 한계로 지목했습니다.

실제로 그 파편화는 상당했습니다. 이미지 생성은 텍스트에서 이미지를 만드는 T2I, 편집, 피사체 참조, 모션 참조, 스타일 참조가 각각 별도의 전문가 모델로 갈라져 있었습니다. 음향 생성에서는 음성과 효과음, 음악이 서로 다른 연구 분야로 다뤄졌습니다. 영상 생성은 더 심해서 텍스트에서 영상, 이미지에서 영상, 첫 프레임과 끝 프레임 지정, 피사체 참조, 모션 참조, 음성 참조, 영상 편집이 모두 다른 작업이었고, 그 위에 이미지와 영상과 음향 사이의 경계까지 겹쳐 있었습니다.

이렇게 칸이 나뉜 구조는 두 방향에서 대가를 치릅니다. 사용하는 쪽에서는 하고 싶은 작업마다 다른 모델과 다른 인터페이스를 찾아가야 하니 창작의 자유도가 줄어듭니다. 학습하는 쪽에서는 모델이 일반화할 수 있는 여지 자체가 작업 경계에 의해 잘려 나갑니다. MiniMax가 H3의 첫 번째 설계 원칙으로 "작업 전반의 통합과 일반화" 를 내세운 이유입니다.

이 원칙은 사전학습 단계의 데이터 구성에 그대로 반영됐습니다. H3는 텍스트에서 이미지, 텍스트에서 영상(음향까지 함께 생성하며 모든 음향 출력은 네이티브 스테레오), 네이티브 멀티샷 모델링, 텍스트에서 음향(음성과 효과음, 음악을 분리하지 않고 함께 모델링)을 한 모델 안에서 학습했습니다. 여기에 일반화된 참조 및 편집(Generalized Reference and Editing) 이 더해지는데, 이미지에서 이미지, 이미지에서 영상, 음향에서 음향, 음향과 영상에서 음향과 영상으로 향하는 참조와 편집을 모두 포함합니다.

MiniMax가 이 부분에서 강조한 두 가지 설계 판단이 특히 흥미롭습니다. 첫째, 참조와 편집 데이터를 합성이 아니라 "전부 실제의 자연 데이터로 구축" 해 데이터 확장성을 확보했습니다. 둘째, 참조와 편집의 관계를 고정된 작업 집합으로 묶지 않고 자연어로 표현하게 했습니다. MiniMax는 이 지점을 두고 "언어(넓게는 지능의 구조)가 일반화로 향하는 다리" 라고 표현합니다. 뒤에서 볼 프롬프트 문법이 왜 그렇게 서술적인지가 여기서 설명됩니다.

아키텍처와 학습 전략에 대해 MiniMax가 같은 문장으로 두 번 반복한 원칙도 있습니다. 서로 다른 데이터 유형과 작업을 가능한 한 이른 시점에 융합하고, 그 혼합 비율(mixing ratio) 을 제대로 잡는 것이 핵심이라는 것입니다. 작업별로 학습을 나눈 뒤 나중에 합치는 방식이 아니라, 처음부터 섞어서 일반화를 사전학습 단계의 성질로 만들겠다는 이야기입니다. 다만 MiniMax는 이 단순한 설계 철학을 구현하는 일이 대단히 복잡했다고 인정하면서, Hailuo 01에서 Hailuo 02를 거쳐 H3에 이르는 각 세대가 이전 세대보다 만드는 복잡도가 자릿수 단위로 커졌다고 밝혔습니다.

이런 변화는 학습 패러다임에만 머무르지 않습니다. MiniMax는 창작자들이 단순한 시각적 프롬프트를 입력하는 대신 자신의 의도를 자연어로 직접 서술하는 흐름을 관찰하고 있다고 밝히면서, 멀티모달 이해와 지시 따르기, 복잡한 작업 수행 능력이 계속 향상되면 영상 모델이 "한 클립을 생성하는 것에서 콘텐츠 제작 전 과정에 실질적으로 참여하는 쪽으로" 옮겨 갈 것이라고 전망합니다. H3의 프롬프트가 한 줄짜리 묘사가 아니라 시나리오에 가까운 형태를 띠는 이유가 이 전망과 맞닿아 있습니다.

세 개의 모듈로 나뉜 H3 시스템

H3는 하나의 모델 파일이 아니라 세 개의 모듈이 이어진 시스템입니다. 그리고 오픈 웨이트로 공개된 것은 그중 가운데 한 조각뿐이라는 점을 먼저 알아 두는 편이 좋습니다.

H3-Context-IR 은 자유 형식의 멀티모달 입력을 받아 전처리하고 오케스트레이션하는 호스팅 시스템입니다. 텍스트와 이미지, 음향, 참조 영상 사이의 관계는 물론이고 그 소재들이 만들려는 결과물과 어떤 관계인지까지 해석합니다. 내부 워크플로우는 지시 파싱과 모달리티 간 연관 짓기, 시간적 이해, 복잡한 논리 추론으로 이뤄져 있고, 그 결과를 H3-Base가 받아들이는 구조화된 표현, 즉 컨텍스트 중간 표현(Context Intermediate Representation)으로 직렬화합니다. 사용자의 원래 의도를 벗어나지 않는 범위에서 빠진 의미 정보를 보충하기도 합니다. 다단 워크플로우와 여러 호스팅 모델에 의존하기 때문에 이 모듈은 오픈소스 공개 대상이 아니며, MiniMax는 대신 공식 워크플로우를 재현할 수 있는 API와 프롬프트 작성 가이드를 제공합니다.

H3-Base 는 H3-Context-IR의 출력을 받아 768p 해상도의 영상과 음향을 생성하는 모듈이고, 오픈 웨이트로 공개된 부분이 바로 이것입니다.

H3-Regenerate-2K 는 768p 결과물을 원래의 컨텍스트와 함께 다시 H3에 넣어 2K 해상도로 재생성합니다. 이 모듈도 시스템 복잡도 때문에 아직 공개되지 않았고, MiniMax는 준비되면 공개하겠다고 밝히면서 결과 검증용 API를 제공합니다.

정리하면 로컬에서 온전히 돌릴 수 있는 것은 768p 출력까지이고, 2K 결과를 재현하려면 로컬 H3-Base와 MiniMax 오픈 플랫폼 API를 조합하는 방식을 따라야 합니다. MiniMax는 H3-Context-IR이 최종 출력 품질에 결정적이므로 "생성 파이프라인에 반드시 포함시키거나, 프롬프트 작성 가이드를 따라 직접 컨텍스트 처리 시스템을 구축하라" 고 강하게 권고합니다.

모델 카드는 이 조합을 검증할 수 있도록 세 개의 API 엔드포인트(/video-generation-v2-h3-context-ir, /video-generation-v2-create, /video-generation-v2-regeneration)와 함께, T2VA와 I2VA, Ref2VA 각각에 대해 단계별 요청 스크립트와 기준 결과 영상을 제공합니다. 768p만 로컬로 검증하는 경로에도 세 가지 재현 가능한 사례가 스크립트와 결과 MP4로 함께 올라와 있어서, 자기 배포가 공식 결과와 얼마나 일치하는지 대조해 볼 수 있습니다.

출력 규격과 두 개의 체크포인트

항목	규격
출력 길이	4초에서 15초
프레임레이트	24 FPS 고정
출력 음향	32 kHz 스테레오
기본 해상도	짧은 변 768 픽셀 (2K는 H3-Regenerate-2K로)
화면비	21:9, 16:9, 4:3, 1:1, 3:4, 9:16 등
대사 지원 언어	아랍어, 중국어, 영어, 프랑스어, 독일어, 이탈리아어, 일본어, 한국어, 포르투갈어, 러시아어, 스페인어 11개 언어 안정 지원
프롬프트 길이	최대 7,000자

출력 길이는 소스마다 조금씩 다르게 적혀 있어서 확인이 필요합니다. 모델 카드와 SGLang, vLLM은 모두 4초에서 15초라고 명시하지만, diffusers 문서와 Hugging Face Space는 "체크포인트가 고정하는 값" 으로 5초에서 15초를 적습니다. 프레임 수가 17n+5 격자로 스냅되는 방식 때문에 프레임워크마다 하한 처리가 갈리는 것으로 보이므로, 4초대 짧은 클립을 노린다면 쓰려는 스택의 검증 조건을 먼저 확인하는 편이 안전합니다.

공개된 가중치는 작업별로 나뉜 두 개의 체크포인트입니다. 각 체크포인트는 전용 Omni Transformer와 함께 프로세서, 토크나이저, 텍스트 인코더, 시각 VAE, 독립 오디오 VAE를 모두 담은 자기완결적인 Hugging Face 형식 저장소로 배포되며, 정밀도는 BF16입니다.

체크포인트	지원 작업	입력 조건
MiniMax-H3 Base FL2VA	`t2va`, `fl2va`	텍스트, 선택적으로 첫 프레임 또는 끝 프레임 또는 둘 다
MiniMax-H3 Base Ref2VA	`ref2va`	텍스트와 함께 참조 이미지, 영상, 음향

두 체크포인트 모두 CFG 증류(CFG-distilled) 된 Omni Transformer 가중치입니다. 가이던스가 가중치에 녹아 들어가 있어서 네거티브 프롬프트도, guidance_scale도 없고, 스텝마다 정확히 한 번의 순전파만 돕니다. 뒤에서 볼 서빙 스택들이 하나같이 "CFG 병렬화를 켜지 마라" 고 못 박는 이유가 여기 있습니다. 존재하지 않는 네거티브 분기를 복제하려는 설정이므로 서버가 조용히 무시하는 대신 명시적으로 요청을 거부합니다.

참조 입력의 한도는 다음과 같습니다. 이미지는 최대 9장(변 길이 256에서 5,760 픽셀, 화면비 5:2에서 2:5, 파일당 30MB 이하), 영상은 최대 3개 클립(각 2초에서 15초, 합계 15초 이하, 파일당 50MB 이하), 음향은 최대 3개 클립(각 2초에서 15초, 파일당 15MB 이하)이며, 전체 파일 수는 12개를 넘을 수 없습니다. 음향은 단독 입력으로 쓸 수 없고 반드시 이미지나 영상과 함께 넣어야 합니다. 요청 본문 전체는 64MB 이하로 유지해야 하므로, 큰 파일은 Base64로 인라인하지 말고 공개 URL을 넘기는 편이 안전합니다.

멀티모달 컨텍스트 이해가 실제로 무엇을 뜻하는가

블로그의 대표 예시가 이 모델의 성격을 가장 잘 보여 줍니다. 프롬프트는 "Video 1의 히치콕식 카메라 무빙을 참조하고, Image 2의 인물이 노래하게 하며, 보컬은 Audio 3에 맞춰라" 한 줄입니다. 세 개의 다른 모달리티 소재에 각각 역할을 지정하고, 그 관계를 자연어로만 서술하면 나머지는 모델이 처리합니다.

먼저 카메라 무빙을 제공하는 입력 영상입니다.

다음은 인물의 정체성을 제공하는 입력 이미지입니다.

그리고 보컬을 제공하는 입력 음향입니다.

세 소재와 한 줄 지시로 H3가 만들어 낸 결과물입니다. 카메라 움직임은 첫 영상에서, 인물은 이미지에서, 노래는 음향에서 가져왔습니다.

MiniMax는 이런 능력의 뿌리를 캡셔닝(Captioning) 에서 찾습니다. 멀티모달 컨텍스트가 들어오면서 캡션이 담아야 하는 범위가 크게 넓어졌다는 것입니다. 이제는 만들려는 영상만 묘사하는 것이 아니라 컨텍스트와 목표 영상의 관계, 나아가 컨텍스트 안의 요소들 사이의 관계까지 서술해야 합니다. 영상과 음향을 함께 묘사해야 하고, 그 시청각 관계는 여러 샷에 걸쳐 훨씬 복잡해집니다.

MiniMax는 이것을 맥락적 옴니 표현(Contextual Omni Representation) 이라 부르며, 언어가 일반화 가능한 다리이자 해석기로 작동해 "작업" 을 열린 서술 형태로 통합한다고 설명합니다. 이를 위해 전용 모델과 전모달리티 이해 파이프라인을 따로 구축했고, 소재 하나를 처리하는 데 대략 100K 토큰 규모의 추론이 들어간 뒤 평균 4K 토큰 정도로 압축된다고 밝혔습니다.

2K 해상도 결과물과 네이티브 스테레오 음향을 보여 주는 예시도 함께 공개됐습니다. 먼저 2K 출력입니다.

다음은 스테레오 음향이 어떻게 공간감을 만드는지 확인할 수 있는 예시입니다. 헤드폰으로 들어야 좌우 채널의 차이가 드러납니다.

MiniMax는 광고와 브랜딩, 전자상거래, 제품 디자인, UI/UX, 게임 같은 상업적 콘텐츠 제작에 H3가 바로 쓸 만한 수준이라고 밝히면서, 특히 지시 따르기와 정확한 텍스트 및 브랜드 렌더링, 영상에서 영상으로의 모션 전이(V2V Motion Transfer)를 강점으로 꼽았습니다. 아래는 영화 오프닝 타이틀 예시입니다.

제품 웹사이트용 예시입니다.

정지 이미지를 움직이는 포스터로 만든 예시입니다.

마지막은 광고와 전자상거래용 예시입니다.

H3-Base 아키텍처: 하나의 패킹된 시퀀스에서 영상과 음향이 함께 나온다

H3-Base의 구조는 단순한 아이디어 하나로 요약됩니다. 하나의 트랜스포머가 텍스트 조건과 조건 이미지, 참조 영상과 음향, 그리고 만들어야 할 목표 음향과 목표 영상까지 전부 담은 하나의 패킹된 시퀀스(Packed Multimodal Sequence) 를 전체 셀프 어텐션으로 디노이징합니다.

각 모달리티는 자기에게 맞는 인코더나 VAE로 부호화된 뒤 통합 시퀀스로 묶이고, 토큰 사이의 공간적 시간적 관계는 RoPE(Rotary Position Embedding) 로 표현됩니다. 텍스트는 H3-Encoder가, 시각 입력은 H3-Encoder와 H3-VisualVAE가 함께, 음향은 H3-AudioVAE만 담당합니다. H3-Omni-Transformer가 영상과 음향 잠재 표현을 동시에 예측하고, 그 결과가 각각 영상과 스테레오 음향으로 디코딩됩니다.

H3-Encoder: Qwen3-VL-32B의 50번째 레이어를 꺼내 쓴다

H3-Encoder는 Qwen3-VL-32B의 사전학습 가중치를 그대로 사용하며, 마지막 레이어가 아니라 50번째 디코더 레이어의 정규화되지 않은 은닉 상태를 H3-Omni-Transformer에 넘깁니다. 공개된 체크포인트의 text_encoder/config.json을 보면 언어 모델 쪽이 64개 레이어에 어텐션 헤드 64개, KV 헤드 8개로 되어 있으니, 64개 중 50번째 층의 중간 표현을 꺼내 쓰는 구조입니다. 결과적으로 공개 체크포인트에는 Qwen3-VL의 언어 모델 헤드가 사용되지 않은 상태로 포함되어 있습니다. Qwen3-VL 자체의 능력이 궁금하다면 커뮤니티에 정리된 Qwen3-VL 소개 글을 참고할 만합니다.

토크나이저에는 <d> 같은 특수 토큰이 몇 개 추가되어 있습니다. 뒤에서 볼 대사 표기 문법에 쓰이는 토큰인데, 그래서 H3를 쓸 때는 반드시 H3 저장소가 제공하는 토크나이저와 설정 파일을 써야 합니다.

H3-VAE: 시퀀스 길이를 4배 줄인 토크나이저 전면 개편

H3는 시각과 음향에 각각 별도의 잠재 표현을 씁니다. H3-VisualVAE 는 시간적으로 인과적인(Temporally Causal) 영상 오토인코더로, 공간 압축 16배, 시간 압축 4배, 잠재 채널 24개를 뜻하는 f16t4d24 구성입니다. 트랜스포머에 들어가기 전에 시각 잠재 표현을 (시간, 높이, 너비) 축으로 1 x 2 x 2 패치화하므로, 실제로 트랜스포머가 보는 시각 토큰의 공간 다운샘플링 배율은 32배가 되고 시간 배율은 4배로 유지됩니다.

MiniMax는 H3에서 이전 세대의 토크나이저를 완전히 갈아엎었고, 재구성 품질과 학습 용이성(Learnability) 양쪽에서 개선을 얻었다고 밝혔습니다. 높은 압축률이 유효 시퀀스 길이를 4배 줄여 학습과 추론 비용을 크게 낮췄으며, 네이티브 2K 해상도 지원을 가능하게 한 핵심 기술이라는 설명입니다. 인코더 학습 후에는 디코딩 비용을 줄이고 재구성 품질을 더 높이기 위해 ViT 기반 디코더를 별도로 학습시켰습니다.

H3-AudioVAE 는 좌우 채널에 같은 인코더와 디코더를 쓰면서 각 채널을 독립적으로 처리하고, 디코딩된 채널을 다시 합쳐 스테레오 입출력을 구현합니다. 채널당 32 kHz 음향을 40 Hz 시간 해상도의 잠재 토큰 열로 압축합니다. 잠재 공간 최적화는 VA-VAE의 접근에서 착안했는데, 재구성 품질을 지키면서도 생성 모델이 배우기 쉬운 잠재 공간을 만드는 것이 목표입니다.

H3-Omni-Transformer: 33B 밀집 단일 스트림, 그리고 AdaLN에 숨은 13B

H3-Omni-Transformer는 확장성과 일반화를 위해 상대적으로 단순한 트랜스포머 블록 설계를 택한 33B 파라미터의 밀집(Dense) 단일 스트림 트랜스포머입니다. 이 중 약 13B가 AdaLN(Adaptive Layer Normalization) 관련 분기에 있는데, AdaLN 변조 출력은 미리 계산해 캐시할 수 있으므로 추론만 하는 배포에서는 이 파라미터를 적재할 필요가 없습니다. MiniMax가 파인튜닝 같은 후속 개발을 지원하기 위해 전체 가중치를 공개한 이유입니다.

어텐션 레이어에도 FFN 레이어에도 모달리티별 구조는 들어 있지 않습니다. 모달리티별 파라미터는 입출력 레이어와 AdaLN 분기에만 국한되며, 특히 모달리티별 AdaLN이 상대적으로 적은 추가 비용으로 생성 품질을 끌어올린다는 설명입니다. 공개된 아키텍처 도식과 Hugging Face Space의 구현 기록을 함께 보면 이 공유 DiT 백본은 동일한 블록 50개가 반복되는 구조입니다. 위치 관계는 시간과 두 공간 축, 즉 (t, h, w)를 표현하는 3차원 멀티모달 회전 위치 임베딩(Multimodal Rotary Position Embeddings, MM-RoPE) 으로 다룹니다.

MiniMax가 아키텍처 절에서 특히 강조한 판단은 Hailuo-02의 아키텍처를 의도적으로 버렸다는 점입니다. 그 구조가 한때 상당한 이점을 줬음에도, 작업 일반화를 중심으로 설계하는 모델에는 불필요한 복잡성을 들여온다고 봤기 때문입니다. MiniMax는 "작업 일반화는 되돌릴 수 없는 흐름이며, 아키텍처적 기교는 모델을 어떻게 정의하는지에 자리를 양보해야 한다" 고 썼습니다.

멀티모달 컨텍스트가 들어오면서 시퀀스 길이의 분산이 3배로 커지고 이해와 생성의 연산 부하가 크게 이질적으로 갈렸는데, MiniMax는 이해와 생성 작업 부하를 분리하는 학습 아키텍처를 채택해 각각에 맞게 하드웨어 활용도를 조정했습니다. 샘플별 이질적 연산량과 샘플 간 부하 분산을 함께 균형 잡은 결과 종단간 학습 처리량이 30% 가까이 향상됐다고 합니다.

한 가지 유의할 점은 희소 어텐션(Sparse Attention) 입니다. H3는 학습 마지막 단계에서 긴 시퀀스의 연산 비용을 줄이기 위해 네이티브 희소 어텐션을 도입했지만, 초기 오픈소스 공개본에는 이 구현이 포함되지 않았습니다. 즉 지금 내려받아 쓰는 추론 경로는 전체 어텐션(Full Attention)이며, 희소 어텐션 구현은 이후 별도 업데이트로 공개될 예정입니다.

H3-Regenerate-2K: 초해상 모듈 대신 자기 출력을 다시 생성하기

2K 출력을 만드는 방식이 이 시스템에서 가장 개념적으로 재미있는 부분입니다. H3는 전용 초해상(Super-Resolution) 모듈을 쓰지 않고, H3 베이스 모델이 자신의 저해상도 결과물을 인컨텍스트 방식으로 다시 생성하게 합니다.

여기에는 두 가지 이점이 있습니다. 첫째, 재생성 과정이 H3 베이스 모델에 이미 들어 있는 생성 능력을 최대한 재사용합니다. 둘째, 인컨텍스트 형식이므로 고해상도 출력을 만들 때 원래의 멀티모달 컨텍스트를 다시 참조할 수 있어서, 전통적인 초해상 기법이라면 "추측" 할 수밖에 없고 흔히 복원하지 못하는 정보, 예컨대 작은 글자나 미세한 디테일을 되살릴 수 있습니다. MiniMax는 이 인컨텍스트 재생성 자체가 작업 일반화의 한 사례라고 설명합니다.

가격에 대해서는 MiniMax가 자사 기준으로 밝힌 수치만 있습니다. 2K를 기본으로 제공하면서, 2K에서 초당 가격이 주요 모델들의 3분의 1 미만이고 768p에서는 주요 모델들의 720p 대비 절반 미만이라는 주장인데, 비교 대상 모델을 명시하지 않은 자체 발표이므로 실제 비용은 MiniMax 플랫폼에서 직접 확인하는 편이 정확합니다.

프롬프트 쓰는 방식이 달라진다: 세 개의 필드와 참조 태그

H3-Context-IR이 하는 일은 결국 사용자의 자유 형식 입력을 H3-Base가 이해하는 구조화된 프롬프트로 바꾸는 것입니다. MiniMax가 공개한 프롬프트 작성 가이드를 보면 그 구조화된 프롬프트가 어떻게 생겼는지 알 수 있고, H3-Context-IR을 쓰지 않고 직접 프롬프트를 만들려면 이 문법을 따라야 합니다.

텍스트에서 영상을 만드는 T2VA 기준으로 프롬프트는 세 개의 핵심 필드로 이뤄집니다.

integrated_multimodal_description: [Shot 1] ...

overall_soundscape: ...

non_diegetic_music: ...

integrated_multimodal_description 은 타임라인을 따라 영상과 동작, 샷, 화자, 대사, 노래, 그리고 화면 안에서 발생하는 음향(Diegetic Audio)을 서술합니다. overall_soundscape 는 영상 전체의 환경음과 물리적 동작음, 비언어적 사람 소리를 1개에서 4개 문장으로 요약합니다. non_diegetic_music 은 등장인물은 들을 수 없고 관객만 듣는 배경음악을 서술합니다. 첫 프레임을 지정하는 I2VA나 첫 프레임과 끝 프레임을 함께 지정하는 FL2VA에서는 이 세 필드 앞에 정렬 지시문이 한 줄 더 붙습니다.

For the target video, at 0.00 seconds into the target video, <Picture 1> (from [Shot 1]) is fully referenced.

샷과 컷은 번호와 시각으로 명시합니다. 첫 샷에는 타임스탬프를 붙이지 않고, 이후 샷은 영상 길이 안에서 엄격히 증가하는 컷 시각으로 시작합니다.

[Shot 2] At 00:03.500, the camera cuts to...

카메라 움직임은 동작 유형, 진폭, 속도 세 축으로 표현합니다. 유형은 Zoom In과 Push In, Pan Left, Truck Right, Tilt Up, Pedestal Down, Arc Shot, Tracking Shot, Static Shot, Shake Strongly, POV, Roll Clockwise 등으로 나뉘고, 진폭은 with small amplitude 또는 with large amplitude, 속도는 at slow speed 또는 at fast speed를 씁니다. 중간 진폭과 보통 속도는 생략하는 것이 원칙이고, 라벨을 문장 끝에 나열하는 대신 샷 안의 자연스러운 영어 동작 문장으로 써야 합니다.

The camera pushes in with small amplitude at slow speed toward the folded letter in her hands.

대사는 화자 ID와 <d> 태그로 다룹니다. 말하거나 노래하거나 화면 밖 목소리를 내는 피사체에 (S1), (S2) 같은 안정된 ID를 부여하고, 화자의 식별 정보와 동작, 전달 방식은 <d> 밖에 두고 <d> 안에는 언어 태그와 실제 대사만 넣습니다. 원문의 모든 단어와 문장 부호를 그대로 보존해야 하며 번역하거나 다시 쓰지 않습니다.

The young woman with a quiet, breathy voice (S1) says: <d>[English] I get off at the next station.</d>

같은 대사가 컷을 넘어 이어지면 양쪽 지점에 <scenetrans>를, 영상이 끝나면서 말이 잘리면 <cutoff>를 씁니다. 화면에 실제로 보이는 간판이나 자막, 라벨 같은 텍스트는 영어 큰따옴표로 감싸고 원문 그대로 보존합니다.

음향 쪽 두 필드에는 서술 방식에 제약이 붙습니다. overall_soundscape는 대사와 노래, 화면 내 음악을 여기에 다시 적지 않습니다. 그것들은 이미 멀티모달 서술에 속하기 때문입니다. non_diegetic_music은 1개에서 3개 문장으로 악기 구성과 속도, 리듬, 세기 변화에 집중하고 추상적인 분위기 단어나 음악의 정서적 기능을 설명하는 표현은 쓰지 않습니다. 해당 요소가 없으면 두 필드 모두 N/A를 씁니다.

가이드에 실린 T2VA 완성 예시를 보면 이 규칙들이 어떻게 한 덩어리로 합쳐지는지 분명해집니다.

integrated_multimodal_description: [Shot 1] Live-action, cinematic, a medium-wide shot frames a baker opening the shutters of a small street bakery before sunrise. The camera pushes in with small amplitude at slow speed as the middle-aged baker with a calm, slightly raspy voice (S1) places a fresh loaf on the wooden counter and says: <d>[English] First batch of the morning.</d> [Shot 2] At 00:05.000, the camera cuts to a close-up of steam rising from the sliced bread while the baker's final words carry over from the previous shot.

overall_soundscape: Wooden shutters scrape open over a quiet street as trays clink softly inside the bakery. The doorbell rings once, followed by light footsteps and the crisp sound of bread being sliced.

non_diegetic_music: A soft acoustic-guitar pattern at a moderate tempo, joined by sparse upright-bass notes and a gentle fade at the end.

한 줄짜리 아이디어가 아니라 촬영 콘티에 사운드 디자인 노트를 붙인 문서에 가깝습니다. 앞서 본 H3-Context-IR의 토큰 사용량이 왜 그렇게 큰지도 여기서 납득이 됩니다.

참조를 쓰는 Ref2VA 모드는 별도의 가이드가 있고, 여섯 개 섹션으로 구성됩니다.

섹션	역할
`subject_definitions`	참조된 내용과 그 참조 라벨을 정의
`summary`	작업 유형과 목표 영상, 주요 참조 관계를 요약
`retention_analysis`	참조된 내용이 어떻게 보존, 전이, 재사용되는지 서술
`detailed_description`	재생 순서대로 영상, 동작, 샷, 음향, 대사를 서술
`overall_soundscape`	환경음과 물리적 소리를 요약
`non_diegetic_music`	관객만 듣는 배경음악을 서술

참조 라벨은 네 종류입니다. <Subject N> 은 참조 소재에서 추상화해 목표 영상에서 재사용하거나 수정할 수 있는 시각적 내용(인물, 동물, 사물, 장면, 의상, 소품, 스타일, 동작, 표정, 포즈)을 가리키고, <Picture N> 은 구체적인 목표 프레임이나 샷 기획 앵커로 쓰이는 참조 이미지, <Video N> 은 편집 소스나 이어 붙일 시작점, 전체 영상의 시간 구조를 제공하는 참조 영상, <Audio N> 은 복사되거나 참조되는 음향 신호를 뜻합니다. 라벨의 순서는 의미를 가지므로 같은 참조물을 순서만 바꿔 넣으면 다른 요청이 됩니다.

앞서 MiniMax가 "참조와 편집의 관계를 고정된 작업 집합으로 묶지 않고 자연어로 표현" 하게 했다고 했는데, 그것이 실제로 어떻게 구현되는지가 summary의 작업 유형 접두사에서 드러납니다. 별개의 모델을 고르는 대신 프롬프트 안에 대괄호로 작업 성격을 선언하고, 성격이 겹치면 +로 이어 붙입니다.

작업 유형	쓰는 상황
`keyframe completion`	이미지가 목표 영상의 첫 프레임, 키프레임, 끝 프레임 같은 구체적 프레임 앵커로 쓰일 때
`reference generation`	이미지나 영상, 음향이 인물, 장면, 스타일, 동작, 카메라 무빙, 콘티 등의 생성 가이드를 제공할 때
`video editing`	기존 소스 영상을 직접 수정할 때
`video continuation`	기존 소스 영상에서 이어지거나 확장, 재개, 전환할 때
`audio reuse`	같은 음향 신호를 전체 또는 일부 재사용할 때
`audio reference`	음향을 복사하지 않고 음악 스타일, 음색, 대사 내용, 효과음 질감, 비트, 연속성만 참조할 때

예를 들어 소스 영상을 이어 붙이면서 이미지를 끝 프레임으로 쓰면 [video continuation + keyframe completion]이 되고, 소스 영상을 편집하면서 원래 음향을 그대로 남기면 [video editing + audio reuse]가 됩니다. 가이드는 여기서 흔한 오해도 짚습니다. 영상이나 음향이 입력에 들어 있다는 사실만으로 해당 작업 유형이 생기지는 않습니다. 참조 영상이 카메라 무빙과 컷, 리듬만 제공한다면 그것은 video editing이 아니라 reference generation입니다.

retention_analysis에서는 각 참조물이 결과에 어떻게 남는지를 고정된 영어 값으로 표기합니다. 시각적 내용(<Subject N>, <Picture N>, <Video N>)에는 완전히 보존되면 fully_preserved, 일부 특성만 유지되면 partially_preserved, 참조한 특성이 다른 대상으로 옮겨지면 attribute_transfer, 스타일이나 분위기 수준의 넓은 유사성만 남으면 weak_reference를 씁니다. 음향은 별도의 표기 체계를 쓰는데, 모델 카드의 Ref2VA 예시를 보면 인물과 소스 영상이 fully_preserved인 반면 재사용된 배경음악은 partially_copy, 음색만 참조한 목소리는 reference로 적혀 있습니다. 결국 "이 참조를 얼마나 지킬 것인가" 를 모델에게 명시적으로 알려 주는 장치입니다.

이 구조화된 프롬프트가 얼마나 상세한지는 실제 토큰 사용량이 잘 보여 줍니다. 모델 카드에 실린 H3-Context-IR 응답 예시를 보면, 텍스트만 넣은 T2VA에서 총 8,565 토큰, 첫 프레임 이미지를 더한 I2VA에서 22,822 토큰, 영상과 음향 참조를 함께 넣은 Ref2VA에서 39,299 토큰을 소비했습니다. 즉 한 줄 지시가 수천 단어 규모의 시청각 시나리오로 확장된 뒤 H3-Base에 전달되는 구조입니다.

로컬에서 돌리기: 네 개의 서빙 스택

H3는 출시와 동시에 네 개의 스택에서 돌아갑니다. 다만 각 스택이 커버하는 범위와 검증 수준이 다르므로, 목적에 따라 고르는 편이 좋습니다.

스택	강점	유의할 점
SGLang	하드웨어별 실측 레시피가 가장 넓음(B300, B200, H200, H100, MI300X, MI355X, RTX 5090). 품질 프로파일 4단계 제공	서버 프로세스 하나가 체크포인트 한 종만 적재
vLLM	4×B300 정확도 검증 경로, 텍스트 인코더 텐서 병렬화, VAE 패치 병렬화	768p 모드 미지원(1,440 픽셀 짧은 변으로 생성), FP8 미지원, 참조 조합 제한
diffusers	12GB에서 16GB급 소비자 GPU까지 내려가는 양자화 및 오프로딩 레시피	아직 정식 릴리즈 미포함(PR에서 설치), Modular Diffusers 블록만 제공
ComfyUI	GUI 워크플로우 템플릿 3종, 노드 조합으로 확장	기본 가중치가 원본 BF16이 아닌 양자화본(pruned int8 + NVFP4 AWQ), 템플릿은 예시일 뿐 전체 모드를 다 담지 않음

SGLang: 품질 프로파일과 하드웨어별 실측

SGLang의 MiniMax-H3 쿡북은 하드웨어와 배포 프로파일, 체크포인트 파티션, 요청 모드를 고르면 실행 명령을 생성해 주는 대화형 선택기를 제공합니다. 쿡북에 실린 모든 하드웨어와 토폴로지 조합은 해당 GPU 모델에서 실제 요청을 완료한 것들입니다.

sglang serve \
  --model-path MiniMaxAI/MiniMax-H3 \
  --num-gpus 4 \
  --ulysses-degree 4 \
  --performance-mode speed \
  --host 0.0.0.0 \
  --port 30010 \
  --model-variant fl2va

여기서 --model-path에 루트 모델 ID를 그대로 넘기는 것에 주목할 만합니다. SGLang이 체크포인트 디렉토리 매핑을 직접 관리하므로 수동으로 내려받은 하위 디렉토리를 가리키면 안 되고, 파티션 선택은 --model-variant가 담당합니다. fl2va가 t2va와 fl2va 둘 다를 서빙하고, ref2va는 참조 조건 요청을 담당합니다. Hugging Face 대신 ModelScope를 쓰려면 명령 앞에 SGLANG_USE_MODELSCOPE=true를 붙이고 모델 경로를 MiniMax/MiniMax-H3로 바꾸면 되며, 나머지 변형과 토폴로지 플래그는 그대로 둡니다.

Ref2VA를 서빙하려면 --model-variant ref2va로 바꿔 별도 프로세스를 띄웁니다. 블로그가 강점으로 꼽은 영상에서 영상으로의 모션 전이(V2V) 도 별도의 작업 값이 아니라 ref2va에 영상 참조를 넣는 방식입니다. 입력이 무음일 수 있으면 type: "video"를 쓰고, 사운드트랙이 있으면 H3가 그것도 음향 참조로 함께 씁니다. 두 스트림이 모두 필수일 때만 type: "video_audio"를 쓰는데, 이 형태는 음향이 없는 입력을 거부합니다. 긴 소스에서 구간을 고를 때는 conditions[].start_time_seconds를 쓰면 SGLang이 영상과 사운드트랙을 같은 지점으로 함께 이동시킨 뒤 필요한 길이만 한 번에 디코딩합니다. 중간 클립으로 재인코딩하지 않는다는 점이 실무에서 편한 지점입니다.

병렬화는 Ulysses 시퀀스 병렬화가 기본 축이고, H3의 패킹된 다중 세그먼트 어텐션과 호환되지 않는 Ring 방식은 쓸 수 없습니다. 텐서 병렬화는 TP 로컬 헤드 수가 Ulysses 차수로 나누어질 때 함께 쓸 수 있습니다.

가장 실용적인 기능은 요청 단위로 고를 수 있는 품질 프로파일입니다. quality 필드로 네 단계를 선택하는데, 승인된 Cache-DiT 정책을 배치 경계에서 붙이거나 떼는 방식이라 서버 하나가 네 프로파일을 모두 전환할 수 있습니다.

`quality`	평균 추론 지연	속도 향상	lossless 대비 SSIM	lossless 대비 PSNR
`lossless`	75.10초	1.00배	1.000	정확히 동일
`high`	53.70초	1.40배	0.931	28.16 dB
`medium`	30.23초	2.48배	0.818	20.40 dB
`low`	25.81초	2.91배	0.794	19.25 dB

측정 조건은 4×H200에서 1344×768, 124프레임, 24fps T2VA에 추론 스텝 50, 영상 flow shift 12, 음향 flow shift 3이며 프롬프트와 시드 조합 세 쌍의 평균입니다. SGLang 문서는 이 SSIM과 PSNR이 절대적 지각 품질이 아니라 같은 시드에서의 궤적 이탈을 재는 지표임을 분명히 합니다. 근사 프로파일이 다른 결과를 내놓더라도 그 자체로 그럴듯한 영상일 수 있다는 뜻입니다. 또한 두 지표는 영상만 다루는데 프로파일은 영상과 음향의 결합 디노이징 궤적을 함께 바꿉니다.

하드웨어별 실측 중 인상적인 것들을 꼽아 보면, 8×B300에서 FL2VA를 BF16으로 돌릴 때 5.167초 길이 1344×768 50스텝 요청이 19.04초에 완료되며 GPU당 최대 메모리는 83,578MB입니다. 온라인 FP8 양자화를 켜면 18.03초에 51,926MB로 떨어져, 지연은 5% 정도 줄면서 메모리는 38% 가까이 절약됩니다. Ref2VA는 참조 처리 때문에 같은 조건에서 29.12초로 늘어납니다.

4×H200에서는 순수 Ulysses4가 종단간 84.14초였는데, --warmup-resolutions 1344x768로 워밍업을 서빙 해상도에 맞추면 74.38초로 줄어듭니다. 첫 요청의 콜드 스타트가 이 워크로드에서 10초 가까이 되므로, 워밍업 해상도를 맞추는 것만으로 얻는 이득이 토폴로지 선택보다 큽니다. TP2 + Ulysses2는 5% 정도 느리지만 GPU당 최대 메모리가 약 30GB 낮아서, 80GB H100에서는 이쪽이 권장 레시피입니다.

가장 눈에 띄는 것은 소비자 GPU 경로입니다. 2×RTX 5090(각 32GB) 에서 TP2와 레이어별 오프로딩을 쓰면 50스텝 1344×768 5초 요청이 559.67초에 완료됩니다. 디노이징 525.05초에 디코딩 33.61초, GPU당 최대 메모리는 26.3 GiB입니다. 레이어별 배치는 파라미터 위치와 전송 스케줄만 바꾸고 BF16/FP32 디노이징이나 VAE 연산은 건드리지 않으므로 무손실입니다. 다만 호스트 메모리를 384 GiB급으로 갖춘 머신을 전제로 검증된 레시피입니다.

AMD 쪽도 검증됐습니다. MI355X 8장에서 T2VA 디노이징 55.29초, MI300X 8장에서 167.49초이며, AITER 패킹 어텐션이 세그먼트별 BF16 SDPA와 코사인 유사도 0.9999991655(MI355X) 및 0.9999991059(MI300X)로 일치했습니다.

주의할 설정도 몇 가지 있습니다. --performance-mode speed가 DiT를 의도적으로 eager로 유지하는데, 현재 torch.compile 경로가 모델의 수치적 출력을 바꾸기 때문에 어떤 무손실 프리셋도 이를 암묵적으로 켜지 않습니다. 일관성 기준값을 만들 때는 반드시 eager BF16/FP32 실행을 써야 합니다. VAE는 공개된 품질 레시피인 겹치는 타일 디코드만 지원하고, spatial 및 spatial_shard 병렬 디코드 모드는 출력 불일치가 확인되어 거부됩니다.

vLLM: 정확도 검증 경로와 텍스트 인코더 샤딩

H3 지원은 vllm 휠이 아니라 vLLM-Omni에 들어 있습니다. Docker 이미지에는 H3 핸들러와 FlashAttention-4 커널이 함께 들어 있어 별도 설치가 필요 없습니다.

docker pull vllm/vllm-omni:minimax-h3

pip 경로를 쓴다면 소스 체크아웃이 필요합니다. [fa4] 엑스트라가 CuTe-DSL 기반 FlashAttention-4 커널을 설치하는데, CUDA 전용이며 Blackwell에서 쓰입니다.

uv venv
source .venv/bin/activate
uv pip install vllm==0.26.0
git clone https://github.com/vllm-project/vllm-omni.git
cd vllm-omni
uv pip install -e '.[fa4]'

주의할 점은 H3가 Hugging Face ID가 아니라 로컬 디렉토리에서 서빙된다는 것입니다. 체크포인트의 두 파티션이 하위 디렉토리이고, 서버 프로세스 하나가 그중 하나만 적재합니다. 그래서 먼저 내려받아야 합니다.

hf download MiniMaxAI/MiniMax-H3 --local-dir /path/to/MiniMax-H3

이렇게 하면 /path/to/MiniMax-H3/FL2VA와 /path/to/MiniMax-H3/Ref2VA가 생기고, vllm serve에 그중 하나의 경로를 직접 지정합니다. 이 지점이 SGLang과 정확히 반대라는 점을 기억해 두면 좋습니다. SGLang은 체크포인트 디렉토리 매핑을 스스로 관리하므로 "수동으로 내려받은 하위 디렉토리를 --model-path로 가리키지 말라" 고 명시하고 루트 모델 ID를 받습니다. 같은 모델인데 두 스택의 경로 규약이 정반대이니 레시피를 섞어 쓰면 바로 막힙니다. 이 밖에 ffmpeg와 ffprobe가 PATH에 있어야 참조 영상 준비와 MP4 먹싱이 동작합니다.

한 가지 덧붙이면, vLLM 레시피는 "모델 카드에서 접근 권한을 신청하라(저장소가 게이트되어 있다)" 고 안내하지만 2026년 8월 4일 확인 기준으로 저장소에는 게이트가 걸려 있지 않아 신청 절차 없이 바로 내려옵니다(Hugging Face API가 gated: False를 반환).

CUDA_VISIBLE_DEVICES=0,1,2,3 \
FLASHINFER_DISABLE_VERSION_CHECK=1 \
VLLM_WORKER_MULTIPROC_METHOD=spawn \
VLLM_OMNI_VIDEO_SYNC_TIMEOUT=1800 \
vllm serve /path/to/MiniMax-H3/FL2VA \
  --omni \
  --host 0.0.0.0 \
  --port 8000 \
  --trust-remote-code \
  --num-gpus 4 \
  --usp 4 \
  --ring 1 \
  --vae-patch-parallel-size 4 \
  --vae-parallel-mode tile \
  --vae-use-tiling \
  --diffusion-attention-backend FLASH_ATTN

4×B300에서 FL2VA 209프레임 1248×768(8.7초) 요청이 클라이언트 기준 종단간 86.96초에 완료됐고, 단계별 분해가 병목을 명확히 보여 줍니다. 텍스트 인코더 0.21초, 시각 인코더 0.20초, DiT 79.1초로 요청의 88% 를 차지하고, 영상과 음향 VAE 디코드가 2.40초입니다. VAE 패치 병렬화는 디코드를 8.24초에서 2.40초로 3.4배에서 3.5배 줄이는 가장 값싼 개선입니다. 두 개 영상을 참조하는 Ref2VA 사례를 스택 프로파일링한 결과는 파이프라인이 호스트가 아니라 GPU 어텐션에 묶여 있음을 보여 줍니다. FlashAttention-4가 diffuse 디바이스 시간의 약 76%이고 GPU 활용률은 92.8%에서 94.3%, 트랜스포머 순전파 내부의 CPU 유휴 구간 합집합은 3.15%에 불과합니다.

기본 설정에서는 Qwen3-VL 인코더 전체가 DiT 메인 랭크에 상주해 최대 메모리의 병목이 됩니다. --text-encoder-tp-size N으로 첫 N개 DiT 랭크에 샤딩하면, 4개 GPU에서 N=4일 때 랭크당 엔진 최대 메모리가 133GB에서 103GB로 내려가면서 측정 가능한 처리량 손실이 없습니다. 수치적으로는 N=1이 Hugging Face 참조 경로를 비트 단위로 재현하고(max_abs = 0), N=4는 행 병렬 올리듀스를 FP32로 처리해 BF16 반올림만 유입되어 종단간 PSNR 31.11 dB, SSIM 0.9566을 보입니다.

체크포인트 자체의 참조 구현과 비교한 정확도는 T2VA와 FL2VA에서 SSIM 0.9873에서 0.9896, PSNR 39에서 42 dB, 픽셀 코사인 0.9996 이상, 음향 로그 멜 코사인 0.977에서 0.996입니다. Cache-DiT는 명시적 옵트인인데, 50스텝 T2VA 실험에서 디노이즈 시간을 30.2%(121.01초에서 84.47초) 줄였지만 SSIM이 0.831로 떨어졌습니다.

vLLM 문서는 알려진 제약도 솔직하게 나열합니다. 서빙 경로가 모델이 지원하는 것보다 적은 참조를 받습니다. H3는 옴니 참조 요청당 이미지 9장과 영상 3개, 음향 3개까지 문서화하지만, 현재 vLLM-Omni 경로는 이미지 1장에 음향 1개, 또는 별도 audio_reference 없이 영상 하나 이상(소스 사운드트랙을 사용)만 받습니다. 768p 모드가 아직 없어서 1,440 픽셀 짧은 변으로 생성해야 하고, FP8 양자화도 미지원입니다. 8×64GB 구성은 OOM이 나는데, --usp 8 --ring 1 --tp 1에서 66.3GB DiT가 랭크마다 복제되어 --text-encoder-tp-size 8을 써도 활성화 전에 랭크당 83.3GB가 남기 때문입니다. 이 경우 인코더 TP는 필요하지만 충분하지 않고 DiT TP를 2 이상 두거나 HSDP 또는 CPU 오프로딩이 함께 필요합니다.

diffusers: 소비자 GPU까지 내려가는 양자화 레시피

diffusers 통합은 아직 정식 릴리즈에 포함되지 않아 PR에서 설치해야 합니다.

pip install git+https://github.com/huggingface/diffusers.git@refs/pull/14355/head

이 통합은 아직 움직이는 표적입니다. 위 문서가 붙어 있는 PR #14355 (Add MiniMax-H3)는 초안(draft) 상태이고, 그 뒤로 PR #14371 (review & refactor)이 별도로 열려 작업 중입니다. 뒤에서 볼 Hugging Face Space는 후자를 특정 커밋에 고정해 설치하면서, 그 PR이 WIP이므로 갱신될 때마다 다시 고정해야 한다고 밝힙니다. 정식 릴리즈에 들어가기 전까지는 API가 바뀔 수 있다고 보는 편이 안전합니다.

H3는 Modular Diffusers 블록으로만 통합되어 있고 DiffusionPipeline 쪽 절반이 없습니다. 변환된 저장소는 두 체크포인트 파티션을 하나로 합치면서, 트랜스포머를 뺀 나머지(영상 VAE, 음향 VAE, Qwen3-VL 조건기, 토크나이저, 프로세서, 두 스케줄러)를 공유해 한 번만 저장합니다. transformer/는 t2va와 fl2va를, transformer_ref/는 ref2va를 담당하며 각 블록셋이 자기가 쓰는 컴포넌트만 내려받습니다.

import torch
from diffusers import ModularPipeline
from diffusers.modular_pipelines import MiniMaxH3Ref2VABlocks

# `t2va` / `fl2va`: loads `transformer/`, and never `transformer_ref/`.
pipe = ModularPipeline.from_pretrained("MiniMaxAI/MiniMax-H3")

# `ref2va`: loads `transformer_ref/`, and never `transformer/`, out of the same repository.
pipe = MiniMaxH3Ref2VABlocks().init_pipeline("MiniMaxAI/MiniMax-H3")

pipe.load_components(dtype=torch.bfloat16)

영상과 음향 잠재 표현은 트랜스포머 호출 한 번 안에서 서로 다른 두 스케줄을 따라 내려갑니다. 그래서 두 블록셋 모두 MiniMaxH3Scheduler 인스턴스를 두 개 기대하는데, 영상 잠재용 scheduler는 공개 체크포인트에서 shift=12.0, 음향 잠재용 audio_scheduler는 shift=3.0입니다.

생성 제약도 명확합니다. 24fps에 5초에서 15초이며, num_frames는 영상 VAE가 디코딩할 수 있는 다음 17 * n + 5 값으로 올림됩니다. 예를 들어 15초에 가까운 요청은 362프레임, 즉 15.083초가 됩니다. 높이와 너비는 32의 배수여야 하고, 첫 키프레임의 화면비에 맞춘 H3 자체의 캔버스가 기본값이 됩니다. 시드 하나로 키프레임 또는 참조 조건 노이즈, 영상 노이즈, 음향 노이즈를 순서대로 뽑기 때문에 같은 제너레이터 상태에서 두 번 실행하면 같은 영상과 사운드트랙이 나옵니다. 사소하지만 걸리기 쉬운 함정으로, num_inference_steps는 시그마 격자의 점 개수를 세고 마지막 0도 포함하므로 실제 모델 평가 횟수는 그보다 하나 적습니다.

메모리가 이 통합의 핵심 주제입니다. 트랜스포머만 bfloat16으로 61.7GB이고 Qwen3-VL 조건기가 다시 62.1GB이므로, 적재 방식이 하드웨어에 따라 완전히 달라집니다. diffusers 문서는 "모든 구성에서 가장 큰 속도 레버는 작은 캔버스" 라고 짚으면서, 960×544가 학습 해상도인 1344×768보다 스텝당 약 2.3배 빠르다고 밝힙니다.

80GB 카드 한 장이라면 컴포넌트를 ComponentsManager에 등록해 가속기와 CPU 사이를 오가게 합니다.

import torch
from diffusers import ComponentsManager, ModularPipeline

manager = ComponentsManager()
pipe = ModularPipeline.from_pretrained("MiniMaxAI/MiniMax-H3", components_manager=manager)
pipe.load_components(dtype=torch.bfloat16)
manager.enable_auto_cpu_offload(device="cuda", memory_reserve_margin="12GB")
pipe.transformer.set_attention_backend("_flash_3_hub")  # Hopper, roughly 3x faster; kernels fetched from the Hub

24GB에서 32GB급 소비자 카드에서는 두 개의 큰 컴포넌트를 적재 시점에 int8로 양자화하고 트랜스포머 블록을 CPU 메모리에서 스트리밍합니다. torchao의 Int8WeightOnlyConfig와 diffusers의 그룹 오프로딩을 조합하는 방식이며, 지원되는 로더만 쓰고 별도 패치 없이 bfloat16 체크포인트에서 바로 동작합니다.

import torch
from diffusers import MiniMaxH3Transformer3DModel, ModularPipeline, TorchAoConfig
from diffusers.hooks import apply_group_offloading
from transformers import Qwen3VLForConditionalGeneration
from transformers import TorchAoConfig as TransformersTorchAoConfig
from torchao.quantization import Int8WeightOnlyConfig

pipe = ModularPipeline.from_pretrained("MiniMaxAI/MiniMax-H3")
pipe.update_components(
    transformer=MiniMaxH3Transformer3DModel.from_pretrained(
        "MiniMaxAI/MiniMax-H3", subfolder="transformer", dtype=torch.bfloat16,
        quantization_config=TorchAoConfig(
            Int8WeightOnlyConfig(version=2),
            modules_to_not_convert=[
                "proj_in", "audio_proj_in", "context_embedder", "time_embedder", "time_proj",
                "token_refiner", "norm_out", "proj_out", "audio_proj_out",
            ],
        ),
        low_cpu_mem_usage=False,
    ),
    text_encoder=Qwen3VLForConditionalGeneration.from_pretrained(
        "MiniMaxAI/MiniMax-H3", subfolder="text_encoder", dtype=torch.bfloat16,
        quantization_config=TransformersTorchAoConfig(
            Int8WeightOnlyConfig(version=2),
            modules_to_not_convert=["model.visual", "model.language_model.embed_tokens", "model.language_model.norm", "lm_head"],
        ),
    ),
)
pipe.load_components(dtype=torch.bfloat16)

# version=2 int8 tensors are pinnable, which streamed offload needs, and freezing removes the one autograd
# path the quantized tensors cannot serve.
pipe.transformer.requires_grad_(False)
pipe.text_encoder.requires_grad_(False)

offload = dict(onload_device=torch.device("cuda"), offload_device=torch.device("cpu"), use_stream=True)
pipe.transformer.enable_group_offload(offload_type="block_level", num_blocks_per_group=1, **offload)
apply_group_offloading(pipe.text_encoder.model, offload_type="leaf_level", **offload)
pipe.vae.to("cuda")
pipe.audio_vae.to("cuda")

12GB에서 16GB에서도 같은 레시피에 영상 VAE까지 그룹 오프로딩하고 960×544 같은 작은 캔버스를 쓰면 동작합니다. 대신 가중치가 호스트 메모리에 상주하므로 int8에서도 75GB 내외의 시스템 메모리를 예상해야 합니다. 카드가 두 장이면 오프로딩이 아예 필요 없습니다. device_map으로 조건기를 두 번째 카드에 올리고 디노이저가 첫 번째 카드를 차지하면, 80GB 두 장은 완전한 bfloat16으로, 48GB 두 장은 두 컴포넌트를 int8로 적재해 스트리밍 없이 돌아갑니다.

실제 생성 코드는 단순합니다. 영상과 음향이 videos와 audio로 따로 나오고 사운드트랙의 sampling_rate가 함께 오므로, 하나의 파일로 먹싱하는 것은 호출자의 몫입니다.

from diffusers.utils.export_utils import encode_video

prompt = "A red fox trotting through a snowy pine forest, snow crunching underfoot"
state = pipe(prompt=prompt, generator=torch.Generator().manual_seed(42))

encode_video(
    state.get("videos")[0],
    fps=24,
    output_path="minimax_h3_fl2va.mp4",
    audio=state.get("audio")[0],
    audio_sample_rate=state.get("sampling_rate"),
)

참조를 쓰는 쪽은 MiniMaxH3Reference 객체의 순서 있는 목록을 넘깁니다. 순서가 프롬프트 안의 <Picture 1>, <Audio 1>, <Video 1> 라벨과 대응하고 공유되는 음향 및 영상 회전 클럭을 진행시키므로, 같은 참조물의 순서를 바꾸면 다른 요청이 됩니다. 경로나 URL은 물론 메모리 안의 미디어도 받는데, 경로를 넘기면 이미지는 load_image로, 영상과 음향은 PyAV로 참조가 만들어지는 시점에 디코딩됩니다. 키프레임과 달리 참조는 생성될 영상의 기하 구조를 결정하지 않고 자기 해상도로 인코딩되며, 목표 캔버스는 H3의 16:9 기본값이 됩니다.

ComfyUI: GUI에서 세 가지 워크플로우로

ComfyUI 튜토리얼에 따르면 ComfyUI 0.30.0 이상으로 업데이트한 뒤 템플릿 라이브러리의 Video 항목에서 MiniMax H3 워크플로우를 고르면 됩니다. 모델 파일은 Hugging Face의 Comfy-Org/MiniMax-H3 저장소에 있습니다. 템플릿은 텍스트에서 영상(T2V), 이미지에서 영상(I2V), 참조에서 영상(R2V) 세 가지이고, 이것은 예시일 뿐 네이티브 노드인 MiniMaxH3ImageToVideo와 MiniMaxH3ReferenceToVideo로 더 많은 조합을 만들 수 있습니다.

여기서 짚어야 할 중요한 사실이 있습니다. ComfyUI 템플릿이 내려받는 기본 가중치는 원본 BF16이 아니라 양자화본입니다. Comfy-Org 저장소는 같은 모델을 여러 정밀도로 함께 배포하는데, 템플릿 기본값은 DiT는 pruned_int8_convrot, 텍스트 인코더는 nvfp4_awq입니다.

파일	크기	역할
`minimax_h3_{fl2va,ref2va}_bf16.safetensors`	66.28 GB	원본 정밀도 DiT
`minimax_h3_{fl2va,ref2va}_int8_convrot.safetensors`	34.04 GB	int8 DiT
`minimax_h3_{fl2va,ref2va}_pruned_int8_convrot.safetensors`	20.97 GB	템플릿 기본값
`minimax_h3_{fl2va,ref2va}_pruned_fp8_scaled.safetensors`	20.96 GB	fp8 대안
`qwen3vl_32b_minimax_h3_bf16.safetensors`	51.51 GB	원본 정밀도 텍스트 인코더
`qwen3vl_32b_minimax_h3_int8_convrot.safetensors`	27.14 GB	int8 텍스트 인코더
`qwen3vl_32b_minimax_h3_nvfp4_awq.safetensors`	15.69 GB	템플릿 기본값
`minimax_h3_video_vae_fp16.safetensors`	5.21 GB	시각 VAE
`minimax_h3_audio_vae_fp32.safetensors`	0.61 GB	오디오 VAE

이 숫자들이 앞서 본 아키텍처 설명과 정확히 맞물립니다. BF16 DiT 66.28GB는 33B 파라미터에 2바이트를 곱한 값이고, vLLM 문서가 말한 "66.3GB DiT" 와 같은 것입니다. int8로 내리면 절반인 34.04GB가 되는데, pruned 변형은 여기서 다시 20.97GB로 떨어집니다. 1바이트당 1파라미터로 환산하면 약 21B이고, 이는 33B에서 AdaLN 분기의 13B를 덜어낸 20B와 거의 일치합니다. 앞서 본 대로 AdaLN 변조 출력은 미리 계산해 캐시할 수 있어서 추론만 하는 배포에는 적재할 필요가 없는데, Comfy-Org의 pruned 변형이 정확히 그 여지를 실제로 활용한 빌드인 셈입니다. 파인튜닝을 하려면 원본 BF16 파일을 써야 합니다.

각 파일의 배치 경로는 다음과 같습니다.

ComfyUI/
├── 📂 models/
│   ├── 📂 diffusion_models/
│   │   └── minimax_h3_fl2va_pruned_int8_convrot.safetensors
│   ├── 📂 text_encoders/
│   │   └── qwen3vl_32b_minimax_h3_nvfp4_awq.safetensors
│   └── 📂 vae/
│       ├── minimax_h3_video_vae_fp16.safetensors
│       └── minimax_h3_audio_vae_fp32.safetensors

즉 ComfyUI 경로는 다른 세 스택과 성격이 다릅니다. SGLang과 vLLM은 BF16/FP32 수치를 보존하는 무손실 경로를 기본으로 놓고 근사를 옵션으로 제공하지만, ComfyUI 템플릿은 처음부터 양자화된 빌드를 기본으로 받아 소비자 GPU에서 돌아가는 것을 우선합니다. 품질 기준값을 만들거나 다른 스택과 결과를 비교할 목적이라면 이 차이를 고려해야 합니다.

해상도는 Resolution Selector 노드가 화면비와 메가픽셀, 배수 세 가지 설정으로 계산합니다. 배수는 H3의 해상도 격자에 맞추기 위해 32로 두고, 온전한 품질을 원하면 16:9에서 메가픽셀을 1.0 정도로 올려 대략 1344×768을 얻으라고 안내합니다. 지속 시간 입력은 24fps에서 모델의 17프레임 블록 격자(17k+5)로 스냅됩니다.

속도를 대략 두 배로 올리는 옵션으로 Sage Attention이 소개되어 있습니다. sageattention 패키지를 설치하고 KJNodes가 제공하는 Patch Sage Attention KJ 노드를 UNETLoader와 BasicGuider 사이에 연결하는 방식입니다. H3가 일부 레이어를 float16이나 bfloat16이 아닌 dtype으로 돌리기 때문에 콘솔에 표준 어텐션으로 되돌아간다는 메시지가 뜨는데, 이는 정상이며 해당 레이어만 폴백하고 생성은 계속됩니다.

참조 워크플로우에서 특히 유용한 조언이 두 가지 있습니다. 첫째, 각 참조에 어떤 역할을 맡길지 명시하라는 것입니다. 어떤 참조가 정체성을, 어떤 참조가 스타일이나 모션, 카메라, 목소리를 담당하는지 명시적으로 지정하면 결과가 훨씬 좋아진다고 합니다. 둘째, ref_image_size 설정에서 match는 참조를 생성 해상도로 줄여 속도를 얻고 max는 최대 2,048 픽셀 짧은 변까지 유지해 정체성 충실도를 높입니다. 샘플러는 참조가 많은 프롬프트에서 simple보다 res_multistep에 beta 또는 normal 스케줄러 조합이 낫다는 것이 튜토리얼의 권고입니다.

Hugging Face Space에서 먼저 확인해 보기

가중치를 내려받기 전에 결과물을 확인해 보고 싶다면 multimodalart/minimax-h3 Space를 쓸 수 있습니다. 이 데모의 구현 방식 자체가 H3의 크기를 잘 설명해 줍니다.

H3는 bfloat16으로 195.9 GiB이고 ZeroGPU Space는 저장 용량 150GB에서 축출되기 때문에, 양자화하지 않은 단일 Space는 애초에 불가능합니다. 그래서 이 데모는 MiniMaxH3Blocks 시퀀스를 text_encoder 단계에서 잘라 두 개의 Space로 나눴습니다. 62.14 GiB의 Qwen3-VL 조건기는 qwen3vl-conditioner Space가 담당하고, 61.73 GiB의 트랜스포머와 두 오토인코더는 본체 Space가 담당하면서 매 요청마다 Gradio API로 앞쪽을 호출합니다. 양쪽 모두 양자화 없이 온전한 bfloat16입니다.

흥미로운 결과는 양자화하지 않은 쪽이 오히려 빨랐다는 점입니다. 95.0 GiB 카드에 72.16 GiB의 가중치가 올라가면 요청 경로에 오프로딩이 전혀 없기 때문에, 4비트 Space가 자동 오프로딩 트래픽 때문에 스텝당 19초에서 21초를 쓰는 동안 이 Space는 스텝당 10.6초를 기록했습니다. 여기에 50개 반복 트랜스포머 블록을 AoTI로 컴파일한 패키지를 붙이면 스텝당 거의 일정하게 0.5초 정도의 커널 실행 오버헤드가 제거되는데, 행렬 곱 자체는 건드리지 못하므로 연산 바운드가 아닌 작은 캔버스에서 이득이 큽니다. 768×1344에서 4.6%, 640×1152에서 9.1%, 544×960에서 11.0% 빨라졌습니다.

같은 실리콘(RTX PRO 6000 Blackwell, sm120, 95.0 GiB)에서 1344×768, 124프레임, 30스텝을 돌린 실측은 다음과 같습니다.

항목	값
`load_components` (77.3GB, warm Xet)	43초
`.to("cuda")` 1회	10초
상주 가중치	72.16 GiB
디노이즈와 디코드	317초, 스텝당 10.58초
최대 할당 및 예약 메모리	78.54 / 85.37 GiB
출력	h264 1344×768 24fps 5.167초 + 스테레오 AAC 32 kHz

이 Space를 실제로 호출한 수치가 더 흥미롭습니다. 텍스트만 18토큰 넣은 요청은 조건기 7초에 디노이즈와 디코드 339초로 스텝당 10.53초, 왕복 353초였습니다. 여기에 768×1344 키프레임 한 장을 더해 1,034토큰이 되면 조건기 9초에 디노이즈와 디코드 370초로 스텝당 11.39초가 됩니다. 키프레임 한 장이 스텝당 약 8%의 비용을 더한다는 뜻인데, 그 이유가 앞서 본 패킹된 시퀀스 구조를 그대로 설명합니다. 키프레임은 프롬프트 앞에 1,016개의 비전 행을 넣고 동시에 패킹된 시퀀스에 1,016개의 조건 행을 넣는데, H3는 매 레이어마다 그 전부에 어텐션을 걸기 때문입니다. 조건을 하나 더하는 비용이 입력 단계에서 한 번 드는 것이 아니라 모든 레이어와 모든 스텝에 곱해지는 구조입니다.

어텐션 백엔드 선택도 참고할 만합니다. 이 Space는 기본값으로 cuDNN 융합 커널(_native_cudnn)을 쓰는데, SDPA 기본값보다 10%에서 20% 빠르면서 별도 설치가 필요 없습니다. FlashAttention-3은 sm90 전용이라 sm120인 이 풀에서는 쓸 수 없습니다. 앞서 본 diffusers의 _flash_3_hub 권고가 Hopper 기준이라는 점과 함께 놓고 보면, 세대별로 최적 백엔드가 갈린다는 것을 알 수 있습니다.

라이선스: 한국은 현재 오픈 웨이트 적용 지역에서 제외

이번 H3 모델 라이선스 사용 불가가 국내 독자에게는 사실상 가장 중요한 부분입니다. H3의 가중치는 Apache 2.0이나 MIT 같은 일반적인 오픈소스 라이선스가 아니라 MiniMax H3 Community License Agreement 로 배포되며, 라이선스 날짜는 2026년 8월 2일입니다.

이 라이선스는 권리 허여의 범위를 적용 지역(Applicable Territory) 으로 한정하고, 적용 지역을 "제외 지역을 뺀 전 세계" 로 정의합니다. 그리고 제외 지역(Excluded Territories)은 다음 네 곳입니다.

유럽연합
영국
대한민국
미국

즉, 대한민국 내에서 이 가중치를 내려받아 사용하거나 복제, 수정, 배포, 실행, 전시하는 행위는 현재 라이선스가 부여하는 권리 범위 밖입니다. 라이선스 제5조는 "적용 지역 밖에서 MiniMax H3 저작물이나 그 출력물, 결과물을 사용, 복제, 수정, 배포, 전시할 수 없으며, 적용 지역 밖에서의 그러한 사용은 본 계약에 의해 허가되지 않는다" 고 명시합니다.

여기서 오해하기 쉬운 부분을 분명히 해 둘 필요가 있습니다. 이 제한은 기술적으로 강제되지 않습니다. Hugging Face 저장소에는 접근 게이트가 걸려 있지 않아서(API가 gated: False를 반환하고 인증 없이도 가중치가 내려옴) 국내에서도 hf download 명령 한 줄이면 파일은 그대로 받아집니다. 즉 다운로드가 성공한다는 사실이 사용 허가를 뜻하지 않습니다. 판단 기준은 오직 라이선스 문구이고, 개인 실험을 넘어 조직 차원의 배포나 서비스 운영을 고려한다면 법무 검토가 필요한 사안입니다.

MiniMax는 이 제한의 배경을 별도의 라이선스 Q&A 문서로 설명했습니다. 특정 국가를 배제하려는 의도가 아니라, 영상 생성 모델이 텍스트나 코드 모델보다 훨씬 복잡하고 빠르게 변하는 규제 환경에 놓여 있음을 인정한 결과라는 것입니다.

한국이 제외된 이유에 대한 설명은 한 문장뿐입니다

그런데 네 개 제외 지역을 설명하는 밀도가 서로 크게 다릅니다. 국내 독자에게는 이 차이 자체가 중요한 정보이므로 나누어 짚겠습니다.

유럽연합에 대해서는 근거 법령과 그 미비점을 함께 지목합니다. EU AI Act가 이미 집행에 들어갔지만, 영상과 초상(likeness)을 생성할 수 있는 모델에 대한 실무 요구사항은 여전히 형성 중이라는 설명입니다.

영국과 한국은 하나의 문장에 함께 묶여 있고, 그 문장이 전부입니다.

"Similar regulatory uncertainties exist in the UK and South Korea regarding AI-generated content and video generation."

영국과 한국에도 AI 생성 콘텐츠와 영상 생성에 관한 유사한 규제 불확실성이 존재한다.

즉 한국에 대해서는 법령 이름도, 소관 기관도, 구체적인 조항이나 쟁점도 하나도 언급되지 않습니다. "유사한(similar)" 이라는 한 단어로 유럽연합 쪽 설명에 얹혀 있을 뿐입니다. 제외 지역 네 곳 가운데 개별적인 사유가 붙지 않은 곳은 영국과 한국뿐이고, 그마저 두 나라를 한 문장으로 처리했습니다.

이것이 실무적으로 뜻하는 바는 두 가지입니다. 첫째, MiniMax가 한국의 어떤 규제를 문제로 봤는지 이 문서만으로는 알 수 없습니다. 국내에도 AI 생성물 표시를 포함한 규율 체계가 자리를 잡아 가는 중이지만, MiniMax가 그중 무엇을 지목한 것인지 특정할 근거가 원문에 없습니다. 둘째, 그래서 "이 조건이 충족되면 제외가 풀린다"고 미리 짚어 볼 수 있는 기준도 제시되지 않았습니다. 국내 사용자가 언제쯤 열릴지를 스스로 가늠할 방법이 없다는 뜻입니다.

다만 Q&A의 다른 대목을 보면 MiniMax가 실제로 우려하는 지점이 개별 국가의 특정 조항보다는 배포 방식 자체에 있음을 짐작할 수 있습니다. MiniMax는 핵심 문제가 "MiniMax-H3의 존재 자체가 아니라, 오픈 웨이트가 우리 인프라를 벗어난 뒤에도 컴플라이언스를 통제할 수 있는지" 라고 썼습니다. 가중치가 공개되면 개발자가 독립적으로 배포하고 수정할 수 있어서 호스팅 서비스와는 컴플라이언스 난이도가 다르다는 것입니다. 그래서 모든 관할권의 규제가 완전히 명확해질 때까지 공개를 미루는 대신, 지역 범위를 투명하게 밝히고 지금 공개한 뒤 계속 재평가하는 쪽을 택했다고 설명합니다. MiniMax는 현재의 제한이 "아직 아니다(not yet)" 이지 "영원히 아니다(not ever)" 는 아니라고 표현했습니다.

그래서 2026년 8월 4일 현재, 국내에서 H3를 쓰려면 실질적으로 두 가지 경로가 있습니다. 하나는 전 세계에 열려 있는 공식 API를 쓰는 것이고, 다른 하나는 MiniMax에 정식 라이선스를 신청해 승인을 받는 것입니다.

첫째, MiniMax의 공식 API를 쓰는 것입니다. 오픈 웨이트와 달리 MiniMax API는 전 세계에서 이용할 수 있습니다. MiniMax가 서빙 인프라를 직접 운영하며 미성년자 관련 오용 방지와 저작권 준수 조치, 콘텐츠 안전 통제를 적용할 수 있기 때문에 배포 모델 자체가 다르다는 설명입니다. Hailuo AI 웹앱과 데스크톱 앱도 같은 경로입니다.

승인을 받으면 제외 지역에서도 쓸 수 있습니다

둘째 경로가 이것입니다. 제외 지역이라고 해서 길이 완전히 닫힌 것은 아닙니다. Q&A 문서는 "제한 지역의 조직도 MiniMax-H3를 여전히 쓸 수 있는가" 라는 질문을 따로 두고 "그렇다(Yes)" 로 답합니다.

절차는 이렇습니다. 제한 지역의 조직은 정식 라이선스를 신청할 수 있고, MiniMax가 배포 시나리오를 검토한 뒤 적절한 컴플라이언스 통제와 안전장치가 실제로 구현되어 있음을 확인하면 사용을 승인할 수 있습니다. 신청은 MiniMax가 공개한 양식으로 받습니다.

MiniMax는 이 방식의 취지를 "승인된 배포를 통해 현지 법규 요구사항을 충족하면서도 MiniMax-H3가 책임 있게 사용되도록 보장할 수 있다" 고 설명합니다. 앞서 본 "인프라를 벗어난 뒤의 통제" 라는 문제의식과 이어지는 해법입니다. 지역 제외의 목적이 사용을 막는 것이 아니라, 통제가 확인된 형태로만 배포되게 하는 데 있다는 뜻입니다.

라이선스 본문도 같은 통로를 열어 둡니다. 제2조는 제외 지역의 적용 법령과 규제, 컴플라이언스 요구사항을 계속 평가할 것이라고 밝히면서, "그 사이에 제외 지역의 누구든 우리 모델을 배포하는 데 관심이 있다면 라이선스 취득에 관해 연락해 달라" 고 안내하고, 그 라이선스는 "제외 지역의 법률과 규정, 컴플라이언스 요구사항을 준수하기 위한 견고한 통제와 가드레일에 근거해 부여될 것" 이라고 적고 있습니다. 문의 창구는 model@minimax.io이며, 상업적 이용 승인은 api@minimax.io로 별도 안내되어 있습니다.

두 문서의 표현 차이는 한 가지 짚어 둘 만합니다. Q&A는 신청 주체를 조직(organizations) 으로 쓰고 승인도 "할 수 있다(may authorize)" 는 재량 표현인 반면, 라이선스 제2조는 누구든(any person) 이라고 쓰고 "부여될 것이다(will be granted)" 로 적습니다. 개인 연구자가 신청 대상에 포함되는지, 요건을 갖추면 승인이 사실상 보장되는지는 두 문서만으로 단정하기 어렵습니다. 실제로 필요하다면 신청 양식과 위 메일 주소로 직접 확인하는 편이 정확합니다.

MiniMax가 함께 밝힌 네 가지 약속도 이 통로가 임시적인 것임을 뒷받침합니다. 지역별 규제와 컴플라이언스 요구사항을 계속 검토하고, API는 전 세계에서 계속 이용 가능하게 유지하며, 라이선스가 바뀌면 조용히 갱신하지 않고 명확히 알리고, 이 제한에 영향받는 개발자와 연구자, 조직의 피드백을 듣겠다는 것입니다. Q&A의 마지막 문장은 "지금의 라이선스 범위는 오늘의 규제 현실을 반영한 것이고, 우리의 장기적인 비전은 아니다" 입니다.

적용 지역 안에서 쓰는 경우에도 알아 둘 조건들이 있습니다. 상업 제품이나 서비스가 연 매출 2,000만 미국 달러를 넘으면 MiniMax에서 별도의 사전 서면 승인을 받아야 하고, H3를 쓰는 상업 제품의 사용자 인터페이스에 "MiniMax H3" 를 잘 보이게 표시해야 합니다. 또한 H3나 그 출력물, 결과물을 다른 인공지능 모델을 개선하는 데 사용할 수 없습니다(H3 자신과 그 파생 모델은 예외). 출력물의 권리는 MiniMax가 주장하지 않으며 사용자가 전적으로 책임집니다. 준거법은 홍콩특별행정구법이고 관할도 홍콩 법원 전속입니다. 재배포할 때는 계약서 사본을 함께 제공하고 수정한 파일에 수정 사실을 명시해야 하며, 권고 사항으로는 "Powered by MiniMax H3" 표기와 생성 파일에 AI 생성 식별자를 넣는 것, 사용 경험을 담은 기술 블로그 글이나 공개 성명을 최소 한 건 게시하는 것이 열거되어 있습니다.

이용 정책에서 특히 눈에 띄는 조항

라이선스에 편입된 이용 정책(Acceptable Use Policy) 도 함께 읽어야 합니다. 20개 항목 중 영상 생성 모델의 성격상 실무에서 걸릴 여지가 큰 것들을 꼽으면 다음과 같습니다.

기계 생성 사실의 명시 (제12항): 이미지나 코드, 게시물, 기사를 공개된 환경에 게시하거나 유통할 때, 그 내용이 기계로 생성되었다는 사실을 명확하고 잘 보이게 밝히지 않는 사용을 금지합니다. 즉 결과물을 공개할 때의 AI 생성 표기는 권고가 아니라 이용 정책상의 의무입니다.
동의 없는 인물 사칭 금지 (제13항): 당사자의 동의나 권한, 적법한 권리 없이 다른 사람을 사칭하는 데 쓸 수 없습니다. 참조 이미지로 인물의 정체성을 고정하고 목소리 음색까지 참조할 수 있는 모델이므로 특히 유의할 항목입니다.
허위 정보와 여론 조작 금지 (제7항, 제8항): 타인에게 해를 끼치거나 선거에 영향을 줄 목적의 검증 가능한 허위 정보, 그리고 가짜 리뷰를 포함한 거짓 온라인 참여의 조작에 쓸 수 없습니다.
고위험 자동 의사결정 금지 (제14항): 법 집행, 이민, 의료, 핵심 인프라 관리, 신용, 고용, 주거, 교육, 사회적 점수화, 보험처럼 개인의 안전과 권리, 복지에 영향을 주는 영역의 고위험 자동 의사결정에 쓸 수 없습니다.
군사적 목적 금지 (제19항) 및 안전장치 우회 금지 (제5항).
미성년자 착취 및 위해 금지 (제6항).

또한 하위 사용자나 제3자에게 H3 기반 서비스를 제공한다면, 제공 전과 운영 기간 내내 이 제한을 위반하는 접근과 출력을 막고 완화하기 위한 합리적이고 비례적인 기술적 조직적 안전장치를 구현하고 유지하며 주기적으로 점검해야 하고, 위반 신고 창구도 접근 가능한 형태로 유지해야 합니다.

한편 API 경로를 쓰는 경우에는 MiniMax 쪽 자동 검수가 개입한다는 점을 알아 둘 필요가 있습니다. 모델 카드는 사용자가 제출한 텍스트와 이미지, 영상은 물론 H3-Context-IR이 보강한 프롬프트까지 자동 모더레이션 대상이며, 불법이거나 음란하거나 제3자 권리를 침해한다고 의심되는 내용은 차단될 수 있다고 밝힙니다. 업계 표준 필터링을 쓰지만 오탐과 미탐을 완전히 없앨 수는 없다는 단서도 붙어 있고, 이 안전장치가 라이선스상 이용자의 의무를 면제하지는 않는다고 명시합니다.

한편 인코더로 쓰이는 Qwen3-VL-32B는 Apache 2.0으로 별도 라이선스된다는 점이 라이선스 말미에 부기되어 있습니다.

남은 과제와 다음 버전

MiniMax H3는 공개되었지만, 실질적으로는 여러 조각이 아직 열려 있지 않은 상태로 공개됐습니다. 아직 공개되지 않은 부분들을 정리하면 다음과 같습니다:

H3-Context-IR 은 다단 워크플로우와 여러 호스팅 서비스에 의존해 공개 대상이 아니며, API와 프롬프트 가이드로 대체됩니다.
H3-Regenerate-2K 도 시스템 복잡도로 인해 아직 공개되지 않았습니다. 로컬 배포만으로는 768p까지입니다.
희소 어텐션 구현은 초기 공개본에 포함되지 않았고, 현재 추론 경로는 전체 어텐션입니다.
기술 보고서는 곧 공개될 예정이라고만 안내되어 있습니다.

MiniMax가 밝힌 다음 버전의 우선순위도 명확합니다. 첫째, 강한 멀티모달 이해가 고품질 생성의 토대인데 여기에 개선할 여지가 크므로 다음 H 시리즈에서는 M 시리즈 모델의 능력을 통합할 계획입니다. 둘째, 현재 모델 크기가 여러 능력에서 개선 여지를 남기고 있어 규모 확장이 분명한 경로이며, 더 강한 작업 일반화가 그 잠재력을 온전히 끌어낼 것으로 봅니다. 셋째, 일부 상황에서 시각적 디테일이 아직 개선될 수 있어 더 높은 해상도와 시각적 충실도를 계속 밀어붙일 것입니다.

MiniMax가 비전 절에서 내놓은 문장이 이 모델의 설계 철학을 압축합니다. "멀티모달 이해와 생성에 있어 우리는 언어를 일반화 가능하고 확장 가능한 계산 시스템으로 본다. 그래서 멀티모달 지능은 언어에 깊이 뿌리내려야 한다고 믿는다." 영상 생성 모델의 프롬프트가 왜 시나리오처럼 길어지고, 왜 참조 관계를 자연어로 서술하게 만드는지가 이 한 문장에서 설명됩니다.

영상과 음향을 함께 생성하는 시도 자체는 H3가 처음이 아닙니다. 커뮤니티에도 LTX-2와 Ovi, Wan2.2, Vidu S1 같은 모델들이 정리되어 있고, 프롬프트 설계 측면에서는 Seedance 2.0 실전 가이드가 참고할 만합니다. H3가 이들과 갈라지는 지점은 참조와 편집까지 자연어 한 겹으로 통합했다는 것, 그리고 그 통합을 33B 밀집 모델의 오픈 웨이트로 내놨다는 것입니다. 다만 국내에서는 그 오픈 웨이트를 그대로 쓸 수 없다는 조건이 붙어 있으니, 실험 전에 라이선스 범위를 먼저 확인하시기를 권합니다. 조직 차원에서 로컬 배포가 필요하다면 배포 시나리오와 안전장치를 정리해 MiniMax에 승인을 신청하는 경로가 열려 있고, 그 전까지는 전 세계에서 제약 없이 쓸 수 있는 API가 현실적인 출발점입니다.

라이선스

MiniMax H3는 MiniMax H3 Community License Agreement로 배포되며, 권리 허여 범위가 유럽연합과 영국, 대한민국, 미국을 제외한 전 세계로 한정됩니다. 따라서 국내에서 가중치를 내려받아 사용하거나 배포하려면 MiniMax의 별도 승인이 필요합니다. 승인은 신청 양식으로 접수되며, MiniMax가 배포 시나리오와 컴플라이언스 통제, 안전장치를 검토해 확인되면 사용을 승인할 수 있습니다. 승인 절차 없이 바로 쓸 수 있는 경로는 전 세계에서 이용 가능한 API입니다. 적용 지역 안에서도 연 매출 2,000만 미국 달러 초과 시 사전 서면 승인, 상업 제품 UI에 MiniMax H3 표시, 다른 AI 모델 개선 목적 사용 금지 등의 조건이 붙습니다. 인코더로 쓰이는 Qwen3-VL-32B는 Apache 2.0으로 별도 라이선스됩니다.

MiniMax H3 소개 블로그

MiniMax H3 모델 카드

MiniMax H3 Hugging Face Space 데모

SGLang MiniMax H3 배포 쿡북

vLLM MiniMax H3 레시피

diffusers MiniMax H3 파이프라인 문서

github.com/huggingface/diffusers

docs/source/en/api/pipelines/minimax_h3.md

minimax-h3

<!-- Copyright 2026 The HuggingFace Team. All rights reserved.

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with
the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on
an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the
specific language governing permissions and limitations under the License. -->

# MiniMax-H3

<!-- Remove this note once the pull request is merged. -->
> [!TIP]
> MiniMax-H3 is not part of a diffusers release yet. Install diffusers from the pull request to use it:
> `pip install git+https://github.com/huggingface/diffusers.git@refs/pull/14355/head`


MiniMax-H3 generates video and its soundtrack **jointly**. One transformer denoises a single packed sequence that holds the text conditioning, the conditioning image, video and audio rows, the target audio rows and the target video rows at once, with full self-attention over all of it. There is no separate vocoder and no audio post-hoc pass: video and audio come out of the same denoising loop.

This file has been truncated. show original

ComfyUI MiniMax H3 워크플로우 튜토리얼

MiniMax 홈페이지

더 읽어보기

이 글은 GPT 모델로 정리한 초안을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 댓글로 알려주시기를 부탁드립니다.

이 글이 유용하셨다면 아래쪽 좋아요를 눌러주세요 — 파이토치 한국 사용자 모임이 새로운 소식을 정리하고 공유하는 데 힘이 됩니다!

9bow · 8월 4, 2026, 5:00오전

한국이 드디어 EU, 미국, 영국과 동등(?)한 취급을 받기 시작했다는 점에서 기뻐해야 할지 슬퍼해야 할지 애매하네요