Vidu S2 讓影片邊播邊改：25–42 FPS 不等於互動延遲（2026）

2026 年 9 月 15 日（台北時間），Vidu 官方 GitHub 在標題為「Vidu S2 launch」的 commit 中，把試用入口從「Coming Soon」改成可用連結。值得注意的是，9 月 10 日的技術報告已先稱 demo 可玩，但 9 月 11 日官方 repo 仍標示尚未開放；因此 9 月 15 日是目前最明確的官方上線證據，不一定是頁面首次可被存取的時間。這次真正值得注意的，不是又多了一支 AI 影片，而是 Vidu S2 讓影片開始像介面：對話途中能接收新指令，參考圖可以隨時換，輸入中的畫面也能一邊播放、一邊改。

官方把它描述成「即時、可互動、可編輯、可生成空間影片」的系統。以下先還原 Vidu S2 官方展示頁與原始技術報告說了什麼，再拆開兩個更重要的問題：25–42 FPS 到底證明了多少，以及它是否真的把生成影片從「等待成片」推進到「持續互動」。

Vidu S2 的核心，不是更快出片，而是邊播邊改

傳統生成影片比較像一筆工作：你送出 prompt，系統運算，最後交回一段完成的 clip。Vidu S2 想把這個流程改成一個持續存在的 session。當影片已經在播放，使用者仍能說話、補指令、換參考圖，甚至把一條正在進來的攝影機或影片串流交給模型改造。

整套系統其實由兩個主要模型與一條實驗性空間影片管線組成：

• Vidu S2-Avatar：用參考圖、聲音與文字條件持續生成人物影片，可在串流中更換物件、服裝或背景，也展示了全身舞蹈等較大幅度動作。
• Vidu S2-Editing：接收來源影片、文字指令與可選的參考圖，處理風格轉換、虛擬試穿、人物替換與背景替換。
• Spatial Video：先估算單眼畫面的深度，再把它扭曲成左右眼影像；目前比較接近固定視角的立體影片，不是能自由走動的 3D 世界。

Editing 的核心設計是 frame-aligned attention：每個輸出幀只讀取同一時間點的來源幀，參考圖則可被所有輸出幀讀取，以保留原始動作與時間。訓練資料包含 80 萬支篩選影片，分成四個互不重疊的 20 萬支子集；風格轉換資料由 surface-normal video 與參考圖合成，其他任務則混合多個開源編輯模型的候選輸出再篩選。這些都是作者披露的訓練流程，不代表資料來源、授權或完整訓練設定已公開。

三個關鍵設計：長期因果、畫質補強與互動編排

1. Self-Replay Forcing：讓模型練習接住自己的上一段輸出

串流生成最難的地方，不只是單幀好不好看，而是模型必須長時間以自己先前生成的畫面作為歷史。訓練時若只看乾淨的真實影像，部署後一旦某一段產生小錯，錯誤就可能沿著時間累積。

論文提出的 Self-Replay Forcing，先讓目前的 student 模型自行生成一段歷史，再把這條軌跡加回噪聲、串成可微分的因果圖重播。直覺上，它不是只教模型「正確答案長什麼樣」，而是讓模型練習「前面已經是自己生成的結果時，下一段怎麼繼續」。這是 Vidu S2 對長時間漂移問題最有技術含量的回答。

2. 一步 latent refiner：先求速度，再把輸出拉到 720p

Vidu S2 沒有讓主幹模型全程在高解析度做所有運算。它先在較低解析度維持因果生成，再用一步 latent super-resolution refiner 補到 720p；粗略的動作連續性與細節各自使用不同噪聲程度的 cache。這能解釋為何論文可以同時提出高解析輸出與較高吞吐量，但也意味著「720p」指的是最終輸出，不等於整個 diffusion backbone 原生以 720p 運算。

3. VLM agent：影片模型之外，還有一個導演在盯畫面

