MiniMax H3 비디오 길이는 15초입니다. 그 중 한 비디오에서 컷이 10개나 있었습니다.

누구나 첫날엔 똑같은 짓을 한다. duration 드롭다운을 열고 15를 보자마자 나누기부터 시작한다. 10분짜리 영화? 40회 생성. 3분짜리 설명 영상? 12회. 그런 다음 나눗셈이 만들어낸 숫자를 보고 탭을 닫고, 이 모델은 스토리가 있는 작업에는 아직 부적합하다고 결론을 내린다.

나도 똑같이 나눗셈을 했다. 그런 다음 실제 H3 클립 아홉 개에 ffmpeg를 돌렸고, 그 계산 전체가 우스워 보이게 만드는 무언가를 발견했다.

그중 한 클립은 15.10초다. 그 안에서 씬 감지기가 깔끔한 컷 열 개를 잡아낸다. 열 개. 다른 의상, 다른 프레이밍, 다른 배경, 전체 화면 타이틀 카드까지, 모두 생성 한 번의 비용으로 완성된 단일 생성 안에 들어 있다. 그 클립을 나눗셈이 시사하는 방식대로, 샷마다 생성 한 번씩 계획했다면 같은 15초에 열 배를 지불했을 것이다.

나눗셈이 실수다. 상한선은 스톱워치가 아니라 용기이고, 거의 아무도 그 용기를 채우지 않고 있다.

스트로브 시퀀스로 포착된 트릭 수행 중 스케이트보더, 단일 프레임 안에 여러 개의 뚜렷한 자세가 얼어 있다

하나의 프레임, 여러 개의 순간. duration 드롭다운이 당신을 설득해 빼앗아 가는 사고방식이 바로 이것이다.

핵심 요약

• duration 매개변수는 4에서 15 사이의 정수만 허용한다. 기본값은 8이다. 7.5는 없고 15를 초과하는 값도 없다.
• 모든 클립은 24 FPS, 최대 네이티브 2K로 반환되며, 영상과 같은 패스에서 생성된 스테레오 오디오가 포함된다.
• "15초" 클립은 실제로 362프레임, 즉 15.083초다. 지속 시간은 17프레임 그리드로 올림되며, 정확히 정수 초에 떨어지는 값은 duration: 8뿐이다.
• 한 번의 생성에 여러 샷을 담을 수 있다. 프롬프트에 SHOT 1 / CUT TO를 쓰면 모델이 추가 비용 없이 직접 컷을 넣어준다.
• API에 extend 매개변수는 없다. 15초를 넘기려면 체이닝을 써야 한다: 마지막 프레임을 다음 첫 프레임으로, 참조 이미지로 룩을 유지하고, 하드 콘캣으로 붙인다.

세 개의 클립으로 만든 45초 MiniMax H3 영상 길이 보기

이론보다 먼저 실제 결과물을 보자. MIDNIGHT BOWL이라는 45초 누들 스톨 광고다. 세 번의 생성, 각각 15초, 그 안에 각각 세 개의 샷. 총 아홉 개의 샷, 이음새를 숨기는 디졸브 없이 하나의 연속된 내러티브다.

전체 45초 컷. 트랜지션 효과 없이 세 개의 MiniMax H3 생성물을 이어붙였다. 셰프, 앞치마, 전구, 손으로 쓴 간판이 두 번의 핸드오프를 견뎌낸다.

MIDNIGHT BOWL 광고의 아홉 프레임을 3x3 콘택트 시트로 배열, SHOT 1부터 SHOT 9까지 타임코드와 함께 표시

아홉 개의 샷, 세 번의 생성. 각 행이 한 번의 생성이고, 각 열이 모델이 스스로 만든 컷이다. 샷 3과 4가 이어지는 이유는 생성 2가 생성 1의 마지막 프레임에서 시작하기 때문이며, 이것이 바로 이음새가 보이지 않는 이유다.

세 번의 생성. 아홉 번이 아니다. 그 차이가 이 글의 전부다.

나는 어떤 것도 손으로 컷하지 않았다. 각 생성에 타임코드가 있는 세 개의 샷을 요청했고, ffmpeg의 씬 감지기가 첫 번째에서 4.9초와 9.1초, 두 번째에서 4.9초와 9.0초, 세 번째에서 5.3초와 11.0초에 컷이 있음을 확인했다. 아홉 개의 샷, 세 장의 청구서.

