MiniMax H3 ComfyUI 本地部署：33B開源權重、2K API與硬體限制

先講結論：本地推理、模型權重、API 與 GPU 記憶體需求。

Q1 這個工具／模型在解決什麼？ 本文整理MiniMax H3 ComfyUI的技術與使用方式，核心是本地推理、模型權重、API 與 GPU 記憶體需求。

Q2 核心技術或概念是什麼？ 主要規格或功能包含33B 開源權重、2K API、ComfyUI 與硬體限制。

Q3 哪些規格或功能最重要？ 版本、API、權重、硬體或推理模式是建立基本輪廓的入口。

Q4 為何值得注意？ 值得注意的是，宣稱規格不等於所有情境的實際表現。

Q5 實作或落地時的限制是什麼？ 落地時要考慮成本、硬體、授權、相容性和資料限制。

Q6 新手如何入門？ 入門可先定義使用情境，再對照官方文件與實測。

Q7 評估時可注意什麼？ 評估時應分開看品質、延遲、價格、穩定性和可重現性。

Q8 如何避免常見誤解？ 不要只用最大數字或新聞標題判斷技術價值。

Q9 最後應記住什麼？ 理解MiniMax H3 ComfyUI要把功能、限制、驗證和需求放在一起。

<

p class=”wp-block-paragraph”>MiniMax H3已正式釋出33B H3-Base權重，ComfyUI 0.30.0以上也已提供Text-to-Video、Image-to-Video與Reference-to-Video原生工作流。本地H3-Base可生成4至15秒、24fps、32kHz立體聲的768p影音；官方完整2K流程則仍需搭配未開源的H3-Context-IR與H3-Regenerate-2K API，不能把「權重已開放」理解成整套2K系統完全離線。

H3的核心是把文字、圖片、影片與音訊放進同一個上下文，再共同生成畫面、人聲、音效與音樂。它已能在ComfyUI中本地執行，但官方沒有公布RTX 3060或RTX 5090的最低VRAM、生成時間與穩定規格；硬體判斷仍應以實際工作流、解析度、秒數與量化版本驗收。

MiniMax Research 官方文章將 H3 定位為可理解文字、圖片、影片與音訊的多模態生成模型，並記錄 2026 年 7 月 31 日的發布資訊；本文用官方主視覺辨識模型，不把官方描述替代成本、速度或畫質的本地實測。

• MiniMax H3是33B Dense、單一串流的H3-Omni-Transformer。
• 輸出長度4至15秒、24fps，音訊為32kHz立體聲。
• 穩定支援中文、英文、日文、韓文等11種對話語言。
• H3-Base已公開FL2VA與Ref2VA兩組任務權重。
• ComfyUI 0.30.0以上原生支援T2V、I2V與R2V模板。
• ComfyUI官方推薦INT8 diffusion model、NVFP4 AWQ文字編碼器及獨立影音VAE。
• 本地H3-Base原生畫布短邊768px，最高約768×1344。
• 完整2K需要H3-Regenerate-2K；該模組尚未開源，目前透過API使用。
• H3-Context-IR也是託管服務，不包含在開放權重內。
• License是MiniMax H3 Community License，不是Apache 2.0。

MiniMax H3目前的開放範圍

模組	功能	開放狀態
H3-Base FL2VA	文字生影音、首幀／尾幀／首尾幀生影音	已開放BF16權重及ComfyUI量化版本
H3-Base Ref2VA	圖片、影片、音訊混合參考生影音	已開放BF16權重及ComfyUI量化版本
H3-Context-IR	理解複雜多模態素材並重寫成結構化生成描述	未開源，提供官方API及提示詞指南
H3-Regenerate-2K	把768p結果與原始上下文重新生成為2K	未開源，提供官方API
Native Sparse Attention	降低長序列推論成本	初始權重版尚未包含，官方表示後續釋出

因此，「MiniMax H3已開放權重」是正確的；「完整2K系統可以完全離線執行」則不正確。純本地工作流目前主要驗證H3-Base的768p生成，完整官方2K品質需要API參與。

33B模型架構的意義

H3-Omni-Transformer是33B參數的Dense單一串流Transformer，其中約13B位於AdaLN相關分支。官方指出，AdaLN調制輸出可預先計算及快取，因此純推論部署不必載入全部相關參數；完整權重仍被釋出，以支援微調及後續研究。

