MiniMax H3 视频长度为15秒。我在其中一个视频中数出了十次剪辑。

每个人第一天做的都是同一件事。你打开时长下拉菜单，看到15，然后开始除法。十分钟的电影？四十个生成。三分钟的讲解视频？十二个。然后你看着除法得出的数字，关掉标签页，断定这个模型还无法处理任何有故事性的内容。

我也做了除法。然后我在九个真实的H3视频片段上运行了ffmpeg，发现了一些让整个计算看起来可笑的东西。

其中一个片段时长15.10秒。在它内部，场景检测器标记了十个干净的剪辑点。十个。不同的服装、不同的构图、不同的背景、全屏风格卡片，全部包含在一个生成中，成本只相当于一个生成的价格。如果我按照除法暗示的方式来规划那个片段——一个镜头一个生成——那么同样的十五秒，我需要支付十倍的费用。

除法是错的。上限不是秒表，而是一个容器，而且几乎没有人把它填满。

一个滑板者做特技动作的频闪序列，多个不同位置被冻结在单一帧中

一帧，多重瞬间。这就是时长下拉菜单让你忽略的思维模型。

关键要点

• duration 参数仅接受从4到15的整数。默认值为8。没有7.5，也没有超过15的值。
• 每个视频片段都以24FPS、最高原生2K分辨率返回，并带有与画面同时生成的立体声音频。
• 你的“15秒”片段实际上是362帧，即15.083秒。时长会向上取整到17帧的网格，只有 duration: 8 落在整秒上。
• 一次生成可以包含多个镜头。在提示词中写入 SHOT 1 / CUT TO，模型就会为你剪辑，无需额外费用。
• API中不存在 extend 参数。要超过15秒，需要通过链式生成：将最后一帧作为下一段的第一帧，使用参考图像保持外观，然后进行硬拼接。

观看由三个片段构建的45秒MiniMax H3视频时长

在理论之前，先看实际效果。一个45秒的拉面摊广告，名为“午夜碗”。三次生成，每次十五秒，每次内部包含三个镜头。九个镜头，一个连续的叙事片段，没有溶解过渡来隐藏接缝。

完整的45秒剪辑。三个MiniMax H3生成片段直接拼接，无过渡效果。厨师、围裙、灯泡和手绘招牌在两处接力中保持不变。

来自“午夜碗”广告的九帧画面，排列成3x3的缩略图，标注了镜头1至镜头9及时间码

九个镜头，三次生成。每一行是一次生成，每一列是模型自行完成的剪辑。镜头3和4相似，因为第二次生成从第一次生成的最后一帧开始，这正是接缝不可见的原因。

三次生成，不是九次。这个差距正是本文的全部意义所在。

我没有手动剪辑任何部分。我要求每次生成提供三个有时间码的镜头，ffmpeg的场景检测器在第一段中找到了位于4.9秒和9.1秒的剪辑点，第二段在4.9秒和9.0秒，第三段在5.3秒和11.0秒。九个镜头，三次计费。

为什么MiniMax H3视频时长会破坏长片计划

数字本身没问题。对于这一代模型，15秒的上限已经很慷慨了，并且片段是2K分辨率并带有真实的立体声。真正破坏人们计划的是他们用来规划的单位。

如果你以秒为单位做预算，一分钟的项目就是“四个片段”，十分钟的项目就是“40个片段”，而40个片段对于连续性工作来说无疑是一场噩梦。如果你以镜头为单位做预算，一分钟的项目就是四次生成，大约包含十二个镜头，这对于商业广告来说是正常的覆盖量。同一个模型，同一个上限，完全不同的制作计划。

复古平面海报插图：一条35毫米胶片，其中连续三帧各显示完全不同的场景

以镜头为单位做预算，而不是以秒为单位。一次计费的胶片条，内部包含三个不同场景。

还有第二件事会破坏长片计划，而且根本不是上限本身。是接缝。单个片段几乎不会在中间崩溃。它们会在连接处崩溃，因为每次生成都会创造自己的音轨，并在服装和灯光上略有偏差。为接缝做好计划，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帧块构建视频，并将你请求的时长向上取整到24FPS下下一个 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个片段的项目，如果假设整秒来规划，到最后会偏差近四秒。

一个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个断点，位于 1.54 2.88 3.63 4.21 5.54 5.83 6.92 8.88 11.17 13.00 ...
3

其中十个是前十三秒内干净的镜头切换。尾部是黑底上闪烁的标题卡，这抬高了原始计数，所以十个是保守诚实的数字。无论如何，它不是一个镜头，也不是三个。

