LTX-2.5 是近來熱門的影音模型，這個 22B 影音生成模型跑在 128GB 統一記憶體的 ARM 機器上，CyberQ 測試了三種工作流程全部跑通。 比較意外之處，是發現節點最少的 flf2v 反而最慢，而號稱有原生 FP4 算力加持的 NVFP4，在基準解析度只快 2.3%，幾乎埋在雜訊裡，但它的優勢會隨 token 數成長。
最後，我們把同一台機器上的 MiniMax-H3 也拉來跑同一個測試去比較速度和品質差異，它們的權重量幾乎相同，但測試時間差 14 倍， 而這樣的差距呢，我們從 token 數的耗用量就可以知曉原因了。
本次測試的軟硬體說明
NVIDIA DGX Spark 這台機器的特點是 128GB 統一記憶體，一般 24GB 顯卡要煩惱的放不放得下在這裡不是問題， 連 bf16 全套（transformer 42GB + 文字編碼器 26GB）都塞得進去。真正的限制是記憶體頻寬與 ARM 生態的相容性。
| GPU | NVIDIA GB10（sm_121，Blackwell），驅動 580.173.02，CUDA 13.0 |
| 記憶體 | 128GB 統一記憶體 |
| 架構 | aarch64，Linux 6.17 |
| PyTorch | 2.9.1+cu130，bf16 matmul 實測 62 TFLOPS（4096³） |
| ComfyUI | 27bca654（v0.32.0 之後；LTX-2.5 支援在 57ce8e1a 與 ce4fc130） |
PyTorch 對 sm_121 會發出超出支援範圍的警告（該版本宣告上限 sm_120），但 CyberQ 這次測試時，其實際運算全部正常。
權重檔與相容性
| 檔案 | 大小 | ComfyUI | 說明 |
|---|---|---|---|
...distilled-transformer-comfy-int8-convrot | 21.50 GB | 可用 | 官方版本，ComfyUI 範本預設 |
...distilled-transformer-nvfp4 | 18.72 GB | 不可用 | 官方版本，但是給 ltx-pipelines 的 ModelOpt 格式 |
...distilled-transformer-nvfp4-comfy | 18.72 GB | 可用 | 第三方轉檔，補上 ComfyUI 描述子 |
gemma4-12b-with-proj-ltx-2.5-comfy-int8-convrot | 15.37 GB | 可用 | 文字編碼器 |
ltx-2.5-video-vae-bf16 / audio-vae-bf16 | 1.83 GB | 可用 | 影像與音訊 VAE |
ltx-2.5-latent-spatial-upscaler-x2-bf16-1.0 | 1.00 GB | 可用 | t2v / i2v 第二階段用 |
三種工作流程的差別在取樣階段
三個官方範本是我們這次測試的要角，主要是載入模型 → 取樣 → 解碼的過程，但 t2v/i2v 與 flf2v 的取樣策略不同， 這是後面速度差異的主要原因。
| 工作流程 | 取樣階段 | 節點數 | 特有節點 |
|---|---|---|---|
| t2v | 兩階段：8 步 @ 640×352 → latent 上採樣 → 3 步 @ 1280×704 | 38 | — |
| i2v | 同 t2v 兩階段 | 44 | LTXVImgToVideoInplace ×2、LTXVPreprocess |
| flf2v | 單階段：8 步全部 @ 1280×704，無上採樣 | 37 | LTXVAddGuide ×2、LTXVCropGuides |
flf2v 的節點數最少，卻是最慢的一個。因為決定成本的不是節點數，而是步數 × 該步的解析度。 把兩者換算成「百萬像素．步數」會是這樣：
| 工作流程 | 階段一 | 階段二 | 合計 |
|---|---|---|---|
| t2v / i2v | 8 × 0.225 = 1.80 | 3 × 0.901 = 2.70 | 4.51 MP·步 |
| flf2v | 8 × 0.901 = 7.21 | — | 7.21 MP·步 |
理論比值 7.21 / 4.51 = 1.60，實測 107.79 / 61.89 = 1.74。 差距落在引導幀的 VAE 編碼與全解析度解碼上，量級吻合，以上這類算式可以拿來預估任何新解析度的成本。
實測速度比較
全部條件相同：1280×704、5 秒、24fps、含同步音訊、distilled 8 步。 數字取 ComfyUI 伺服器端回報的 Prompt executed，不含排程與輪詢。兩張圖共用 120 秒座標軸，可直接互相比較。 三種工作流程 int8-convrot 權重，模型已駐留記憶體
NVFP4 值不值得
第一眼看到的是 81.0s 對 67.5s，差 17%，但那次 int8 是從 NVMe 冷讀 21.5GB。檔案進了 page cache 之後變成 71.4s 對 67.5s，而扣掉載入的純運算是 61.9s 對 59.7s，只差 3.5%。
GB10 有原生 FP4 tensor core，理論上該更快，沒發生的原因是這條 pipeline 的時間並非由線性層主導 ，包括 attention、VAE 解碼、diffusion video decoder 都不吃 FP4 這種模型帶來的好處。再加上 NVFP4（18.7GB）與 int8（21.5GB）的檔案大小只差 15%，頻寬紅利本來就有限。
所以 CyberQ 建議，如果你用 NVFP4 模型，其實只換到一點點時間的加速，但代價是採用第三方轉檔、加上官方不背書、以及一些細節要處理等等，所以建議生產環境直接用官方 int8-convrot 更適合。
看品質，PSNR 要用對地方
CyberQ 用同一個 seed 種子去比較兩種量化，直覺會想算 PSNR。第一次這樣做得到 13.8 dB，看起來像災難，實際上兩支影片各自都很好，只是構圖完全不同。量化改變了去噪軌跡，同 seed 走到了另一個同樣合理的解，逐像素指標在這種情況下可以跳過。
換到 seed 43 時兩者構圖恰好重合，PSNR 18.1 dB，這時比較才成立，int8 的毛髮與臉部細節略實，NVFP4 略軟。差異存在但不大。
PSNR 真正好用的地方是引導幀的忠實度，有明確的參考影像：
| 量測 | PSNR | 判讀 |
|---|---|---|
| i2v 產出首幀 vs 輸入圖 | 34.18 dB | 肉眼幾乎一致 |
| flf2v 產出首幀 vs 引導首幀 | 33.38 dB | 貼合良好 |
| flf2v 產出末幀 vs 引導末幀 | 30.04 dB | 貼合良好，略遜於首幀 |
| int8 vs NVFP4（seed 43，構圖重合） | 18.15 dB | 量化造成的實際差異 |
| int8 vs NVFP4（seed 42，構圖發散） | 13.76 dB | 無意義，不同取樣結果 |
i2v／flf2v 的首幀不會是 100% 還原，因為引導圖會經過 LTXVPreprocess（img_compression=18）與 VAE 往返。
同一台機器上的另一個選擇 MiniMax-H3
這台機器上同時裝著 ComfyUI 版的 MiniMax-H3，一樣是影音同步生成、一樣有官方範本。 兩個模型放在同一顆 GB10、同一份 ComfyUI 上跑同一件事，是難得乾淨的對照條件。我們設定的條件對齊是 1280×704、5 秒、24fps、含同步音訊、模型已駐留記憶體。
同樣的輸出規格，H3 要 866 秒，LTX 要 61.9 秒，差 14.0 倍。為何會有這樣的顯著差距呢，CyberQ 認為，並不是因為 H3 是更大的模型，兩者的權重量其實幾乎一樣，重點是推論方式和品質。
| 組成 | LTX-2.5 | MiniMax-H3（ComfyUI 版） |
|---|---|---|
| DiT | 21.50 GB int8-convrot | 20.97 GB pruned int8-convrot |
| 文字編碼器 | gemma4-12b 15.37 GB | qwen3vl-32b nvfp4-awq 15.69 GB |
| VAE 等其他 | 2.83 GB（含上採樣器） | 5.82 GB（影像 5.21 + 音訊 0.61） |
| 合計 | 39.70 GB | 42.49 GB |
| 層數 / hidden | 48 層 / 4096 | 50 層 / 5376 |
這兩種模型的權重只差 7%，但產生影片的時間差 14 倍，差距的產生來自於需要算多少 token、算幾次。
一、H3 沒有蒸餾
CyberQ 是以 ComfyUI 官方給的範本來測試，LTX 用的是 distilled 權重，8 步。H3 範本是 BasicScheduler 20 步。單這一項就是 2.5 倍。
二、H3 的 latent 密得多
LTX 的 latent 壓縮是空間 32、時間 8，H3 則是是空間 16、時間約 3.35 （frames 124 → latent_t 37，公式 ((f−5)/17)×5+2）。
H3 的 DiT 會再對 latent 做一次 2×2 patchify，抵掉一半空間密度，但會留下明顯落差。我們同樣卻去看 1280×704、5 秒，進 DiT 的序列長度的差異呢，是 H3 32,560 對 LTX 14,080，約為 2.31 倍。
三、LTX 有 8/11 的步數跑在四分之一解析度
LTX 的兩階段策略讓 8 步只在 640×352（3,520 token）上跑，只有最後 3 步進全解析度。 H3 是單階段，20 步全部吃 32,560 token。
| 1280×704 · 5s | 每步 token | 步數 | token·步 |
|---|---|---|---|
| LTX 階段一（640×352） | 3,520 | 8 | 28,160 |
| LTX 階段二（1280×704） | 14,080 | 3 | 42,240 |
| LTX 合計 | — | 11 | 70,400 |
| H3（單階段） | 32,560 | 20 | 651,200 |
因此上面這三種原因的差異，全部疊起來是 9.25 倍的工作量差距，但實測是 14.0 倍，剩下的 1.51 倍是 attention 的平方項。而這個推論有實測可以驗，我們把 H3 自己降到 864×480 重跑一次。
| 設定 | 每步 token | 實測 | 每 token·步 |
|---|---|---|---|
| LTX 1280×704 | 14,080（階段二） | 61.89s | 0.879 ms |
| H3 864×480 | 14,985 | 287.51s | 0.959 ms |
| H3 1280×704 | 32,560 | 866.0s | 1.330 ms |
CyberQ 指出，這個測試的關鍵在最後一欄。H3 在 864×480 的每 token·步成本是 0.959 ms， 和 LTX 的 0.879 ms 幾乎一樣，所以呢，H3 的每 token 成本並沒有比較差。但把 token 數拉到 2.17 倍，成本跳到 1.330 ms，時間變成 3.01 倍。 縮放指數 ln(3.01)/ln(2.17) = 1.42，自然就超過線性。
對照本文前面的 LTX 測試，這就是 H3 慢的主要原因，它把整支 5 秒片子當成一條 32,560 token 的序列做 self-attention， 而 LTX 用兩階段把大部分步數留在四分之一長度的序列上。
最後一項差別是權重載入
不但如此，載入也有差喔，H3 從 page cache 載入 42.5GB 要 83 秒，LTX 是 9.5 秒，差距有 8.7 倍，比權重量的差距（1.07 倍）大得多，這是因為 H3 模型採用的 qwen3vl-32b 文字編碼器與兩個 VAE ，總是是分開的四份檔案， 而且中間夾著量化描述子的解析。在兩個模型之間來回切換時，這 83 秒每次都要支出時間。
那該用哪一個好呢 ?
如果只看速度，LTX 自然是快多了，即使讓 H3 跑它自己範本預設的 864×480（像素只有 LTX 的 65%）， 287.5 秒仍是 LTX 在 1280×704 的 4.65 倍。 要在這台機器上做迭代式的影音創作，改 prompt、調 seed、看結果再改，LTX 的 1 分鐘和 H3 的 14 分鐘是兩種完全不同的工作方式。
但是品質的話， H3 比 LTX 好，這是無庸置疑的，H3 的 20 步非蒸餾取樣，在運動連貫性、prompt 依從度、音畫同步的精準度都比 LTX 2.5 好，速度比較慢並不等於 H3 不夠好，只是它在這台機器上並不適合當互動式工具，而是需要細細品味，搭配好的提示詞來完成更好看的影片作品。
比較範圍的限制
另外說明一下，CyberQ 在本文這次測的是 ComfyUI 版的 H3，它是調整過的版本加上 int8-convrot 量化的 20.97GB DiT。 同一台機器上，CyberQ 另外用工具跑的是 135GB 的 FL2VA 完整權重，這就是是另一份模型了，精緻度會更高。
小插曲，連續重負載會讓機器直接斷電
第一次跑這組 H3 測試時，CyberQ 的 GB10 機器在取樣到 16/20 步時整台斷電。 journal 停在最後一筆例行 cron 就沒有了：沒有 Out of memory: Killed process、 沒有 critical temperature reached、沒有任何關機序列。 當下系統記憶體用 81.7GB／121GB，還剩 40GB，swap 只用了 10%，因此不是 OOM 記憶體的問題。當核心層完全沒有機會留字，代表是韌體、供電層的問題。
關鍵差別在熱累積，那次的自動關機或斷電時，機器已經連續跑了一整天的 LTX 影片製作，可能是熱浸透狀態才開始跑 H3。當我們重開機、閒置兩小時後，從 36°C 冷機開始跑完全相同的負載，就一次很順利地跑完了。跑完整組測試量到的峰值是 GPU 87°C、機殼熱區 95°C。
怎麼避開這問題呢 ? 畢竟這是熱的問題，我們檢查了 GB10 ，它沒有開放 power limit （nvidia-smi 的 power.limit 全部回報 N/A）， 所以能做的是排程上留冷卻間隔、並且在跑長時間批次時把功耗與溫度取樣寫到家目錄而不是 /tmp，當萬一斷電後 /tmp 會被清空，我們想要找原因時還可以去找回記錄檔看看結果呢。
跳出單機實測，社群怎麼看這兩個模型
CyberQ 這次的測試聚焦在同一台 DGX Spark 上的 ComfyUI 對照，我們如果看目前社群和市場的狀態，兩個模型的定位差異其實相當一致，與我們的實測結論互相印證。
LTX-2.5 的定位是速度與生產工作流
官方資料顯示在雙 NVIDIA GB200 上生成 10 秒 720p 圖生視訊約 6.8 秒，快於即時播放，API 端約 23.7 秒。社群在 RTX 5090 等消費級硬體上的實測同樣明顯快於 H3，與本文在 GB10 上量到的差距方向一致。專業工作流方面則有 Diffusion Fidelity Rendering、HDR ACES 與 EXR 支援、真實素材編輯、實體 AI 與機器人預訓練檢查點，以及可自 2.3 版直接轉移的成熟 LoRA 與 IC-LoRA 生態。
該模型的發布日即獲 ComfyUI 原生支援並有 NVIDIA 最佳化，電影工作室（如 Asteria）與機器人團隊已有實際採用案例。對重視資料與 IP 不離開設備、需要長期微調與成本可控的團隊而言，它的地端 AI 應用生態成熟。
MiniMax H3 的定位是全模態參考與精準控制
它可以同時輸入多張圖片、多段影片與音訊，並以自然語言描述各素材與生成目標的關係，例如「參考影片 1 的鏡頭運動、圖片 2 的人物、音訊 3 的歌聲」。在角色一致性、動作遷移（V2V）、品牌文字渲染與複雜指令遵循上表現突出。
著名的獨立測試 Artificial Analysis 平台顯示其在 Video Editing 常居前列，Text-to-Video 與 Image-to-Video 亦名列前段，並原生支援立體聲與 11 種語言的多語對話。這款模型的權重開源後社群迅速推出 INT8、NVFP4 等量化版本，API 與 Hailuo 產品線完整，但完整 2K 管線目前仍部分需要使用官方 API，這一點與本文提到 ComfyUI 版屬調整後版本、135GB 完整權重另計的觀察相呼應。
至於品質評價上，需要留意資料來源。LTX 官方自行盲測中 LTX-2.5 勝率約 67%，H3 約 50%，但這是廠商自行宣稱的資料，大家可以發現到，在獨立排行榜上， H3 在編輯與部分生成任務反而更強。我們自己實測的體感，是 H3 在複雜人體運動、表情與多參考一致性上較佳。LTX 則在高運動控制與電影感上比較有優勢，這也是本文提到，H3 品質較好但不比較適合當互動式工具的現況。
選擇建議
CyberQ 建議，如果你需要高速迭代、本地自架、電影級 HDR 後期、長期生產管線或機器人模擬，且重視成本與資料隱私者，LTX-2.5 是較佳選擇。需要多圖、影片、音訊同時控制的全模態參考，或角色、動作、聲音的精準遷移，以及短片廣告與品牌內容等需要音畫同步精度的場景，MiniMax H3 更為適合。
另一個取捨的點是，很多人都說玩過 H3 就回不去，影片的品質確實是有感的，它是社群中被認定地端 AI 跑無審查內容卻可以達到閉源雲端模型如 Seedance 3等級的模型。
實務上，我們可以看到很多創作者其實採取兩者並用的路線，用 LTX 快速產出草稿並掌控工作流，再以 H3 處理需要多參考一致性的最終鏡頭。以本文的 DGX Spark 為例，兩者可共存於同一份 ComfyUI，只要留意 H3 每次切換需支出約 83 秒的權重載入時間，即可依專案階段彈性切換，也不會暴記憶體。
