MiniMax H3와 H3 Max, 지금 구분해 봐야 하는 이유 | DAKER 커뮤니티

비디오 생성 모델 이야기는 늘 빠르게 바뀌지만, 실제로 팀이 헷갈리는 지점은 의외로 단순합니다. 이름이 비슷한 두 모델을 같은 것으로 보고, 해상도와 모드, 워크플로를 한 번에 섞어 쓰는 순간부터 구현과 커뮤니케이션이 어긋나기 시작합니다.

지금 확인할 포인트는 MiniMax가 공식 문서에서 MiniMax-H3와 MiniMax-H3-Max를 어떻게 나누고 있는지입니다. 특히 H3 Max의 속도 이야기가 많이 퍼지고 있는 만큼, 공식 문구와 fal.ai·보도에서 나온 수치를 구분해 읽는 것이 중요합니다.

공식 문서가 구분하는 두 모델

MiniMax 공식 가이드 기준으로 보면 MiniMax H3와 MiniMax H3 Max는 같은 줄에 놓여 있지만 역할이 같지는 않습니다. MiniMax H3는 텍스트·이미지·비디오·오디오를 통일된 맥락으로 이해하고 생성, 레퍼런스, 편집을 지원하는 오픈 범용 멀티모달 비디오 모델로 설명됩니다. 반면 MiniMax H3 Max는 MiniMax와 fal.ai가 공동 출시한 모델이며, fal.ai가 MiniMax H3를 후훈련해 고속 생성에 맞춘 모델로 소개됩니다.

MiniMax-H3와 MiniMax-H3-Max는 이름만 비슷한 같은 모델이 아니라, 공식 문서에서 스펙과 역할이 분리된 두 모델입니다.

API에서 사용하는 모델 ID도 문서 표기 그대로 MiniMax-H3와 MiniMax-H3-Max입니다. 별칭을 임의로 붙여 쓰기보다 문서의 ID를 그대로 맞추는 편이 좋습니다.

해상도와 길이, 어디까지 가능한가

두 모델의 가장 실무적인 차이는 출력 스펙입니다. H3는 768P와 2K를 지원하고, 출력 길이는 4–15초의 정수 값입니다. H3 Max는 480P와 768P를 지원하며, 출력 길이는 5–15초의 정수 값입니다.

2K가 필요하면 H3 경로이고, 빠른 480P·768P 초안이 목적이면 H3 Max 경로입니다.

이 차이는 단순한 옵션 차원이 아닙니다. H3 Max에 2K를 기대하거나, H3의 스펙을 그대로 Max에 옮겨 적으면 바로 오해가 생깁니다. 공식 문서의 표를 기준으로 파이프라인을 나눠 보는 것이 좋습니다.

지원 모드도 다릅니다

현재 H3 Max는 T2V와 I2V를 지원합니다. 텍스트만으로 영상을 만들거나, 첫 프레임·끝 프레임 이미지와 텍스트를 함께 써서 생성하는 방식입니다. 공식 문서에는 Reference Generation이 coming soon으로 적혀 있습니다.

반면 H3는 레퍼런스 생성과 편집까지 표에 포함되어 있습니다. 이미지·비디오·오디오를 조합하는 레퍼런스 워크플로가 필요하다면 H3 쪽을 먼저 검토해야 합니다.

I2V에서는 이미지가 있으면 종횡비가 입력 이미지를 따르고, ratio는 adaptive 쪽으로 간다고 예시 주석이 설명합니다. 반대로 T2V에서는 ratio가 필요하고 adaptive를 쓸 수 없다는 주석이 붙어 있습니다. 모드별 파라미터를 그대로 복사해 쓰지 않는 편이 안전합니다.

입력 제한과 포맷은 미리 확인해야 합니다

공식 표에는 입력 제한도 비교적 자세히 정리돼 있습니다. 첫 프레임과 끝 프레임 이미지는 0·1·2장까지 가능하고, 폭·높이는 [256, 5760], 종횡비는 2:5–5:2입니다. 레퍼런스 입력은 이미지 ≤9, 비디오 ≤3, 오디오 ≤3이며, 비디오와 오디오는 클립당 2–15초, 총합 ≤15초입니다. 혼합 총 파일 수 상한은 12개입니다. 프롬프트는 ≤7000자, 요청 본문은 ≤64MB입니다.

지원 포맷은 비디오 H.264/AVC·H.265/HEVC, 이미지 JPG/JPEG/PNG/WEBP/HEIC/HEIF, 오디오 WAV/MP3입니다. 파일 크기 상한은 비디오 50MB, 이미지 30MB, 오디오 15MB입니다.

프롬프트 길이와 파일 크기 상한은 생성 품질보다 먼저 실패를 가르는 조건입니다.

문서에는 큰 에셋은 URL 입력을 권장한다는 취지의 안내도 있습니다. 입력 검증 단계에서 이 조건을 먼저 걸어 두면 운영이 한결 단순해집니다.

구현은 비동기 3단계로 봐야 합니다

워크플로는 생성 작업 생성, task_id로 상태 조회, 성공 시 content.url에서 다운로드하는 비동기 3단계입니다. 권장 폴링 간격 예시는 10초입니다. 동기식 단발 응답처럼 가정하고 코드를 짜면 실제 동작과 어긋날 수 있습니다.

task 상태가 failed나 cancelled일 때는 error 필드를 함께 남기는 예시도 안내됩니다. 성공 URL만 저장하고 실패 사유를 버리면 재현과 디버깅이 어려워집니다.

API 기본 URL 예시는 https://api.minimax.io 입니다. 리전이나 프록시를 따로 두는 조직이라면 엔드포인트 관리가 문서와 어긋나지 않도록 맞춰 두는 것이 좋습니다.

