OmniScope: Modality-Decoupled Token Compression for Omnimodal Large Language Models
Jinsen Su, Yongdong Luo, Yuexiao Ma, Yibo Hu, Meiguang Jin, Xiaowu Zheng
cs.CV
2026-07-25
OmniScope 让全模态大模型的音视频各自按 query 独立压缩,在 Qwen2.5-Omni 上保留 25% token 时 prefill 加速 3.53 倍、显存降 15%,平均精度仅掉 0.35 分。
全模态大语言模型(OmniLLM,如 Qwen2.5-Omni、GPT-4o)同时吃视频帧和音频,token 数随视频时长线性涨。一段几分钟的视频喂进去,光音视觉 token 就能挤爆显存,prefill 阶段尤其慢,实时和边缘部署基本没戏。
直接的办法是 token 压缩,砍掉冗余 token。难点在砍哪些。已有的全模态压缩方法(OmniZip、OmniSIFT)都走「单向跨模态指导」:用一个模态的重要性分数决定另一模态留什么,比如让音频告诉你视频里哪些帧关键。论文指出这个假设经常崩。同一个问题下,音频的关键时刻和视觉的关键时刻往往不在一处。他们量化了这件事:1197 个「问题-视频」对里,约 78.3% 的音视觉重要性只是弱相关。哨声在音频里早早就响,裁判的手势在画面里晚半拍才出现。问「哨响后裁判做了什么手势」,用音频去筛视频,就会把那个手势丢掉。
论文先给了一个反直觉的观察。满 token 时,Qwen2.5-Omni 的注意力几乎全锁在局部时间窗里,跨窗和跨模态的注意力极弱。一旦压缩掉冗余 token,跨窗和跨模态注意力反而明显增强。压缩不是单纯地丢信息,它把原本被冗余 token 稀释的注意力预算释放了出来,引向别处。问题就变成:被释放的注意力,会落到任务相关的线索上,还是被引向次要内容。
OmniScope 的设计原则一句话:query 跨模态共享,salience 估计不共享。每个模态各自按问题算自己的重要性,各自分配自己的压缩预算。整个框架免训练,挂在 Qwen2.5-Omni 的 7B 和 3B 上。
三步走。
四个音视频 benchmark:WorldSense、DailyOmni、OmniVideoBench、Video-MME,对照 Random、FastV(A&V)和 OmniZip(当前最强的开源免训练全模态压缩方法)。OmniSIFT 没比,因为它要额外训练且没开源。
| 设置(Qwen2.5-Omni-7B) | Full Tokens | OmniScope | OmniZip | FastV |
| 45% 保留,平均分 | 51.35 | 51.65(+0.30) | 51.15(−0.20) | 51.13(−0.22) |
| 25% 保留,平均分 | 51.35 | 51.00(−0.35) | 49.80(−1.55) | 50.53(−0.82) |
45% 保留时,7B 模型不降反升 0.30 分;压到 25%,OmniScope 只掉 0.35,OmniZip 掉 1.55。3B 模型趋势一致。所有压缩档下 OmniScope 平均分都是压缩方法里最高。
效率(7B,WorldSense):
| 指标 | Full Tokens | 25% 保留 |
| Prefill 时间 | 6299 ms | 1784 ms(3.53× 加速) |
| 峰值显存 | 28.31 G | 24.00 G(降 15.2%) |
| 端到端延迟 | 10.97 s | 4.79 s(约 2.3×) |
消融把核心论点验了一遍。取消 query-aware 预算、改成两模态均匀压缩,平均掉 1.65 分;无论是「音频指导视觉」还是「视觉指导音频」,正反两个方向都比各自独立按 query 压要差。视觉侧全用 Anchor 或全用 Delta 都更差(分别 −1.10、−1.65)。音频侧 per-second 合并优于 energy-based 过滤(−2.75)、随机丢弃和平均池化。
OmniLLM 正在变多,而音视觉联合 token 的长度是它们落地的实际拦路虎。OmniScope 给了一条免训练、可直接接入现有推理管线的加速路径,25% 保留就能换 3.53 倍 prefill 加速和 15% 显存,几乎不掉点。
更值钱的是那个设计原则本身:「共享 query,不共享 salience」。它不绑死这个框架,任何要同时压多个模态 token 的系统都能借用。对做长视频理解、实时音视频交互、边缘部署的人,这是直接能用的工程结论。
论文自己承认的最大一处:视觉侧要外挂 CLIP,这个一次性评分跑在 LLM 推理管线之外。后果是 45% 保留时端到端延迟(5.28 秒)反而比 FastV(4.58 秒)和 OmniZip(4.51 秒)慢。生成越短,这个固定开销占比越大(只生成 1 个 token 时约占 13%),生成到 100 个 token 才摊到 7%。论文评测的全是短选项 QA,prefill 占大头所以加速显著;但字幕生成这类长输出场景只做了摊销分析,没给实测。
视觉依赖外部 CLIP、音频却能复用模型自身 encoder,两侧 scorer 不对称,论文在附录里说明这是因为模型内部的 vision-text alignment 还不够稳。
读下来还有两点没验证够。一是「所有压缩设置下平均最高」其实只在 45% 和 25% 两档、四个 benchmark 上成立,覆盖偏窄。二是 Video-MME 本质是视频 benchmark,论文自己说「加上音频能进一步提升」,把它算进「音视频 benchmark」略有凑数。模型只测了 Qwen2.5-Omni 的 7B 和 3B,没在 VITA-1.5 等其他 OmniLLM 上验证。