MiniMax H3 영상 길이가 롱폼 계획을 망치는 이유

숫자 자체는 괜찮다. 이 세대 모델 기준으로 15초 상한은 넉넉한 편이고, 클립은 2K에 실제 스테레오 사운드가 붙는다. 사람들을 망가뜨리는 것은 그들이 계획에 쓰는 단위다.

초 단위로 예산을 세우면 1분짜리 작업은 "클립 4개", 10분짜리는 "클립 40개"가 되고, 어떤 것이든 40개는 연속성 작업의 악몽이다. 샷 단위로 예산을 세우면 1분짜리 작업은 약 12개의 샷을 담은 네 번의 생성이며, 이는 광고 한 편에 정상적인 커버리지 규모다. 같은 모델, 같은 상한선, 완전히 다른 제작 계획.

35mm 필름 스트립 하나에 서로 다른 세 장면이 연속된 프레임에 담긴 레트로 평면 포스터 일러스트레이션

초가 아닌 샷 단위로 예산을 세워라. 청구되는 스트립 하나, 그 안에 서로 다른 세 장면.

롱폼 계획을 망가뜨리는 두 번째 요인이 있다. 그것은 상한선이 전혀 아니다. 바로 이음새다. 개별 클립이 중간에 무너지는 경우는 거의 없다. 문제는 연결부에서 발생한다. 각 생성이 제각각 오디오 베드를 만들고 의상과 조명이 조금씩 어긋나기 때문이다. 이음새를 계획에 반영하면 45초는 쉽다. 무시하면 완벽한 클립 네 개가 여전히 네 개로만 보인다.

MiniMax H3 영상 길이의 실제: 17프레임 그리드 위의 4~15 정수 초

스펙부터 확인하자. 서로 다른 두 숫자가 유통되고 있기 때문이다. Atlas Cloud의 세 H3 엔드포인트 전체 라이브 API 스키마는 duration을 정확히 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15의 열거형으로 나열하며 기본값은 8이다. 정수만 허용되고, 분수는 없으며, 15를 넘는 값도 없다. 출시 보도도 같은 내용을 확인해 준다: 2K 출력, 4~15초, 정수 지속 시간만 허용 (MarkTechPost, 2026년 8월). MiniMax 자체 출시 게시물도 네이티브 스테레오 사운드를 지원하는 최대 15초 2K로 설명한다 (MiniMax, 2026년 8월).

여러 프로필 소개란이나 퀵스타트에서 "5~15초"라고 적힌 것을 여전히 볼 수 있고, 일부 플랫폼 내 카피도 그렇다. 스키마 열거형을 진실로 취급하라. 하한은 4이고, 내가 4초 클립으로 청구한 사실이 그것을 증명한다.

이제 거의 아무도 언급하지 않는 부분이다. 15초를 요청해도 360프레임을 받지 못한다. 362프레임을 받는다.

H3는 17프레임 블록 단위로 비디오를 만들고, 요청한 지속 시간을 24 FPS 기준 다음 17k + 5 프레임 수로 올림한다. 이 그리드는 ComfyUI 공식 H3 튜토리얼(ComfyUI Docs, 2026)에 문서화되어 있으며 API 쪽에서도 동일하게 유지된다. 나는 ffmpeg로 실제 H3 파일 아홉 개의 프레임을 세어봤다:

textCopy
1ffmpeg -i video-1.mp4 -map 0:v:0 -c copy -f null - 2>&1 | tail -1
2# frame=  362  ...
3#   Duration: 00:00:15.10, 1280x720, 24 fps
4

모든 15초 파일은 362프레임으로 돌아왔다. 모든 10초 파일은 243프레임이었다. 이 글을 위해 새로 돌린 세 생성도 362프레임이었고, 5단계의 4초 리허설은 107프레임이었다. 그리드에 대입해 보자: 362는 17x21+5, 243은 17x14+5, 107은 17x6+5다. 공식이 세 값 모두를 정확히 예측했고, 이런 일치 덕분에 나머지 표도 신뢰하게 된다.

