[Benchmark] 同一句中文台詞，LTX-2.5 用 29 秒、MiniMax-H3 用 95 秒：一張 5090 的實測

前半段是 MiniMax-H3，後半段是 LTX-2.5，同一段雙人台詞，我先把兩段的響度都調到 −16 LUFS，再接在一起。

前言

買菜的時候你會同時看兩個攤子的價錢，但不會拿一斤的價格去比一兩的。比兩個影片模型也一樣：要讓兩邊講同一句話、在同一張卡上、用各自的原生工作點跑，才有得比。

這個系列前六篇都在磨 MiniMax-H3 怎麼在一張 RTX 5090 上跑得動、跑得快、跑得出對白。這一篇換個方向：Lightricks 在 8 月 11 日開源了 LTX-2.5，它也會講話、也會對嘴，那它在同一張卡上是什麼速度。

28.67 秒對 81.22 秒：同一句台詞的兩邊數字

台詞是這一句，兩邊逐字相同：

今天的汤头特别浓，先喝一口暖暖身子，再慢慢告诉我你的故事。

25 個簡體漢字，對應大約 5.17 秒。H3 的中文台詞一定要用簡體，繁體會讓句子中段崩壞，這是這個系列第一篇就量過的事。

	解析度 × 幀	步數	取樣秒	整個流程	整合響度	CER
MiniMax-H3	1344×768 · 124	14 + Spectrum	66.40	81.22	−25.1 LUFS	0%
LTX-2.5	1280×704 · 121	8 + 3	14.31	28.67	−10.4 LUFS	0%

兩邊解析度不同，不能直接相減。畫素乘幀數的負載，LTX 大約是 H3 的 85%。就算把那 15% 補回去，取樣那一段還是差三倍以上。

同一句台詞、同一張卡，上面是 H3、下面是 LTX-2.5。兩邊的場景是各自生的，不是同一個畫面的兩種畫質。

差距來自步數。LTX-2.5 的蒸餾版走兩段取樣，第一段 8 步、中間把 latent 放大兩倍、第二段 3 步，總共 11 次前向。H3 走 14 步，其中 Spectrum 幫它預測掉 5 步，實際算 9 次。11 對 9，次數差不多，時間差三倍——所以差的不是次數，是每一次的成本，而那主要是解析度與模型結構。

響度那一欄差了 15 dB。H3 的原生輸出一直落在 −30 到 −34 LUFS，比一般內容低 15 到 20 dB，出片前要補增益。LTX 的 −10.4 已經接近一般內容水準，那一步可以省掉。

1344×768 不是我挑的，是兩條限制夾出來的唯一整數

這個系列從第一篇開始就用 1344×768，我一直以為那是某個人先用了、大家跟著抄。實際上它是算出來的。

MiniMax 官方的 model card 寫短邊預設 768 像素，而 ComfyUI 這條路要求寬高可以被 32 整除。短邊 768 要湊 16:9，寬度得是 768 × 16 ÷ 9 = 1365.33，連整數都不是。往下對齊到最近的 32 倍數就是 1344 = 42 × 32。

所以嚴格講，1344×768 並不是 16:9 —— 1344 ÷ 768 = 1.75，那是 7:4。它是「16:9 想要的那個寬度」往下取到合法值之後剩下的東西。

旁證有兩個：NVIDIA 的 Sol-Engine 基準用 1344×768 乘 124 幀，FastVideo 的 H3 蒸餾模型就是在 768×1344 乘 124 幀訓練的。兩邊獨立撞上同一組數字。

LTX-2.5 的限制不一樣：幀數除以 8 要餘 1。所以 121 幀合法（15×8+1），124 幀不合法。H3 那邊是 17k+5 的網格，124 = 17×7+5。兩邊的幀數規則不能互套，這是我第一次接 LTX workflow 時撞到的第一堵牆。交集不是沒有——73、209、345 三個數字兩邊都合法（209 = 26×8+1 = 12×17+5），但那三個點都不在各自的原生工作點上。

LTX-2.5 要五個檔，一個都不能少

從 Lightricks/LTX-2.5 抓，放進 ComfyUI 對應的資料夾：

