【AI技能】24GB 4090 本地跑 MiniMax H3：ComfyUI 安装、下载提速与显存拆峰实战

MiniMax H3 开放权重后，我第一时间把它接进了自己的 Windows 视频生产项目。

机器是 RTX 4090 24GB、64GB 内存，环境用项目内独立的 ComfyUI。模型能出片，原生声音也能正常封进 MP4，但整个过程和“下载四个文件、打开工作流、点一下 Queue”差得很远。

我踩到的几个问题很典型：19GB 主模型从 Hugging Face 下载时一度只有 150KiB/s；20 步采样明明跑完了，程序却卡在视频与音频 VAE 的切换；EasyCache 报出 2 倍采样加速，端到端时间却没有跟着减半。

这篇教程不追求把所有加速节点都塞进工作流。我只保留了几项能解释、能复现、出问题也知道从哪里拆的改动。

这套方案已经在 Windows、RTX 4090 24GB 上稳定跑通 T2V、I2V 和原生音频；5.17 秒、1056×608、20 步的早期 Sage + EasyCache 测试，四次总执行时间中位数约 111.6 秒。

-视频号链接

本机 ComfyUI + MiniMax H3 竖屏测试帧，输出为 24fps。

装之前，先看清这套方案的边界

我的已验证环境如下：

项目版本 / 配置 GPU RTX 4090，24GB 系统内存 64GB 系统 Windows Python 3.12.9 PyTorch 2.9.1+cu130 ComfyUI 0.30.0，固定到已验证提交 Triton Windows 3.5.1.post24 SageAttention 2.2.0，cu130 / torch 2.9+ wheel ComfyUI-KJNodes 1.4.9，固定提交

ComfyUI 官方 H3 文档

要求 0.30.0 或更高版本。H3 输出固定 24fps，时长会吸附到 17k+5 的帧网格；它的原生画布短边为 768，最大约 768×1344，宽高按 32 对齐。

如果你是 16GB 甚至 12GB 显卡，这篇文章里的参数不能原样照抄。那类机器更适合研究 WanGP/MMGP 的运行时级分层卸载。MMGP 做的是模型切片、模块预算、锁页内存和异步 CPU/GPU 搬运，不是往 ComfyUI 里多接两个节点就能复刻。

MMGP 官方说明

还特别提醒，Windows 通常要比 Linux 多准备约 16GB 系统内存。

建一个隔离环境，别把主项目的 CUDA 依赖搅乱

H3 还很新，ComfyUI、PyTorch、Triton、SageAttention 和自定义节点都在快速迭代。最省事的做法，是给 ComfyUI 单独建环境。

mkdir H3-ComfyUI cd H3-ComfyUI git clone

https://github.com/Comfy-Org/ComfyUI.git

tools/comfyui py -3.12 -m venv .venv-comfy ..venv-comfy\Scripts\python.exe -m pip install torch==2.9.1 torchvision==0.24.1 torchaudio==2.9.1 –index-url

https://download.pytorch.org/whl/cu130

