[Benchmark] 先抽到好的再強化：詳解 NVIDIA 的 H3 + LTX-2.5 兩段式影片產線

前言

裁縫不會拿正式的布打版。先用便宜的胚布車一件，版型對了才裁真正的料——因為改版很貴，而那件胚布從頭到尾都不會出現在成品裡。

影片生成一直沒有這道工序。我們在 part 2 換掉了放大器（Real-ESRGAN 109 秒換成 VSR 11.2 秒），在 part 7 把 LTX-2.5 跟 MiniMax-H3 擺在一起對打。這篇是把兩件事接起來：不換放大器，而是換掉「放大」這件事本身。

方法不是我想的。NVIDIA Research 的 Efficient AI 團隊 2026-09-11 發表 Sol-H3-Spark，主張很直接——不要讓生成模型跑在它最貴的解析度上。我把它搬到 RTX 5090 上照著做了一遍。

原生一條線，混合兩段加一個交接

兩條路的終點都是 1344×768、五秒、含音訊。中間做的事完全不同。

原生是一條直線：H3 在 1344×768 的畫布上跑四步，解碼，出片。單一模型、單一解析度、一次付清。

混合分兩段。H3 只在 672×384 工作——那是四分之一的像素——跑完四步之後，把結果交給 LTX-2.5，由它在完整解析度上跑三步精修。

交接那一段是整條路最容易接錯的地方，也是最值得看清楚的地方。

先講一個等下會一直出現的詞：latent。影片模型不是直接畫像素，它在一個壓縮過的空間裡作畫，那個壓縮版本就叫 latent——可以想成尚未沖洗的底片。要變成看得到的畫面得「解碼」，要交給另一個模型接手則得先「編碼」回它認得的底片格式。這條路的交接就是在做這件事：

H3 latent (672×384)
   ↓ 解碼成 RGB
   ↓ 用 LTX 的 VAE 重新編碼
   ↓ LTX 自家的 ×2 latent 放大器
LTX latent (1344×768)
   ↓ 三步精修
   ↓ LTX VAE 解碼
出片

有三件事在圖上看得到、在文字裡容易漏掉：

解析度是在交接之後才變的。 H3 從頭到尾只跑 672×384，處理的 token 數只有完整解析度的四分之一，注意力那一段自然便宜得多。

音訊完全不走第二段。 H3 是單次前傳同時生影像和聲音的模型，那條音軌在草稿階段就完成了，之後直接 mux 進 MP4。所以精修再怎麼重畫畫面，對白和音效都不受影響——中文台詞的品質是 H3 的，跟 LTX 無關。

兩段是兩個獨立的模型堆疊。 這件事在 32 GB 的卡上會變成後面那節的主題。

你需要什麼：一個節點包，零行程式碼

如果你沒接過 ComfyUI：它是一個把 AI 模型接成流程圖的工具，每個方塊叫一個「節點」，你把節點連起來就是一條產線。要多裝的東西只有兩類——幾個節點（別人寫好的功能方塊）和幾個權重檔（模型本體，就是那些幾 GB 的大檔案）。

這條路不用寫任何程式，因為 T8mars 的 comfyui-minimax-h3-audio-T8 已經把 NVIDIA 的第二段實作成現成節點了。三個節點就是整條路：

節點	做什麼
MiniMaxH3SolEngineDraftToLTXT8Advanced	把草稿交給 LTX 之前的整理工：裁掉多餘的幀、把畫面裁成正確的比例
MiniMaxH3SolEngineLTXIdentityRefinerSetupT8Advanced	設定精修要怎麼跑（跑幾步、每步的強度）
LTXVLatentUpsampler	官方的 ×2 放大器，把草稿的底片尺寸拉到輸出尺寸

九個權重檔，分成五種角色

權重檔就是模型本體。這條路兩段各有一套，聽起來很多，但其實只有五種角色，兩段各自都有：

