MiniMax H3：真正的全模态，不是能上传素材，而是读懂素材之间的关系

现在打开一款AI视频工具，通常会看到一整排功能入口：

文生视频、图生视频、首尾帧、动作参考、人物参考、口型同步、视频编辑、声音生成……

功能看起来越来越丰富，使用过程却不一定更简单。

创作者必须先理解每个功能的边界，再把一个完整需求拆成若干小任务：人物交给一个模型，动作交给另一个模型，声音单独生成，最后再用剪辑工具组装。

表面上是人在使用AI，实际上很多时候，是人在迁就模型的能力边界。

MiniMax H3真正想改变的，正是这套工作方式。

它最高支持15秒、2K分辨率和原生双声道音视频，但这些只是比较容易传播的表层参数。更深层的变化在于，H3不再把图片、视频、声音和编辑当成互不相关的功能，而是试图让一个模型统一理解所有素材与任务。目前pixpix官网已经完成首发接入，支持视频生成和编辑。

过去的生成模型，为什么需要这么多入口？

上一代生成模型大多按照单项任务训练。

图片领域被拆成：

文生图；

图片编辑；

主体参考；

姿势参考；

风格迁移。

视频领域又被拆成：

文生视频；

图生视频；

首尾帧生成；

人物一致性；

动作迁移；

视频局部编辑；

音色与口型参考。

声音生成同样被分成人声、音乐和音效。

这种专用模型的好处是目标明确，某一项能力容易快速优化；缺点则是不同模型之间很难自然协同。

例如，用户想让一张图片中的人物唱歌，同时参考另一段视频的镜头运动，再使用第三段音频中的声音。

这其实是一个完整的创作需求，但传统工具通常要求用户把它拆成多个步骤，依次处理人物、动作、镜头、声音和画面合成。

H3的目标，是让用户直接用自然语言说明素材之间的关系：

图片提供人物；

视频提供镜头与动作；

音频提供声音；

最终输出一段人物唱歌的新视频。

用户负责描述创作意图，模型负责理解任务结构。

“全模态”不是素材更多，而是模型能读懂关系

很多产品也支持同时上传图片、视频和音频，但支持上传，不等于真正理解。

模型需要分清楚每份素材的用途。

同一张图片可能是人物参考，也可能只是风格参考；一段视频可能用于复制动作，也可能只参考运镜；一段音频既可能提供人声，也可能只提取节奏和环境音。

H3将这种能力称为Contextual Omni Representation，可以理解为“上下文中的全模态关系表达”。

传统视频标注主要告诉模型画面里出现了什么，例如“一个人在雨夜走进便利店”。

H3需要的标注则更复杂：

哪个素材是最终生成目标；

哪些素材负责提供参考；

需要保留哪些人物与物体；

哪些动作、声音或风格需要迁移；

不同镜头中的音频和画面如何对应。

据官方介绍，H3为此搭建了专门的多模态理解流程。部分训练素材会先消耗约10万Token进行分析，再整理成平均约4000 Token的详细关系描述。

这意味着H3训练的重点，不只是识别一段视频中有什么，还包括理解用户为什么提供这些素材。

语言正在变成创作任务的“操作系统”

H3的核心判断是：自然语言不应该只是描述画面，还应该负责组织整个创作任务。

过去写视频提示词，通常是：

雨夜，一名年轻人走进便利店，电影感，镜头缓慢推进。

这种提示词主要描述最终画面。

H3想要理解的指令更接近：

保留视频中的人物与背景，将人物手中的饮料换成图片里的产品；镜头运动参考另一段视频；声音改成英文，同时增加字幕，但不要遮挡人物和商品。

这里不仅有画面描述，还包含素材分工、保留条件、修改范围和输出要求。

从这个角度看，提示词正在从“画面关键词”变成真正的创作指令。

创作者需要表达的不再只是画面长什么样，还包括：

参考什么；

保留什么；

修改什么；

不允许改变什么；

不同素材之间如何组合。

如果模型能够稳定理解这种任务，未来的生成工具可能不再需要几十个功能入口。用户上传素材、说明目标，模型自行判断需要执行图片编辑、动作迁移、音频替换还是高分辨率重构。

H3训练的不是单项能力，而是一组可组合任务

为了实现任务统一，H3在预训练阶段就混合了多种数据和能力。

其中包括：

文生图；