..venv-comfy\Scripts\python.exe -m pip install ` -r .\tools\comfyui\requirements.txt

为了复现我的环境，可以把 ComfyUI 固定到这次验证过的提交：

git -C .\tools\comfyui checkout 16e3f3034f2bba1fff6c70cbd759339778555cd6

这个提交包含一项 H3 VAE 的设备转换修复。以后升级没有问题，但请先保留当前工作环境，另建一份新目录测试。直接在能出片的环境里追最新版，排错成本通常比重装还高。

我采用的目录结构很普通：

H3-ComfyUI/ ├─ .venv-comfy/ └─ tools/ └─ comfyui/ ├─ models/diffusion_models/ ├─ models/text_encoders/ ├─ models/vae/ └─ user/default/workflows/

第一道门槛，是 42.5GB 模型下载

T2V 与 I2V 共用四个文件：

文件体积放置目录 FL2VA INT8 ConvRot DiT 20.97GB models/diffusion_models/ Qwen3-VL 32B NVFP4/AWQ 15.69GB models/text_encoders/ Video VAE FP16 5.21GB models/vae/ Audio VAE FP32 0.61GB models/vae/

合计约 42.5GB，Windows 按 GiB 显示时大约是 39.6GiB。R2V 还要再下一个独立 REF2VA DiT，又是 20.97GB。

我的建议很直接：先装 T2V/I2V，跑通 480p 或 0.6MP 的短片，再决定是否要 R2V。别在吞吐、显存和工作流都没验证前，把 63GB 权重一次性塞满磁盘。

国内网络先试 ModelScope

项目最早从 Hugging Face 拉 19GB 主模型。16 连接起步只有约 150KiB/s，ETA 一度逼近 38 小时。后来我把默认源切到 ModelScope，同一台机器下载 Video VAE 和 Audio VAE 的平均速度分别达到 92MiB/s、86MiB/s。

差距来自线路，不来自什么神奇参数。多开连接救不了一条不合适的源。

安装

aria2

后，可以这样下载：

$base

= ‘

https://modelscope.cn/models/Comfy-Org/MiniMax-H3/resolve/master

‘

$root

= ‘.\tools\comfyui\models’ aria2c -c -x16 -s16 -k8M –file-allocation=none -d "$root\diffusion_models" -o ‘minimax_h3_fl2va_pruned_int8_convrot.safetensors’ "$base/diffusion_models/minimax_h3_fl2va_pruned_int8_convrot.safetensors" aria2c -c -x16 -s16 -k8M --file-allocation=none -d “$root\text_encoders” -o 'qwen3vl_32b_minimax_h3_nvfp4_awq.safetensors' “$base/text_encoders/qwen3vl_32b_minimax_h3_nvfp4_awq.safetensors” aria2c -c -x16 -s16 -k8M –file-allocation=none -d "$root\vae" -o ‘minimax_h3_video_vae_fp16.safetensors’ "$base/vae/minimax_h3_video_vae_fp16.safetensors" aria2c -c -x16 -s16 -k8M --file-allocation=none -d “$root\vae” -o 'minimax_h3_audio_vae_fp32.safetensors' “$base/vae/minimax_h3_audio_vae_fp32.safetensors”

-c 是断点续传，-x16 -s16 是 16 连接。下载完成后不要只看文件名，至少检查大小和 SHA256。项目里四个文件的已验证 SHA256 如下：

FL2VA DiT e889202c41dafb67b10d67b97f0d8541508036a6090af23425a5c2615d03c47a Text Encoder 35a88d51044231fe332301d7a62aa81e3f2cba62febeb446e2c1e3e0ef76f2c6 Video VAE 7c1f131492e7eddacaac9069a61b81bdd39de5cc96561e677c5eab1cdce5e522 Audio VAE 8e505d95dd1561d47abd43d4238fd40d9bb1ae9e147ed0a4cba778d76ae4db48

PowerShell 校验命令：

Get-FileHash .\tools\comfyui\models\vae\minimax_h3_video_vae_fp16.safetensors -Algorithm SHA256

下载脚本最好把文件大小、SHA256 和重试都写死。几十 GB 的权重如果静默损坏，常常要到模型加载或采样中途才暴露，排查起来很像显存问题。

先跑官方工作流，确认基础链路

启动 ComfyUI：

..venv-comfy\Scripts\python.exe .\tools\comfyui\

main.py

--listen 127.0.0.1 –port 8189 ` –reserve-vram 4

浏览器打开 http://127.0.0.1:8189，在 Template Library 的 Video 分类里选择 MiniMax H3 T2V 或 I2V。官方模板会识别前面的模型目录。

先用小画布、短时长、20 步做资源探针。启动 ComfyUI 本身不会加载 H3，点击 Queue 后才会进模型加载和推理。

我的冒烟测试顺序是：

864×480，约 5.17 秒；
1056×608 或 608×1056，约 5.17 秒；
确认视频与音频都能写入 MP4；
再升到 0.7MP、0.8MP。

5 秒在 H3 的帧网格上实际会变成 124 帧，也就是约 5.17 秒。这是由 17k+5 与 24fps 共同决定的正常结果。

本机 864×480 动作测试，公众号 GIF 已压缩到 2.7MB。

同一轮横屏测试里还有一条书页与排版转场。它的镜头运动不大，难点换成了页面结构、字形和版式切换的连续性。短句能保持大致可读，长段文字仍会留下生成式排版的瑕疵，适合做气质画面，不适合替代真正的字幕与版式设计。

本机 1056×608、约 5.17 秒的图形排版测试。

SageAttention 能加速，版本必须对上

ComfyUI 官方文档给出的判断是：Sage Attention 可以让 H3 生成速度大致翻倍，画质损失较小。这个“约 2 倍”指 attention / 采样相关部分，不是模型加载、文本编码、VAE 解码和 MP4 封装的总时间。

SageAttention 官方项目

也明确把内核速度和端到端模型表现分开讨论。

我的 Windows 组合是：

Triton Windows 3.5.1.post24；
SageAttention 2.2.0 的 cu130、torch 2.9+ 预编译 wheel；
KJNodes 1.4.9，提交 6edfa76599c13905968841b81309784a7dbb7803。

先安装 Triton Windows：

..venv-comfy\Scripts\python.exe -m pip install triton-windows==3.5.1.post24

SageAttention 在纯 Windows 上最好下载与 Python、PyTorch、CUDA 完全匹配的 wheel，再本地安装。我的文件名是：

sageattention-2.2.0+cu130torch2.9.0andhigher.post4-cp39-abi3-win_amd64.whl

对应的 Windows wheel 来自

woct0rdho/SageAttention Windows releases

。预编译 wheel 属于第三方构建，我在项目安装器里固定 URL 和 SHA256，不直接执行来源不明的包。

再安装 KJNodes：

git clone

https://github.com/kijai/ComfyUI-KJNodes.git

