裁判吹響哨子的那一刻，你會盯著哪里？

(資料圖片僅供參考)

如果你正在看一場足球比賽的回放，有人問你："哨響之后，裁判做了什么手勢？"你的注意力會立刻從"哨子響的那一秒"跳到"裁判舉手的那一秒"。這兩個瞬間在時間軸上根本不重疊。聲音的關(guān)鍵信息在前面，畫面的關(guān)鍵信息在后面。

這聽起來是句廢話，人本來就是這樣看視頻的。但如果你要設(shè)計一個AI模型，讓它同時處理視頻里的畫面和聲音，這句"廢話"就變成了一個技術(shù)難題。因為現(xiàn)在幾乎所有的做法，都假設(shè)畫面和聲音的"重要時刻"應(yīng)該是一致的。

這篇論文要講的,就是研究者們發(fā)現(xiàn)了這個假設(shè)是錯的,并且找到了一個不需要重新訓(xùn)練模型的解決辦法。

視頻AI的"內(nèi)存爆炸"難題

先說說為什么這件事非解決不可。

現(xiàn)在能同時理解視頻和音頻的AI模型，行話叫**全模態(tài)大語言模型**

全模態(tài)大語言模型：一種可以同時處理視覺、聽覺和文字三種信息的AI模型，比如阿里的Qwen2.5-Omni，能一邊"看"視頻一邊"聽"聲音，然后回答關(guān)于這段視頻的問題

這類模型的工作方式是，把視頻拆成一幀一幀的畫面，把音頻拆成一段一段的聲波，分別塞進(jìn)兩個不同的"翻譯器"里，翻譯成AI能理解的**token**

Token：可以理解成AI處理信息的最小單位，一段文字、一幀畫面、一小段聲音，經(jīng)過編碼后都會變成一串token，模型就是靠處理這些token序列來"理解"內(nèi)容的

問題來了：視頻越長，token就越多。一部十分鐘的視頻,可能產(chǎn)生幾萬個token,這些token全部要塞進(jìn)AI的"注意力計算"里,計算量會隨著token數(shù)量的增加而急劇膨脹。這不僅讓模型跑得慢、吃顯存,還會讓真正重要的信息被大量無關(guān)token"稀釋",導(dǎo)致模型在長視頻里抓不住重點。

于是"token壓縮"就成了繞不開的一環(huán),思路很直接:既然很多token是冗余的,能不能提前把它們篩掉或者合并掉,只留下真正有用的?

在純視覺領(lǐng)域，這個方向已經(jīng)研究得比較成熟了，有不少方法能把圖片或視頻里的冗余視覺token砍掉一大半而不影響準(zhǔn)確率。但音頻和視頻要一起壓縮，這個組合題目前研究得還很少。

現(xiàn)有的少數(shù)幾個方案,采用的是一種叫"單向跨模態(tài)引導(dǎo)"的策略。簡單說就是:讓一個模態(tài)說了算,由它來決定另一個模態(tài)該保留哪些token。比如OmniZip這個方法,就是用音頻的重要性打分,去指導(dǎo)視頻token怎么砍。

這個思路聽起來挺合理，聲音里說了"進(jìn)球了"，那畫面上進(jìn)球那一刻的幀當(dāng)然更重要嘛。但研究者們做了個實驗，發(fā)現(xiàn)這個假設(shè)經(jīng)常是不成立的。

78.3%的樣本里，眼睛和耳朵根本不在同一個頻道

研究團(tuán)隊找來1197對"問題-視頻"樣本，分別用CLIP（負(fù)責(zé)視覺打分）和CLAP（負(fù)責(zé)音頻打分）去計算，針對同一個問題，視頻每一幀的重要性分?jǐn)?shù)，以及音頻每一秒的重要性分?jǐn)?shù)。

CLIP：一種能同時理解圖片和文字的AI模型，能計算一張圖和一句話的"匹配程度"，分?jǐn)?shù)越高說明這張圖跟這句話越相關(guān)

CLAP：跟CLIP類似，只不過CLIP處理的是"圖片+文字"，CLAP處理的是"聲音+文字"，用來判斷一段音頻和一句話的相關(guān)程度

結(jié)果算出來的斯皮爾曼相關(guān)系數(shù)，78.3%的樣本，視覺重要性曲線和音頻重要性曲線之間的相關(guān)性都很弱（相關(guān)系數(shù)絕對值小于0.3）。

這個數(shù)字什么概念？相關(guān)系數(shù)接近0，意味著"視頻里最重要的那一刻"和"音頻里最重要的那一刻"幾乎是兩條互不相干的曲線，誰也預(yù)測不了誰。換句話說，絕大多數(shù)情況下，靠一個模態(tài)去猜另一個模態(tài)的重點，基本等于瞎猜。

