Lab Notes · 2026.08.03
MiniMax H3 本地實測
MiniMax H3 是一個全模態生成模型:影像與立體聲音訊在同一次前向裡一起生成, 嘴型不是事後對上去的,而是跟聲音一起長出來的。 這一篇記錄它在本地 ComfyUI 的完整配置、兩條工作流的差別、多重參考的實際接法, 以及在 RTX 5090 上的真實生成時間與長度限制。
這篇是什麼
ScopeComfyUI 官方文件已經有一份 MiniMax H3 的說明,涵蓋模型介紹、三個範本工作流與模型下載位置:
本文不重複官方文件,而是把它實際跑一遍之後的結果補上去。模型配置與工作流骨架都依官方說明;我們調整的是參數、輸入的參考素材與參考音,記錄的是官方沒有列出的部分——實際生成時間、長度與音訊品質的衰減曲線、首格與末格的服從程度差異,以及多段串接的做法。
成品先看
Result下面這支是本文全部設定跑出來的最終結果:三段各約 10 秒、接成 27.5 秒的連續自拍鏡頭。人物、服裝、場景在三段之間保持一致,嘴型與語音同步,聲音是預先用本地 TTS 產生後餵進模型的參考音。
一、模型配置
SetupComfyUI 官方模板庫已內建 H3 的工作流,節點也已進主線(本文使用 ComfyUI 0.29.0)。模型放在 ComfyUI/models/ 對應資料夾即可,不需要自訂節點。
| 類別 | 檔案 | 大小 | 用途 |
|---|---|---|---|
| diffusion_models | minimax_h3_ref2va_pruned_int8_convrot | 19.5 GB | Reference-to-Video(多重參考) |
| diffusion_models | minimax_h3_fl2va_pruned_int8_convrot | 19.5 GB | Image-to-Video(首/末幀) |
| text_encoders | qwen3vl_32b_minimax_h3_nvfp4_awq | 14.6 GB | 文字編碼器(兩條共用) |
| vae | minimax_h3_video_vae_fp16 | 4.85 GB | 影像 VAE |
| vae | minimax_h3_audio_vae_fp32 | 0.56 GB | 音訊 VAE |
兩條工作流共用文字編碼器與兩顆 VAE,所以第一條跑完之後,要加跑另一條只需再下載一個 19.5 GB 的擴散模型。全部備齊約 59 GB。
CLIPLoader 的 type 必須選 minimax,不是預設值。
其二,量化版本要對得上硬體——本文用的 nvfp4_awq 文字編碼器需要 Blackwell 世代(RTX 50 系列)才有原生支援,
舊卡請改用 int8_convrot 或 bf16 版本。
二、兩條工作流的差別
WorkflowsH3 在 ComfyUI 裡有兩個核心節點,差別不在畫質,而在你能餵給它什麼。這個選擇會直接決定成品能不能用。
| 節點 | 可餵的參考 | 聲音來源 | 適用 |
|---|---|---|---|
MiniMaxH3ImageToVideo | first_frame / last_frame | 模型自己生成 | 不在意音色的短片 |
MiniMaxH3ReferenceToVideo | ref_images ×9 · ref_videos · ref_audios | 可指定參考音 | 需要固定人物與固定聲音 |
兩者都會生出同步的嘴型,但 ImageToVideo 沒有音訊輸入,音色每次都由模型自行決定。若要角色的聲音固定,就必須走 ReferenceToVideo,把預先產生的語音接到 ref_audios。
依官方文件,Reference-to-Video 可接的參考素材上限為 9 張參考圖、3 段參考影片(各可帶自己的音軌)、3 段獨立參考音。另有一個 ref_image_size 參數:match 會把參考圖縮到生成解析度(較快),max 則使用 2048px 短邊以取得更強的身份保真,代價是參考的 token 會參與每一個取樣步,速度慢上數倍。本文全部使用 match。
<Picture 1>,第一段參考音就是 <Audio 1>。
並且要「Assign each reference a job」:在提示詞裡說清楚哪一個參考負責身份、哪一個負責畫面、哪一個負責聲音。
參考音有兩種用法,由提示詞的措辭決定:寫成音色參考時,模型會借用音色但另外生成台詞;寫成 use <Audio 1> exactly as it is 時,會照著那段語音的內容與節奏生成畫面。後者是「讓角色說出這段話」的做法。
需要留意的是,它並非位元層級的複製——輸出會經過音訊 VAE 重建,高頻略有損失(實測 4 kHz 以上能量佔比由 21.5% 降到 15–18%)。若需要原始音質,可在後製把原音軌換回去;本文成品即採此做法。
三、提示詞是有結構的
Prompting這是 H3 與多數影片模型最不一樣的地方:它的提示詞不是一段散文,而是有欄位的結構文件。官方指南定義了六個區塊,其中 subject_definitions 負責宣告每一個參考素材代表什麼——參考圖是誰、參考音屬於誰。
三件實務上會影響成敗的事:
1. 每一個標籤都必須先被定義。提示詞裡出現的 <Picture N>、<Audio N>,都要對應到實際接上的輸入,並在 subject_definitions 裡說明它是什麼。指向不存在的素材時模型不會報錯,只會忽略那個指令。
2. 對白要內嵌在鏡頭敘述裡。官方指南明寫對白應 appear inline within the shot description, not appended separately。附加在段落最後會被當成背景音軌處理。
3. 說話是一個「可見動作」,要寫進去。畫面內說話與旁白的差別,在於前者需要明確描述嘴部動作(嘴唇隨字句開合、下巴與臉頰起伏),後者才使用 says in an off-screen voiceover 並註明雙唇閉合。動作描述位在鏡頭敘述的中段,權重高於段末的通用句——因此描述裡若出現「微笑」「安靜」這類靜態表情,會蓋過說話指令。收尾的表情動作建議寫成「說完最後一個字之後」才發生。
四、多重參考與連續鏡頭
Multi-Reference單段長度有上限(見下節),所以較長的影片必須分段。分段的關鍵在於每一段要從什麼起跑。
可行的做法是先產生數張彼此連貫的參考圖,再讓它們同時擔任「上一段的末格」與「下一段的首格」:
| 段 | 首格 | 末格 |
|---|---|---|
| 第 1 段 | A | B |
| 第 2 段 | B | C |
| 第 3 段 | C | —(自由收尾) |
這樣安排的好處是每一段都從原始畫質起跑,段與段之間不會互相影響。實測首格與末格的服從程度並不對稱:
| 檢查項目 | 與指定圖的相似度 |
|---|---|
| 各段首格 vs 指定圖 | 0.990 / 0.990 / 0.981 |
| 各段末格 vs 指定圖 | 0.788 / 0.918 |
首格是硬約束,末格是軟約束。模型幾乎完美地從指定圖起跑,但結尾只是往指定方向靠近。因此接縫的品質上限由末格決定:實務上可把交界處當成一個剪接點,或加上約 0.2 秒的交叉淡入;交界用的參考圖,也建議選動作幅度小、姿勢中性的構圖。
五、人物一致性
Consistency在只給一張參考圖的情況下,測試人物原地轉一整圈——中途完全背對鏡頭、臉部消失數秒——再轉回正面,檢查是否仍是同一個人。攝影機全程固定,以便確認旋轉來自人物而非運鏡。
| 量測 | 數值 | 意義 |
|---|---|---|
| 首幀 vs 末幀 · 臉部區域 | 0.976 | 轉身遮擋後身份保持 |
| 首幀 vs 末幀 · 整幀 | 0.984 | 構圖與光線一致 |
| 背景區域 · 首幀 vs 末幀 | 0.991 | 確認攝影機確實固定 |
髮飾位置、指甲顏色、頸部小痣等細節在旋轉前後一致。進一步讓人物轉完後走到不同位置、改用不同姿勢收尾(脫離參考圖的姿態),臉部特徵同樣保持——顯示一致性並非只是「回到參考姿勢時看起來像」。
六、尺寸、長度與幀數規則
ConstraintsH3 的畫布有明確限制:短邊最大 768、長邊最大 1344,且兩邊都必須是 32 的倍數。因為 720 不是 32 的倍數,直式 720P 實際要取 736。
| 比例 | 480P | 720P |
|---|---|---|
| 9:16 直式 | 480 × 864 | 736 × 1312 |
| 16:9 橫式 | 864 × 480 | 1312 × 736 |
幀數不是任意值,必須落在 17k + 5 的網格上(24 fps):
官方標註的訓練區間是 124–362 幀(5.17–15.08 秒)。最後那個 while 迴圈很重要:只做網格吸附時,算出來的長度可能比語音短零點幾秒,尾音會被截掉且不會有任何錯誤訊息。
七、硬體與生成時間
Benchmark測試環境:RTX 5090(32 GB VRAM)· ComfyUI 0.29.0 · 480P · 24 fps · steps 20 · res_multistep 取樣器。實際峰值顯存使用在 30 GB 以內。
| 幀數 | 影片長度 | 生成時間 | 每幀成本 |
|---|---|---|---|
| 124 | 5.17 s | 101 s | 0.81 s |
| 209 | 8.71 s | 231 s | 1.11 s |
| 226 | 9.42 s | 246 s | 1.09 s |
| 260 | 10.83 s | 307 s | 1.18 s |
| 362 | 15.08 s | 526 s | 1.45 s |
成本是超線性的,解析度與長度都是。畫布由 480×864 放大到 736×1312(像素 ×2.33)時,生成時間變為 ×3.32;同一解析度下,每幀成本也隨序列變長而上升(209 幀 1.11 秒/幀 → 362 幀 1.45 秒/幀)。因此估算時程時,不能只用面積比或幀數比線性外推。
本文成品的實際數字:
| 項目 | 數值 |
|---|---|
| 成品規格 | 480 × 864 · 24 fps · 661 幀 · 27.5 秒 |
| 三段生成時間 | 246 s + 277 s + 241 s = 764 s(12.7 分) |
| 實時倍率 | 約 27.7× |
依實測的每幀成本(平均 1.156 秒/幀)推估其他規格:
| 目標 | 切法 | 純影片生成 | 端到端(含備料) |
|---|---|---|---|
| 480P · 30 秒 | 3 段 × 10 秒 | 約 14 分 | 約 20 分 |
| 480P · 30 秒 | 4 段 × 7.5 秒 | 約 15 分 | 約 21 分 |
| 720P · 30 秒 | 3 段 × 10 秒 | 約 43 分 | 約 49 分 |
「端到端」另外包含備料時間:三張參考圖約 4 分鐘、三段語音約 1.5 分鐘。這兩項不吃影片模型的顯存,可與其他工作並行。
結論
Takeaways把上面的實測整理成幾條可以直接拿去用的結論:
影音同源是這個模型的核心價值。畫面與立體聲在同一次前向裡生成,省掉「先生語音、再做對嘴」的第二段流程,也不會有兩段之間的時間軸漂移問題。代價是音色由模型決定,需要固定聲音時必須走 Reference-to-Video 餵參考音。
構圖限制比上一代寬鬆很多。手持自拍視角、邊走邊說、原地旋轉這類過去容易導致「身體凍結、只有嘴在動」的構圖,在 H3 上可以正常運作,不需要為了防止崩壞而遷就第三人稱固定機位。
提示詞的結構比詞彙重要。H3 讀的是有欄位的結構文件,素材要先宣告、對白要內嵌、說話要當成可見動作寫出來。這三點沒做到時模型不會報錯,只會安靜地產出一支看起來正常、但缺了關鍵行為的影片。
10 秒是目前的實用單位。模型上限 15 秒,但語音在後段會瓦解;以 10 秒為一段、用連貫的參考圖串接,是現階段兼顧品質與效率的做法。
本文所有數據皆為單機實測,環境為 RTX 5090 + ComfyUI 0.29.0,測試日期 2026 年 8 月 3 日。生成時間會隨顯示卡、驅動與取樣器設定而異。
參考資料
References模型說明、範本工作流與模型下載位置,均以 ComfyUI 官方文件為準;本文的角色是在其之上補上實測數據與參數調整的結果。
| 來源 | 內容 |
|---|---|
| ComfyUI 官方文件 | 模型定位與能力、T2V/I2V/R2V 三個範本、模型檔案與存放位置、畫布與 17k+5 幀數規則、參考素材上限與 ref_image_size |
| 本文(單機實測) | 各長度的實際生成時間與每幀成本、超線性倍率、音訊隨長度的衰減曲線、首格/末格服從程度、多段串接做法、參考音的接法與音質影響 |
模型權重來自 Hugging Face 上的 Comfy-Org/MiniMax-H3;提示詞結構依 MiniMax 官方的 video prompt writing guide。