MiniMax H3 사용 방법: 프롬프트, 로컬 실행, 그리고 쓰레기가 아닌 오디오

8월 4일, 사이먼 윌리슨은 약 115GB의 가중치를 다운로드하고, 비공식 MLX 포트인 MiniMax H3를 자신의 M5 Max MacBook Pro에서 실행한 다음, 슈퍼마켓에서 이끼 낀 통나무를 뛰어넘는 무지개색 스컹크를 요청했다. 45분이 채 안 되어 그는 진정으로 인상적이라고 평가한 클립을 얻었다. 다만 그가 이상하고 말 같은 쓰레기라고 표현한 오디오 트랙도 함께였다. 그 자신의 진단이 바로 유용한 부분이었다. 그는 모델에 어떤 오디오 지시도 주지 않았고, 프롬프트 가이드를 먼저 읽지도 않았다. 이것이 H3(Hailuo 3.0으로도 판매됨)를 사용하기 시작할 때의 경험을 가장 간결하게 요약한 것이다. 영상은 거의 공짜로 따라온다. 그 외의 모든 것 — 사운드, 촬영 타이밍, 2K, 네 번의 연속 촬영에서 생존해야 하는 캐릭터 — 은 현재 사용되는 거의 모든 다른 비디오 모델보다 더 엄격한 형식으로 명시적으로 요청해야 한다.

이 문서는 사용 가이드이지 출시 보도가 아닙니다. 이 문서에는 세 가지 출처 계층이 있으며, 매번 그 출처가 표시됩니다: 회사의 자체 문서 (모델 카드, 저장소에 포함된 두 개의 프롬프트 작성 가이드, 플랫폼 API 문서); 커뮤니티 조사 결과 — 실제로 실행해 본 사람들(ComfyUI 유지관리자, 독립 벤치마커, 리셀러 문서, Hugging Face 토론 스레드, 모두 2026년 7월 31일~8월 5일 사이의 것)에게서 얻은 것이며, 우리가 직접 기본 파일을 읽었음을 밝힌 소수의 사례도 있습니다. 커뮤니티 수치는 별도로 명시되지 않는 한 통제되지 않은 하드웨어에서의 단일 보고서입니다. 실무자들이 서로 의견이 다를 경우, 그 불일치는 해결되지 않은 채 보고됩니다.

무엇보다 먼저: 당신은 아마 전체 모델을 실행하고 있지 않을 것입니다.

H3의 첫 주에 발생한 혼란의 대부분은 마케팅 문구가 흐리는 하나의 구조적 사실에서 비롯됩니다. H3는 단일 모델이 아닙니다. 모델 카드에 따르면, H3는 세 부분으로 구성된 시스템이며, 그중 중간 부분만 오픈소스로 공개되었습니다:

• H3-Context-IR — 멀티모달 명령 전처리기입니다. 텍스트, 이미지, 오디오 및 비디오를 읽고, 이들 간의 관계를 추론하여 요청한 내용을 구조화되고 의미적으로 풍부한 표현으로 출력합니다. 호스팅 API로만 제공됩니다. 자체 작업 유형으로 노출되며, 강화된 프롬프트를 반환하고 비디오는 전혀 반환하지 않습니다.

• H3-Base — 실제로 프레임과 사운드를 생성하는 33B 파라미터 생성 모델입니다. 이것은 오픈 웨이트(open-weights) 부분입니다.

• H3-Regenerate-2K — 768p 결과를 2K로 끌어올리는 인컨텍스트 재생성 패스입니다. 호스팅 API 전용입니다.

두 가지 결과가 즉시 뒤따르며, 전체 작업 흐름을 결정합니다. 첫째, 로컬 생성은 768p 상한입니다. H3의 기본 캔버스는 768픽셀의 짧은 변 기준이고, 768×1344로 제한됩니다 — 16:9로는 대략 1344×768입니다. ComfyUI 출력이 2K가 아니어도 문제가 된 것은 아닙니다. 다운로드한 패키지는 H3-Base이며, 업스케일링 모듈은 포함되어 있지 않습니다. 둘째, 호스팅 API는 엉성한 프롬프트를 수정해 주지만 로컬 설치에서는 그렇지 않습니다. 유료 API 호출에서 Context-IR이 수행하는 모든 작업 — 구조 추론, 어떤 참조가 무엇을 의미하는지 해석, 애매하게 남긴 부분을 채우는 일 — 은 이제 H3-Base가 여러분의 문장을 보기 전에 직접 또는 다른 모델로 수행해야 하는 단계입니다. 이 하나의 비대칭성이 "동일한 프롬프트가 Hailuo에서는 작동하지만 ComfyUI에서는 깨져 보인다"는 대부분의 보고를 설명합니다.

