Local AI · DGX Spark
AI 影片生成工作台
打一句描述，換一支動態影片。
非同步佇列生成 × ComfyUI + LTX-2.3，全程跑在自家 GPU 上。
實際介面・Playwright 實機截圖
為什麼要自己蓋一個
雲端的 AI 影片生成很好玩，但同樣的老問題：資料要出門、按秒計費、想換模型還得等官方更新。企業內部要用來做示意影片、簡報素材，資料出門這一條就先卡關。
DGX Spark 上的 GPU 平常忙著推論，還有餘裕跑一支支影片。把 ComfyUI 接上 LTX-2.3 模型，就是一個不用錢、不出門的影片生成工作台。
難的是等待：一支影片動輒跑好幾分鐘，不能讓人盯著轉圈圈。這個工具花最多力氣的地方，就是把「等」設計得不痛苦。
原理：一支影片的旅程
從一句描述到一支動態影片，中間發生五件事。
場景輸入
每個場景可以分別輸入中文或英文描述，也能請 AI 優化 prompt，或直接跟工具要靈感。
送入非同步生成佇列
生成不是打了就乾等，請求進佇列排隊，送出後可以繼續排下一支，不用卡在畫面前。
ComfyUI + LTX-2.3 本地運算
佇列逐一送進 DGX Spark 本地的 ComfyUI，由 LTX-2.3 影片模型實際運算生成。
延伸與多場景
完成的影片可以再往下「延伸」，也能一次排好多個場景，串成一支完整的影片。
影片輸出
生成好的影片回到工作台，可以下載，也可以直接拿去延伸下一段。
原理深掘：LTX-2.3 兩段式生成節點圖
核心是兩段式取樣：先在半解析度用蒸餾 LoRA 跑約 8 步探索構圖與動作，再用潛空間放大模型 2× 放大回全解析度，最後只花約 3 步做精修。同硬體實測比全程都在全解析度跑同樣步數快上 40%~80%。以下是文生影片（t2v）實際執行的節點流程。
工具內建「運作原理」頁實際切版，呈現 ComfyUI 節點圖與即時模型狀態
i2v 模式在文字編碼分支之後多插入一個 LTXVImgToVideoInplace 節點，把參考圖編碼進第一幀 latent；t2v 從純噪音開始，i2v 構圖穩定但動作可控性較低。
非同步任務佇列
POST /generate 立刻拿 job_id → FIFO worker thread（單 GPU 一次一支）→ ComfyUI /prompt → 前端每 3 秒 GET /job/{id} → done 播放 mp4
多場景接龍
場景 1 生成 → ffmpeg 擷取最後一幀當場景 2 的 i2v 起始圖 → 重複到第 N 段 → ffmpeg concat demuxer（-c copy）無損拼接成一支長片
實測研究筆記
拆節點圖、跑 A/B 測試量出來的三個已知限制——不是憑感覺猜的，是實際數據。
問題 1・i2v 遵循度
兩段取樣鎖參考圖強度不對稱：Stage 1（決定構圖動作，跑滿 8 步）只用 strength 0.7；Stage 2 雖拉到 1.0，卻只剩 3 步能修正。A/B 測試把 Stage 1 strength 拉到 0.95，鏡頭漂移明顯減少，但樣本數還小（1 個 prompt、1 組 seed）。
問題 2・動作遵循
同根因：動作軌跡幾乎在低強度的 Stage 1 就定型，Stage 2 只有 3 步高解析度精修，來不及修正方向。影片擴散模型執行動作指令本身也比理解靜態構圖難，是這類模型的通病。
問題 3・多段聲音不連續
ffmpeg astats 量測接縫：場景1結尾 -24.7dB／場景2開頭 -24.7dB／場景2中段 -24.4dB
音量幾乎沒落差。不是音量問題，是每段音訊各自獨立生成、內容特徵不相關。接龍只帶最後一幀當 i2v 起始圖，聲音沒有任何延續管道。
關鍵設計決策
非同步佇列，而不是同步等待
影片生成耗時長，讓使用者卡在畫面前等成品沒有意義。送出就進佇列，可以繼續排下一支，等生成完再回來看結果。
多場景一次生成＋影片延伸
同一支影片能往後「延伸」，也能一次排多個場景，串成一段完整的故事。
標準／進階雙模式
不是每支影片都需要最貴的設定。依需求分成標準與進階兩種模式，把運算資源花在真正需要的地方。
local-first，不經雲端
從 prompt 優化到最終生成，全程跑在 DGX Spark 本地，資料不出內網。
技術架構
Frontend
Sora 風格工作台
每場景獨立 AI 優化與靈感
內附原理節點圖與研究筆記
Queue
非同步生成佇列
排隊制，不阻塞畫面
可續交下一支
Inference
ComfyUI on DGX Spark
LTX-2.3 影片模型
逐一運算生成
LLM
本地 prompt 優化 LLM
中英文皆可輸入
靈感標籤輔助
線上工具已上鎖（Basic Auth）・本頁分享架構與設計