Linear Scaling Video VLMs for Long Video Understanding线性扩展的视频 VLM：长视频理解（StateKV）

长视频 VLM 的预填充（prefill）随帧数增长呈平方级开销，是长视频推理的主要瓶颈。已有流式方法（如滑窗注意力）把复杂度降到线性，但只按“最近性”保留跨帧上下文，容易丢掉早期却重要的信息，精度明显低于全量自注意力。StateKV 提出：在预填充阶段额外维护一个固定容量、按重要性动态筛选的压缩状态，只用它承载跨帧交互，把逐帧的详细 KV 完整保留给最终解码使用；跨帧注意力被限制在固定大小的记忆里，预填充开销从平方降为线性，精度显著优于滑窗类方法、接近全量自注意力，且无需微调、不改变模型结构。

长视频 VLM 的推理成本主要卡在视频侧 KV 缓存的构建（prefill）上：视觉 token 数随帧数线性增长，全量自注意力的开销却随视频长度呈平方增长。此前的思路大致分两类：一类是在输入层就丢帧、丢 token 或压缩视觉表征，但压缩过猛会明显损失长视频精度；另一类是流式预填充方法（如滑窗注意力），把视频编码和文本生成分离，用“只看最近若干帧”之类的启发式规则降低构建 KV 缓存的开销，但会丢掉大量早期却仍然有用的跨帧信息。

关键贡献

• 提出双状态 KV 缓存机制：固定容量的压缩状态承载跨帧交互，完整的详细状态承载最终解码，把长视频预填充复杂度从平方降到线性。
• 基于经验观察提出“跨帧重要性集中在少量时间锚点”和“锚点缓慢演化”两个假设，并给出可检验的机制化验证方案。
• 设计基于注意力分数的增量式 Top-K 选择规则，每帧只需在小候选池内重新排序，而不必重新扫描整段历史。
• 在三个长视频基准、三种模型家族、多个参数规模上系统验证，方法始终比滑窗类流式基线更接近全量自注意力。
• 揭示“算力换模型规模”的实践含义：省下的 FLOPs 可以用来运行更大骨干，在同等甚至更低算力下取得更高精度。
• 给出缓存构建阶段与文本解码阶段一致的 RoPE 缩放方案，保证两阶段位置编码互相兼容。

总体思路

StateKV 面向的问题是：给定一段按帧顺序输入的长视频，如何在预填充阶段把跨帧上下文的开销降到线性，同时尽量不损失全量自注意力的精度。做法是给每一层维护两套 KV 状态：一套是详细状态（detailed state），完整保留每一帧的全部视觉 token，专门留给最终文本解码使用；另一套是固定容量的压缩状态（compressed state），只在构建缓存阶段承担跨帧交互，容量不随视频长度增长。逐帧处理时，当前帧只能看到压缩状态里的历史信息，看完之后再用注意力分数把压缩状态刷新一遍——留下最重要的、淘汰不重要的。等所有帧处理完，文本生成阶段直接对完整的详细状态做标准自回归解码，压缩状态从此不再使用。

跨帧重要性集中假设

方法的第一个经验假设是：某一帧对历史 token 的注意力权重之和，绝大部分只落在一小撮“时间锚点”上，且这撮锚点的数量不随视频总长增长。定义键 $j$ 在处理第 $n$ 帧时的跨帧重要性为对全部 $T$ 个查询的注意力权重求和：

$$s_{n,j} = \sum_{i=1}^{T} A_{n,i,j}$$

存在大小为 $K$ 的锚点集合 $S_n$（$K \ll |\mathcal{H}_{n-1}|$），使得锚点集合内的重要性总和近似等于全部历史键的重要性总和：

$$\sum_{j \in S_n} s_{n,j} \approx \sum_{j \in \mathcal{H}_{n-1}} s_{n,j}$$

这个假设是“用固定容量记忆代替完整历史”能成立的前提——如果重要性均匀分布在所有历史 token 上，压缩到固定容量就必然大量丢信息。

锚点缓慢演化假设

第二个假设是锚点集合不会剧烈跳变，下一时刻有用的锚点可以由“上一时刻锚点 + 当前帧新 token”这两部分近似得到：

$$S_{n+1} \approx \mathrm{TopK}\bigl(S_n \cup \{\text{frame } n+1 \text{ 的 token}\}\bigr)$$

这条假设直接支撑了增量式更新规则：每帧只需要在“旧锚点 ∪ 新帧 token”这个小候选池里重新选一次 Top-K，而不必对整段视频历史重新打分排序，这正是把复杂度从平方降到线性的关键设计依据。

双状态 KV 缓存

在第 $\ell$ 层，处理完第 $n$ 帧后同时维护：

$$D_n^\ell = \{(K_{1:n}^\ell, V_{1:n}^\ell)\}, \quad C_n^\ell = \{(\bar{K}_n^\ell, \bar{V}_n^\ell)\}, \quad |\bar{K}_n^\ell| = |\bar{V}_n^\ell| = B$$

