MiniMax H3 时长为什么总是小数：24 帧下只有一个整秒

跟 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 之外不需要任何资料，而它能一次性了结一个看上去像是「模型行为不可预测」的问题。