세 가지 사실이 그 표에서 나온다.

duration: 8은 전체 범위에서 정확한 정수 초를 주는 유일한 값이며, 우연히도 기본값이다. 우연이 아니다. 17x11+5 = 192 = 8 x 24가 정확히 맞아떨어진다.

6을 요청하면 6.583초를 받는다. 반 초 이상의 공짜 화면이다. 13을 요청하면 13.667초를 받는다. 그리드는 항상 올림하고 내림은 절대 하지 않으므로 손해 볼 일이 없다.

음악에 맞춰 컷하거나 프레임 정확한 편집을 맞춰야 한다면, 절대 타임라인을 duration x 24로 계산하지 마라. 파일을 직접 측정하라. 정수 초를 가정하고 계획한 40클립 프로젝트는 마지막까지 가면 거의 4초가 어긋난다.

15초 MiniMax H3 생성 하나 안에 들어 있는 컷 열 개

서두에서 언급한 클립이다. 한 번의 생성, 362프레임, 컨테이너상 15.10초. 패션 키네틱 타이프 피스로, 단일 테이크가 아니라 편집된 뮤직비디오처럼 동작한다.

단일 MiniMax H3 생성 하나. 의상 변경, 프레이밍 변경, 스플릿 스크린, 전체 화면 타이틀 카드가 모두 15초 작업 하나 안에 있다.

눈으로 세는 대신 ffmpeg의 씬 감지기를 돌렸다:

textCopy
1ffmpeg -i video-5.mp4 -vf "select='gt(scene,0.6)',showinfo" -f null -
2# 18 breaks flagged, at 1.54 2.88 3.63 4.21 5.54 5.83 6.92 8.88 11.17 13.00 ...
3

그중 열 개는 처음 13초 안에서 발생한 깔끔한 샷 전환이다. 끝부분은 검은 배경에서 깜빡이는 타이틀 카드인데, 이게 원시 개수를 부풀리므로 열 개가 보수적으로 정직한 숫자다. 어느 쪽이든 한 개의 샷이 아니고, 세 개도 아니다.

이제 대조 실험을 보자. "H3는 항상 클립을 조각조각 낸다"는 반대 방향의 오류로, 똑같이 틀렸다. 다음 파일도 단일 15초 생성이고, 역시 362프레임이며, 같은 감지기가 그 안에서 컷이 정확히 0개임을 찾아낸다.

또 다른 단일 생성, 같은 362프레임, 감지된 컷 0개. 15초 내내 끊김 없는 연속 카메라 무브.

그러므로 상한선은 "15초 분량의 푸티지"가 아니다. 한 번의 끊김 없는 테이크부터 컷 열 개까지, 원하는 대로 자유롭게 세분할 수 있는 15초의 스크린 타임이다. 프롬프트로 제어하며, 어느 쪽이든 비용은 같다.

MiniMax H3 영상 길이를 구성하는 세 엔드포인트, 한 탭에

15초를 넘기려면 세 가지 다른 작업이 필요하다: 앵커 프레임을 만드는 작업, 애니메이션과 체이닝을 담당하는 작업, 피사체를 잃지 않으면서 카메라를 움직이는 작업. Atlas Cloud에서는 네 가지가 모두 같은 카탈로그에 하나의 키와 하나의 잔액으로 존재한다. 다음 섹션의 체인이 파일들을 여러 번 주고받기 때문에 여기서는 그 점이 중요하다.

세 H3 엔드포인트 모두 현재 할인이 없으므로 요금은 그대로다. 전체 모델 카탈로그에서 확인할 수 있다.

단일 요청을 작성하기 전에 알아두어야 할 세 가지 매개변수 함정이 있다. 문서 산문이 아니라 라이브 스키마에서 직접 가져온 것이다:

1. ratio는 엔드포인트마다 다르게 동작한다. text-to-video는 여섯 가지 비율을 제공하고 기본값은 1:1인데, 설정을 빼먹으면 조용히 정사각형 클립이 나온다. adaptive는 아예 받지 않는다. image-to-video는 오직 adaptive만 제공하므로 프레이밍은 첫 프레임을 따른다. reference-to-video만 전체 세트에 adaptive까지 갖춘 유일한 엔드포인트다.
2. resolution은 768P 또는 2K, 기본값은 2K다. 두 등급 모두 카탈로그에서 단일 초당 요금 아래에 있으므로 768P로 낮춰도 비용이 절약되지 않는다. 2K를 써라.
3. image-to-video에는 선택적 end_image도 있다. 시작뿐 아니라 클립의 양끝을 모두 고정할 수 있다. 아래 체이닝 기법을 양방향에서 조종할 수 있게 된다.

MiniMax H3 영상 길이 제한을 넘기는 방법, 단계별

이것이 전체 MIDNIGHT BOWL 빌드다. 아래 모든 프롬프트는 내가 실제로 보낸 것이며, 그대로 복사해도 된다. 총 런타임은 H3 생성 세 번과 스틸 한 장이며, 브라우저 탭 하나에서 재현할 수 있다.

1단계: 앵커 프레임 하나로 룩 고정하기

비디오부터 시작하지 마라. 진심으로 마음에 드는 스틸 하나부터 시작하라. 체인의 모든 클립이 그 스틸의 조명, 의상, 간판을 물려받기 때문이다. 이 단계를 틀리면 비싸고, 제대로 하면 센트 몇 푼이다.

모델: openai/gpt-image-2/text-to-image. 설정: 품질 high, 비율 16:9.

textCopy
1Film still, 2am at a narrow Tokyo back-alley noodle stall. A 50-year-old chef in a navy apron and white bandana leans over a steaming stockpot behind a scratched wooden counter, sleeves rolled to the elbow, forearms lit hot orange by a single hanging bulb. Rain-slick asphalt reflects red and green signage; paper lanterns and a hand-painted wooden sign reading "MIDNIGHT BOWL" hang above the counter. Steam rolls across the frame from camera right. Shot on a 35mm lens at f/2, shallow depth of field, deep shadows, warm tungsten key against cool blue night, visible fine film grain, no text overlays.
2

Atlas Cloud의 GPT Image 2 플레이그라운드, MIDNIGHT BOWL 앵커 프롬프트가 입력되고 완성된 스틸이 출력 패널에 표시

Atlas Cloud의 GPT Image 2: 품질을 high로, 16:9로 설정하고 오른쪽에서 앵커 프레임이 렌더링되었다.

MIDNIGHT BOWL 앵커 프레임: 비 내리는 뒷골목에서 외로운 전구 아래 김이 나는 스톡팟 뒤에 선 네이비 앞치마의 셰프

앵커 프레임. 이후 모든 것이 이 전구, 이 앞치마, 이 간판을 물려받는다.

2단계: 15초 MiniMax H3 생성 하나에 샷 세 개 넣기

예산을 바꾸는 핵심 동작이 여기 있다. 연속된 15초를 요청하는 대신 명시적 타임코드와 CUT TO라는 단어가 담긴 샷 리스트를 모델에 건네라. 모델이 청구되는 생성 하나 안에서 직접 컷을 만들어 줄 것이다.

모델: minimax/h3/image-to-video. 설정: resolution 2K, duration 15, ratio adaptive (유일한 옵션이며 프레이밍은 첫 프레임을 따름), 첫 프레임 = 1단계 스틸.

textCopy
1SHOT 1 (0-5s): Locked-off wide of the stall. Steam billows; the chef ladles broth into a black bowl; rain drips off the awning edge. SHOT 2 (5-10s): CUT TO a macro close-up of the ladle breaking the broth surface, golden fat swirling, chopped scallion falling in slow arcs. SHOT 3 (10-15s): CUT TO a medium shot of the chef looking straight into the lens, wiping his hands on the apron, and saying in Japanese with a tired smile: "Ippai, dozo." He sets the bowl down on the counter and the shot holds on his face.
2Audio: heavy rain on the awning, broth simmering, the ladle knocking the pot rim, a distant train, low late-night city hum. One line of clear male Japanese dialogue, natural room tone, no music.
3Keep the same chef, apron, bandana, bulb and signage in all three shots. Hard cuts only, no dissolves, no camera whip transitions. Warm tungsten key, cool blue night, 35mm look, film grain.
4