리포지토리 자체에서 주목할 만한 점은 가중치가 minimax-h3-community-license-agreement 태그를 달고 있다는 것입니다. Apache나 MIT가 아니라요(이에 대해서는 아래에서 더 자세히 다루겠습니다. 바로 이 부분이 배포 가능 여부를 결정하기 때문입니다). 모델은 F32/BF16 기준 33B 파라미터로 등재되어 있으며, 현재 기준으로 정확히 하나의 추론 제공자 — fal — 만이 이 모델을 서비스하는 것으로 등재되어 있습니다. 이미 23개의 파인튠, 20개의 양자화, 31개의 Spaces가 이 모델을 기반으로 존재하는데, 이는 커뮤니티가 얼마나 빠르게 움직였는지를 보여주는 확실한 신호입니다.

프롬프트 형식: 샷 블록, 타임코드가 아닌

여기가 커뮤니티와 문서가 공개적으로 충돌하는 지점이며, 이는 이 글에서 다른 어떤 단일 요소보다 더 중요합니다.

가장 빠르게 퍼진 템플릿은 — 레딧을 거쳐 여러 공개 가이드로 퍼져나간 — 클립을 타임코드 구간으로 나눕니다: [0s-2s], [2s-5s], 등등, 그 뒤에는 스타일 계약, 타임라인, 카메라, 오디오, 명시된 텍스트, 부정 목록으로 구성된 6개 블록 구조가 이어집니다. 이 템플릿은 회사가 제공한 45개의 예시 프롬프트를 읽고 역설계된 것으로, 헛소리가 아닙니다: 그 예시들은 실제로 사운드 큐 시트가 첨부된 촬영 목록이며, 중앙값 길이는 약 130개의 한자, 가장 긴 것은 657자와 858자에 달합니다.

하지만 회사 자체의 VIDEO_PROMPT_WRITING_GUIDE_base_en.md, 리포지토리의 docs 폴더에 있는데, 뭔가 다른 것을 규정합니다. 그것의 조직 기준은 샷 블록이며, 시간 범위가 아닙니다. 우리는 그것을 직접 읽었습니다; 그것이 요구하는 구조는 다음과 같습니다:

• 지침 — 이미지 정렬 규칙으로, 키프레임 모드(I2VA, FL2VA, L2VA)에 사용되며 순수 텍스트-비디오 변환에서는 생략됩니다.

• integrated_multimodal_description — 본문으로, [Shot 1], [Shot 2] 등으로 구분됨.

• overall_soundscape — 다이제틱 사운드에 대한 1~4개의 문장.

• 비다이제틱 음악 — 스코어에 대한 1~3문장.

그 안에서, 규칙들은 검증 가능할 만큼 구체적입니다. [Shot 1]은 타임스탬프가 전혀 없습니다 — 이후의 샷은 절대 컷으로 시작하며, "At 00:03.500, the camera cuts to…"처럼 표현됩니다. 카메라 움직임은 동작 유형과 진폭, 속도를 조합하여 자연스러운 영어로 표현되며, 라벨처럼 나열하지 않습니다: 작은 진폭의 느린 푸시인이지, camera: dolly-in, slow가 아닙니다. 사용 가능한 움직임은 익숙한 세트입니다 — 줌, 팬, 틸트, 트래킹, 아크, POV, 그리고 약한 변형 또는 강한 변형의 셰이크. 대화는 태그로 감쌉니다: <d>[English] Get in the car.</d>, 구두점은 정확히 보존되며 절대 번역하거나 의역하지 않습니다. 화자에게는 고정 ID가 부여됩니다 — (S1), (S2), 그리고 공동 대사의 경우 (S1,S2) — 첫 등장 시 나이, 성별, 음색, 억양이 함께 설명됩니다. 내레이션은 화면 밖 대사로 표시되며 입을 다물고 있다는 명시적 메모가 붙는데, 이것이 모델이 얼굴에 내레이션을 립싱크하지 않도록 막는 방법입니다. 교차 편집된 대화는 <scenetrans> 마커와 연속성 설명문을 사용합니다.

이 가이드의 명시적 금지 사항은 규칙만큼이나 유익합니다. 첫 번째 샷에 타임스탬프를 찍지 말고, 전체 사운드스케이프 내에서 대사나 노래 또는 화면 속 음악을 반복하지 말며, 논다이제틱 음악에 추상적인 분위기 단어를 사용하지 말고, 대사 한 줄도 다시 쓰지 말아야 합니다. 그리고 한 가지 눈에 띄는 부재가 있습니다 — 공식 가이드에는 네거티브 프롬프트 섹션이 전혀 없으며, 이는 인기 커뮤니티 템플릿의 "금지된 전환" 목록이 문서화된 기능이 아닌 커뮤니티의 창작물임을 의미합니다.

이 갈등을 얼마나 진지하게 받아들여야 할까? H3 저장소의 Hugging Face 토론에서 한 커뮤니티 회원이 타임코드 스타일 구조를 가이드로 게시했고, 다른 실무자가 비슷한 구조를 사용해 봤지만 전부 잘못됐다며 번들 매뉴얼을 읽으라고 단호하게 답변했다. 이는 관리자의 결정이 아니라 한 사람이 다른 사람을 반박한 것이다. 증거에 대한 우리의 판단: 둘 다 호스팅 API를 통해 작동하는데, Context-IR이 보내는 모든 것을 정규화하기 때문이다. 문서화된 형식만이 H3-Base에 직접 사용할 때 신뢰할 수 있다. 로컬 가중치를 실행 중이라면 저장소의 파일을 따르라. API를 사용 중이고 타임코드 프롬프트로 좋은 클립을 얻고 있다면, 그 작업은 전처리기가 해 주는 것이며 형식 덕분에 얻은 것이라고 결론 내리면 안 된다.

