MiniMax-H3 在 32GB 的 5090 上能跑原生 768p 的 15 秒片嗎?

可以，但要掛 KJNodes 的兩個節點。1344×768 × 362 幀在沒掛的時候會 OOM，取樣器要 47.11 GiB。掛上 MiniMaxLowVRAMAttention 跟 MiniMaxChunkFeedForward 之後跑得完，在 torch 2.13+cu130 上是 518 秒。

head_chunks 要設多少?

16，搭配 FFN chunks 8。節點 tooltip 讀起來像在建議「取剛好塞得下的最小值」，但這台實測是反過來的:2/2 要 2208 秒、8/4 要 1056 秒、16/8 只要 756 秒，32/16 跟 16/8 打平。切太粗會讓每次呼叫的暫存變大，反而溢出到系統記憶體。

torch 從 cu128 換到 cu130 值得嗎?

在 NVFP4 底模上值得，實測 362 幀省 32.4%、124 幀省 45.2%。原因是 ComfyUI 在 torch 的 CUDA 版本小於 13 時會關掉 comfy-kitchen 的 cuda 後端，而那個後端要在 cuBLASLt 13 存在時才註冊 scaled_mm_nvfp4。cu128 上這個 kernel 根本沒登記，換過去才會用到。

SageAttention 或 Sol-Attn 能再快多少?

在這台上都只有 2-3%。兩者單看 kernel 都快 4 倍以上，但 5090 跑 H3 時 attention 不是瓶頸。Sol-Attn 第一發還會因為 Triton autotune 比不掛更慢 8.7%，只跑一發會得到相反的結論。

[Benchmark] MiniMax-H3 在 RTX 5090 上的加速組態:換成 cu130 省 32%，注意力 kernel 只值 3%

TL;DR

同一張 5090、同樣 14 步、同樣品質設定，六個加速組態各值幾 %:KJNodes 的兩個 chunk 節點讓原生 768p 的 15 秒片從 OOM 變成跑得完，參數從 8/4 調到 16/8 再省 1.40 倍;torch 從 cu128 換到 cu130 省 32.4%，因為 cu128 上 comfy-kitchen 根本沒註冊 NVFP4 的那個 kernel。而 SageAttention 跟 Sol-Attn 這兩個單看 kernel 快 4 倍的東西，端到端只值 2-3%。⚠️ 換 kernel 會改數值，畫質只做過目視沒做盲測。

前言

同一條路，開車的時間差可以是塞在市區還是走高速公路的差別——引擎沒換、油門踩得一樣深，差的只是你走哪條道。

這系列前面四篇分別把 H3 在一張 5090 上跑起來(Part 1)、把出片時間對半砍(Part 2)、用參考圖鎖角色(Part 3)、跑完十個效果 embedding(Part 4)。

這篇換一層:不改步數、不加蒸餾、不動提示詞，只調組態，看每一格各值幾 %。全部量測都在 1344×768、14 步、res_multistep + simple、shift 12/3、Spectrum 開著，底模 minimax_h3_fl2va_pruned_nvfp4，文字編碼器 qwen3vl_32b_heretic_minimax_h3_nvfp4。

實測結果:原生 768p 的 15 秒片，從 OOM 變成 8.6 分鐘

直接看結論。1344×768 × 362 幀就是 H3 的 15.08 秒上限，而 362 幀在 32GB 上本來塞不下:

組態	1344×768 × 362 幀
什麼都不掛	OOM — 取樣器要 47.11 GiB
KJNodes 兩個節點(8/4)	~1056 秒
chunk 調到 16/8	755.6 秒
再換 torch 到 cu130	518.0 秒 = 8.6 分鐘

整套出片流程(124 幀，再放大到 3840×2176)從 240 秒降到 134.2 秒。

兩個 KJNodes 節點:先讓它跑得起來

沒掛節點的時候，SamplerCustomAdvanced 直接報 Allocation on device 0 would exceed allowed memory，記憶體分配器要到 47.11 GiB。32GB 的卡塞不下。我查到的討論串裡，大家給 32GB 的建議也都是「5 秒 @768p 或 15 秒 @480p」二選一。

KJNodes 有兩個 H3 專用節點解掉這件事:

MiniMaxLowVRAMAttention — 把 attention 拆成 head group。head 彼此獨立，所以逐組算是等價的;同時在 qkv GEMM 之後立刻放掉 normed h、分配 out_proj 的記憶體之前再放掉融合的 qkv 緩衝。
MiniMaxChunkFeedForward — 沿 packed token 維切 SwiGLU。activation 是 per-token 量化，所以切了輸出相同。