이 작업이 성공하는 데는 세 가지가 있다. 명시적 초 범위, 말 그대로의 CUT TO 문자열, 그리고 컷을 견뎌야 하는 모든 요소를 이름으로 지정하는 연속성 조항. 연속성 조항을 빼면 샷 3이 다른 앞치마로 돌아온다.

Atlas Cloud의 MiniMax H3 image-to-video 플레이그라운드, 앵커 프레임이 로드되고 duration 15와 2K가 선택되었으며 완성된 클립이 출력 패널에서 재생

Atlas Cloud의 MiniMax H3 image-to-video: 첫 프레임으로 앵커 프레임 로드, 해상도 2K, 완성된 클립이 오른쪽에 표시. Duration 슬라이더와 그에 연동되는 가격에 주목. 이 실행은 duration을 기본값 8에 두었기 때문에 버튼이 $1.12로 표시된다. 15로 설정하면 $2.10이 된다.

생성 1. 청구된 작업 하나, 샷 세 개(4.92초와 9.13초에서 측정된 컷), 립싱크가 있는 대사 한 줄, 네이티브 2560x1440, 같은 파일에 32kHz 스테레오 오디오까지.

3단계: 마지막 프레임에서 다음 15초 체이닝하기

extend 매개변수는 없다. 체인은 수동이며 매우 간단하다: 생성 1의 마지막 프레임을 뽑아 생성 2의 첫 프레임으로 다시 넣으면 된다.

bashCopy
1ffmpeg -sseof -0.08 -i generation-1.mp4 -frames:v 1 -q:v 2 handoff-frame-01.jpg
2

모델: minimax/h3/image-to-video를 다시 사용. 설정: 첫 프레임 = handoff-frame-01.jpg, resolution 2K, duration 15, ratio adaptive.

여기서 중요한 훈련은 무엇을 빼느냐다. 셰프를 다시 묘사하지 마라. 그는 이미 넘겨준 픽셀 안에 있다. 다시 묘사하면 모델이 그를 재해석할 허가를 받게 된다.

textCopy
1Continue from this exact frame, same man, same apron, same light. SHOT 1 (0-5s): He slides the bowl across the counter with both hands toward camera. SHOT 2 (5-10s): CUT TO over-the-shoulder of a customer's hands lifting wooden chopsticks and splitting them, sleeve cuffs of a wet grey raincoat visible. SHOT 3 (10-15s): CUT TO an extreme macro noodle pull, steam curling up past the lens, broth dripping back into the bowl.
2Audio: continuous rain and simmering carried over from before, ceramic on wood, chopsticks snapping, a slurp, the same distant train. No music, no narration.
3Hard cuts only. Same tungsten key from the hanging bulb, same cool blue night behind, same 35mm shallow depth of field and film grain.
4

생성 2, 생성 1의 마지막 프레임에서 시작. 같은 셰프, 같은 반다나 패턴, 같은 네이비 상의, 뒤쪽의 같은 주방. 다시 샷 세 개, 4.92초와 9.04초에서 컷.

생성 1과 생성 2 사이의 이음새를 가로지르는 2초 루프

이음새 자체: 생성 1의 마지막 1초에서 생성 2의 첫 1초. 트랜지션 효과 없이 그냥 컷이다.

4단계: Reference-to-Video로 카메라 움직이기

마지막 프레임 체이닝에는 내장된 한계가 있다: 이전 카메라가 서 있던 자리에서 항상 재개된다는 것. 같은 피사체를 유지하면서 진짜 새로운 각도로 점프하려면 엔드포인트를 바꿔라.

모델: minimax/h3/reference-to-video. 설정: refers = 1단계 앵커 프레임 + 생성 2의 마지막 프레임, resolution 2K, duration 15, ratio는 여기서 adaptive로 두지 말고 명시적으로 16:9로 설정. 이 엔드포인트는 참조 이미지 최대 9개, 참조 비디오 3개, 오디오 클립 3개를 허용하며 참조 비디오는 총 15초로 제한된다 (MarkTechPost, 2026년 8월).

