MiniMaxH3技术解读

目　录

一、公司介绍：MiniMax 是谁　　2022 年初创立，使命 Intelligence with everyone

二、技术发展过程与技术路线　　三代模型，一次范式切换

三、定义、功能及作用　　统一上下文的视频生成模型

四、协调配合工作的技术架构　　四个组件接力

五、技术原理　　四条技术选择各解决一个瓶颈

六、技术发展路线　　三个已实现，两个在路上

七、技术应用场景　　官方按六类内容组织

八、市场和价格情况　　五档单价与单条成本

九、竞争对手情况　　与 Sora 2 的逐项对照

十、行业市场案例　　H3 Max 与 fal.ai 的联合发布

关于 LinkTokenView　　一个密钥，接入你所有的大模型

附、数据来源与说明　　哪些核实了，哪些是本文归纳

  先给一句定位：H3 值得单独写一篇，不是因为它画得更好看，而是因为它换掉了「任务怎么划分」这件事本身。过去图像、视频、音频各有各的专家模型，文生视频、图生视频、首尾帧、主体参考也各是一个任务；H3 把它们统一成「用自然语言描述上下文与目标的关系」。这个改变同时影响了应用范式和训练范式，也解释了它为什么能把 2K 单价压到官方所说的水平。

  一  公司介绍：MiniMax 是谁

MiniMax 创立于 2022 年初，官方使命写的是「与每个人共创智能」（Intelligence with everyone）。它的定位是一家通用人工智能技术公司，自研了一系列多模态基础模型，特点是代码与 Agent 能力、超长上下文处理，以及能理解、生成并整合文本、音频、图像、视频、音乐等多种模态。

把这些能力做成产品的方式也值得注意：它同时铺了面向普通用户的产品线和面向开发者的开放平台。前者包括 MiniMax Code、MiniMax Design、MiniMax Audio、Talkie，后者是给企业和开发者用的 API 平台。这种「自有产品 + 开放平台」的双轨，是理解它定价策略的前提——它既卖 API，也自己消化一部分产能。

  1.1 模型矩阵：三条线并进

从官方文档的模型清单能看清它的产品结构：语言、视频、语音与音乐三条线各自独立演进，而不是用一个模型包打全部。

▪ 语言线。MiniMax-M3.1-Flash 与 MiniMax-M3，百万级上下文，多模态，M3.1 Flash 还支持可调的思考深度。价格上 M3.1 Flash 输入每百万 token 0.15 美元、输出 0.60 美元，M3 在 512K 以内输入 0.30 美元、输出 1.20 美元（长期五折价）。

▪ 视频线。MiniMax H3 与 H3 Max。这是本文的主角，下文展开。另有 Hailuo 2.3、2.3 Fast、Hailuo 02 作为旧型号仍在文档中列出。

▪ 语音与音乐线。speech-2.8-hd 与 speech-2.8-turbo，支持 40 种语言、7 种情绪；以及 Music 3.0，官方称其为开放权重、可直接用于生产的音乐模型。

  1.2 为什么视频线值得单独看

三条线里，视频是最贵、也最容易被价格挡住的一条。语音按字符计费、语言按 token 计费，而视频按秒计费，一条片子几秒就是几毛到一块多美元。这决定了视频模型的市场竞争不只比画质，更比「每秒多少钱」。H3 的整套设计——从统一任务降低训练成本，到五档单价覆盖不同场景——都是围绕这件事展开的。

  二  技术发展过程与技术路线

官方博客把 H 系列的三代分工写得很清楚：Hailuo 01 是从零把系统建起来，Hailuo 02 聚焦改进核心组件——架构效率、数据质量、规模。到了 H3，换的不是组件，而是任务的划分方式。

图 1　三代演进与 H3 的范式切换

  2.1 H3 之前：能力被切成孤岛

官方在解释设计动机时，列了一张「碎片化」的清单，这张清单本身就是问题诊断：

▪ 图像侧。图像生成被拆成文生图、编辑、主体参考、运动参考、风格参考，各自一个专家模型。

▪ 音频侧。人声、音效、音乐基本作为三个独立方向研究。

▪ 视频侧。视频生成被进一步切成文生视频、图生视频、首尾帧、主体参考、运动参考、语音参考、视频编辑，而且图像、视频、音频之间还有明确边界。

官方对这套结构的评价是：这些孤岛既限制了创作自由，也在训练侧封顶了模型的泛化能力。注意后半句——它承认问题不只是使用体验，而是训练效率。这一点很关键，因为它意味着统一任务不是产品层的包装，而是成本层的动作。

  2.2 技术路线：用语言把任务统一

