MiniMax-H3-Image는 세 가지 플랫폼에서 제공됩니다: 각 플랫폼이 실제로 제공하는 것

이번 주 MiniMax-H3-Image에 관해 가장 짧고 참인 문장은 그것이 세 곳에서 제공된다는 것이다: Hugging Face, MiniMax Code, 그리고 MiniMax 자체 API. 구매자가 실제로 필요한 문장은 더 좁다. 그중 둘은 요청 엔드포인트와 요금표를 건네고, 하나는 135기가바이트의 가중치와 읽어야 할 라이선스, 그리고 하드웨어 결정을 건넨다. 이들은 같은 접근 권한의 세 가지 형태가 아니며, 이를 서로 바꿔 쓸 수 있는 것으로 취급하면 팀이 이미지당 2센트에 살 수 있었던 일에 일주일을 배정하게 된다.

모델 자체는 재포장이 아닌 진정한 출시입니다. MiniMax는 2026년 11월 10일 14:50 UTC에 가중치를 Hugging Face 저장소 MiniMaxAI/MiniMax-H3-Image에 올렸고 같은 날 오후 15:40에 이에 대해 게시했습니다. 저장소 자체는 11월 3일부터 있었는데, 이는 누구나 다운로드할 수 있기 전 일주일 동안 가중치가 비공개로 존재했음을 의미합니다. 이는 대략 1,600만 화소로 생성하는 331억 매개변수의 디퓨전 트랜스포머로, 발표문의 "4K"가 바로 이것이며, 단일 체크포인트에서 텍스트-이미지 변환과 참조 기반 편집을 수행합니다. 다음 내용은 발표문이 답하지 않는 한 가지 질문, 즉 어떤 표면에 있어야 하는가를 중심으로 구성됩니다.

세 개의 정문이 있으며, 그중 하나만 다운로드입니다.

각 문이 무엇인지부터 시작하세요. 차이는 겉모습이 아니라 구조에 있기 때문입니다.

이 API가 일반적인 경로입니다. 이 모델은 MiniMax-H3-Image로 표기되어 있으며, Highspeed 형제 모델과 함께 MiniMax의 국제 및 중국 본토 플랫폼에서 제공되고, 이미지당이 아니라 입력 및 출력 백만 토큰당 과금됩니다. 이 인터페이스는 유난히 독단적이어서 — 샘플링 단계 6개, 가이던스 스케일 없음, 네거티브 프롬프트 없음 — MiniMax 자체 참조 문서에 따르면 그 외 다른 것을 요구하는 요청은 HTTP 400으로 반환됩니다. 당신은 내부에 고정된 레시피가 들어 있는 작동하는 엔드포인트를 구매하는 셈입니다.

M​iniMax Code와 Hailuo AI는 제품 표면입니다. 즉, 프롬프트 상자 뒤에 있는 동일한 모델이며, 샘플링 결정은 이미 내려져 있고 여러분이 직접 토큰별 연산을 할 필요가 없습니다. 출력이 얼마나 좋은지 평가하는 데는 유용하지만, 무언가를 구축하는 데는 유용하지 않습니다. 구축의 기반이 될 대상이 노출되지 않기 때문입니다. 또한 M​iniMax Code는 코딩 에이전트 제품이므로, 그곳의 이미지 생성은 주 기능이 아니라 곁문에 해당합니다. "M​iniMax Code에서 사용 가능"을 코드 래퍼가 씌워진 이미지 API로 읽지 마십시오.

Hugging Face는 세 번째 문이며, 서비스가 아니라 인계인 유일한 문입니다. 저장소, 라이선스 파일, 그리고 이제 직접 실행되도록 해야 하는 가중치 세트를 받게 됩니다. 셀프 호스팅은 대부분의 팀이 오픈 웨이트 이미지 모델을 아예 검토하는 이유이기도 하며, 계산이 모델에 관한 것에서 멈추고 여러분의 랙에 관한 것으로 시작되는 지점이기도 합니다.

저장소는 헤드라인 파라미터 수가 시사하는 것보다 더 무겁습니다.

