最近我在梳理流式視頻理解相關(guān)工作看標題為 StreamTTT 的工作時第一反應(yīng)是這名字起得太直白了。Stream TTT幾乎等于把“流式視覺語言模型”和“測試時訓(xùn)練”兩個詞焊在一起?？烧嬲业牟皇敲撬}目里的那組矛盾——Real-Time Perception 與 Long-Term Memory。做過 Streaming VLMs 落地的人都知道這組矛盾是所有實時視頻理解系統(tǒng)的“房間里的大象”。模型不是沒有能力看懂一幀畫面也不是完全沒有記憶能力而是當你要它一邊看下一秒一邊記得幾十秒前發(fā)生了什么還要在延遲可接受范圍內(nèi)回答問題時常規(guī)架構(gòu)會迅速達到天花板。常見做法像是在給一個不斷流進來的水龍頭接一個永遠在長大的杯子今天能接住十秒明天想接住十分鐘顯存和延遲一起爆炸。所以我想把這類方向拆開聊清楚Streaming VLMs 到底難在哪StreamTTT 想要協(xié)調(diào)的兩種能力為什么沖突測試時訓(xùn)練又能給出什么不一樣的解法。下面的內(nèi)容不會假裝我能復(fù)現(xiàn)論文全部細節(jié)主要從問題本質(zhì)、機制推理和工程落地三個角度展開。1. 實時感知和長期記憶不是功能沖突而是狀態(tài)管理問題1.1 流式任務(wù)看起來只是加了“流”實際上改變了解題順序先做個簡單的對比。一段普通視頻理解任務(wù)模型拿到的是完整、有頭有尾的視頻。模型可以先掃一遍全局知道這段視頻講的是一場會議、一段體育比賽還是一次機器運行然后再決定從哪一幀開始分析。這時候模型的時間觀是“上帝視角”過去、現(xiàn)在、未來都在輸入里躺著。但 Streaming VLM 面對的任務(wù)完全不同視頻流是持續(xù)不斷的模型面前永遠只有當前這一小段時間。你可能問它“現(xiàn)在畫面里有沒有異物”它不但要看懂這一幀還要知道“異物是剛剛出現(xiàn)還是已經(jīng)存在了一會兒”“上一段出現(xiàn)異物是什么時候”。這些問題都需要模型在不能回頭重看的約束下回答。真正讓問題變難的不是“每幀識別”而是時間尺度。單幀識別是感知問題可以在預(yù)訓(xùn)練階段解決得相當好跨時間的狀態(tài)判斷是記憶問題要求模型把過去的信息壓縮、保存、檢索再和當前幀融合。這兩件事在模型內(nèi)部用的機制不一樣資源消耗模式也不一樣。StreamTTT 的題目之所以故意把 Real-Time Perception 和 Long-Term Memory 并列我理解是它想說明這兩個需求不是一前一后排隊完成的而是要在同一條流上同時成立。你在實時看清當前畫面的同時其實也在持續(xù)改寫模型對“之前發(fā)生過什么”的認知。1.2 每一條新幀進來模型都要做一次“先遺忘再決策”的過程如果把一個 Streaming VLM 比作值班人員他的桌上不能堆滿過去所有幀因為下一幀進來時他根本沒地方放也不能完全不在乎過去因為大量問題要求跨時間回答。于是每個 step 其實都在暗中做三個決定哪些舊信息已經(jīng)沒用了可以丟。哪些舊信息還有用必須壓縮保存。當前幀的信息如何更新已保存的記憶。聽起來很自然但在基于 Transformer 的主流架構(gòu)里這個“狀態(tài)管理”過程是隱式的而且常常失控。模型并不真正知道哪些 token 該丟、哪些該留它只是把所有舊 token 塞進上下文里讓注意力自己去尋找需要的信息。如果舊 token 不太多效果不錯一旦上下文變得很長計算代價、緩存代價、還有注意力被稀釋的問題就會一起冒出來。所以我把這個問題稱為狀態(tài)管理問題而不是功能缺陷。模型不是“記不住”而是沒有一種高效、可控、可更新的狀態(tài)來表示已經(jīng)發(fā)生過的長歷史。2. 一條暗線長期記憶也許不該放在上下文里而該放在模型狀態(tài)里2.1 上下文越長代價不是線性增長而是平方級增長為什么不用滑動窗口加大一點就能解決假設(shè)每幀產(chǎn)生 F 個 token新視頻幀到達時把舊幀的 token 繼續(xù)留在 KV Cache 中。當歷史累積 N 幀時注意力計算涉及的總 token 數(shù)是N * F。視覺 token 本身數(shù)量就很大關(guān)鍵幀可能幾百上千個 token。KV Cache 的顯存開銷可能是單幀 token 數(shù)的好幾倍。在真正實時的場景里這個問題尤其尖銳。你不僅要保證單幀推理時間足夠短還要保證不會因為歷史 token 積累造成越來越慢最終跟不上視頻幀率。很多人最開始跑流式 demo 能很流暢跑 5 分鐘后就開始掉幀原因往往就是 KV Cache 在無聲地膨脹?；瑒哟翱诳此平鉀Q了失控膨脹但代價是記憶變成“最近幾秒”。如果模型剛回答完“當前畫面正?！蹦懔⒖套穯枴澳莿偛拍莻€異常事件持續(xù)了多久”它就會因為沒有歷史記憶而卡住。窗口太大模型能記住但實時性崩掉窗口太小心實時性夠了但記憶能力不足。StreamTTT 想打破的正是這個非此即彼。2.2 摘要、檢索、記憶池都是好用的外掛但都沒有解決“更新”這個問題工程上常用的妥協(xié)方案有幾種把歷史幀抽幀讓 LLM 定期生成摘要存成更短的文本。把關(guān)鍵幀的 embedding 存到向量數(shù)據(jù)庫回答問題時做相似度檢索。設(shè)置一個外部記憶池把重要事件按時間戳寫進去回答時額外拼給模型。這些方案都能一定程度上平衡實時感知和長期記憶但如果細看就會發(fā)現(xiàn)它們都假設(shè)“記憶”獨立于“感知”存在。系統(tǒng)先感知把關(guān)鍵信息提取出來再寫進外部記憶。問題在于什么樣的信息算關(guān)鍵本身就是動態(tài)的。你看完第 50 秒后可能才發(fā)現(xiàn)第 10 秒那個普通瞬間是關(guān)鍵。如果當時沒有把那個瞬間存下來后面再檢索也沒用。所以這類外掛方案真正瓶頸不在存儲而在“當時當刻如何決定該記住什么”。這個決定需要模型對當前幀和歷史上下文有聯(lián)合理解而且需要在極短的時間內(nèi)完成。2.3 一種反直覺的設(shè)計“記憶”不應(yīng)該是緩存而應(yīng)該是模型參數(shù)這里有一條在 RNN 時代很流行、后來被 Transformer 遮蔽的思路把記憶放在模型的隱藏狀態(tài)里。RNN 的隱藏狀態(tài)本質(zhì)上是一個向量在每步讀入新 token 后更新因此天然適合流式輸入。它的容量非常有限一個幾千維的向量很難編碼復(fù)雜的長視頻歷史。這也是它后來在長序列任務(wù)里被 Transformer 壓倒的重要原因。但如果把“隱藏狀態(tài)”的概念升級一下不再只存一個向量而是讓隱藏狀態(tài)本身是一個可更新的模塊情況就不同了。傳統(tǒng) RNN 的隱藏狀態(tài)被固定大小的向量卡住而“把記憶當作參數(shù)”的思路允許隱藏狀態(tài)擁有更強的表達能力。這就引出了 StreamTTT 這類工作的核心機制Test-Time TrainingTTT。3. TTT 提供的機制在測試時讓模型自己更新自己3.1 拆開看什么是 Test-Time TrainingTest-Time Training 的基本想法很反直覺模型推理時不只用前向傳播做預(yù)測還會先在測試輸入上做一步自監(jiān)督學(xué)習(xí)更新一部分模型參數(shù)然后再做預(yù)測。過去 TTT 更多用于分布偏移場景。比如訓(xùn)練集里只有晴天照片測試時來了雨天照片模型可以在雨天照片上先做一步自監(jiān)督任務(wù)把自己稍微調(diào)整到更適應(yīng)雨天分布再輸出分類結(jié)果。它相當于把訓(xùn)練過程延伸到了測試階段。而把 TTT 用在長上下文建模上的關(guān)鍵工作我清楚地記得是 2024 年的那篇Learning to (Learn at Test Time): RNNs with Expressed Memories。它把 RNN 的隱藏狀態(tài)從一個固定向量升級成了一個小型模型的參數(shù)。每讀到一個新 token模型不僅更新 RNN 的外部隱藏狀態(tài)還要在內(nèi)部更新這個“記憶模型”。換句話說模型對待見過的內(nèi)容不是把它們簡單堆在緩存里而是把它學(xué)進自己的參數(shù)里。這正好給流式 VLM 提供了一個可能的答案與其讓視頻幀 token 無限堆積不如在每一幀到達時用當前幀和之前狀態(tài)構(gòu)造一個自監(jiān)督目標讓模型把“這一段歷史”編碼進一個可更新的記憶表示里之后舊幀 token 可以放心丟棄。3.2 為什么這個機制和視頻流任務(wù)天然契合視頻流任務(wù)里通常找不到一個完美的“未來監(jiān)督信號”但同一個視頻流內(nèi)部有大量自然的自監(jiān)督目標。一個很簡單的例子當前幀前面幾幀都描述了同一場景模型如果能利用前后幀的一致性做重建或者對比學(xué)習(xí)就有機會把“這個場景現(xiàn)在長什么樣”沉淀到記憶參數(shù)里。之后即使這些幀不再出現(xiàn)在上下文中記憶參數(shù)仍然保留著該場景的核心信息。這種“看完一段學(xué)進一段然后放下一段”的過程非常接近人理解視頻的方式。你不是在腦子里回放所有幀而是不斷更新自己對“事情發(fā)展到哪一步了”的理解。TTT 在這里還有一個工程上的吸引力它不依賴未來幀符合流式約束。每處理一幀只需要當前幀和當前記憶狀態(tài)不需要停在那里等后面的幀。對于 Streaming VLM 來說這是比雙向注意力模型更適合的機制。3.3 一個值班交接記錄式的類比可以把流式視頻理解比作多個人輪班盯監(jiān)控。傳統(tǒng)的 Transformer 方案相當于每個人接班時都把之前同事寫的所有原始日志一字不差地貼出來然后自己從頭讀。日志越來越厚接班越來越慢。摘要方案呢相當于上一班同事給了一個很短的總結(jié)但總結(jié)往往遺漏了只有看到原始畫面才能判斷的細節(jié)。TTT 風(fēng)格的做法更像是一本可以隨時改寫的交接記錄里面不只是文字還有當前場景的關(guān)鍵狀態(tài)。每個值班人員看到新情況后會按一套規(guī)則更新記錄重要的新情況寫進去不再重要的舊細節(jié)被覆蓋掉。后來的接班人員不用翻閱所有舊日志只看這本最新狀態(tài)的記錄就能快速形成判斷。這個類比當然不完美但它能解釋一個問題為什么長期記憶和實時感知不能通過“加長窗口”或者“簡單摘要”輕松解決。因為兩者本質(zhì)上都把歷史當成靜態(tài)的東西而不是隨每個新幀同步更新的動態(tài)狀態(tài)。4. StreamTTT 的三種可能機關(guān)從題目里讀出的方向接下來這部分我必須先說清楚相關(guān)論文摘要和完整方法細節(jié)在我掌握的材料里沒有完整出現(xiàn)所以這里不是復(fù)述給定結(jié)論而是結(jié)合標題、熱詞和技術(shù)脈絡(luò)做推理。StreamTTT 的完整名稱是 Reconciling Real-Time Perception and Long-Term Memory in Streaming VLMs。如果我們要理解它可能怎么實現(xiàn)可以從題目中的 “Stream”、“TTT”、以及“長期記憶”三個詞分別出發(fā)。4.1 方向一視覺 token 不直接進 LLM先進 TTT 記憶層流式 VLM 的做法通常是視頻幀經(jīng)過視覺編碼器變成若干視覺 token然后和文本指令一起進入 LLM。當視頻流很長時視覺 token 越來越多LLM 的上下文壓力也越來越大。一個自然的改動是在視覺編碼器和 LLM 之間插入一個 TTT 層。該層每次接收一小段視覺 token不把它們?nèi)拷唤o LLM而是先把視覺信息壓縮進 TTT 層的“記憶參數(shù)”。LLM 實際看到的只有 TTT 層當前狀態(tài)對應(yīng)的輸出表示。這樣舊幀沒有堆積在 LLM 上下文里而是被編碼進了一個不斷更新的狀態(tài)。這個設(shè)計如果成立真正的收益是LLM 自身處理的 token 數(shù)可以保持相對穩(wěn)定不再隨視頻時長無限增長。模型“記住十年前”和“記住十秒前”的代價差異也從“逐 token 重放”變成“狀態(tài)更新一次”。這種設(shè)計在直覺上最接近 TTT 論文里“替代 self-attention”的角色。把一個長序列處理問題轉(zhuǎn)變成一個固定大小的狀態(tài)更新問題。4.2 方向二快速感知和慢速記憶走雙時間尺度“Reconciling Real-Time Perception and Long-Term Memory”還有一種可能的實現(xiàn)方式系統(tǒng)中存在兩套時間尺度?？焖俪叨蓉撠煯斍皫睦斫庖蟮脱舆t關(guān)注視覺細節(jié)窗口很小。慢速尺度負責歷史信息的長期積累用 TTT 維護一段緩慢更新的記憶不會因為單幀抖動而劇烈變化。這有點像人腦的感覺記憶和工作記憶的分離。感知層看到的永遠是“現(xiàn)在”但長期記憶層把“現(xiàn)在”的經(jīng)驗慢慢沉淀到結(jié)構(gòu)化的狀態(tài)里。需要回答“剛才發(fā)生了什么”這種問題時模型不直接去查原始幀, 而是查那個已經(jīng)更新到當前時刻的記憶層。如果 StreamTTT 真的采用雙時間尺度結(jié)構(gòu)它的核心貢獻可能不只是“用 TTT 替代注意力”而是提出一套如何在流式 VLM 中分配“快速感知資源”和“慢速記憶資源”的思路。前者看重實時性后者看重一致性。4.3 方向三把“連續(xù)語義”當成 TTT 的自監(jiān)督目標TTT 要更新參數(shù)必須有一個損失函數(shù)。但視頻流沒有人工標注幀所以自監(jiān)督目標的選取很關(guān)鍵。從常見做法推測StreamTTT 大概率利用視頻時間連續(xù)性當前時刻的隱表示應(yīng)該能預(yù)測鄰近時刻的某種信息或者同一事件里的多次觀測應(yīng)該在記憶空間中保持相近。這有助于讓 TTT 層學(xué)會“什么值得保留”。但這里有一個需要特別注意的點連續(xù)幀之間不一定都相似。視頻里常見鏡頭切換、場景突變、事件轉(zhuǎn)折。如果自監(jiān)督目標只獎勵“預(yù)測相近的下一幀”模型可能在場景切換后更新不上來。成熟的實現(xiàn)應(yīng)該需要設(shè)計一個門控或者切換機制讓記憶在連續(xù)階段平穩(wěn)更新在突變階段允許重置或者大跨度調(diào)整。在沒有讀到論文完整方法前我不建議把上面三個方向當成已證實的結(jié)論。更合理的做法是把它們當作重新設(shè)計實驗時的三種假設(shè)用可復(fù)現(xiàn)的實驗一一代入驗證。5. 和其他記憶方案對比各有各的取舍為了把 StreamTTT 的定位講清楚我整理了一張記憶方案對比表。這些方案在 Streaming VLM 長期記憶問題上各有擁躉核心差異就在于“在哪個環(huán)節(jié)做記憶”以及“是否動態(tài)更新”。方案實時性能長記憶能力狀態(tài)是否動態(tài)更新主要風(fēng)險長上下文 全量 tokens隨上下文增長下降明顯強但資源消耗不可控否靠注意力隱式檢索KV Cache 無限膨脹延遲難以保證滑動窗口最好基本恒定弱只保留最近一段否超出窗口直接丟棄對需要歷史事件的問題幾乎失效周期性文本摘要中等摘要生成本身耗時中依賴摘要質(zhì)量半動態(tài)歷史被重寫后無法糾錯關(guān)鍵細節(jié)丟失摘要口徑不一致外部向量檢索中等檢索耗時有波動強數(shù)據(jù)庫可無限擴展否寫入時一次性決定寫入時沒標記為重要就再也查不到外部記憶池/事件流中等中強取決于事件抽取質(zhì)量半動態(tài)需要額外的“事件感知識別”模塊TTT 記憶狀態(tài)理論上接近恒定單步更新中強取決于記憶參數(shù)容量是每幀都會更新更新機制不穩(wěn)定自監(jiān)督目標設(shè)計難對這張表補充幾個判斷滑動窗口仍然是基線里最實用的一種因為它簡單、可控、不會在實時場景中失控。但它“沒有記憶”的缺陷決定了它只適合那些只關(guān)心當下的任務(wù)。外部向量檢索適合離線事件回溯但在流式場景里它非常依賴你早先是否已經(jīng)識別并索引了相關(guān)信息。你沒有辦法檢索一個在寫入時就被判定為“不重要”的事件。TTT 不是全能解它把記憶問題轉(zhuǎn)化為“記憶參數(shù)容量”和“更新目標設(shè)計”問題。參數(shù)容量太大單步更新慢太小記憶能力不足可能比摘要好但遠達不到“忠實記住所有關(guān)鍵幀”的程度。這也是我認為 StreamTTT 這類工作的價值在于“協(xié)調(diào)”而不是“碾壓”的原因。它不是宣稱自己解決了長期記憶問題而是把實時感知和長期記憶放進同一個更新循環(huán)里讓雙方可以互相遷就。6. 從“看起來有道理”到“真的有效”評估和復(fù)現(xiàn)時容易翻車的地方如果看完前面分析你很想自己做一個 TTT 風(fēng)格的流式 VLM 實驗?zāi)敲丛u估環(huán)節(jié)比模型結(jié)構(gòu)更值得先想清楚。6.1 先定義清楚你要評測的是實時感知還是長期記憶還是兩者協(xié)同一個常見錯誤是拿一段短視頻直接測試。短視頻里模型只要上下文裝得下全部幀就能把問題答對。這考察的其實還是長上下文能力不是流式記憶能力。要驗證“實時感知 長期記憶”的協(xié)同能力通常需要構(gòu)造如下條件視頻流足夠長明顯超出模型上下文窗口。關(guān)鍵事件出現(xiàn)在較早時刻但問題在幾十秒甚至幾分鐘后才被提出。視頻流以“逐幀到達”的方式輸入模型不能一次性看到全部未來幀。對模型回答案延遲有約束不允許把整段視頻先緩存再離線處理。我建議在一開始就把評測集拆成三檔分別看三件事感知檔只問當前畫面內(nèi)容確認模型的基礎(chǔ)單幀理解沒有退化。短期記憶檔事件出現(xiàn)在 10 秒內(nèi)確認快速更新路徑正常工作。長期記憶檔事件出現(xiàn)在數(shù)分鐘前中間穿插大量無關(guān)幀確認模型沒有遺忘。只有三檔都有結(jié)果你才能定位瓶頸在感知、記憶還是兩者協(xié)調(diào)上。6.2 常見的失敗現(xiàn)象和排查鏈路如果效果不好先不要急著調(diào)整 TTT 損失函數(shù)的權(quán)重。按下面順序排查通常能更快定位問題先看輸入流本身視頻幀有沒有按時序輸入有沒有丟幀、亂序、重復(fù)幀TTT 更新對順序非常敏感輸入亂序會導(dǎo)致記憶狀態(tài)反復(fù)被改寫。再看記憶更新是否真的發(fā)生把模型在插入 TTT 層前后做輸出對比。如果效果沒有差異大概率是 TTT 層被旁路或者損失權(quán)重太低模型沒有真正利用記憶。然后看記憶容量把記憶參數(shù)從小調(diào)大觀察長時記憶問題是否改善。如果提升不明顯問題可能不在容量而在更新目標沒有讓記憶編碼到足夠關(guān)鍵的信息。接著看事件密度如果視頻里每秒都有大量不同事件模型可能來不及在記憶里完成更新。這就要檢查 TTT 層更新頻率是否和幀率匹配。最后看評測問題本身如果問題問的是“某幀出現(xiàn)了什么具體文字”這本來就更適合檢索式方案TTT 風(fēng)格記憶不一定能很好支持。這類細粒度跟蹤需求和“全局狀態(tài)理解”需要分開測試。一個務(wù)實的建議先用離線小規(guī)模閉環(huán)驗證再上實時流。不要一開始就接攝像頭或者直播流否則排查輸入問題和模型問題會混在一起很難快速定位。6.3 什么時候值得上這種方案什么時候還是別硬上最后聊適用邊界。需要 TTT 風(fēng)格記憶的場景通常具備這些特征歷史信息和當前判斷必須連續(xù)關(guān)聯(lián)。視頻流很長且模型需要以幾乎恒定的延遲工作。關(guān)鍵信息散布在長時段里無法用一句話摘要充分覆蓋。部署環(huán)境允許在推理階段做額外自監(jiān)督更新也就是有一定算力余量。不適合的場景同樣明顯如果單幀問答完全夠用不需要跨時間關(guān)聯(lián)滑動窗口仍然是成本最低的方案。如果任務(wù)要求精確到秒級的事件回溯本身更適合事件檢測加向量索引不要把所有責任都壓給記憶模塊。如果推理硬件的時延余量很小TTT 單步更新可能反而成為瓶頸。從工程經(jīng)驗看任何帶“測試時更新”的方案都要額外評估穩(wěn)定性和安全性。模型在推理時還在更新意味著它可能因為某一段異常輸入把記憶狀態(tài)更新到錯誤方向。如何限制更新幅度、如何回滾異常狀態(tài)、如何防止輸入中對抗性幀污染記憶這些都是走向生產(chǎn)環(huán)境前必須想清楚的事。結(jié)尾真正值得關(guān)注的不是“看得更快”而是“記得的方式”回到開頭那個問題。StreamTTT 這類方向最吸引我的不是它讓 Streaming VLM 處理某段視頻的跑分提高而是它試圖重新定義“長期記憶”的形態(tài)。在主流 Transformer 范式里記憶幾乎等價于“把舊 token 留在上下文中”。這個定義方便注意力機制去查但它忽略了記憶是一個在線過程你每次看到新東西對過去的理解都可能發(fā)生改變。真正的記憶不只是存儲而是持續(xù)的更新。如果沿著 TTT 這條路繼續(xù)走未來 Streaming VLM 的架構(gòu)可能會發(fā)生一個很有意思的轉(zhuǎn)變模型在實時感知的同時本身就在被視頻流“訓(xùn)練”。它看過的每一段視頻都在微調(diào)那個負責記憶的內(nèi)部狀態(tài)。實時感知和長期記憶不再是兩套分開的資源而是同一個測試時學(xué)習(xí)循環(huán)里互為前提的兩個環(huán)節(jié)。如果你想自己做點實驗我的建議是從小規(guī)模閉環(huán)開始。先做一個 TTT 記憶層接到一個現(xiàn)有 VLM 的視覺 token 后面構(gòu)造一條 5 分鐘以上的合成視頻流要求模型回答跨越不同時間點的問題。先跑通再觀察哪些問題類型被它解決哪些問題類型依然無解。這樣你對“把測試時訓(xùn)練用在流式 VLM 身上”這件事的價值和代價會有遠比今天更具體的體感。