AURA：讓視頻大模型從“看完再答”，走向邊看邊理解、邊看邊響應

• 論文標題：AURA: Always-On Understanding and Real-Time Assistance via Video Streams
• 論文地址：https://arxiv.org/pdf/2604.04184
• GitHub鏈接：https://github.com/aurateam2026/AURA

近年來，視頻多模態大模型（VideoLLM）發展迅猛，在視頻描述、視頻問答、時序定位等任務上不斷刷新性能上限。隨著模型能力持續增強，業界也開始思考一個更重要的問題：視頻大模型能不能不再只是 “看完一段視頻再回答”，而是真正進入實時世界，持續觀察、實時理解，并在關鍵時刻主動給出反饋？

由香港中文大學 MMLab 與華為小藝大模型應用實驗室聯合推出的 AURA，正是對這一問題的一次有力回應。論文通訊作者為香港中文大學 MMLab 李鴻升副教授和華為小藝大模型應用實驗室主任劉睿博士。小藝大模型應用實驗室長期關注終端智慧助手從被動響應走向持續感知、主動服務與世界交互的演進。AURA 的提出，不僅是面向真實場景的一次重要探索，也讓視頻模型朝著真正理解世界、參與交互邁出了關鍵一步。

AURA 的全稱是Always-On Understanding and Real-Time Assistance via Video Streams，是一套面向實時視頻流的端到端視覺交互框架。它希望構建的不再是一個 “事后分析員”，而是一個始終在線的視覺助手：一邊持續接收視頻流，一邊理解場景變化，在需要的時候回答問題，在應該沉默的時候保持安靜，甚至還能在發現關鍵信息時主動提醒用戶。

為什么傳統 VideoLLM 不夠用？

盡管現有 VideoLLM 已經在多個任務上取得不錯成績，但大多數方法仍然建立在 “離線視頻理解” 的范式上：先把整段視頻緩存下來，再交給模型統一處理。這種方式很適合做事后分析，卻不適合實時助手、直播理解、機器人交互、現場監控等對時效性要求極高的場景。

更進一步說，流式視頻理解并不是簡單把 “離線推理” 加快一點就能解決的。它至少帶來了兩個新挑戰。第一，視頻流和對話歷史會不斷增長，模型如何在有限上下文里持續工作；第二，模型不只是要 “會答題”，還要學會判斷什么時候該說、什么時候不該說、什么時候應該等看到更多信息后再說。論文認為，現有方法要么采用 “觸發模型 + 主模型” 的分離式架構，容易出現觸發判斷和最終回答不一致的問題；要么雖然是統一式架構，但更偏連續描述，對復雜開放式問答和長時間交互的魯棒性仍然不足。

AURA 想做什么？

為了解決這些問題，論文提出了 AURA：一套基于統一 VideoLLM 的實時視覺交互框架。AURA 的目標很明確：

一是讓同一個模型能夠逐幀處理視頻流，并自主決定是保持沉默，還是輸出合適的回答；

二是讓系統能穩定處理無界增長的視頻和文本輸入，在長時間持續運行時依然保持可用。

圍繞這兩個目標，AURA 并不是只改了某一個模塊，而是從上下文管理、數據構造、訓練目標到推理部署做了整套協同設計。這也是這篇工作的亮點所在：它不是單點優化，而是把 “流式視頻理解” 當成一個完整系統問題來做。

AURA 具有以下幾個顯著特點

AURA 推理流程

1. 統一式流式視覺交互

AURA 不再把 “是否響應” 和 “如何響應” 拆給兩個不同模型，而是讓統一模型在連續視頻流中直接完成觀察、判斷和回答。這種方式的好處是，模型的上下文理解和最終響應來自同一套內部狀態，理論上更一致，也更適合復雜的開放式交互。

2. 不只是回答問題，還會 “選擇沉默”

AURA 認為，實時視覺助手最關鍵的能力之一，不是一直說話，而是知道什么時候不該說話。在真實流式場景里，大多數時間模型都應該保持沉默，只有在用戶提問、場景發生關鍵變化，或者用戶預先設定的條件被觸發時，才需要輸出響應。為此，AURA 專門圍繞 “沉默” 和 “發聲” 的平衡設計了訓練目標。

三種 QAs 示例