BF16에서 331억 개 매개변수는 다른 무엇을 계산하기 전에 약 66GB이며, "다른 무엇"이 바로 저장소가 사람들을 놀라게 하는 지점입니다. 디퓨전 트랜스포머만 66.28GB입니다. 전체 다운로드는 68.65GB로, 트랜스포머에 VAE와 설정을 더한 값입니다. 텍스트 인코더는 그 수치에 포함되지 않습니다: MiniMax-H3-Image는 MiniMax-H3 비디오 저장소의 Qwen3-VL 텍스트 인코더를 재사용하고, 그 인코더의 50번째 레이어에서 읽으며, 해당 인코더는 별도의 66.7GB 다운로드입니다. 다시 말해 첫 이미지를 만들기 전에 디스크에 약 135GB의 아티팩트를 예산으로 잡아야 하며, 이는 어떤 프레임워크의 자체 캐시도 고려하기 전의 수치입니다.

아키텍처는 한 문단으로 다룰 가치가 있습니다. 모델이 무엇인지 알려주기 때문입니다. 50개의 트랜스포머 레이어, 은닉 크기 5,376, 56개의 어텐션 헤드, 피드포워드 폭 14,336에 3차원 멀티모달 로터리 위치 임베딩을 갖춥니다. VAE는 16× 공간 다운샘플링과 24개 잠재 채널을 사용하는 24층 2차원 ViT 디코더와 결합된 컨볼루션 인코더입니다. 이 디코더 선택은 파이프라인 끝에서 일반 컨볼루션 디코더보다 더 많은 연산을 요구하며, 4K의 일부 미세한 디테일이 여기서 비롯될 가능성이 있습니다. 이 설계는 모델 카드에서 오디오를 뺀 H3 아키텍처로 설명되는데, 이는 타당한 요약입니다. 이것은 비디오 모델의 이미지 브랜치를 단독으로 제공한 것입니다.

두 가지 결과가 따른다. 첫째, 16메가픽셀에서의 33B급 확산 트랜스포머는 최신 언어 모델 옆에서 파라미터 수가 어떻게 들리든 노트북용 모델이 아니다. 활성화 메모리는 출력 면적에 따라 커지고, 면적이야말로 이번 출시의 핵심이다. 둘째, 텍스트 인코더를 비디오 모델과 공유하기 때문에 이미 MiniMax-H3를 운영 중인 매장은 다운로드할 파일의 대부분을 이미 디스크에 갖고 있다. 이는 실질적인 할인이며, “Hugging Face에서 사용 가능”이라는 문구가 전달하지 못하는 종류의 것이다.

그것을 제공하는 네 가지 방법, 그리고 일치하지 않는 숫자 하나

모델 카드에는 SGLang, vLLM-Omni, diffusers, ComfyUI의 네 가지 경로가 나열되어 있습니다. vLLM 팀은 출시 당일 NVIDIA와 AMD 하드웨어 모두를 위한 day-zero 지원을 vLLM-Omni에 제공했으며, 약 1,600만 화소의 네이티브 출력을 지원합니다. 이는 가중치가 존재한다는 사실보다 더 강력한 출시 신호입니다 — M​iniMax 외부의 누군가가 발표가 나온 지 한 시간도 되기 전에 이를 실행하고 있었습니다. Diffusers는 참조 경로를, ComfyUI는 워크플로 그래프 사용자층을 담당합니다.

이 불일치는 누군가에게 문제가 될 수 있으므로 짚고 넘어갈 가치가 있습니다. 모델 카드는 최대 16개의 참조 이미지를 사용한 편집을 설명하며, 위치에 따라 <Picture 1>부터 <Picture 16>까지 업로드 순서대로 지정됩니다. 동일 모델에 대한 vLLM-Omni 릴리스 레시피는 요청당 최대 9개의 이미지를 문서화합니다. 두 가지 모두 동시에 사실일 수 있습니다 — 프레임워크의 서빙 한도와 모델의 학습된 용량은 서로 다른 숫자이며, 서빙 스택의 배칭 또는 메모리 제약이 먼저 작용할 것입니다 — 하지만 워크플로에 참조 이미지 12개가 필요하다면, 오늘날 정직한 답은 그 기능은 존재하지만 문서화된 서빙 경로가 이를 감당하지 못할 수 있다는 것입니다. 어느 문서도 믿지 말고 자신의 스택에서 그 숫자를 테스트하세요.

프롬프트 창에도 같은 주의가 적용됩니다. 이 카드는 최대 32,000자까지 입력을 받아들이지만, 그중 대략 처음 4,096개 토큰만 모델이 실제로 조건으로 삼습니다. 긴 프롬프트가 거부되는 것은 아니며, 꼬리 부분은 그저 역할을 하지 않을 뿐입니다. 언어 모델 습관에서 상세한 아트 디렉션 프롬프트를 옮겨 오는 사람은 그 사실을 비싼 대가를 치르고 알게 될 것입니다.

