你有沒有想過這樣一個場景：讓你一邊看一部兩小時的電影，一邊全神貫注地聽裡面的每一句對白和每一個背景音，然後立刻回答關於劇情的問題。人腦其實做不到把每一幀畫面和每一段聲音都記得清清楚楚，我們會自動篩選，抓住重點，忽略掉大部分重複的、不重要的資訊。
現在的AI也面臨一模一樣的困境，只不過它的"記憶"是以"token"（詞元，可以理解為AI處理資訊的最小單位，一段文字、一幀畫面、一段聲音都會被切成很多個token）的形式存在的。
問題是，影片和音頻產生的token數量,實在是太嚇人了。
一段幾分鐘的影片，可能被切成幾千甚至上萬個視覺token，再加上同步的音頻token，全部塞進大語言模型（LLM，也就是能理解和生成語言的AI核心引擎）里處理，計算量會呈指數級增長。這就是為什麼"全模態大語言模型
"（Omni-LLM，也就是能同時理解文字、圖像、影片、音頻的AI模型，比如Qwen2.5-Omni、GPT-4o這些）雖然能力很強，但一旦要處理長影片，就會變得又慢又貴，很難真正落地部署。
於是研究者們開始琢磨一件事：能不能在不損失理解能力的前提下，把這些冗餘的token"壓縮"掉，讓AI跑得更快？這就是這篇論文要解決的核心問題。
一、當前的壓縮方法，到底卡在哪兒了
在這篇論文出現之前，已經有不少團隊嘗試過給Omni-LLM"瘦身"。
比如OmniZip這個方法，思路是用音頻資訊來指導影片token的壓縮，哪裡有重要的聲音事件，就多保留哪裡的畫面。還有OmniSIFT，做法是先對影片做時空壓縮，再用視覺資訊反過來篩選音頻token。這些方法有一個共同點：它們都是在進入大語言模型之前，也就是"預處理階段"，就把該扔的token扔掉了。
這樣做的問題在哪兒？
論文指出了兩個致命短板。
第一個短板是，現有方法沒有充分建模音影片的"長程時空結構"。什麼意思呢？一部電影裡，關鍵的情節線索可能散落在相隔很遠的幾個時間點，一次突然的畫面切換，一聲轉瞬即逝的槍響，這些資訊在時間軸上是稀疏分布的。如果壓縮算法只看"局部重要性"或者"token之間像不像"，很容易把這些散落在遠處的關鍵證據漏掉，尤其是在長影片裡。而且，直接把評分低的token一扔了之，會造成不可逆的資訊損失，因為有些單獨看起來不起眼的token，湊在一起其實提供了重要的補充資訊。
如果這裡不做好會怎樣？想像你在看一部懸疑片，兇手在第10分鐘露了個臉，之後再沒出現過，直到第90分鐘真相揭曉。如果壓縮算法只盯著"當前畫面重不重要"來評分，第10分鐘那個一閃而過的鏡頭很可能被判定為"不夠顯著"而被刪掉，等到第90分鐘需要回憶兇手長相時，AI手裡已經沒有這條線索了。這不是危言聳聽，這正是論文反覆強調的"全局分布證據"缺失問題。
第二個短板更微妙，是關於音頻和視覺資訊"什麼時候該互相幫忙"的問題。
現有方法比如OmniZip和OmniSIFT，是在進入大語言模型之前就讓一個模態去指導另一個模態的壓縮。可這時候的音頻編碼和影片編碼，都還是各自獨立處理出來的原始特徵，彼此之間幾乎沒有發生過深層的語義互動。用一個還沒"想明白"的信號去指導另一個信號的取捨，可靠性自然要打折扣。雖然後來有OmniDrop和SEATS這樣的方法，嘗試在大語言模型內部也做逐層壓縮，但它們的做法主要依賴文本查詢來指導壓縮，沒有顯式建模音頻和視覺之間的協作關係。
這就好比一個團隊做項目，如果兩個部門（音頻組和視覺組）還沒開過一次碰頭會，就讓其中一個部門單方面決定另一個部門該保留哪些材料，這個決策大概率是不可靠的。真正可靠的做法應該是，先讓兩個部門各自把明顯沒用的材料清理掉（這一步不需要開會，憑經驗就能做），等到大家真正坐下來對齊資訊、理解了任務目標之後，再一起決定哪些材料是真正關鍵的，哪些可以進一步精簡。
這個洞察，正是這篇論文提出解決方案的出發點。
二、OmniPack：先分頭打掃，再聯合精修
論文提出的方法叫OmniPack，是一個訓練無關（training-free，意思是不需要額外訓練模型參數，直接可以拿來用）的兩階段壓縮框架。
它的核心思路可以用一句話概括：在進入大語言模型之前，先按各自模態的特點做結構性壓縮；進入模型、經過充分的音影片互動之後，再根據任務需求做語義級的精細壓縮。
這個設計呼應了前面提到的那個團隊協作的比喻。第一階段就是"各部門先各自清理冗餘材料"，第二階段則是"碰頭會之後，根據討論出的重點再精簡一輪"。如果跳過第一階段直接進行第二階段的重度壓縮，計算量會因為token數量太大而扛不住；如果只做第一階段不做第二階段，又沒法利用後續產生的任務相關語義資訊。兩階段結合，才能既省計算量，又不丟關鍵資訊。
### 階段一：進入大模型之前，怎麼給影片和音頻瘦身
這一階段，OmniPack對視覺和音頻分別獨立處理，因為此時跨模態的語義還沒有充分融合，談"協作"還為時過早。這一步分為三個動作：重要性篩選、覆蓋度篩選、相似度感知的token合併。
重要性篩選，顧名思義，是先找出那些"存在感"很強的token。
論文的做法是結合兩類資訊：一類是編碼器自帶的注意力（attention）統計，通俗講就是模型在處理這段影片或音頻時，哪些token被其他token"關注"得最多，這本身就是一種重要性信號；另一類是"結構變化"信號。
對影片而言，論文定義了兩種變化線索：相鄰幀變化（一幀畫面和下一幀畫面差別有多大）和空間獨特性（一個畫面塊和整幀畫面的平均特徵差別有多大）。對音頻而言，則是相鄰時刻的聲音變化，變化越大，越可能是一個聲音事件的邊界，比如突然的關門聲、一聲驚呼。
這兩類信號疊加起來，就得到了每個token的"重要性分數"。
引用塊：注意力（Attention）：Transformer模型里衡量"一個token對另一個token的關注程度"的機制，注意力越高通常代表資訊越核心。
DPC-KNN：一種結合"密度峰值聚類"和"K近鄰"思想的算法，用來從一堆點裡找出既能代表局部區域、又和其他代表點保持距離的"典型樣本"。
但是，光靠重要性篩選是不夠的，因為它容易"扎堆"，把票都投給幾個特別顯眼的片段，而忽略掉那些雖然不那麼"搶眼"、但分布在別處的內容。這就是覆蓋度篩選要解決的問題。
覆蓋度篩選的思路是同時看"特徵相似度"和"位置距離"，把這兩者結合成一個聯合距離，然後用前面提到的DPC-KNN算法，挑出那些既能代表局部區域、又和其他代表性區域保持距離的token，確保壓縮後的結果不會只集中在某幾個熱點上，而是能覆蓋整段影片或音頻的不同區域。
這就好比你去逛一個很大的展覽館，如果只按"哪個展品前面圍的人最多"來決定要看哪些展品，你很可能錯過那些冷門但同樣精彩的角落。合理的做法應該是既看人氣排名，也刻意去幾個不同的區域走走，保證自己不會只看到展館的一個側面。覆蓋度篩選做的就是這件"刻意走幾個不同區域"的事。
有了重要性篩選和覆蓋度篩選選出來的token，剩下沒被選中的token怎麼辦？直接扔掉太可惜。這就是第三步，相似度感知的token合併要做的事。
論文的做法是，對每個沒被選中的token，去找一個和它最相似（同時考慮特徵相似度、位置接近程度、以及目標token本身的重要性）的"代表token"，把它的資訊融合進這個代表token里，而不是簡單丟棄。融合時會根據重要性給不同的未選中token分配不同的權重，重要的多貢獻一點，不重要的少貢獻一點。
這一步的邏輯其實很接近搬家時候的"打包合併"。你搬家的時候，不會把每件小東西單獨裝一個箱子，而是把相似的、能放在一起的小物件塞進一個大件旁邊的空隙里，這樣既沒有真的丟掉任何東西，又大大減少了要搬的箱子數量。如果不做這步合併，直接把沒選中的token扔了，就相當於搬家時候把很多雖然不起眼但確實有用的小東西直接扔進垃圾桶，等到了新家才發現少了充電器、少了螺絲刀，追悔莫及。
### 階段二：進入大模型之後，怎麼結合文本需求做二次精修
經過第一階段的壓縮，影片和音頻token連同文本token（也就是用戶問的問題）一起被送進大語言模型，經過前面若干層Transformer模組（Transformer是當前主流大語言模型的基礎架構單元）的處理之後，視覺和音頻的表示已經和文本進行了充分的語義互動。
這時候，OmniPack啟動第二階段的壓縮，論文稱之為"查詢條件化的模型內壓縮"（Query-Conditioned Inner-LLM Compression）。
引用塊：Transformer塊：大語言模型的基本處理單元，每一層Transformer都會讓輸入的各種token之間互相"交流資訊"，層數越深，資訊融合得越充分。
這一階段的核心是給每個token算一個"相關性分數"，這個分數由三部分組成：文本相關性（這個token和用戶提出的問題有多相關）、音影片協作程度（這個token和另一個模態的整體資訊有多契合）、模態內代表性（這個token在自己所在的模態里，是不是足夠獨特，不和別人重複）。
這三部分分數綜合起來之後，OmniPack不是簡單地"分數高的留下，分數低的刪掉"，而是採用了一種兼顧"相關性"和"多樣性"的貪心選擇策略：先選出分數最高的token作為起點，然後每一步都挑選那個"和已選集合差異最大、同時自身相關性也不錯"的token加入，直到湊夠目標數量為止。
這個設計的巧妙之處在於，它避免了選出來的token全都長得差不多的情況。如果只按相關性分數排序取前幾名，很可能選出來的token高度雷同，因為它們都在描述同一個熱門話題的不同角度。而兼顧多樣性的貪心選擇，能保證留下來的這一小撮token，儘可能覆蓋到不同類型的資訊。
這就像你去開一個只能帶五個人的項目討論會，如果你只按"誰最懂這個項目"來選人，很可能選出來的五個人觀點高度一致，討論不出什麼新東西。真正有效的做法是既要有懂行的人，也要照顧到不同角色和不同視角的人，這樣討論才能覆蓋更全面。
值得說明的是，OmniPack不是隨便找個層就開始做這個二次壓縮的。論文做了實驗，發現壓縮的時機太早，模型還沒來得及做充分的音影片語義互動，壓縮效果不好；壓縮得太晚，雖然效果好，但省下來的計算量就少了。實驗結果顯示，在Qwen2.5-Omni-7B這個28層的模型里，第18層是最佳選擇點，兼顧了效果和效率。
三、實測效果：省了九成計算量，效果幾乎不掉
說了這麼多設計思路，最終還是要看數字說話。
論文在五個基準測試集（AVUT、WorldSense、DailyOmni、VideoMME、LVOmniBench，分別覆蓋了音頻為主/影片為主、短影片/長影片、感知型/推理型等各種任務場景）上，對三個不同的Omni-LLM骨幹模型（Qwen2.5-Omni-3B、Qwen2.5-Omni-7B、MiniCPM-o-2.6）做了系統測試。
引用塊：FLOPs：浮點運算次數（Floating Point Operations），衡量一個模型做一次推理需要多少計算量的指標，數值越低說明模型跑起來越省資源。
基準測試集（Benchmark）：專門用來評估AI模型能力的標準化測試集合，就像考試題庫一樣，方便不同方法之間做公平比較。
最亮眼的結果出現在Qwen2.5-Omni-7B上。在保留25%預處理階段token、12.5%模型內token的設置下，OmniPack保留了原始模型98.0%的性能，但計算量（FLOPs）只用了原來的16.7%。
更狠的是極限壓縮場景。
當把保留比例進一步壓到15%預處理、7.5%模型內的時候，OmniPack依然能保住95.6%的原始性能，計算量卻只有原來的10.0%，相當於計算量減少了10倍，推理階段（prefill，也就是模型讀入所有輸入內容進行初步處理的階段）的速度提升了4.5倍。
即便壓到10%預處理、5%模型內這種近乎"苛刻"的水平，OmniPack仍然保留了92.9%的性能，只用了6.8%的原始計算量。
論文裡有張表格特別能說明問題，下面把關鍵數字摘出來對比一下（數值代表在Qwen2.5-Omni-7B上五個基準的平均得分，滿分是原始未壓縮模型的54.6分）：
原始模型（不壓縮）：54.6分，計算量73.2T，相對性能100%
保留25%預處理+12.5%模型內的OmniPack：**53.5分，計算量12.2T，相對性能98.0%**
保留15%預處理+7.5%模型內的OmniPack：**52.2分，計算量7.3T，相對性能95.6%**
保留10%預處理+5%模型內的OmniPack：**50.7分，計算量5.0T，相對性能92.9%**
作為對比，同樣在15%保留比例下，另一個強力競品SEATS的兩個變體分別只能保住93.4%的性能，而OmniPack能做到95.2%（不加模型內壓縮的版本）到95.6%（完整版）。VisionZip-om在這個檔位只能保住91.4%，OmniSIFT只能保住89.7%。差距雖然看起來是幾個百分點，但換算到實際使用場景里，意味著每問10個關於影片內容的問題，用OmniPack壓縮的模型能比同檔位的競品多答對1到2個。
在跨模型規模的驗證上，結果同樣穩。Qwen2.5-Omni-3B在15%/7.5%這個設置下保住了92.7%的性能，只用9.0%的計算量。而在MiniCPM-o-2.6上更是出現了性能"不降反升"的有趣現象，壓縮後的模型達到了100.8%的相對性能，也就是說壓縮之後的效果比不壓縮還要好一點點。這背後的原因，論文推測是壓縮掉了一些干擾性的冗餘token之後，反而讓模型更專注於真正有用的資訊，減少了"噪音"的干擾。
四、拆開看，每個部件都有用嗎
任何一個多模組拼起來的方法，都會被問一個問題：這幾個模組是不是都真的有用，還是有些純屬湊數？
論文做了詳細的消融實驗（ablation study，也就是把方法拆開，一塊一塊地去掉，看看少了哪塊效果掉得最多）來回答這個問題。
先看預處理階段的三個組件：重要性篩選、覆蓋度篩選、相似度合併。單獨使用覆蓋度篩選，在WorldSense和LVOmniBench上的表現是三者里最好的，分別達到43.1和34.7分。但把三個組件全部疊加起來使用，效果進一步提升到44.6和34.9分，比單獨用覆蓋度篩選還要高出3%到4.8%左右。這說明三個組件各自捕捉了不同維度的資訊，重要性篩選抓熱點，覆蓋度篩選保廣度，相似度合併防丟失，三者疊加確實產生了"1+1+1大於3"的效果。
再看模型內壓縮階段的關鍵設計，也就是"音影片協作"這個機制到底有沒有用。論文對比了"有音影片協作"和"沒有音影片協作"（也就是讓音頻和視覺各自獨立決定該保留哪些token，互不參考）兩種設置，結果顯示，有協作機制的版本在AVUT、WorldSense、DailyOmni三個測試集上都穩定地略優於沒有協作的版本。差距雖然不算巨大（比如AVUT上58.1對57.8），但方向是一致的，說明讓兩個模態"互相看一眼對方在關注什麼"，確實能幫助雙方做出更明智的取捨判斷。
還有一個有意思的對比，是關於"用什麼方式讓文本來指導壓縮"。論文比較了三種做法：一種是用一個籠統的、和具體問題無關的通用查詢；一種是只看最後一個文本token的注意力；第三種是OmniPack自己採用的"文本感知引導"，會綜合利用整個文本查詢里的語義資訊。結果顯示，文本感知引導的效果最好，雖然領先幅度不算懸殊，但趨勢很清晰。這說明，越是充分地利用用戶提問里蘊含的語義資訊，壓縮就越能"對症下藥"，保留下真正和問題相關的內容。
論文還專門測試了不同壓縮策略之間能不能"混搭"。比如把OmniPack的預處理階段換成別的方法（VisionZip-om、OmniSIFT、SEATS），模型內壓縮仍然用OmniPack自己的方案，結果性能都出現了明顯下滑。反過來，如果預處理階段用OmniPack自己的，模型內壓縮換成SEATS的方案，性能同樣有所降低。這個結果說明，OmniPack的兩個階段是專門為彼此設計、互相配合的，硬拆開各自和別的方法搭配，效果會打折扣。這也印證了論文最初的設計理念：預處理階段該做的事和模型內階段該做的事，本質上是不同性質的任務，不能用同一套邏輯簡單套用到兩個階段上。
五、一個具體的例子，看看壓縮出了岔子會怎樣
論文裡給了一個挺直觀的案例對比。
有一段影片裡出現了這樣一個問題："影片中'這是什麼？'這句話最可能是針對什麼場景說的？"選項包括關門聲、iPad打開後播放的歌曲、突然驚醒的人、iPad上兩個年輕人的照片。
在同樣25%的預處理保留比例下，SEATS方法漏掉了關鍵的影片幀資訊，最終選擇了錯誤答案B（認為是對歌曲的反應）。而OmniPack因為更好地保留了關鍵token、減少了冗餘，正確選出了答案D（關於iPad上兩個年輕人照片的提問）。
這個例子雖然只是一個案例，但很能說明問題：壓縮不是簡單地"刪掉不重要的東西"，一旦刪錯了關鍵資訊，模型的回答方向就會整個跑偏。OmniPack之所以能在這類場景下表現更穩，本質上還是回到了它最初的設計哲學，預處理階段儘量保住結構性的關鍵證據，模型內階段再結合具體問題做二次篩選，兩道關卡疊加，出錯的概率自然更低。
六、這個方法目前走到了哪一步，後面可能會怎麼走
論文裡提到，這類研究方向目前還處在相對早期的階段。此前的工作，比如OmniZip在2026年的CVPR上提出了音頻引導的動態token壓縮，OmniSIFT在2026年的ICML上探索了模態非對稱的壓縮策略，而SEATS則嘗試了預處理和模型內壓縮相結合的漸進式方案。OmniPack可以看作是在這條技術路線上，把"哪個階段該做什麼事"這個問題想得更清楚了一步，明確提出預處理階段該靠結構資訊，模型內階段該靠任務語義，並且用具體的實驗證明了這個分工是有效的。
從更長遠的角度看，音影片token壓縮這個方向未來大概率還會繼續往"更細粒度的跨模態協作"上演進。目前OmniPack雖然在模型內階段考慮了音影片的相互關係，但這種關係目前還是通過"原型向量"和"餘弦相似度"這種相對簡化的方式來建模的，如果未來能有更精細的跨模態對齊機制，說不定還能在同樣的壓縮比例下擠出更多性能空間。
寫在後面
讀這篇論文的時候，最觸動我的其實不是最終的性能數字，而是它對"該在哪個階段做什麼事"這個問題的拆解方式。很多壓縮方法容易陷入一個思維定式，覺得壓縮就是壓縮，用一套統一的評分邏輯貫穿始終就夠了。但OmniPack的實驗結果其實在說一件更細緻的事：資訊的"重要性"本身是分層次的，淺層的重要性是結構性的，比如畫面變化劇烈不劇烈、聲音有沒有突變；深層的重要性是語義性的，跟具體問的是什麼問題有關。這兩種重要性發生的時機不一樣，判斷標準也不一樣，如果強行用一套邏輯去處理兩個不同性質的任務，效果自然會打折扣。
另一個讓我意外的細節是，壓縮之後模型性能在MiniCPM-o-2.6上反而超過了100%。這其實提示了一件事，多模態輸入里的冗餘資訊不只是"占地方"，它可能還會真的干擾模型的判斷，去掉之後模型反而更聚焦了。這和很多人直覺里"資訊越多越好"的想法是有出入的。
這篇論文沒有回答的一個問題是，如果壓縮比例繼續往下探，比如降到3%甚至1%，這套"結構優先、語義精修"的兩階段策略還能不能撐住。畢竟目前測試的最低點是10%預處理、5%模型內，再往下會不會出現性能的斷崖式下跌，這是個挺值得繼續追問的問題。
Q&A
Q1：OmniPack是什麼？
A：OmniPack是一個訓練無關的多模態大語言模型token壓縮框架，專門針對全模態大語言模型（Omni-LLM）處理音頻和影片時產生的海量token進行壓縮，通過預處理階段的結構性壓縮和模型內階段的語義精修兩步走，在大幅降低計算量的同時儘量保住原始理解能力。
Q2：OmniPack能省多少計算量，性能損失大不大？
A：在Qwen2.5-Omni-7B模型上，OmniPack在保留15%預處理token、7.5%模型內token的設置下，能把計算量降到原來的10%（相當於減少10倍），同時保留95.6%的原始性能；即使壓縮到10%預處理、5%模型內這種極限檔位，也能保留92.9%的性能，只用6.8%的計算量。
Q3：OmniPack和之前的OmniZip、SEATS這些方法比，優勢在哪？
A：OmniPack的核心優勢在於把壓縮拆成兩個專門的階段，進入大模型前用結構資訊（重要性、覆蓋度、相似度合併）做粗篩，進入模型充分互動後再結合用戶問題和音影片協作關係做精細篩選，在同等壓縮比例下，五個基準測試的平均得分都優於VisionZip-om、OmniSIFT、SEATS等現有方法。