H3 的第一原则是「把任务与模态统一、泛化」。具体落地成四条预训练任务线：

▪ 生成类。文生图、文生视频、文生音频。其中文生视频会联合生成音频，所有音频输出都是原生立体声，并且支持原生多镜头建模；文生音频里人声、音效、音乐不再分离，全部联合建模。

▪ 参考与编辑类。图到图、图到视频、音频到音频、音视频到音视频。官方的叫法是「广义参考与编辑」。

「广义参考与编辑」有两层含义，官方都点明了。第一层是数据：完全来自真实的自然数据，因此数据可扩展性强。第二层是接口：参考关系与编辑关系用自然语言表达，而不是被固定在一个任务集合里。官方把这句总结为——语言是通往泛化的桥梁。

  这里有一个容易被忽略的判断：如果参考关系能用自然语言描述，那么「新增一种参考类型」就不需要新训一个模型，只需要把这种关系说清楚。这是为什么 H3 的示例提示词可以写出「参考视频 1 的希区柯克式运镜，让图像 2 的人物演唱，音色对齐音频 3」这种跨模态组合——它不是三个功能串起来，而是一句话被理解。

  三  定义、功能及作用

  3.1 定义

官方的定义是：H3 是一个通用多模态生成模型，它统一理解文本、图像、视频与音频上下文，生成带原生立体声的视频，最高 15 秒、2K 分辨率。官方同时说明，计划在符合适用法规的前提下开放模型权重。

拆开看三个限定词。「统一上下文」意味着四种输入不是分别处理再拼接，而是在同一处被读；「原生立体声」意味着声音是生成出来的，不是后期配的；「计划开放权重」意味着它把自己放进了开源生态这一侧，而不是纯闭源服务。第三点后面第九章讲竞争格局时会再提，因为它改变了竞争方式。

图 2　定义、三种生成模式与三大核心能力

  3.2 功能：三种生成模式

官方把能力收敛成三种模式，每种对应不同的输入组合。

▪ 文生视频。只给提示词，从零生成一条视频。

▪ 图生视频。提示词加首帧和／或尾帧图像，控制起点或终点。

▪ 参考生成。提示词加参考图像、视频或音频，可以参考人物、运动、镜头、风格、音色或剪辑节奏。

第三种是 H3 与多数同类产品差别最大的地方：它能同时吃下多路、多模态的参考，并且允许你在提示词里描述这些参考之间、以及参考与目标之间的关系。

  3.3 官方归类的作用：三大核心能力

官方文档把能力归纳为三条，并用大量示例视频佐证。这三条其实是三个层次：

▪ 原生多模态理解与生成。接受四种输入，理解人物、运动、声音、情绪、镜头、风格与意图，把多路参考融成一条音画同步的输出。

▪ 精确的多模态编辑与控制。跨维度修改人物、物体、场景、声音与节奏，对已有内容做可预期的迭代。

▪ 可直接生产的内容创作。面向影视、广告、品牌、电商与游戏，覆盖画面文字、品牌资产、创意效果、产品展示、界面动效、游戏视觉与风格化表达。

第二条值得单独说一句。官方在博客里明确提到 H3 擅长「准确的文字与品牌渲染」以及「V2V 运动迁移」。这两项恰好是广告和电商素材最常见的两个硬需求——包装上的字不能错，产品的运动要像。它们不是画质问题，是可用性问题。

  3.4 规格：H3 与 H3 Max

官方目前给出两个视频型号。它们不是新旧关系，而是同一基座上的两种取舍。

表 1　两个视频型号的规格对照（据官方 Models 与 Video Generation 页）

项目	MiniMax H3	MiniMax H3 Max
模型名	MiniMax-H3	MiniMax-H3-Max
输出分辨率	768P / 2K	480P / 768P
输出时长	4 至 15 秒，仅整数	5 至 15 秒，仅整数
帧率	24 fps	24 fps
生成模式	文生视频、图生视频、首尾帧、多模态参考	文生视频、图生视频、参考生成
参考输入	图像、视频、音频	图像、视频、音频
定位	开放、通用的多模态视频模型	由 fal.ai 在 H3 上后训练，面向高速生成

  两个型号的时长下限不同，这一点在排期时会被忽略：H3 从 4 秒起，H3 Max 从 5 秒起。如果你需要一条 4 秒的素材，只有 H3 能做。另外两者都要求整数秒，不接受 4.5 秒这种取值。

  四  协调配合工作的技术架构

