Lucy 2.5 即時影片：延遲、成本與 API 設定指南

Decart 的 Lucy 2.5 每秒只要 $0.02，看起來很划算——但連續串流四小時，帳單就會來到 $288。Lucy 2.5 即時影片已經以 API 形式廣泛開放，可用來即時轉換影片；不過，產品發布素材裡的 1080p 並不是 API 文件所標示的解析度，而宣稱的低延遲也只是模型端數字，並不代表從攝影機擷取到觀眾螢幕顯示的完整延遲。本指南會把行銷說法和正式文件分開檢視，再換算每小時成本，最後整理各種存取與整合方式。

Lucy 2.5 即時影片到底是什麼？

Lucy 2.5 是 Decart 的即時 video-to-video 編輯模型，於 July 16, 2026 以「Raising the Bar for Live AI」為題發布。影片透過 WebRTC 連線輸入，再用文字提示詞與選用的參考圖片控制轉換，處理後的影格宣稱可達 30 fps。重點在於「轉換」：Lucy 是在既有的直播畫面中重新設計、替換、加入或移除元素，而不是憑空生成一段完成的影片。Theoretically Media 的 Tim Simmons將兩者區分得很清楚：這是針對串流畫面的即時特效與合成，不是非線性剪輯；而且目前只提供 API——「目前還沒有 App 版本」，Decart 發布影片中那個手持手機使用的產品「也不是現有產品」。

API 文件支援即時與錄製影片輸入，而 fal 的模型頁面則表示，依其條款可用於商業用途。Decart 已募得超過 $450M，其中包括由 Radical Ventures 主導、於 May 2026 完成的 $300M 融資。

先把 1080p 這個解析度說法放一邊

發布素材與 fal 模型頁面都把 Lucy 2.5 標示為 30 fps、1080p，但 Decart 自己的API 文件明確寫的是1280 × 720 輸出，支援 16:9 橫向或 9:16 直向。在官方公開文件出現 1080p endpoint 之前，規劃時應以 720p 為準：這才是 API 合約載明的規格，定價範例也是以 720p 為基礎。

影格率也有同樣的問題。「30 FPS」出現在行銷文案中，但沒有公開測量方法；Decart 也未透露伺服器硬體、模型大小，或從擷取到播放的測試結果。可以參考一個外部基準：SANA-Streaming這篇 May 2026 發表的研究預印本指出，在單張 RTX 5090 上，以 1280 × 704 輸出時，端到端速度為 24 fps，而其 diffusion-transformer 核心則是 58 fps。這並不是 Lucy 的基準測試，而是說明單獨提出「30 FPS」卻不交代測量位置，對實際效能來說資訊並不完整。

「近乎零延遲」到底算到哪裡？

目前流傳的 Lucy 2.5 延遲數字有三組，而且測量的是不同環節。Decart 在與 $300M 融資一同發布的DOS 2.0 基礎架構文章中，提到模型回應時間低於 30 ms；Hugging Face 上的社群文章則將 720p 下低於 40 ms 的推論速度歸因於 Decart 的推論堆疊，包括 MXFP8/NVFP4 量化、動態稀疏注意力與 deep kernel fusion，並宣稱在受計算限制的操作上速度提升 4 倍。但這些資料都沒有公布從攝影機擷取到觀眾螢幕顯示的端到端延遲；WebRTC 傳輸、編碼與播放器都會增加時間，而且結果會隨網路狀況變動。若要估算自己的實際部署延遲，可以在攝影機畫面中錄入可見的時間戳，再對照目標網路與播放器路徑上顯示的輸出畫面。

八種編輯模式，以及 Self-Anchoring 何時會失效

Lucy 2.5 的文件列出八種編輯操作，每一種都能用文字提示詞、參考圖片，或兩者一起控制：

比起模式清單，更值得注意的是兩項控制機制。第一，Self-Anchoring 是避免長時間串流中人物身分逐漸漂移的機制：它會把模型最近輸出的畫面回饋為參考。這項功能預設啟用，而且只能在建立連線時修改。Decart 文件提醒，如果畫面突然切換、有人新進入鏡頭，或場景出現大幅變化，就應該停用它；因為此時 anchor 參照的是已經不存在的場景。這代表你需要重新連線，因此多機位系統必須事先把這種情況納入設計。

