7 月 31 日，中国 AI 公司 MiniMax 发布第三代视频生成模型 H3；8 月 3 日，模型权重在 Hugging Face 上线，ComfyUI 同日提供原生支持。在 Artificial Analysis 的盲评排名中，H3 拿下视频编辑第一名（Elo 1130），文生视频第二（Elo 1240，仅次于 Google Gemini Omni Flash），图生视频第三（Elo 1187）。这是开放权重视频模型首次在任何主流评测维度上登顶。
但本次开源的边界同样值得审视：H3 的核心生成器（H3-Base）以两个任务特定 checkpoint 的形式开放，而负责将多模态指令转化为结构化输入的 Context-IR 预处理系统，以及实现 2K 输出的 In-Context Regeneration 模块，目前仍通过 MiniMax API 提供。
这是一次分层的开放，而非全面开放。它同时给出了开源视频生成的两个信号：技术上，开放权重模型已具备与闭源竞品正面竞争的能力；策略上，前沿模型完全开源的工程难度仍然很高，分层开放正在成为务实的过渡方案。
一个模型取代五个专家：H3 的统一架构
H3 跟前两代 Hailuo 产品线最大的区别在于任务边界被消解了。传统视频模型通常将文生视频、图生视频、首尾帧生成、主体参考、运动参考、视频编辑等拆分为独立专家模型；音频生成中，语音、音效、音乐也各自为政。H3 在预训练阶段就把这些任务统一到一个框架中——所有输入模态（文本、图像、视频、音频）被编码后打包为一个统一的序列，送入同一个 33B 参数的 Omni-Transformer 进行联合预测，输出视频与原生立体声。
这种统一设计依赖三个关键技术选择：
H3-VAE 的高压缩比。 这是 H3 能以经济可行的方式支持原生 2K 的基础。H3-VisualVAE 的空间压缩比为 16×，时间压缩比为 4×，24 个潜在通道。在进入 Transformer 之前，视觉潜在表示还会被进一步 patchify（patch size 1×2×2），使有效空间下采样达到 32×。综合来看，这带来了约 4 倍的有效序列长度增益，大幅降低了训练和推理成本。
H3-Encoder 基于 Qwen3-VL-32B。 MiniMax 没有从头训练视觉语言编码器，而是直接使用了 Qwen3-VL-32B 的完整预训练权重，取其第 50 层的隐藏状态馈入 Omni-Transformer。这一选择既节约了训练资源，也让 H3 从起步就具备了较强的多模态理解能力。
In-Context Regeneration 替代传统超分。 H3 的 2K 输出路径不走常规的"生成低分辨率→外挂超分模块"路线。它让 H3-Base 先生成 768p 的结果，然后将这个结果与原始多模态上下文一起回传给模型，让模型在上下文中重新生成高分辨率版本。这样做的好处是：细节（小文字、品牌标识、精细纹理）可以从原始参考材料中"拉"回来，而不是被独立超分网络凭空猜测。MiniMax 官方称，传统超分方法往往无法恢复这类信息。
开源的与未开源的：三层系统中的两层墙
H3 的完整生产系统由三个模块串联而成：
- H3-Context-IR：接收用户的多模态指令（文本 + 最多 9 张参考图 + 3 段视频 + 3 段音频），解析跨模态关联、时序理解和逻辑推理，输出结构化的 Context Intermediate Representation——这是决定最终生成质量的关键预处理环节。
- H3-Base：基于 Context-IR 的输出生成 768p 视频和立体声音频。这是本次开源的核心部分。
- H3-Regenerate-2K：将 768p 结果与原始上下文再次输入模型，生成 2K 输出。
开源的只有第 2 层——H3-Base 的两个任务 checkpoint（FL2VA 用于首尾帧场景，Ref2VA 用于多模态参考场景），每个 checkpoint 包含 Omni-Transformer、processor、tokenizer、text encoder、Visual VAE 和 Audio VAE 的完整权重。第 1 层和第 3 层均通过闭源 API 提供。
这意味着什么？本地部署 H3-Base 的用户可以得到 768p 的视频和立体声音频，可以进行微调、私有化部署和自定义工作流集成。但要复现官方 2K 产品级质量，仍然需要调用 MiniMax 的 Context-IR API 和 Regenerate-2K API，或者自行构建等效的预处理系统。MiniMax 在 model card 中提供了详细的提示词编写指南，鼓励社区自建 Context-IR——但这不是一件简单的事：官方 Context-IR 处理一段多模态输入可能需要消耗约 100K token 的推理计算，最终压缩为约 4K token 的结构化表示。
此外，H3 架构中设计用于降低长序列计算成本的稀疏注意力机制也未包含在此次开源中——首版仅支持全注意力推理。MiniMax 承诺后续会单独发布。
从 123GB 到 42GB：ComfyUI 如何把 33B 模型塞进 RTX 3060
33B 参数的视频生成模型跑在消费级 GPU 上，这听起来不太可能。ComfyUI 团队做了三件事让它成为现实：
调制权重剪枝。 H3-Omni-Transformer 约 40% 的参数（约 13B）位于 AdaLN（自适应层归一化）分支。这些参数的作用是根据条件信号调制主网络的激活——但其输出可以在推理前预计算并缓存，因此推理时无需加载。ComfyUI 团队将这些调制权重剪枝并替换为功能等效的查找表，在零质量损失的前提下显著缩小了内存占用。
int8 卷积旋转量化。 对剩余权重采用精确且高效的 int8 量化，进一步压缩内存。
动态 VRAM 卸载。 推理过程中将非活跃组件在 GPU 和系统内存之间动态迁移。
三项措施叠加，将全精度 123.6 GB 的内存占用降至 42.5 GB，削减 66%。配合动态 VRAM 卸载，用户可以在 RTX 3060（12 GB VRAM）上本地运行 H3-Base 的 768p 生成。
值得注意的是，这仅覆盖 H3-Base。2K 输出需要额外调用 Regenerate-2K API，不能在本地完成。
定价与竞争：领跑者的价格标签
在 Artificial Analysis 的排名中，H3 的竞争位置如下：
| 任务 | H3 排名 | H3 Elo | 领先模型 |
|---|---|---|---|
| 视频编辑（含音频） | #1 | 1130 | — |
| 文生视频（含音频） | #2 | 1240 | Gemini Omni Flash (1244) |
| 图生视频（含音频） | #3 | 1187 | Seedance 2.0 (1196), Gemini Omni Flash (1193) |
H3 的 API 定价为 $7.80/分钟（2K 输出，含音频），在同类产品中处于中位：比 Gemini Omni Flash 的 $6.00/分钟略高，但远低于 Seedance 2.0 1080p 的 $22.45/分钟、Kling 3.0 1080p 的 $20.16/分钟，以及 HappyHorse-1.1 的 $9.90/分钟。
MiniMax 官方称，H3 在 2K 分辨率下的每秒价格不到主流模型的三分之一，在 768p 下不到主流模型 720p 价格的一半。这一说法在与 Seedance 和 Kling 的对比中基本成立，但需要注意 Gemini Omni Flash 在更低价格下提供了相近甚至略优的 T2V 和 I2V 表现。
与同日发布的字节跳动 Seedance 2.5 相比，两者选择了截然不同的路线：Seedance 2.5 保持闭源，单次可生成 30 秒视频（H3 为 15 秒），但 H3 以开放权重和更低价格作为差异化策略。
许可证：两千万美元的商用红线
H3 的权重采用 MiniMax H3 Community License 发布。核心条款：免费非商业使用；年收入低于 2000 万美元的组织可免费商用，需显著署名；年收入超过 2000 万美元的组织需与 MiniMax 单独协商商业授权。
这与 MiniMax 此前 M 系列语言模型采用的 MIT 许可证不同（后者在 M2.7 时已转向更严格的社区许可证）。对于大多数独立开发者和中小型工作室，2000 万美元的收入上限不会构成障碍；但对大型企业和平台而言，自建 H3 部署的商业成本需要单独谈判。
开源视频进入正面竞争
H3 之前，开放权重视频模型的性能明显落后于闭源产品。上一个标杆 LTX-2.3 从未在任何主流评测中接近榜首。H3 在视频编辑维度登顶，在 T2V 和 I2V 维度进入前三，标志着一道门槛被跨过。
但完全开放的工程成本仍然很高。H3 的分层开放——Base 开源 + 预处理和超分闭源——反映了前沿视频模型的一个现实：生成器本身可以开放，但高质量的多模态指令理解和 2K 再生涉及复杂的多阶段工作流和多种托管模型，打包成可部署的开源组件并非易事。MiniMax 的选择是务实的：用开放 Base 降低自托管、微调和社区适配的门槛，同时用闭源组件保护端到端产品体验和商业护城河。
方向是明确的：MiniMax 在官方博文中宣布后续 H 系列将整合其 M 系列语言模型的能力，并继续推进 scaling 和高分辨率。ComfyUI 团队在 day-0 的深度适配则证明，开源生态对降低前沿模型硬件门槛的杠杆效应不可替代。接下来最值得观察的变量是：MiniMax 是否以及何时开源剩余的 Context-IR 和 Regenerate-2K 模块，以及社区能否在缺少这两个组件的情况下构建出有竞争力的替代方案。