H3 开源了什么、没开源什么：三个模块的开放状态逐条拆开
看到「MiniMax H3 开源」这几个字，多数人的第一反应是：权重放出来了，那我把它跑起来，效果就跟官方演示一样。这个推论在 H3 上不成立，而且不成立的原因写在 README 里，不是我们猜的。
H3 不是一个模型，是一个由三个模块串起来的系统。开源的是中间那一个。前面那个负责理解你输入的模块、后面那个负责把结果提到 2K 的模块，截至 2026-08-09 的官方仓库 README，都没有包含在这次开源发布里，只提供 API。
这篇就把这条边界画清楚：哪些拿得到、哪些拿不到、拿不到的部分官方建议你怎么办、以及最后你该走哪条路。
一、先看这张表：三个模块和各自的开放状态
按 github.com/MiniMax-AI/MiniMax-H3 README 的「System Overview」章节，H3 的骨架是这样的：
| 模块 | 职责 | 开源状态（2026-08-09） |
|---|---|---|
| H3-Context-IR | 输入越来越复杂时，用一套专门系统深度理解并精炼多模态指令，转换成 H3 易于理解的 Context Intermediate Representation（上下文中间表示），再交给生成 | 未包含在本次开源发布中；官方提供 API 复现官方工作流行为，并提供教程让开发者按 Prompting Guidance 自建预处理系统 |
| H3-Base | 基于 H3-Context-IR 的输出生成音频与视频，产出 768p 分辨率结果 | 已开源（两个 checkpoint） |
| H3-Regenerate-2K | 把 768p 结果连同原始上下文一起送回 H3，重新生成 2K 分辨率输出 | 尚未开源，README 原文写「Due to the complexity of the system, this module is not yet open-sourced. We will release it once it is ready.」；提供 API 用于验证官方结果 |
这张表怎么读？关键不在三行分别写了什么，而在于它们的顺序。Context-IR 在最前面，它的输出是 H3-Base 的输入；Regenerate-2K 在最后面，它的输入是 H3-Base 的输出。开源的那一层，恰好被两个闭源层夹在中间。
也就是说，你拿到权重之后，前面的输入怎么组织、后面的高分辨率怎么出，这两件事都得你自己解决。这跟「下载一个模型直接推理」的心智模型完全不同，也是 H3 这次发布里最反直觉的一处。
二、Context-IR：官方自己说它对最终质量至关重要
这里必须原样引一句 README，因为它是整个判断的支点：
H3-Context-IR is critical to the quality of the final output, so we strongly recommend incorporating it into your generation pipeline or following the “Prompting Guidance” to build your own context-processing system.
翻成人话：官方明确说这一层对最终输出质量至关重要，并强烈建议你二选一——
- 把它接进你的生成流水线（也就是调官方 API）；
- 或者照官方的 Prompting Guidance，自己搭一套上下文处理系统。
注意这两条建议的性质不一样。第一条是「用官方的」，第二条是「按官方指引自己造」。官方没有给出第三条路，也没有说「不接也行、影响不大」。
由此推出的核心判断，我建议你直接记住：拿到权重不等于拿到官方效果。
这句话不是唱衰，是把责任边界说清楚。你在 WebApp 或官方 API 上看到的产出，走的是完整链路（Context-IR → H3-Base → 可选的 Regenerate-2K）；你在本地跑开源权重，走的是只有中间一段的链路。两条链路的输入形式就不一样，把它们的结果直接摆在一起比较，比的其实不是同一件事。
这也意味着，如果你本地跑出来的东西不理想，第一个该怀疑的不是「权重是不是缩水了」，而是「我喂进去的上下文，是不是根本没经过 Context-IR 该做的那道精炼」。排查方向差很远。
顺带一提，README 明确写了 H3-Base 产出的是 768p，而输入输出规格表里也写着短边默认设为 768 像素、2K 生成需通过 H3-Regenerate-2K 实现。所以「开源版能不能直出 2K」这个问题，答案在官方文档里是闭合的：不能，2K 那一步在没开源的模块里。
三、Regenerate-2K：它不是超分，换掉就不是同一件事
有人会想：2K 那一层没开源没关系，我本地接一个现成的超分模型补上不就行了。
从工程上你当然可以这么干，但要清楚你替换掉的不是同一个东西。README 的说法是：对 2K 输出，H3 不使用传统的专用超分模块，而是让 H3 基础模型以 in-context 的方式重新生成自己的低分辨率结果。官方给了两点理由：一是重生成过程能最大程度复用 H3 基础模型的生成能力；二是 in-context 形式能在产生高分辨率输出时复用原始多模态上下文，从而恢复传统超分方法只能「猜」的信息，例如小字与精细细节。
关键词是「复用原始多模态上下文」。传统超分只看那张低分辨率画面，缺失的细节只能靠先验补；而 Regenerate-2K 手里还握着你最初给的那份上下文。这是机制层面的差别。
我不会给你任何画质对比结论——官方没给评测数据，我们也没有跑过任何一次生成。这里只说清一件事：用外部超分顶替 Regenerate-2K，是换了一套机制，不是复现了官方那一步。 你在技术方案里怎么描述它，别把两者写成等价物。
四、开源的那一层，到底给了多少
把边界的另一半也说清楚：H3-Base 开出来的东西并不吝啬。
README 的 checkpoint 表给了两个：
| Checkpoint | 支持任务 | 输入条件 | 输出 | 精度 |
|---|---|---|---|---|
| MiniMax-H3 Base FL2VA | Text-to-Audio-Video（t2va）、First/Last-Frame-to-Audio-Video（fl2va） | 文本；可选首帧、尾帧或两者 | 视频与音频 | BF16 |
| MiniMax-H3 Base Ref2VA | Reference-to-Audio-Video（ref2va） | 文本 + 参考图像、视频和/或音频 | 视频与音频 | BF16 |
README 另注明，发布的 checkpoint 是 CFG-distilled 的 Omni Transformer 权重。
更值得注意的是架构章节里的一句：H3-Omni-Transformer 是 33B 参数的 dense、单流 Transformer，官方发布完整模型权重以支持包括微调在内的后续开发。这不是只放一份推理用的裁剪版。同一章还提到，约 13B 参数位于 AdaLN 相关分支，由于 AdaLN 调制输出可以预先计算并缓存，这些参数在「仅推理」的部署中不需要加载。
这条我要多加一句警告：它是理解部署形态的重要依据，但不要拿它去换算「所以只需要多少显存」。官方没有给显存数字，我们也没有部署过。想知道跑起来是什么规模，去看 README 里官方给出的部署示例参数，那是唯一有依据的入口。
五、还有第四样没开源的东西：稀疏注意力实现
这一条最容易在二手报道里被写错，所以单独拎出来。
README 的架构章节写：为降低长多模态序列的计算开销，H3 原生支持稀疏注意力的训练与推理；但首次开源发布只提供 full attention 的推理，稀疏注意力实现将在未来更新中发布。
把这两句拆开：
- 「原生支持稀疏注意力」——这是模型能力；
- 「开源版只能跑 full attention」——这是当前发布状态。
两者不能混为一谈。写成「H3 开源版支持稀疏注意力」就是错的。这个区分和前面 Context-IR / Regenerate-2K 的区分是同一类：能力和你现在拿得到的东西，是两码事。 你在评估技术选型、写内部方案时，凡是从架构介绍里读到的能力描述，都要多问一句「这一条随首个开源版发布了吗」。
顺带记一条相关的硬约束：H3-Encoder 使用 Qwen3-VL-32B 的完整预训练权重，并在 tokenizer 配置中新增了若干特殊 token（例如 <d>），README 明确要求使用 H3 时必须用 H3 仓库提供的 tokenizer 与相关配置文件。别想着拿一个普通的 Qwen3-VL tokenizer 顶替——README 把「必须用 H3 仓库提供的 tokenizer 与相关配置文件」写成了要求，而不是建议；特殊 token 对不上会有什么具体表现，官方没有展开，我们也不替它猜。
六、一个容易被忽略的实际差异：安全护栏只在 API 侧
README 的「Safety Guardrails」章节说：用户提交的文本、图像与视频，以及增强后的提示词，都要经过自动审核；疑似违法、色情或侵犯第三方权利的内容可能被拦截。官方同时承认，使用的是行业标准的过滤措施，但无法消除误判（false positives）与漏判（false negatives）。官方还写明，这些护栏不影响被许可方在 MiniMax H3 Community License 下的义务，尤其是与合法使用和使用限制相关的义务。
把这段和第二节接起来看，就得到一个很实际的结论：只要你选择「接入 Context-IR」这条路，你的输入就会走官方 API，也就会过这道审核。 反过来，你选择按 Prompting Guidance 自建预处理、全程不调官方接口，输入就不经过官方那一侧，这道自动审核自然也不在链路里。
这不是「哪条路更好」的问题，而是你做架构决策时必须提前知道的一个差异点：
- 走 API：多一道自动审核。官方自己说了它会有误判和漏判，所以既不能当成「内容一定合规」的保证，也不能忽略它可能拦掉你的正常素材。
- 走自建：这一道不在链路里，合规责任怎么落，得你自己在系统里安排。
无论走哪条，License 相关的义务都不因护栏而改变——这是 README 自己强调的。至于许可条款到底怎么规定，本文不做任何解读：H3 的许可证全称是 MiniMax H3 Community License Agreement，原文在 Hugging Face 仓库 MiniMaxAI/MiniMax-H3 的 LICENSE 文件里，能不能商用、怎么二次分发、产出物权属如何，一律以那份原文为准。
七、所以你该走哪条路
按你的处境往下走，不用把上面全部记住：
如果你的目标是复现官方演示级别的产出，那么开源权重单独用不够，你至少需要接入 H3-Context-IR 的 API；要 2K，还得再接 H3-Regenerate-2K 的 API。README 写明这两个模块提供 API，Regenerate-2K 的 API 用途官方表述为「验证官方结果」。
如果你的目标是本地可控、可微调、不依赖外部服务，那么走开源的 H3-Base 是合理的，官方也确实放了完整权重支持微调。但你要接受两个前提：输出是 768p 这一档，且前置的上下文处理得你自己按 Prompting Guidance 搭。这时候 Prompting Guidance 不是「进阶技巧文档」，而是你链路里缺掉的那一环的施工图，优先级应该排到很前面。
如果你只是想先判断这东西值不值得投入，先别急着下权重。先去读 README 的 System Overview 和 Prompting Guidance，把「我要不要自建 Context-IR」这个问题想清楚——这决定的是工程量，比显卡的事更早需要答案。
最后是一条评估纪律：拿本地开源版的产出，去和官方 WebApp、官方 API 的产出做对比，然后得出「开源版不行」的结论，这个对比本身是不成立的。它们跑的不是同一条链路。要比，先把链路对齐；对不齐，就在结论里如实写明差异，别让读你方案的人误以为是同一回事。
延伸阅读
- H3 的 2K 为什么不是超分：H3-Regenerate-2K 的 in-context 重生成读法
- MiniMax H3 的原生立体声是怎么做出来的：H3-AudioVAE 与音视频联合预测
- ComfyUI 里的 H3 和官方权重不是同一套
本文依据 MiniMax H3 官方仓库（github.com/MiniMax-AI/MiniMax-H3）的 README、模型配置文件与官方 h3-prompt-writing skill 文档整理，核对日 2026-08-09。本文内容为官方仓库口径，未在本机部署或调用过 H3。模型、部署方式与许可条款以官方最新说明为准。许可条款请以官方 LICENSE 原文为准，本文不构成法律意见。