角色	做什麼	H3 那一段	LTX 那一段
主模型	真正在畫畫的那個	minimax_h3_fl2va_pruned_nvfp4 · 11.67 GiB	ltx-2.5-22b-distilled-transformer-int8 · 20.03
讀提示詞的	把你打的字變成模型看得懂的東西	qwen3vl_32b_heretic_minimax_h3_nvfp4 · 14.61	（第二段不需要，理由在進階那節）
影像編解碼	底片與畫面之間的翻譯	minimax_h3_video_vae_fp16 · 4.85	ltx-2.5-video-vae-conv-bf16 · 1.35
音訊編解碼	同上，但管聲音	minimax_h3_audio_vae_fp32 · 0.56	ltx-2.5-audio-vae-bf16 · 0.34
加速用的小檔	讓四步就畫完、讓底片能放大	minimax_h3_fl2v_turbo_4step_v0.1_768p_sla · 1.82	ltx-2.5-latent-spatial-upscaler-x2-bf16 · 0.93

整張 workflow 可以直接下載

不用照著表格自己接。這是我實際跑出本文所有數字的那張，33 個節點、已經重新編號過、沒有任何內部路徑：

⬇︎ minimax-h3-ltx-hybrid-refine.json

拖進 ComfyUI 就會展開。它預設的提示詞是本文那支古風片，換成你自己的就能跑。缺哪個權重檔 ComfyUI 會直接亮紅字，照上面那張角色表去補即可。

⚠️ 這張是前半段教的基本版——完全不用寫 code，也不含後面進階那節拿掉文字編碼器的優化。

H3 那一側的權重我整理成一個 repo，兩顆 transformer、文字編碼器、兩顆 VAE、四步 turbo LoRA 都在裡面，目錄就照著 ComfyUI 的 models/ 排，抓一次就能跑：coolthor/MiniMax-H3-pruned-NVFP4。上面那張 workflow 跟進階那節的無文字編碼器版本也一併放在裡面的 workflows/。LTX-2.5 因為授權不同，沒有鏡像進去，要自己去 Lightricks 抓。

尺寸不能亂挑

輸出的寬高都必須能被 32 整除——這是 LTX 的硬性要求，挑錯了會在放大那一步噴 shape error。

草稿的尺寸則沒有那麼死：SolEngineDraftToLTX 那個節點會自己把解碼後的畫面縮放並置中裁切成輸出的一半，所以你餵別的尺寸它也接。我還是讓 H3 直接生 672×384，理由只是省掉一次重採樣——本來就是要的尺寸，不必先生大再裁小。

為什麼輸出是 32 的倍數？因為兩個模型把畫面壓成底片的倍率不同——H3 是 16 倍、LTX 是 32 倍。1344×768 這組讓兩邊的底片網格剛好一致：

LTX 側   1344 ÷ 32 = 42     768 ÷ 32 = 24
H3  側    672 ÷ 16 = 42     384 ÷ 16 = 24
                      ↑ 兩邊都是 42×24，剛好對上

順帶一提，1344×768 不是 16:9，是 7:4；真正的 16:9 在 768 高度下是 1365.33，除不盡 32。

精修的起跑 sigma 設 0.78，不是官方的 0.909

影片模型作畫的方式是從一團雜訊開始，一步一步把雜訊清掉、圖案浮現。sigma 就是「還剩多少雜訊」的刻度：1.0 是整片雪花，0 是完成品。精修不從雪花開始——它從你的草稿開始，往回加一點雜訊再重畫，加多少就是起跑的 sigma。

加得越多，模型重畫的自由度越大，但它會連你想留的東西一起改掉。

NVIDIA 的 configs/default.json 把第二段的排程寫死成 [0.909375, 0.725, 0.421875, 0]——也就是從 0.909 起跑，等於把草稿加回九成雜訊。照抄那個數字，在 ComfyUI 這條路上會壞。

我量了五格，看背景的直窗框在幀與幀之間有沒有脹縮（那是純背景，任何位移都是瑕疵）：

起跑 sigma	背景脹縮 ≥1px 的幀數（共 120）
不精修	0
0.5（官方 identity 預設）	1
0.65	1
0.78	2
0.85	6
0.909（官方 Sol 排程）	11

不是線性惡化，是懸崖。0.909 那格同時還換了臉——五官被重畫成另一個人，項鍊消失。0.85 就開始改到原本想留的細節（項鍊從方墜變成心形）。0.78 兩個問題同時消失，而且是六格裡最快的一支。