模型另外使用Qwen3-VL-32B完整預訓練權重作為H3-Encoder，再配合H3-VisualVAE與H3-AudioVAE。這說明硬體需求不能只用「33B×每參數位元」計算，因為實際工作流還包含文字／視覺編碼器、影像VAE、音訊VAE、影片Latent、KV Cache與ComfyUI框架開銷。

輸出規格與參考素材限制

影片長度	4至15秒
幀率	24fps
本地原生解析度	短邊768px，最高約768×1344
完整2K	透過H3-Regenerate-2K API
音訊	32kHz Stereo
圖片參考	最多9張
影片參考	最多3段，每段2至15秒，總長不超過15秒
音訊參考	最多3段，需搭配圖片或影片，不能單獨作為唯一輸入
混合檔案	總數最多12個

R2V的重點是替每份參考素材指定角色，例如人物身份、視覺風格、鏡頭運動、動作或聲音。只把多個檔案丟進節點，卻沒有說明彼此關係，通常會降低控制力。

ComfyUI原生工作流的開始方式

1. 更新ComfyUI至0.30.0或更高版本。
2. 開啟Template Library，進入Video分類。
3. 選擇MiniMax H3 T2V、I2V或R2V模板。
4. 依跳出視窗下載Comfy-Org／MiniMax-H3模型檔案。
5. 先使用模板預設的低解析度與短秒數測試。
6. 確認畫面與立體聲均能輸出後，再提高Megapixels及Duration。

官方模板已包含Native MiniMax H3節點，不需要依賴第三方H3 Custom Node。T2V與I2V共用FL2VA權重；R2V則必須使用另一組Ref2VA權重，兩者不能互換。

ComfyUI官方推薦的模型檔案

T2V與I2V

• minimax_h3_fl2va_pruned_int8_convrot.safetensors
• qwen3vl_32b_minimax_h3_nvfp4_awq.safetensors
• minimax_h3_video_vae_fp16.safetensors
• minimax_h3_audio_vae_fp32.safetensors

R2V

• minimax_h3_ref2va_pruned_int8_convrot.safetensors
• qwen3vl_32b_minimax_h3_nvfp4_awq.safetensors
• minimax_h3_video_vae_fp16.safetensors
• minimax_h3_audio_vae_fp32.safetensors

Comfy-Org倉庫同時提供BF16、Pruned BF16、INT8及FP8 diffusion model，以及BF16、INT8和NVFP4 AWQ文字編碼器。不同版本的速度、VRAM與品質需要自行測試，不能假設量化檔在所有GPU與CUDA版本都同樣穩定。

T2V、I2V與R2V的選擇方法

模式	適合工作	主要限制
T2V	概念片、氣氛鏡頭、短廣告與快速素材	角色及商品一致性較依賴提示詞
I2V	人物圖、商品圖、首幀或首尾幀動畫	動作需與輸入構圖相容
R2V	固定人物、風格、動作、鏡頭與聲音參考	需要另一組權重，參考整理及Prompt更複雜

角色短劇或商品廣告不應直接從T2V開始。先用I2V固定外觀，再以R2V測試聲音、動作及鏡頭參考，通常更容易定位失敗原因。

2K與單純放大的差異

H3的2K流程不是傳統Super Resolution。H3-Regenerate-2K會把768p結果與原始文字、圖片、影片及音訊上下文重新送回模型，讓系統重新生成細節，而非只對像素插值。

這個模組目前沒有開放權重。完整2K驗證流程是：使用H3-Context-IR API整理上下文，本地H3-Base生成768p，再把影片與原始上下文送到H3-Regenerate-2K API。需要完全離線的團隊，現階段只能停在768p或使用自己的後期放大方案。

RTX 3060與RTX 5090的執行差異

官方已提供量化ComfyUI檔案，但沒有公布RTX 3060 12GB、RTX 4090或RTX 5090的最低VRAM、生成秒數與峰值RAM。MiniMax的SGLang官方示例使用4張GPU及Ulysses Degree 4，反映原始BF16部署仍是多GPU工作負載。