這套 Avatar 不只把聲音送進影片模型。視覺語言模型會改寫指令、查看生成幀，並維持「人物是否還拿著杯子」之類的狀態。換句話說，Vidu S2 的互動能力有一部分來自 agent 對影片模型的持續編排，而不是單一模型突然理解了整場對話。

官方 model map也把產品邊界說得很清楚：完整 Real-time Edition 由 Vidu 提供 RTC、語音辨識、LLM 與語音合成；Component Edition 則由客戶自行提供這些模組。因此，「能對話」是整條產品管線的結果；但技術報告把 Avatar backbone 定義為聯合預測影音 latent 的 audio-visual DiT，不能簡化成只把條件轉成連續影像。產品層的 TTS 分工與研究模型的聯合影音建模，是兩個不同層次。

25–42 FPS 很重要，但它不是互動延遲

“Vidu S2-Avatar raises real-time generation from 540p to 720p while keeping 25~42 FPS.”

中文：Vidu S2-Avatar 把即時生成從 540p 提升到 720p，同時維持 25–42 FPS。

Vidu S2 技術報告，第 1 節

這是整份報告最醒目的數字，也是最容易被讀錯的數字。FPS 衡量的是系統進入穩態後，每秒能輸出多少影片幀；25 FPS 只表示每秒輸出的影片量等價於 25 幀，不代表系統每 40 毫秒就逐幀回傳一次，也不能推出首幀或指令生效延遲。它沒有告訴我們，使用者開始說話後要等多久、語音要累積多少毫秒、LLM 與 TTS 花多少時間，或換一張參考圖後第幾幀才真正反映新指令。

這個吞吐量也不是只靠模型本身：作者使用逐層選擇的 SageAttention、SpargeAttention、Sparse-Linear Attention、per-block W8A8 GEMM、Triton／CUDA kernel fusion、CUDA Graphs，以及量化通訊的多 GPU context parallelism。論文沒有拆出各項加速的貢獻，也沒有說明 25 FPS 與 42 FPS 各自對應哪種硬體與並行配置。

截至 2026 年 9 月 16 日，論文沒有為 25–42 FPS 列出 GPU 型號、GPU 數量、模型參數量、batch、精度或測量範圍。Avatar 內部測試提到 160、320、480 毫秒的聲音 chunk，也說測了端到端延遲與成本，卻沒有公開這些結果。因此最準確的寫法是：25–42 FPS 是作者報告的輸出吞吐量，不能直接換算成插話或換圖的反應時間。

benchmark 的好消息與那個更關鍵的空白

品質面並非只靠宣傳片。作者把 Vidu S2 放進 StreamAV-Bench、Sparkle-Bench、OpenVE、RefVIE 與 ViViD 等公開 benchmark；在論文列出的欄位中，Vidu S2 都取得最佳已報成績。以編輯為例，Sparkle-Bench overall 為 3.74，略高於 Decart 的 3.67；合併 OpenVE 與 RefVIE 時，overall 為 4.26，對比 Bernini-R 14B 的 3.92。這些 Vidu S2 成績都是作者報告；比較表中的 baseline 數字則在 benchmark、split 與 metric 完全相同時允許沿用原論文結果，部分指標也由模型裁判評分。

要判斷的事	目前公開證據	仍缺的答案
畫面品質與一致性	多個公開 benchmark 的作者報告結果	第三方用同一版本與設定重跑
穩態吞吐量	Avatar 的作者宣稱為 25–42 FPS	硬體、GPU 數量、測量口徑與尾端抖動
真正互動反應	官方 demo 與功能說明展示即時通話、動態參考圖及串流編輯	插話／中斷成功率、time-to-first-frame、指令生效延遲、P95／P99
長時間穩定	StreamAV 公開 protocol 最長 180 秒；作者另以內部圖表呈現 10–90 秒評分，並描述 5 分鐘 Avatar 與約 10 分鐘 editing 測試	完整長跑輸出、逐段數值、失敗率與恢復時間

