MiniMax 官推喊话：H3 本地推理太慢？试试 Sol Engine

2026 年 8 月 11 日，MiniMax 官方推特账号发了一条推文："如果你被本地 MiniMax H3 模型的推理速度困扰，这大概就是你缺的东西。"推文第二句直接点出答案："社区爱 Sol Engine——感谢你们点燃了那么多 GPU、让大家感到 GPU 富足"（"The community loves Sol Engine—thank you for setting so many GPUs on fire and making people feel GPU rich"）。

一家模型公司公开推荐用户去用另一家公司的优化工具来解决自家模型的速度问题，并且用的是社区 meme 式的口吻：不是"我们与 NVIDIA 合作"，而是直接对 Sol Engine 这个具体的开源优化引擎说谢谢。这不多见。

截至当天，这条推文获得了 109 次点赞、10 次转发和约 9,700 次浏览。在回复中，有用户写道"GPU rich 这个词太准了"（），也有人表示"调了好几天参数还是很慢，今晚就试这个"（）。

但 Sol Engine 的社区口碑早在 MiniMax 官推开口之前就已建立。从 MiniMax H3 模型权重放出那天起，Sol Engine 的故事就是一场速度竞赛。

一个 33B 的全模态模型，压在单张显卡上

要理解 Sol Engine 为什么成为"缺失的那块拼图"，先得看清 MiniMax H3 到底是个什么东西。

7 月 31 日，MiniMax 了 H3（内部代号 Hailuo 3.0），一个 33B 参数的全模态生成模型。它接收文本、图像、视频、音频作为统一的上下文输入，输出 4-15 秒、最高 2K/24fps 的视频，并且在同一轮前向传播中合成原生 32kHz 立体声音频：对话、音效、环境声与画面同步生成，不是事后配音。

这种"音画同源"的设计是 H3 最特别的地方，也是它最贵的地方。根据 NVIDIA Sol Engine 团队在中的分析，attention 需要跑在视频和音频的联合序列上，序列长度足以主导整个计算 profile；33B 参数中约有 13B 分布在 AdaLN 分支上，每个去噪 step 都要触发一遍；而参考实现是用 BF16 写的，追求清晰而非速度。

未经优化的参考实现在单张 RTX 5090 上跑一段 720p、5 秒、50 步的视频，基线耗时 1,045 秒，超过 17 分钟。这个数据来自 NVIDIA 自己的测试环境，且运行的是 H3 原始 checkpoint，未经蒸馏、微调、LoRA 或离线校准。

4.5 小时：从 GB200 到 RTX 5090

8 月 3 日，H3 权重释出仅数小时后，NVIDIA 的 Sol Engine 团队就放出了第一组数据。

NVIDIA 研究员 Enze Xie 在中宣布：Sol Engine 在 4.5 小时内完成了对 MiniMax H3 的全栈优化，在 8×GB200 上实现了 3.95× 端到端加速（对比 Diffusers），以及 2.80× 对比 SGLang 的加速。Xie 在推文中写道："我们特别高兴看到像 MiniMax H3 这样强大的开源模型被发布给社区。开源模型对于推动视频生成研究、系统优化和实际部署至关重要。"

NVIDIA Sol Engine 技术页面，通常一个新模型的推理优化需要数周的手动调参：模型、硬件、分辨率、帧率的组合不同，recipe 不能直接迁移，每个部署都要逐案调整。Sol Engine 用自动搜索替代了手调，kernel、稀疏注意力、缓存三条轴并行扫参，再由 integrator 做组合搜索，把数周压缩到了一个下午。

两天后，8 月 5 日，Sol Engine 的桌面版优化：DGX Spark 上 3.92× 加速（480p、5 秒、24fps），RTX 5090 上 4.52× 加速（720p、5 秒、24fps）。RTX 5090 的基线从 1,045 秒压到了 231 秒，从超过 17 分钟降到不到 4 分钟。

三层加速是怎么叠出来的

Sol Engine 的加速配方由三个 Pillar 叠加而成，每个都在前一个的基础上继续乘倍数。

Pillar 1，无损 Kernel 融合。参考实现中大量时间消耗在 HBM 往返上：小算子把中间结果写回显存、下一个算子立刻读出来。Sol Engine 将多个 elementwise 操作融合成单个 kernel，在寄存器和共享内存中保持中间值。对 H3 最关键的融合是 fused RMS-AdaLN，因为 H3 有 13B 参数在 AdaLN 分支上，这个融合消除了调制分支上的显存往返，是整个优化中最大的一笔"免费收益"。再加上 QKV 合并（三道瘦 GEMM 合成一道宽的）、GEMM+GELU 融合，以及 torch.compile 图捕获。在 RTX 5090 上这一步从 1,045 秒降到 972 秒，看起来只有 1.08×，但这是因为 RTX 5090 的显存带宽相对充裕；在 DGX Spark 上同样的 kernel 优化直接砍掉了近 200 秒。

