OneStreamer:用同一個「主動生成」介面,統一串流影片的感知、記憶與即時回應
OneStreamer: Unifying Perception, Memory, and Proactive Response in Streaming Video Interaction
背景
影片大型語言模型(Video LLM)過去多半是「離線」運作:整段影片先丟進模型,使用者再提問。真實場景並非如此。監視器、AR 眼鏡、直播助理或機器人面對的是持續湧入的影像串流,問題可能在幾秒後才出現,也可能永遠不出現。模型有兩件事得同時做好。
第一件是在不知道未來會被問什麼的情況下保存證據。如果把每一幀的視覺特徵都存起來,顯存和延遲很快就爆掉。如果只看最近幾秒,對「十分鐘前那個人拿了什麼?」這類歷史問題就答不出來。
第二件是在證據足夠時主動開口。串流場景中,模型大多數時間應該保持沉默,等到事件真的發生才回應。這就是「proactive response」。
現有做法常把這幾件事拆開處理:感知用一個模組,記憶用另一套檢索或壓縮機制,回應時機再靠另一個判斷頭。拆開之後,記憶通常是壓縮後的視覺特徵,不容易重用,也和語言任務脫節。另外,主動回應的訓練資料有嚴重的類別不平衡,絕大多數時間點的標籤都是「繼續等待」,模型很容易學成永遠不說話。
OneStreamer 想回答的問題是:能不能用同一個生成式介面,同時學會「記錄證據」、「形成記憶」和「適時回應」?
方法
OneStreamer 以 Qwen3-VL-4B-Instruct 為底座,凍結 vision encoder,只訓練 multimodal projector 與 LLM,在 32 張 NVIDIA H200 上訓練一個 epoch。核心設計有三塊。
1. Proactive Hierarchical Caption Memory(PHCM)
模型在串流過程中會自己生成兩種文字紀錄:
</Observe>:密集的局部細節 caption,描述剛剛直接觀察到的物件、動作、場景與狀態變化,並帶有時間標記。</Summary>:較稀疏的語意摘要,在事件結束後以較粗的粒度總結。
推論時,最近 16 到 32 幀(依任務以 1 到 4 FPS 取樣)仍以視覺 token 保留,作為「近期視窗」。更早的畫面離開視窗後,模型生成的 caption 會留在文字歷史中,提供長程上下文,不必再回頭取用歷史視覺特徵。訓練時用串流 caption 作為監督目標,讓模型學會解讀「已觀察的影片前綴」。因為記憶本身就是模型的輸出,它和問答用的是同一個語言空間,可以直接重用。
2. Proactive State Transition Learning(PSTL)
模型的輸出被設計成三種控制狀態:</Silence>(繼續觀察)、</Standby>(證據正在浮現但還不夠)、</Response>(產出使用者可見的回答)。難點在於 Silence 的樣本壓倒性地多。
PSTL 的做法是保留每一個輸出錨點(output anchor)的監督,同時只挑選具代表性的「狀態轉換」與「狀態持續」token 來計算損失。結果只監督了 27.5% 的已標註狀態 token,效果卻優於對所有 token 做密集 cross-entropy。
3. 串流資料合成管線與 OneStreamer-1M
作者設計了一條資料合成流程,透過「證據區間定位」(evidence-interval localization)與「回應時間校準」(response-time calibration),讓輸出內容與時間點對齊當下已有的證據,避免答案提早洩漏未來資訊。結合清理過的開源資料後,得到 OneStreamer-1M,共 1,160,004 筆,分四類:
- Proactive Caption Memory:60,000 筆
- Proactive Interaction:271,570 筆
- Proactive QA:197,584 筆
- Perception & Memory QA:630,850 筆
實驗結果
作者報告 4B 模型在八個串流影片理解 benchmark 上,都是所比較方法中的最佳。下表對照同底座的 Qwen3-VL-4B:
| Benchmark | OneStreamer | Qwen3-VL (4B) | 提升 |
|---|---|---|---|
| OVOBench | 72.1 | 58.8 | +13.3 |
| StreamingBench Real-Time | 86.9 | 81.8 | +5.1 |
| OVBench | 66.8 | 55.4 | +11.4 |
| ODVBench | 71.3 | 57.6 | +13.7 |
| ProactiveVQA | 48.7 | 34.3 | +14.4 |
| OmniMMI | 36.6 | 29.4 | +7.2 |
| OVO-Timing | 41.6 | 29.4 | +12.2 |
| ViSpeak | 2.87 | 2.41 | +0.46 |
提升最大的是和「主動回應」與「時間點判斷」相關的項目(ProactiveVQA +14.4、OVO-Timing +12.2),也包含一般的串流感知任務(OVOBench +13.3、ODVBench +13.7)。StreamingBench Real-Time 的基線本來就高(81.8),提升較小(+5.1)。要注意的是,這些提升是在「加入 OneStreamer-1M 訓練資料」與「新機制」兩者疊加下得到的,論文表格本身無法把兩者的貢獻完全分開,看消融實驗更能判斷各機制的作用。
消融實驗的重點有三個:
- 保留生成 caption 能改善歷史問答:在歷史記憶類的指標(ASI)上,從 63.5 提升到 71.6,而即時感知能力沒有下降。這回應了摘要裡「不犧牲即時感知」的主張。
- 階層式設計優於單一做法:「近期視覺視窗 + 遠端 caption 記憶」的組合,在記憶任務上勝過「保留完整歷史」,也勝過「只看近期」。
- PSTL 的選擇策略有效:選擇性狀態監督優於密集 cross-entropy。在監督比例相同的情況下,它也優於隨機挑選,說明收益來自「怎麼選」,而不單單是「選得少」。
意義
這篇論文有幾個值得注意的地方。
第一,記憶以文字形式存放。把歷史變成模型自己寫的 caption,有幾個實務上的好處:佔用的上下文遠比視覺 token 小,可以直接閱讀和除錯,也能被後續任何問題重用。代價是,caption 沒寫到的細節就永遠丟失了。所以「query-independent」的 caption 品質(寫什麼、寫多細)會成為上限。論文用 caption 監督資料(6 萬筆)來訓練這項能力,但在更開放、更長時間尺度的場景中是否仍然足夠,還需要觀察。
第二,「該不該說話」被當成一般的生成問題。用 </Silence>、</Standby>、</Response> 這些 token 表示狀態,不需要額外的決策頭,與感知和記憶共用同一套訓練流程。PSTL 針對類別不平衡的解法也很通用,任何「大部分時間無事發生」的序列決策任務(例如機器人監控、對話中的插話時機)都可能借用。
第三,4B 的規模說明了資料與介面設計的價值。在八個 benchmark 上贏過同類方法,而且用的是小模型,對想在邊緣裝置或低延遲場景部署的團隊很有吸引力。另一方面,「best among the compared methods」取決於作者選的比較對象與設定,讀者在採用前,最好自行核對論文中的完整比較表,以及是否包含更大的模型。
整體來看,OneStreamer 的主張是:把感知、記憶形成與主動回應,都歸結為同一種「主動生成」,是一條簡潔且可擴展的路線。後續值得追蹤的問題包括:caption 記憶在數小時以上的影片中會不會累積錯誤、</Observe> 的生成成本對即時延遲的影響,以及這套資料與模型是否會開源,讓社群能複現這些結果。