H3 的架构可以理解成一条四段式流水线：每一步都把上一步的产物当输入，四者串起来才构成一次完整的生成。官方在博客里点名了这四个组件。

图 3　四个组件的接力关系与关键数字

  4.1 四个组件各管一段

表 2　四个技术组件的职责与官方关键事实

组件	解决什么	官方给出的关键事实
H3-Contextual Omni Representation	把多模态上下文读成带关系描述的结构	caption 不只描述目标视频，还要描述上下文与目标的关系、上下文内部元素之间的关系；源素材约需 100K tokens 推理，蒸馏到平均约 4K
H3-VAE	把像素压成 token，决定效率上限	彻底重做 tokenizer，重建质量与可学习性全面提升；高压缩比带来 4 倍有效序列长度
H3-Omni Transformer	在统一空间里完成理解与生成	多模态上下文让序列长度方差扩大到 3 倍；理解与生成负载分离训练；端到端训练吞吐提升近 30%
H3-In-context Regeneration	把低分辨率结果重生成到 2K	不使用常规专用超分模块；复用基座生成能力，并可再次调取原始多模态上下文

  4.2 它们是接力，不是并列

这四个组件常被误解成四个并列的模块，实际是严格的前后依赖：

▪ 理解。第一步读上下文。把文本、图像、视频、音频读成一份结构，其中包含「上下文与目标的关系」这样的描述。这一步决定了后面能参考什么。

▪ 编码。第二步压 token。把各模态压到统一表示，压缩比直接决定序列长度，而序列长度决定训练与推理成本能不能接受。

▪ 生成。第三步生成。在统一空间里同时处理理解与生成——注意这两件事的计算负载是不一样的。

▪ 放大。第四步重生成。回到原始上下文，把低分辨率结果重新生成成高分辨率。

第二步到第三步之间存在一处真实的工程矛盾。官方说，引入多模态上下文后序列长度方差变成 3 倍，理解与生成的计算负载高度异构。他们的做法是把两类负载分开训练、分别调硬件的利用率，同时在单样本层面平衡异构计算、在样本之间做负载均衡。结果是端到端训练吞吐提升近 30%。这个数字不是模型能力，纯粹是工程效率，但它直接换算成了单价。

  4.3 一处刻意的「退化」

官方在讲 H3-Omni Transformer 时，主动说了一件反常的事：他们放弃了 Hailuo 02 的架构。尽管那套架构此前给他们带来明显的架构优势，但对一个以任务泛化为目标的模型来说，它会引入不必要的复杂度。

官方给的理由是：任务泛化是不可逆的趋势，架构技巧应当让位于模型如何被定义。这句话值得抄下来，因为多数团队的做法正好相反——先选一套好用的架构，再让任务迁就它。

  五  技术原理

把官方的技术说明按「解决什么瓶颈」重排，会得到四条清晰的因果链。每条都不是为了跑分。

图 4　四条技术选择与它们各自解决的瓶颈

  5.1 语言作为桥梁：caption 的范围变了

H3 最重要的工程动作之一是强化 captioning 能力。引入多模态上下文之后，「caption」要覆盖的东西扩大了：不再只是描述目标视频，还要描述上下文与目标视频之间的关系，甚至上下文内部各元素之间的关系；而且要同时描述视频与音频，这种音画关系在多镜头之间会更复杂。

官方把这套做法叫 Contextual Omni Representation：语言充当可泛化的桥梁和解释器，把各种「任务」统一成一种开放的、描述性的形式。这是 H3 强指令跟随的根源。

配套的工程细节是：大多数源素材需要约 100K tokens 的推理，蒸馏到平均约 4K tokens。这个 25 倍左右的压缩，是把「理解上下文」这件事做成可负担的前提。

  5.2 H3-VAE：4 倍有效序列长度

H 系列一直在推进 tokenizer 技术，到 H3 直接换掉了前一代的分词器，在重建质量和可学习性上全面改善。更关键的是高压缩比带来的 4 倍有效序列长度增益——官方说这大幅降低了训练与推理成本，并且是原生 2K 支持的关键技术。

换句话说，2K 不是靠事后超分拼出来的，而是在表示层就腾出了空间。这也解释了为什么第五章要讲的下一个组件可以不走超分路线。

  5.3 In-context Regeneration：让基座自己重做一遍

2K 输出最常规的做法是接一个专用超分模块。H3 没有这么做，而是让基座模型在上下文里重新生成自己的低分辨率输出。官方给了两个理由：