放哪	檔名	磁碟大小
diffusion_models/	ltx-2.5-22b-distilled-transformer-comfy-int8-convrot.safetensors	20.03 GiB
text_encoders/	gemma4-12b-with-proj-ltx-2.5-comfy-int8-convrot.safetensors	14.32 GiB
vae/	ltx-2.5-video-vae-conv-bf16.safetensors	1.35 GiB
vae/	ltx-2.5-audio-vae-bf16.safetensors	0.34 GiB
latent_upscale_models/	ltx-2.5-latent-spatial-upscaler-x2-bf16-1.0.safetensors	0.93 GiB

三個要注意的地方。

一定要 distilled 不要 dev。 dev 版兩種量化都會產出糊掉像融化的畫面。

影像 VAE 要挑 conv 那個。 repo 裡還有一個 ltx-2.5-video-vae-bf16，大小差不多，但第三方在 5090 上量到換成 conv 版整體快 22.5%，解碼段從 8.91 秒砍到 4.68 秒，峰值 VRAM 幾乎不動（31,692 MB 變成 31,728 MB，多 36 MB）。純換檔。

那個 latent 放大器不是選配。 官方藍圖是兩段取樣，中間夾一個 LTXVLatentUpsampler 把 latent 放大兩倍，少了它整條鏈接不起來。我第一次接這條 workflow 時漏了這個檔，是回頭讀官方範本才補上的。

取樣參數照官方藍圖，兩段各有一組手動 sigma：

取樣器    euler_ancestral
導引      LTXVDualCFGGuider [1, 1]
第一段    1.0, 0.99375, 0.9875, 0.98125, 0.975, 0.909375, 0.725, 0.421875, 0.0   (8 步)
          ↓ LTXVLatentUpsampler ×2
第二段    0.85, 0.7250, 0.4219, 0.0                                              (3 步)
幀率      LTXVConditioning [24]
解碼      VAEDecodeTiled [512, 64, 64, 16] + LTXVAudioVAEDecode
音影鏈    LTXVSeparateAVLatent / LTXVConcatAVLatent

處理音訊與影像的那串節點不能省，接錯會報 split_with_sizes。

對白要放在引號裡，兩邊的語法不一樣

LTX-2.5 有一個把台詞放進引號、並指明語言與口音的模板：

[Speaker] is speaking [Language/Accent], saying: "[Dialogue]"

它的 model card 標了九種語言，中文在裡面，沒有單列粵語（沒列不等於不會，只是官方沒標）。

🔴 那個模板出自官方文件的 Dub-It（語音替換）那一節，而那一節開頭就寫「Unlike text-to-video generation」。 我一開始把它當成 LTX-2.5 的通用對白語法，那是範圍錯置。文生影那條路上，官方沒有給這麼具體的模板。

H3 那邊不一樣，它用 (S1) (S2) 標說話者，而且標籤本身不帶身分——身分要寫在主體描述裡，<Subject 1> (S1), a young woman with shoulder-length black hair… 這樣。同時說話才用 (S1,S2)。這個系列第六篇講 Ref2VA 時整理過完整的六段式格式。

雙人輪流兩邊都做得到，LTX 少了開頭兩個字

這是我原本以為會分出高下的一格，因為我把幾條限制讀成了通則。

Lightricks 自家的 Dub-It IC-LoRA 文件明文寫 beta 版只處理一個說話者、不區分多說話者——但同一頁也寫它還沒在 LTX-2.5 上驗證過。另外 ComfyUI-LTXVideo 有一個 2026-01-28 開到現在還沒關的 issue，回報 Character A / Character B 會隨機對到錯的台詞、兩人常常同時講話；串上有兩則留言但都不是官方，而且回報者自己寫了他跑的是 LTX-2 的蒸餾版，不是 2.5。

所以那幾條都不是「LTX-2.5 做不到多說話者」的證據。我當時把它們疊起來當成通則了。

我用這兩句跑：

S1（年輕女性）  这碗汤是你煮的吗，闻起来好香。
S2（中年男性）  是我煮的，趁热喝吧。

	取樣秒	整個流程	峰值 VRAM	S1 CER	S2 CER	整段 CER