第二，參考圖片也有明確要求：畫面要清晰、光線充足、沒有遮擋，至少512 × 512 像素，而且構圖要與來源影片相符。光線不足或構圖不匹配的參考圖片，可能會讓替換操作直接失敗。

即時生成與離線生成：先選對使用路線

離線生成工具（Runway、Pika、Sora 類工具）和 Lucy 2.5 解決的是不同問題，所以「哪個比較好」沒有單一答案，得看使用情境。以下四個面向最關鍵：

1. 互動性。如果需要觀眾或攝影機在影片播放的同時影響畫面，即時生成是唯一選擇；離線工具只能走輸入提示詞、等待渲染的流程。
2. 影片長度。根據Hugging Face 的比較，離線工具通常處理 5–60 秒的短片，Runway 與 Pika 類產品的渲染時間則從幾秒到幾分鐘不等。Lucy 可以持續串流——fal 宣稱能連續運作數小時而不會失去身分一致性，但目前沒有公開長時間壓力測試。
3. 品質底線。如果是 1080p 以上的正式交付內容，考量 API 文件記載的輸出仍是 720p，離線渲染目前依然佔優。Tim Simmons 提出一個實用的混合流程：把即時生成當作 live previs，先用手機拍攝，再用 Lucy 即時套用效果來確認鏡頭，最後透過離線 video-to-video 模型完成高品質版本。
4. 成本結構。離線工具按生成片段收費；Lucy 則按串流啟用的秒數計費，時間一長，每小時成本就會快速累積（下一節詳述）。

大家實際上想用這類工具做什麼？r/generativeAI 的 u/TastyFooting 用一句話說出了核心吸引力：

「搭配文字提示詞的即時 video-to-video 生成。不用再等渲染。」（來源）

社群討論也反覆提出兩個尚未解答的問題——u/ai_art_is_art 在「這種模型到底有什麼用途？VTubing？」中發問，r/AINewsAndTrends 的一位創作者則關心「如果離開示範場景，它是否也能一樣有效」。fal 模型頁面列出的應用方向包括直播購物與虛擬試穿、即時產品置入、互動式串流、App 內場景轉換、遊戲，以及直播導覽中的虛擬佈景；Hugging Face 文章另外提到 VTubing 與廣告版本變體工作流程。想進一步了解即時生成如何改變影片 API 生態，也可以參考我們對 SeedRealtime 的介紹。

實際串流成本：$0.02/秒不是最該看的數字

目前有兩條公開使用路線，價格也不同：

Decart 自己的定價範例先從小規模使用情境算起：30 秒即時工作階段要 $0.60，5 秒的離線 720p 編輯則是 $0.20。根據兩家平台的定價頁面，它們計算的是啟用生成的秒數，而不是觀看者停留的時間。真正需要拿來做決策的，是更長時間的使用情境：

如果每個工作日啟用串流四小時，fal 每天約收 $576；以每月 22 個工作日計算，約為 $12,700，還不包含網路與內容審核成本。持續生成會把低單價變成每小時併發數問題：如果 App 裡每位觀眾都會開啟一條獨立的 Lucy 串流，每小時成本就要乘上併發人數。若要和其他生成 API 比較，per-second、per-clip、per-token 等不同計費維度，請參考我們的影片生成 API 定價指南。

有兩種結構性的省錢方式。首先，攝影機閒置時間不必等同於啟用生成時間，可以只在真正有內容時開啟串流。其次，路線選擇本身就能讓帳單減半：在相同的 720p 文件規格下，Decart 直連 API 的費率是 fal 的一半；相對地，fal 把 Playground、商業條款與生態系整合在一起。哪一個更適合，取決於你需要模型周邊哪些服務，而不只是模型本身。

如何取得 Lucy 2.5：Decart 直連、Playground 與 fal

想最快看到 Lucy 2.5 對自己的臉做出反應，可以先使用 Decart 的瀏覽器體驗lucy.decart.ai，或前往示範 Playgrounddemos.decart.ai——新帳戶會取得測試額度，可能足以支應第一次測試。先用這些工具測試參考圖片與提示詞寫法，再開始寫程式，會更有效率。

根據Lucy 2.5 即時文件，Decart 直連 API 採用標準 WebRTC 流程：