샘플러는 당신이 조정하는 설정이 아니라 물려받는 제약입니다.

6단계, classifier-free guidance 없음, 네거티브 프롬프트 없음. 이것은 더 높일 여지가 있는 기본값이 아니다. API는 다른 단계 수와 가이던스 값을 곧바로 거부한다. 이 모델은 6번의 순전파로 실행되도록 증류되었으며, 33B 트랜스포머가 1,600만 화소 이미지를 쓸 만한 속도로 반환할 수 있는 이유 전체가 바로 그 증류 덕분이다.

API 경로에서는 이 수치가 보이지 않으며 문제가 되지 않습니다. 셀프 호스팅 경로에서는 사양표에서 가장 유용한 단일 수치이며, 두 가지 면에서 그렇습니다. 이 수치는 이미지당 연산을 비증류 모델에 필요한 25~50회가 아니라 트랜스포머 평가 6회로 제한하는데, 바로 이것이 16메가픽셀을 애초에 실용적으로 만듭니다. 그리고 일반적인 셀프 호스팅 튜닝 루프—스텝을 늘려 보고, 가이던스를 추가하고, 네거티브 프롬프트를 추가하고, 반복하기—가 여기에는 존재하지 않는다는 뜻입니다. 출력 품질이 실망스럽다면 조정 수단은 샘플러가 아니라 프롬프트와 레퍼런스입니다. “모델 튜닝”에 일주일을 배정한 팀이라면 그 시간을 대신 프롬프트 작업에 배정해야 합니다.

각 경로에 드는 비용을 실제 청구되는 단위로

API는 토큰을 기준으로 요금을 청구하며, 카드에 포함된 계산 예시가 이를 가장 명확하게 보여줍니다. 1,024×1,024 텍스트-이미지 요청은 $0.02179입니다. 2,048×2,048 요청은 $0.02333으로, 픽셀 수는 네 배인데 가격은 1.07배입니다. 토큰 수가 면적보다 훨씬 느리게 증가하기 때문입니다. 4,096×4,096 요청은 정가 $0.06879이며, 2026년 11월 17일 16:00 UTC까지 진행되는 기간 한정 50% 할인을 적용하면 $0.03439입니다. 이 할인은 전달된 이미지가 최소 16,600,000픽셀이어야 적용됩니다. Standard 티어 요금은 입력 텍스트 토큰 100만 개당 $2.30, 입력 이미지 토큰 100만 개당 $1.50, 출력 이미지 토큰 100만 개당 $3.80입니다. Highspeed 티어는 입력 요금을 그대로 유지하며 출력 요금은 $7.60입니다.

그 세 숫자를 함께 보면 4K에 대한 가격 논리는 대부분 사라진다. 2K 단계에서 1.07배의 비용으로 4배의 픽셀을 얻는 것은 선물과 같다. 2K에서 4K로 가는 것은 같은 4배의 면적 증가에 약 3배의 비용이 들며, 할인만이 이를 2K 요금 근처로 되돌린다. 사용 사례에 한 변 4,096픽셀이 필요 없다면, 이 모델이 저렴한 곳은 2K 등급이다.

OrcaRouter는 MiniMax-H3-Image를 제공하지 않습니다 — 여기에는 이에 대한 경로가 없으며, 이 글의 CTA는 비디오용 자매 모델인 minimax/minimax-h3를 가리키는데, 이 경로는 저희가 라우팅합니다. 저희가 제공하는 것은 해당 경로가 존재하는 날에 관련이 있습니다: 공급자 목록 가격을 그대로 전달하는 0% 마크업, 즉 해당 4K 할인과 같은 공급자 가격 변경이 공급업체 페이지에 반영되는 당일 청구서에도 반영된다는 뜻이며, 공급자 경로가 저하될 경우 자동 페일오버가 이루어집니다. 그때까지 중요한 비교는 자체 하드웨어 대비 API 지출이며, 어떤 라우팅 계층도 그 계산법을 바꾸지 않습니다.

셀프 호스팅, 정직한 가격

