在 ComfyUI 裡跑 MiniMax H3：版本、檔案，以及那個止住 OOM 的旗標
原生節點在 0.30.0 就有了；真正止住記憶體爆掉的修正在 0.32.0，而多數教學還停在前面那個版本。現況，附 PR 編號。
編輯部
要在 ComfyUI 裡跑 MiniMax H3，你需要 ComfyUI 0.32.0 或更新的版本、 四個總共 42.47 GB 的模型檔案，以及零個自訂節點。 原生支援在 0.30.0 到位，但修聲音失真的取樣器修正落在 0.31.0， 尖峰記憶體的修正落在 0.32.0。在一張 24 GB 的卡上， 決定它跑不跑得完的是主機 RAM。
這裡每一件事都有日期。0.30.0 之後又出了九個 H3 修正， 所以第一週寫的教學描述的是另一個程式。底下每一條都附著它的 PR 編號和它的版本。
在你下載任何東西之前先確認這件事：MiniMax H3 社群授權把美國、歐盟、英國和南韓 排除在「在本機跑這些權重」的授權之外，而 §V.4 把那條限制延伸到產出。 託管 API 不受地域條款涵蓋。以下是摘要，不是法律意見—— 完整的授權拆解 有那些條款。
0.30.0 給你什麼，又沒給你什麼
0.30.0 是那些節點和三個本機範例範本出現的地方。它就只是這樣。
0.31.0 在 8 月 8 日又帶來六個修正，領頭的是 kijai 的 #15243，
Fix sampler issues for audio with minimax。0.32.0 在 8 月 11 日帶來三個，
包括 comfyanonymous 的 #15486，Fix peak memory issue with H3——
一張以前會死掉的 24 GB 卡現在跑得完，原因就是它。
| 版本 | PR | 它修了什麼 | 嚴重度 |
|---|---|---|---|
| 0.31.0 | #15243 | 取樣器踩過頭聲音那條排程；在 4 步時它是雜訊 | 阻斷級 |
| 0.31.0 | #15390 | EasyCache 弄壞聲軌 | 重大 |
| 0.31.0 | #15377 | 聲音 VAE 的完整卸載會失敗 | 重大 |
| 0.31.0 | #15334 | int8_convrot 的 VAE 載不進來 | 重大 |
| 0.31.0 | #15322 | 遮罩取樣是錯的 | 輕微 |
| 0.31.0 | #15268 | VAE 解碼時的裝置不符錯誤 | 輕微 |
| 0.32.0 | #15486 | 就是 OOM 那個。 動手改任何東西之前先更新 | 阻斷級 |
| 0.32.0 | #15477 | 分塊 VAE 解碼在 NestedTensor latent 上崩潰 | 重大 |
| 0.32.0 | #15446 | 沒有它，解碼更慢也更重 | 輕微 |
0.33.1 在 8 月 13 日加了 MiniMax ContextIR 和 Regenerate-2K 的 API 節點
（#15471），所以託管的 2K 那一段可以串到本機工作流上。
那一段的權重留在託管端，所以這條路要的是一把 API 金鑰，不是一份本機檢查點。
cd /path/to/ComfyUI
git pull
python -m pip install -r requirements.txt
python main.py --version # expect 0.32.0 or laterWindows 免安裝版：用內附的更新腳本或程式內的更新器。
該下載哪幾個模型檔案，各自放在哪裡
不要 clone 整個倉庫——它裝著每一種精度版本，總共大約 475 GB。 一條文字轉影片或圖片轉影片的工作流只載四個檔案， 8 月 14 日對著 Hugging Face 逐位元組核對過。
| 檔案 | 大小 | 放在 |
|---|---|---|
minimax_h3_fl2va_pruned_int8_convrot.safetensors | 20.97 GB | models/diffusion_models/ |
qwen3vl_32b_minimax_h3_nvfp4_awq.safetensors | 15.69 GB | models/text_encoders/ |
minimax_h3_video_vae_fp16.safetensors | 5.21 GB | models/vae/ |
minimax_h3_audio_vae_fp32.safetensors | 0.61 GB | models/vae/ |
| 合計 | 42.47 GB = 39.55 GiB |
hf download Comfy-Org/MiniMax-H3 \
diffusion_models/minimax_h3_fl2va_pruned_int8_convrot.safetensors \
text_encoders/qwen3vl_32b_minimax_h3_nvfp4_awq.safetensors \
vae/minimax_h3_video_vae_fp16.safetensors \
vae/minimax_h3_audio_vae_fp32.safetensors \
--local-dir ComfyUI/models參考圖生影片要加第五個檔案，也就是另外那份 Ref2VA 檢查點， 整組變成 63.44 GB。把 FL2VA 那個檔案載進一條 R2V 工作流， 是第一次跑最常見的失敗。
有兩張被廣泛複製的檔案表，數字用的是 gibibyte，標籤卻寫 GB。 如果你清出來的是 39.6 GB 的硬碟空間，那你在 ComfyUI 寫任何東西之前 就已經少了 2.9 GB。
關於精度：光是擴散模型，bf16 就是 66.28 GB——只有在你知道為什麼的時候才挑它。
fp8_scaled 是 20.96 GB，大小跟 int8_convrot 幾乎一樣；
只有在 int8_convrot 在你的環境裡建不起來的時候才選它。
然後：Workflow → Browse Templates → Video → MiniMax H3。 三個本機範本，另外三個呼叫 API。
你的顯示卡跑得動嗎？
官方沒有最低需求，而你找得到的每一張硬體表都跟其他的兜不攏， 因為它們量的是不同的東西。
殺掉這次執行的是主機 RAM，不是 VRAM
在一張 4090 上跑那套剪枝過的 INT8 組合，取樣期間待在 VRAM 裡的只有大約
6.6 GB——權重住在主機記憶體裡，用到才換進來。
所以這是一次主機記憶體的失敗。有一筆記錄在案的 3090 執行到了
31,997 MB 中的 29,866 MB，被核心殺掉；同一個任務加上
--disable-pinned-memory，尖峰是 7,508 MB，並在 23 分 17 秒跑完。
釘住的記憶體換不出去，這就是為什麼光加 swap 什麼都不會變。
如果你在 0.30–0.31 而且沒辦法更新，那些可重現的做法都改同一個常數——
comfy/supported_models.py 裡的 MiniMaxH3.memory_usage_factor，
從 0.114 改成 1.0。在 0.32.0 或更新的版本上，先更新，
只有在它還是 OOM 的時候才動手改。
量到的執行結果，以及各自背後的硬體
有十四筆執行結果公布得夠詳細，可以歸屬到具體組態。沒有一筆是基準測試—— 沒有人把變數固定住。把它們讀成存在性證明：這個組態跑完了，花了這麼久。
| 顯示卡 | VRAM | 主機 RAM | 畫布 | 長度 | 時間 |
|---|---|---|---|---|---|
| RTX 3060 | 12 GB | 16 GB | 0.2 MP | 5 秒 | 51 分 07 秒 |
| RTX 3060 | 12 GB | 32 GB | 864×480 | 5.17 秒，20 步 | 不到 9 分 |
| RTX 3070 | 8 GB | 32 GB | 0.4 MP | 5 秒 | 約 9–10 分 |
| RTX 4090 Laptop ＋ SageAttention | 16 GB | 32 GB | 960×540 | 5 秒，20 步 | 182 秒 |
| RTX 5070 Ti | 16 GB | 64 GB | 0.4 MP | 5／10／15 秒 | 約 2／4.5／7 分 |
| RTX 5080 | 16 GB | — | 1.0 MP | 10 秒 | 13 分 36 秒 |
| RTX 4090 | 24 GB | — | 832×480 | 15 秒，8 步 | 約 25–30 分 |
| RTX 3090 | 24 GB | 31 GB | — | 15 秒 | 23 分 17 秒 |
| 2× RTX 5090（SGLang，不是 ComfyUI） | 各 32 GB | 377 GiB | 1344×768 | 124 影格，50 步 | 559.67 秒 |
最後那一行是另一個執行環境、兩張卡、377 GiB 的主機 RAM。 列它是為了尺度感，不是為了比較——拿它去推單卡 ComfyUI 的速度是錯的。 在單張 4090 上，同一套做法給的是一個可行性的邊界： 832×480 在 124 和 362 影格都跑得完，1088×640 在 124 影格跑得完， 而 1088×640 在 192 影格、1344×768 在 362 影格都 OOM。
這張卡划不划得來，是另一筆帳。
解析度、影格，以及 17n+5 那張網格
Resolution Selector 上有三個設定會產生寬和高。Multiple 保持在 32—— 那是 H3 的網格。原生畫布是短邊 768 像素，上限 768×1344。 在 16:9 下，Megapixels 填 0.98 剛好給出 1344×768；1.0 這個預設給的是 1376×768，那已經在文件寫的畫布之外了。範本出貨時是 0.4 MP。從那裡開始。 下限是 384p；256p 直接失敗。
影格數在 24 fps 下吸附到 17n+5，所以多數請求都會往上進位。 175 影格是 7.29 秒；沒有 7.00 這個值。整個 4–15 秒的區間裡， 剛好只有一個值落在整秒上：192 影格，8.000 秒。 驗證過的上限是 362 影格，也就是 15.08 秒。
沒有聲音，或者聲音失真
兩種不同的失敗，兩種不同的成因。
沒有聲音是接線問題。 兩個 VAE 都要載入，
而且 VAEDecodeAudio 的輸出必須接到儲存節點。去看檔案，不要看播放器——
你應該看到 24 fps 的 H.264 和 32 kHz 的 AAC 立體聲。
沒有第二條串流表示工作流錯了，不是模型錯了。
ffprobe -hide_banner out.mp4失真是取樣器問題。 H3 讓畫面和聲音跑在兩條 flow 排程上，
shift 12 和 shift 3，而一個單時鐘的取樣器會踩過其中一條。
在 20 步時這個誤差看不見；在 Turbo LoRA 用的 4 步時，它變成削波和雜訊。
ComfyUI 0.31.0 透過 ModelSamplingAV 原生處理兩條排程。
低於那個版本，你需要 larryvrh 的雙時鐘取樣器。
錯誤，以及各自那一行的修法
改任何東西之前先記兩條規則。一次只改一個變數，
並用同一份提示詞和同一個種子重跑——
把 --lowvram、--reserve-vram、--cache-none 和一份量化過的檢查點
一次全疊上去，你最後不會知道是哪一個有效。
還有，先讓一個原始的官方範本跑完，再去加 SageAttention、TeaCache、
EasyCache 或 GGUF 載入器。
| 主控台裡的症狀 | 成因 | 修法 |
|---|---|---|
取樣期間 CUDA out of memory | 畫布 × 影格數超出計畫 | 先降 Megapixels，再降影格數。在 0.30–0.31 上，更新到 0.32.0（#15486） |
| 行程被殺、機器凍住、沒有 CUDA 錯誤 | 主機 RAM。 釘住的記憶體換不出去 | --disable-pinned-memory --disable-async-offload |
| 只有在 VAE 解碼時 OOM | 解碼的配置量跟著影格數走 | 少一點影格或小一點的畫布；更新到 0.32.0（#15477、#15446） |
找不到 MiniMaxH3… 節點或範本 | 核心比 0.30.0 舊 | python main.py --version，更新，重啟 |
| 到處都找不到「文字轉影片」節點 | 誤會一場 | T2V 範本就是什麼都不接的 MiniMaxH3ImageToVideo。不要安裝第三方的替代方案 |
| R2V 工作流上的載入器錯誤 | 選到 FL2VA 檢查點而不是 Ref2VA | 選 minimax_h3_ref2va_pruned_int8_convrot.safetensors |
| 輸出沒有聲音串流 | 聲音 VAE 沒載入，或者 VAEDecodeAudio 沒接到儲存節點 | 兩個都檢查，用 ffprobe 驗證 |
| 聲音削波、嗡叫，或者變成雜訊 | 兩條 flow 排程被同一個時鐘踩 | 更新到 0.31.0（#15243），或用 larryvrh 的 Turbo Sampler |
| 在 256p 生成失敗 | 低於 H3 的 384p 下限 | 用範本的預設值 |
讓它變快，按有效的順序
照這個順序，因為前兩個免費，最後一個要拿品質換。
- 更新。 0.32.0 的 VAE 最佳化和記憶體修正，比任何旗標都值錢。
- 先降畫布，再降長度。 一張 24 GB 的卡上 1 MP 常常跑不完，0.4 MP 跑得完。
- SageAttention。 用
--use-sage-attention啟動，或者用 KJNodes 掛進去。 ComfyUI 估大約快一倍；受卸載拖累的機器看到的比較少。 那些 dtype 回退的警告是預期之內的。 - Turbo LoRA。 larryvrh 的 v4 把取樣從大約 20 步砍到 4–8 步。 用 6–8；4 會把快速運動抹糊，而超過 8 就不再有幫助。
不要把 --lowvram 和 --disable-pinned-memory 一起加。它們互相衝突。
什麼時候不該在 ComfyUI 裡跑它
有三種情況本機是錯的答案，還有一種它明顯是對的。
如果你人在美國、歐盟、英國或南韓而且要自架權重，本機是錯的；授權沒有給你這件事。 如果你要從開放權重拿到 2K，本機是錯的， 因為 Regenerate-2K 從來沒被釋出。 如果你是 8 GB 顯示卡加 16 GB 系統記憶體，本機也是錯的， 那個組合上一支五秒的片子被回報要 51 分鐘。
本機是對的，如果你有 24 GB 的 VRAM、32 GB 的主機 RAM，而且在允許的地區。 ComfyUI 這時給你的批次處理、LoRA 和節點層級的控制， 是任何託管介面都比不上的，包括我們的。 這也是為什麼這裡每一個檔名和旗標都寫出來。
第一次跑失敗之後的問題
我需要自訂節點嗎？ 不用。0.30.0 起原生支援，而那些範本只用核心節點。
為什麼沒有文字轉影片節點？
T2V 範本就是什麼都不接的 MiniMaxH3ImageToVideo。這是設計。
我到底該跑哪個版本？ 0.32.0 或更新。0.30.0 跑得動，但少了九個 H3 修正。
我的輸出為什麼沒有聲音？
兩個 VAE 都要載入，而且 VAEDecodeAudio 必須接到儲存節點。用 ffprobe 驗證。
為什麼在 4 步時聲音會壞？ 單時鐘取樣踩過了聲音那條排程。0.31.0 修好了。
我需要多少硬碟？ T2V 和 I2V 是 42.47 GB，加上 Ref2VA 是 63.44 GB，另外還要快取空間。
一張 12 GB 的卡做得到嗎？ 做得到，靠大量卸載。有一位維護者回報 864×480、124 影格、20 步，不到九分鐘。
我那支 7 秒的片子為什麼跑成別的長度？ 影格數吸附到 17n+5。175 影格是 7.29 秒。
我該用 GGUF 版本嗎？ 沒有官方的。等官方那套跑通之後再試。
我在本機拿得到 2K 嗎？ 從開放權重拿不到。0.33.1 之後你可以把託管的 Regenerate-2K 節點串上去。
如果卡住你的是那 42.47 GB 的下載或那張版本對照表， MiniMax H3 AI 影片生成器 三段全部託管跑完， 沒有東西要裝，也不用顯示卡。
可能會變的事。 這東西每週都在動：去看 ComfyUI 的發行說明裡
比 0.33.1 新的 H3 條目。362 影格的上限是第三方文件寫的，不是官方的上限。
另外 memory_usage_factor 那個修改，在 0.32.0 之後可能已經不必要了。
最後查核 2026-08-14。
