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

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/）

快12倍的H3是啥体验

不光是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秒的图生视频，这次我喂了一张吉卜力风格的参考图。

△图片AI生成

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

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

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

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＋Ulysses4减少通信和资源上的浪费；

最后，RunningHub把这些方法全部整合进SGLang multimodal_gen推理引擎，由它把模型生成、多卡协同和各种加速组件真正组织到一起。

现在AI行业的各种性能数字已经卷得飞起，只要舍得堆顶级GPU、高速互联和数据中心，把模型跑得飞快并不稀奇。

可真正想本地部署开源视频模型的创作者、工作室和中小团队要问了：

我手里的机器，能不能跑出这个速度？

RunningHub：必须能。

H3 Lightning特意绕开了“超能力解法”，针对的就是无NVLink的PCIe多卡环境，RTX 6000D也是公开可购买的专业GPU规格。

也就是说，RunningHub从一开始针对性优化的，就是一种更贴近工作室和企业团队实际部署的多卡环境。

当然了，如果你的预算没上限，用B300的卡配合这个方式，出片速度能直接提升至秒级。

从环境安装、模型下载，到服务启动和推理测试，H3 Lightning整个本地部署流程都公开了。

开发者也可以结合公开的社区加速LoRA，再配上前面提到的注意力优化、计算缓存和多卡并行，在自己的机器上重新跑一遍。

到底要几张卡、怎么调参数、速度和画质怎么取舍，都可以围绕自己的业务适配。

当然了，有设备的团队可以照着开源方案自己部署；

没有多卡服务器、不想研究环境配置的创作者，直接在RunningHub上点开H3 Lightning也能用。

顶级算力被垄断，RunningHub选了创作者够得着的那条路

当一个足够强的开源模型出来之后，围绕它其实会出现很多“二创”。

有人会拿开源底座继续做后训练，把优化后的能力跑在顶级数据中心集群上，再封装成API提供给用户。

用户不需要关心背后的GPU和工程优化，按调用付费就能直接获得结果，这当然是一种很成熟的商业路径。

另一边，也会有人选择把优化继续留在开源生态里——

开发者自己拥有硬件、自己部署模型，围绕自己的工作流继续改，优化方法又能被下一批开发者拿去复现和迭代。

RunningHub这次明显更偏向后者。

而且，这已经不是它第一次围着H3这么干了。

H3刚开源的时候，RunningHub首先做的是接入。

模型出来之后，平台第一时间把它接进来，让创作者不用先研究一大堆部署问题，就可以上手尝试新模型。

随后，它又参与生态共建，把全套ComfyUI节点开源。

这一下，开发者能玩的更多了。

有人拿H3做电商内容，有人拿去做短剧、漫剧，有人研究声音克隆、动作克隆和音频驱动，还有人继续把自己的玩法封装成新的工作流。

比如，创作者@魅力创意直接盯上了电商视频。

TA发布的MiniMax H3·电商多参生视频工作流，只需要把商品、模特、场景一股脑塞进去，再简单说说卖点——

H3就能自己琢磨人物该在哪儿、商品怎么露出、场景怎么搭，最后直接给你一条完整电商广告。

还有创作者@艾橘溪整的音频驱动数字人说话唱歌工作流。

上传一张人物图片，再扔进去一段音频，原本静止的人物就能秒变数字人开口营业。

不管是说话还是唱歌，口型和节奏都能同步对上。

还有今年超火的漫剧，创作者@qwlulnpi也搬出了新创意。

把分镜图、脚本、音频一次性丢进去就能拿到有画面有声音的完整成片。

多少有点“素材备齐，一把梭哈”的流水线味儿了。

这还只是RunningHub上冒出来的一小撮玩法。

自打H3上线以来，RunningHub平台上已经有上千名创作者，围绕它开源了近万条创意工作流。

其实这也是开源模型的乐趣，一个人解决一点问题，最后整个生态能用的东西就越来越多。

而H3 Lightning相当于RunningHub再进一步，开始把自己积累的工程能力反过来贡献给H3，直接解决推理效率的问题。

如果只看RunningHub，一个AIGC创作平台突然跑去研究后训练、算子优化和多卡并行，多少有点跨界。

但把它放回母公司海马云过去十多年的技术演进里，这事儿其实顺理成章。

海马云2014年成立，过去十多年长期和GPU、高性能内容打交道。

那个时候，行业面对的问题还不是“AI大模型怎么推理”。

当时的核心矛盾是游戏、图形、高性能数字内容体量越来越大，如何让这些负载稳定、高速地运行起来。

GPU容器调度、图形虚拟化、实时流媒体、大规模云渲染，海马云的整套能力体系都是围绕这个目标打磨的。

时至今日，海马云已经在国内建设60余个边缘节点，支撑超过2000万月活用户的智算服务。

到了生成式AI时代，需要被高效调度的计算对象发生了变化。

除了游戏、图形和高性能数字内容，现在还加入了大模型，以及模型驱动的内容生成。

于是海马云面对的命题也随之从「高性能内容怎么跑」，进一步转向了「AI能力如何调用，又如何高效落地」。

计算对象从云渲染到AI推理，但这也恰好让海马云这家原生AI公司十余年的技术积累有了更大的发挥场景。

所以RunningHub并不算“跨界”做模型加速。

RunningHub H3 Lightning，是海马云「GPU工程能力」在AI时代的一个新落点，补齐的也是开源模型从权重到生产力之间缺失的环节。

过去一年，开源模型越来越多，真正稀缺的是：

谁能在模型开源之后，最快把它接进真实环境、优化到生产可用，再把这些能力持续回馈给社区。

模型开源，RunningHub平台完成接入，创作者「能直接用」了；

开放ComfyUI节点与工作流，创作者「能玩的花样」多了；

而H3 Lightning推理优化，则是在模型跑通之后，继续攻克速度、成本与硬件门槛，把单次试玩的内容生成，升级为可稳定复用的批量生产力。

RunningHub就是这样一个生态反哺者。

咱普通创作者也算是跟着吃上细糠了～

GitHub仓库：

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

文章来自于微信公众号 “量子位”，作者 “量子位”