详细状态 $D_n^\ell$ 随帧数以 $O(nT)$ 增长、只做追加、构建阶段从不被后续帧查询，专门留给解码阶段用；压缩状态 $C_n^\ell$ 容量固定为 $B$（如 1024 个 token），是第 $n$ 帧在构建阶段唯一能看到的“过去”，且每处理完一帧就刷新一次。

逐帧前向：只对压缩记忆和当前帧做注意力

设第 $n$ 帧视觉 token 的隐状态为 $X_n \in \mathbb{R}^{T \times d}$，先算出当前帧的 Q/K/V，再和上一步的压缩记忆拼接做注意力：

$$\mathrm{Attn}\bigl(Q_n^\ell,[\bar{K}_{n-1}^\ell; K_n^\ell],[\bar{V}_{n-1}^\ell; V_n^\ell]\bigr)=\mathrm{softmax}\!\left(\frac{Q_n^\ell [\bar{K}_{n-1}^\ell; K_n^\ell]^\top}{\sqrt{d_h}} + M_n\right)\cdot [\bar{V}_{n-1}^\ell; V_n^\ell]$$

这一步是复杂度从平方降到线性的直接来源：每帧的注意力计算量只和“当前帧大小 + 固定的压缩记忆大小”相关，不再随已处理的帧数线性甚至更快增长。算完之后，当前帧自己的 $(K_n^\ell,V_n^\ell)$ 会被追加进详细状态 $D_n^\ell$，供解码阶段使用。

压缩状态的更新：注意力驱动的 Top-K 筛选

候选池由上一步锚点和当前帧 token 组成：

$$\mathcal{U}_n^\ell = \bar{S}_{n-1}^\ell \cup \{1,\dots,T\}$$

候选池里每个 token 的重要性分数用视频侧的平均注意力算：

$$s_{n,j}^\ell = \frac{1}{T} \sum_{i=1}^{T} A_{n,i,j}^\ell$$

取分数最高的 $B$ 个 token 组成新的压缩状态：

$$\bar{S}_n^\ell = \mathrm{TopK}\bigl(\{s_{n,j}^\ell : j \in \mathcal{U}_n^\ell\},\, B\bigr)$$

分数只用“视频看视频”的注意力统计计算，不掺入文本查询——因为压缩状态只是构建阶段的近似跨帧记忆，不是最终喂给语言模型的那份缓存，没必要迎合某个具体问题的查询方向。

为什么解码阶段仍用完整详细缓存

StateKV 的关键设计选择是把“压缩近似”限定在预填充阶段，解码阶段完全不用压缩状态、只用保留了全部帧全部 token 的详细状态 $D_N^\ell$ 做条件生成。这样设计的理由是：压缩状态只需要近似“帧与帧之间要传递多少信息”这一件事，不需要同时承担“最终回答问题需要哪些细节”这件事——如果两件事都靠同一份固定容量记忆完成，容量瓶颈会直接体现在回答质量上；分离之后，压缩状态可以做得很小、丢失也无所谓，因为解码永远有机会看到完整细节。

小结

StateKV 的核心是把“压缩近似”和“精确解码”拆成两条独立的缓存：跨帧交互靠一个容量固定、按注意力重要性动态刷新的压缩状态完成，把预填充复杂度从平方降到线性；最终回答问题时仍然对着完整的逐帧详细缓存做标准解码，精度损失被限制在“构建阶段的近似”，不会传导到“生成阶段的信息量”。

实验在 VideoMME（去字幕）、MLVU、OVOBench（Real-Time 子集）上进行，视频 1 FPS 采样、单例最长 512 帧，覆盖 InternVL3 等多种模型家族与规模。除注意力算子外各方法共享同一推理栈。结论：StateKV 三个基准上都比滑窗基线更接近全量自注意力，预填充计算量从平方降到线性。

关键数据

StateKV 处于“固定预算压缩”与“流式近似”两条路线之间：不像 token 剪枝方法牺牲最终解码时的细节，也不像滑窗方法固守局部近邻假设，而是用注意力驱动的动态记忆去近似全量自注意力。它说明流式预填充可以用比滑窗更聪明的选择规则大幅逼近全量精度，为后续在同一算力下选择“更大模型 + 近似注意力”而非“更小模型 + 精确注意力”提供了依据。

局限与不足

论文对“跨帧注意力集中在少量锚点”和“锚点缓慢演化”两个核心假设的机制验证，只在作者测试过的模型和输入上做了检验，并非通用或理论上必然成立的性质——未测试过的骨干或未来模型可能不满足同样的假设，届时压缩状态的近似质量无法保证。方法把重要性完全建立在“仅看视频 token”的注意力统计上，刻意不考虑文本查询可能如何改变哪些历史 token 更重要；这在保证解码阶段仍能用完整详细缓存的前提下是合理简化，但也意味着压缩状态本身对特定问题没有任何针对性。论文效率结论主要以测量 FLOPs 而非端到端 wall-clock 为准，缓存构建阶段用的是 eager attention 路径，真实部署中的实际加速效果依赖于是否配备论文补充材料中提到的自定义 Triton kernel。