MiniMax-H3	67.94	94.82	31,811 MiB	0%	0%	0%
LTX-2.5	14.34	29.21	31,729 MiB	15.38%	0%	9.52%

兩邊都真的輪流講，沒有搶話。 我另外做了四項檢查：

ASR 的 timestamp 不重疊。H3 是 S1 落在 0.00 到 2.40 秒、S2 落在 3.02 到 4.88 秒；LTX 是 S1 在 0.00 到 1.54 秒、S2 在 2.56 到 4.84 秒。

逐幀看嘴形，動嘴的都是該講話的那個人。LTX 那支在 0 到 1.4 秒是女性嘴形持續變化、男性大致閉嘴，2 到 4.8 秒換成男性說話、女性閉嘴看著。

交棒那一段幾乎沒有聲音。我用 20 毫秒的 window 算 RMS 包絡，H3 的交棒區是 0.000296、LTX 是 0.000646，各自只有前一句平均音量的 1.1% 到 1.2%。

基頻也對得上。H3 兩段的中位數是 242 Hz 掉到 104 Hz，LTX 是 286 Hz 掉到 130 Hz，都是前高後低。

差別在逐字完整度。 LTX 漏掉開頭的「这碗」兩個字。我給音訊前後各補 0.75 秒靜音重跑一次 ASR，還是少同樣兩字，所以不太可能只是轉錄工具的片頭邊界問題。H3 那邊兩句都是零錯誤。

要說清楚這裡的限制。混合音訊的單條包絡分不出說話者，轉錄工具也可能漏掉重疊的聲音，所以「有停頓」不等於「每一毫秒都沒有疊音」。基頻不能證明說話者身分。而且這是 n=1、一組台詞、一個場景。

兩個都只剩不到 900 MiB 餘量

這是我最沒預料到的一格。直覺會以為快三倍的那個比較輕，實際上兩邊都貼著天花板。

	峰值 VRAM	卡的總量	餘量
LTX-2.5	31,736 MiB	32,607 MiB	871 MiB
MiniMax-H3（雙人那發）	31,811 MiB	32,607 MiB	796 MiB

兩個都是「剛好塞得下」，不是「有空間」。有人回報 LTX-2.5 拉到 8 秒 720p 會撞牆；也有人回報把 decode 的 tile 調小之後跑完了 15 秒。所以那不是一條硬上限，是跟工作流綁在一起的。我這組設定的餘量就是上面那個數字。

---

進階：VRAM 的峰值落在哪裡

不讀這節不影響使用。前面說兩邊都只剩不到 900 MiB，這一節是那個數字怎麼量出來的，以及我試著把它壓下來的結果。

LTX 的峰值在第二段取樣，調小 decode tile 是壓錯段

LTX-2.5 只剩 871 MiB 餘量，問題是壓哪裡。VAEDecodeTiled 跑的是 512 的 tile，是最好動的一個旋鈕，所以值得先確認峰值到底落在哪個節點。

量法是這樣：那一發留了 123 筆 VRAM 取樣和 114 筆執行事件，而執行事件帶 elapsed_s。把兩邊的時間軸對起來，就能切出每個節點區間各自的峰值。

節點	區間峰值
CLIPTextEncode	19,032 MiB
UNETLoader	16,632 MiB
第一段取樣	31,653 MiB
LTXVLatentUpsampler	31,466 MiB
第二段取樣	31,736 MiB
VAEDecodeTiled	30,873 MiB
SaveVideo	27,193 MiB

峰值在第二段取樣，而第一段只差 83 MiB。兩段取樣都貼著天花板，解碼比它們都低。

從這張表也能看出另一個重點：文字編碼那段是 19,032 MiB，載入 transformer 之後掉到 16,632，表示 text encoder 編完就釋放，不跟 transformer 同時常駐。把文字編碼器換成更小的量化版，對取樣峰值沒有幫助。

NVFP4 的檔小 2.59 GiB，峰值反而多 72 MiB

取樣期間常駐的是權重，所以換小一點的權重檔是最直接的做法。同一個 repo 有 NVFP4 版，18,721,548,408 bytes，比 int8-convrot 少 2.59 GiB。