這就是論文里說的"跨模態(tài)顯著性錯位"。如果你只用音頻的重要性去決定該留哪些視頻幀，那些音頻聽起來平平無奇、但畫面上恰好在做關(guān)鍵動作的瞬間，很可能被直接砍掉。反過來也一樣。

論文開頭舉的那個例子特別形象：裁判吹哨之后打手勢判罰，問題是"哨響后裁判做了什么手勢"。聲音的高潮在哨聲那一刻，畫面的高潮在打手勢那一刻，兩者錯開了好幾秒。如果用音頻引導(dǎo)視頻壓縮，哨聲附近的畫面幀會被留下來，但真正回答問題所需要的"打手勢"那一幀，很可能因為音頻當(dāng)時很安靜而被判定為不重要，直接刪掉。答案就這么丟了。

這就像什么呢？

想象你在整理一場婚禮的照片和錄音，你打算用錄音的"熱鬧程度"來決定留哪些照片。錄音里最熱鬧的時刻是賓客碰杯歡呼那一段，于是你把那幾分鐘的照片全部保留了下來?？尚氯私粨Q戒指的那一刻，現(xiàn)場安靜得只有主持人的聲音,錄音波形平平無奇。如果按錄音熱鬧程度去篩照片，交換戒指這張最該保留的照片反而最容易被漏掉。你留下的是熱鬧，丟掉的是重點。這不是一個抽象的比喻，這就是單向引導(dǎo)壓縮的真實代價：它優(yōu)化的是"某一個模態(tài)自己覺得重要的東西"，而不是"這個問題真正需要的東西"。

壓縮之后，注意力去哪兒了

研究者沒有止步于發(fā)現(xiàn)問題，他們還往深挖了一步：壓縮到底會對模型內(nèi)部產(chǎn)生什么影響？

他們跑去看了Qwen2.5-Omni-3B模型內(nèi)部的注意力分布圖（就是模型在處理信息時，"看"哪里更多、"看"哪里更少的可視化圖）。結(jié)果發(fā)現(xiàn)一個很有意思的現(xiàn)象:在沒有壓縮、全token都保留的情況下，模型的注意力幾乎全部集中在"局部時間窗口"內(nèi)部，也就是說，模型主要在看"當(dāng)前這一小段時間"里的畫面和聲音，很少去關(guān)聯(lián)更遠(yuǎn)的時間窗口，跨模態(tài)（畫面看聲音、聲音看畫面）的關(guān)聯(lián)也很弱。

但是一旦做了隨機壓縮，把每個時間窗口里的token數(shù)量減少，情況就變了：**跨窗口的注意力和跨模態(tài)的注意力都明顯增強了**。

這個發(fā)現(xiàn)很關(guān)鍵。它說明壓縮本身不是壞事，反而能激發(fā)模型去做更大范圍的信息關(guān)聯(lián)，本來窩在自己一小塊地盤里的注意力，被逼著往外看了。問題在于，如果之前用單向引導(dǎo)壓縮，把關(guān)鍵token錯誤地刪掉了，那這股被激發(fā)出來的"往外看"的注意力，就會被導(dǎo)向錯誤的、次要的信息上去,因為真正重要的線索已經(jīng)不在了。

而如果每個模態(tài)各自保留自己跟問題最相關(guān)的token，這股被壓縮激發(fā)出來的注意力，就會自然而然地落在兩邊真正重要的線索上。

這就是整篇論文最核心的設(shè)計原則：**用同一個問題作為兩個模態(tài)共享的語義錨點，但讓每個模態(tài)各自獨立判斷自己該留哪些token，不要互相指揮。**

OmniScope：讓畫面和聲音各自打分，互不干涉

基于上面的發(fā)現(xiàn)，研究團(tuán)隊提出了一個叫**OmniScope**的壓縮框架。

OmniScope：這篇論文提出的方法名，一個不需要額外訓(xùn)練的、把音頻和視頻壓縮過程"解耦"（也就是分開處理）的token壓縮框架，專門用于全模態(tài)大語言模型的推理加速

它的整體思路分三步走：先給音頻和視頻token各自打分（同一個問題，兩套獨立的打分系統(tǒng)），再根據(jù)打分結(jié)果分別壓縮視頻和音頻。

**第一步，查詢感知打分**

Query-Aware Scoring：根據(jù)用戶提出的問題（query），分別計算視頻每一幀、音頻每一秒跟這個問題的相關(guān)程度，作為后續(xù)決定"留多少、留哪些"的依據(jù)