文生视频；

文生音频；

图片到图片的参考与编辑；

图片到视频的参考与编辑；

音频到音频的参考与编辑；

音视频到音视频的参考与编辑；

多镜头音视频联合生成。

在人声、音乐和音效之间，H3也没有设置完全独立的边界，而是将其作为统一音频信息进行建模，输出采用原生双声道。

这种训练方式押注的是“能力组合”。

模型不一定要为每一个新需求重新增加专用模块，而是通过语言理解任务，再调用预训练中已经学到的图片、视频和声音能力完成组合。

MiniMax为什么放弃Hailuo 02的原有优势？

H3研发过程中，一个值得注意的决定，是MiniMax没有继续沿用Hailuo 02的原有架构。

Hailuo 02的部分架构设计曾经带来明显的效率优势，但当模型需要同时处理图片、视频、声音、理解和生成时，这些针对特定任务的设计反而可能增加系统复杂度。

MiniMax最终选择让架构服从任务泛化。

换句话说，团队愿意放弃部分已经验证过的短期优势，换取未来继续扩展新任务的空间。

这个决定反映出其对视频模型发展方向的判断：

未来最重要的能力，可能不是把文生视频单独做到极致，而是让模型处理越来越完整、越来越混合的创作需求。

H3-VAE：为什么2K价格能够降下来？

高分辨率视频非常消耗算力。

视频包含大量连续画面，分辨率和时长稍微增加，模型需要处理的数据量就会快速上升。

H3重新设计了视觉信息的压缩与还原方式。根据官方公布的数据，H3-VAE带来了约4倍的序列长度收益。

可以把它理解为：同样一段视频经过重新压缩后，模型需要处理的信息变得更紧凑了。

这项优化降低了训练和推理成本，也是H3能够默认提供2K分辨率，并把每秒价格压到主流模型较低区间的重要技术基础。

H3-Omni Transformer：同时处理不同重量的任务

图片、音频和视频占用的计算资源并不相同。

一张图片可能只包含一个画面，一段视频则包含大量连续帧；理解参考素材与生成最终视频，所需要的计算量也存在明显差异。

多模态上下文加入后，H3不同样本之间的序列长度差异扩大了约3倍。

如果继续使用完全统一的计算方式，很容易出现部分硬件等待、部分硬件过载的问题。

H3因此采用了理解与生成异构的训练架构，根据不同任务调配计算资源，并在样本之间进行负载均衡。官方数据显示，这套方案让端到端训练吞吐提升了接近30%。

它解决的不是某一个画面效果，而是模型在面对复杂输入时如何更高效地运行。

In-context Regeneration：2K不是简单放大

很多视频模型生成高分辨率内容时，会先得到低清视频，再交给独立超分模型放大。

问题是，传统超分模型通常看不到原始提示词和参考素材。面对模糊文字、产品包装和复杂纹理，它只能根据低清画面推测细节。

所以画面虽然变清晰了，文字却可能写错，商品结构也可能被“修复”成另一种样子。

H3采用的是In-context Regeneration。

它会让H3基础模型重新读取低分辨率结果、原始指令和多模态参考素材，再生成一遍高分辨率版本。

假如画面中的包装小字已经模糊，模型不仅能看到低清画面，还能重新读取用户上传的产品图，因此比传统超分更有机会还原正确内容。

这不是单纯提高像素，而是带着原始上下文重新生成细节。

H3可能改变的，是视频工具的使用方式

H3目前最高只能生成15秒内容，部分画面精度、多模态理解和复杂任务的稳定性也仍需提高。

任务统一同样会带来新问题。

输入素材越多，素材之间的关系就越复杂。模型一旦理解错某个参考对象的用途，最终结果可能整体偏离。自然语言虽然比固定功能更加自由，但也对指令理解和执行稳定性提出了更高要求。

所以H3还没有证明所有专用工具都会消失。

但它给出了一条比较清晰的路线：

过去是一个入口对应一个功能；未来可能是一句话对应一个完整任务。

真正值得关注的，不是H3比上一代多生成了几秒，也不是2K画质又提高了多少，而是视频模型开始从“执行单项操作”，转向“理解完整创作意图”。

当模型能够自己判断每份素材的作用，并在图片、视频、声音和编辑之间自由组合时，它才有机会从一个视频生成器，变成真正参与内容生产的多模态创作系统。