一张 5090 把 MiniMax H3 跑到底

MiniMax H3 是 2026-08-03 开源的视频生成模型，一次前向同时出画面和原生立体声——人声、音效、配乐不是后期贴上去的，是和画面一起生成的。开源当天 ComfyUI 就给了原生支持。

我在 AutoDL 租的单张 RTX 5090 上，从零装机一路跑到出片。这篇是那一天的完整记录：七次实测的耗时与显存、五个和直觉相反的发现、以及一份「官方文档说的和实际对不上」的清单。文末有完整数字表，你可以直接拿去估自己的机器。

先说结论：能跑，而且比想象中宽裕。 官方两个上限——1344×768 的原生画布、362 帧（15 秒）的训练范围上限——同时拉满也没爆显存。整个摸底过程花了 ¥10.15，其中真正用来出片的只有 ¥3.25。

---

为什么是「单卡 + ComfyUI」

MiniMax 官方推荐四种推理框架：SGLang、vLLM、diffusers、ComfyUI。前三条在这台机器上直接出局，原因不是显存，是主机内存。

SGLang 官方 cookbook 给了一份消费卡配方：2×RTX 5090，张量并行加逐层 offload，峰值显存只要 26.3 GiB——听起来很美，但它标注了一个条件：需要约 384 GiB 主机内存。AutoDL 的 5090 实例只有 90 GB。

于是只剩 ComfyUI 这条路。它是官方支持的，docs.comfy.org 有专页和三套模板，而且不设硬件门槛。代价是得用量化过的权重：官方模板指定的四件套一共约 39.6 GB：

这里有个容易吓退人的数字：模型仓库总大小 465 GB。那是所有量化变体之和，不是你要下的量。实际只需要上面这四个。

顺带一提，H3 开源的是 768p 那颗芯。2K 需要 H3-Regenerate-2K、提示词编译需要 H3-Context-IR，这两个都没开源，只有 API。

---

一、显存吃到 98%，不代表快 OOM 了

第一条基线跑完，我看到峰值显存 31804 MiB / 32607 MiB，97.5%，当场在文档里写下一段推论：

出片档 1344×768 是它的 2.49 倍像素，激活显存大致同比例放大 ⇒ 直接跑出片档几乎必然 OOM。

然后我跑了一条，一次就过，峰值 32092 MiB——只比基线多 288 MiB。

错在哪？我把「显存峰值」当成了因变量去外推。但 ComfyUI 开着 DynamicVRAM，峰值是被摁住的：画布变大、激活变大，它就把更多权重换出到主机内存，让峰值继续贴着显卡上限。真正随档位增长的是时间，不是显存。

七次生成，档位差了 8 倍，峰值显存全落在 26974–32094 MiB 之间：

横轴七根柱子对应七次实测，画布从 864×480 到 1344×768、时长从 5 秒到 15 秒，峰值显存几乎是同一个数

这条经验可以带走：在有自适应 offload 的运行时上，别拿「显存占用率已经很高」去推「再加就会 OOM」。先跑一条，比推一整段都便宜——那次实测代价是 274 秒，约两毛钱。

---

二、加画布、加时长，代价是时间，而且是超线性的

既然显存不动，代价就全在时间上。而时间的增长明显快于线性：

灰色虚线是「若按帧数正比增长」的参考线。实测两条曲线都在它上方，说明代价是超线性的

拟合出来的指数：像素约 1.3 次方，帧数约 1.8 次方。帧数那条更陡，因为时间注意力的开销随序列长度约二次增长。

这个模型的用处是估时间。我在跑 15 秒那条之前用它预测过一次，实测 88.25，误差 4%。

一个附带的坑：帧数不能随便填。H3 走的是 17k+5 网格，官方节点里的换算式是：

n = max(5, round(seconds * 24))
length = n + (5 - (n % 17)) % 17

所以 5 秒是 124 帧、10 秒是 243 帧、15 秒是 362 帧。我一开始按「秒 × 24」凑了个 236，那个数根本不在网格上。别自己凑，用官方式子现算。

---

三、SageAttention 的提速不是一个常数

SageAttention 是清华 thu-ml 出的注意力加速库，用低精度量化重写 attention 那一步。ComfyUI 官方文档写着「roughly double the generation speed with minimal quality loss」。

装它比想象中麻烦，因为官方的两条安装说法都不能照抄（详见第四节）。最后只有一条路走得通：clone 到 tag v2.2.0 自己编译。

export CUDA_HOME=/usr/local/cuda PATH=$CUDA_HOME/bin:$PATH
export TORCH_CUDA_ARCH_LIST=12.0   # sm_120，显式指定就不需要 GPU 在场
git clone --depth 1 --branch v2.2.0 https://github.com/thu-ml/SageAttention.git
cd SageAttention && pip install . --no-build-isolation

我原本最担心的是版本：官方仓最后推送是 2026-01-17，而这台机器是 torch 2.12 + CUDA 13.0，都是那之后才有的东西。结果编过了，sm_120 的 kernel 正常产出。

真正有意思的是效果。官方说「约翻倍」，但实测它不是常数：

片子越长，收益越大。 机制说得通：attention 开销随序列长度约二次增长，其他算子线性，所以序列越长 attention 占总开销的比重越大，而 Sage 削的正是这块。旁证是上面那张图里的指数——从 1.83 被压到 1.62，超线性那截确实被削掉了一段。