3. 支持三類流式問答

AURA 把流式交互分成三類。

第一類是Real-Time QA，也就是實時問答。用戶提出問題后，模型立刻基于當前或已觀察到的畫面給出回答。

第二類是Proactive QA，也就是主動式問答。用戶先拋出一個請求，模型不一定馬上回答，而是等未來出現足夠證據時再給出響應。

第三類是Multi-Response QA，也就是多次響應問答。針對一個持續演化的場景，模型可以隨著新信息出現，陸續給出多個回答，而不是只答一次。論文明確指出，這三類問答共同構成了 AURA 數據構造和能力建模的核心。

AURA 的設計思路

流式上下文管理

交互式視頻流上下文管理

AURA 首先設計了一套Interactive Video Stream Context Management機制。簡單理解，它把視頻流切成一個個小時間塊，并把每個時間塊對應的用戶輸入、模型回答、以及 “沉默” 狀態組織成連續對話。

為了避免上下文無限增長，AURA 使用了 “雙滑動窗口” 策略。一邊保留最近一段視頻窗口，另一邊保留最近若干組問答歷史。視頻窗口負責保存最新的視覺證據，問答窗口則保留用戶意圖和關鍵歷史信息。這樣既能控制上下文長度，又能盡可能保留對交互最有價值的信息。論文給出的默認超參數是：視頻窗口長度 30 秒，額外緩沖 15 秒，保留最近 10 組 QA 歷史。

Coarse-to-Fine 數據引擎

Coarse-to-Fine 數據引擎

流式問答的難點，不只是模型結構，更在于訓練數據怎么構造。AURA 為此設計了一套五階段數據引擎，包括：

視頻預處理，QA 合成，QA 精煉，流式結構化，質量校驗

在視頻預處理階段，團隊從公開互聯網收集了體育、vlog、紀錄片、百科內容、影視、課程、游戲、動畫等多種類別的視頻，并統一重采樣到 2 FPS，同時轉碼為 H.264，以提升后續處理的一致性和穩定性。

在QA 合成階段，AURA 分別為不同類型的流式問答構造監督信號。對于實時問答和主動問答，模型會先做場景分段和描述，再生成帶時間戳的問答對；對于多次響應問答，則會生成同一問題在不同時間點的多個有效答案。之后，這些候選樣本還要經過再次驗證，確保問題合理、答案有依據、時間戳準確。

在QA 精煉階段，AURA 進一步增強訓練樣本的多樣性。比如對實時問答增強難度層級，對主動問答和多響應問答改寫不同表述方式，以更貼近真實用戶在流式交互中的提問習慣。

在流式結構化階段，AURA 會把前面得到的帶時間戳 QA 標注，轉換成真正符合流式推理形式的訓練樣本。具體來說，系統先按時間塊組織視頻和對話，再按雙滑動窗口規則截斷上下文，最后把同一段連續交互 “展開” 為多個訓練樣本。每個樣本只對應一個需要監督的目標回答，并以前文歷史作為上下文。這樣做的目的，是讓訓練過程盡量貼近真實在線推理時的輸入形式。

在質量校驗階段，AURA 會進一步檢查：經過窗口截斷后，當前保留下來的視頻內容和歷史上下文，是否仍然足以支撐目標答案。如果證據不足，模型就可能學到 “明明看不到也硬答” 的壞習慣，增加幻覺風險。因此，AURA 會過濾掉那些視覺依據不充分、時間對應不準確、或者答案與上下文不一致的樣本，只保留真正可靠的數據。對于實時問答，重點檢查答案是否有視覺支撐、是否事實正確、是否時間一致；對于主動問答和多響應問答，則重點檢查回答時機是否合理、內容是否準確且 grounded。

專門為 “沉默與發聲” 設計的訓練目標

AURA 的訓練目標叫Silent-Speech Balanced Loss。這個設計非常關鍵。

原因在于：在流式場景里，沉默消息遠比非沉默回答多得多。如果直接用普通交叉熵訓練，模型很可能學到一個 “最安全策略”—— 盡量一直沉默。與此同時，由于滑動窗口會截斷上下文，較早的歷史回答在當前窗口中可能已經沒有足夠證據支撐，如果繼續把這些回答都當作監督目標，還會增加模型幻覺風險。