게으른 브리프를 H3의 방언으로 컴파일하기

Willison의 12단어 프롬프트를 입력으로 삼아 보자 — 무지개색 스컹크가 슈퍼마켓에서 이끼 낀 통나무를 뛰어넘는 장면. 문서화된 방식으로 쓰면 대략 다음과 같아진다: [Shot 1] 블록은 스타일(실사, 핸드헬드, 형광등 조명)과 프레임(슈퍼마켓 통로, 리놀륨을 가로지르는 이끼 낀 통나무, 뒤로 멀어지는 선반들)을 명명하는 것으로 시작하며, 그다음 물리적 순서에 따라 피사체와 동작 — 두 번의 가벼운 걸음, 웅크림, 도약, 착지 — 을 제시하고, 카메라는 통나무 반대편에서 끝나는 느리고 진폭이 작은 트래킹 무브를 보여준다; overall_soundscape는 리놀륨 위의 발톱 소리, 통나무의 축축한 긁힘 소리, 냉장고의 윙윙거림, 멀리서 들리는 카트 바퀴 소리로 이루어지며; 그리고 non_diegetic_music 라인은 보컬이 없는 짧고 가벼운 현악 플러킹 큐다. 그 안에는 창의적 천재성이 전혀 없다. H3가 요청하는 네 가지가 실제로 담겨 있다는 점만 다를 뿐 같은 아이디어다 — 그리고 그것이 요청되지 않은 룸 톤과 당신이 설계한 사운드트랙 사이의 차이다.

이 단계는 기계적이고 반복적이며 인간에게는 부적합한 일입니다. 그래서 회사는 이를 위한 도구를 출시했지만, 거의 보도된 적이 없습니다. 리포지토리에는 스킬 디렉터리가 있으며, 그 안에는 아홉 가지 에이전트 스킬이 있고, 그 첫 번째는 — h3-prompt-writing — 정확히 이런 일을 합니다: 요청을 받아 다섯 가지 생성 모드 모두에 걸쳐 구조화된 H3 프롬프트를 작성하며, 사운드스케이프와 음악 섹션도 포함합니다. 나머지 여덟 가지는 장르 레시피(제품 광고, 3D 애니메이션 단편, 종이공예 설명 영상, 뮤직비디오 자막, 협동 게임 인트로, 손그림 실사 하이브리드 등)로, 동일한 형식을 워크플로에 적용합니다.

그 스킬을 실행하려면 비디오 모델이 아니라 텍스트 모델이 필요하며, 라우터는 플러그가 아니라 진정으로 유용한 지점이 바로 여기입니다. 회사 자체 LLM, MiniMax M3, 이 작업에 적합한 선택이며 OrcaRouter에 입력 토큰 100만 개당 $0.30, 출력 토큰 100만 개당 $1.20에 제공됩니다 — 공급업체 목록 가격이며, 0% 마크업으로 전달하므로 — 1M 토큰 컨텍스트 창과, 드물게도 비디오를 입력 유형으로 허용합니다. 그 마지막 세부 사항이 적합한 이유입니다. 공식 프롬프트 가이드, 브리프, 실제 참조 클립을 한 번의 호출로 전달하고, 돌려받는 것은 [Shot N] 블록이며, 이 블록은 그것을 설명합니다. 프롬프트를 컴파일하는 비용은 초당 과금되는 비디오 생성 비용에 비해 1센트의 일부에 불과하므로, 이를 수작업으로 작성할 이유가 없습니다. 솔직한 주의 사항 두 가지: H3 비디오 생성 자체는 OrcaRouter에서 실행되지 않습니다 — 클립은 회사 플랫폼, fal, 또는 자체 GPU에서 생성되며, 컴파일 단계는 편의를 위한 것이지 품질 보장이 아닙니다. 라우터가 여기서 제공하는 이점은 파이프라인의 텍스트 절반이 자동 장애 조치를 갖춘 하나의 키 뒤에 있어서, 배치 중간에 공급업체 중단이 발생해도 렌더 대기열이 좌초되지 않는다는 것입니다. 그리고 컴파일된 프롬프트를 비교하기 위해 M3를 다른 모델로 바꾸는 것은 새 계약이 아니라 문자열 변경일 뿐입니다.

오디오는 모두가 첫날에 헤매는 부분이다

첫 주에 단연 가장 많이 확인된 실패 모드는 Willison이 마주한 것입니다: 소리를 지정하지 않으면 H3가 무언가를 엉터리로 만들어냅니다. 그는 오디오 지시가 없는 프롬프트에서 말소리 같은 노이즈를 얻었습니다. 공식 예시를 리버스 엔지니어링한 분석 글은 같은 종류의 실패를 더 순화된 형태로 보고합니다 — 오디오 블록을 생략하면 모델이 요청하지 않은 룸 톤을 출력합니다 — 그리고 이런 경우들을 실수라기보다는 부재로 간주하는데, 이는 오디오-비디오 결합 모델을 생각하는 올바른 방식입니다. 모델은 항상 사운드트랙을 생성합니다. 유일한 선택은 사운드트랙을 지정할지 여부입니다.

