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