T8 的 identity 精修節點有 manual_exp 模式，直接填：

0.78, 0.643, 0.546, 0

放大器補不回細節，所以它該待在最後

這是這條路最反直覺、也最容易用眼睛驗證的一件事。

先講清楚一件我原本說錯的事：VSR 和 Real-ESRGAN 不是內插，它們是學出來的超解析度網路——VSR 預測高解析殘差、Real-ESRGAN 是 GAN，兩者都會「補」東西出來。

但它們補的東西只能從那張低解析輸入推出來。同一張 672×384 草稿，VSR 把畫布拉到 1344×768，臉的有效像素從 175×161 變成 350×323——而我這支片子上，沒有一根睫毛是新的。

LTX 的三步精修不是在放大，是重新生成：它拿草稿當起點，在完整解析度上再跑一次擴散，所以畫得出草稿裡從來不存在的髮絲、牙齒邊界與皮膚紋理。差別不在「有沒有學習」，在有沒有再跑一次生成。

四格裁在同一個位置、同一個 seed。①②③ 是同一個人——它們共用同一張草稿。④ 是另一個人，因為換解析度就換 latent 形狀、換雜訊。

所以 VSR 不是被淘汰，是站錯位置。它該做的事是把已經有的細節放大到交付尺寸，而不是指望它無中生有補出還沒生成的細節。

加碼：把 VSR 接在精修之後

既然 LTX 已經把細節畫進 1344×768，再讓 VSR 去放大就不是放大一片糊了。實際接起來跑：49.7 秒出 2688×1536，比不接 VSR 的 40.3 秒只多 9.4 秒，換到四倍像素。

這格是順手試出來的，不是這條路的必要環節。但如果你要交付比 1344×768 更大的尺寸，它比在草稿階段放大划算得多

2688×1536，49.7 秒。精修先把細節畫進 1344×768，VSR 再把它拉到四倍像素。

它真正買到的：抽草稿很便宜，精修只付一次

單發比較是這樣的（同解析度、同 seed、每發清模型）：

	冷發
混合 672p 草稿 + LTX 0.78 精修	40.3 s
原生 1344p 四步	51.5 s

快 11 秒。但真正的差別不在這裡，因為沒有人只生一支就收工。

草稿階段單獨跑只要 25.5 秒。所以實際流程是：先多抽幾支草稿，挑到人和構圖都滿意的，再送去精修。

混合   10 × 25.5（抽草稿）+ 50.2（精修中意那支）  ≈ 305 s
原生   10 × 51.1                                  ≈ 511 s

（這是算術，不是實測——三個單項都量過，但這個組合我沒跑過十次。）

而且差的不只是秒數。混合流程不管最後怎麼收尾，都用同一張草稿，所以出來必然是同一個人；原生換解析度就換 latent 形狀、換雜訊、換人。你在 672p 看中的那張臉，到 1344p 重抽會變成別人。

混合把「要哪個人」和「畫多細」拆成兩個可以分開的決定，原生把兩者綁死在同一次擲骰上。

---

進階：量測與踩到的東西

不讀這節不影響使用。上面那條路照著接就會動。

那 15.37 GiB 的文字編碼器可以整個拿掉

第二段的 conditioning 來自 Gemma 編碼的一句話：

4K, refined, high quality, cinematic detail, clean textures, natural motion.

它是常數。正負條件接同一個輸出，沒有任何隨場景變動的輸入。而為了編碼這一句，每次都要載入 gemma4-12b-with-proj-ltx-2.5-comfy-int8-convrot，15.37 GiB。

NVIDIA 原本就沒有這個問題——他們的 config 寫著 "online_text_encoder": false，把這句話離線編碼一次就收工。ComfyUI 的實作沒有那一層。

補上它需要一對小節點（存 / 載 conditioning），然後量到的是：

	冷發	逐幀比對
含 Gemma	48.114 s	—
不含 Gemma	40.260 s	121/121 完全相同

省 7.854 秒（16.3%），畫面完全一樣，連一個位元都沒差。產生快取的那一發要 55.185 秒，但只要跑這麼一次。