所以第三条经验：别拿短片测出的提速比去估长片，会低估。我按 1.89× 预测 15 秒要 974 秒，实测 829 秒。

至于画质——官方说「损失极小」，我没法用数字证明。同 seed 逐帧比出来 PSNR 只有 17.51 dB，但这不是画质变差的证据：换掉 attention kernel 就改变了数值路径，20 步扩散会把微小差异逐步放大，同 seed 也会出不同的片。PSNR 只回答了「是不是同一条片」（不是），回答不了「哪条更好看」。这一层只能人看。

两条都放在这儿，出片档 1344×768 · 5 秒，同 seed 同 20 步，你自己看：

无 SageAttention，总耗时 274 秒

挂了 SageAttention，总耗时 193 秒。同 seed，但不是同一条片

---

四、官方文档说的，和实际对不上的五处

这是我觉得最值得留下来的一节。我给自己定的规矩是「只认官方与正规社区，个人博客的实测数字不作权威」——这条规矩没错，但它是来源门槛，不是免检通行证。一天下来攒了五处：

第一条最坑：ComfyUI 新版模板用了子图（subgraph），子图内部节点的值是陈旧的，会被父节点暴露出来的控件经连线覆盖。读模板必须从父节点读。我按内部值读，错了将近一周。

发现它的方式不是灵光一现，是两条旁证对不上：5 秒换算出来的 124 帧正好等于官方节点源码里的默认值；而 2 秒只有 56 帧，低于官方 tooltip 写的训练范围下限（124–362 帧）——官方不会把出厂值设在自己没测过的区间。

第二条最阴险：源码里确实有个按像素上限缩放的函数，但它只用于参考图适配，用户填的宽高是原样送进去的。填超了不报错、不自动缩，只会静默送进模型没训过的画布。

五处的共同点是：照着官方字面做会踩空，而动手复核一遍就能发现。

---

五、R2V：一直缺的那块能力

H3 开源了两个不同的主干。前面所有测试用的是 FL2VA（文生视频 / 首尾帧），另一个是 Ref2VA——给它一组参考图，生成的视频保持这些参考的样子。ComfyUI 里叫 Reference to Video，通俗说就是「全能参考」。

它对我特别重要：这块能力在别的地方要么开不了（需要账户余额），要么额度很小且很快到期。本地版没有额度概念——最多 9 张参考图，另可挂 3 段视频、3 段音频，跑多少条只看机时。

官方模板一个参数不改跑第一条，79 秒（预览档 864×480 · 5 秒 · 两张参考图）。产物逐帧核过：124 帧、24fps、32 kHz 立体声。

先看它拿到的两张参考图，官方模板自带，我一个字没改：

然后是成片：

R2V 首条，预览档 864×480 · 5 秒，79 秒出片。判据不是「好不好看」，是「片子里那个角色，是不是参考图里的那个」

这里踩了一个值得写下来的坑。参考图输入在 ComfyUI 里是「自动增长」类型（autogrow），它在 API 格式里的字段名不是直觉上的 ref_image_0，而是带点的完整嵌套路径：

"ref_images.ref_image_0": ["137", 0],
"ref_images.ref_image_1": ["139", 0],

写成裸名会在执行时报 unexpected keyword argument。权威出处是模板里那个节点的 inputs[].name 字段——遇到这类动态输入，别猜命名规则，去读模板。

好消息是猜错不花钱：0.19 秒就报错退出，GPU 一点没动。

---

完整数字

单张 RTX 5090 32GB，ComfyUI 0.30.0，官方模板与官方权重，全部一个参数不改或只动一个变量。自测数据，单卡没有官方基准可对照。

⚡ ＝ 挂了 SageAttention。帧数按 24fps 的 17k+5 网格取整：5 秒 ＝ 124 帧、10 秒 ＝ 243 帧、15 秒 ＝ 362 帧。 采样器 res_multistep、调度 simple 20 步，全部为官方模板默认值。卡价按 ¥2.78/时折算。

钱花在哪了

空转和试错占了七成。所以如果要省钱，省的是「开着卡干不吃卡的活」——编译、下载、读文档这些根本不需要 GPU。可惜这台机器一旦关机就不保证还能开回来（按量计费不预留 GPU），所以这笔钱有一部分是买保险。

---

几条经验，不限于 H3

• 占用率高不等于快溢出。在有自适应调度的运行时上，很多「资源指标」是被系统摁住的常量，不是反映压力的变量。拿它做外推会错。
• 官方文档要采信，但要复核。五处不一致全都是「照字面做会踩空、动手一试就发现」。
• 做性能对照时，先确保只有一个变量在动。我判断多线程下载有没有用时，一度在两个下载互相竞争的状态下测总带宽，看到数字没涨就得出了「多线程无用」的错误结论——让它独占跑才看出真实差距。
• 看到「快得不合理」，先怀疑缓存。有一次补测显存，我只改了输出文件名就重跑，9 秒返回、峰值 272 MiB——上游节点全部命中缓存，根本没算。
• 采样值全都一样，是坏了，不是稳。监控脚本写在远程命令行里，命令替换被外层 shell 提前展开了一次，于是每轮打的都是启动瞬间那个陈旧值，看起来像「显存非常平稳」。

最后一条是给自己的：这一天里最值钱的产出不是那七个数字，是那五处「官方说的和实际不一样」。数字换台机器就得重测，而「别照字面信文档」这条不会过期。