GPU를 모른다면 이미지당 자체 호스팅 비용을 제시할 수 없습니다. 왜냐하면 지배적인 항은 135GB의 가중치가 메모리에 들어가는지, 아니면 오프로딩해야 하는지이기 때문입니다. 정확히 말할 수 있는 것은: 6단계 샘플러가 연산량을 고정하고, 1600만 화소 출력이 활성화 예산을 고정하며, 둘 다 큽니다. 80GB 카드 한 장은 트랜스포머는 담을 수 있지만 전체 정밀도의 트랜스포머와 Qwen3-VL 인코더를 함께 담을 수는 없으므로, 현실적인 구성은 멀티 GPU, 인코더 오프로딩, 또는 품질 문제가 따라붙는 양자화된 트랜스포머입니다. 전력 비용을 더하고, SGLang 또는 vLLM-Omni 서빙을 제대로 갖추기 위한 엔지니어-주를 더하면, 2K 이미지당 $0.02333 대비 손익분기점은 수십 장이 아니라 수십만 장 규모의 볼륨입니다.

대부분의 경우 API를 선택하는 근거이고, 소수의 경우에는 가중치를 선택하는 근거는 다음과 같다: 데이터상의 이유로 모델을 자체 경계 안에 두어야 하는 업체, 이미 MiniMax-H3를 운영하며 인코더를 보유한 업체, 고정 비용이 상각되는 규모로 생성하는 업체. 그 외 모두는 먼저 API 가격을 따져보고, 경계가 정말로 요구할 때만 자체 호스팅해야 한다.

다운로드한 뒤가 아니라, 다운로드 전에 라이선스 읽기

가중치는 MiniMax-H3-Image Community License Agreement에 따라 공개되며, 이는 Apache 2.0도 MIT도 아닙니다. "오픈 웨이트(open-weight)"라는 표현은 정확합니다. 팀을 곤경에 빠뜨리는 말은 "오픈 소스(open-source)"이며, 이는 변호사가 블로그 글—이 글을 포함해—이 아니라 실제 파일을 읽어야 하는 바로 그 지점입니다. 실질적인 질문은 대규모 상업적 사용과 라이선스에 귀사의 제품에 적용되는 조건이 포함되어 있는지 여부이며, 그 질문에 대한 답은 어떤 요약으로도 대체할 수 없는 저장소 안에 있습니다.

알아둘 가치가 있는 두 번째의 더 작은 아티팩트가 있습니다. M​iniMax는 모델용 Context-IR 구성 요소와 선택적 프롬프트 확장 모델인 MiniMax-H3-Image-PE를 제공합니다. 이 확장기는 모델이 길고 상세한 프롬프트를 견딜 수 있는 이유 중 일부를 설명합니다. 선택 사항이며 68.65 GB와는 별개이고, 발표라기보다 저장소 목록에서나 볼 수 있는 종류입니다.

이번 주에 자체 스택에서 확인해야 할 사항

• 참고 — 문서를 읽는 대신 실제 요청으로, 서빙 경로가 이미지 16개를 지원하는지 아니면 vLLM-Omni 레시피에 문서화된 9개를 지원하는지 확인하세요.

• 유효 영역 — 모델은 1,600만 화소 미만으로 실행되며, 구성에서는 최소 생성 영역 기본값을 4,194,304픽셀로 노출합니다. 사용 사례가 썸네일이라면 작은 쪽 끝을 테스트하세요. 이 크기의 모델은 1K에서 저렴한 옵션이 아닐 수 있기 때문입니다.

• 메모리 — 하드웨어를 구매하기 전에 4,096×4,096에서 최대 VRAM을 측정하세요. 6단계는 연산 비용이 저렴하지만 활성화 값은 그렇지 않습니다.

• 할인 카운트다운 — 4K가 계획이라면 50% 요율은 2026년 11월 17일 16:00 UTC에 종료되며, API를 사용하는지 자체 베어메탈을 사용하는지에 따라 그 마감이 당신에게 중요한지가 결정됩니다.

• 라이선스 — 읽어 보세요. 다운로드는 135GB이고 그 결정은 되돌릴 수 있지만, 라이선스는 그렇지 않습니다.

이번 릴리스에서 흥미로운 점은 좋은 오픈 이미지 모델이 등장했다는 것이 아니라, 얼마 만에 처음으로 가중치와 프레임워크 레시피, 호스팅 엔드포인트가 모두 같은 주에 도착한 채로 등장했다는 점이다. 그것은 벤치마크 차트보다 더 강한 신호다. 왜냐하면 그것은 그 물건이 실제로 돌아간다는 뜻이기 때문이다. 그것을 직접 실행해야 하는지, 아니면 호출해야 하는지는 전적으로 세 개의 문 중 어느 문으로 들어가느냐에 달려 있으며, 그 세 문은 발표에서 들리는 것보다 훨씬 더 멀리 떨어져 있다.