硬體	合理用途	不能保證
RTX 3060 12GB	INT8／NVFP4、低解析度、短秒數的功能測試，可能高度依賴RAM卸載	15秒768p能在可接受時間穩定完成
RTX 4090／5090	量化模板、較高解析度與較少卸載，適合建立單機Benchmark	BF16完整工作流無需卸載即可運行
多GPU工作站	原始權重、SGLang／vLLM服務與較高吞吐	ComfyUI所有節點均能自動有效分散
API	最快驗證完整2K與Context-IR品質	符合離線、隱私與長期成本需求

真正可比較的測試必須固定模型檔、ComfyUI版本、解析度、幀數、秒數、Attention、GPU、RAM、offload及生成種子。沒有這些條件的「可以跑」缺乏生產意義。

Sage Attention的使用條件

ComfyUI官方教學表示，Sage Attention可讓生成速度約提高一倍，品質損失有限。它是選配套件，需要安裝與PyTorch、CUDA版本相符的wheel，並透過KJNodes或--use-sage-attention啟用。

H3部分層不是FP16／BF16，控制台可能出現回退到PyTorch Attention的提示。這是預期行為，不代表整個工作流失敗；正式使用仍應比較速度、顯存與逐幀品質。

Community License的使用注意事項

MiniMax H3採用專用的MiniMax H3 Community License Agreement，不是Apache 2.0、MIT或一般Creative Commons。商業使用、衍生模型、量化散布、使用限制與責任應直接閱讀License全文。

模型能生成品牌文字、人物與聲音，不代表使用者自動取得商標、肖像、配音、音樂或參考素材權利。台灣團隊仍需保存素材來源、授權、提示詞、模型版本及輸出審查紀錄。

台灣團隊的最小驗收流程

1. 安裝ComfyUI 0.30.0以上並先載入官方模板。
2. 使用INT8 diffusion model、NVFP4文字編碼器與官方VAE。
3. 先生成4至5秒、低Megapixels的T2V，確認影音都存在。
4. 再測I2V首幀、尾幀與首尾幀控制。
5. 最後才下載Ref2VA權重，加入人物、動作與聲音參考。
6. 逐次記錄VRAM、RAM、時間、錯誤、音畫同步與人物漂移。
7. 需要2K時，比較官方Regenerate API與本地第三方放大的成本及品質。
8. 正式量產前檢查中文、台語、品牌文字、Logo、手部及多鏡頭一致性。

本地部署與模型使用疑問

MiniMax H3權重的公開狀態

是。MiniMaxAI／MiniMax-H3已在Hugging Face公開H3-Base FL2VA與Ref2VA權重，採MiniMax H3 Community License。

ComfyUI原生支援H3的狀態

是。ComfyUI 0.30.0以上的Template Library已有H3 T2V、I2V及R2V模板與原生節點。

本地生成2K的條件

官方本地H3-Base主要輸出768p。完整2K需要尚未開源的H3-Regenerate-2K API，或自行使用其他本地放大工具。

H3的參數規模

H3-Omni-Transformer為33B Dense模型，其中約13B位於可預先計算及快取的AdaLN相關分支。

RTX 3060的可執行範圍

官方沒有提供RTX 3060基準。量化與Dynamic VRAM可能讓低規格測試成為可能，但不能承諾速度或15秒768p生產能力。

RTX 5090執行完整模型的條件

可優先測試ComfyUI量化模板，但官方沒有保證單張5090可無卸載運行BF16完整工作流。應以實際VRAM、RAM及秒數Benchmark判斷。

H3同時生成人聲、音效與音樂的能力

可以。H3會共同預測影片及音訊Latent，輸出32kHz原生立體聲，對話、音效與音樂在同一次生成中建立同步關係。

R2V可放入的素材數量

最多9張圖片、3段影片及3段音訊，混合檔案總數不超過12個；音訊不能單獨作為唯一輸入。

H3現在可以本地使用，但完整系統仍是混合架構

MiniMax H3已從「預告開放」進入真正可下載、可用ComfyUI模板執行的階段。33B Dense模型、原生立體聲與多模態參考，讓它具備角色短片、商品廣告、MV及預演的實際價值。

同時，官方最佳流程仍依賴託管的Context-IR與2K Regeneration；本地硬體也缺少統一的RTX 3060／5090基準。較可靠的導入方式，是先跑官方768p模板、建立自己的性能表，再決定是否使用API補齊2K與複雜上下文。

