MiniMax H3 影片可以多長——以及為什麼只有 192 影格剛好是整秒

一支 MiniMax H3 影片可以是 4 到 15 秒。 上限是 24 fps 下的 362 影格，也就是 15.083 秒，而不是整整十五秒——多出來的那 0.083，正是底下每一件事的線索。

跟 MiniMax H3 要一支八秒的片子，你拿到的是 8.000 秒。要七秒，回來的是 7.292。 要十二秒，回來的是 12.250。這不是模型四捨五入沒算好——它根本就不是按秒在運作。

H3 是按影格區塊渲染的，不是按秒

每一次 H3 渲染都是整數個 latent 區塊，影格數永遠落在這條式子上：

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 秒 和九秒的差別。

它開始要緊，是從這支片子不再單獨出現的那一刻起：

• 跟著音樂剪。 120 bpm 一小節是 2.000 秒。你要十秒，拿回來的是 7.292 或者 8.708——兩個都跟節拍網格對不上，而這種偏移會在一串鏡頭裡累積。
• 多支拼接。 六個 5.167 秒的鏡頭是 31.002 秒，不是 31。差得很小，但它會攢成 一條永遠對不準你打的標記的時間軸。
• 任何有硬性時段的場合。 六秒的前置廣告，H3 做不出這個長度。最接近的是 6.583，而它超了。

只要專案裡有任何時間限制，就拿 8.000 秒的區塊去搭，剩下的在剪輯裡裁掉。 這是模型唯一會乾乾淨淨交回來的長度。

落到手上怎麼用

三條值得記住：

1. 能要八秒就要八秒。 這是白送的精準度——每輸出秒的成本和其他值一模一樣， 而它是唯一整整齊齊到手的那個。
2. 看影格數，別看秒數那一欄。 影格是模型真正認下的東西。秒數是你事後自己 做的一次除法。
3. 別在提示詞裡跟這張網格較勁。 在提示詞裡寫「正好六秒」不會改變區塊的大小。 鏡頭內部的時間安排——比如某個節拍落在 00:04.500——是會被照辦的； 總長度沒得商量。

這套算術值得你自己算一遍。一分鐘就夠，除了 17n + 5 這條規則和 24 fps 之外不需要 任何資料，而它能一次了結一個看上去像是「模型行為不可預測」的問題。

或者讓介面替你做：這裡的 MiniMax H3 AI 影片生成器 只提供這張網格真的渲染得 出來的長度，所以你挑的那個數字，就是你拿回來的秒數。