▪ 一是复用。最大化复用基座已经具备的生成能力，不必额外训一个超分网络。

▪ 二是找回细节。重生成时能再次调取原始的多模态上下文，因此可以恢复传统超分只能「猜」、往往也猜不出来的细节——比如画面里的小字和细微纹理。

这一条对广告和电商场景意义很具体：包装上的文字、logo 的边缘、产品的高光细节，恰好是超分最容易糊掉的地方。而官方把「准确的文字与品牌渲染」列为 H3 的强项，与这条技术选择是一致的。

  5.4 预训练范式的一句话总结

官方对预训练范式的表述是：尽早融合多样的数据类型与任务，而正确的混合比例是关键。这句话里没有玄机，但「混合比例」三个字提示了真实难度——统一任务是方向，能不能收敛取决于配比，而配比是试出来的。

  六  技术发展路线

官方博客里，已经发生的和明确要做的分得很清楚。前者可以核对，后者只能引述。

图 5　三个已实现的方向与两个官方明确的下步

  6.1 已经实现的三件事

▪ 分辨率与时长。前代 Hailuo 2.3 是 1080p、6 或 10 秒；H3 做到 2K、4 到 15 秒，帧率 24fps。

▪ 价格阶梯。同一基座给出 2K、768P、Highspeed 768P、Lite 768P、Lite 480P 五档单价，最便宜一档约是 2K 的五分之一。

▪ 开放权重。官方明确计划开放模型权重，理由包括适配更多 AI 硬件、让用户更容易构建自己的定制版本，并称硬件兼容性从 H3 设计早期就是重点考虑项。

  6.2 官方明确的下一步

博客结尾列了三条，措辞都比较克制，值得按原文理解：

▪ 并入 M 系列的理解能力。官方称强多模态理解是高质量生成的基础，仍有显著改进空间，下一代 H 系列计划整合 M 系列模型的能力。

▪ 扩大模型规模。官方承认当前模型规模在若干能力上仍有提升空间，扩展是明确路径，并认为更强的任务泛化能释放潜力。

▪ 提高分辨率与视觉保真。某些场景的视觉细节仍可改进，会继续推向更高分辨率与更高保真。

  这三条里最有信息量的是第一条。它承认了「理解」和「生成」目前是两套模型，而下一代要把它们并起来。如果这条路线走通，H3 现在的统一是任务层面的统一，下一代可能是模型层面的统一。这是路线图里唯一的方向性变化，其余两条都是量的推进。

  七  技术应用场景

官方文档按六类内容组织示例，每类都给出了提示词与参考素材的实际写法。这种组织方式本身说明它已经按生产场景设计，而不是按技术能力罗列。

图 6　官方归纳的六类应用场景

  7.1 六类场景

▪ 品牌片与影视感内容。电影预告、TVC、高端品牌片。官方示例是一支 16:9 的时尚品牌广告：用四张图分别定调性与颗粒感、定人物、定包、定片尾 logo，再讲一段沙漠公路上的叙事。这类用法的关键是「多路参考定调性」。

▪ 视觉创意与内容包装。视觉包装、片头、动效。依赖准确的文字渲染与品牌资产还原。

▪ AI 叙事内容。带声音的叙事短片。画面与音频一次生成，原生立体声。

▪ 产品与电商。商品展示与带货素材。用参考生成锁住产品外观的一致性。

▪ 数字体验与游戏创意。界面动效与游戏视觉。靠多镜头与运镜参考控制节奏。

▪ 动画与风格化视觉。动画与风格化表达。用风格参考加编辑迭代逐步收敛。

  7.2 一个示例提示词能说明用法

官方给的多模态上下文示例，提示词原文只有一句：「参考视频 1 的希区柯克式运镜，让图像 2 的人物演唱，音色对齐音频 3。」官方对此的说明是：只把上下文与目标视频的关系用文字讲清楚，复杂的全模态理解由 H3 自己处理。

这句提示词的写法值得注意——它没有拆参数，没有分步骤，也没有指定哪个模块做什么。三路参考、两种模态、三种关系（运镜、人物、音色）被压进一句话。这就是第二章说的「语言作为桥梁」在应用层的直接体现。

  7.3 反过来，什么场景不适合

从规格能直接推出几条边界：单条最长 15 秒，所以长片只能靠多段拼接，而多段之间的一致性要自己解决；时长只接受整数秒，精细到帧的卡点做不了；分辨率上限 2K，4K 交付仍需后期处理。这三条不是缺点，是选型时该先确认的事。

  八  市场和价格情况