2026 最新的 MiniMax H3 ComfyUI 官方工作流選擇

這篇文章的 Search Console 查詢已經明確集中在「minimax h3 comfyui」「minimax h3 本地部署」與「minimax h3 開源」。因此真正需要補上的，不是再說一次 H3 能生成影片，而是把官方模板、模型資料夾、解析度設定與第一次驗收順序整理成可以照做的清單。以下內容以 2026 年 8 月 10 日讀取的 MiniMax 與 ComfyUI 官方文件為準；版本、模板與模型檔案會更新，下載前仍應重新查看官方頁面。

先決定 T2V、I2V 還是 R2V

• T2V：只有文字提示詞時使用，適合先確認安裝、提示詞與音訊輸出是否正常。
• I2V：已有商品圖、角色圖或首幀／尾幀時使用；先固定視覺構圖，再測試動作。
• R2V：需要鎖定人物身份、風格、鏡頭運動或聲音時使用；它會混合圖片、影片與音訊參考，所需的整理工作與顯存壓力也較高。

三者不是三個互不相干的第三方節點包，而是 ComfyUI 官方文件列出的原生工作流。T2V 與 I2V 使用 FL2VA 類型的 diffusion model；R2V 要換成 Ref2VA 類型。遇到「找不到模型」時，第一個檢查點不是重新下載全部檔案，而是先確認工作流模式與檔名是否對得上。

第一次啟動的四個檢查點

1. 將 ComfyUI 更新至官方文件標示的 0.30.0 或更高版本，從 Template Library → Video 選擇 MiniMax H3 模板。
2. 讓模板引導下載模型，並確認 diffusion model 放在 ComfyUI/models/diffusion_models/、文字編碼器放在 ComfyUI/models/text_encoders/、兩個 VAE 放在 ComfyUI/models/vae/。
3. 第一次只跑短秒數、低 Megapixels 的 T2V；不要一開始就加上 R2V 多素材或追求最高解析度。
4. 驗收要同時看 MP4 是否產生、畫面是否符合提示詞、音訊是否存在、Console 是否出現模型路徑或 dtype 錯誤。四項中任何一項失敗，都先記下版本、模型檔、GPU、RAM、解析度與 seed，再換設定。

解析度與速度：不要把 2K、768 短邊與 Megapixels 混在一起

ComfyUI 官方 H3 模板用 Resolution Selector 管理 aspect ratio、Megapixels 與 Multiple。Multiple 維持 32，可以讓寬高落在 H3 的解析度網格；16:9 時，官方文件把約 1.0 Megapixel、約 1344×768 視為原生畫布方向的高品質起點。較低 Megapixels 主要用來做快速驗收，並不等於同一支影片已經完成 2K 輸出。

本地開放權重與官方 API 的 2K 路徑要分開記錄：本地模板先解決模型、節點、音畫與參考素材的可重現性；需要完整 2K 或複雜上下文時，再依官方 API 文件評估託管流程、成本與資料權限。不要把 API 的規格直接寫成單機 ComfyUI 的最低硬體保證，也不要把一次成功誤寫成 RTX 3060、4090 或 5090 的固定基準。

最小可重現 Benchmark

如果要回答「本地部署到底能不能跑」，至少固定五個條件：ComfyUI 版本、模型檔與量化格式、GPU／VRAM／系統 RAM、輸出寬高與秒數、seed 與提示詞。T2V、I2V、R2V 應分開記錄；每次只改一個變數，保存生成時間、峰值 VRAM、是否卸載、音畫同步、角色漂移與錯誤訊息。這份表比一句「可以跑」更適合台灣團隊做採購、隱私或 API 成本決策。

官方工作流頁提供 T2V、I2V 與 R2V 範例，也列出模型下載位置、解析度節點與 Prompt 寫法。若你要把本頁當作部署入口，請先打開官方教學確認最新版本，再回到本文依上述順序做小樣本驗收。

本段引用的官方更新來源