視覺這邊，用CLIP來算每一幀畫面跟問題的余弦相似度，這個打分過程完全獨立于模型本身的視覺編碼器，算是一個外部裁判。

音頻這邊，本來想用CLAP這種專門做音頻-文字匹配的外部模型，但研究者發(fā)現(xiàn)CLAP這類模型的時間顆粒度太粗，通常是幾秒甚至更長的片段才給一個分?jǐn)?shù)，而OmniScope需要精確到每一秒甚至每個token的打分，CLAP用不上。

于是他們想了個更巧妙的辦法：直接用模型自己的音頻編碼器輸出。因為這些音頻token經(jīng)過投影層之后，本來就已經(jīng)被映射到跟文字token同一個語義空間里了，可以直接拿來跟問題文本算相似度，不需要額外引入模型。這個做法還用到了一個小技巧,詞向量的模長可以反映這個詞攜帶的信息量,越是關(guān)鍵詞（比如"足球""進(jìn)球"）模長通常越大，越是虛詞（"的""了"）模長越小。研究者用這個模長做了個"門控信號"，讓打分更聚焦在真正有信息量的詞上。

有意思的是，同樣的思路理論上也能用在視覺側(cè)，但作者在附錄里做了對比實驗，發(fā)現(xiàn)目前模型內(nèi)部的"視覺-文字對齊"精度還不夠，直接拿模型自己的視覺特征打分，效果比CLIP差了將近一個百分點（3B模型上平均掉了0.8-0.9分）。所以視覺這邊還是老老實實用外部的CLIP。

打完分之后，還有一步很關(guān)鍵的操作，叫**時間衰減傳播**。因為聲音是有連續(xù)性的，一個高分秒數(shù)附近的秒數(shù)，往往也帶著相關(guān)信息，不該被一刀切地忽略。所以研究者給鄰近高分時刻的秒數(shù)也加了個"沾光"加成，越靠近高分點加成越大，距離越遠(yuǎn)衰減越快。

**第二步，視覺端的錨點-增量交替壓縮**

打完分只是知道"哪里重要"，接下來要決定"具體留哪些token"。這里研究者提出了**AD-STC**

AD-STC（Anchor-Delta Spatio-Temporal Compression，錨點-增量時空壓縮）：一種視頻幀的壓縮策略，把視頻幀交替分成兩種角色，"錨點幀"負(fù)責(zé)保留當(dāng)前畫面的核心信息，"增量幀"負(fù)責(zé)捕捉相對上一個錨點幀發(fā)生了什么變化

具體來說，偶數(shù)位置的幀當(dāng)錨點幀，用一種叫DPC-KNN的密度聚類方法，找出畫面里那些"跟周圍最不像"的token留下來（因為跟周圍太像說明信息冗余）。

奇數(shù)位置的幀當(dāng)增量幀，負(fù)責(zé)捕捉"相對上一幀變了什么"。這里有個很聰明的自適應(yīng)設(shè)計：當(dāng)壓縮不算太狠（預(yù)算比較寬松）的時候，同時看這個token在本幀內(nèi)部是否可替代、在上一個錨點幀里是否也能找到替代品，兩個條件都滿足才判定為冗余刪掉；但當(dāng)壓縮非常狠（預(yù)算極度緊張）的時候，就簡化成只看"這個位置的畫面變化程度"，直接留下變化最大的那些token，避免預(yù)算太少的時候信息散得七零八落。

為什么要這么麻煩地區(qū)分"預(yù)算寬松"和"預(yù)算緊張"兩種模式？

這就像你打包行李。如果箱子夠大，你會既帶幾件應(yīng)急的衣服，也帶幾件應(yīng)急以外、顯得體面的衣服，追求整體的覆蓋面?？扇绻唤o你一個隨身小包，你就沒工夫講究"覆蓋面"了，你只會往里塞最必需的東西,比如證件、手機、錢包,追求的是"信息密度"而不是"廣度"。如果預(yù)算緊張的時候還硬要追求"既要空間上分散、又要時間上分散"的覆蓋策略，結(jié)果往往是每樣?xùn)|西都塞了一點點，但每樣都不夠用，信息碎片化，反而什么都說不清楚。AD-STC正是意識到了這一點，才設(shè)計了這種隨預(yù)算大小切換策略的機制。

**第三步，音頻端的按秒合并**

音頻這邊的策略跟視頻不太一樣。研究者觀察到，聲音信號有個特性叫"短時平穩(wěn)性"

