MiniMax 官宣 NVIDIA Sol 团队 H3 加速:5 秒视频 1.653 秒生成并开源

北京时间 9 月 8 日 0 时 58 分(UTC 9 月 7 日 16:58),MiniMax 官方 X 账号(@MiniMax_AI)发推宣布,「NVIDIA Sol 团队」为开源视频模型 MiniMax-H3 推出了新的视频生成加速,声称「快于回放(faster than playback)」「完全开源(fully open-sourced)」,并已接入 Reactor API,「让你在投入自己的 GPU 之前先试一试」()。这条推文没有附带任何基准数字、仓库地址或实现说明。

具体数字出现在 26 分钟前 NVIDIA 一侧的发布里。UTC 9 月 7 日 16 时 32 分,研究 Sol-Engine 方向的 NVIDIA 成员 Enze Xie(账号 @xieenze_jr,其简介自称 NVIDIA Tech Lead & Staff Research Scientist,负责 Efficient VideoGen、SANA、Sol-Engine;NVIDIA 项目页的核心贡献者名单亦列其名)发推宣布 Sol-H3:在单台 8 卡 NVIDIA B300 Blackwell 系统上,一段 5 秒、1344×768、带原生立体声音频的 MiniMax-H3 视频,端到端推理耗时 1.653 秒,「五秒钟的世界,1.653 秒完成推理」()。作为对比,50 步的 H3 基线在同一系统上需要 18.250 秒,即提速 11.04×。同一组数字出现在 NVIDIA Research 的上,页面署名「NVIDIA Research, Efficient AI Team & Singapore Lab」;这些数字均为 NVIDIA 单方测量的中位数。

快于回放,从 4 张 B300 起步

Sol-H3 的完整测速按 GPU 数量和视频时长分成九格,全部为 1344×768、24 FPS、带立体声的文生视频,页面注明各档使用同一 prompt(提示词)与种子:

配置	5 秒视频	10 秒视频	15 秒视频	相对基线提速
1× NVIDIA B300	13.745 秒	37.813 秒	52.260 秒	9.45×～14.29×
4× NVIDIA B300	2.918 秒	6.993 秒	12.542 秒	12.11×～15.54×
8× NVIDIA B300	1.653 秒	3.732 秒	6.612 秒	11.04×～15.05×

提速的相对基数是同配置下的 50 步 Base H3 Dense(8 卡基线:5 秒 18.250 秒、10 秒 50.660 秒、15 秒 99.513 秒)。「快于回放」在 4 卡和 8 卡配置上成立:生成一段 5 秒视频分别耗时 2.918 秒和 1.653 秒,都短于视频本身的播放时长;单张 B300 上则不成立,5 秒视频仍要 13.745 秒。

测量口径写得很细:每个数字是预热后三次运行的中位数;计时包含文本编码、DiT(Diffusion Transformer,扩散 Transformer)去噪与音视频 VAE(变分自编码器)解码,不含模型加载、编译预热与最终 MP4 编码。Enze Xie 特别强调,这是完整配置档(full-profile)的对比:基线用 50 个采样点(49 次 DiT 前向),Sol-H3 只用 4 次 DiT 前向,而不是只替换注意力实现。

提速来自流水线每一段的叠加

Sol-H3 的路线是「少步数采样 + 运行时全面优化」。默认的四步适配器来自 FastH3 预览版 v1,项目页在致谢中写明这一适配器出自 UCSD 的 Hao AI Lab,并称任何 MiniMax-H3 的少步数 LoRA(低秩适配)都可以插进同一个引擎。

剩下的加速来自 Sol-Engine × Sol-Attn 五个环节的叠加:

稀疏注意力(Sol-Attn):以 64 token 的查询块为单位,按「均值 + τ × 标准差」的查询自适应阈值决定哪些块保留精确注意力,被跳过的块用池化 K/V 的近似修正补偿;路由、稀疏计算与近似修正共用一次 online-softmax 前向,不需要重训。
融合算子:残差 + RMSNorm + 调制、QKNorm + 部分 RoPE、SwiGLU 三条链路的中间张量留在寄存器或片上,减少显存往返与 kernel(内核)启动。
多卡通信:按目标 GPU 直接打包 Q/K/V,一次 all-to-all 完成交换;最快档位用 INT8 QKV 与 FP8 注意力输出传输,BF16 传输仍可选用。
并行 VAE 解码:一段 5 秒输出含 7 个时间片段、196 个空间分块(tile),默认把全部分块摊到 8 卡、每卡一次编译好的批量解码调用,再统一回收。
AdaLN(自适应层归一化)预计算缓存:所有 AdaLN 数值在去噪开始前就能算出,一次性缓存整条轨迹后即可释放投影权重。页面称这一步去掉约 400 次小启动、每步省下约 26 GB 显存读取。

开源代码落在 NVlabs/Sana 的 sol-engine 分支