• ComfyUI 官方 MiniMax H3 Workflow Examples：版本門檻、T2V／I2V／R2V 模板、模型路徑、Resolution Selector 與 Prompt 提示。
• MiniMax Research 官方 H3 介紹：多模態上下文、原生立體聲與模型設計邊界。
• Comfy-Org 官方模型倉庫：ComfyUI 使用的模型檔案與版本，下載前請以倉庫現況為準。
• MiniMax 官方 API 文件：需要 API 2K 或託管生成時的另一條驗證路徑。

核對日期：2026 年 8 月 10 日。本段是查詢意圖與官方文件的內容更新，不是硬體效能測試，也不承諾排名、CTR、流量、互動、轉換或收益改善。

MiniMax H3 2026 年 8 月 14 日現況：本地 ComfyUI、2K API 與 33B 權重怎麼分

截至 2026 年 8 月 14 日重新核對官方文件後，MiniMax H3 最容易被誤解的地方不是「能不能生成影片」，而是把三個不同層次混成同一件事：MiniMax Research 的產品與 API 規格、Hugging Face 上的開放權重與部署格式，以及 ComfyUI 的本地工作流。這篇文章保留原本的 33B、音訊、解析度與硬體討論，以下用最新官方頁面重排成可以直接回答「H3 是什麼、怎麼跑、2K 是否等於本地輸出、圖片要放哪裡」的查證版本。

先給結論：三條路徑不要互相替代

• 本地 ComfyUI：ComfyUI 官方文件目前要求 0.30.0 或更新版本，從 Template Library 的 Video 分類選擇 MiniMax H3 工作流；官方示例分成 T2V、I2V 與 R2V。這條路徑的價值是可以逐項檢查模型、節點、素材、解析度與輸出檔，不能直接承諾任何 GPU 的固定速度。
• Hugging Face 開放權重：MiniMaxAI 官方模型卡把 H3-Omni-Transformer 描述為 33B dense、single-stream Transformer，並說明完整權重、FL2VA 與 Ref2VA 任務家族及 diffusers／原始 checkpoint 的分層。下載前要先確認模型卡的 license、檔案格式、任務家族與部署框架，不要把「有權重」改寫成「所有商用情境都無限制」。
• MiniMax API／託管路徑：MiniMax Research 官方介紹寫的是最高 15 秒、2K 與原生立體聲等產品規格；API 文件另列出 ratio、resolution、duration 與輸入類型。API 的 2K 規格不等於 ComfyUI 本地模板的最低顯存，也不等於離線或零資料傳輸。

截至本次核對的可引用規格

問題	官方可確認內容	不能從這個欄位推出的結論
H3 是什麼	MiniMax Research 將它定位為可理解文字、圖片、影片與音訊的多模態影片生成模型，並強調影片與原生立體聲音訊可以一起生成。	不能因此保證每種角色、品牌文字、口型、動作或音樂都穩定正確。
本地工作流	ComfyUI 官方頁提供 T2V、I2V、R2V 範例；I2V 也可走首幀／尾幀圖片，R2V 可混合圖片、影片與音訊參考。	三個模板是官方示例，不代表只有三種工作流，也不代表所有第三方節點都已相容。
本地解析度	Resolution Selector 由 aspect ratio、Megapixels 與 Multiple 計算寬高；官方頁把 16:9、約 1.0 Megapixel、約 1344×768 說成 H3 原生畫布方向的高品質起點，Multiple 以 32 配合解析度網格。	1344×768 的本地模板起點不等於 2K；較高 Megapixels 也不等於固定畫質或固定速度。
API 2K	MiniMax Research 與 API 文件均提供 2K／比例／秒數等託管生成脈絡；實際可用參數、帳號權限與錯誤回應仍以當下 API 文件為準。	不能把 API 服務的 2K 寫成單機 ComfyUI 的輸出保證，也不能以文件範例宣稱已完成一次實際生成。
模型權重	MiniMaxAI 官方模型卡標示 33B dense、single-stream Transformer，並提供不同任務家族與格式的下載／部署說明；ComfyUI 官方模型倉庫則是對應工作流的另一個入口。	33B 是模型規模描述，不是品質排名、VRAM 最低門檻、每秒速度或商業成效。

T2V、I2V、R2V：從輸入素材決定模型家族