视频模型的定价方式与语言模型不同：语言按 token 计费，视频按秒计费，而且输入视频也要按秒算钱。所以看价格时不能只看一个数字，要看完整的价格结构。

  8.1 官方价格阶梯

表 3　H3 系列按秒计费的五档单价（据官方 Pricing 页）

型号与分辨率	输出视频（美元/秒）	输入视频（美元/秒）	图片输入（美元/张，超出免费额度）
MiniMax-H3　2K	0.13	0.13	0.04
MiniMax-H3　768P	0.08	0.08	0.04
MiniMax-H3-Highspeed　768P	0.06	0.06	0.03
MiniMax-H3-Lite　768P	0.04	0.04	0.02
MiniMax-H3-Lite　480P	0.025	0.025	0.02

三条计费规则要注意。每任务前 5 张图片免费，超出部分按张计费，且图片单价不随图片或输出分辨率变化。输入视频按输入时长、以所选模型的输出分辨率单价计费。音频输入免费。另外，同一模型同一分辨率下，所有任务类型单价相同——文生视频、图生视频、首尾帧、参考生成都是一个价。

  8.2 单条视频的成本是算术题

把单价乘时长就能算出成本，不需要估算。下面按 10 秒一条做对照，这是最常用的长度之一。

表 4　10 秒一条视频的成本换算（按官方单价自算）

做法	单价（美元/秒）	10 秒成本（美元）	相对 2K 的比例
H3　2K	0.13	1.30	1.00
H3　768P	0.08	0.80	0.62
H3-Highspeed　768P	0.06	0.60	0.46
H3-Lite　768P	0.04	0.40	0.31
H3-Lite　480P	0.025	0.25	0.19

这张表里最重要的不是绝对值，而是比例：最便宜一档只有 2K 的 19%。这意味着「先用低档位试，定稿再上 2K」这个流程能省掉大部分钱——而 H3 的五档是在同一基座上的，切换档位不需要改提示词。

  8.3 厂商的价格主张，以及它没说清的部分

官方在博客里给了一个横向对比的说法：2K 下 H3 的每秒价格低于主流模型的三分之一，768p 下低于主流模型 720p 价格的一半。

  这句话必须标注清楚：它是厂商自述，本文没有做独立验证，因为官方没有点名「主流模型」具体指哪几家、取的是哪一档价格。引用时请保留「官方称」这三个字。本文第八章的所有单价与成本换算是可核对的，唯独这句横向比较只能引述、不能复现。

  8.4 价格结构透露的策略

五档单价不只是一张价目表，它对应三种不同的使用方式。按分辨率与档位排下来，可以看出官方在把「试错」和「定稿」分成两笔钱：

▪ 定稿档。2K 与 768P 的 H3 主型号。对应对画质有要求的成片，也是官方宣称价格优势的主要落点。

▪ 日产档。Highspeed 768P。对应日常内容生产，速度与质量折中。

▪ 试错档。Lite 的 768P 与 480P。对应创意探索与批量生成，单价低到可以「多试几条再挑」。

这三档加起来，实际是在卖一个工作流：用最便宜的档位大量试，选中了再用贵档位出成片。如果只有一档价格，这个工作流就不成立。这是我读这份价目表时觉得最值得注意的地方——它的定价是为创作流程设计的，不是为报价单设计的。

  九  竞争对手情况

视频生成这条线上，能公开核对到完整规格与策略的对手不多。本章只做一处可核对的逐项对照：OpenAI 的 Sora 2（以其在 Microsoft Azure 上的文档口径为准），因为这个来源把规格、限制和内容政策都写全了。

  9.1 与 Sora 2 的逐项对照

表 5　H3 与 Sora 2 的逐项对照（H3 据 MiniMax 文档，Sora 2 据 Microsoft Learn）

