ComfyUI 里 H3 的分辨率与帧数是怎么定的

2026-08-09

第一次打开 ComfyUI 的 MiniMax H3 官方模板，很多人会去找”分辨率填在哪、时长填在哪”，然后发现两个都找不到——至少不是以你预期的方式存在。

宽高不是直接填的，是一个叫 ResolutionSelector 的节点按 megapixels 算出来的；时长你倒是能填秒数，但那个秒数会先经过一条数学表达式，被改成另一个数字才送进模型。这不是模板作者故意绕，是模型本身的约束长这样。搞不清这两条链路，你调半天参数其实一直在原地打转。

下面按 ComfyUI 官方教程页（docs.comfy.org/tutorials/video/minimax/minimax-h3）与 Comfy-Org/workflow_templates 仓库里的模板 JSON，把这两件事讲清楚。口径是 2026-08-09 的快照，ComfyUI 侧对应 v0.31.0。

一、尺寸：你调的是 megapixels，不是像素

官方教程页给的约束是三条：短边 768px、上限 768×1344、取整到 32 的倍数；宽高比提供 16:9、9:16、1:1 三个预设；质量参数叫 Megapixels，教程推荐值是 1.0。

而 R2V 模板里 ResolutionSelector 的实际默认值是 16:9 (Widescreen)、megapixels 0.4、multiple 32。

模板内嵌了一张”Size Settings Reference”表，把 16:9 + multiple=32 这一组下 megapixels 到实际像素的映射全列了出来。这张表是理解整条链路的钥匙：

megapixels	输出尺寸	megapixels	输出尺寸
0.2	608 × 352	0.9	1280 × 736
0.3	736 × 416	0.98	1344 × 768
0.4	864 × 480	1.0	1376 × 768
0.5	960 × 544	1.2	1504 × 832
0.6	1056 × 608	1.5	1664 × 928
0.7	1152 × 640	1.8	1824 × 1024
0.8	1216 × 672	2.0	1920 × 1088

读这张表要注意几点。

一是 multiple=32 的取整在结果里到处都是痕迹：352、416、480、544……全是 32 的倍数。所以 megapixels 是个连续旋钮，落到宽高上却是离散的台阶，你把 0.4 微调成 0.42 未必换来任何变化。

二是这张表只对 16:9 有效。换成 9:16 或 1:1，同一个 megapixels 值会解出完全不同的宽高，模板里没有给那两档的对照表，别拿这一张去套。

三是别把 2.0 那一档当成”H3 支持 2K”。这是本篇最需要点破的一条。表格最后一行 1920×1088 是 ResolutionSelector 这个节点能算出来的数，而 MiniMax 官方 README 明确写的是：2K 生成要靠 H3-Regenerate-2K 模块，把 768p 结果连同原始上下文送回去重新生成。而这个模块尚未开源、只提供 API，ComfyUI 侧的模板里根本没有它。所以把 megapixels 拨到 2.0，跟 H3 官方口径里的 2K 是两码事，不能混着说。

二、模板默认 0.4 与教程推荐 1.0 的落差

这是模板里最容易被忽略的一处不一致：教程页推荐 1.0（1376×768），模板默认给的是 0.4（864×480）。差了不止一档。

官方没有解释这个差值的来由，我也不替它猜。能确定的只有一件事：模板加载进来的时候，ResolutionSelector 上摆着的是 0.4（864×480），不是教程页写着推荐的 1.0（1376×768）。 想按教程推荐来，就得自己动手把这个 megapixels 从 0.4 改到 1.0，模板不会替你改。

顺带说一句，模板默认值与官方建议不一致在这套 H3 模板里不是孤例——采样调度器那边也一样，模板 BasicScheduler 默认 simple，而模板自己的说明文字里写着，对参考密集的提示词，beta 或 normal 往往比 simple 表现更好。模板的默认值更像”能跑起来的保守起点”，不是”官方推荐配置”。

三、R2V 模板里那个写死的 1344×768

再看一个容易踩的点。R2V 模板里的 MiniMaxH3ReferenceToVideo 节点，width 是 1344、height 是 768、length 是 124、ref_image_size 是 match。

于是同一个 R2V 模板里就并排摆着两组尺寸数字：ResolutionSelector 的 0.4（换算出来 864×480），和 MiniMaxH3ReferenceToVideo 节点上写着的 1344×768（对应表里 0.98 那一档）。这两处怎么串起来、最终以哪一处为准，官方教程页与模板说明都没有交代，光看默认值也判断不出来，我不替它下结论。

能给你的是一个可执行的判定动作：把模板在 ComfyUI 里打开，找到 MiniMaxH3ReferenceToVideo，顺着它的 width 和 height 两个输入看——如果这两个输入是被上游连进来的，那管事的就是上游那条链；如果它们就是节点上直接填着的 1344 和 768，那管事的就是这两个写死的值。这一眼必须自己在节点图上看，别拿默认值猜。 顺带一提，教程页列出的三个模板（T2V / I2V / R2V）本来就是三份不同的工作流，别把在其中一份上摸出来的接线经验直接套到另一份。

另外 1344×768 恰好也是教程页写的”上限 768×1344”那个数——短边 768、长边 1344。至于表格里 1.0 及以上那几档（1376×768 起，一直到 1920×1088）与这条上限描述之间是什么关系，官方两处表述我们只能原样转述，这一点官方没有给进一步说明，本文不替它下结论。如果你要往 1.0 以上调，把这当成一个有待验证的区域，而不是一条已经确认可用的路。

四、帧数：你填的秒数会被吸附