那個版本之前有災情：取樣階段報維度不符。root cause 是 checkpoint 的 __metadata__ 缺 _quantization_metadata，ComfyUI 於是默默 drop 掉量化的 scale tensor，拿打包過的 FP4 權重直接進線性層。官方在 HF 討論串說已修復。⚠️ 我沒辦法獨立證實「只重傳檔案、完全沒改程式」——那是我從「ComfyUI 那邊的 issue 仍然開著」推的，不是看到檔案修訂差異。但不論修在哪一端，早期抓的本機檔都要自己驗一次。

驗這件事不用下載 18 GB。safetensors 的檔頭就是前 8 個 bytes 的 little-endian u64 長度，加上那麼多 bytes 的 JSON。所以下載前可以用兩個 HTTP range request（先抓 0-7 拿長度，再抓那一段 JSON）驗遠端那份；下載後用本機讀檔驗自己手上這份：

import struct, json
with open(path, 'rb') as f:
    n = struct.unpack('<Q', f.read(8))[0]
    meta = json.loads(f.read(n)).get('__metadata__', {})
print('HAS _quantization_metadata:', '_quantization_metadata' in meta)

我用 range request 對 repo 上現行那一份驗過，_quantization_metadata 在，7,877 個 tensor。所以現在抓就是好的那一份。

換過去之後，同一份 workflow、只換 base model：

	int8-convrot	NVFP4
檔案大小	21,504,034,224 bytes	18,721,548,408 bytes
取樣秒	14.307	13.547
整個流程	28.668	28.815
峰值 VRAM	31,736 MiB	31,808 MiB
餘量	871 MiB	799 MiB
CER	0%	0%

取樣快了 5.32%，整個流程持平（多 0.147 秒）。峰值不但沒降，還多了 72 MiB，餘量從 871 掉到 799。 這是我自己從 149 筆取樣重算過的，不是抄報告。

因為檔案在硬碟上多大，跟跑起來佔多少 VRAM，是兩回事：磁碟上的 FP4 是打包過的，實際參與運算要先展開，展開後的工作 dtype 跟省下來的那 2.59 GiB 沒有直接關係。逐節點看，第一段取樣兩邊幾乎一樣（31,653 對 31,648），真正往上跑的是中間那個 latent 放大器（31,466 變成 31,776）。

可以直接拿去用的一句：檔案小不等於常駐小，要省 VRAM 得看逐節點的峰值落在哪。

最後一件要標的：這一發出現了 [WARNING] unet unexpected:，1,176 個 key 全部是 .comfy_quant 結尾，沒有任何一個 scale key。所以它跟舊版那個「丟掉 scale tensor 導致維度不符」不是同一件事——畫面正常、CER 0%、沒有報錯。但這行 warning 不能無視，只有它會告訴你哪些 key 被默默 drop 掉了。單次量測，沒有重複、沒有統計顯著性。

收尾：兩個模型現在各站哪一格

LTX-2.5 更快，而且快得不只一點——同一句台詞的整個流程是 28.67 秒對 81.22 秒。中文對白它過得了機器那關，逐字比對是 0%。雙人輪流它也做得到；官方那條單一說話者的限制只適用於語音替換（Dub-It），不管文生影的對白。

H3 這次把台詞講完整了，一個字都沒漏。雙人那發它兩句都是零錯誤，LTX 吃掉了開頭兩個字。而逐字正確正是我用 H3 的理由。

「換誰比較省」這個問題在 32 GB 的卡上沒有答案。

還沒做的三件：等響度化之後的人耳盲測還沒做，咬字錯誤率看不出自然度；嘴型對位沒有量過，T8 的節點包裡有現成的 av_delta_ms 我還沒用；LTX-2.5 的中文自然度全世界都沒有量化評測，我這次只填了「機器聽得懂」這一格。

外部參考

• Lightricks/LTX-2.5 model card
• Comfy-Org/workflow_templates

同系列

• 在一張 RTX 5090 上跑 MiniMax-H3：四個檔、31.7 GB、每支會講話的片 175 秒
• 兩張人設圖餵進去，讓小販跟書生自己演完自相矛盾：MiniMax-H3 Ref2VA 入門