逐幀比對我跑了正向與負向兩個對照：拿基準片跟自己比得到「相同」（確認比對程序會回相同），拿不同 seed 的片跟基準比得到「121 幀全部不同」（確認比對程序抓得出差異）。兩個對照都過，那個「121/121 相同」才算數。

H3 的成本隨解析度只成長兩倍，不是四倍

純生成、不放大、四步：

解析度	像素	秒數
672×384	258k	25.5
960×544	522k	28.9
1344×768	1032k	51.1

像素四倍，時間兩倍。注意力的計算量隨序列長度平方成長，但在這個尺寸範圍裡，載入模型、跑 VAE 和編碼也花掉不少時間，所以總耗時沒有跟著翻四倍。

兩段模型塞不進 32 GB，所以每次都在換

把兩段的常駐需求加起來是 71.5 GiB（拿掉 Gemma 之後 56.2）。5090 可用 31.84 GiB。

含 Gemma  71.5 / 31.84 = 2.25 倍
去 Gemma  56.2 / 31.84 = 1.76 倍

連 Stage 1 自己都塞不下（33.5 GiB），所以 ComfyUI 在 H3 那一段內部就已經在換文字編碼器了。

這件事在數字上長這樣——同一張 workflow，第一發清模型（冷）、第二發不清只換 seed（熱）：

	冷	熱	載入吃掉
混合（含 Gemma）	48.1 s	32.2 s	15.9 s
原生四步	51.5 s	41.5 s	10.0 s

混合被載入吃掉的時間比原生多 5.9 秒，因為它要載兩套模型。把載入拿掉，混合快 27%。

⚠️ 熱發那一欄的 execution_cached 節點數是 18 對 10，兩邊跳過的工作量不同，所以熱發的絕對值偏樂觀，只能看相對關係。

三處我刻意偏離官方配方

照著 NVIDIA 的配方做，有三個地方在 32 GB 的卡上必須改：

1. 第二段用 ltx-2.5-22b-distilled-transformer-int8-convrot，不是官方的 dev BF16。 22B 的 BF16 約 44 GB，塞不下。我們手上的 distilled checkpoint等價於「dev 併入蒸餾 LoRA」，強度是 1.0 不是官方的 0.8。
2. 草稿的 LoRA 用 lightx2v 的 minimax_h3_fl2v_turbo_4step_v0.1_768p_sla，不是官方的 FastVideo VSA DataFree。 後者是配 VSA 稀疏注意力的，而我這套裝的節點沒有走那條路。（社群另有 ComfyUI-MiniMax-H3-FastVideo 宣稱在 5090 上測過 VSA，我沒試。）
3. 沒有用 H3→LTX 的 latent adapter。 NVIDIA 有一顆學出來的轉接器（Efficient-Large-Model/H3-to-LTX-Latent-Adapter，389 MB），直接把 H3 的 latent 映到 LTX 空間，省掉一次解碼加一次編碼。我把它包成 ComfyUI 節點跑過，tensor shape 逐項對上、轉換本身只花 0.177 秒——但在 5090 上總時間沒有變快，因為省下的 VAE 來回被新增的 H3 latent 放大器吃掉了。它在記憶體上是有意義的（少載一顆 VAE 編碼器），只是我們這張卡本來就每次都在換模型，吃不到那個好處。

量測方法

所有秒數取自 ComfyUI /history 的 execution_success 減 execution_start 時間戳，除以 1000。每一發都確認 execution_cached.nodes 是空的（冷發）或記下長度（熱發）。冷發前送 POST /free {"unload_models":true,"free_memory":true}。

同批次量到的誤差約四秒——672p 原生 那發 25.5 秒、加了 VSR 的那發反而 21.9 秒，而 VSR 只會加時間不會減。所以任何小於四秒的差距我都不會當成結論。

外部參考

• NVIDIA Sol-H3-Spark — 方法與配方常數的出處
• T8mars / comfyui-minimax-h3-audio-T8 — 讓這條路零程式碼可跑的節點包
• Lightricks/LTX-2.5
• Efficient-Large-Model/H3-to-LTX-Latent-Adapter

同系列

• 把放大器從 Real-ESRGAN 換成 VSR：625 秒砍到 314 秒
• 同一句中文台詞，LTX-2.5 用 29 秒、MiniMax-H3 用 81 秒