1. 取得 API 憑證，並為 lucy-2.5 模型建立即時工作階段
2. 建立 WebRTC 連線，在連線時設定 Self-Anchoring 與提示詞增強功能（之後若要修改 Self-Anchoring，必須重新連線）
3. 把即時或錄製的輸入媒體附加到工作階段
4. 透過現有連線傳送文字提示詞與參考圖片——參考圖片可以在工作階段進行期間更新
5. 接收編輯後的輸出軌道；如果工作階段中斷，則使用內建的自動重新連線功能（指數退避，最多重試 5 次）

如果要透過fal整合，流程分成五步：

1. npm install --save @fal-ai/client
2. 建立 fal 帳戶，並從 dashboard 取得 API 金鑰
3. 開啟與 decart/lucy-2-5/realtime 的 WebRTC 連線
4. 後端透過 tokenProvider 提供短效 JWT（fal 範例使用 10 秒的 token 有效期）——這不是只在瀏覽器執行、把金鑰放在前端的架構
5. 透過 onResult/onError 處理結果與錯誤，再經由即時連線傳送提示詞

根據 fal 的模型頁面，fal 支援 JavaScript、Python 與純 REST 等用戶端整合方式。至於 OBS，要把原型測試和正式環境分開看：用 Decart 體驗版的瀏覽器來源或視窗擷取來測試效果沒有問題，但正式流程應該接收自有 API 整合所輸出的 WebRTC 影像。Hugging Face 文章指出，可以透過 WebRTC 在 OBS 中使用，無需改動原有廣播設定；不過，仍應在自己的技術堆疊中驗證輸入、延遲與重新連線行為。同一篇文章也提到，行動 App 可使用 Android 與 iOS SDK。如果想比較不同版本的表現，Lucy 2.1 目前仍在 fal 上線。若要更全面評估 fal 這個平台，請參考我們的 fal.ai 評測。

正式上線前先處理：揭露規範已經適用

能在即時影片中改造人物、服裝與環境的模型，代表合規不是事後補上的政策註腳，而是工程設計的一部分。Decart 的可接受使用政策（更新於 February 12, 2026）禁止在沒有清楚、醒目揭露及可驗證同意的情況下冒充真實人物；部署者也必須揭露 AI 生成或操弄內容、執行適當的內容審核，並在技術可行時保留機器可讀標記。另外，EU 透明度義務自 August 2, 2026 起生效，要求對可偵測的 AI 生成內容加入機器可讀標記，並要求部署者針對 deepfake 類用途進行揭露。若服務面向 EU 市場，應在上線前確認適用的透明度與來源標示義務，不要等到上線後才處理。

現在適合用 Lucy 2.5 開始開發嗎？

接下來最值得留意的是：如果 Decart 推出公開的 1080p 路線，即時與離線生成之間的畫質差距會明顯縮小；在那之前，請把 720p 視為正式合約規格，把更高的解析度視為未來方向。

Lucy 2.5 即時影片常見問題

Lucy 2.5 真的算即時嗎？

如果以即時 WebRTC 串流套用編輯、宣稱可達 30 fps，以及模型端低於 30–40 ms 的延遲來看，它確實是即時處理。但目前沒有公開獨立的端到端（從擷取到播放）測量，因此「即時」目前代表已在示範中驗證，而不是經過基準測試驗證。

Lucy 2.5 API 的輸出解析度是多少？

API 文件記載的輸出為 1280 × 720，支援 16:9 或 9:16。發布素材宣稱 1080p，但截至 late August 2026，仍沒有公開文件記載的 1080p endpoint。

Lucy 2.5 每小時要多少錢？

Decart 直連 API 在 720p 下按每個啟用秒數 $0.02 計費，也就是每個啟用小時 $72。fal 上的同一模型則是每秒 $0.04，或每個啟用小時 $144。兩者計算的都是實際生成時間，而不是觀看者停留時間。

Lucy 2.5 能搭配 OBS 使用嗎？

可以用於原型測試：瀏覽器體驗能透過瀏覽器來源或視窗擷取作為 OBS 輸入。若是正式環境，則應先在自己的廣播技術堆疊中測試 WebRTC 輸入流程，再決定是否採用。

Lucy 2.5 還是 Lucy 2.1？

根據fal 的版本比較，Lucy 2.5 擴大了編輯範圍，涵蓋物件、服裝、角色、屬性、背景、風格與 VFX，並宣稱在提示詞遵循度、編輯隔離與參考圖保真度方面有所提升。如果需要一個已知穩定度的基準，較早期的即時 endpoint Lucy 2.1 仍可在 fal 上使用——建議用自己的素材實際比較兩者。