维度	MiniMax H3	Sora 2（Azure 口径）
最高分辨率	2K	1920×1080（含竖版 1080×1920）
时长	4 至 15 秒，整数	1 至 20 秒；接口取 4 / 8 / 12，默认 4
帧率	24 fps	文档未列明
音频	原生立体声，生成即带	输出支持音频
参考输入	图像、视频、音频，可多路	至多 2 张图；1 段不超 5 秒视频
对已有内容再加工	参考生成与编辑	Remix，按 ID 复用结构与运镜
权重开放	官方计划开放	闭源，由云平台托管
内容政策	本文未取得官方口径，不下结论	拒绝全部 IP 与写实内容；仅适合 18 岁以下受众；拒绝版权角色与版权音乐；不得生成真人含公众人物；含真人脸的输入图会被拒绝
生成耗时	文档未列明	约 1 至 5 分钟
并发	文档未列明	同时最多 2 个任务

  这张表里最值得注意的不是分辨率或时长，而是内容政策那一行。Sora 2 在 Azure 上的口径明确写了两条：不得生成真人（含公众人物），含真人脸的输入图会被拒绝。而 H3 官方把「电商模特」「品牌人物」这类需要稳定人像的场景列为主打。这两者在可用边界上是明显不同的。但本文没有取得 H3 自身内容政策的官方完整表述，所以只陈述差异，不推断优劣。

  9.2 三条可读出的竞争差异

▪ 分辨率与时长方向不同。H3 上限 2K、Sora 2 上限 1080p；反过来 Sora 2 上限 20 秒、H3 上限 15 秒。一个往清晰度走，一个往长度走。

▪ 参考输入的模态不同。H3 接受音频作参考，Sora 2 的参考输入只有图和短片段视频。这是模态覆盖面的差别，会直接影响「配音对齐」这类需求能不能一次做完。

▪ 生态形态不同。H3 计划开放权重，Sora 2 闭源托管。这决定了生态玩法：开放权重可以被第三方后训练、可以在自有硬件上跑；闭源只能通过云服务调。

  9.3 一份诚实的说明

本章没有给出市场份额、厂商营收或增长率的比较，也没有给出画质盲测结论。原因是本次未能取得可核实的此类一手材料。视频生成的画质评价高度依赖具体提示词与审片标准，官方示例都经过挑选，用它做横向比较并不成立。

如果要做真正的选型比较，建议的做法是：用你自己的十条提示词，在同一预算下各跑一遍，按「可用条数」而不是「最好一条」来打分。这也是本文唯一敢给的选型建议。

  十  行业市场案例

这一章要说明清楚性质：本文没有编造客户故事和效果数字。能核实到、并且对这个行业的合作方式有实际影响的一个案例，是 H3 Max 与 fal.ai 的联合发布。它属于平台层面的产业分工，不是单一客户案例。

图 7　H3 Max 与 fal.ai 的分工结构

  10.1 事件本身

官方文档的表述是：MiniMax H3 Max 由 MiniMax 与 fal.ai 联合发布，是 fal.ai 在 MiniMax H3 上做后训练得到的视频生成模型，针对高速生成做了优化。它提供主流的 480P 与 768P 输出，生成速度快于 MiniMax H3，支持文生视频、图生视频与参考生成三条路径。

注意这里的措辞是「后训练」（post-trained），不是「接入」或「代理」。也就是说这不是一个渠道分销关系，而是 fal.ai 真的在 H3 的权重上继续训练了一个速度优化的版本。这个区别决定了后面要说的一切。

  10.2 关键事实

表 6　H3 Max 案例的关键事实（据官方 Video Generation 与 Models 页）

项目	内容
参与方	MiniMax（提供基座 H3）与 fal.ai（后训练与高速优化）
产物	MiniMax H3 Max，官方模型名 MiniMax-H3-Max
输出规格	480P / 768P，5 至 15 秒，24 fps
速度定位	官方称生成快于 MiniMax H3
支持模式	文生视频、图生视频、参考生成
与前代关系	不是替代关系，与 MiniMax H3 在官方清单里并列
原厂保留	2K 输出与文生视频／图生视频／首尾帧／多模态参考的完整能力

  10.3 这个案例为什么值得单独讲

它示范了一种在闭源时代不成立的合作方式。三点：

▪ 开放权重是前提。如果 H3 是闭源的，第三方拿不到权重，就不可能在上面做后训练。速度优化只能由原厂自己排队做，而且要和画质优化抢同一批资源。

▪ 画质与速度被拆开卖。同一套基座被拆成两个产品：一个卖 2K 画质，一个卖速度，分辨率和价格都不一样。用户不必二选一，而是按任务选。

▪ 分发可以由别人做。原厂不必自己覆盖所有推理场景。平台方负责就近推理与速度，原厂收回生态与心智。对原厂来说，这是用一部分商业空间换生态覆盖。

  10.4 这个案例不能证明什么

需要说清楚的是：本文没有取得 H3 Max 的实际调用量、收入分成比例、用户增长或客户名单，也没有取得它相对 H3 的速度实测数据。官方只说「快于」，没有给倍数。