공식 프롬프트 가이드의 지침과 리셀러 문서 및 리뷰어들이 실제로 작동한다고 보고하는 내용을 종합하면:

• 대사는 가장 구하기 어려운 것입니다. 음성 대사는 클립 5초당 한두 문장으로 유지하세요. 너무 긴 대사는 서두른 전달, 마지막 프레임을 지나치는 오디오, 또는 어색한 립싱크를 초래하며 — 이는 검토자들 사이에서 일관되게 보고되었습니다.

• 대사 앞에 화자를 설명하고, 그에 맞는 전달 방식을 함께 제시하세요. 공식 가이드에 따라 첫 등장 시 나이, 성별, 음색 및 억양을 명시하고, (명확하게, 따뜻하게, 무미건조하게 같은) 간단하고 직접적인 전달 메모를 사용하세요. 복잡한 연기 지시는 싱크를 저하시키는 것으로 알려져 있습니다.

• 모든 효과를 눈에 보이는 이벤트에 연결하세요. "코르크가 날아가는 바로 그 순간에 나는 팝 소리"라고 해야지, "소리: 팝"이 아니라, 바로 as, when 그리고 then이라는 단어들이 동기화를 담당합니다.

• 장르, 템포, 분위기, 악기 구성으로 음악을 간단히 지정하세요 — 아티스트나 곡으로는 절대 지정하지 마세요. 화면이 주도해야 할 때는 "no vocals"를 추가하세요. 이는 믹스를 깔끔하게 유지하는 문서화된 방법입니다.

• 한 절 안에 분위기를 겹겹이 쌓아라.유리창에 내리는 빗소리, 낮게 깔린 대화 소리, 이따금 들리는 컵 부딪히는 소리, 부드러운 배경 재즈 — 항목으로 나열하지 않고 하나의 문장 안에 차곡차곡 쌓는 방식이다.

• 사운드스케이프 섹션에서 대사를 반복하지 마십시오. 공식 가이드에 명시된 금지 사항입니다. 섹션들은 서로 겹치지 않도록 설계되었으며, 해당 부분에서 대사를 반복하면 대사가 두 번 나오게 됩니다.

• 화면에서 읽을 수 있어야 하는 단어는 따옴표 안에 입력하세요. 리뷰어들은 구체적으로 명시된 문자열은 깨끗하게 렌더링되지만, 모호한 요청("HUD elements", "a sign")은 글자 모양의 노이즈로 돌아온다고 보고합니다.

여러 리뷰어들의 평가에 따르면, 이 오디오가 진정으로 강점을 발휘하는 분야는 구체적인 물리적 사운드, 즉 눈에 보이는 것과 연결된 폴리(Foley)와 효과음, 그리고 앰비언스입니다. 추상적이거나 분위기 위주의 요청에는 상대적으로 약합니다. 다중 화자 장면은 화자 순서를 바로잡기 위해 편집이 필요한 경우가 많으며, 발음 품질이 언어마다 다르므로 프로젝트를 확정하기 전에 대상 언어를 임시 클립으로 먼저 테스트해 보는 것이 좋습니다. 여러 리뷰어들은 또한 솔직한 한계를 지적합니다. 음질이 소셜 배포에는 충분하지만, 방송용이나 유료 광고 믹스로 교체 없이 출시하기에는 일반적으로 부족하다는 것입니다. 이 중 어느 것도 공급업체의 안내가 아니라 실무자들이 보고한 내용입니다.

참조: 모든 파일에 작업을 할당하십시오.

H3의 레퍼런스 시스템은 가장 강력한 차별화 요소이자 설정 실수가 가장 흔하게 발생하는 부분입니다. 플랫폼 API 문서에 명시된 제한 사항은 다음과 같습니다: 최대 이미지 9개, 비디오 클립 3개, 오디오 클립 3개이며, 총 12개 파일로 제한됩니다, 각 레퍼런스 비디오 또는 오디오의 길이는 2초에서 15초 사이여야 하며, 이들의 총 길이는 15초를 초과할 수 없습니다. 레퍼런스를 비디오로 변환하려면 이미지 또는 비디오가 최소 1개 필요하며, 오디오만으로는 허용되지 않습니다.

공식 참조 가이드와 커뮤니티 보고서가 모두 동의하는 기법은 각 입력에 태그를 지정하고 작업을 할당하는 것입니다. 파일이 첨부된 정확한 순서대로 태그로 참조하세요 — <Picture 1>, <Video 1>, <Audio 1> — 그리고 나서 프롬프트에서 어떤 참조가 어떤 속성(아이덴티티, 스타일, 모션, 카메라, 음성)을 결정하는지 명시하세요. 공식 예제 프롬프트는 정확히 이 방식으로 시작하며, 이미지 1이 전체적인 분위기와 스타일 참조이고 이미지 2가 주인공이라고 선언합니다. 실무자들은 명시적 할당이 아홉 개의 이미지를 던져놓고 바라는 것보다 훨씬 더 효과적이라고 보고합니다.