最值得追問的是 StreamAV-Bench。原 benchmark設計了 32 個面向，除了 FPS 與首個 chunk 時間，也包含更新是否成功、反應延遲、狀態保留與歷史重用等互動指標。Vidu S2 的 Table 1 只公布其中 9 個品質、對齊與一致性欄位，沒有報 FPS、TTFC，也沒有報互動 response／state 指標。這不代表系統不能互動；它代表公開表格目前還不足以證明互動做得多快、多穩。

“Product-page claims about frame rate or latency do not replace measured results.”

中文：產品頁對幀率或延遲的宣稱，不能取代實際量測結果。

Vidu S2 技術報告，第 5.1.3 節

這句話其實來自作者自己的評測原則，也應該反過來用在 Vidu S2 身上。截至同日查閱，官方 repository提供的是專案說明與 overview 圖，尚未提供足以讓本文重跑速度與 benchmark 的程式、權重及設定清單。論文也未披露 Avatar 訓練資料規模、完整資料來源與授權、訓練算力、步數或超參數；Editing 雖披露 80 萬支影片的任務切分，仍未提供可審核的資料清單。能打開雲端 demo，和能在相同硬體獨立重現數字，是兩種不同強度的證據。

空間影片是有趣的附加題，還不是自由探索的世界

Vidu S2 的 spatial video 先估算每幀深度，把單眼畫面依視差向兩邊扭曲，再補洞與做時間穩定，最後得到左右眼影像。這條方法可以把 Avatar 或編輯後影片快速變成立體輸出，也能把左右並排的 stereo input 一起編輯。

但它仍是固定視角的 2D-to-stereo 轉換。論文自己把更高解析度、更低延遲與全景探索列為後續方向，並指出高延遲會讓頭部運動與 passthrough 顯示不同步；論文沒有進一步做 VR 舒適度或暈動症測試。把它理解成「即時生成影片向 headset 多走一步」很合理；把它說成已經能取代 3D 場景或 world model，就超出了現有證據。

真正的轉折：生成影片正在變成一種有狀態的媒介

如果只看 720p 與 FPS，Vidu S2 很容易變成又一次規格競賽；更深的變化在控制迴路。過去的生成影片把 prompt 當成一次性訂單，現在它開始接收連續事件：新語音、新圖片、新背景，以及「剛才那個動作還沒完成」的狀態。當模型可以在播放中接受修正，影片便不再只是檔案，而開始具有 UI 的性質。

這會先改變幾種工作：直播電商可在不中斷畫面的情況下換商品或服裝；教學、客服與虛擬角色能根據對話持續改變表情和動作；創作者則能把攝影機 feed 當成一張持續可編輯的畫布。真正決定它能否進入製作流程的，不會只是最高 FPS，而是指令命中率、P95 延遲、長時間身份穩定、併發成本，以及失敗後能不能恢復。

現在值得怎麼看、怎麼試

Vidu S2 已經足以讓人認真看待「互動式生成影片」這個產品類別，但還不足以讓人只憑 25–42 FPS 就判定它解決了即時互動。若你準備評估這類系統，可以把 demo 的驚喜轉成五個具體測試：

1. 在人物說話途中插入新指令，記錄從說話開始到畫面真正改變的時間。
2. 連續更換參考圖，觀察身份、手部、服裝與背景是否互相污染。
3. 用快速動作、遮擋、多人與鏡頭晃動測試 editing，而不是只看精選片段。
4. 把 session 拉到 30 分鐘以上，檢查漂移、崩壞與恢復能力。
5. 要求供應商提供硬體、併發、P95／P99、每分鐘成本與內容來源控管，而不只是一個峰值 FPS。

對研究者來說，下一份更有說服力的材料會是公開的 latency card、固定版本 benchmark manifest、原始長跑影片與第三方重現。對使用者來說，最簡單的判準則是：不要問「它能不能生成這個畫面」，要問「我在影片已經進行時改變主意，它多久能正確接住？」