你有没有想过这样一个场景：让你一边看一部两小时的电影，一边全神贯注地听里面的每一句对白和每一个背景音，然后立刻回答关于剧情的问题。人脑其实做不到把每一帧画面和每一段声音都记得清清楚楚，我们会自动筛选，抓住重点，忽略掉大部分重复的、不重要的信息。
现在的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等现有方法。
热门跟贴