사람들에게 렌더링 비용을 초래하는 두 가지 세부 사항:

• <Picture 1>은 무드 보드가 아니라 말 그대로 첫 프레임이며, 0.000초 시점에 있고 [Shot 1]에 속합니다. 그 안에 무엇이 있는지(스타일, 피사체, 구도, 장면 앵커)를 먼저 설명한 다음, 그로부터 이어지는 동작을 설명하세요. 그것을 힌트가 아니라 애니메이션 중인 스틸 이미지로 취급하세요.

• 체크포인트는 두 개로 나뉘어 있으며, 잘못된 것을 사용하면 조용히 실패합니다. fl2va는 텍스트-투-비디오와 첫/마지막 프레임 작업을 처리하며; ref2va는 레퍼런스-투-비디오를 처리합니다. 이것은 가장 많이 보고된 ComfyUI 오류입니다: R2V 그래프가 여전히 FL2VA 모델이 선택된 상태로 실행됩니다. 또한 알아둘 만한 점으로, ComfyUI 발표의 한 댓글 작성자가 지적했듯이 제공된 R2V 템플릿은 모델이 9개의 이미지 참조를 받을 수 있는데도 이미지 참조 슬롯이 두 개만 노출됩니다 — 이것은 템플릿 제한이지 모델 제한이 아닙니다.

호스팅 측에서는 리셀러 문서에 나온 실무자 메모 두 가지가 더 있습니다: ratio 매개변수는 ref2va 엔드포인트에서 필수이며 "adaptive"로 남겨둘 수 없습니다. 또한 중복 작업은 대기열에 쌓이지 않고 작업 동시성 제한으로 429를 반환하므로, 순차적으로 일괄 처리하거나 자체 대기열을 구축해야 합니다. 로컬에서는 ref_image_size의 기본값은 match이며, 더 빠릅니다. max는 참조 이미지의 짧은 변을 최대 2048픽셀까지 보존하지만 시간이 더 걸립니다.

로컬 실행에 실제로 소요되는 벽시계 시간

공식 전체 저장소를 다운로드하면 498GB이고, ComfyUI로 재포장된 미러는 343GB입니다. 둘 다 전체를 받을 필요는 없습니다. ComfyUI 자체 튜토리얼에서 텍스트-투-비디오 및 이미지-투-비디오용으로 나열한 네 개 파일은 약 42.5GB입니다:

• 확산 모델 — minimax_h3_fl2va_pruned_int8_convrot.safetensors, 20.97 GB, models/diffusion_models.

• 텍스트 인코더 — qwen3vl_32b_minimax_h3_nvfp4_awq.safetensors, 15.69 GB, models/text_encoders에.

• 비디오 VAE — minimax_h3_video_vae_fp16.safetensors, 5.21 GB, 다음 경로에models/vae.

• Audio VAE — minimax_h3_audio_vae_fp32.safetensors, 0.61 GB, models/vae에도 넣습니다.

• reference-to-video용 추가 — minimax_h3_ref2va_pruned_int8_convrot.safetensors, 또 다른 20.97 GB.

그 42.5GB는 VRAM 수치가 아니라 디스크 용량이며, 데이터 조각들은 스트리밍되고 오프로드됩니다. 이 모델이 컨슈머 그래픽 카드에 들어가는 이유는 ComfyUI가 문서화한 엔지니어링 트릭 덕분입니다. {{1}}파라미터의 약 40%가 AdaLN 변조 분기에 존재하는데, 해당 출력은 사전 계산되어 기능적으로 동등한 룩업 테이블로 대체될 수 있으며{{/1}}, 이를 통해 로드되는 모델이 33.12B에서 약 20.11B로 줄어듭니다. ComfyUI에 따르면 품질 손실은 없습니다. 전체 정밀도라면 123.6GB입니다. {{2}}파인튜닝을 하거나 마지막 몇 퍼센트의 충실도를 추구하는 경우, 프루닝되지 않은 int8 체크포인트(각 34.04GB)와 bf16 체크포인트(각 66.28GB)가 존재합니다{{/2}}.

ComfyUI 0.30.0 이상이 필요하며, T2V, I2V, R2V 세 가지 템플릿이 포함되어 있습니다. 모든 가이드와 관리자가 첫 실행 시 공통으로 채택하는 기준 설정은 의도적으로 작게 설계되었습니다: 0.4 MP(864×480)의 16:9, 5초, 20스텝, simple 스케줄러를 사용하는 res_multistep 샘플러, denoise 1.0, 배치 1. 해상도나 길이를 변경하기 전에 비디오와 스테레오 오디오가 모두 포함된 MP4 파일 하나를 출력해 보세요. 예상할 수 있는 산술적 특이점 하나: 지속 시간은 17k+5 프레임 그리드에 맞춰지므로, 5초 요청은 124프레임이 되어 24fps에서 약 5.17초가 되고, 10초 요청은 243프레임, 즉 10.125초가 됩니다. 5~15초 범위의 요청이 더 안전한 영역입니다.