时长这条链更绕一点。模板里有个 PrimitiveFloat，标签是 Duration，默认 5（秒）。看起来是”填几秒就几秒”，但它的值要先过一个 ComfyMathExpression 节点，表达式原样是：

max(5, round(a * 24)) + (5 - (max(5, round(a * 24)) % 17)) % 17

拆开看其实很清楚：

a * 24 —— 秒数乘帧率。24 这个数不是随便来的，MiniMax README 的输出规格表里写明输出帧率就是 24 FPS，模板末尾的 CreateVideo 节点 fps 参数也是 24。两处对上了。
round(...)、再 max(5, ...) —— 取整，并保证不低于 5 帧。
后半段那串 % 17 的运算 —— 把结果向上补齐到 17k+5 这个形式。

第三步就是官方教程里说的”snaps to the model’s 17-frame-per-block (17k+5) grid”的实现。H3 在时间维度上是按 17 帧一块处理的，合法的总帧数只能是 5、22、39、56、73、90、107、124……这类值。所以你填的秒数不会被原样使用，会被吸附到最近的合法帧数上。

拿模板自带的默认值走一遍这条式子，正好能对上模板里的另一个数：Duration 默认 5 秒，5 × 24 = 120 帧，120 不落在 17k+5 的网格上，补齐后是 124（17×7+5）——而 MiniMaxH3ReferenceToVideo 节点上 length 的默认值就是 124。两个数字严丝合缝，这条表达式在干什么也就一目了然了。按 24 FPS 折算，124 帧大约是 5.17 秒，比你填的 5 秒长一点点。

这个设计的实用含义是：在秒数上做精细调节意义不大。 你把 5 改成 5.1，乘 24 得 122.4，取整 122，补齐后还是 124，什么都没变。真要换时长，得跨过一整个 17 帧的台阶。想要确定的结果，不如反过来算：先定一个 17k+5 的目标帧数，再除以 24 得到该填的秒数。

还有一条边界要记住：MiniMax README 的规格表写的是输出时长 4–15 秒。表达式本身不会替你拦住越界的输入，别把秒数填到规格之外再去猜为什么不对劲。

五、按你的处境倒推该怎么填

罗列参数没什么用，下面按处境给决策路径。注意这些结论都是条件式的——显存够不够、跑多久、画质怎么样，官方教程页和 MiniMax README 都没有给数据，本文不比这几项。

你要先确认工作流能跑通。 什么都别动，模板给什么就用什么，包括 ResolutionSelector 上那个 0.4。这是官方模板作者摆在那儿的出厂状态，链路验证阶段变量越少越好——你这一步要回答的问题只有”从加载模型到出文件这条链通不通”，不是”尺寸调得对不对”。也不要在这一步的产物上评判任何输出质量。

链路通了，要按官方口径出片。 把生效的那一处尺寸挪到教程推荐的 1.0 那一档，也就是 1376×768。在这张 megapixels 表覆盖的所有档位里，只有 1.0 是官方教程明确写了推荐的，其余档位官方一个字都没表态——包括模板自己默认的 0.4。这是”有依据”和”没依据”的区别，不是”好”和”更好”的区别。

你走的是 R2V（参考生视频）。 别急着调 ResolutionSelector，先按第三节说的，在节点图上确认 MiniMaxH3ReferenceToVideo 的 width / height 是从上游连进来的、还是节点上写着的 1344×768。哪个在管事，就改哪个。这一步花不了三十秒，省下的是”改了半天没反应”的那种怀疑人生。

你机器吃力，想往下压。 表里 0.2（608×352）和 0.3（736×416）都在。往下压是合理的自救手段，但把它当成”先看构图对不对”的草稿档，别拿低档位的结果去下”这模型行不行”的结论。

你想往 1.0 以上冲。 前面说过，那几档与教程页写的 768×1344 上限之间的关系官方没说清楚，属于未验证区域。要试可以，但心里得清楚这不是官方铺好的路。尤其别把 2.0 当成 2K——真正的 2K 在未开源的 H3-Regenerate-2K 里。

你对时长有硬要求。 反着算：定 17k+5 的目标帧数，除以 24 得秒数填进 Duration。同时守住 README 的 4–15 秒规格。

最后提醒一句跨篇通用的：ComfyUI 侧用的是 Comfy-Org/MiniMax-H3 的量化权重（扩散模型是 pruned_int8_convrot，文本编码器是 nvfp4_awq），MiniMax 官方发布的 checkpoint 精度是 BF16。两边不是同一套权重，评估效果时不要把两边的结果混为一谈。至于许可条款，H3 用的是「MiniMax H3 Community License Agreement」，原文在 Hugging Face 仓库里，涉及能不能用、怎么用请直接读原文。

延伸阅读

本文依据 MiniMax H3 官方仓库（github.com/MiniMax-AI/MiniMax-H3）的 README 与模型配置文件，以及 ComfyUI 官方仓库（github.com/Comfy-Org/ComfyUI）的 README、release notes 整理，核对日 2026-08-09，ComfyUI 对应版本 v0.31.0。ComfyUI 侧的模型文件与工作流信息来自 docs.comfy.org 的官方教程与 Comfy-Org/workflow_templates 仓库的模板文件。本文内容为官方文档与仓库口径，未在本机部署或调用过 H3，也未在 ComfyUI 中运行过相关工作流。参数、默认值与功能随版本变动，请以官方文档与模板文件的实际内容为准；模型、部署方式与许可条款以官方最新说明为准。许可条款请以官方 LICENSE 原文为准，本文不构成法律意见。