AREXOpen in interactive Feed

AREX Feed Article

MiniMax 官方盘点 H3 开源生态:FastH3 4 步蒸馏版已能在 DGX Spark 与 Apple Silicon 上运行

September 14, 2026

9 月 14 日,MiniMax 的官方 X 账号发帖,把 H3 视频生成模型近期的开源生态进展集中列出:FastH3、Sol-H3、VDN、PDD 与 LightX2V,并在文末点名致谢一批团队账号与个人贡献者()。帖文以「开放权重,共享进展」开头,称开源社区正在让 H3 的能力「更快、更易获得、更容易在其上构建」。

被 MiniMax 放在第一位的是 FastH3:由 FastVideo、Nuva Lab 与 NVIDIA 合作,把 H3 蒸馏到 4 步,现已能在 NVIDIA DGX Spark 与 Apple Silicon 上运行。帖文对它的描述只有一行;FastVideo 团队在 8 月底与 9 月初的两篇发布博客里给出了完整细节。

FastH3:蒸馏、稀疏注意力与本地化条件

FastH3 是 FastVideo 对 H3 做的后训练与优化版本:用少步蒸馏把 H3 的去噪调度压缩成 4 次 transformer 调用,再叠加视频稀疏注意力(Video Sparse Attention)与一系列推理工程优化()。作为底座的 H3 是 MiniMax 已开放权重的视频模型:可生成最长 15 秒、24 FPS、默认 768 像素短边的视频,并同步输出 32 kHz 立体声()。

本地化细节来自 9 月 2 日的团队博客:FastH3 可以跑在最多 2 台 DGX Spark 上,也能通过 MLX 在 Apple Silicon 上运行,Mac 路径需要 36 GB 及以上的统一内存;两台 Spark 能用 QSFP 链路合跑同一次生成()。速度方面,博客对比了公开的 vLLM-Omni DGX Spark 配方:同一台机器上,1024×576、5 秒、50 步的一次请求耗时 1,881 秒,FastH3 以 4 步在 268 秒完成,约 7 倍;博客摘要给出的总体口径是「最高 8 倍」。

FastH3 Preview v1 在 8 月 27 日发布,推荐检查点为「4-step VSA / Data-Free」,同时提供完整权重与预提取的 LoRA(低秩适配器)()。FastVideo 在博客中说明,这项工作与 Nuva Lab、NVIDIA FastGen 团队(Julius Berner、Chao Liu、Arash Vahdat)以及 NVIDIA Enterprise Products 团队合作完成;Nuva Lab 则说明了自己的分工:把真实创作负载、评估标准与端到端生产反馈带进合作。

Sol-H3:15 秒输出压到 6.6 秒,口径写进脚注

Sol-H3 来自 NVIDIA 团队。MiniMax 帖文称其来自「NVIDIA 的 SANA 团队」;项目页自己的署名是「NVIDIA Research, Efficient AI Team & Singapore Lab」,页面挂在 NVlabs 的 Sana/Sol-Engine 路径下()。

按项目页的描述,Sol-H3 是 Sol-Engine 与 Sol-Attn 组成的一体化推理栈:Sol-Attn 在运行时按查询动态挑选需要精确计算的注意力块,其余块用池化摘要近似,整个过程不需要重新训练;此外还有算子融合、8 卡通信优化(QKV 走 INT8、注意力输出走 FP8)、并行 VAE 解码、AdaLN 预计算缓存等优化。

数字集中在 8 卡 B300 上:15 秒、1344×768、24 FPS、带立体声的完整输出耗时 6.612 秒;作为对照,50 步的 Base H3 dense(全注意力)配置在同一系统上需要 99.513 秒,Sol-H3 比它快 15.05 倍。5 秒与 10 秒输出分别为 1.653 秒与 3.732 秒;1 卡、4 卡、8 卡三个配置的加速区间为 9.45~15.54 倍。

这些数字的测量口径是:一次预热后取三次运行的中位数;计入文本编码、DiT 去噪、音视频 VAE 解码;不计模型加载、编译预热与最终 MP4 编码。所有运行都是 1344×768、24 FPS、同一条提示词与随机种子、无参考的 T2VA(文本到视频+音频)设定;页面还专门注明,这是完整流程的对比:基线是 50 个调度点、49 次 DiT 前向,Sol-H3 是 4 次前向,「不是只换注意力的运行时改动」。MiniMax 配图里的星号脚注写着同样的边界:warm inference(预热后推理),不含模型加载、编译与 MP4 编码。

两条与生态有关的细节:Sol-H3 默认使用的正是 FastH3 的 4 步适配器,项目页在致谢中列出了 Hao AI Lab;9 月 7 日,Sol-H3 作者之一 Enze Xie 在 X 上补充说,代码以 Apache 2.0 发布,任何 H3 的少步 LoRA 都能接入同一个引擎,并称已与 Reactor 合作,让 Sol-H3 在首发当天以 API 上线()。配图里的「NOW ON DGX SPARK」对应项目组的另一个页面:在单台 DGX Spark 上,两阶段管线先用 FastH3 出 384p 草稿,再由 Lightricks 的 LTX-2.5 精修到 768p,两阶段之间用学习到的 VAE 适配器直接搬运 latent(潜空间表示),跳过像素空间往返()。

VDN:近处用 softmax,远处换线性注意力