커뮤니티 보고에서 본 실제 소요 시간은 다음과 같습니다 (모든 실행은 단일 실행, 통제되지 않은 조건, 서로 다른 설정이었습니다 — 위 차트는 각 설정을 막대 옆에 표시합니다): 32GB 시스템 RAM과 빠른 NVMe를 갖춘 12GB RTX 3060은 동적 오프로드를 사용하여 864×480 / 124프레임 / 20스텝 기준을 9분 미만으로 완료했습니다. SageAttention을 활성화한 16GB RTX 4090 노트북은 960×540, 5초, 20스텝을 182초 만에 처리했습니다. 단일 RTX 5090의 NVFP4 빌드는 10스텝에서 243프레임(10.1초)의 864×480 클립을 175초 만에 생성했으며, VRAM 사용량은 최대 26.9GiB, 디스크 파일은 31.7GB에 불과했습니다. SGLang 자체 쿡북 레퍼런스 — 레이어별 오프로드를 적용한 두 개의 RTX 5090에서 1344×768, 124프레임, 50스텝 — 는 559.67초가 걸렸습니다. 그리고 비공식 MLX 포트를 통한 Apple Silicon 경로는 단일 클립 기준 45분 미만이 걸렸습니다.

그 보고서들에서 추려낸 실용적인 메모:

• 시스템 RAM과 디스크 속도는 부하를 감당하는 필수 요소이지 선택 사항이 아닙니다.12GB 카드에서는 선택된 파일이 설계상 VRAM을 초과하므로, 오프로드 경로는 RAM을 거친 후 SSD로 이어집니다. 성공적인 저VRAM 보고서 두 건 모두 32GB RAM이 포함되어 있습니다. 검증된 8GB 결과는 존재하지 않습니다.

• SageAttention은 유일한 무료 가속 방법입니다 — ComfyUI 기준 약 2배이며, 실행이 오프로드 트래픽에 의해 주도되는 경우에는 더 적습니다. 정확한 PyTorch 및 CUDA 빌드와 일치하는 휠과 ComfyUI-KJNodes를 설치한 다음 Patch Sage Attention KJ를 UNET 로더와 가이더 사이에 삽입하고 자동으로 설정하세요. 일부 H3 레이어가 FP16/BF16이 아니라는 경고가 표시될 수 있습니다. 해당 폴백은 문서화되어 있으며 정상적인 현상입니다.

• 스텝 수는 조정 가능합니다.5090 벤치마크는 10회, ComfyUI 베이스라인은 20회를 실행한 반면, SGLang 참조 구성은 50회를 사용합니다. 아무도 스텝별 품질 곡선을 발표하지 않았으므로, 50회가 필요하다고 가정하기 전에 자신만의 최소 스텝 수를 찾으세요.

• OOM에서 벗어나려면 한 번에 하나의 변수만 변경하십시오. 문서화된 복구 방법은 0.4 MP, 5초, 배치 1로 되돌리고 시도할 때마다 설정 하나만 조정하는 것입니다.

• 무음 오디오는 오디오 VAE가 비디오 출력 노드에 연결되지 않았음을 의미합니다. 이는 오디오 불량과는 구별되는 오류로, 모델이 소리 생성을 거부하는 것으로 오해하기 쉽습니다.

• Apple Silicon 지원은 비공식적입니다.Willison이 사용한 방법은 PipeNetwork/minimax-h3-mlx라는 커뮤니티 포트를 uv를 이용해 MLX 요구사항 파일을 대상으로 실행한 것이었습니다. 회사 자체 자료에는 SGLang, vLLM, Diffusers, ComfyUI가 언급되어 있으며, 일반적인 배포는 BF16에서 GPU 4개를 사용하고, Metal이나 MPS에 대해서는 언급하지 않습니다. Mac 지원은 커뮤니티가 유지 관리하는 것으로 간주하세요.

로컬 대 호스팅, 숫자로 보는 비교

2K 모듈과 프롬프트 전처리기가 호스팅 전용이기 때문에, 이것은 실제로 둘 중 하나를 고르는 문제가 아닙니다. 아키텍처가 권장하는 패턴은 다음과 같습니다: 768p에서 로컬로 반복하며 각 시도는 전기료와 3분만 소모하고, 그다음 마무리를 구매하세요. 초당 요금은 유지하는 컷에는 무난하지만, 버리는 40개에는 치명적입니다.

가격에 관해서는 주의하세요. 구매처에 따라 약 2배까지 차이가 나고, 공급업체의 자체 블로그 게시물에는 달러 수치가 명시되어 있지 않기 때문입니다. 단지 2K가 주류 모델의 3분의 1 미만이고, 768p가 경쟁사의 720p 가격의 절반 미만이라고만 언급했습니다. 구체적으로 게시된 내용은 다음과 같습니다: 현재 Hugging Face 저장소에 나열된 유일한 추론 제공업체인 fal의 요금은 768p에서 초당 $0.16, 2K에서 초당 $0.26. 보조 트래커들은 회사의 자체 정가가 상당히 낮다고 보고합니다 — 약 768p에서 초당 $0.09–$0.10, 2K에서 초당 $0.13–$0.14 — 그리고 그들은 1센트 단위까지 서로 일치하지 않으므로, 이러한 수치를 참고용으로만 간주하고 예산을 책정하기 전에 플랫폼 가격 페이지를 확인하세요. 또한 참조 동영상은 생성된 출력물과 별도로 자체 길이에 따라 청구된다는 점도 예산에 반영하세요.