现在是对照案例，因为“H3总是把你的片段切成碎片”是相反的失败，同样错误。下一个文件也是一个15秒的生成，也是362帧，相同的检测器在其中发现零个剪辑点。

另一个单一的生成，相同的362帧，零个检测到的剪辑点。整个十五秒是一个连续的镜头运动。

所以上限不是“十五秒的素材”。它是你可以随意细分的十五秒屏幕时间，从一次不间断的拍摄到十个剪辑点。你通过提示词控制它，并且无论哪种方式支付相同的费用。

MiniMax H3视频时长背后的三个端点，一览无余

要超过十五秒，需要三个不同的任务：一个用于制作锚点帧，一个用于动画和链式生成，一个用于移动相机而不丢失主体。在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视频时长限制

这是完整的“午夜碗”构建过程。下面的每个提示词都是我实际发送的，可以逐字复制。总运行时间是三次H3生成加一次静态图像，整个流程可以在浏览器标签页中复现。

步骤1：在一个锚点帧中锁定外观

不要从视频开始。从一张你真正喜欢的静态图像开始，因为链中的每个片段都会继承它的光线、服装和招牌。搞错这个代价高昂；做对只需几美分。

模型：openai/gpt-image-2/text-to-image。设置：质量 高，比例 16:9。

textCopy
1电影静帧，凌晨2点，东京狭窄后巷的拉面摊。一位50岁的厨师，穿着海军蓝围裙，头戴白色头巾，斜靠在一个冒热气的高汤锅后面，面前是划痕累累的木制柜台。袖子卷到肘部，前臂被一个悬挂灯泡映成炽热的橙色。雨水浸湿的柏油路反射着红色和绿色的招牌；纸灯笼和一块手绘木牌写着"MIDNIGHT BOWL"，挂在柜台上方。蒸汽从画面右侧横贯而过。使用35mm镜头，f/2光圈，浅景深，深阴影，暖色钨丝灯主光与冷色蓝色夜晚形成对比，可见的精细胶片颗粒，无文字叠加。
2

Atlas Cloud上的GPT Image 2操作界面，已填入"午夜碗"锚点提示词，输出面板中显示完成的图像

Atlas Cloud上的GPT Image 2：质量设置为高，16:9，右侧渲染出的锚点帧。

"午夜碗"锚点帧：一位厨师，穿着海军蓝围裙，在冒热气的高汤锅后面，悬挂灯泡下，雨夜后巷

锚点帧。下游所有内容都继承了这个灯泡、这件围裙和这个招牌。

步骤2：在一个15秒的MiniMax H3生成中放入三个镜头

这是改变预算的关键操作。不要要求一次连续的十五秒，而是给模型一个带有明确时间码的镜头列表，并使用 CUT TO 这个词。它会在一次计费的生成中为你完成剪辑。

模型：minimax/h3/image-to-video。设置：resolution 2K，duration 15，ratio adaptive（这里唯一的选择，构图跟随你的第一帧），第一帧 = 步骤1的静态图像。

textCopy
1镜头1 (0-5秒)：固定广角镜头，展示摊位。蒸汽滚滚；厨师将高汤舀入黑色碗中；雨水从遮阳篷边缘滴落。镜头2 (5-10秒)：切换到勺子在汤面上划过的微距特写，金色油脂旋转，切好的葱花呈慢弧线落下。镜头3 (10-15秒)：切换到厨师直视镜头的中景，在围裙上擦手，用日语带着疲惫的微笑说："いっぱい、どうぞ。" 他将碗放在柜台上，镜头停留在他的脸上。
2音频：遮阳篷上大雨的声音，高汤沸腾的声音，勺子碰到锅沿的声音，远处火车的声音，低沉的城市夜晚环境音。一句清晰的日语男性对话，自然的房间声，无音乐。
3在所有三个镜头中保持相同的厨师、围裙、头巾、灯泡和招牌。仅硬剪辑，无溶解，无相机快速过渡。暖色钨丝灯主光，冷色蓝色夜晚，35mm风格，胶片颗粒。
4

让这有效的是三件事：明确的秒数范围、文字字符串 CUT TO，以及底部的连续性条款，列出了所有必须在剪辑中保留下来的元素。省略连续性条款，镜头3会以不同的围裙出现。

Atlas Cloud上的MiniMax H3图像转视频操作界面，已加载锚点帧，选择了时长15和2K，输出面板中播放完成的片段

Atlas Cloud上的MiniMax H3图像转视频：锚点帧作为第一帧加载，分辨率2K，右侧是完成的片段。注意时长滑块和随之变化的价格。这次运行将时长留在了默认的8，所以按钮显示 $1.12；设为15则显示 $2.10。