所以这个案例能证明的是「这种分工方式已经发生」，不能证明它「带来了多少商业回报」。把这两件事分开，是对读者更有用的诚实。

  关于 LinkTokenView

视频模型的账最难算：它按秒计价，输入视频也按秒算钱，而一条片子往往要被重试好几次。选错档位，成本不是多百分之几，而是差五倍。LinkTokenView 是 AI 一站式服务平台：一个密钥，接入你所有的大模型。把不同厂商、不同模态、不同档位的调用与成本放在同一处看清，才能判断一条片子该用 2K 定稿、还是用最低档先试。

Link tokens, view the future.

www.linktokenview.com

  附  数据来源与说明

[1] MiniMax 官方博客《MiniMax H3: An Open Model Breaking the Boundaries Between Tasks and Modalities》（2026-07-31）。用于：H3 是通用多模态生成模型、统一理解文本/图像/视频/音频上下文、生成带原生立体声的视频、最高 15 秒 2K；计划在符合适用法规前提下开放模型权重；早期测试显示适用于商业内容创作，擅长指令跟随、准确的文字与品牌渲染、V2V 运动迁移；面向广告、品牌、电商、产品设计、UI/UX、游戏；厂商价格主张「2K 每秒价格低于主流模型三分之一、768p 低于主流模型 720p 的一半」；Hailuo 01 从零建系统、Hailuo 02 改进架构效率与数据质量与规模；H3 之前任务被碎片化的清单（图像侧五类、音频侧三类、视频侧七类）；第一原则是统一与泛化任务；四条预训练任务线；「广义参考与编辑」的两层含义（真实自然数据、语言作为桥梁）；尽早融合多样数据类型与任务、混合比例是关键；四大技术组件与它们的说明（Contextual Omni Representation 的 caption 范围扩大、约 100K tokens 蒸馏到约 4K、H3-VAE 换掉分词器与 4 倍有效序列长度、H3-Omni Transformer 放弃 Hailuo-02 架构与序列长度方差 3 倍与训练吞吐提升近 30%、In-context Regeneration 不使用专用超分模块及其两个理由）；多模态上下文示例提示词原文；品牌片示例提示词原文；官方明确的下一步三条（整合 M 系列能力、扩大模型规模、提高分辨率与保真）；以及结尾「Intelligence with Everyone」。

[2] MiniMax 官网首页（minimax.io）。用于：公司创立于 2022 年初、使命 co-create intelligence with everyone、自研多模态基础模型并具备代码与 Agent 能力与超长上下文、可理解生成整合文本音频图像视频音乐、产品线包括 MiniMax Code、MiniMax Design、MiniMax Audio、Talkie 与面向企业与开发者的开放平台；以及模型矩阵中 M3.1 Flash、M3、H3、H3 Max、Speech 2.8、Music 3.0 的并列关系与 H3 归入 VIDEO 类。

[3] MiniMax API 文档《Video Generation》。用于：MiniMax H3 是开放、通用多模态视频模型，统一理解文本与图像与视频与音频输入，支持视频生成、基于参考的创作与视频编辑；MiniMax H3 Max 由 MiniMax 与 fal.ai 联合发布、是 fal.ai 在 H3 上后训练并针对高速生成优化的模型、提供 480P 与 768P 输出、生成快于 H3、支持 T2V 与 I2V 与参考生成；两种型号的生成模式表；模型名 MiniMax-H3 与 MiniMax-H3-Max；H3 输出 768P/2K、4 至 15 秒仅整数、H3 Max 输出 480P/768P、5 至 15 秒仅整数；以及常见画幅比例或自适应。

[4] MiniMax API 文档《Models》。用于：视频型号清单中 MiniMax H3 标注为 768P/2K、4 至 15 秒、24fps，支持文生视频/图生视频/首尾帧/多模态参考；MiniMax H3 Max 标注为 480P/768P、5 至 15 秒、24fps；旧型号 Hailuo 2.3 为 1080p 6 秒或 768p 6 秒与 10 秒、Hailuo 2.3Fast 与 Hailuo 02 同列；语言线 M3.1-Flash 与 M3 均为百万上下文多模态、M3.1 Flash 支持可调思考深度；语音线 speech-2.8-hd 与 speech-2.8-turbo 支持 40 种语言与 7 种情绪。本文第六章「前代是 1080p、6 或 10 秒」即取自此处。