실제 숫자로 계산해 보자. 8초짜리 키퍼 클립 100개는 각각 8초일 때 생성 시간 800초가 된다. 2K 요금 $0.14 기준으로는 약 $112, fal의 $0.26 기준으로는 대략 $208, 그리고 낮은 공시가로 768p로 전달한다면 약 $76이다. 키퍼 하나당 리젝트 40개가 청구액을 결정하며, 그런 리젝트들은 로컬에서 생성해야 한다. 이것이 비교하는 가격을 정직하게 유지해야 하는 이유이기도 하다. OrcaRouter에서는 해당 파이프라인의 텍스트 측면이 공급자 목록에 0% 마크업으로 전달되므로, 공급업체가 가격을 인하하면 마진 재계산 후가 아니라 같은 날 바로 반영된다. 비디오 생성은 다시 말하지만 우리 것이 아니다. 요점은 컴파일 단계가 당신이 신경 써야 할 라인 아이템이 되어서는 안 된다는 것뿐이다.

이것을 기반으로 제품을 만들기 전에 라이선스를 읽으십시오.

이 부분은 대부분의 '사용 방법' 안내서가 생략하는 부분이며, 많은 독자에게 결정을 바꾸는 유일한 부분입니다. 저장소의 LICENSE 파일을 직접 읽었습니다. 가중치는 H3 Community License Agreement에 따라 제공되며, 오픈소스 라이선스가 아니라 그 안에는 요약해서 인용할 만큼 특이한 조항이 포함되어 있습니다:

• 지역. 라이선스는 '적용 지역'을 전 세계로 정의하되, 제외: 유럽연합, 영국, 대한민국, 미국. 명백히 해석하면, 이는 현재 로컬 생성 결과를 게시하고 있는 많은 사람들을 배제한다 — 그리고 그 제한은 가중치뿐만 아니라 출력물에도 적용되도록 작성되어 있다.

• 출처 표시. 상업적 사용은 제품 인터페이스에 "H3"를 표시해야 하며, 라이선스는 "Powered by H3" 표시를 권장합니다.

• 수익 기준. 이를 기반으로 구축한 제품 또는 서비스로 연간 2천만 달러 이상을 벌어들이는 조직은 회사의 별도 서면 승인을 받아야 합니다.

• 증류 금지. H3 또는 그 출력물을 H3 파생물 외의 다른 AI 모델을 개선하는 데 사용할 수 없습니다. 이는 표준 합성 데이터 방식을 배제합니다.

• 준거법. 홍콩 특별행정구 법을 준거법으로 하며, 홍콩 법원이 전속 관할권을 가진다.

• 진정으로 개방된 구성 요소가 하나 있습니다. Qwen3-VL-32B 텍스트 인코더는 Apache 2.0 라이선스를 따르며, 위의 제한 사항은 H3 가중치에 적용됩니다.

저희는 여러분의 변호사가 아니며, 이는 법률 자문이 아닙니다. 라이선스와 회사가 그와 함께 제공하는 Q&A 문서를 읽으십시오. 제외 지역에서 상업적으로 구축하는 경우 블로그의 해석보다는 변호사의 조언을 받으십시오. 실질적인 갈림길은 다음과 같습니다: 호스팅 API는 다른 조건의 별도 거래입니다. 즉, 커뮤니티 라이선스의 가중치에 대한 조건과는 다릅니다. 따라서 로컬 라이선스가 적합하지 않다면 API 경로가 여전히 가능할 수 있습니다. 구매하는 플랫폼의 약관을 확인하십시오.

1주차 테스트 계획

이 순서대로 5번 실행하면 H3가 당신의 파이프라인에 속하는지 여부를 알기에 충분합니다:

• 실행 1 — 파이프라인을 검증한다. T2V 템플릿, 864×480, 5초, 20스텝, res_multistep/simple. 성공 기준은 좋은 클립이 아니라 스테레오 오디오가 포함된 MP4다.

• 실행 2 — 형식이 중요함을 증명하세요. 동일한 주제를 두 번 다루세요: 한 번은 느슨한 한 줄 설명으로, 한 번은 [Shot 1] 더하기 overall_soundscape 더하기 non_diegetic_music로 작성하세요. 두 번째가 H3-Base보다 명확히 더 낫지 않다면, 설정에 뭔가 문제가 있는 것입니다.

• Run 3 — 대사 한 줄. 화자 한 명, 문장 하나, 전달 방식이 설명된 5초 분량입니다. 이는 오디오가 용도에 충분히 좋은지, 목표 언어가 어떻게 발음되는지 가장 빠르게 확인할 수 있는 방법입니다.

