OmniPack：面向高效全模态大语言模型的统一Token压缩框架 OmniPack: Unified Token Compression for Efficient Omni-modal Large Language Models
无需训练的两阶段全模态Token压缩，极致压缩下仍保持95%性能
前置知识
全模态大语言模型 (Omni-LLM)
能够在一个统一框架内同时接收并理解文本、图像、视频和音频四类输入的大模型，代表有Qwen2.5-Omni、MiniCPM-o、GPT-4o、Gemini。与纯视觉语言模型(VLM)不同，它强调跨模态(尤其是音视频)的协同推理，能处理需要声画佐证的动态真实场景。
OmniPack的所有压缩目标和评测对象都是Omni-LLM，理解它为何token密集、为何需要音视频协同，才能看懂压缩的动机。
Token压缩 / 剪枝 (Token Compression/Pruning)
在送入或经过LLM的过程中，按某种打分删减或合并冗余的多模态token，从而缩短序列、降低注意力与FFN的二次方计算量。分pre-LLM(LLM之前压缩)和inner-LLM(LLM内部逐层压缩)两种调度。关键难点是在大幅减token时不丢任务相关信息。
本文核心就是把这两类调度统一协调起来，必须先理解它们的区别与各自局限。
编码器注意力中心性 (Encoder Attention Centrality)
用模态编码器最后一层的自注意力矩阵 $A_m=\mathrm{Softmax}(Q_m(K_m)^\top/\sqrt{d})$ 统计每个token从其它同模态token收到的平均注意力，作为该token显著性的基线度量。注意力高代表该token在模态内部更被关注。
它是OmniPack重要性选择的第一性打分依据，看懂它才能理解后续如何叠加结构变化信号。
DPC-KNN 密度峰值聚类
一种聚类算法：对每个候选点用KNN估计局部密度$\rho$，再算到更高密度点的最小距离$\delta$，综合得分$\gamma=\rho\delta$高的点既代表局部邻域又与其他代表分离。OmniPack用它来做覆盖选择，挑出全局分散、互不重复的代表性token。
覆盖选择是OmniPack区别于纯重要性选择、保留全局分散证据的关键机制，必须理解DPC-KNN才能看懂。
Prefill FLOPs
指模型处理输入提示(prefill)阶段所需的浮点运算量。Transformer每层近似为 $4nd^2+2n^2d+2ndm$，其中注意力项随序列长度$n$二次增长，因此减token能直接、显著降低prefill FLOPs和首token延迟。
论文用FLOPs和prefill加速倍数衡量效率，理解这个度量才能读懂10.0×降算力、4.5×加速等核心结果。
研究动机
全模态大语言模型(Omni-LLM)虽能统一处理图像、视频、音频与文本，但视觉和音频输入被密集编码成远长于文本的token序列，给推理带来巨大的计算与显存开销。例如Qwen2.5-Omni每个时间窗口约产生288个视觉token和50个音频token，而MiniCPM-o每个窗口产生约4096个视觉token和750个音频token；在LVOmniBench这种平均时长2069.7秒的长视频上，序列长度爆炸式增长。现有压缩方法在低保留率下普遍退化：纯pre-LLM方法(如OmniZip、OmniSIFT)主要依据局部重要性或token相似度筛选，容易丢弃那些全局分散、对任务至关重要但单独看显著性不强的证据——比如稀疏分布在远处时间段的瞬时声学事件或突变视觉画面；直接丢弃低分token还会造成不可逆信息损失。而inner-LLM类方法(如SEATS、OmniDrop)虽能在LLM内部渐进剪枝，却主要依赖文本引导，没有显式建模音频与视觉token之间的协同交互。结果是激进压缩时性能急剧下降，难以兼顾速度与精度。
本文的目标是本文的目标是在无需任何训练的前提下，设计一个能在极低token预算下仍保持全模态理解能力的压缩框架。具体而言，作者希望：在Qwen2.5-Omni-7B上将FLOPs压到原来的16.7%时仍保留98.0%的原始性能；压到6.8%FLOPs时仍保留92.9%性能；在15%/7.5%保留率下实现10.0×的FLOPs降低与4.5×的prefill加速。更关键的是，方法需要跨不同模型规模(3B/7B)与不同架构(Qwen2.5-Omni、MiniCPM-o)泛化，并在音频中心、视频中心、短/长视频、从感知到推理等多种benchmark上稳定优于现有方法。作者追求的不是单一设置上的极致数字，而是一条在很宽保留率范围(10%–25%)内始终最优的性能-效率权衡曲线。
与已有工作不同的是，本文最独特的洞察是一个「分阶段专精」原则：压缩应根据多模态语义成熟的程度，在不同位置使用不同依据。pre-LLM阶段，音频与视觉表征还各自独立编码、跨模态语义尚未充分交互，此时应利用模态自身特有的时空结构去剔除冗余；而inner-LLM阶段，经过若干层Transformer后跨模态交互已成熟，此时才适合用查询条件与音视频协同来精修token。以往工作要么只在一个位置压缩，要么在跨模态语义尚未对齐时强行用一个模态指导另一个模态(导致引导基于不足对齐的特征)，要么在LLM内部剪枝时完全忽略音视频协同。OmniPack抓住了这个被忽视的「时机」问题，并进一步引入「回收而非丢弃」的设计——把被筛掉的token信息融合进保留的代表性token，避免不可逆信息损失。
核心方法
可以打个比方：OmniPack像一个「两轮筛选」的招聘流程。第一轮在送入LLM之前做「简历初筛」，只看每个模态自身的结构特征(像看候选人自身经历)，快速剔除大量结构性冗余；第二轮在LLM内部、多模态充分交流之后做「面试」，依据具体任务问题与音视频之间的相互佐证做精细筛选。技术路线上，pre-LLM压缩对视觉和音频分别执行三步：重要性选择(找最显著的token)、覆盖选择(用DPC-KNN找全局分散的代表性token)、相似度感知合并(把被淘汰token的信息加权融合进保留token，而非直接丢弃)。inner-LLM压缩在第 $\ell$ 层(7B模型默认第18层)之后执行，用文本查询相关性、音视频跨模态原型相关性、模态内代表性三者加权打分，并兼顾相关性-多样性平衡来选token，再通过相关性调制的加权平均融合被淘汰token。两阶段协同，把压缩依据从「结构线索」平滑过渡到「任务语义」，以最小信息损失实现激进压缩。
全文最核心的思想有两点。第一是「分阶段专精」：不要用同一套依据在所有位置压缩。pre-LLM阶段跨模态语义还没成熟，强用跨模态引导是「对齐不足」的；此时最该利用的是模态自身的时空结构——比如视频的帧间变化 $e^{temp}_{t,p}$、空间区分度 $e^{spat}_{t,p}$，音频的相邻token变化 $e_t$ 能捕捉声学边界与瞬时事件。inner-LLM阶段跨模态交互成熟后，才适合用查询条件与音视频协同来精修。第二是「信息回收」：绝大多数压缩方法直接丢弃低分token，造成不可逆损失；OmniPack用相似度感知合并把被淘汰token的信息加权融合进最近的保留代表token(affinity $\Phi_{ij}=\cos(x_i,x_j)-\tau_m d^{pos}_{ij}+\zeta\bar{s}_j$)，这样既减token又保信息。这两个理念结合，使OmniPack在本质上有别于「只在pre-LLM压缩且丢弃」的OmniZip/OmniSIFT，也不同于「渐进剪枝但不建模音视频协同」的SEATS。
方法步骤详情
整体流程：(1)编码：视频 $X^v$、音频 $X^a$ 经各自编码器-投影器映射到LLM嵌入空间，得 $N_v$ 个视觉token与 $N_a$ 个音频token，预算 $K_m=\mathrm{round}(r_m N_m)$。(2)重要性选择：用最后一层编码器注意力 $A_m$ 算注意力中心性 $a_m$，叠加模态特异结构信号——视频用帧间变化 $e^{temp}_{t,p}$ 与空间区分度 $e^{spat}_{t,p}$，音频用相邻token变化 $e_t$，取top-$K^{imp}_m$(占比 $\eta_m$，视觉0.25、音频0.35)。(3)覆盖选择：对剩余候选用联合距离 $d_{ij}=1-\cos(x_i,x_j)+\lambda d^{pos}_{ij}$($\lambda=0.20$)做DPC-KNN，挑出既代表局部邻域又与其他代表分离的token，补足预算。(4)相似度感知合并：未选中token按affinity $\Phi_{ij}=\cos(x_i,x_j)-\tau_m d^{pos}_{ij}+\zeta\bar{s}_j$ 分配给最近保留token，按 $w_i=(1+\bar{s}_i)/2$ 加权平均融合，输出 $X^{pre}_m$ 送入LLM。(5)inner-LLM压缩：经前 $\ell$ 层(7B为第18层)后，对隐状态用相关性 $R_i$(文本相关性+音视频协同+模态内代表性，均min-max归一化)打分，从最高分token起每次贪心选兼顾相关性 $\mathcal{N}(R_i)$ 与多样性 $D_i$ 的token直至 $K'_m$；未选中token按相关性调制相似度加权平均融合进保留token，再过剩余层。文本token全程不动。
技术新颖性
与已有技术的本质区别有三处。其一，OmniZip是「用音频指导视频丢弃」、OmniSIFT是「用视觉筛选音频」，二者都在pre-LLM阶段用一个模态指导另一个，但此时跨模态语义尚未对齐、引导基于不足成熟的特征；OmniPack坚持pre-LLM只做模态内结构压缩，把跨模态协同推迟到inner-LLM。其二，SEATS/OmniDrop虽在LLM内部渐进剪枝，但只依赖文本引导、忽略音视频token之间的协同；OmniPack的inner-LLM显式引入跨模态原型 $p_{\bar{m}}$ 来度量音视频互补性。其三，绝大多数方法直接丢弃token(不可逆损失)，OmniPack在两个阶段都用加权融合回收信息。它是首个把「结构感知pre-LLM压缩」与「查询条件音视频inner-LLM压缩」统一协调的免训练框架，并用消融(Table 7)证明两阶段策略必须配套、不可随意互换。
实验结果
在Qwen2.5-Omni-7B主表(Table 1)上，OmniPack在所有保留率下都最优：25%/12.5%时保留98.0%原始性能(均分53.5 vs 54.6)、FLOPs仅16.7%；15%/7.5%时保留95.6%性能、FLOPs降到10.0%、prefill加速4.5×；极端的10%/5%设置仍保留92.9%性能、只用6.8%FLOPs(73.2T→5.0T)，全面超过SEATS两种变体(91.2%)与VisionZip-om(89.2%)。仅pre-LLM的25%设置下，OmniPack(w/o M)以53.6均分超过SEATS†(52.9)、VisionZip-om(51.9)等全部方法。跨骨干(Table 2)同样稳健：Qwen2.5-Omni-3B在15%/7.5%下保留92.7%性能(仅9.0%FLOPs)，MiniCPM-o-2.6在同设置下反而达到100.8%性能(10.0%FLOPs)——压缩提升了表现，作者归因于剔除了冗余/噪声token。值得注意：在VideoMME长视频子集上OmniPack保留107.4%原始性能，说明对长序列去冗余尤其有益；消融(Table 4–7)证明三组件互补、音视频协同优于独立压缩、文本感知引导优于通用查询/末token引导，且pre-LLM与inner-LLM策略相互兼容、必须配套使用。超参敏感性(Table 15)很低，$\lambda$ 变化最多1.0分，所有配置都优于现有方法。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| 音视频理解(5个benchmark平均) | 相对性能% / FLOPs占比 | 15%/7.5%保留率下保留95.6%性能，仅10.0%FLOPs | SEATS⋆ 同等token预算下93.4%性能 | +2.2个百分点性能且FLOPs更低，并实现10.0×算力降低 |
| Qwen2.5-Omni-7B 极限压缩(10%保留) | 相对性能% | 92.9%(10%/5%设置) | VisionZip-om 89.2%、OmniSIFT◦ 86.4% | +3.7个百分点，仅用6.8%原始FLOPs |
| 推理效率 | prefill加速倍数 | 4.5×(15%/7.5%) | 原始模型1.0× | 首token延迟降低到约1/4.5 |
| 跨骨干泛化(MiniCPM-o-2.6) | 相对性能% | 100.8%(15%/7.5%，反而超过原始) | FastV-om 87.4%、OmniSIFT◦ 97.3% | 压缩后性能不降反升，验证去冗余对噪声token的收益 |
局限与改进
作者承认的局限包括：inner-LLM压缩层 $\ell$ 的选择是经验性的——7B与MiniCPM用第18层、3B(36层)用第26层，过早会限制任务条件下的多模态交互、过晚又削弱计算收益(Figure 3)。SEATS两种变体只在28层架构上评测，因为其深度相关的层选择调度官方只提供了28层配置。我自己观察到的局限：(1)FLOPs按近似公式 $T(4nd^2+2n^2d+2ndm)+\cdots$ 估算，未计入编码器、投影器、token选择与合并操作和LM head的开销，而选择/合并操作在长序列上也有不可忽略成本；(2)模态预算分配(视觉/音频比例)是逐模型手工设定的(Table 9)，缺乏自适应；(3)只在三个Omni-LLM上验证，未覆盖更广的开放权重生态；(4)所有指标是单次评测，未报告方差/置信区间，部分微小差距的统计显著性存疑。
独立分析的弱点
独立分析的弱点及改进方向：(1)超参虽被证明不敏感，但仍有6个关键超参($\eta_v,\eta_a,\lambda,\tau_v,\tau_a,\zeta$)与压缩层 $\ell$ 需逐模型设定，且模态预算比例靠手工分配——可引入按输入自适应的预算分配，例如用一个小策略网络或基于注意力熵动态决定视觉/音频token比例。(2)合并是单向不可逆的：一旦被淘汰token融合进保留token就无法恢复，若后续层发现误删也无补救；可考虑软掩码或保留一个小的「候补池」供后续层召回。(3)只在离线batch评测，未在流式/实时对话场景验证；Omni-LLM常用于实时助手，延迟-吞吐的实际收益需要端到端测量(论文只报prefill，未报解码阶段与整体吞吐)。(4)免训练固然是优点，但也意味着无法针对特定下游任务专门优化；可探索少量参数微调(如LoRA)让选择器学习任务偏好。每个弱点都对应明确的改进路径。
未来方向
作者提出的方向相对含蓄，主要是把方法推广到更多Omni-LLM与更长的多模态上下文。基于成果可延伸的方向：(1)自适应压缩层与预算——用学习或启发式让 $\ell$ 和模态比例随输入长度/复杂度变化；(2)流式/增量压缩，适配实时全双工对话助手(如MiniCPM-o的实时交互)，目前方法假设一次性拿到全部token，而实时场景是增量到达；(3)与训练感知压缩结合，把OmniPack作为初始化再做轻量微调，进一步逼近甚至超过原始性能(已有MiniCPM-o上100.8%、长视频107.4%的迹象支撑)；(4)扩展到3D、生成或更多模态(如深度图、热成像)；(5)研究压缩对安全/幻觉的影响——去掉「噪声」token是否也会去掉约束性证据，这是落地前必须回答的问题。
复现评估
复现性总体较好。代码已开源(github.com/RowanSu/OmniPack)，方法完全免训练，只需挂在现成Omni-LLM推理流程上。评测统一用公开的LMMs-Eval框架，benchmark(AVUT/WorldSense/DailyOmni/VideoMME/LVOmniBench)全部公开。所有超参、模态预算分配表(Table 9)、各baseline的复现细节(如FastV的K=2、VisionZip的上下文比例0、FastVID的c=8/τ=0.84、OmniZip的g=3)都在附录给出。算力方面需NVIDIA H20 GPU，7B原始73.2T FLOPs、压缩后显著降低，单卡即可跑。难点在于：各baseline实现风格不一需仔细对齐，SEATS两种变体的层调度需手工适配28层架构；最大帧数(短benchmark 128帧、长benchmark 768帧)与每帧像素预算128×28×28需严格一致才能复现数字。整体复现难度中等偏低，适合工程团队直接借鉴落地。
论文图表