這兩個節點都不會改掉計算結果，我讀過原始碼，不是只信 README。接線順序是插在 Spectrum 之後——最後套用，patch 才不會被蓋掉:

UNETLoader → SpectrumApplyMiniMaxH3
           → MiniMaxLowVRAMAttention(head_chunks=16)
           → MiniMaxChunkFeedForward(chunks=8, seq_threshold=4096)
           → BasicScheduler / BasicGuider

chunk 切越細越快:文件跟社群的建議在這台剛好相反

節點的 tooltip 寫的是「chunk 越多峰值越低，但 overhead 會稍微增加」。照這句推，合理的做法是取剛好塞得下的最小值。

同 seed、同提示詞、只改這兩個參數:

head_chunks / ffn_chunks	秒
2 / 2	2208.1
8 / 4	~1056
16 / 8	755.6
32 / 16	761.3

2/2 比 16/8 慢了 2.9 倍。方向整個反過來，而且曲線在 16 就平了——32/16 只差 0.8%，落在雜訊裡。

照那個推法，VRAM 只有塞得下跟塞不下兩種狀態。實際上中間有一段:塞不進 VRAM 但還沒爆,Windows 會讓 CUDA 溢出到系統記憶體，整段走 PCIe 分頁。chunk 切太粗，每次呼叫的暫存就大，剛好掉進那一段。

換成 cu130 省 32%:cu128 上那個 kernel 根本沒註冊

六種改法裡，換 cu130 省得最多，而且完全不用動生成參數。

幀數	torch 2.11.0+cu128	torch 2.13.0+cu130	差
124(n=3)	181.8 秒	99.6 秒	−45.2%
362(n=1)	766.1 秒	518.0 秒	−32.4%

機制查得到。ComfyUI 的 comfy/quant_ops.py 在 torch 的 CUDA 版本小於 13 時會直接關掉 comfy-kitchen 的 cuda 後端:

cuda_version = tuple(map(int, str(torch.version.cuda).split('.')))
if cuda_version < (13,):
    ck.registry.disable("cuda")

而 comfy-kitchen 那邊還有第二道:cuda 後端要在執行期找得到 cuBLASLt 13 才會註冊 scaled_mm_nvfp4。直接問 registry:

kitchen 後端	cu128	cu130
`cuda` 被關掉	True	False
`cuda` 的能力數	44	46
`cuda` 有 `scaled_mm_nvfp4`	False	True

所以 cu128 上，NVFP4 的矩陣乘法只能走 eager。換到 cu130 之後才會接到 kitchen 的 cuBLAS FP4 GEMM。

兩邊都實跑 14 步。 ComfyUI log 裡 Spectrum 的帳目逐項相同:steps=14、offline_replay_calls=14、anchor_steps=11、smoothed_steps=3、bypassed_steps=0、fallbacks=0。快不是因為做得比較少。

升級前先確認三件事

torch 2.13 沒有 cu128 的 wheel。Windows 上只有 cu126 / cu130 / cu132(cu129 只有 Linux)，所以升版等於強制換 CUDA 版本
SageAttention 要換成 +cu130 那顆——同一個 post6 release 裡 cu128 跟 cu130 兩版都有，不用自己編
RTXVideoSuperResolution 依賴的套件在 PyPI 上叫 nvidia-vfx,nvvfx 只是 import 名

注意力 kernel 只值 2-3%:兩個都一樣

這台的瓶頸不在 attention。

SageAttention 的單一運算實測 4.10× 到 4.21×，端到端在這張 5090 上只有 2%(52.18 秒 → 51.11 秒)。同一顆 Sage 在改裝 2080 Ti 上值 19%。

Sol-Attn 單看 kernel，在 8K 到 65K token 是 1.38× 到 1.65×，而我們的 362 幀是 91k token，理論上在它的 sweet spot 之上:

設定	秒
16/8 不掛 Sol	755.6
Sol，第一發	821.3
Sol，第二發	733.2
Sol + head_chunks=1	730.2

只值 3%。 而第一發比不掛還慢 8.7%——那是 Triton autotune 的 overhead，按 token 數快取一次。所以這個節點要量兩發，第一發不算。

VAE 加速對長片沒用:它只佔 6.2%