• Run 4 — 참조 규율. R2V를 ref2va 체크포인트와 함께 사용합니다. 두세 개의 레퍼런스는 각각 명시적으로 태그를 지정하고 역할을 부여하며, <Picture 1>은 실제 첫 번째 프레임으로 설명합니다. 그런 다음 의도적으로 깨뜨려 보세요. 동일한 레퍼런스를 할당 없이 연결하고 비교합니다.

• Run 5 — 마무리. 최고의 로컬 768p 프롬프트를 2K 호스팅 API로 가져가 Context-IR과 재생성 패스가 무엇을 더하는지 확인하세요. 그 델타가 초당 가격이 구매하는 것이며, 하이브리드 워크플로우의 가격을 정직하게 책정하는 유일한 방법입니다.

자주 묻는 질문

로컬 가중치에서 2K를 얻을 수 있나요?

아니요. 오픈 패키지는 H3-Base이며, 기본 캔버스는 768픽셀 단변(최대 768×1344)입니다. 2K는 회사가 호스팅 API에 유지해 둔 별도의 인컨텍스트 재생성 모듈인 H3-Regenerate-2K에서 비롯됩니다. 일반적인 업스케일러로 로컬에서 업스케일할 수 있지만, 이는 H3 자체의 재생성 패스와는 다른 작업이므로 그 결과와 일치하지 않습니다.

왜 동일한 프롬프트가 API와 ComfyUI에서 다르게 동작하나요?

API가 먼저 H3-Context-IR을 실행하기 때문입니다. API는 사용자의 텍스트와 참조 자료를 읽고, 그 관계를 추론한 다음, 구조화되고 강화된 지침을 H3-Base에 전달합니다. 로컬에서는 그러한 단계가 없습니다. H3-Base는 사용자의 원문(날 것 그대로)을 받습니다. API를 통해 훌륭한 클립을 생성하는 모호한 프롬프트는 사용자가 설치하지 않은 전처리기에 의해 구제되는 것입니다. 따라서 문서화된 프롬프트 형식이 API 사용자보다 로컬 사용자에게 훨씬 더 중요한 이유가 바로 이것입니다.

[0s-2s] 타임코드 템플릿이 잘못된 건가요?

이것은 배포된 가이드가 요구하는 바가 아닙니다. 회사의 VIDEO_PROMPT_WRITING_GUIDE_base_en.md는 [Shot N] 블록으로 구성되어 있으며, Shot 1에는 타임스탬프가 없고, 이후 컷은 절대 시간으로 표현합니다("At 00:03.500, the camera cuts to…"). 또한 네거티브 프롬프트 섹션이 없으므로, 인기 있는 템플릿의 "banned transitions" 목록은 커뮤니티에서 추가된 것입니다. 그렇긴 하지만, 실무자들은 타임코드 형식으로 API에서 좋은 결과를 얻고 있다고 보고하고 있습니다 — 아마도 Context-IR이 이를 정규화하기 때문일 것입니다. 우리의 해석: 문서화된 형식을 로컬 가중치에 사용하고, 전처리기가 얻었을 수도 있는 API 결과를 타임코드 괄호 덕분으로 돌리지 마십시오.

미국 또는 EU의 기업이 오픈 가중치를 상업적으로 사용할 수 있나요?

우리가 읽은 라이선스 텍스트는 적용 지역에서 EU, 영국, 한국, 미국을 제외하며, 그 제외 조항은 가중치뿐만 아니라 출력물에도 적용되도록 작성되어 있습니다. 이는 해당 지역에서의 상업적 배포에 심각한 장애물이며, 기술적 문제라기보다 법적 문제입니다. 라이선스와 Q&A 파일을 직접 읽고 조언을 구하십시오. 호스팅된 API는 커뮤니티 라이선스가 아니라 플랫폼 자체의 약관에 따라 적용되므로, 동일하게 제한된다고 가정하기보다 별도로 평가할 가치가 있습니다.

커밋하기 전에 확인할 사항

H3는 특정 형태의 작업에 비해 유난히 가성비가 좋다: 실제 샷 리스트를 작성할 의향이 있는, 짧고 사운드 디자인이 적용되었으며 레퍼런스 일관성을 갖춘 클립들 말이다. 그만큼 요청 방식에 대해서도 유난히 까다롭다. 가장 빠르게 변하는 부분이므로 직접 확인해볼 가치가 있는 세 가지는 다음과 같다: fal 옆에 더 많은 추론 제공자가 나타나는지(이것이 초당 가격을 낮추는 요인이다), ComfyUI R2V 템플릿이 두 개의 레퍼런스 슬롯을 넘어 모델의 아홉 개까지 확장되는지, 그리고 누군가 로컬 가중치와 대조 비교를 실행했을 때 커뮤니티의 타임코드 관행과 문서화된 샷 블록 형식 중 어느 쪽이 승리하는지이다. 아직 아무도 그 비교를 발표하지 않았다. 그때까지는 저장소의 매뉴얼이 더 나은 선택이다 — 그리고 그것은 이미 42GB를 쓴 그 다운로드 안에 그대로 들어 있다.