你有没有想过这样一个场景让你一边看一部两小时的电影一边全神贯注地听里面的每一句对白和每一个背景音然后立刻回答关于剧情的问题。人脑其实做不到把每一帧画面和每一段声音都记得清清楚楚我们会自动筛选抓住重点忽略掉大部分重复的、不重要的信息。现在的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的重要性分数。引用块注意力AttentionTransformer模型里衡量一个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%左右。这说明三个组件各自捕捉了不同维度的信息重要性筛选抓热点覆盖度筛选保广度相似度合并防丢失三者叠加确实产生了111大于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%模型内再往下会不会出现性能的断崖式下跌这是个挺值得继续追问的问题。QAQ1OmniPack是什么AOmniPack是一个训练无关的多模态大语言模型token压缩框架专门针对全模态大语言模型Omni-LLM处理音频和视频时产生的海量token进行压缩通过预处理阶段的结构性压缩和模型内阶段的语义精修两步走在大幅降低计算量的同时尽量保住原始理解能力。Q2OmniPack能省多少计算量性能损失大不大A在Qwen2.5-Omni-7B模型上OmniPack在保留15%预处理token、7.5%模型内token的设置下能把计算量降到原来的10%相当于减少10倍同时保留95.6%的原始性能即使压缩到10%预处理、5%模型内这种极限档位也能保留92.9%的性能只用6.8%的计算量。Q3OmniPack和之前的OmniZip、SEATS这些方法比优势在哪AOmniPack的核心优势在于把压缩拆成两个专门的阶段进入大模型前用结构信息重要性、覆盖度、相似度合并做粗筛进入模型充分互动后再结合用户问题和音视频协作关系做精细筛选在同等压缩比例下五个基准测试的平均得分都优于VisionZip-om、OmniSIFT、SEATS等现有方法。 
长河君 · 2026/8/20 8:09:58 · 阅读 1.2k 当AI又要看视频又要听声音时，怎么才能不把自己累死
你有没有想过这样一个场景让你一边看一部两小时的电影一边全神贯注地听里面的每一句对白和每一个背景音然后立刻回答关于剧情的问题。人脑其实做不到把每一帧画面和每一段声音都记得清清楚楚我们会自动筛选抓住重点忽略掉大部分重复的、不重要的信息。现在的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的重要性分数。引用块注意力AttentionTransformer模型里衡量一个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%左右。这说明三个组件各自捕捉了不同维度的信息重要性筛选抓热点覆盖度筛选保广度相似度合并防丢失三者叠加确实产生了111大于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%模型内再往下会不会出现性能的断崖式下跌这是个挺值得继续追问的问题。QAQ1OmniPack是什么AOmniPack是一个训练无关的多模态大语言模型token压缩框架专门针对全模态大语言模型Omni-LLM处理音频和视频时产生的海量token进行压缩通过预处理阶段的结构性压缩和模型内阶段的语义精修两步走在大幅降低计算量的同时尽量保住原始理解能力。Q2OmniPack能省多少计算量性能损失大不大A在Qwen2.5-Omni-7B模型上OmniPack在保留15%预处理token、7.5%模型内token的设置下能把计算量降到原来的10%相当于减少10倍同时保留95.6%的原始性能即使压缩到10%预处理、5%模型内这种极限档位也能保留92.9%的性能只用6.8%的计算量。Q3OmniPack和之前的OmniZip、SEATS这些方法比优势在哪AOmniPack的核心优势在于把压缩拆成两个专门的阶段进入大模型前用结构信息重要性、覆盖度、相似度合并做粗筛进入模型充分互动后再结合用户问题和音视频协作关系做精细筛选在同等压缩比例下五个基准测试的平均得分都优于VisionZip-om、OmniSIFT、SEATS等现有方法。