先算一笔账2K 视频生成的成本正在被腰斩7 月 31 日MiniMax 发布了全模态生成模型 H3随后宣布将在几天内开放模型权重。消息传开后资本市场先动了MiniMax 股价盘中一度拉升 15%。但比起股价我更想先算一笔账。AI 视频生成的价格过去半年一直卡在一个尴尬的位置。以 2K 分辨率为例主流闭源视频模型按秒计价一条 15 秒的 2K 视频成本大致在 20 到 40 美元之间。这个价格决定了它只能出现在广告片、预告片这种高预算场景里普通内容创作者根本用不起。H3 给出的报价是2K 分辨率下每秒价格不到主流模型的三分之一768P 下不到二分之一。基础套餐下一条 15 秒 2K 视频的成本可能低至 1 美元。这个价格不是靠补贴撑出来的而是靠架构层面的压缩换来的。H3 这次做了两件关键的事重写了 tokenizer以及在推理链路里加入了一个叫 In-context Regeneration 的环节。这两件事都值得拆开看。价格背后推理成本是怎么被一步步砍下来的视频生成的定价逻辑和文本模型不一样。文本按 token 计价视频按秒计价但两者背后是同一个公式单价等于推理成本除以毛利率。推理成本低才有底气把单价打下来所以看一家视频模型厂商的定价本质是在看它的推理效率。推理成本由三块组成计算量、显存占用和生成长度。计算量决定每帧要跑多少次矩阵运算显存占用决定单卡能同时处理几个任务生成长度决定一个任务要跑多久。H3 的 H3-VAE 把序列长度压到四分之一三块成本一起降序列短了注意力计算量降一个量级序列短了中间激活的显存占用同步下降序列短了单任务耗时缩短单位时间的吞吐量上升。更关键的是第二块收益——显存。视频生成是显存饥渴型任务主流模型单条 2K 视频经常要占满一张高端卡。序列压缩之后同样的显存能塞下更长的视频或者同样的视频能跑在更小的卡上。对厂商来说这意味着单位 GPU 的产出翻倍对开发者来说这意味着本地部署的门槛降低。所以 H3 的定价不是市场策略是架构策略的必然结果。它把成本结构的底子改了然后才敢把价格打下来。这个顺序不能反先定价再压缩是营销先压缩再定价才是工程。另外值得注意的一点是MiniMax 上一代视频模型的定价并不便宜这次的价格调整幅度之大说明 H3-VAE 带来的收益是量级层面的不是百分之十几的边际优化。这也是为什么发布当天市场反应那么直接——懂行的人看的是成本曲线不是演示视频。对比维度主流视频模型Seedance 等MiniMax H3最高分辨率1080P 为主部分支持 4K原生 2K2560×1440音频多数需额外合成视频音频同步生成原生双声道2K 每秒成本基线不到基线的 1/3768P 每秒成本基线不到基线的 1/2输入模态文本、图像为主文本、图像、视频、音频任意组合开源计划闭源计划开放权重在展开技术细节之前有必要把这件事放进更大的背景里看。过去半年AI 视频生成赛道被 Seedance 2.0 压得喘不过气几乎所有的技术讨论都围绕它展开MiniMax 上一代视频模型的声量明显落后。H3 的发布某种程度上是一次憋了很久的反击。而它选择的反击方式不是堆参数也不是堆演示视频而是直接改写成本结构。这个策略选择本身就值得单独分析。同时要看到MiniMax 上个月刚凭借 M3 在文本模型领域崭露头角这次紧接着推出全模态的 H3产品节奏明显在加速。一家公司同时押注文本、视频两条线而且都选择了开源路线这背后有清晰的商业逻辑文本模型证明技术实力视频模型打开付费场景开源权重换取生态和信任。H3-VAE把视频序列压缩到原来的四分之一视频模型之所以贵根源在序列长度。一段 15 秒的 2K 视频按帧拆开是几百帧图像每帧再切成 token序列长度轻松冲到几十万。序列越长注意力计算的成本越高推理也就越慢越贵。所有视频生成模型都在做同一件事用一个 VAE 把高分辨率视频压缩成潜空间里的短序列生成完成后再解码回像素。压缩率决定了序列能短多少也就决定了整个模型的成本下限。H3 的做法是重写整个 tokenizer做出了一个全新的 H3-VAE。官方给出的数字是压缩率带来的序列长度收益达到4 倍。序列长度直接缩到原来的四分之一意味着注意力计算量理论上下降一个量级推理成本和延迟随之大幅下降。这里有个容易被忽略的细节压缩率提升不是免费的。压缩得越狠潜空间里丢失的细节越多解码回来的画面就越糊。H3 解决这个矛盾的办法不是调低压缩率而是给推理链路加了一个后处理环节也就是下一节要说的 In-context Regeneration。对开发者来说H3-VAE 的意义在于它把成本结构改了。以前想省成本只能降分辨率、缩短时长现在同样的预算可以跑出 2K 的长片段产品的边界就被打开了。In-context Regeneration先出低清再在原地上补细节In-context Regeneration 这个名字听起来很学术做的事情其实很直白让基座模型结合原始上下文重新生成高分辨率版本。传统超分辨率是独立的后处理模块模型只能看到一张低清图靠插值或单独训练的超分网络去猜测细节猜出来的东西经常和原内容对不上——人物五官变形、文字笔画错乱。H3 的 Regeneration 不是独立超分而是把低分辨率输出连同原始输入上下文一起重新喂回基座模型让模型在理解原意的基础上补全细节。文字渲染、品牌信息、人物一致性这些最容易翻车的环节因为有了原始上下文的约束表现明显提升。这也是为什么 H3 敢主打手绘风格特效和复杂字幕动画。官方演示里用户给一句自然语言描述模型直接输出带动态花体字的画面不需要任何后期软件。传统视频后期里最费人工的字幕动画环节在这里被模型直接吃掉了。把 H3-VAE 和 In-context Regeneration 放在一起看能发现一个有意思的分工前者负责把成本压下来后者负责把质量补回去。压缩是为了快和便宜再生成是为了不糊不烂。两个机制一降一升恰好补上了对方留下的洞。任务泛化不再一个任务一个模型MiniMax 之前的视频模型是按任务拆分的图生视频一个模型文生视频一个模型视频编辑又一个模型。每个任务单独训练、单独维护参数不共享成本自然堆叠。H3 换了一条路官方管它叫「任务泛化」。具体做法是把多种任务塞进同一个预训练框架用自然语言描述任务之间的关系模型在训练时学会的不是某一个具体任务而是任务之间共享的底层规律——画面怎么动、时序怎么连贯、声音和画面怎么对齐。这套架构换来的直接收益是端到端训练吞吐提升接近30%。训练效率上去了模型迭代速度就跟得上成本也有进一步下降的空间。任务泛化对使用者的体验提升是隐性的但很关键你不需要记住「这个功能该用哪个模型」一个 H3 就能同时处理生成、编辑、风格迁移、音频同步。接口变简单了产品逻辑也变简单了。从工程角度看任务泛化的本质是把「模型的维护成本」转移成了「数据的组织成本」。以前每新增一个任务就要训练一个新模型现在每新增一个任务只需要在统一框架里补充对应的任务描述和训练数据。对模型厂商来说这是把固定成本变成边际成本的关键一步。全模态输入随便混输出带声音H3 的另一个卖点是全模态。它的输入可以接受文本、图像、视频、声音的任意组合输出是一段带原生双声道音频的视频最高 15 秒、2K 分辨率。举官方演示里的例子输入一段参考视频、一张人物图片和一段歌声录音用自然语言告诉模型你要什么H3 就能自己把三样东西捏合成一段完整的视频。以前这个流程需要至少三个工具、两次人工导出导入现在是一句话的事。音频同步生成是容易被低估的点。市面上一大半视频模型只出画面不出声声音要靠 TTS 和音效库后期拼对齐永远是手工活。H3 把声音作为输出的一部分原生生成双声道直接给到后期的工作量直接少掉一块。对内容创作者来说这意味着生产链路从「画面、声音、字幕三个流水线」收敛成「一个模型」。收敛的不只是操作步骤还有出错的可能性。过去三个工具之间的格式转换、时间轴对齐、参数调优是出错率最高的环节这些环节现在整个消失了。还有一个很多人没注意到的点全模态输入意味着 H3 可以吃参考视频做风格迁移可以吃参考音频做人声克隆式的配音可以吃产品图做商品视频。输入的组合方式越自由能覆盖的生产场景就越多一个模型吃掉一整条后期工作流的可能性就越大。H 系列与 M 系列MiniMax 的双线布局理解 H3不能只看它自己还要看它在 MiniMax 整个产品矩阵里的位置。MiniMax 目前有两条模型线M 系列管文本和推理H 系列管生成。上个月发布的 M3 是文本线的旗舰这次的 H3 是生成线的旗舰。两条线不是各干各的。官方明确表示后续计划把 H 系列和 M 系列的能力融合——H 管生成M 管理解和推理两者合流之后才是完全体。这句话翻译成产品语言就是未来的模型既能听懂复杂的意图又能把意图变成高质量的视频中间不需要用户在两个模型之间手动搬运。这个布局和 OpenAI、Google 的路线有本质区别。后者的多模态是把图像、视频能力塞进同一个大模型MiniMax 则是用两条线并行演进各自优化最后合流。两种路线哪个更快走到头现在下结论还早但 MiniMax 的选择更符合它的资源禀赋文本和生成分开训练每一块的训练成本都更低迭代节奏也更快。对开发者来说这个布局意味着两件事。第一现在接入 H3 的代码在 M 系列合流之后大概率还能用接口是兼容的第二选型的时候不用在两个产品线之间二选一可以先用 H3 把生成场景跑起来等合流版本出来再整体升级。视频后期行业真正的冲击在字幕和特效岗H3 的技术参数聊完了最后说点跟饭碗有关的事。视频后期行业是这次冲击最直接的承压面而压力最大的不是剪辑岗是字幕动画和特效岗。传统视频后期里字幕动画是最费人工的环节之一。一个花体字标题动画从字体设计、逐帧动画、入场出场节奏到和画面同步熟练的后期师也要做一两个小时。H3 用一句话就能生成带动态字效的画面还支持手绘风格特效这正好打在字幕动画师的工作核心上。当然说「岗位消失」还为时过早。H3 目前的字效生成还局限在固定几种风格复杂定制、品牌规范、多层合成仍然需要人工。但成本结构的变化是真实的以前一个字幕动画的报价可能是几百块现在模型生成的基础版可能只要几分钱人工只负责最后润色。这意味着低端字幕动画的需求会被大幅压缩从业者要么往创意和定制方向走要么往模型调优方向走。对内容公司来说这件事的另一面是产能重构。以前一条营销视频要排三天期等后期做字幕和特效现在生成阶段就能把字幕带出来后期只用做审片和微调。排期缩短意味着同样的团队能产出更多的内容这是行业层面的效率提升不亚于当年数字剪辑取代线性剪辑。接入实战一段真正能跑的代码光说不练没有意义。H3 走的是 OpenAI 兼容的 API 格式这意味着你不需要引入新的 SDK用现成的 openai 客户端就能接。下面是完整可运行的示例输入一张商品图和一句描述输出一段带配音的 2K 视频。import base64 import time from openai import OpenAI client OpenAI( api_keyYOUR_API_KEY, base_urlhttps://api.minimax.io/v1 ) def encode_image(path: str) - str: with open(path, rb) as f: return base64.b64encode(f.read()).decode() resp client.chat.completions.create( modelminimax-h3, messages[{ role: user, content: [ {type: text, text: 生成一段 8 秒视频产品缓缓旋转 背景从深蓝渐变为暖金画面中央浮现 品牌名『AURORA』的金属立体字效 配一句低沉的中文旁白}, {type: image_url, image_url: { url: fdata:image/jpeg;base64,{encode_image(product.jpg)} }} ] }], extra_body{resolution: 2k, audio: True} ) video_url resp.choices[0].message.content print(视频地址:, video_url)这段代码有三个值得注意的点。第一输入消息里文本和图片可以混在同一组 content 里多模态是原生支持的不需要分两次请求。第二音频参数直接在请求体里打开不需要再走一遍 TTS 再手动对齐。第三请求是同步阻塞的长视频生成可能要等几十秒生产环境记得开异步任务或加超时重试。如果把这段代码放进一个批量生产管线你只需要在外面套一层循环遍历商品图列表每条生成一段视频把结果统一归档。全模态的输入设计让整个管线只需要维护一份调用代码这是它和传统多工具链路最本质的区别。当然代码里的 API Key 要换成你自己的模型名以官方文档为准。但这个接入模式的形状不会变一个客户端、一个模型、一次请求。开源这张牌国产芯片兼容是最实在的一条H3 宣布开放权重这在视频生成赛道里是少数派。头部视频模型几乎全部闭源权重只租不卖开发者想在上面做二次开发只能贴着 API 走。开源带来的连锁反应值得逐条算第一成本可控权重在自己手里推理成本只跟算力走不跟供应商的定价策略走第二可定制训练数据、LoRA 微调、风格迁移都可以自己做API 模式里这些都是黑盒第三数据安全视频素材往往涉及商业机密本地部署意味着素材不出内网。其中国产芯片兼容这一条对国内开发者尤其重要。官方明确考虑了国产芯片的适配这意味着部署不需要绑定特定厂商的硬件生态。对于一个要长期跑生产任务的团队这一条往往比纸面性能数字更值钱。当然开源不等于是免费的。权重下载之后2K 视频的推理对显存和算力的要求是实打实的团队需要自己评估本地跑还是 API 跑。算账的时候把电费和 GPU 折旧算进去结论未必是本地更便宜。举个具体的例子。假设团队每天要生产一百条十五秒视频每月按三千条算。用 API 按 H3 的定价这笔账每个月可能只要几百美元边际成本几乎可以忽略。如果换成自部署一张能跑 2K 视频推理的高端卡采购价按十几万人民币计折旧加电费摊到每个月是好几千块还要算上运维人力。除非你每天的生产量再放大一个数量级或者对数据隐私有硬性要求否则自部署在账面上未必划算。所以开源权重最大的价值短期内不在省钱而在选项本身。它给了团队一条后路定价策略调整了或者某个场景的用量突然暴涨你随时可以把推理迁回本地不被任何一家供应商绑架。这种选择权在闭源体系里是花钱也买不到的。短板要认H3 还不是万能模型把亮点说完短板也得摆上台面。H3 目前的多模态上下文理解还不够深画面精细度相比头部闭源模型仍有差距模型规模也偏小。这些不是贬低是客观现状。具体到场景上复杂长镜头、多人交互、高速运动场景H3 的稳定性和 Seedance 这类成熟产品比还有距离。官方自己也承认后续计划把 H 系列和 M 系列的能力融合——H 管生成M 管理解和推理两者合流之后才是完全体。所以现在该不该上车取决于你的场景。如果是商品展示、UI 动效、字幕动画、短视频批量生产这类对精度要求可控的场景H3 的成本优势是实打实的现在就可以测。如果是电影级长镜头、复杂叙事建议再等一轮迭代。给开发者的三件事最后整理成可以直接执行的三件事。第一去官方文档把 API 的鉴权方式和模型参数看一遍用上文代码跑通一个最小示例把 2K 和 768P 两条成本线记下来。第二盘点你手里现有的视频生产链路找出其中可以被单模型替换的环节——参考视频、图片、旁白、字幕能混给一个模型的就不要拆成三个工具。第三把权重开源的发布时间加进你的技术选型日历权重落地后用本地推理跑一遍同样用例对比延迟和成本再决定生产环境用 API 还是自部署。MiniMax H3 的意义不在于它是某一项指标的冠军而在于它第一次把「全模态、带声音、2K、开源、低成本」这五个词放进了同一个模型里。每一个词单独拿出来都不新鲜但五个词同时成立说明视频生成的成本结构真的到了拐点。
)