TRT-VAE 用 TensorRT 跑 H3 的 VAE，README 宣稱最多 1.7×。有人傳給我一份實測說端到端省 9.9%，我自己量只有 1.7%。

差別在分母。用同 seed 讓取樣命中 ComfyUI 的快取，就能單獨量後段:

階段	秒	佔比
取樣(14 步 × 362 幀)	~1009	86%
放大鏈	~116	10%
VAE 解碼 + 封裝	47.0	4%

那份實測跑的是 928×544 × 124 幀 × 8 步 + Acc LoRA。取樣便宜，VAE 就佔到 24%。步數只讓取樣變久，VAE 不會跟著變慢——他 8 步我 14 步，取樣工作量差十倍，所以同樣省掉 4 秒，在他那邊是 −9.9%，在我這邊只剩 −0.6%。

另外還量到兩件事:engine 編譯只花 23.6 秒;它固定用 256px tile，換解析度或幀數都不用重建。encoder 的 profile 寫死在 T=17，但現行程式碼會把不足 17 幀的輸入補到 17，所以單幀編碼不會單純因為形狀不合而失敗。

完整組態表

ComfyUI 0.34.0 · Python 3.13.7 · torch 2.13.0+cu130
sageattention 2.2.0+cu130torch2.10.0andhigher.post6
comfy-kitchen 0.2.31 · triton-windows 3.7.1.post27 · nvidia-vfx 0.1.0.1

啟動:main.py --listen 0.0.0.0 --port 8188 --enable-manager --use-sage-attention

底模  minimax_h3_fl2va_pruned_nvfp4.safetensors
TE    qwen3vl_32b_heretic_minimax_h3_nvfp4.safetensors
VAE   minimax_h3_video_vae_fp16 + minimax_h3_audio_vae_fp32

取樣  res_multistep + simple · 14 步 · shift 12/3
接線  UNETLoader → Spectrum → MiniMaxLowVRAMAttention(16)
                            → MiniMaxChunkFeedForward(8) → 取樣器

組態	值多少
KJNodes 兩個節點	從 OOM 到跑得完
chunk 8/4 → 16/8	1.40×
torch cu128 → cu130	1.48×(362 幀)
Sol-Attn	1.03×
SageAttention	1.02×
TRT-VAE	1.02×

前三個是白賺的:位元相同，或同步數同 sampler，沒有近似。後三格加起來不到 8%，而且都要改數值。

進階:那個 11 倍的中間帶

不讀這節不影響使用。這裡放的是 VRAM 溢出的量測，以及為什麼 vram_free 讀不到它。

同樣 362 幀，只改解析度:

解析度	像素	秒
960×544	0.52 MP	318
1152×640	0.74 MP(1.41×)	3576
1344×768(無 KJ 節點)	1.03 MP	OOM
1344×768(KJ 16/8)	1.03 MP	755.6

1.41 倍的像素換來 11.2 倍的時間。 注意力對 token 是平方，1.41² 也只該是 2.0 倍，中間差了 5.6 倍。

VRAM 的三個區間:塞得進 VRAM 全速、溢出但沒爆會慢一個數量級、連溢出都不夠就 OOM。1152×640 比 960×544 只多 1.41 倍像素卻慢 11.2 倍

而且 1344×768 掛上 KJ 節點之後是 755.6 秒——像素多 40%，反而比 1152×640 快 3 倍。

那個缺口不是計算量，是 Windows 讓 CUDA 溢出到系統記憶體，整段在 PCIe 上分頁。實際上會碰到三種情況:

塞得進 VRAM → 全速
溢出但沒爆 → 跑得完，慢一個數量級
連溢出都不夠 → OOM

中間那段最陰險，因為它看起來只是「比較慢」。

vram_free 量不到這件事。OOM 那一發我每 5 秒抽樣，最高只看到 24.3 GB——溢出的部分不算在 VRAM 裡，而記憶體分配器實際要到 47.11 GiB。要判斷有沒有溢出，看的是時間對像素的斜率不合理，不是看 VRAM 讀數。

沒有驗的:畫質

換 kernel 就是換數值，去噪軌跡跟著分岔。同 seed 在兩個環境跑出來的是兩次獨立生成，不是同一張圖的兩種畫質——上次換底模也是同一種情況。

我做過的只有 n=1 目視:兩邊細節密度相當、都沒有崩塊或糊臉。那不足以說哪一邊比較好，要判這個得跑多 seed 盲測。時間數字可以下結論，畫質還不行。