H3 전용 기능은 Max와 섞지 않는 편이 좋습니다

H3에는 H3-Context-IR과 Video Regeneration이 별도로 연결되어 있습니다. Context-IR은 멀티모달 맥락을 해석해 강화 프롬프트를 돌리는 기능으로, 영상을 직접 생성하지 않습니다. Regeneration은 768P 규격 소스 비디오를 2K로 재생성하는 흐름입니다.

Context-IR과 Regeneration은 H3 전용 흐름으로 보고, H3 Max 호출과 분리해 이해하는 편이 정확합니다.

Recommended Reading에는 Create Video Generation Task, H3-Context-IR, Regeneration, Query/List/Cancel Task, Pricing이 함께 연결되어 있습니다. 구현 전에 이 문서들을 순서대로 확인하면 전체 구조를 파악하기 쉽습니다.

속도 이야기는 출처를 나눠서 읽어야 합니다

공식 문서가 확정하는 표현은 H3 Max가 H3보다 빠르게 생성된다는 점입니다. 다만 fal 측이나 보도에서 언급되는 5초 768p+오디오를 약 3초 안에 생성한다는 이야기, 15초를 약 15초에 만든다는 이야기, 공식 H3 엔드포인트 대비 약 35배 처리량 같은 수치는 출처를 분리해서 다뤄야 합니다.

공식 문서는 더 빠름을 말하고, 구체적인 배수와 서브3초 수치는 fal.ai·보도 출처로 구분해야 합니다.

이 글의 제목처럼 재생 시간보다 빨리 뽑힌다는 훅은 가능하지만, 본문에서는 어떤 수치가 MiniMax 공식 가이드인지, 어떤 수치가 fal 측 주장인지 분리해 적는 편이 정확합니다.

또한 공식 문서가 말하는 것은 H3 Max가 mainstream 480P and 768P output을 제공한다는 점입니다. 이를 업계 최고 해상도처럼 과장하기보다, 표에 적힌 480P와 768P를 그대로 옮기는 것이 맞습니다.

계정 조건과 운영상 주의할 점

문서에는 H3와 H3 Max를 사용하려면 Pay-as-you-go API를 선택해야 한다고 적혀 있습니다. 패키지와 요금 상세는 Pricing 문서로 연결됩니다.

오픈 플랫폼 노출, Design 제품면 노출, fal 샌드박스 무료 횟수 같은 프로모션 정보는 시점과 채널에 따라 달라질 수 있습니다. 이런 내용은 영구 혜택처럼 적기보다 확인일과 함께 관리하는 편이 좋습니다.

콘텐츠 배열은 type text / image_url / video_url / audio_url과 role 라벨로 구분됩니다. role 이름은 first_frame, last_frame, reference_*처럼 문서 값에 맞추는 것이 중요합니다.

카메라 지시인 [pan], [zoom], [static] 같은 표기는 H3 가이드의 T2V 팁으로 나옵니다. Max에서도 같은 문법이 그대로 통하는지는 샘플로 확인한 뒤 내부 가이드에 반영하는 편이 안전합니다.

H3 블로그는 광고·브랜딩·이커머스·제품 디자인·UI/UX·게임 등 상용 콘텐츠 용도를 언급합니다. 다만 이 용도 설명은 MiniMax H3 블로그 출처로 보는 것이 맞고, H3 Max 문서에 같은 목록이 반복된다고 단정할 필요는 없습니다.

또한 오픈 웨이트 계획은 H3 쪽 설명에 초점이 있습니다. H3 Max의 가중치와 라이선스가 동일하게 열렸다고 단정하기보다, 문서가 말하는 공동 출시와 후훈련, 고속 생성이라는 범위 안에서 이해하는 편이 정확합니다.

무엇이 아닌지도 분명합니다

이 이야기는 DeepSeek 비전 MIT 공개(Sep1)와는 다른 주제입니다. 같은 중국발 소식이라도 모델과 맥락이 다릅니다.

또한 7월의 H3 발표를 반복하는 글도 아닙니다. 이번에 봐야 할 것은 H3 Max가 문서와 플랫폼에 올라오면서 H3와 어떻게 구분되는지입니다.

H3 Max가 오늘 바로 2K와 레퍼런스까지 모두 연다는 뜻도 아닙니다. 2K와 레퍼런스는 H3 쪽에 있고, Max는 현재 480P·768P와 T2V·I2V에 초점이 있습니다.

공식 가이드가 35배 처리량을 확정했다는 뜻도 아닙니다. 그 수치는 fal.ai·보도 출처로 구분해야 합니다.

한 페이지로 정리하면

MiniMax 공식 비디오 가이드는 MiniMax-H3와 MiniMax-H3-Max를 분명히 나눕니다. H3는 768P/2K, 4–15초, 레퍼런스와 편집까지 포함하는 경로이고, H3 Max는 480P/768P, 5–15초, T2V·I2V 중심의 고속 생성 경로입니다. H3 Max는 fal.ai가 H3를 후훈련한 변형으로 연결되지만, 속도 관련 구체 수치는 공식 문서와 fal.ai·보도 출처를 구분해 읽어야 합니다. 구현은 비동기 task 워크플로를 전제로 하고, 입력 상한과 포맷 제한을 먼저 확인하는 편이 좋습니다.

핵심은 H3와 H3 Max를 같은 모델처럼 다루지 않고, 목적에 따라 파이프라인을 분리하는 것입니다.

참고 자료: https://platform.minimax.io/docs/guides/video-generation
https://www.minimax.io/blog/minimax-h3

실제로는 H3와 H3 Max 중 어떤 경로가 지금 팀의 작업 방식에 더 잘 맞아 보이시나요?