生成1。一次计费任务，三个镜头（剪辑点测量为4.92秒和9.13秒），一句带口型同步的对话，原生2560x1440，以及同一文件中的32 kHz立体声音频。

步骤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
1从这一帧继续，同一个人，同一件围裙，同一束光。镜头1 (0-5秒)：他用双手将碗滑过柜台朝向镜头。镜头2 (5-10秒)：切换到顾客肩膀上方镜头，顾客的手拿起木筷子并分开，可见湿灰色雨衣的袖口。镜头3 (10-15秒)：切换到极端的面条微距特写，蒸汽在镜头前旋转上升，汤汁滴回碗中。
2音频：延续之前的持续雨声和沸腾声，陶瓷与木头的碰撞声，筷子分开声，吞咽声，同一列远处火车。无音乐，无旁白。
3仅硬剪辑。相同的悬挂灯泡钨丝主光，相同的背后冷色蓝色夜晚，相同的35mm浅景深和胶片颗粒。
4

生成2，从生成1的最后一帧开始。相同的厨师，相同的头巾图案，相同的海军蓝上衣，他身后相同的厨房。又是三个镜头，剪辑点在4.92秒和9.04秒。

生成一和生成二之间接缝处的两秒循环

接缝本身：生成1的最后一秒进入生成2的第一秒。无过渡效果，只是一个剪辑。

步骤4：使用参考转视频移动相机

最后一帧链式生成有一个固有的限制：它总是从先前相机所在的位置继续。要跳到一个真正新的角度同时保持相同的主体，请切换端点。

模型：minimax/h3/reference-to-video。设置：refers = 步骤1的锚点帧加上生成2的最后一帧，resolution 2K，duration 15，并在此处显式将 ratio 设置为 16:9，而不是保留在 adaptive 上。此端点最多接受九张参考图像、三个参考视频和三个音频片段，参考视频总时长上限为15秒（MarkTechPost，2026年8月）。

textCopy
1从湿漉漉的街道中间低角度广角镜头，回头看向同一个拉面摊，里面的同一个厨师。镜头1 (0-6秒)：雨丝划过画面；两个顾客剪影坐在柜台前；厨师在单个灯泡下工作。镜头2 (6-11秒)：切换到手绘木牌，旁边动态白色文字逐一动画出现："MIDNIGHT BOWL - OPEN TILL 4AM"。文字保持极其锐利，锁定在招牌上，同时相机漂移。镜头3 (11-15秒)：切回广角镜头，厨师抬头，微微挥手，灯泡闪烁一次。
2音频：雨声，街道环境音，一辆摩托车经过，同一列微弱的火车，文字落定时一声低沉的副音。无对话。
3与参考图像中相同的厨师、围裙和头巾，相同的招牌和灯笼颜色。仅硬剪辑，胶片颗粒，35mm，暖色钨丝灯与冷色蓝色对比。
4

那个 ratio 指令不是多疑。以下是你在该端点上保留下拉菜单默认值会发生的情况：

Atlas Cloud上的MiniMax H3参考转视频操作界面，已加载两张参考图像，长宽比保留在adaptive上，输出面板中显示400验证错误

Atlas Cloud上的MiniMax H3参考转视频：已加载两张参考图像，分辨率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是通过API在请求体中设置 ratio: "16:9" 实现的。失败的运行没有花费任何费用。

生成3。从湿漉漉的街道对面全新的相机位置，相同的厨师，招牌上的动态白色文字在相机漂移时保持极其锐利。剪辑点在5.29秒和10.96秒。

原始锚点帧与生成3中一帧的并排比较，显示相同的厨师和招牌，在41秒后和两次交接后

左：步骤1的锚点。右：生成3在41秒标记处，两次交接后。相同的厨师，相同的头巾，相同的海军蓝上衣，相同的手绘招牌，相同的红灯笼。

步骤5：测量真实的MiniMax H3视频时长，然后拼接

最后两个习惯。首先，在购买15秒之前，先进行一次廉价的排练。相同的提示词，duration 4，你就能以大约四分之一的价格知道模型是否理解了你的镜头列表。

相同镜头列表的4秒排练。测量为107帧，即4.458秒，与网格预测完全一致。足以在购买完整片段之前判断模型是否理解了场景。

其次，在剪辑之前测量每个文件，因为它们没有一个是你要的长度：

bashCopy
1# 真实帧数和封装时长，而不是 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# 硬剪辑拼接，无过渡，无重新编码
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秒。很小，直到你拼接四十个这样的片段。

变体：对话、竖屏和4秒排练

一旦链式生成工作，相同的三个端点覆盖了人们实际要求的大部分内容。