因此，AURA 采用了兩項策略：

一是只監督所有沉默消息和最后一個非沉默回答；

二是對沉默類目標降權，讓 “沉默” 和 “發聲” 在訓練中保持相對平衡。

從消融實驗來看，這個設計非常有效。若改回默認交叉熵損失，AURA 在 OmniMMI 上的總體成績會從25.4%降到16.4%，其中主動提醒能力 PA 甚至會直接掉到 0.0%。這說明對于流式智能體來說，“什么時候不說” 確實和 “說什么” 一樣重要。

實時部署怎么做？

除了訓練，AURA 還專門設計了實時推理系統。系統把視頻流、ASR 和 TTS 集成在一起，支持視頻輸入、語音輸入、多模態推理和語音輸出的完整閉環。

為了保證長時間運行時的低延遲，AURA 在推理階段引入了 KV cache 復用和帶緩沖區的浮動窗口策略。相比每來一幀就立刻刪最舊內容的簡單 FIFO 方式，這種設計能減少前綴變化頻率，從而更高效地復用已計算過的緩存，顯著降低重復計算。論文實驗表明，滑動窗口和 prefix caching 兩者結合，才能同時控制上下文增長并維持較低的首 token 延遲。

在部署層面，AURA 以Qwen3-VL-8B-Instruct為底座模型，并集成 ASR 和 TTS，最終實現了一個可實際演示的實時系統。部署優化后，系統可在兩張 80G 加速卡上以2 FPS實時運行。

AURA 的訓練與實驗結果

StreamingBench 測試結果

OVO-Bench 測試結果

OmniMMI 測試結果

訓練方面，AURA 使用約11.5 萬條流式視頻 QA 樣本和約5.9 萬條離線視頻 QA 樣本，總計約17.4 萬條樣本、約12 億 token。模型初始化自 Qwen3-VL-8B-Instruct，只微調 LLM 部分，視覺編碼器和連接模塊保持凍結。

在基準測試上，AURA 在三個代表性流式視頻理解 benchmark 上都取得了當前最優結果：

• StreamingBench上，AURA 總分達到73.1%
• OVO-Bench上，AURA 總分達到65.3%
• OmniMMI上，AURA 總分達到25.4%

更值得注意的是，AURA 不僅超過了多種開源基線，在部分指標上也超過了 GPT-4o 和 Gemini-1.5-Pro 等閉源模型，說明它在 “實時視覺理解 + 主動交互” 這個方向上確實做出了比較完整的系統突破。

當然，AURA 也不是完全沒有代價。論文報告顯示，經過流式訓練后，模型在傳統離線視頻理解任務上的表現相比底座模型會有一定回落，但整體仍然保持了較強競爭力。這也說明，AURA 并不是簡單追求 benchmark，而是在離線能力與在線交互能力之間做了一次相對均衡的工程取舍。

實時性能表現如何？

延遲測試結果

論文還給出了端到端延遲拆解。

• ASR 轉寫延遲約84.2 ms
• AURA 主模型 TTFT 約75.0 ms
• 首句解碼時間約60 ms
• TTS 首塊語音延遲約93.0 ms

綜合估算，從用戶語音輸入到系統輸出第一段語音回復的總延遲約為312.2 ms。對于一個同時涉及視頻理解、語音識別、文本生成和語音合成的系統來說，這個速度已經非常接近實時交互體驗。

總結

從這篇論文可以看出，AURA 想解決的并不是傳統的視頻問答，而是一個更接近真實世界的問題：如何讓視頻大模型成為一個始終在線、持續觀察、懂得沉默、能夠主動響應的視覺助手。

它的核心價值，不只是提出了一個新模型，而是把流式視頻理解這件事拆解成了一整套可落地的方法：

有上下文管理，有三類流式交互定義，有系統化的數據引擎，有專門為 “沉默 — 發聲” 平衡設計的訓練目標，還有面向實時部署的高效推理框架。

如果說過去的視頻大模型更像 “看完錄像后寫報告的人”，那么 AURA 想做的，就是一個真正站在現場、持續值守、隨時響應的 AI 助手。隨著這類工作不斷推進，未來的視覺智能系統或許不再只是 “回答你問了什么”，而是能進一步理解場景、理解時機，并在真正重要的時候主動開口。