T2V 適合第一次確認安裝與提示詞：只放文字，先驗收工作流能否產出含畫面與音訊的 MP4。I2V 適合已經有商品圖、角色圖或首幀／尾幀時使用；測試表應留下原圖尺寸、裁切方式、提示詞、seed、秒數與輸出解析度。R2V 則要把每個參考素材的責任說清楚，例如圖片負責人物身份、影片負責動作、音訊負責聲音或氛圍；參考素材越多，越需要固定順序與命名，否則失敗時無法判斷是模型、素材還是提示詞造成。

ComfyUI 官方文件把 FL2VA 與 Ref2VA 視為不同的原生節點／任務路徑。實務上遇到「找不到模型」或節點報錯時，先查三件事：工作流是 T2V／I2V 還是 R2V、目前下載的是哪一個任務家族、模型是否被放到模板所要求的目錄；不要先把全部 checkpoint 和量化檔重新下載一次。

安裝與驗收順序：把可重現性放在畫質之前

1. 先記錄 ComfyUI 版本、作業系統、GPU、VRAM、系統 RAM、Python／CUDA 環境與工作流檔案版本；本輪官方文件的版本門檻是 ComfyUI 0.30.0 或更新版本。
2. 從 Template Library → Video 開啟 MiniMax H3 官方模板，讓模板引導模型下載；同時保存模型來源、任務家族、量化格式與檔案 hash，避免只記「H3 已下載」。
3. 先跑短秒數與預覽 Megapixels 的 T2V，驗收 MP4 是否有畫面、音訊、合理的 Console 訊息與完整輸出檔；再逐項提高 Megapixels 或 duration。
4. 接著用固定圖片做 I2V，最後才加入 R2V 的圖片、影片與聲音參考。每次只改一個變數，保存 seed、輸入檔、輸出檔、峰值 VRAM、生成時間、卸載設定與錯誤訊息。
5. 若要比較 API 2K，另建一筆 API 測試紀錄，把 prompt、ratio、resolution、duration、輸入素材、回應 task id、成本、資料傳輸與輸出 URL 分開保存；API 結果不能當作完全離線的本地基準。

搜尋常見問題的短答案

MiniMax H3 可以本地部署嗎？

可以沿 ComfyUI 官方工作流與 Hugging Face 模型卡建立本地驗收路徑，但能否在特定 GPU、VRAM、RAM、量化格式與秒數下完成，要由自己的測試紀錄回答；官方頁面沒有替所有硬體提供固定最低門檻。

MiniMax H3 的本地輸出是 2K 嗎？

不能直接這樣說。ComfyUI 官方文件以 Resolution Selector 管理本地畫布，16:9 約 1.0 Megapixel 時約為 1344×768；2K 是 MiniMax Research／API 文件中的另一個託管規格層，兩者要分開標示。

33B 是否代表一定比其他影片模型好？

不是。33B 只是官方模型卡的參數規模描述；品質、速度、顯存、音畫同步、角色一致性與商業授權都需要指定條件的獨立測試或文件證據。

官方圖片能證明 H3 已在本機成功生成嗎？

不能。本文使用的官方 ComfyUI I2V 輸入圖只用來辨識工作流與輸入素材脈絡，圖片本身不證明本文作者的本機生成、固定畫質、速度、人物一致性或商業授權結果。

圖片與來源的 current verification

本文的官方 I2V 圖片在 2026 年 8 月 14 日重新核對：來源為 ComfyUI 官方 workflow_templates 的透明外殼電競滑鼠輸入圖，source 與 yololab 部署 PNG 均為 1,383,312 bytes，SHA-256 完全相同。圖說只描述「官方 I2V 工作流的輸入素材」，不把它誤標成本文本機截圖；alt、可見 caption、media description 與來源連結也維持同一個 provenance。這種圖片證據適合說明輸入格式與工作流位置，不適合單獨回答速度、畫質、模型排名或商用合規。

本輪官方資料與更新界線

• ComfyUI 官方 MiniMax H3 工作流文件：0.30.0 版本門檻、T2V／I2V／R2V、原生節點、模型來源與 Resolution Selector。
• MiniMax Research 官方 H3 介紹：多模態上下文、原生立體聲、最高 15 秒／2K 等產品規格與研究脈絡。
• MiniMaxAI 官方 Hugging Face 模型卡：33B 架構、FL2VA／Ref2VA、模型檔案、部署框架與 license。
• Comfy-Org 官方模型倉庫：ComfyUI 對應的模型格式與工作流入口。
• MiniMax 官方 API 文件：輸入類型、比例、resolution、duration 與 API 回應邊界。

