MiniMax H3 是什么：一个全模态生成系统
第一次翻 MiniMax H3 的仓库，最容易犯的错是把它当成”又一个文生视频模型”。它不是。README 里对自己的定位写得很直接：一个通用、全模态的生成系统（general-purpose, omni-modal generative system）。注意”系统”这两个字——它由三个模块拼起来，而这次开源的只有中间那一块。这个事实决定了你后面所有的技术选型，所以我把它放在最前面讲。
本文全部依据 github.com/MiniMax-AI/MiniMax-H3 仓库 2026-08-09 的快照。我们没有下载权重，没有部署，也没有发起过任何一次推理请求，所以你在下面看不到任何显存数字、速度、画质评价——那些官方没给，我们也没有。
一、先看仓库现状：它还很新
| 项 | 值（2026-08-09 仓库首页） |
|---|---|
| 仓库 | github.com/MiniMax-AI/MiniMax-H3 |
| Star 数 | 2.4k |
| 提交数 | 27 Commits |
| 许可证 | MiniMax H3 Community License Agreement |
| 权重托管 | Hugging Face MiniMaxAI/MiniMax-H3；另有 ModelScope 组织页 modelscope.cn/organization/minimax |
| README 语言 | 英文、简体中文、韩文、日文四版 |
| 联系方式 | model@minimax.io |
2.4k star 配 27 个 commit，这个组合本身就是信息量。star 说明关注度已经起来了，27 个 commit 说明仓库刚开出来不久、代码还在早期形态。判断依据在这里：一个只有二十几次提交的仓库，你不应该按”稳定发行版”的预期去规划工期，README 里今天写的路径、脚本名、默认值，下个月可能就变了。任何基于它的结论都要带日期。
许可证这一项我只能给你名字：MiniMax H3 Community License Agreement，原文在 huggingface.co/MiniMaxAI/MiniMax-H3/blob/main/LICENSE。我们没有读过 LICENSE 正文，所以关于能不能商用、二次分发要满足什么条件、生成物的权属归谁，本文一个字都不解读，请以官方 LICENSE 原文为准。这不是谨慎过头——License 名字里带 “Community” 的模型，条款差异往往很大，靠类比 Apache 或 MIT 来猜是要出事的。
二、系统定位：它想解决的是”多模态上下文”
README 的 System Overview 一节说，H3 支持对由文本、图像、视频、音频构成的多模态上下文做统一理解，并能生成带原生立体声音频的视频，分辨率最高 2K，时长最长 15 秒。官方给的解释是：得益于面向任务泛化的系统设计，H3 在预训练阶段就具备了广泛的多模态上下文理解与生成能力，因而在遵循复杂多模态指令上表现出色。
“原生立体声”和”统一理解”都是官方原话，可以引用。但 README 没有给任何跑分、也没有和其它模型的对比数据，所以”表现出色”到什么程度、和别家比如何，这里没有答案，我也不打算替它编一个。
真正有用的是”统一”这两个字背后的工程含义：音频不是后期配上去的，视频和音频在同一个生成过程里出来。这决定了你不能用”先出画面、再找配音”的老流程去套它，参考输入里的音频也会和图像、视频一起进上下文——第七节会看到这条约束的具体形态。
本节延伸：H3 开源了什么、没开源什么：三个模块的开放状态逐条拆开、稀疏注意力：能力与发布状态是两回事。
三、输入输出规格表：这张表要背下来
这是 README 的原表，是你做任何方案设计前的硬边界：
| 类别 | 规格 |
|---|---|
| 输出时长 | 4–15 秒 |
| 输出宽高比 | 支持较宽范围，包括但不限于 21:9、16:9、4:3、1:1、3:4、9:16 |
| 输出分辨率 | 支持多种分辨率；短边默认设为 768 像素；2K 生成需通过 H3-Regenerate-2K 实现 |
| 输出帧率 | 24 FPS |
| 输出音频 | 32 kHz 立体声 |
| 支持的对白语言 | 稳定支持 11 种：阿拉伯语、中文、英语、法语、德语、意大利语、日语、韩语、葡萄牙语、俄语、西班牙语。其它语言也有不同程度的支持 |
这张表怎么读，有三处容易看漏：
第一，下限是 4 秒，不是 0 秒。 想做 2 秒的短闪切、或者一段 1 秒的过场，单次生成给不了，得靠后期剪。上限 15 秒也意味着任何”一镜到底一分钟”的想法在这个模型上不成立，长片只能是多段拼接。
第二，短边默认 768，2K 不在同一条路径上。 表里写得很克制——“2K 生成需通过 H3-Regenerate-2K 实现”。这句话不是说”把某个参数调大就行”，而是说 2K 走的是另一个模块。这个模块的开源状态见下一节，先记住这个伏笔。
第三，宽高比那一行写的是”包括但不限于”。 官方列了六种常见比例，没有说这是全集，也没说超出会怎样。要用冷门比例（比如户外大屏那种超宽），README 给不了保证。
帧率 24 FPS 和音频 32 kHz 立体声是固定值，表里没有给可调的说法。11 种稳定支持的对白语言是白名单式表述，“其它语言也有不同程度的支持”这半句是官方留的余地，不是承诺。
本节延伸：MiniMax H3 的原生立体声是怎么做出来的：H3-AudioVAE 与音视频联合预测、H3 的 2K 为什么不是超分：H3-Regenerate-2K 的 in-context 重生成读法。
四、三个模块：本文最关键的一节
H3 由三个模块组成，开源状态各不相同。这是理解整个项目的骨架：
| 模块 | 职责 | 开源状态 |
|---|---|---|
| H3-Context-IR | 输入越来越复杂时，用一套专门系统深度理解并精炼输入的多模态指令，转换成 H3 易于理解的形式——Context Intermediate Representation（上下文中间表示），再交给生成 | 未包含在本次开源发布中；官方提供 API 复现官方工作流行为，并提供教程让开发者按 Prompting Guidance 自建预处理系统 |
| H3-Base | 基于 H3-Context-IR 的输出生成音频与视频，产出 768p 分辨率结果 | 已开源（两个 checkpoint） |
| H3-Regenerate-2K | 把 768p 结果连同原始上下文一起送回 H3，重新生成 2K 分辨率输出 | 尚未开源。README 写：这一模块因系统复杂度原因暂未开源，会在就绪后发布；同时提供 API 用于验证官方结果 |
把这张表和上一节的规格表对起来看，一个反直觉的结论就浮出来了：拿到开源权重 ≠ 拿到官方效果。
开源的是三明治的中间层。前面负责”读懂你到底想要什么”的 H3-Context-IR 没开源，后面负责”把 768p 变成 2K”的 H3-Regenerate-2K 也没开源。你在 Hugging Face 上下载到的 H3-Base，输入端要自己想办法喂对格式，输出端封顶 768p。
README 对 Context-IR 还有一句很重的强调，原文大意是：H3-Context-IR 对最终输出的质量至关重要，因此强烈建议把它纳入你的生成流程，或者遵循 Prompting Guidance 自建上下文处理系统。
这句话是判断依据，不是客套。 官方自己说这一层”critical to the quality of the final output”，那么当你本地跑 H3-Base 觉得结果不对劲时，第一嫌疑人不该是权重，而该是”我给的输入没有经过 Context-IR 这一层的加工”。对应的下一步动作也很清楚，二选一：要么接官方 API 让 Context-IR 帮你处理，要么老老实实按 Prompting Guidance 自己搭一套预处理。跳过这一层直接甩原始提示词进 H3-Base，然后拿结果去和官方 demo 比，这个比法从一开始就不成立。
顺带说一句边界：Context-IR 走官方 API，意味着你的输入会进入官方链路。README 的 Safety Guardrails 一节写明，用户提交的文本、图像与视频，以及增强后的提示词都要经过自动审核，疑似违法、色情或侵犯第三方权利的内容可能被拦截；官方也坦承使用的是行业标准的过滤措施，无法消除误判与漏判。这些护栏不影响被许可方在 MiniMax H3 Community License 下的义务。所以”走 API 还是本地”这个决策，除了效果和成本，还有一条是内容审核路径的差异。
本节延伸：H3 开源了什么、没开源什么：三个模块的开放状态逐条拆开、用官方 API 还是本地部署 H3：按你的实际处境倒推、33B Omni-Transformer 的结构：MiniMax H3 里那 13B 参数为什么推理时不用加载。
五、两个 checkpoint 对应什么任务
H3-Base 开源了两个 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 权重。
选哪个，判断依据其实只有一句：你手里的参考素材是”关键帧”还是”素材库”。
如果你要控制的是”片子从哪一帧开始、到哪一帧结束”，那是 FL2VA。如果你要控制的是”里面出现的这个人长这样、场景是这个风格、语气参考这段音频”，那是 Ref2VA。两者不是能力强弱关系，是控制维度不同。
本节延伸：本地部署 H3-Base 的完整路径：从下载范围到 SGLang 起服务、下载 MiniMax H3 权重时别下重了：--include 到底在挡什么。
六、FL2VA 的三种模式：0 张图、1 张图、2 张图
FL2VA 支持 0、1 或 2 张输入图像，模式随图像数量切换：
- 无图像输入 → 文生视频模式
- 1 张图像 → 首帧生视频，或尾帧生视频
- 2 张图像 → 首尾帧生视频
这个设计挺省事的：不用切模型、不用换任务名，给几张图就是哪个模式。但有一个地方值得留意——1 张图有两种解释：它可以是首帧，也可以是尾帧。README 在这张表里把两种都列了出来，说明这是模式而不是歧义，具体怎么告诉系统”我这张图是首还是尾”，属于调用参数层面的问题，本文不猜，请查官方推理文档。
2 张图的首尾帧模式，从控制维度上看是给定条件最多的一档：起点和终点这两帧都由你指定，剩下的部分交给模型。README 只说明了”2 张图像 → 首尾帧生视频”这个映射关系，中间过程怎么生成没有展开，本文也不替它补。而 0 张图的纯文生视频，控制全靠文本——这时候前面说的 Context-IR 那一层价值就更突出，因为唯一的输入通道就是文字。
本节延伸：H3 提示词的三个核心字段：对齐指令、字段顺序与 Ref2VA 的分工、十二种运镜怎么写进 MiniMax H3 提示词：Zoom 与 Push 到底差在哪。
七、Ref2VA 的输入限制：一组必须原样记住的硬数字
Ref2VA 支持多模态参考输入，README 给的限制是硬性的，不能四舍五入：
- 图像：≤ 9 张
- 视频：≤ 3 段；每段必须 2–15 秒；总时长 ≤ 15 秒
- 音频：≤ 3 段；音频必须伴随图像或视频输入，不能作为唯一输入；每段 2–15 秒；总时长 ≤ 15 秒
- 混合输入：所有输入类型加起来最多 12 个文件
这几条里有三个坑，我按容易踩的顺序排：
坑一：12 这个总数会先于单项上限卡住你。 单看各项，9 + 3 + 3 = 15，但总数封顶 12。也就是说你不可能同时用满图像、视频、音频三项。想放 9 张图，剩下只能再给 3 个文件——视频和音频加起来 3 个，不是各 3 个。做素材配比的时候，先算总数，再分配各类。
坑二：音频不能单独作为输入。 这条很容易在做”手里先有一段音频，想让画面跟着它走”这类需求时撞上。按 README 的限制，光给音频是不行的，必须同时有图像或视频。README 只给了这条限制本身，没有解释原因；从任务名 Reference-to-Audio-Video 来看，音频在这里是被当作”参考”之一列出的，但这只是我们对表述的读法，官方没有展开说明。
坑三：视频和音频每段都有 2 秒下限。 不只是上限 15 秒，下限 2 秒同样是硬的，裁出来的 1.5 秒片段不满足条件。总时长 ≤ 15 秒这一条则和输出时长上限对齐。
自查动作：准备 Ref2VA 输入前，按这个顺序过一遍——文件总数是不是 ≤ 12；有没有音频却没有任何图像或视频；每一段视频和音频是不是都落在 2–15 秒之间；视频总时长、音频总时长是不是各自 ≤ 15 秒。四项全过再提交。README 没有说不满足限制时系统会怎么反应，所以这里不预测报错形态，只建议在送进去之前先按这四项对一遍素材清单。
本节延伸：Ref2VA 的参考标签体系：
八、在线入口：不想折腾部署就走这里
README 列了官方的在线通道，全球与中国大陆分开：
- API：全球
platform.minimax.io，中国platform.minimaxi.com，文档路径/docs/api-reference/video-generation-v2-create - WebApp：全球
hailuoai.video（/tools/minimax-h3），中国hailuoai.com - 桌面版：全球
hub.minimax.io，中国hub.minimaxi.com - 社区：Discord
discord.com/invite/dbMxutw7tP；微信联系入口在platform.minimaxi.com/docs/faq/contact-us
价格、免费额度、速率限制这些我们手上一个数字都没有，也不做任何”贵不贵、够不够用”的判断，请直接看官方平台页。
关于”跑得动吗”这类问题，同样没有可引用的硬件数据。官方部署示例里，SGLang 那一路是官方示例使用 4 GPU 配置——这是示例的写法，不等于”必须四张卡”，也不能倒推显存需求，以官方部署文档为准。
另外提醒一句：模型”原生支持”某项能力，和”首个开源版本是否提供了对应的推理路径”是两回事，不要把前者直接读成后者。这类”能力”与”发布状态”的错位在 H3 上出现了不止一次——Context-IR、Regenerate-2K 都是同一类情况。
本节延伸：用官方 API 还是本地部署 H3：按你的实际处境倒推、H3 的许可与合规边界怎么看：先分清「我们知道什么」和「必须去读原文的部分」。
九、一张地图：你现在应该往哪走
把上面所有信息压成一条决策路径：
- 只想看效果、验证想法 → 走 WebApp 或桌面版，跳过所有部署问题。
- 要接进自己的产品、且需要官方级质量（含 2K） → 走官方 API。因为 Context-IR 和 Regenerate-2K 都只有 API 这一条路。
- 要本地/私有化部署 → 你能拿到的是 H3-Base 的两个 checkpoint，768p，BF16，前置的上下文处理要按 Prompting Guidance 自建。别拿这条路的产出去和官方 demo 做效果对比，链路不一样。
- 只是想搞清楚素材能不能满足输入要求 → 回到第六、七节，对着 FL2VA 的 0/1/2 张图和 Ref2VA 的 9/3/3/12 那组数字自查。
许可、定价、硬件门槛这三件事，请分别去看 Hugging Face 上的 LICENSE 原文、官方平台页和官方部署文档，仓库 README 回答不了它们。
专题全部内容
系统与架构
- H3 开源了什么、没开源什么：三个模块的开放状态逐条拆开
- 33B Omni-Transformer 的结构：MiniMax H3 里那 13B 参数为什么推理时不用加载
- H3-VisualVAE：f16t4d24 是什么意思
- MiniMax H3 的原生立体声是怎么做出来的：H3-AudioVAE 与音视频联合预测
- 为什么必须用 MiniMax H3 自带的 tokenizer：从 H3-Encoder 的接口说起
- 稀疏注意力：能力与发布状态是两回事
- H3 的 2K 为什么不是超分：H3-Regenerate-2K 的 in-context 重生成读法
本地部署
- 本地部署 H3-Base 的完整路径：从下载范围到 SGLang 起服务
- 下载 MiniMax H3 权重时别下重了：
--include到底在挡什么 - 用 SGLang 起 H3 服务：两条官方命令怎么抄、怎么验收
- 用 diffusers 跑 MiniMax H3 的第一个坑：
pip install diffusers装到的版本可能没有 H3 模型类 - MiniMax H3 的 Full 2K Workflow：本地 SGLang 服务 + 官方 API 怎么串成一条链
提示词写法
- H3 提示词的三个核心字段：对齐指令、字段顺序与 Ref2VA 的分工
- 十二种运镜怎么写进 MiniMax H3 提示词：Zoom 与 Push 到底差在哪
- MiniMax H3 提示词里的
<d>标记、说话人 ID 与旁白怎么写 - Ref2VA 的参考标签体系：
/ /
在 ComfyUI 里跑
- 在 ComfyUI 里跑 MiniMax H3：版本门槛、模型放置与 R2V 模板节点链拆解
- MiniMax H3 的五个模型文件分别放哪：ComfyUI 侧的下载来源、目录对应与验收方法
- ComfyUI 里 H3 的分辨率与帧数是怎么定的
- 音视频联合 latent 是怎么解码成一个 MP4 的
- ComfyUI 里的 H3 和官方权重不是同一套
选型与合规
- SGLang / vLLM / diffusers / ComfyUI：H3 四种跑法怎么选
- 用官方 API 还是本地部署 H3：按你的实际处境倒推
- H3 的许可与合规边界怎么看：先分清「我们知道什么」和「必须去读原文的部分」
本文依据 MiniMax H3 官方仓库（github.com/MiniMax-AI/MiniMax-H3）的 README、
模型配置文件与官方 h3-prompt-writing skill 文档整理，核对日 2026-08-09。
本文内容为官方仓库口径，未在本机部署或调用过 H3。
模型、部署方式与许可条款以官方最新说明为准。
许可条款请以官方 LICENSE 原文为准，本文不构成法律意见。