正打反打对话。 将对话的双方放在一次生成内，而不是跨越两次。口型同步和音轨在一个任务内是连续的，而在不同任务之间是独立的，因此跨越两次生成的对话会得到两个不相关的房间声。保持交流在一个片段内。

两名年轻演员在混凝土楼梯间平台上争执，硬窗光斜照在他们身上，越过肩膀拍摄

正打反打有效，只要两个角度都在同一个生成内。

竖屏。 在 image-to-video 上，你不设置比例，而是设置第一帧。生成一个高的锚点，adaptive 会跟随它。我测量过的一个片段以1280x2276分辨率返回，与它的16:9同辈具有相同的243帧数，因此帧网格不关心你的长宽比。

将4秒排练作为标准做法。 以每秒0.14美元计算，四秒是0.56美元，而完整片段是2.10美元。在一个九镜头的构建中，在承诺之前排练每个生成，成本低于一个浪费的15秒任务。

上限真正咬人的地方。 任何需要超过十五秒不间断表演的内容。一个连续的30秒独白不是链式生成问题，而是跨接缝的口型同步问题，再多的提示词纪律也无法解决。

45秒MiniMax H3视频时长的成本

以每秒0.14美元计算，一个完整的15秒生成为2.10美元。这是你唯一需要的数字；其他都是乘法。有趣的列是最后一列。

看每个镜头的成本列，关于上限的恐慌基本消失了。按每次生成一个镜头来规划，每个镜头成本为2.10美元。将三个镜头打包到每次生成中，每个镜头成本为0.70美元。相同的模型，相同的十五秒上限，账单只有三分之一。

保留率列是人们忘记的。没有东西每次第一次尝试都能返回可用的结果，而假设每次都能成功的计划会在第2分钟耗尽预算。

为了了解上限与目录中其他所有内容的相对位置，以下是截至2026年8月4日的当前情况：

两个结论。H3的十五秒处于当前一代的顶端，而不是落后；Veo 3.1上限为八秒。而且，如果你真正需要的是一个端点上的一个长文件，存在专门的扩展模型，但在链中切换模型意味着切换面孔。

关于音频、权重和MiniMax H3视频时长的一个诚实说明

三个注意事项，都不影响上限。

音频不会跨生成传递。 每个任务从头开始构建自己的立体声床。三个链式片段意味着三个不相关的雨声床，即使画面完美匹配，你也会听到变化。两个修复：在每个提示词中完全一致地写入环境音条款，使音床接近；或者静音拼接后的剪辑，在下面铺设一个连续的音轨。对于对话，保持交流在单个生成内。

左侧几个独立的短音频波形片段，之间有可见间隙；右侧是一个连续的长波形，背景为浅色

左：链式生成实际给你的。右：你必须在它下面构建的。

自托管不会解锁更长的片段。 开放权重于2026年8月2日发布（Hugging Face，2026年8月），本地运行会给你一个768像素的短边，四舍五入到32的倍数，根据ComfyUI的设置说明。17帧网格和15秒上限是相同的。社区许可证目前也不涵盖欧盟、英国、韩国或美国，因此对于大多数团队来说，API是实用途径。

模型可以静默地重写你。 我曾遇到过H3返回 completed 状态，但任务中它静默地丢弃了我要求的元素。从每个片段中提取帧，在拼接之前检查它们。在一个九镜头的链中，一个未检查的片段就是一个浪费的接缝。

常见问题

MiniMax H3视频的最大时长是多少？

十五秒。duration 参数是4到15的整数枚举，默认值为8，因此16被拒绝，7.5不是有效值。每个片段都是24FPS，最高原生2K分辨率，带有与画面同时生成的立体声音频。

MiniMax H3能生成超过15秒的视频吗？

单次生成不行，并且API没有 extend 参数。要超过15秒，需要通过链式生成：将一个片段的最后一帧作为下一个片段的第一帧，当需要新相机角度时使用 reference-to-video，然后用硬剪辑拼接。一些消费者前端在H3之上添加了自己的扩展功能，可以达到大约30秒，但那是产品在做拼接，而不是模型生成了更长的内容。

为什么我的15秒MiniMax H3片段实际上是15.08秒？

因为时长会向上取整到17帧的网格。请求15秒返回362帧，即17x21+5，在24FPS下是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 在目录中位于一个列出的费率之下，因此降低分辨率没有节省。缩短片段，而不是像素。

一分钟的视频需要多少MiniMax H3片段？

四个，如果你每次都填满十五秒。但改用镜头计数：四次生成，每次三个镜头，给你十二个镜头的覆盖量，这对于一分钟的商业广告来说是正常的量。然后大致将预算乘以三，以考虑你丢弃的片段。