吹爆开源！RunningHub让MiniMax H3满血提速12倍，本地部署照样起飞

admin

闻乐 发自 凹非寺

量子位 | 公众号 QbitAI

MiniMax H3是真强也是真火啊。

开源还能打，在AI视频圈也算是独一份了。

模型底座强成这样，开发者们自然也闲不住，开始琢磨怎么把它玩得更爽。

所以MiniMax前脚刚把H3开源，后脚各种工作流、ComfyUI节点、垂直优化玩法就已经冒了出来。

这不，一站式AIGC创作平台RunningHub就盯上了一个大家都特《急急急》的事儿：

让H3跑快点。

咋说呢，模型越好用人越忍不住多抽几次，结果一抽一个大等待。

灵感一上头，创意改起来只要十几秒，下一版都已经在脑子里剪完了，结果屏幕上的这一版还在转……

于是乎，RunningHub干脆给H3踩了脚油门，直接朝着等待时间砍了一刀。

同样生成5秒、1344×768的视频，在4张RTX 6000D上，原始BF16 50步方案耗时348.8秒，差不多6分钟。

RunningHub H3 Lightning完整加速之后，只需要28.7秒。

好家伙，前后约12倍提速，生成耗时减少约92%，却依旧能保留BF16数值精度。

现在，RunningHub已经把整套玩法放GitHub上开源了，任何创作者都能开箱即用！

（https://github.com/RH-RunningHub/MiniMax-H3-MultiGPU-Lightning/）

不光是5秒视频，就算是15秒、双参考图，RunningHub H3 Lightning依旧能给你猛猛提速。

在8张RTX 6000D环境下，让H3做一个15秒、分辨率768×1344的视频，纯文字生成大约需要48秒、双参考图生成约73秒。

也就是说，一条15秒的图生视频，可以打进“1分钟出结果”这个时间尺度了。

而且在RunningHub H3 Lightning这儿，AI加速可不等于质量劣化。

整套加速方案还全程保留BF16满血精度，没有走降精度换速度的“捷径”。

一个本来就已经很能打的模型，又被狠狠优化了一波，咱必须得体验一把！

我先试了一个5秒、768P的文生视频，直接来个大动作。

场景放在沙漠，一个女越野摩托车手原地起步，随后高速冲上沙丘，腾空、落地，再接一个大幅甩尾。

嫌这还不够，我又给镜头加了点活儿。

先低机位侧面追车，随后绕到正面倒退跟拍，最后让摩托直接从镜头旁边冲过去。

从点击生成到出片的实际用时约为30s，人、车、沙尘的运动逻辑挺连贯。

落地的时候车身有明显的下沉和回弹，骑手的重心也跟着往下压了一下，还有尘土的飞扬看着也挺真实。

我预设的机位也都安排妥了。

其实，除了画面质量高之外我最大的感受是，等待间隙我甚至都没刷完一个某音视频……

确实是丝滑。

不过5秒还是短，咱还得上强度。

再试试15秒的图生视频，这次我喂了一张吉卜力风格的参考图。

原本是一人一狗背对着镜头坐在草地上，现在咱让他俩跑起来。

少年从草地上起身，直接向山坡前方奔跑；金毛也得跟着起来，一边跑一边跳；少年中途还要张开双臂、转身继续跑。

镜头从背后推进，再切到侧面跟拍，最后拉远，把整个山谷重新带进画面。

15秒长视频的生成时间就比较久了，从点击到出片大概88秒。

从坐着到起身，再到迈步加速，动作之间有比较明显的衔接；金毛也没有沦为一张跟着人物平移的贴纸，自己完成了起身、奔跑和跳跃。

更关键的是，15秒跑下来，这一人一狗还基本是原来那一人一狗。

少年的黄色外套、蓝色裤子、黑色头发这些主要特征一直都在，金毛的体型和毛色也没有跑到后半段突然换了个品种。

而且镜头转完一圈后，远处的湖泊和夕阳依旧在画面中。

当然了，你要是真盯着看也还是能挑出毛病。狗在快速跳跃时，四肢动作偶尔会有点“硬”，但是倒也不会特别出戏。

本来打算收工了，我又突然冒出来一个想法，晴天不要了，给我下雨。

没错咱创作的时候灵感就是嘎嘎跳跃！

少年得站起来撑伞，在草地上跑，再突然停下转一圈；金毛继续绕着他跑，还得从旁边跳过去。

与此同时，原来的远山和湖泊还得留住。