VDN(Video DeltaNet)由 Haocheng Xi 与 OpenVDN 团队完成;MiniMax 的概括是「重新设计注意力,让 H3 推理更快;权重、训练与推理代码均已发布」。项目页给出的动机是:在 H3 这类长序列模型上,softmax 注意力占总运行时间的 85% 以上()。

VDN 的做法是把视频与视频之间的注意力拆成两条支路:局部帧组保留滑窗 softmax,逐帧精确保留短期细节;长程上下文交给一条双向线性注意力分支(Video Delta Attention),用帧级 delta 规则一次解出该帧要写入的状态。两条分支的输出尺度不同,项目组用内容相关的 sigmoid 门控加权后再相加。训练分三层推进:先逐层校准新分支,再端到端适配,最后联合训练分支与挂在 QKV、O 投影上的 LoRA,主干权重全程冻结。

结果方面:在 8 张 B200、8 步去噪的设置下,VDN-H3 生成 14.4 秒的 768p 片段耗时 11.23 秒;相对单卡 dense 基线加速 74.5 倍,相对 8 卡 dense 基线仍有 10.7 倍,并称画质「接近无损」。发布内容包括约 82 GB 的权重(H3 基础权重加 50 步、8 步两个阶段)与训练、推理代码()。8 步模型是从社区的 MiniMax-H3 turbo LoRA 出发、用 DMD2 继续蒸馏得到的;项目页写道,他们「刻意避开激进的 4 步设置」,把质量排在延迟前面。

9 月 2 日公布时,Haocheng Xi 在 X 上的说法是「开源视频生成现在比播放还快,而且不牺牲质量」()。

PDD 与 LightX2V:低步数 LoRA 的两条路线

PDD 这一项由 Alibaba PAI 完成:他们把 Parallel Decoding Distillation(并行解码蒸馏)用到 H3 上,发布 8 步的 FL2VA 与 Ref2VA 加速 LoRA,rank 为 64()。MiniMax 在帖文与配图中把它概括为「NVIDIA 的蒸馏方法,由 Alibaba PAI 引入 H3,做成 8 步 Acc-LoRA」;帖文里那句「现获 ComfyUI 支持」,对应的是 9 月 9 日 ComfyUI 更新日志的新条目:加载「MiniMax-H3 PDD LoRA」以加速 H3 采样()。

LightX2V 则从框架一侧切入。这个由 ModelTC 维护的推理框架从 8 月 7 日起支持 H3 的完整推理,覆盖 T2AV、I2AV、L2AV、FL2AV、Ref2AV 五类工作流,并带模型与块级卸载、张量和序列并行、量化 DiT 推理与特征缓存;8 月 11 日发布 4 步 768p 蒸馏 LoRA,配置为 1344×768、无 CFG 的 4 步推理;8 月 27 日又发布 8 步 v1.0 版本,称音画质量进一步提升()。MiniMax 对这项工作的描述是「4 步与 8 步 Turbo LoRA,以及面向文本、图像与参考条件视频+音频的工作流」。

快了多少:三套数字,三种口径

这些基准数字来自各团队自己的页面,测量方法与使用的硬件并不相同。

Sol-H3 与 VDN 都在页面上写清了边界。前者的口径是 warm inference,取三次运行的中位数,不含模型加载、编译与 MP4 编码;后者的口径是稳态去噪,不含加载、预热、VAE 解码与 MP4 转换。VDN 页面还建议,实际部署时把提示词重写、VAE 解码和 MP4 转换放到其他机器,让 8 张卡只做去噪。FastH3 的本地数据则来自 FastVideo 团队在单台或双台 DGX Spark,以及一台 36 GB 统一内存的 M4 Max 上的对比测试;Nuva Lab 在页面里专门标出「证据边界」:这些是公开发布的结果,不是普适的性能声明,质量与延迟仍取决于具体检查点、负载、硬件与完整媒体链路。

这些数字均由相关团队自行发布;MiniMax 的帖文是对这些工作的汇总与致谢。

致谢名单、社区索引与许可边界

帖文把致谢分成两组:一组是团队与项目账号:@haoailab、@nuvalab、@NVIDIAAI、@xieenze_jr、@HaochengXiUCB、@ArashVahdat、@julberner、@LightX2V、@ComfyUI,共九个;另一组是「推动工作前进的个人贡献者」:@haozhangml、@cxlcl1、@lawrence_cjs、@yitongli165665、@haopengl33、@songhan_mit、@shanasaimoe,共七位。帖文里的一句话是:「每个发布的背后,都有人在训练、优化、量化、测试和分享。」

帖文末尾的「Explore the ecosystem」链接指向 GitHub 仓库 MiniMax-AI/awesome-minimax-h3-integration:一个「由社区维护的 H3 checkpoint、工具与工作流索引」,仓库创建于 8 月 13 日()。仓库按用途组织内容:官方资源、按显存挑选推理栈、ComfyUI 节点与工作流、Turbo LoRA 等;它同时声明自己「不是完整的兼容性列表」,其中的社区量化文件「不是 MiniMax 官方发布」。

「开放权重」之外还有一层写到项目页面里的限制:Nuva Lab 与 OpenVDN 的页面均注明,H3 及其衍生模型适用 MiniMax H3 Community License,默认适用地域不包含美国、欧盟、英国与韩国,处于排除地域的部署者需联系 MiniMax 获得授权;ComfyUI 的 H3 教程页则写明,本地生成内容的商用需要 MiniMax 商业许可()。

参考链接