LTX-2.5 原生多鏡頭影片模型：開放權重真正跨過哪條線？（2026）

2026 年 8 月 11 日，LTX Team 在官網發布〈Introducing LTX-2.5: The Open World Model for Video, Real-Time, & Physical AI〉，宣布釋出 LTX-2.5 開放權重、Python pipelines 與 ComfyUI 工作流，並把「一次生成一段含有多次切鏡的影片」放在這次更新的正中央。

這確實值得注意，但理由不是 LTX-2.5「發明」了多鏡頭。真正的進步，是把多鏡頭、原生聲音、可下載權重、較少推論步數，以及 Python／ComfyUI 控制面組合成同一套 sequence 工作流。以下先釐清多鏡頭到底改變了什麼，再拆解 6.8 秒、16GB 與 distilled 等最容易誤讀的數字，最後判斷它距離可靠的敘事影片還差哪幾張成績單。

LTX-2.5 想消除的，是「每次切鏡都重置世界」

傳統 AI 影片工作流常把每個鏡頭分開生成，再交給剪輯軟體拼接。問題是，每次重新取樣，模型都可能重畫人物臉孔、服裝細節、道具位置、光線，連聲音質地也跟著改變。剪接可以隱藏時間跳躍，卻修不好已被重置的世界狀態。

Native multishot generation renders a full sequence as one output, holding character, scene, and voice across cuts.

中文：原生多鏡頭會把完整 sequence 當成一次輸出，並在切鏡之間維持角色、場景與聲音。

LTX Team

這句話描述的是產品級能力：同一個提示詞可以安排多個 shot 與 cut，產品以一次請求／一次輸出呈現整段聲畫，而非由使用者先生成數個互不相干的片段。公開資料仍不足以判定所有 shots 是否以全局 attention 或單一 latent sampling 聯合生成。「維持」也仍是 Lightricks 的能力主張，不是保證。官方提示詞指南建議一段以 2～4 個 shots 為宜，每次切鏡後仍要重新識別出場主體，並明寫聲音如何延續；若對話必須在固定構圖中準確對嘴，官方反而建議單一 shot。

因此，原生多鏡頭不等於長片記憶。它可以降低一次 sequence 內的斷點，卻沒有證明角色隔了數十秒再出場仍能完全一致，也沒有自動解決肢體、物理因果、聲音指派或劇情狀態。截至 2026 年 8 月 13 日，LTX-2.5 官方 model card 所列的 arXiv 連結仍是 2026 年 1 月的 LTX-2 聲畫架構論文；該卡未提供 2.5 專屬的 multishot 訓練／評測細節，這份舊論文也不能替 22B 的 2.5 新權重證明跨切鏡品質。

它不是第一個展示切鏡聲畫輸出的開放權重模型

「首款」說法經不起一個直接反例。MiniMax-H3 官方 repository 的 8 月 5 日初始 commit，已提供一個 10 秒、兩鏡頭的文字轉聲畫案例：提示詞以 [Shot 2] 和 00:04.500 的 cut 安排第二個鏡頭，H3 Omni Transformer 同時預測影片與 32kHz 立體聲。它的完整 2K Context-IR／regeneration 系統沒有全數開放；官方可重現案例以 768p 輸出，示範 server command 使用四張 GPU，但那是範例配置，不是已證實的最低需求。這足以否定「LTX-2.5 是第一個在開放權重模型的一次聲畫輸出中展示提示控制切鏡者」；公開資料仍不足以證明 H3 與 LTX-2.5 採用相同的 multishot 生成機制。

LTX-2.5 更務實的價值，是把 sequence generation 接進既有 Python／ComfyUI 生態。官方 Python v1.2.0 release 與 ComfyUI 2.5 workflows 都在發布日到位。對創作者而言，這理論上降低了一種「生成邊界稅」：少一次獨立生成，就少一次人物、空間與聲音被重新取樣的機會。它是工作流層級的結構性改善，不是已量測的一致性增益，也不代表每個 cut 都已穩定。

distilled 比較快，卻不是比較小的 22B 模型