二次创作的时间变短了，也就50秒左右，最后画面远处还出现了一抹彩虹～

之前想改个人物、场景、镜头啥的，动手之前可能会考虑考虑值不值得再等很长时间。

现在不用愁了，有了灵感就能快速出片。

对很多创作者来说，创意落地、试错的时间成本都降低了，也不用因为漫长等待就砍掉很多一闪而过的想法。

那么问题来了，不降BF16精度，也不开挂顶级数据中心算力，RunningHub抠出来的时间，到底是从哪儿省出来的？

快，自然是用工程抠出来的，解法是很工整的三刀——

先看看哪里算得太多，再看看哪里算得太慢，最后看看几张GPU之间有没有时间浪费在“互相等”上。

第一刀，先从模型本身动手，让H3少算一点。

视频生成不是模型看完Prompt，啪一下就直接把最终画面吐出来。

它需要一轮一轮地把画面“想”出来。

把文字或者图片变成视频需要经过多轮计算，画面才会逐渐从噪声中成形，这个轮次叫生成步数。

原始H3推理默认50步，每一步背后都有一轮实打实的计算，步数越多，GPU自然就得干得越久。

RunningHub做的第一件事，就是引入自研的RH后训练加速模型。

简单点说就是让H3经过后训练之后，学会用更少的步数把视频做出来，还得在不丢画质的前提下完成。

这一步的效果已经相当明显。

同样使用4张RTX 6000D生成5秒视频，换成RH后训练加速模型的9步测试方案之后，时间直接缩短到了43秒。

第一刀下去，已经提速了8倍。

顺便说一句，RunningHub的推荐配置是默认4步；

遇到快速运动、大幅动作这类难任务可以切到8步，快还是稳，咱创作者自己来决定。

做到43秒，按理说已经挺猛了，但RunningHub显然还嫌慢。

模型虽然少算了，可剩下这些必须完成的计算，总不能就这么放着吧。

RunningHub接着想解决的是，剩下这些必须完成的计算，还有没有地方能继续省时间？

于是第二刀开始往执行层里砍。

这次一口气上了三个技术组合，SageAttention2、Cache-DiT和torch.compile。

SageAttention2盯的是注意力计算。

视频模型每生成一段内容，都需要处理大量画面元素之间的关系。

谁和谁相关、前后画面怎么联系、不同信息怎么共同影响最终结果，这些注意力计算本身就是推理过程中相当吃算力的一环。

SageAttention2要做的就是让这块核心计算执行得更高效。

Cache-DiT则开始盯着重复劳动。

视频生成前后多个计算步骤之间存在可以复用的信息，如果有些中间结果已经算过，后面的步骤就没必要每次都从头再来。

能缓存的缓存，能复用的复用，把重复工作减下来，时间自然还能继续往下挤。

最后还有torch.compile，它会对计算过程进行编译优化，让GPU执行这些操作时更加顺畅，减少一些原本零散的调度和执行开销。

当RH后训练加速模型和这些算子、缓存、编译优化叠到一起，该跑快的跑快，该复用的复用，该捋顺的捋顺，刚才压到43秒的生成过程又被继续压到了28.7秒。

但这还没完，H3这种视频模型真跑起来，往往不会只让一张GPU单打独斗。

多张卡一起干活，新的问题就又来了。

卡多，不等于一定快。这和多人一起干活其实挺像的。

八个人当然比一个人手多，可如果任务分配不合适，每个人刚干两下就要停下来等别人递东西，A等B，B等C，最后时间全耗在互相交接上。

多卡推理也是类似的道理。

GPU之间需要不断交换数据，而在没有NVLink高速互联、主要依靠PCIe通信的环境里，卡间通信的成本尤其不能忽略。

RunningHub这次专门针对这种环境，把不同的多卡并行方式拉出来重新测了一遍，最后选中的组合是TP2＋Ulysses4。

TP负责从张量计算层面拆任务，Ulysses则进一步从序列维度做并行。

在8张RTX 6000D、PCIe连接且没有NVLink的环境下，TP2＋Ulysses4相比TP4＋Ulysses2，速度快约12%，同时减少约14GiB显存占用。

所以从整体技术路径来看，这套工程栈基本就是沿着推理链路一路抠时间：

RH后训练加速模型先把需要完成的计算量压下来；

SageAttention2、Cache-DiT和torch.compile继续提高剩余计算的执行效率；

到了多卡层面，再用TP2＋U……

查看原文

（本文转载自量子位，仅作资讯分享）