引言:两条路,同一个目的地
2026 年夏天的视频生成领域,有两颗重磅炸弹值得放在一起看。
第一颗是 MiniMax H3——7 月 31 日,MiniMax 正式发布,定位是”通用的全模态生成模型”,号称能统一处理文本、图像、视频、音频,最高支持 15 秒 2K 分辨率。
第二颗是 Wan2.1——2025 年 2 月开源,由阿里通义万相团队推出,是当时首个能在消费级显卡上跑的文生视频模型,T2V-1.3B 只需 8.19GB 显存。
它们几乎同时期出现,却走了一条截然不同的路。这篇文章就是要把它们摆在一起,认真看看。
一、MiniMax H3:全模态大一统的野心
1.1 是什么
MiniMax H3 的官方定位是 “打破任务和模态的边界”。这不是一句 marketing slogan,而是贯穿整个模型设计的第一纲领。
来看看它的官方定义:
MiniMax H3 是一款通用的全模态生成模型,支持对文本、图像、视频、声音组成的多模态上下文的统一理解能力,能够输出具备原生双声道的音视频,最高可支持 15s 2K 分辨率。
几个关键词值得注意:
- 全模态:不是单一视频生成,而是文、图、视频、音频统一建模
- 原生双声道:音频和视频从训练阶段就是一起生成的,不是后期拼接
- 15s 2K:默认就是 2K 分辨率,不是靠后期超分
- 多模态上下文:可以同时输入视频、图片、音频作为参考,让模型理解它们之间的关系
1.2 它到底能做什么
H3 的能力清单比想象中大得多:
| 能力类别 | 具体任务 |
|---|---|
| 纯生成 | 文生图、文生视频、文生音频(人声/音效/音乐不区分) |
| 参考生成 | 图→图参考编辑、图→视频参考、音频→音频参考、音视频→音视频参考 |
| 多镜头 | 原生多镜头建模 |
| 复杂指令 | “参考视频1的镜头运动,让图2的人物唱歌,歌声参考音频3” |
这个”复杂指令”的例子非常关键。传统视频模型通常只能做一个任务——文生视频或图生视频。H3 试图用一个模型覆盖所有”参考+生成”的组合,用自然语言描述它们之间的关系。
1.3 核心技术栈
H3 的技术论文还没发(官方说后续会有 Tech Report),但从博客里能提取出四个关键技术:
(1)Contextual Omni Representation
这是 H3 最底层的创新。传统视频模型只需要描述”这个视频是什么样”。H3 需要描述的是:上下文(输入的多模态素材)和目标视频之间的关系,以及上下文内部元素之间的关系。
实现方式:定制专门的模型对素材做全模态理解,每个素材消耗约 10 万 Token 推理,最终压缩到平均约 4000 Token。这是一个巨大的标注成本。
(2)H3-VAE
Tokenizer 技术的彻底革新。相比 Hailuo-02 架构,H3-VAE 在重建质量和易学性上全面提升,压缩率带来 4 倍的序列长度收益——这意味着同样算力下可以训练更高分辨率的内容。这是支持原生 2K 的关键。
(3)H3-Omni Transformer
一个”异构”训练架构。由于多模态上下文引入,序列长度方差扩大了 3 倍,理解和生成部分的计算 workload 也显著异质化。H3 采用了理解与生成异构的训练架构,端到端提升了约 30% 的训练吞吐。
值得注意的是,MiniMax 明确说:抛弃了 Hailuo-02 的架构,因为它在以任务泛化为核心的定义中会带来额外复杂性。架构技巧让路给模型定义——这个决策的勇气不小。
(4)In-context Regeneration
H3 的 2K 输出不是靠超分模块,而是让基模型对自己的低分辨率结果做 in-context 的重新生成。好处是:可以复用基模型的生成能力,还能利用原有上下文信息还原超分”猜”不出来的细节(比如小文字)。
1.4 商业策略
- 默认 2K 分辨率,每秒价格不到主流模型的 1/3
- 768P 分辨率下是主流模型 720P 的 1/2
- 计划开源权重(合规前提下)
- 设计初期就考虑了国产芯片兼容
- 定位:广告、品牌、电商、产品设计、UI/UX、游戏
二、Wan2.1:开源亲民的另一种哲学
2.1 是什么
Wan2.1 是阿里通义万相团队在 2025 年 2 月开源的视频基础模型套件。它不是某个单一模型,而是一系列模型:
| 模型 | 参数 | 显存需求 | 生成能力 |
|---|---|---|---|
| Wan2.1-T2V-1.3B | 1.3B | 8.19GB | 480P 文生视频 |
| Wan2.1-T2V-14B | 14B | 需要 A100/H100 | 480P + 720P 文生视频 |
| Wan2.1-I2V-1.3B | 1.3B | 低显存 | 480P 图生视频 |
| Wan2.1-I2V-14B | 14B | 高显存 | 720P 图生视频 |
关键数据:T2V-1.3B 在 RTX 4090 上生成 5 秒 480P 视频约需 4 分钟(未量化)。
2.2 核心特色
Wan2.1 的五大卖点:
- SOTA 性能:声称在多基准测试中持续超越现有开源模型和部分商用模型
- 消费级 GPU 支持:1.3B 模型只需 8.19GB VRAM——这意味着 RTX 3060 12GB 也能跑
- 多任务:文生视频、图生视频、视频编辑、文生图、视频转音频
- 视觉文字生成:首个能生成中文和英文文字的视频模型——这是一个实际应用的巨大突破
- Wan-VAE:能编码解码任意长度 1080P 视频,保留时间信息
2.3 开源生态
Wan2.1 是 Apache 2.0 协议完全开源的,这意味着:
- 权重完全开放,可以商用
- HuggingFace 上有完整的模型权重和推理代码
- Diffusers 库已集成
- 社区已有大量微调、部署、优化方案
截至本文写作时,Wan2.1 的 HuggingFace 仓库已有 12.3k followers,T2V-14B 获得 1.54k likes。
2.4 局限
Wan2.1 也不是完美的:
- 最高分辨率 1080P(VAE 层面),实际生成是 480P/720P
- 不支持原生音频生成(只有 Video-to-Audio 这个附属能力)
- 多模态上下文能力有限——主要是文/图作为输入
- 14B 模型对显存要求高,不适合个人开发者
- 2025 年 2 月发布后迭代速度放缓(Wan 官方已更新到 3.0,但 2.1 仍是社区主力)
三、深度对比:四个维度的正面交锋
3.1 架构理念对比
1 | Wan2.1 的思路: |
这是两种截然不同的设计哲学。Wan2.1 是”把一件事做到极致并开放”,H3 是”把所有事融成一个系统”。
3.2 能力矩阵对比
| 维度 | MiniMax H3 | Wan2.1 |
|---|---|---|
| 最高分辨率 | 2K(默认) | 1080P(VAE),720P(生成) |
| 最大时长 | 15s | 约 5s(1.3B),更长需 14B |
| 原生音频 | ✅ 原生双声道 | ❌ 仅 Video-to-Audio |
| 多模态输入 | ✅ 视频+图+音频+文本 | ⚠️ 主要是文本+图片 |
| 中文文字生成 | 未明确提及 | ✅ 首个支持中英文字生成 |
| 图→视频参考 | ✅ 广义参考编辑 | ✅ I2V 专用模型 |
| 动作迁移 | ✅ V2V Motion Transfer | ❌ 无 |
| 多镜头 | ✅ 原生支持 | ❌ 单镜头为主 |
3.3 成本与可及性对比
| 维度 | MiniMax H3 | Wan2.1 |
|---|---|---|
| 获取方式 | API 调用(商用) | 完全开源(Apache 2.0) |
| 本地部署 | 不可(权重未开放) | ✅ 可本地部署 |
| 消费级 GPU | 未知 | ✅ 1.3B 仅需 8.19GB |
| RTX 3060 12GB | 不可用 | 可用(T2V-1.3B) |
| 商用成本 | 2K 每秒 < 主流 1/3 | 自有 GPU = 电费 |
| 自定义/微调 | 不可(短期) | ✅ 完全可控 |
| 国产芯片 | 已考虑兼容 | 社区适配中 |
这里有一个关键差异:H3 的性价比是”API 调用层面的”,Wan2.1 的性价比是”拥有权层面的”。
如果你用的是 API,H3 在 2K 分辨率下确实便宜(不到主流 1/3)。但如果你有自己的 GPU,Wan2.1 的边际成本几乎为零。
3.4 生态成熟度对比
| 维度 | MiniMax H3 | Wan2.1 |
|---|---|---|
| 开源状态 | 计划开源(未定时间) | 已开源(2025.02) |
| 技术论文 | 未发布(承诺后续 Tech Report) | 未发布(Coming Soon) |
| 社区生态 | 刚起步 | 12.3k followers,活跃社区 |
| 集成支持 | MiniMax API | Diffusers, HuggingFace, ModelScope |
| 第三方工具 | MiniMax Design, 星野 | 大量社区工具 |
| 迭代速度 | 新发布(Hailuo 01→02→H3) | 2.1 后已有 Wan 3.0 |
四、实战视角:RTX 3060 12GB 用户怎么选
作为有一张 RTX 3060 12GB 的开发者,这个问题的答案其实很明确——但取决于你的使用场景。
场景 A:你想本地部署、自由实验
选 Wan2.1-T2V-1.3B。
这是目前唯一能在 12GB 显存上跑的文生视频模型。8.19GB 的显存需求意味着你还有余量做 LoRA 微调或者跑 ComfyUI 工作流。生成速度慢(5 秒视频约 4 分钟),但至少你能:
- 离线生成,不花钱
- 微调自己的风格
- 集成到 ComfyUI 工作流
- 生成带中文文字的视频(海报、片头)
我之前的博客里写过从 ComfyUI 到最终 AI 视频生产流水线的路径,Wan2.1 是那个流水线上最接地气的环节。
场景 B:你需要 2K 画质、原生音频、商用交付
选 H3 API。
如果你要做广告、电商视频、品牌内容——这些场景对画质和音频有硬性要求。1.3B 模型的 480P 视频没法交差。H3 的 2K 原生分辨率 + 原生双声道音频是目前 API 市场里少有的”商用级”选择。
但代价是:
- 你需要 API 额度
- 不能本地部署
- 暂时不能微调
场景 C:两者都不是,或者两者都要
短期用 Wan2.1 做实验,等 H3 开源后切换。
MiniMax 承诺了 H3 会开源,而且”设计初期就考虑了国产芯片兼容”。如果 H3 的权重真的开放,而且能适配消费级 GPU,那将是一次巨大的范式转移。
但目前,Wan2.1 是唯一可落地的选择。
五、深层观察:行业正在发生什么
5.1 “统一模型”趋势的真实含义
H3 的核心叙事是”任务统一”——不再需要 T2V 一个模型、I2V 一个模型、Video Editing 一个模型。这个方向在 LLM 领域已经被证明是有效的(GPT-4 一个模型处理所有文本任务),但在视频生成领域还处于早期。
但这里有个悖论:任务统一的代价是训练数据和标注成本的爆炸式增长。H3 的 Contextual Omni Representation 需要每个素材消耗 10 万 Token 推理做 caption——这是天文数字的成本。MiniMax 能不能持续投入,取决于 H3 的商业回报。
5.2 开源 vs 闭源的永恒博弈
Wan2.1 证明了”视频生成开源”是可行的——1.3B 模型能在消费级 GPU 上跑,Apache 2.0 协议允许商用。这会倒逼其他玩家跟进。
MiniMax H3 也承诺开源,但”在符合相关法律法规的前提下”这个措辞很微妙。中国 AI 模型的开源政策还在演变中,H3 能否真正开源、何时开源、以什么协议开源,都有不确定性。
5.3 分辨率竞赛的下一步
当前视频生成模型的分辨率大致是:
1 | 2024 年:480P 是"高清" |
但分辨率不是唯一指标。H3 的 In-context Regeneration 思路很有趣——与其在超分上死磕,不如让模型”重新想象”高分辨率版本。这个方向值得持续关注。
5.4 音频生成的分水岭
H3 的原生双声道音频是一个质变。目前大多数视频模型要么没有音频,要么只有后期配音。H3 试图从训练阶段就让视频和音频联合建模——这意味看生成的视频里,人物的口型、动作和声音在时间上是天然对齐的。
这对广告、影视、游戏行业的意义是巨大的。但目前只有 H3 和少数闭源模型做到,开源社区还差得很远。
六、总结:没有银弹,只有选择
| 如果你是…… | 推荐选择 | 理由 |
|---|---|---|
| 个人开发者,有消费级 GPU | Wan2.1-T2V-1.3B | 唯一可本地部署的方案 |
| 内容创作者,需要商用画质 | H3 API | 2K + 原生音频,性价比不错 |
| 企业用户,需要定制化 | 等 H3 开源 | 短期用 Wan2.1 + ComfyUI |
| 研究人员,想深入理解 | Wan2.1 | 完全开源,可复现、可修改 |
| 多模态交互产品开发者 | 等 H3 稳定 | 多模态上下文是独特卖点 |
视频生成还在快速演变中。Wan2.1 代表了”开源民主化”的路线,H3 代表了”全模态大一统”的路线。它们不是竞争关系——更像是同一个领域的两个实验方向,一个向下扎根社区,一个向上冲击天花板。
“最好的模型不是参数最大的,也不是开源的,而是最适合你当下那个具体问题的。”
参考链接:
- MiniMax H3 官方发布 — “MiniMax H3:打破任务和模态的边界”,2026-07-31
- Wan2.1-T2V-1.3B (HuggingFace) — 8.19GB VRAM,Apache 2.0
- Wan2.1-T2V-14B (HuggingFace) — 14B 参数旗舰版
- Wan 官网 — 已更新至 Wan3.0
- MiniMax 模型矩阵 — M3、M2.7、M2.5、H3、Speech 2.8、Music 3.0