「distilled 可在消費級硬體運行」最容易讓人聯想到一個縮小版 checkpoint。LTX-2.5 的實際檔案不是如此。官方 Python quick start 要下載 22B BF16 transformer、Gemma 4 12B 文字編碼器、影音 VAE 與 upscaler，README 估計這組 quick-start 元件的下載體積約 66 GiB；這不是最低 VRAM。各 checkpoint 的位元組大小可在 Hugging Face 官方檔案樹逐一核對。

官方檔案	大小	真正改變的是什麼
Dev 22B BF16 transformer	39.13 GiB	完整開發版取樣
Distilled 22B BF16 transformer	39.13 GiB	固定少步數推論，不是較少參數
Comfy INT8 transformer	20.03 GiB	量化降低權重占用
Distilled NVFP4 transformer	17.44 GiB	更低精度權重，另有硬體與 kernel 條件

DistilledPipeline 的重點，是使用預設的低步數 sigmas；官方兩階段高品質 pipeline 把第一、第二階段設為 8 與 3 次 denoising update，分別對應 9 與 4 個 sigma 點，但那是該 pipeline 的配置，不是所有 LTX-2.5 呼叫都固定如此。白話說，distilled 解決的是「要算幾次」，不是「整套東西有多大」。量化可降低權重占用，但可能改變數值與畫質；CPU／disk offload 則主要把顯存壓力轉移到 RAM、SSD I/O 與等待時間。若想先理解蒸餾與量化為何不是同一件事，可參考 AlphaLab 的模型蒸餾完整解析。

官方 6.8 秒很快，但那是 2× GB200 Superchip 的數字

Lightricks 公布的最快結果，是 2× NVIDIA GB200 Grace Blackwell Superchip（合計四顆 Blackwell GPU）在 steady state 下，以 6.8 秒生成 10 秒、720p、24fps 的 I2V。另一個 LTX API 數字是 23.7 秒，但解析度升到 1080p。圖中的競品多經 fal.run 計算端到端 API 時間，包含排隊，解析度也不一致；Veo 3.1 更是 8 秒片段。這張圖支持「特定資料中心配置的吞吐量很高」，不能外推成一般 RTX 顯卡已能即時生成。

右側品質圖也要看清分母。LTX-2.5 Pro 的 visible-glitch score 是 0.28，Fast 是 0.39；官方稱以相同 98 個 prompts 做自動評分，尋找斑塊、破碎紋理、融化與塗抹等瑕疵，結果仍屬 preliminary。它沒有直接測角色辨識、手腳正確性、提示詞遵循、聲音意圖或跨 cut 一致性。因此，0.28 不能改寫成「整體影片品質第一」。生成速度與品質都不是模型常數，而是模型、步數、解析度、硬體、offload、解碼與排隊方式共同產生的系統結果。

16GB、32GB 與 RTX 3060，說的是三種不同門檻

官方文件本身還沒有把硬體口徑對齊。產品頁比較表寫「Runs on any GPU」與最低 16GB VRAM；目前的 LTX-2.5 system requirements 則列 NVIDIA GPU 32GB 以上 VRAM、CUDA 12.7+、32GB RAM 與 100GB 儲存空間，並推薦 A100 80GB／H100。官方 ComfyUI 節點也把 32GB+ 列為需求，所謂 low-VRAM offloading 是「把生成塞進 32GB」，不是已驗證的 16GB 基準。

這不代表較小的卡一定產不出東西。一則高討論度的 RTX 3060 field report，用 RTX 3060 與 16GB 系統 RAM 生成約 0.5MP、10 秒影片，耗時約 180 秒；prompt enhancer 關閉，作者稱開啟約再加 30 秒。解析度高於 0.5MP 時，作者在 video VAE decode 遇到 OOM。貼文沒有完整交代 CPU、GPU VRAM、量化、offload 與 workflow 版本，因此它能證明「低規配置有機會產出」，不能當成可重現的效能 benchmark。

更重要的是，那支 3060 影片只有單一 clip，沒有 cut，也沒有測跨切鏡人物一致性；它無法替本次 headline 背書。作者還補充，展示片沒有漏步，但其他走路／跑步樣本出現動畫跳步。截至 8 月 13 日 05:25 UTC，官方發布串約 953 票、3060 實測串約 395～396 票。這些數字是強烈的社群興趣訊號，不是品質驗證。

早期品質評價分裂，反而指出真正缺的測試