[5] MiniMax API 文档《Pricing Overview》。用于：H3 系列五档单价——MiniMax-H3 2K 输出视频与输入视频均为每秒 0.13 美元、768P 均为 0.08 美元；MiniMax-H3-Highspeed 768P 均为 0.06 美元；MiniMax-H3-Lite 768P 均为 0.04 美元、480P 均为 0.025 美元；图片输入超出免费额度后 2K 与 768P 为每张 0.04 美元、Highspeed 为 0.03 美元、Lite 为 0.02 美元；每任务前 5 张图免费、图片单价不随图片或输出分辨率变化、输入视频按输入时长以所选模型输出分辨率单价计费、同一模型同一分辨率下所有任务类型单价相同、音频输入免费；以及语言线 M3.1-Flash 输入 0.15 与输出 0.60、M3 在 512K 以内输入 0.30 与输出 1.20（长期五折）。本文第八章的单价与成本换算全部取自此处，其中成本换算为单价乘时长的算术结果。

[6] MiniMax API 文档《H3 Feature Highlights》。用于：三大核心能力的官方表述（原生多模态理解与生成、精确的多模态编辑与控制、可直接生产的内容创作）；六类应用场景的分类与各自的示例提示词，其中品牌片示例提示词原文为 16:9 时尚品牌广告、四张图分别定调性与人物与包与片尾 logo 的那一段。

[7] Microsoft Learn《Video generation with Sora 2 (preview)》。本文第九章竞品对照中 Sora 2 的全部数据均取自此处：支持文本到视频与图像到视频与视频到视频；输出支持音频生成；支持 remix；输出分辨率支持 480×480、480×854、854×480、720×720、720×1280、1280×720、1080×1080、1080×1920、1920×1080；时长 1 至 20 秒且接口取 4/8/12 默认 4；至多 2 张图输入、1 段不超 5 秒视频输入；1080p 不支持多变体、720p 最多 2 个、其他最多 4 个；同时最多 2 个任务；任务保留 24 小时；生成约需 1 至 5 分钟；提示词建议使用英文等拉丁字母语言；以及内容政策原文——拒绝全部 IP 与写实内容、仅适合 18 岁以下受众、版权角色与版权音乐会被拒绝、不得生成真人含公众人物、含真人脸的输入图当前会被拒绝。该页标注最后更新于 2026-03-18，且 Sora 2 处于预览状态。

[8] 本文的归纳框架（非官方口径）：第六章 6.1 的「五档单价最便宜一档约是 2K 的五分之一」为按官方单价计算的算术结果；第八章 8.4「定稿档／日产档／试错档」的三分法与「定价是为创作流程设计」的判断；第九章 9.2 的三条竞争差异归纳与 9.3 的选型建议；第十章 10.3 的三点解读与 10.4 的边界说明；第二章 2.2 结尾关于「新增参考类型不需要新训模型」的推论。这些是为讲清问题做的组织与推断，事实依据均来自上述官方来源，但「这样分类、这样下判断」是本文的做法，对外引用时请说明这一点。

[9] 案例的性质说明：第十章采用的是一个可核对的平台层合作事件（第三方在原厂基座上做后训练并联合发布），不是某一客户的落地案例。本文没有虚构客户名称、效果提升百分比、成本节省金额、调用量或用户规模，因为本次未能取得可核实的此类材料；官方也未公布 H3 Max 相对 H3 的速度倍数。若需要客户侧案例，建议由具备相应授权的资料来源补充。

[10] 未作断言的部分：本文未引用任何视频生成或 AI 视频的市场规模、市场份额、增长率、厂商营收或用户数数字；未给出任何画质盲测、胜率或排名结论；未对 H3 与 Sora 2 的优劣下判断；未取得 H3 自身内容政策的完整官方表述，因此第九章内容政策一栏只陈述 Sora 2 的原文，对 H3 写的是「本文未取得官方口径，不下结论」；H3 与 Sora 2 的生成耗时、并发数两项，凡文档未列明处均写「文档未列明」，未作推测。厂商自述的价格横向比较已在正文 8.3 明确标注为厂商口径、未做独立验证。

[11] 本文图片全部由脚本按上述事实绘制，图中每个数字与规则都能在对应章节正文或表格中找到出处。

[12] 关于时效的说明：本文所述型号谱系、规格与价格对应当前可查到的官方文档内容。该产品线迭代较快（Hailuo 01、Hailuo 02、Hailuo 2.3 到 H3），且官方已说明计划开放模型权重、下一代将整合 M 系列能力，涉及具体型号可得性、价格与规格时，请以官方文档当期内容为准。本文未对后续型号作任何预测。