Pillar 2，跨步缓存（Cross-step cache）。在去噪轨迹的中段，相邻 step 的 transformer 输出极为相似。模型在做微调，不是在做决策。Sol Engine 用 First Block Cache 作为门控：监控第一个 transformer block 产出的残差，如果它与上一步相比几乎没有变化，就跳过剩余 block，直接复用前一步的输出。一个标量阈值控制"多相似算够相似"。这个 Pillar 是最大的单一加速来源：在 RTX 5090 上从 708 秒直接拉到 231 秒，DGX Spark 上从 451 秒拉到 181 秒。

Pillar 3，Sol-Attn，免训练稀疏注意力。视频扩散模型中的 attention map 极度稀疏，大部分 query block 只对少数 key block 有意义的关注。Sol-Attn 不依赖训练或离线校准，它将 block 选择折叠进 online-softmax 过程中：每个 query 行从自身 block proxy 分数的统计量中推导出阈值（τᵢ = μᵢ + βσᵢ），无需逐层调度；被拒绝的 block 的贡献通过泰勒展开近似回收，所以即使在高稀疏度下质量也不会断崖式下跌。

三条 Pillar 不是独立串行。它们会互相影响（缓存改变了稀疏注意力需要服务的 step），所以 Sol Engine 的核心设计是一个 agent-native 的自动搜索框架：kernel、稀疏注意力、缓存三条轴并行搜索，各自扫自己的参数空间，然后由 integrator 在组合层面做搜索，人类验证者签收最终输出视频。整个过程对 H3 来说只用了 4.5 小时。

社区跑得比官方快

在 MiniMax 官推发声之前，Sol Engine 已经被社区验证了整整一周。

8 月 4 日，ComfyUI 社区用户 keys（）在单张 DGX Spark 上跑通了 Sol Engine + MiniMax H3 的完整 workflow，把每步时间从 28.2 秒压到 12.5 秒，并把整个配置。这条推文获得了近 15,000 次浏览和 89 次点赞。

8 月 5 日，RyanLee（MiniMax 开发者关系负责人）发了一条，详细罗列了社区在 48 小时内为 H3 搭建的完整生态：从 ComfyUI 原生支持、Diffusers pipeline、SGLang serving、到 Sol Engine 加速、Sage Attention、EasyCache。他在"加速"一栏中专门标注了 NVIDIA SANA 团队的 Sol Engine，称其实现了"3.95× 端到端，无质量折损"。

8 月 6 日，前 DoorDash、Uber 工程师 Miki Ovshievich（）报告了他的组合加速方案：EasyCache（1.45×）叠上 Sol-Attn（1.24×），总计约 1.8× 加速，而且原生 768p 终于能塞进他 16GB 显存的显卡里了。他特别致谢了 NVIDIA Sol Engine 团队为两项技术提供的思路。

8 月 8 日，用户 Sean Rotramel（）在同一张 RTX 5090、同一个 H3 模型、同一段 720p 剪辑上做了头对头对比：Sol Engine 160.4 秒 / 29.2 GiB，ComfyUI 开源方案 161.9 秒 / 28.7 GiB，几乎打平。"免费方案追上了官方方案，"他写道。

也有用户报告了不同的体验。Medium 作者 Andrew Zhu 在中表示，Sol-Attn 在他的测试中"降低了质量——人脸细节有微妙的损失"，他最终选择了 Sage Attention + EasyCache 的组合，获得了超过 100% 的速度提升。

官方认账的分量

MiniMax 这条官推发生在 H3 权重释出后的第 11 天，Sol Engine 桌面版上线后的第 6 天。社区已经把 Sol Engine 跑透了、测遍了、开源了，MiniMax 的官方推荐是追认，而非预告。

但追认本身有意义。开源模型的生态中，模型厂商和工具链厂商之间往往隔着一层礼貌的距离。你发你的模型，我做我的优化，彼此在博客和推文中互相感谢，但很少有一方的官号直接对用户说"就用那个"。MiniMax 打破了这层距离，而且用的不是正式的合作公告语气，而是社区 meme 式的措辞。

对 MiniMax 而言，H3 的"慢"是一个真实的产品问题。一个 33B 的全模态模型在本地单卡上跑到让人愿意等，这是开源生态能否真正落地的关键门槛。Sol Engine 帮它迈过了这道门槛，MiniMax 选择公开认账，而不是假装问题不存在。

对 NVIDIA 而言，Sol Engine 从 H3 身上拿到了它最想要的东西：一个高关注度的开源模型作为"快速优化"的展台。H3 之前，Sol Engine 已经，H3 是第四个。但 H3 是社区反响最热烈的一个。它的"慢"太明显了，Sol Engine 的效果立竿见影。

MiniMax 官推提到的"社区爱 Sol Engine"，在数据上可以得到印证。Enze Xie 的 Day 1 推文获得了 49,000+ 次浏览和 416 次点赞；keys 的 ComfyUI workflow 获得了 13,800+ 次浏览；RyanLee 的 48 小时生态总结获得了 47,900+ 次浏览。

这条官推本身没有宣布任何新产品、新合作或新版本。它只是说了一句实话：我们做的模型，单卡跑得慢，他们做的工具能解决，去用。