近年来,大语言模型 (LLM) 的能力大幅扩展,已从单纯的文本处理迈向了多模态理解。在这些进步中,Video-LLM (视频大语言模型) 因其能够观看、分析并回答有关视频内容的问题而脱颖而出。然而,这种能力的代价是巨大的计算成本。
处理视频与处理静态图像有着本质的区别。单个视频可以分解为数百甚至数千帧,当这些帧转换为 token 时,生成的序列长度极其庞大——对于一个短片来说,往往会超过 100,000 个 token。
这就造成了一个瓶颈。Video-LLM 遭受着高推理延迟的困扰,使得实时应用变得困难。罪魁祸首是这些模型使用的自回归解码机制,它要求系统在生成每一个词时,都要重复访问海量的内存。
在这篇文章中,我们将深入探讨一篇名为 “Sparse-to-Dense: A Free Lunch for Lossless Acceleration of Video Understanding in LLMs” 的新研究论文。这篇论文提出了一种名为 Sparse-to-Dense (STD) 的新方法,该方法无需任何模型训练或架构更改,即可将视频处理速度提高达 \(1.94\times\)。它实现这一点的核心在于一个简单的观察: 模型在生成下一个词时,极少需要查看每一帧视频。
瓶颈所在: 为什么 Video-LLM 这么慢
要理解解决方案,我们必须先理解问题所在。现代 Video-LLM 以自回归方式运行。这意味着它们一次生成一个 token (词或子词) 。为了预测下一个 token,模型必须“关注” (attend to) ——或者说回顾——序列中所有之前的 token。
在视频语境下,“所有之前的 token”包括代表视频每一采样帧的视觉 token。如果一个 1 小时的视频每 5 秒采样一次,它将产生 720 帧。在像 VILA 这样的模型中,这转化为超过 141,000 个视觉 token。
内存墙与 KV 缓存
为了避免在每一步都重新计算这 141,000 个 token 的数学表示 (键 Key 和值 Value) ,LLM 使用了一种称为 KV 缓存 (KV Caching) 的技术。它们将这些张量存储在 GPU 的高带宽内存 (HBM) 中。
虽然 KV 缓存节省了计算量,但它将瓶颈转移到了显存带宽上。在每个生成步骤中,GPU 必须从内存中提取这个巨大的 KV 缓存来计算注意力分数。随着视频长度的增加,缓存也随之增长,在内存和计算单元之间移动数据所需的输入/输出 (I/O) 操作成为了限制因素。这就是为什么为长视频生成字幕会让人感觉反应迟钝。
解决方案: 投机解码
在纯文本 LLM 中,解决这种延迟的一种流行方法是投机解码 (Speculative Decoding) 。 这种技术依赖于一个“草稿-验证”循环:
- 起草 (Drafting): 一个更小、更快的模型 (草稿模型) 快速猜测接下来的几个 token。
- 验证 (Verification): 主模型 (目标模型,通常很大) 在单次并行传递中检查这些猜测。
如果草稿是正确的,系统就会接受这些 token,实际上是以大模型一次内存访问的成本生成了多个 token。如果草稿是错误的,系统会丢弃错误的 token 并恢复标准生成。
将此应用于 Video-LLM 的问题在于, 草稿模型非常昂贵 。 通常你需要训练一个独立的、更小的模型,或者维护一个复杂的辅助系统。这增加了工程开销,并消耗了额外的 GPU 显存,而这在处理视频时本来就很稀缺。
隆重介绍 Sparse-to-Dense (STD)
Sparse-to-Dense (STD) 背后的研究人员提出了一个关键问题: 我们能否在不需要独立草稿模型的情况下进行投机解码?
他们的答案在于稀疏性 (Sparsity) 的概念。
核心观察
作者分析了 Video-LLM (特别是 Qwen2-VL) 的注意力模式,并做出了一个至关重要的发现。在解码阶段,模型的注意力分数极其稀疏。这意味着对于任何给定的 token 生成步骤,模型将其计算注意力集中在一小部分“关键”token 上,实际上忽略了绝大多数视频帧。
实证测试表明,仅保留 Top-K (最相关的) KV 缓存对,即可在大约 95% 的 token 上保持原始预测的准确性。这一见解表明,我们不需要单独的草稿模型。我们可以简单地通过限制原始模型仅使用其内存中最这重要的部分,来让其充当自己的起草者。
STD 如何工作
STD 将解码过程分为两个共享相同模型权重的不同模块:
- 稀疏模块 (起草者) : 该模块快速生成推测性 token。它使用“Top-K 注意力”,意味着它只加载并关注视频 token 的一小部分选定子集 (稀疏 KV 缓存) 。因为加载的数据更少,它的运行速度比标准解码快得多。
- 稠密模块 (验证者) : 该模块使用带有完整 KV 缓存的完整自注意力机制。它并行运行以验证稀疏模块提出的 token。
至关重要的是,因为稠密模块就是原始的、未修改的模型,所以这个过程是无损的。最终输出在数学上保证与模型正常生成的输出完全相同。如果稀疏模块猜错了,稠密模块会对其进行纠正。
选择重要 Token
如果稀疏模块只查看 token 的子集,它如何知道该保留哪些呢?随机选择会导致糟糕的预测。
作者设计了一种巧妙的、无需训练的指标。由于目标通常是回答用户的问题或遵循文本提示,因此视觉 token 的相关性由文本 token 决定。
在“预填充”阶段 (模型首次处理视频和用户提示时) ,系统计算文本 token (提示) 和视觉 token (视频帧) 之间的注意力分数。收到文本关注度最高的视觉 token 被认为是最关键的。
形式上,对于每一层,系统根据视觉 token 从文本 token 收到的平均注意力分数,保留 Top-K 个视觉 token。这种选择在解码开始前发生一次,避免了生成过程中的动态开销。
效率分析
为什么这会更快?让我们看看 I/O 复杂度。
在标准解码中,每个生成的 token 都需要加载完整的缓存 (\(m_v + m_t\),其中 \(m_v\) 是视觉 token,\(m_t\) 是文本 token) 。
在 STD 中,稀疏模块生成 \(\gamma\) (gamma) 个草稿 token。它只加载较小的 Top-K 缓存。然后,稠密模块加载一次完整缓存来同时验证所有 \(\gamma\) 个 token。
每个 token 的平均 I/O 开销由以下公式定义:

变量含义如下:
- \(\gamma\) (gamma): 起草的推测性 token 数量。
- \(K\): 稀疏缓存的大小。
- \(\alpha\) (alpha): 接受率 (正确的草稿 token 的百分比) 。
只要接受率 \(\alpha\) 很高——由于稀疏性的观察结果,它确实很高——每个 token 的平均内存成本就会显著低于标准成本。
实验结果
研究人员在最先进的 Video-LLM 上实现了 STD,具体包括 LLaVA-OneVision-7B 和 Qwen2-VL-7B , 并在视频理解基准测试 (MLVU 和 VideoMME) 上进行了评估。
他们将 STD 与另外两个免训练的加速基线进行了比较:
- LayerSkip: 一种在较低层提前退出模型以起草 token 的方法。
- Streaming: 一种使用流式注意力 (基于窗口) 作为起草者的方法。
结果如下表 1 所示,非常令人信服。

数据中的关键结论:
- 加速: STD 实现了高达 \(1.94\times\) 的端到端时间加速 。 这意味着以前需要 10 秒的视频处理任务现在大约只需要 5 秒。
- 卓越的接受率: 注意接受率 (Acc %)。STD 显著优于 LayerSkip 和 Streaming。例如,在 Qwen2-VL 的 MLVU 测试中,STD 的接受率为 66.1%,而 LayerSkip 仅为 5.2%。这验证了“稀疏注意力”比“早期层退出”能更好地近似完整模型的假设。
- 无损: 表格指出未报告生成内容的评估,因为该方法是无损的——根据定义,其准确性与原始模型完全相同。
超参数分析
STD 的性能主要取决于两个超参数:
- \(K\): 在稀疏缓存中保留多少个视觉 token。
- \(\gamma\): 一次起草多少个 token。
研究人员在图 1 中分析了这些变量的影响。

观察 图表 (a) , 我们可以看到随着 \(\gamma\) 增加,加速比呈现倒 U 形。如果 \(\gamma\) 太小,我们无法从并行性中获益太多。如果 \(\gamma\) 太大 (例如 13) ,草稿模型被迫预测太遥远的未来,准确率下降,我们在验证错误 token 上浪费了时间。6-9 左右的值似乎是最佳的。
图表 (b) 揭示了与 \(K\) 的权衡。较高的 \(K\) 意味着草稿模型更准确 (接受率更高,由绿色柱状图表示) 。然而,较高的 \(K\) 也意味着草稿模型必须加载更多数据,从而变慢。“最佳平衡点”确保草稿模型足够准确以发挥作用,同时又足够轻量以保持快速。
结论与未来展望
“Sparse-to-Dense” 论文提出了一个令人信服的论点,让我们重新审视如何优化大型多模态模型。与其训练复杂的辅助模型或执行破坏准确性的有损量化,我们不如利用注意力机制本身的固有行为。
优势总结:
- 即插即用: 无需训练或微调。仅需约 20 行代码即可实现。
- 无需额外显存: 由于稀疏模型只是稠密模型的一个子集,因此不需要额外的 GPU 显存来存储模型权重。
- 无损: 它保证输出分布与原始的、计算昂贵的模型完全相同。
对于任何部署 Video-LLM 的人来说,这项技术都是一顿“免费的午餐”。它有效地解锁了高效的长视频处理,使得像实时视频摘要或交互式视频聊天这样的应用在当前硬件上变得更加可行。
虽然目前的局限性在于依赖 GPU HBM 容量 (完整缓存仍必须存在于内存中以进行验证步骤) ,但未来的工作可以探索将部分缓存卸载到 CPU 内存,或将其与其他压缩技术相结合。目前,STD 代表了使 Video-LLM 更快、更易用的重要一步。
](https://deep-paper.org/en/paper/2505.19155/images/cover.png)