MiniMax H3 가 딱 떨어지게 주는 길이는 192 프레임 하나뿐

MiniMax H3 에 8초를 요청하면 8.000초가 나옵니다. 7초를 요청하면 7.292초가 나옵니다. 12초를 요청하면 12.250초가 나옵니다. 모델이 반올림을 못 하는 것이 아니라, 애초에 초 단위로 일하지 않는 것입니다.

H3 는 초가 아니라 프레임 블록으로 만듭니다

H3 의 모든 결과물은 정수 개의 잠재 블록이고, 프레임 수는 언제나 여기에 떨어집니다.

frames = 17n + 5

24 fps 에서는 이것이 러닝타임을 확정합니다. 화면의 길이 조절은 요청이고, 실제로 만들어지는 것은 이 격자입니다. 여러분이 넣으신 값은 가장 가까운 유효 블록으로 맞춰집니다. ComfyUI 는 이 맞춤을 눈에 보이게 합니다. 길이를 정하고 프레임 칸이 튀는 것을 보세요.

API 가 받는 4~15초 범위라면 격자 전체를 표로 옮길 수 있을 만큼 작습니다.

굵게 표시한 줄이 하나 있고, 굵게 표시할 만한 줄도 그것 하나뿐입니다.

왜 딱 하나만 정수 초로 떨어지는가

프레임 수가 24 의 배수일 때 초 단위로 정확히 나뉩니다. 그러니 이것을 풀면 됩니다.

17n + 5 ≡ 0  (mod 24)
17n     ≡ 19 (mod 24)

17 은 마침 24 를 법으로 할 때 자기 자신이 역원입니다 — 17 × 17 = 289 = 12 × 24 + 1. 양변에 17 을 곱하면:

n ≡ 17 × 19 ≡ 323 ≡ 11 (mod 24)

그래서 해는 n = 11, 35, 59, … 입니다. 11 다음은 35 인데, 그건 600 프레임이고 25초입니다. 15초 상한을 한참 넘습니다.

H3 가 실제로 만들 수 있는 범위 안에서 n = 11 이 유일한 답입니다. 192 프레임. 8.000초. 그 밖에 요청하실 수 있는 모든 값은 소수점이 붙은 길이입니다.

이게 문제가 되는 때와 되지 않는 때

피드에 바로 올릴 영상 한 편이라면 전혀 문제가 되지 않습니다. 반복 재생되는 영상을 보면서 8.708초와 9초를 구별할 사람은 없습니다.

문제가 되기 시작하는 것은 그 영상이 혼자가 아니게 되는 순간입니다.

• 음악에 맞춰 자를 때. 120 bpm 의 한 마디는 2.000초입니다. 10초를 요청하면 7.292초나 8.708초가 오는데, 둘 다 격자에서 밀리고 그 밀림이 이어 붙일수록 쌓입니다.
• 영상을 이어 붙일 때. 5.167초짜리 여섯 컷은 31초가 아니라 31.002초입니다. 작지만, 쌓이면 표시해 둔 지점과 끝내 맞지 않는 타임라인이 됩니다.
• 자리가 정해져 있을 때. 6초짜리 프리롤은 H3 가 만들 수 있는 길이가 아닙니다. 6.583 이 가장 가깝고, 그건 넘칩니다.

타이밍 제약이 조금이라도 있는 작업이라면 8.000초 블록으로 짓고 편집에서 다듬으세요. 모델이 깔끔하게 돌려주는 길이는 그것 하나뿐입니다.

실전으로 옮기면

세 가지만 기억하시면 됩니다.

1. 가능하면 8초를 요청하세요. 공짜로 얻는 정확도입니다. 결과물 초당 비용은 다른 값과 똑같은데, 정수로 도착하는 것은 이것뿐입니다.
2. 초가 아니라 프레임 수를 읽으세요. 프레임은 모델이 약속한 것이고, 초는 그다음에 여러분이 하는 나눗셈입니다.
3. 프롬프트로 격자와 싸우지 마세요. 프롬프트에 「정확히 6초」라고 쓴다고 블록 크기가 바뀌지 않습니다. 샷 안의 타이밍 — 예를 들어 00:04.500 의 박자 — 은 지켜지지만, 전체 러닝타임은 협상 대상이 아닙니다.

이 계산은 직접 해 보실 만합니다. 1분이면 되고, 17n + 5 규칙과 24 fps 말고는 다른 자료가 필요 없으며, 그러지 않으면 모델이 제멋대로 구는 것처럼 보이는 문제 하나를 끝내 줍니다.