短時平穩(wěn)性：指聲音信號在很短的時間片段內(nèi)變化不大，相鄰的音頻片段往往高度相似，但又不完全一樣，帶著細(xì)微的差異

正因為相鄰音頻片段很像但又不完全一樣，直接粗暴地刪掉一些token會造成時間軸上沒法彌補的信息斷層。所以研究者沒有選擇"刪"，而是選擇"合并"。

具體做法是用**二部圖軟匹配**

Bipartite Soft Matching（二部圖軟匹配）：一種token合并技術(shù)，把一組token分成兩撥（比如按奇偶位置分），計算兩撥之間兩兩的相似度，把最相似的一對對token融合成一個，從而在減少數(shù)量的同時盡量保留原始信息

在每一秒鐘的音頻片段內(nèi)獨立進(jìn)行，把token按奇偶分成兩組，算相似度矩陣，相似度最高的那些配對直接做平均融合。如果一次合并還不夠，就迭代著再來一輪。

這個思路可以理解為拼車。視頻端的AD-STC像是刪除不需要出行的車次（有些幀確實信息量太少，直接不要了），而音頻端的做法更像是把兩趟路線幾乎一樣的車合并成一趟，把兩車乘客都裝上,你沒有減少任何一個乘客(信息)，你只是把運力（token數(shù)量）優(yōu)化了。如果兩條相似的音頻片段硬生生刪掉一條，就等于把一部分乘客直接甩在了路邊，這些信息就再也找不回來了。

實際效果如何

論文在四個音視頻理解基準(zhǔn)（WorldSense、DailyOmni、OmniVideoBench、Video-MME）和兩個模型規(guī)模（Qwen2.5-Omni的7B和3B版本）上做了系統(tǒng)測試。

在45%保留率（也就是砍掉超過一半的token）的情況下，OmniScope的表現(xiàn)幾乎與完全不壓縮持平，7B模型上平均準(zhǔn)確率反而比不壓縮還高出0.3分。

真正拉開差距的是在25%保留率（只留四分之一token）這種極端壓縮場景下。這時候7B模型上，OmniScope相比不壓縮只掉了0.35分，而目前最先進(jìn)的開源方案OmniZip掉了1.55分，隨機壓縮掉了1.57分。

| 方法 | 保留比例 | WorldSense | DailyOmni | OmniVideoBench | Video-MME | 平均分 |

| Full Tokens | 100% | 46.0 | 62.0 | 34.1 | 63.3 | 51.35 |

| Random | 25% | 44.9 | 56.9 | 34.9 | 62.4 | 49.78 |

| FastV (A&V) | 25% | 44.7 | 58.4 | 35.6 | 63.4 | 50.53 |

| OmniZip | 25% | 44.8 | 57.8 | 33.7 | 62.9 | 49.80 |

| **OmniScope** | 25% | **45.7** | **58.8** | **35.8** | **63.7** | **51.00** |

（表格數(shù)據(jù)取自Qwen2.5-Omni-7B部分，加粗為對應(yīng)指標(biāo)最優(yōu)）

效率方面也很實在。7B模型在25%保留率下，預(yù)填充（prefill，也就是模型開始生成答案之前處理輸入的階段）速度提升到3.53倍，GPU顯存節(jié)省超過15%。而且OmniScope的音頻打分是直接復(fù)用模型推理過程中本來就會產(chǎn)生的中間結(jié)果，不需要額外提取完整的注意力矩陣，這一點比OmniZip更省資源。OmniZip需要提取音頻編碼器的完整注意力矩陣來判斷重要性，這個開銷會隨著音頻長度呈平方級增長，在長視頻場景下會越來越吃緊。

不過OmniScope也不是沒有代價，因為多了一次CLIP打分，端到端延遲（從輸入到生成完答案的總時間）在45%保留率下略高于FastV和OmniZip。但研究者算過一筆賬：CLIP這部分開銷是"一次性"的，隨著生成文字變長，這部分占比會被攤薄，從生成1個token時占13%左右，降到生成100個token時只占7%左右。對于像視頻字幕生成這種需要長輸出的任務(wù)，這個固定成本會被進(jìn)一步稀釋，壓縮帶來的預(yù)填充加速和顯存節(jié)省會越來越占主導(dǎo)。

消融實驗：每個設(shè)計選擇都有必要嗎

研究者還做了一系列拆解實驗，驗證每個組件是不是真的有用。

