H3 的 2K 为什么不是超分：H3-Regenerate-2K 的 in-context 重生成读法
看到「最高 2K」这四个字，绝大多数人的第一反应是：先生成一个低分辨率的视频，再挂一个超分模块把它放大。这个反应太自然了，以至于我第一次翻 MiniMax H3 的 README 时，也是直接跳过了这一段——直到发现官方在这里专门写了一句「不使用传统的专用超分模块」。
这句话不是措辞上的讲究，它决定了你在本地能拿到什么、拿不到什么。
官方到底是怎么描述这条路径的
截至 2026-08-09 的 MiniMax H3 官方仓库 README，2K 输出由一个叫 H3-Regenerate-2K 的模块负责。它做的事情是：把 H3-Base 产出的 768p 结果，连同原始的多模态上下文一起送回 H3，重新生成一遍 2K 分辨率的输出。
注意这里的动词是「重新生成」，不是「放大」。README 明确写了这条路径不使用传统的专用超分模块，而是让 H3 基础模型以 in-context 的方式重生成自己的低分辨率结果。
官方为这个选择给了两条理由，我按原意拆开：
第一条，重生成过程能最大程度复用 H3 基础模型的生成能力。 换句话说，2K 这一步没有引入一个能力体系完全不同的新网络，它调用的还是那个已经学会「怎么生成视频和音频」的模型本身。
第二条，也是更关键的一条：in-context 形式能在产生高分辨率输出时复用原始多模态上下文，从而恢复传统超分方法只能「猜」的信息，官方举的例子是小字与精细细节。
第二条值得多停一会儿。传统超分的输入只有那张低分辨率的画面，它并不知道这段视频原本是根据什么提示词、什么参考图、什么音频生成出来的。画面里一块糊掉的招牌，超分模块只能依据像素本身补出一个「看起来像字」的东西——按 README 的说法，这类信息传统超分只能「猜」。而 in-context 重生成拿得到原始上下文，那块招牌上原本要写什么，信息在上游是存在的。
官方还补了一句定性：in-context 重生成也是任务泛化的一个例子。 也就是说，在 MiniMax 的叙述里，「把自己的低分结果重做一遍」和「文生视频」「参考生视频」一样，只是同一个模型上的又一个任务，而不是一条外挂的后处理流水线。
为什么架构上说得通
这条设计如果孤立地看会觉得绕，但把它放回 H3 的整体数据流里就顺了。
README 的「Model Architecture」章节里，H3-Base 的做法是用各模态对应的 encoder 或 VAE 把不同模态编码好，组织成一条统一的 packed multimodal sequence，进 H3-Omni-Transformer 之前先用 RoPE 处理 token 之间的空间与时间关系。文本走 H3-Encoder，视觉输入由 H3-Encoder 与 H3-VisualVAE 共同编码，音频只走 H3-AudioVAE。
关键在于 H3-Omni-Transformer 这一层的性质：官方说它是一个 33B 参数的 dense、单流 Transformer，注意力层与 FFN 层都不含模态特定结构，模态特定的参数只存在于输入/输出层与 AdaLN 分支；位置关系用三维多模态旋转位置编码（MM-RoPE）表示 (t, h, w) 三个维度。
一个不区分模态的主干 + 一条统一的 packed 序列，意味着「把已经生成好的 768p 视频当成上下文的一部分再喂回去」在形式上和「把参考图当成上下文喂进去」没有本质区别——都是往那条序列里再塞一段 token。这就是官方把它叫做任务泛化的原因。
需要提醒的是，以上都是官方对架构的描述，我们没有部署过 H3，也没读到 Regenerate-2K 的实现代码。上面这段只是把 README 的两处说法对上，不要当成对内部实现的确认。
现实这一面：这个模块你现在拿不到
架构讲得通是一回事，能不能用是另一回事。README 里 H3 分三个模块，开源状态并不一致：
| 模块 | 职责 | 开源状态 |
|---|---|---|
| H3-Context-IR | 深度理解并精炼输入的多模态指令，转成 Context Intermediate Representation 再交给生成 | 未包含在本次开源发布中，官方提供 API |
| H3-Base | 基于 Context-IR 的输出生成音视频，产出 768p 结果 | 已开源（两个 checkpoint） |
| H3-Regenerate-2K | 把 768p 结果连同原始上下文送回 H3，重新生成 2K 输出 | 尚未开源，README 写「this module is not yet open-sourced. We will release it once it is ready.」，提供 API 用于验证官方结果 |
也就是说，开源出来的是中间那一层。前面的上下文理解和后面的 2K 重生成都只能走官方 API。README 在输入输出规格表里写得也很直白：输出分辨率支持多种，短边默认设为 768 像素，2K 生成需通过 H3-Regenerate-2K 实现。
这里有个连带影响容易被忽略：走官方 API 就意味着进入官方的安全护栏流程。README 的「Safety Guardrails」写明，用户提交的文本、图像与视频以及增强后的提示词都要经过自动审核，疑似违法、色情或侵犯第三方权利的内容可能被拦截；官方同时承认这类过滤无法消除误判与漏判。你在本地跑 H3-Base 和你把结果送去 API 做 2K，这两段的约束条件是不一样的，做管线设计时得提前想清楚。
别把 megapixels 2.0 那一档当成 2K
这是我认为最值得单独拎出来说的一处误读。
ComfyUI 官方模板里有一个 ResolutionSelector 节点，模板默认 megapixels 0.4、multiple 32，模板内嵌的「Size Settings Reference」表把 megapixels 映射到具体输出尺寸。这张表整表在别的篇目里讲，这里只摘与本篇直接相关的三行（16:9，multiple=32）：
| megapixels | 输出尺寸 |
|---|---|
| 0.98 | 1344 × 768 |
| 1.0 | 1376 × 768 |
| 2.0 | 1920 × 1088 |
看到 2.0 → 1920 × 1088，很容易顺手把它归到「哦，这就是高分辨率那一档」。但这条路和 H3-Regenerate-2K 完全无关：ComfyUI 侧的模板里根本没有 Regenerate-2K 这个节点，它没开源，只有 API。滑动 megapixels 只是在改 H3-Base 这一次生成的目标尺寸，不是在触发那条「重生成」路径。
而且 ComfyUI 的官方教程页给的约束是 768px 短边、上限 768×1344、取整到 32 的倍数，质量参数 Megapixels 推荐 1.0；R2V 模板里的 MiniMaxH3ReferenceToVideo 节点写死的是 width 1344、height 768，正好对应表里 0.98 那一档。把滑块推到远超推荐值（甚至超出教程给的 768×1344 上限）的位置会发生什么，官方教程页没有给说明，我们手上也没有任何依据可以替你下结论——这是需要你在自己机器上判断的部分。判断依据只有一条：教程页写的约束是短边 768、上限 768×1344，凡是超出这两条的档位，都属于官方没有背书的区间。
顺带说一个同样容易混的点：ComfyUI 用的权重来自 Comfy-Org/MiniMax-H3，文件名里带 pruned_int8_convrot / nvfp4_awq，而 MiniMax 官方 README 说自家发布的 checkpoint 是 BF16。这是两套形态不同的权重，评估结果时不要把两边混着看。至于孰优孰劣、量化损失多少——官方两边都没有给对比数据，我们不比。
所以你该怎么决定
把上面几条压成一条判断路径：
- 你必须要 2K 输出 → 目前只有官方 API 这一条路（全球
platform.minimax.io，中国platform.minimaxi.com），本地权重做不到，同时接受输入会过自动审核。 - 你在本地跑开源权重 → 你能拿到的上限就是 H3-Base 这一层，短边默认 768。想要更大的画面，是在调 H3-Base 的生成尺寸，不是在做 2K 重生成，这两件事别在项目文档里写成同一件事。
- 你在写技术方案或对外材料 → 「H3 支持 2K」和「H3 开源版能出 2K」是两句不同的话。这类能力与发布状态的混淆在 H3 上不止一处：模型原生支持稀疏注意力的训练与推理，但首次开源发布只提供 full attention 的推理，稀疏注意力实现要等未来更新——是同一种坑。
- 你想知道什么时候会变 → README 的原话是准备好了就发布，没有给时间点。判断依据只有一个：去看
MiniMax-AI/MiniMax-H3仓库的 README 与 release 说明有没有更新，不要信任何二手的「已经开源了」的说法。
顺便说一句，License 全称是「MiniMax H3 Community License Agreement」，链接在 Hugging Face 仓库里。涉及能否商用、能不能二次分发这类问题，请直接读官方 LICENSE 原文，本文不做任何解读。
延伸阅读
本文依据 MiniMax H3 官方仓库（github.com/MiniMax-AI/MiniMax-H3）的 README、
模型配置文件与官方 h3-prompt-writing skill 文档整理，核对日 2026-08-09。
本文内容为官方仓库口径，未在本机部署或调用过 H3。
文中 ComfyUI 侧的模型文件、节点与尺寸映射信息来自 docs.comfy.org 的官方教程与 Comfy-Org/workflow_templates 仓库的模板文件。
模型、部署方式与许可条款以官方最新说明为准。许可条款请以官方 LICENSE 原文为准，本文不构成法律意见。