你让 AI 看一段很长的视频，再问它某句话响起时画面里有什么。对模型来说，这不只是“看一遍”那么简单：画面片段和声音片段会被拆成大量 Token——也就是模型能够处理的小单位，像一摞按时间排列的索引卡。音频和视频越长，卡片越多，计算与内存负担也越重。
OmniPack 想做的，就是在不重新训练模型的前提下，替这摞卡片瘦身。它不只挑出少数“重要卡片”，而是分两次整理：进入大语言模型前，先按音频和视频各自的结构去掉大块冗余；进入模型、不同信息充分交流后，再根据用户的问题做一次语义精简。
本文的技术设计与实验数字均来自 Yang Shi 等人的论文，尚无独立复现。作者所称“优于现有方法”，应理解为在其选取的模型、基准、压缩预算和对比方法中领先。
为什么不能只留下“最显眼”的部分？
Token 压缩通常面临一个直观取舍：Token 预算——允许保留下来的单位数量上限——越低，计算越省，但也越容易删错。
长视频尤其麻烦。回答问题需要的证据可能很分散：开头闪过一个物件，中间响起短促的声音，结尾才出现与它对应的动作。如果压缩方法只关注局部最醒目的片段，保留下来的卡片可能都挤在同一场戏里，远处的线索则被清空。若只按相似度删除，也可能把看起来不突出、实际上用于补足上下文的信息一并丢掉。
另一条路线是在模型内部，根据问题逐步裁掉无关 Token。但论文认为，已有方法主要依赖文字提问来筛选，没有充分利用声音与画面的互相印证。比如一声关门声是否重要，往往要结合画面里谁刚刚离开才能判断。
先整理素材，再围绕问题精简
OmniPack 是一个 training-free 框架，也就是不需要为压缩过程额外训练模型。它把工作分成两个阶段。
第一阶段发生在大语言模型之前。此时声音和画面还没有充分“对上话”，所以 OmniPack 不急着让一种模态指导另一种，而是分别处理。
它先做重要性选择。视频 Token 除了参考编码器的注意力，还会考虑相邻画面的变化和空间上的独特之处；音频 Token 则关注相邻时刻的变化，以捕捉声音边界或短暂事件。但它只把部分预算交给重要性排序，因为单纯选高分项容易扎堆。
剩下的预算用于全局覆盖。OmniPack 同时考虑内容特征和位置距离，从不同时间、不同空间区域挑选代表。说白了，它不只保存“最精彩的几张”，还要确保整段素材都有目录可查。
更关键的是，未入选的 Token 不会直接消失。系统会把它们按相似性、位置和代表 Token 的重要程度，合并到最合适的保留项中。这像把多张内容接近的索引卡归入一个条目，同时把卡片上的补充信息带过去。论文的消融实验——逐项移除组件、观察性能变化的测试——显示，重要性、覆盖和合并三者一起使用时，在所测的三个基准上取得了该组设置中的最好结果。
第二阶段发生在模型内部。经过若干 Transformer 模块后，文字、声音和画面已经有了较充分的交互，OmniPack 才按任务做进一步压缩。它综合三类信息：某个 Token 与完整问题有多相关，音频与视频能否互相提供证据，以及它在自身模态中是否具有代表性。选择时还会兼顾多样性，避免留下许多意义相近的 Token。
作者发现，这一步放得太早，跨模态信息还没有成熟；放得太晚，又省不了多少计算。在 Qwen2.5-Omni-7B 和 MiniCPM-o-2.6 上，默认放在第 18 层；Qwen2.5-Omni-3B 则放在第 26 层。所有文字 Token 在两轮压缩中都保持不变。
省下来的计算有多少？
作者在 AVUT、WorldSense、DailyOmni、VideoMME 和 LVOmniBench 五个音视频理解基准上测试了 OmniPack，覆盖短视频、长视频以及从感知到推理的任务。骨干模型包括 Qwen2.5-Omni-7B、Qwen2.5-Omni-3B 和 MiniCPM-o-2.6。
在 Qwen2.5-Omni-7B 上，未压缩模型的五项平均分是 54.6。OmniPack 先保留 25% 的音视频 Token，再在模型内部压到 12.5%，平均分为 53.5，即保留原始平均性能的 98.0%；论文口径下，FLOPs 降至原模型的 16.7%。FLOPs 是浮点运算量，用来估算模型完成计算需要做多少算术工作。
压缩进一步加重时，系统先保留 10%，再压到 5%，平均分仍有 50.7，相当于原始平均性能的 92.9%，而 FLOPs 只剩 6.8%。这些百分比是五个基准平均分的相对比例，不代表每项任务都保留了同样多的能力。
另一个较平衡的设置是先保留 15%、最终留下 7.5%。它保留了 95.6% 的原始平均性能，将 FLOPs 降到 10.0%，并让 prefill 加速 4.5 倍。Prefill 是模型先把整段输入读入并建立内部表示的阶段；长音视频 Token 主要在这里形成负担。
结果也不只出现在 7B 模型上。同样采用 15%/7.5% 设置时，Qwen2.5-Omni-3B 以原始 9.0% 的 FLOPs 保留了 92.7% 的平均性能；MiniCPM-o-2.6 以 10.0% 的 FLOPs 得到原始平均性能的 100.8%。后者略高于未压缩模型，但只能视为这组评测中的结果，不能推出压缩普遍会提升能力。
为什么值得关注
OmniPack 最值得看的，不是某一个筛选公式，而是它对“何时该看什么信息”的划分。进入模型前，音频和视频各自的时间、空间结构更可靠，所以先保覆盖、再合并冗余；进入模型后，问题含义以及声画关系更清楚，才根据任务继续精炼。
这种分工也解释了它为何适合低 Token 预算。压缩不是一次性扔掉大部分素材，而是先做不依赖问题的结构整理，再做依赖问题的语义整理。若这一思路能被更多模型和真实部署验证，它可能直接减少全模态模型处理长音视频时的计算账单。
局限与未知
- 所有效果均来自作者论文，尚无第三方评测或独立复现；“最佳性能—效率权衡”只适用于论文覆盖的比较范围。
- FLOPs 下降不等于端到端成本按同一比例下降。论文报告了特定设置下的 prefill 加速，但没有据此证明延迟、显存占用和部署费用都会同步缩减。
- 实验集中在五个理解基准和三个骨干模型。对于材料之外的模型、任务以及更复杂的真实音视频输入，效果仍未知。