Reddit 早期回報的正反面都很具體：有人認為環境一致性比上一版好，部分音訊乾淨；也有人遇到臉部 morph、手部／肢體異常、步態跳步、buzzing 或不合意的隨機配樂。自稱相同或近似硬體的使用者仍回報不同結果，而各貼文沒有控制 workflow、seed、量化等變因；其中 prompt enhancer 與 VAE 解碼設定已有直接差異。這些觀察適合用來設計下一輪測試，還不能排出單一品質結論。

現在最需要的不是更多精選風景片，而是一套固定三鏡頭腳本：同一人物、服裝、道具、聲音與光線跨越兩次切鏡，每種設定跑多個 seeds，公開成功率與失敗樣本；同時記錄 16GB／24GB／32GB 的 VRAM、RAM、解析度，以及 prompt encoding、diffusion、VAE decode 各階段 wall time。只有這種矩陣，才能把「可啟動」「可產出」「可重現」與「可用於製作」四種門檻分開。

「開放」也要拆成下載權、部署權與商用權

LTX-2.5 是開放權重，但不宜無條件稱為 permissive open source。Hugging Face 將授權標成 license:other；具約束力的 LTX-2.x Community License 規定，關係企業合計年營收達 1,000 萬美元的 entity，要把模型用於商業用途需另取得付費授權，並包含使用、再散布與競爭產品等限制。

這裡還有一個值得企業法務留意的文字落差：新聞稿與產品頁用的是「低於 US$10M ARR 可免費」，正式 agreement 寫的卻是 annual revenues，並非 ARR。能下載權重，不代表每個人都能用相同條件部署；能在本地執行，也不代表商用沒有額外門檻。團隊導入前應按實際 entity、用途與正式條款核對，而不是只讀產品頁摘要。

AlphaLab 判讀：它把 clip 推向 sequence，還沒把 sequence 變成電影

我同意什麼

開放影片模型下一個合理的競爭單位，確實不該只是更漂亮的單一 5～10 秒 clip，而是能維持角色、空間與聲音的 sequence。一次生成數個 shots，從工作流上減少獨立取樣邊界，對 storyboard、廣告分鏡、MV、短敘事與 previsualization 都有實際價值。Python、ComfyUI、量化與 offload 路徑，也讓研究者能真正檢查模型，不必只觀看官方精選 demo。

我存疑什麼

本文目前能核對的 LTX-2.5 multishot 證據，主要仍由 Lightricks 提供，缺少固定 prompt、固定 workflow、跨 seeds 的獨立測試。一次輸出 sequence 沒有自動解決長期角色記憶、物理因果、手腳、走路與可重現性；把 2× GB200 Superchip 的速度、16GB 最低標語與「消費級本地運行」放在同一段宣傳裡，也容易讓讀者忽略三者的配置差異。最後，開放權重與客製商業授權必須和真正的 permissive OSS 分開描述。

我的結論是：LTX-2.5 是一次有意義的模型與工具鏈發布，因為它把競爭焦點從「最好看的單一片段」推向「能否維持一段 sequence」；但在獨立跨切鏡測試、標準化消費級硬體矩陣與授權表述更清楚以前，它仍是值得驗證的工作流突破，不是已完成的敘事影片解法。

誰現在適合下載 LTX-2.5？

• 32GB 以上 NVIDIA、熟悉 ComfyUI／Python 的研究者與創作者：現在值得測，尤其適合建立多鏡頭失敗率與 dev／distilled 吞吐量比較。
• 16GB VRAM 級配置：社群個案顯示經量化、offload 與低解析度路徑有機會產出，但應預期分鐘級等待、RAM／SSD 轉移與 VAE 解碼瓶頸；前述 3060 個案只有 16GB 系統 RAM，並未公開 GPU VRAM，不能直接拿來證明 16GB VRAM 效能。
• 製作與商用團隊：先跑自己的固定測試集，再核對正式 license。不要依官方速度圖直接做硬體採購或產能估算。

若要比較另一條開放權重聲畫路線，可先讀MiniMax H3 模型解析與MiniMax H3 ComfyUI 本機教學；前者可比較兩者的發布時序、能力邊界與本地部署差異。若你關心的是模型能力如何接到完整製作流程，則可延伸到Claude Code AI 影片工作室。