本段核對日期為 2026 年 8 月 14 日。供應商頁面、模型檔、license、API 權限與模板會更新；使用前請重新打開官方來源。本段證明的是 current-date 內容、來源分層、圖片 provenance 與可重現驗收方法，不證明搜尋排名、CTR、自然流量、生成式引擎實際引用、收入或因果 ROI。

延伸閱讀

• Qwen生態系2026與Wan 2.2
• NVIDIA RTX Spark與128GB個人AI PC
• Qwen3.8-Max正式API與權重狀態

官方資料來源

• MiniMax官方：H3發布、15秒、2K與技術設計
• MiniMax官方Hugging Face：33B架構、權重、License與本地部署
• ComfyUI官方：原生T2V、I2V與R2V模板
• Comfy-Org：量化模型檔與資料夾位置
• MiniMax API：完整2K與多模態輸入

三種官方工作流怎麼選：先看輸入素材

ComfyUI 官方 MiniMax H3 工作流頁目前把原生範例分成 T2V、I2V 與 R2V 三條路徑。T2V 是文字生影片，適合先確認模型、音訊與輸出節點能否正常運作；I2V 以圖片作為輸入，也可以接首幀或尾幀控制；R2V 則把人物、風格、動作、鏡頭或聲音拆成不同參考素材。三者是官方提供的範例模板，不代表 H3 只有這三種生成方式，實際還能透過原生節點組合更多工作流。

T2V：第一次安裝先從文字生影片開始

第一次驗收應先選 T2V，因為輸入變數最少。官方文件建議把 ComfyUI 更新到 0.30.0 或更高版本，再從 Template Library 的 Video 分類選擇 MiniMax H3 工作流，依模板提示下載模型。先用短秒數與預覽尺寸確認 MP4、畫面、原生立體聲與 Console 訊息都正常，再逐一提高 Megapixels、Duration 或加入參考素材；不要在模型尚未載入時同時排查解析度、R2V 素材與 Sage Attention。

I2V 與 R2V：圖片控制和多模態參考要分開記錄

I2V 的核心問題是輸入圖片能否穩定轉成動態畫面，因此測試表要記錄圖片尺寸、首幀／尾幀設定、提示詞、seed 與輸出秒數。R2V 則不應把所有素材丟進去再凭感覺判斷；官方建議用文字指派每個參考的工作，例如哪一張圖片負責人物身份、哪一段影片負責動作、哪一段聲音負責聲線。R2V 使用 ref2va 權重，和 T2V、I2V 使用的 fl2va 權重不同，模型檔不能混用。

解析度節點要先固定，再談速度與品質

官方工作流的 Resolution Selector 由 aspect ratio、Megapixels 與 Multiple 三個設定共同計算寬高。Multiple 維持 32，是配合 H3 解析度網格的起點；16:9 若把 Megapixels 調到約 1.0，輸出約為 1344×768，仍屬 H3 的原生畫布方向。這裡的「預覽尺寸」「原生 768 短邊」與「官方 API 的 2K」是三個不同驗收層級，不能把其中一個數字直接改寫成單張 GPU 的最低硬體保證。

第一次可重現驗收清單

1. 先確認 ComfyUI 版本、工作流模式與 diffusion model 類型相互對應。
2. 記錄 GPU、VRAM、系統 RAM、模型量化格式、解析度、秒數與 seed。
3. 先跑 T2V 預覽，確認 MP4 同時有畫面與音訊，再測 I2V。
4. 最後才加入 R2V 的圖片、影片與聲音參考，並為每個素材指定用途。
5. 若要比較 2K API，另開一筆測試記錄成本、資料傳輸與結果，不把 API 結果當成完全離線基準。

本文新增的官方示例圖只用來辨識 MiniMax H3 官方頁展示的生成畫面與工作流脈絡，不是本機測試截圖，也不代表固定的畫質、速度、人物一致性或商業授權結果。版本、模板與模型檔會更新，實際下載與使用前請回到 ComfyUI 官方 MiniMax H3 工作流頁及 MiniMax H3 官方介紹重新核對。