textCopy
1Wide low-angle shot from the middle of the wet street looking back at the same noodle stall, the same chef inside it. SHOT 1 (0-6s): Rain streaks through the frame; two silhouetted customers sit at the counter; the chef works under the single bulb. SHOT 2 (6-11s): CUT TO the hand-painted wooden sign as kinetic white type animates on beside it, letter by letter: "MIDNIGHT BOWL - OPEN TILL 4AM". Type stays razor-sharp and locked to the sign as the camera drifts. SHOT 3 (11-15s): CUT BACK to the wide as the chef looks up, raises one hand in a small wave, and the bulb flickers once.
2Audio: rain, street ambience, a scooter passing, the same faint train, a single low sub hit as the type lands. No dialogue.
3Same chef, same apron and bandana, same signage and lantern colours as the reference images. Hard cuts only, film grain, 35mm, warm tungsten against cool blue.
4

그 ratio 지시는 과잉 대응이 아니다. 이 엔드포인트에서 드롭다운을 그대로 두면 어떤 일이 일어나는지 보자:

Atlas Cloud의 MiniMax H3 reference-to-video 플레이그라운드, 참조 이미지 두 개가 로드되고 종횡비가 adaptive로 남았으며 출력 패널에 400 검증 오류 표시

Atlas Cloud의 MiniMax H3 reference-to-video: 참조 이미지 두 개 로드, 해상도 2K, 종횡비는 여전히 adaptive 기본값. 실행 결과 400 오류: "ratio is required for t2va (text-only) and cannot be 'adaptive'; allowed: 16:9/4:3/1:1/3:4/9:16/21:9". 명시적으로 설정하면 같은 요청이 통과하며, 아래 클립이 그렇게 만들어진 것이다. 위의 페이지 소개 문구도 "768P/1080P/2K, 5s/10s"라고 적혀 있지만 스키마는 768P 또는 2K, 4~15초라고 말한다. 스키마를 믿어라.

플레이그라운드의 비율 드롭다운이 세 차례 시도에서도 스크립트된 변경을 유지하지 못해서, 성공한 생성 3는 요청 본문에 ratio: "16:9"를 설정해 API로 만들어졌다. 실패한 실행 비용은 0이었다.

생성 3. 젖은 길 건너편에서 찍은 완전히 새로운 카메라 위치, 같은 셰프, 카메라가 움직이는 동안 간판의 애니메이션 흰색 타입은 선명하게 유지. 5.29초와 10.96초에서 컷.

밤의 일본 음식 스탠드를 나란히 비교한 원본 앵커 프레임과 3세대 프레임, 41초 후와 두 번의 핸드오프 후에도 같은 셰프와 간판 표시

왼쪽: 1단계 앵커. 오른쪽: 41초 시점의 생성 3, 두 번의 핸드오프 후. 같은 셰프, 같은 반다나, 같은 네이비 상의, 같은 손으로 쓴 간판, 같은 빨간 등롱.

5단계: 실제 MiniMax H3 영상 길이 측정 후 이어붙이기

마무리할 두 가지 습관이 있다. 첫째, 15초 전체를 사기 전에 값싼 리허설을 돌려라. 같은 프롬프트, duration 4로 약 4분의 1 가격에 모델이 샷 리스트를 이해했는지 확인할 수 있다.

같은 샷 리스트의 4초 리허설. 107프레임으로 측정되었고 이는 4.458초로 그리드 예측과 정확히 일치한다. 전체 테이크를 사기 전에 모델이 장면을 이해했는지 확인하기에 충분하다.

둘째, 컷하기 전에 모든 파일을 측정하라. 요청한 길이와 실제가 같지 않기 때문이다:

bashCopy
1# real frame count and container duration, not duration x 24
2ffmpeg -i generation-1.mp4 -map 0:v:0 -c copy -f null - 2>&1 | grep -o 'frame= *[0-9]*' | tail -1
3
4# hard-cut concat, no transitions, no re-encode
5printf "file 'generation-1.mp4'\nfile 'generation-2.mp4'\nfile 'generation-3.mp4'\n" > list.txt
6ffmpeg -f concat -safe 0 -i list.txt -c copy midnight-bowl-45s.mp4
7

각각 362프레임인 파일 세 개는 총 1086프레임이며, 완성된 콘캣에서 실제로 측정했다: 45.25초의 화면, 45초가 아니라. 차이가 작아 보일 수 있지만, 40개를 이어붙일 때는 얘기가 다르다.