「完全开源」的落点是代码路径:项目页把实现指向 GitHub 仓库 NVlabs/Sana 的 sol-engine 分支下的 models/minimax_h3/Sol-H3 目录(),该路径真实存在;仓库采用 Apache-2.0 许可(),与 Enze Xie 所称「代码在 Apache 2.0 下便于部署」一致。测量用的 prompt 清单也在项目页上随文公开。

需要留意的边界:MiniMax 推文没有给出仓库地址,也没有说明「完全开源」覆盖的范围;目前可核实的开源部分是上述 Sol-H3 代码路径与仓库许可,默认四步适配器来自 FastH3 预览版。页面没有给出画质对比的量化指标,只公开示例视频与逐条 prompt,供使用者对照评估。

Reactor API 让试用跑在买 GPU 之前

API 的提供方是 Reactor Technologies, Inc.(),一个自称「世界模型开发者平台」的实时视频推理服务,目前处于公共 beta。它在 5 月 28 日宣布带着 5,900 万美元融资(Seed 加 A 轮)走出隐身,由 Lightspeed Venture Partners 领投,参投方包括 NVIDIA 自己的风险投资部门 NVentures()。

公告称联合创始人 Alberto Taiuti(CEO,曾任 Apple Vision Pro 技术负责人,此前联合创立 Luma AI 并任 CTO)与 Bryce Schmidtchen(CTO,同样出自 Apple Vision Pro)。

Sol-H3 项目页在致谢里写明 Reactor 的角色是「在线演示托管与部署协作」;Enze Xie 则宣布与 @reactorworld 合作、在发布当天(day-0)就通过 API 提供,并把指向 Reactor 的 sandbox,模型名为 fast-h3。

这正是 MiniMax 推文里「先试一试」所指的顺序:先在 API 上评估质量和速度,再决定要不要拿开源代码自己部署。

两处口径差仍然存在:其一,Reactor 的在说明队列机制时写「在参考部署上,一个片段约以 1.0× 实时的速度生成」,而这次官宣的 1.653 秒对应的是 8 卡 B300 配置;其二,这条官宣与 NVIDIA 项目页都没有说明 Reactor 上实际运行的硬件配置和计费方式(Reactor 只在 5 月公告里声明定价按模型用量计费)。

多个团队先后宣称实时生成或快于回放

MiniMax-H3 于 7 月底发布,是 MiniMax 的通用多模态生成模型:文本、图像、视频、音频作为统一上下文输入,输出带原生立体声的视频,最高 2K、15 秒。发布博客同时宣布「未来数日内开源权重」()。

UTC 9 月 1 日,MiniMax 官号在一篇回顾社区作品的帖子里写道,H3 的开源权重发布「刚满一个月」()。

这一个月里,NVIDIA 同一条产品线已经发布过两版 H3 加速。8 月 3 日上线的方案面向桌面硬件:该页面把 H3 描述为 33B 稠密全模态模型,并把 50 步的 H3 在 DGX Spark 和 RTX 5090 上分别加速 3.92× 与 4.52×,自称「近无损」、不需要蒸馏与 LoRA()。8 月 17 日的 Super Acceleration 在单台 GB200 上把 5 秒 768p 视频的端到端耗时压到 6.852 秒,较 SGLang 基线快 22.2×,页面同时明示「这不是无损加速,与基线并非逐位一致」();6.852 秒的端到端耗时仍慢于回放。

「快于回放」的说法此前已经出现过。UTC 8 月 29 日,MiniMax 官号发文称赞与 fal 合作的 H3 Max,称「快于实时的视频不再只是一个想法」();UTC 9 月 1 日又发文提到基于 vLLM-Omni 与 Hao AI Lab 的 FastH3 的成果,称「实时生成让交互视频成为可能」()。

官宣后约一小时,X 用户 Hayes(账号「Scaling with Hayes」,简介自称分布式系统创业公司联合创始人兼 CTO,公司已被收购)在转发里给出了他的判断:

「要知道,过去几周里围绕同一个模型,已经有好几个团队提出过『快于回放』的说法,加速数字因配置而差异巨大:视流水线不同,从 3.95× 到 20×+ 都有。不过这一次确实开源,所以你至少可以自己验证,而不是凭信仰接受一个数字」()。

剩下的问题:这份测速能否复现

账号 Atlas Frontier(自称关注基础设施瓶颈)在回复里提醒:「快于回放只有在全栈成立时才有意义:模型、显存、互联与供电。交互式视频既是模型问题,也是基础设施问题」()。

中文用户 VastPlan 赞同官宣的试用顺序:「先 Reactor 试一遍再占 GPU,这步对。加速开源比口头更快,回放速度先过关」()。

NVIDIA 项目页把下一步研究方向写成 24 FPS 的连续流式生成与交互式生成:让生成以块为单位连续推进,并在播放中响应新的输入。代码与测量条件已随发布公开,谁能在别的硬件、别的 prompt 上复现这份测速,是这条消息的下一个可验证节点。