關(guān)于查詢引導(dǎo)打分，如果讓視頻和音頻都用統(tǒng)一比例壓縮（不做差異化分配），平均掉1.65分；如果只讓其中一個模態(tài)做統(tǒng)一比例壓縮，另一個模態(tài)動態(tài)分配，也會掉0.35到1.55分不等。更有意思的是，即便是讓一個模態(tài)的重要性分?jǐn)?shù)去"引導(dǎo)"另一個模態(tài)（哪怕引導(dǎo)方向和OmniZip不一樣），照樣比完全獨立打分要差，這進(jìn)一步證明了論文最核心的觀點：一個模態(tài)的重要性分?jǐn)?shù)，確實沒法可靠地代表另一個模態(tài)的重要性。

關(guān)于視覺壓縮策略，如果全部用錨點幀策略或者全部用增量幀策略，都會掉1.1到1.65分。這說明同時兼顧"空間上的核心信息"和"時間上的變化信息"確實是必要的，任何一個單獨拿出來都不夠。

關(guān)于音頻壓縮策略，直接丟棄token（隨機丟棄或者按"能量"丟棄）效果最差，能量篩選法甚至掉了2.75分，原因是音頻里的"能量大小"反映的是響度而不是語義重要性，用響度去判斷"這段聲音重不重要"本身就是個錯誤的假設(shè)。相比之下，均勻采樣和平均池化雖然保留了時間結(jié)構(gòu)，但沒有充分利用被壓縮掉的token所攜帶的信息。而OmniScope的合并策略把相似token融合而不是直接扔掉，效果最好。

這幾組消融實驗合在一起講的是同一件事：這套方法里的每一個設(shè)計都不是隨手加的裝飾，拿掉任何一塊，整體表現(xiàn)都會打折扣。

寫在后面

讀完這篇論文，讓我印象最深的不是那個3.53倍的加速數(shù)字，而是那張注意力可視化圖揭示的現(xiàn)象:壓縮本身會激發(fā)模型去做更遠(yuǎn)距離的信息關(guān)聯(lián)，這是一個副作用，但這個副作用既能被善用，也能被濫用。同樣是壓縮，用對了方法，模型會把新激發(fā)出來的注意力投向真正重要的線索；用錯了方法，同樣的機制反而會把注意力導(dǎo)向被誤留下來的次要信息。這說明"壓縮"這件事本身沒有絕對的好壞，好壞取決于你怎么決定該留下什么。

另一個讓我重新想了想的地方是78.3%這個數(shù)字。這個統(tǒng)計不是為了佐證"多模態(tài)很復(fù)雜"這種正確的廢話，它其實在暗示一件更實際的事：如果你正在設(shè)計任何一個需要同時處理多種信息源的系統(tǒng),不管是視頻加音頻，還是文本加圖表，默認(rèn)假設(shè)"一種信息的重點等于另一種信息的重點"，大概率是錯的，這個錯誤假設(shè)可能已經(jīng)悄悄寫進(jìn)了很多系統(tǒng)的設(shè)計里，只是沒人去測過這個相關(guān)系數(shù)。

論文里還有個細(xì)節(jié)值得單獨說一句：作者試過讓模型自己的視覺特征來打分（不借助外部CLIP），發(fā)現(xiàn)3B模型上效果比7B模型上更差。這暗示了一件事，模型內(nèi)部"視覺和文字對齊得好不好"這件事本身是分模型規(guī)模的，規(guī)模越小，內(nèi)部對齊可能越粗糙，這也許是以后調(diào)小模型時需要單獨關(guān)注的一個盲點。

Q&A

Q1：OmniScope是什么？

A：OmniScope是一種針對全模態(tài)大語言模型（同時處理視頻和音頻的AI模型）的訓(xùn)練無關(guān)的token壓縮方法，核心思路是讓畫面和聲音各自獨立判斷重要性，而不是讓一個模態(tài)指揮另一個模態(tài)該保留什么。

Q2：OmniScope和OmniZip有什么區(qū)別？

A：OmniZip是用音頻重要性去引導(dǎo)視頻token的保留策略，屬于單向跨模態(tài)引導(dǎo)；而OmniScope讓音頻和視頻各自獨立根據(jù)問題打分、獨立分配壓縮預(yù)算，實驗證明在高壓縮比例下OmniScope的準(zhǔn)確率下降幅度明顯更小。

Q3：為什么視頻和音頻的重要時刻經(jīng)常對不上？

A：論文分析了1197對問題-視頻樣本發(fā)現(xiàn)，78.3%的樣本中視覺重要性和音頻重要性之間只有很弱的相關(guān)性，這說明同一個問題下，畫面的關(guān)鍵時刻和聲音的關(guān)鍵時刻經(jīng)常是錯開的，比如裁判吹哨和打手勢判罰就發(fā)生在不同時間點。