변형: 대화, 세로, 그리고 4초 리허설

체인이 작동하면 같은 세 엔드포인트가 사람들이 실제로 요구하는 대부분을 해결한다.

숏과 리버스 숏 대화. 대화의 양쪽을 서로 다른 생성이 아니라 하나의 생성 안에 넣어라. 립싱크와 오디오 베드는 단일 작업 내에서는 연속적이지만 작업 간에는 독립적이다. 따라서 대화를 두 생성으로 나누면 서로 무관한 두 개의 룸톤이 나온다. 교환은 한 클립 안에 유지하라.

계단참에서 다투는 두 젊은 배우, 하드 윈도우 라이트가 그들을 비스듬히 비추고 어깨 너머로 촬영

숏과 리버스 숏은 두 각도가 같은 생성 안에 있는 한 작동한다.

세로. image-to-video에서는 비율을 설정하지 않고 첫 프레임을 설정한다. 세로 앵커를 생성하면 adaptive가 그것을 따른다. 내가 측정한 클립 중 하나는 16:9 형제들과 같은 243프레임으로 1280x2276으로 나왔다. 프레임 그리드는 종횡비를 신경 쓰지 않는다.

4초 리허설을 표준 관행으로. 초당 $0.14에서 4초는 $0.56이고 풀 테이크는 $2.10이다. 아홉 샷 빌드에서 모든 생성을 커밋하기 전에 리허설하는 비용은 15초 작업 하나가 낭비되는 것보다 적다.

상한선이 진짜로 아프게 작용하는 곳. 15초보다 긴 끊김 없는 퍼포먼스가 필요한 작업이다. 연속 30초 모놀로그는 체이닝 문제가 아니라 이음새를 가로지르는 립싱크 문제이며, 어떤 프롬프트 훈련도 그것을 고치지 못한다.

45초 MiniMax H3 영상 길이의 비용

초당 $0.14에서 15초 생성 1회는 $2.10이다. 그것이 유일하게 필요한 숫자이고 나머지는 전부 곱셈이다. 흥미로운 열은 마지막 열이다.

샷당 열을 읽으면 상한선에 대한 공포가 대부분 사라진다. 샷당 생성 한 번으로 계획하면 샷당 $2.10이다. 각 생성에 샷 세 개를 담으면 샷당 $0.70이다. 같은 모델, 같은 15초 상한, 청구서의 3분의 1.

채택률 열이 사람들이 잊는 부분이다. 매번 첫 시도에 쓸 만한 결과가 나오는 일은 없고, 그걸 가정하는 계획은 2분 만에 예산이 바닥나는 계획이다.

상한선이 카탈로그의 다른 모든 것과 비교해서 어디쯤인지 맥락을 보려면, 다음은 모두 2026년 8월 4일 기준이다:

두 가지 결론. H3의 15초는 현재 세대의 최상위에 있으며 뒤처진 것이 아니다. Veo 3.1은 8초가 최대다. 그리고 진짜 필요한 것이 하나의 엔드포인트에서 나오는 긴 파일 하나라면 전용 extend 모델이 존재하지만, 체인 중간에 모델을 바꾸면 얼굴도 바뀐다.

오디오, 가중치, MiniMax H3 영상 길이에 대한 솔직한 메모 하나

세 가지 주의사항이며, 어느 것도 상한선을 움직이지 않는다.

오디오는 생성 간에 전달되지 않는다. 각 작업은 제각각 스테레오 베드를 처음부터 구성한다. 체인된 클립 세 개는 서로 무관한 빗소리 베드 세 개를 뜻하며, 화면이 완벽하게 일치해도 그 변화가 들린다. 두 가지 해결책: 모든 프롬프트에 분위기 조항을 동일하게 적어 베드가 비슷하게 나오도록 하거나, 이어붙인 컷을 음소거하고 그 위에 연속 트랙 하나를 깔아라. 대화는 단일 생성 안에 유지하라.

왼쪽에 서로 분리된 짧은 오디오 파형 조각들, 오른쪽에 하나의 연속된 긴 파형, 옅은 단일 배경