.\tools\comfyui\custom_nodes\ComfyUI-KJNodes git -C .\tools\comfyui\custom_nodes\ComfyUI-KJNodes checkout 6edfa76599c13905968841b81309784a7dbb7803 ..venv-comfy\Scripts\python.exe -m pip install ` -r .\tools\comfyui\custom_nodes\ComfyUI-KJNodes\requirements.txt

重启 ComfyUI，在 H3 核心子图中把 H3 专用 SageAttention Patch 接到 UNETLoader 之后，再把输出送给 guider / scheduler 使用的模型路径。

控制台偶尔会出现某些输入不是 FP16/BF16、因而回退到 PyTorch attention 的提示。ComfyUI 官方文档说明这是预期行为：H3 有少量其他 dtype 的层，受影响的部分自动回退，工作流仍可继续。

EasyCache 只适合草稿，不要全档开启

我给快速预览档加了 EasyCache：

reuse_threshold = 0.20 start_percent = 0.15 end_percent = 0.95

多次 20 步测试中，它实际跳过 6–11 步，节点报告的采样阶段加速在 1.43x–2.22x 之间。最常见的是跳过 10/20 步，节点显示 2.00x。

这里最容易误读。一次 1056×608、5.17 秒的完整生成还包括文本编码、模型准备、VAE 解码和视频封装。节点省下一半 Transformer 计算，不代表点 Queue 到拿到 MP4 也会减半。

而且缓存会动到画面细节和运动稳定性。我最后把产品档位固定成这样：

档位 16:9 9:16 1:1 加速策略草稿 0.6MP 1056×608 608×1056 768×768 Sage + EasyCache 标准 0.7MP 1152×640 640×1152 832×832 Sage 精细 0.8MP 1216×672 672×1216 896×896 Sage

标准和精细档保留全部 20 步。官方约 1.0MP、1344×768 的原生画布可以手动跑，但我没有把它设为 24GB 4090 自动化生产线的默认值。

竖屏档还留下一条 608×1056 的人物动作测试。全身姿态、宽松衣料、发光裤管与地面反射同时变化，比单帧更容易暴露肢体轮廓和运动连续性问题。

本机 608×1056、约 5.17 秒的竖屏人物测试。

当然，社区还有其他加速方案，但是我没有同时叠加 Spectrum、TE-Speed、Sol-Attn、第二套 cache 和 torch.compile。加速组件越多，收益越难归因；一旦画质漂移或节点失效，你甚至不知道该拆哪一个。

最关键的稳定性改动：采样结束后先清场

项目早期最迷惑的一次故障，是 20 步采样已经完成，进度条也走到头，程序却卡在后面的双 VAE 解码。

H3 的本地链路不只有一个大模型：文本编码器约 14.96GB staged，H3 Transformer 约 20GB staged，Video VAE 约 4.97GB，Audio VAE 约 0.58GB。它们不可能一起舒服地待在 24GB 显存里。

我的处理是在 sampler 和视频/音频 VAE 之间插入 VRAM_Debug 屏障，开启：

empty_cache = true gc_collect = true unload_all_models = true

日志里，这个屏障每次释放约 17.1–18.8GB，空闲显存恢复到约 23.96GB，再加载双 VAE 解码。一次典型记录是：

free memory before: 5.67 GB free memory after: 23.97 GB freed memory: 18.29 GB

H3 Video VAE 已经按空间和时间分块。我没有再叠加通用 VAEDecodeTiled。分块策略不是越多越安全，重复切块会增加复杂度，也可能把真正的问题藏起来。

本机数据怎么看，才不容易自我欺骗

下面是早期 Sage + EasyCache 工作流的几次记录，全部 20 步：

输出视频时长 Queue 到完成 EasyCache 报告 864×480 5.17 秒 89.10 秒跳过 6/20，1.43x 1056×608 5.17 秒 120.95 秒跳过 7/20，1.54x 1056×608 5.17 秒 109.73 秒跳过 10/20，2.00x 608×1056 5.17 秒 113.53 秒跳过 9/20，1.82x 640×1152 5.17 秒 120.92 秒跳过 10/20，2.00x 672×1216 5.17 秒 140.78 秒跳过 10/20，2.00x

这组数据只说明我的 4090 上大致是什么量级。它没有控制所有变量，也不是严谨的 Sage / 非 Sage A/B 基准。

此外还有一条 1152×640、10.13 秒的横屏测试，共 243 个原始视频帧。月面、云海、人物与飞鸟在一个连续镜头里缓慢变化，更适合观察时间跨度拉长后的构图稳定性。它没有放进上面的耗时表，因为视频时长与其他样本不同。

本机 1152×640、约 10.13 秒的连续镜头测试。

真正有用的记录方式，是把首个镜头和第二个镜头分开。首轮常含模型准备和权重搬运，第二轮更接近持续生产吞吐。还要同时记分辨率、帧数、步数、是否原生音频、是否缓存，以及 VAE 是否重新加载。

只截一行“2.00x speedup”，很容易得到一个漂亮但没法指导生产的结论。