왼쪽: 체이닝이 실제로 주는 것. 오른쪽: 그 아래에 직접 구축해야 하는 것.

자체 호스팅으로 더 긴 클립이 가능해지지는 않는다. 오픈 가중치는 2026년 8월 2일에 공개되었고 (Hugging Face, 2026년 8월), 로컬에서 실행하면 ComfyUI 설정 노트에 따라 32의 배수로 반올림된 768픽셀 숏 엣지가 나온다. 17프레임 그리드와 15초 상한선은 동일하다. 커뮤니티 라이선스도 현재 EU, 영국, 한국, 미국을 커버하지 않으므로 대부분 팀에게 API가 현실적인 경로다.

모델이 조용히 당신을 다시 쓸 수 있다. 요청한 요소를 조용히 버리고도 completed를 반환하는 H3 작업을 본 적이 있다. 모든 클립에서 프레임을 뽑아 이어붙이기 전에 직접 확인하라. 아홉 샷 체인에서 확인하지 않은 클립 하나는 낭비된 이음새 하나다.

자주 묻는 질문

MiniMax H3 영상 길이의 최대치는 얼마인가요?

15초입니다. duration 매개변수는 4에서 15 사이의 정수 열거형이며 기본값은 8이므로 16은 거부되고 7.5는 유효한 값이 아닙니다. 모든 클립은 24 FPS, 최대 네이티브 2K이며 영상과 함께 생성된 스테레오 오디오가 포함됩니다.

MiniMax H3가 15초보다 긴 영상을 생성할 수 있나요?

단일 생성으로는 불가능하며, API에 extend 매개변수도 없습니다. 15초를 넘기려면 체이닝을 사용합니다: 한 클립의 마지막 프레임을 다음 클립의 첫 프레임으로 넣고, 새 카메라 각도가 필요하면 reference-to-video를 사용한 다음 하드 컷으로 이어붙입니다. 일부 소비자용 프런트엔드는 H3 위에 자체 extend 기능을 얹어 약 30초까지 도달하지만, 그건 모델이 더 길게 생성하는 것이 아니라 제품이 이어붙이는 것입니다.

15초 MiniMax H3 클립이 실제로는 15.08초인 이유는 무엇인가요?

지속 시간이 17프레임 그리드로 올림되기 때문입니다. 15초를 요청하면 362프레임이 반환되고, 이는 17x21+5이며 24 FPS에서 15.083초입니다. 10을 요청하면 243프레임, 즉 10.125초입니다. 정확히 정수 초에 떨어지는 값은 duration: 8뿐이며 정확히 192프레임입니다. 프레임 정확한 편집이라면 duration x 24로 계산하지 말고 각 파일을 직접 측정하세요.

하나의 MiniMax H3 생성에 여러 샷을 넣을 수 있나요?

가능하며, 그것이 가장 큰 비용 절감 수단입니다. 타임코드가 명시된 샷을 CUT TO라는 글자 그대로의 표현과 함께 프롬프트에 쓰고, 컷을 견뎌야 할 요소를 명명하는 연속성 조항을 추가하세요. 실제 15초 생성 하나에서 깔끔한 컷 열 개를 측정했습니다. 생성당 샷 세 개는 안정적이고 확실한 수치이며, $2.10 클립 하나를 샷당 $0.70짜리 세 개로 바꿔줍니다.

MiniMax H3 영상 길이를 짧게 하면 비용이 줄어드나요?

네, 선형적으로 줄어듭니다. 초당 $0.14로 청구되므로 4초 리허설은 $0.56이고 15초 풀 테이크는 $2.10입니다. 해상도는 다른 이야기입니다. 768P와 2K가 카탈로그에서 단일 요금 아래에 있으므로 해상도를 낮춰도 절약되는 것이 없습니다. 클립을 짧게 하세요. 픽셀을 낮추지 말고.

1분짜리 영상에 MiniMax H3 클립이 몇 개 필요한가요?

매번 15초를 가득 채운다면 네 개입니다. 하지만 샷 단위로 세어보세요: 생성 네 개에 각각 샷 세 개면 12개의 샷 커버리지이며, 1분짜리 광고에 정상적인 규모입니다. 그런 다음 예산에 대략 3배를 곱해 버릴 테이크를 감안하세요.