Google DeepMind：视频大模型的真正瓶颈，从来不在 LLM 那一端

过去一年里，视频大模型的圈子默契地达成了一个共识：要让 Video LLM 看得更长，就得在视觉 token 上做文章。各种 token reduction、token merging、token pruning 方法层出不穷，方向几乎都一样——把视觉编码器吐出的那一堆 token 砍掉一部分，再喂给 LLM。

道理很直接：LLM 是 self-attention 的二次复杂度，token 越多越慢，砍 token 就是给 LLM 减负。

但 Google DeepMind 在 2026 年 5 月放出的一篇新论文 LiteFrame——决定视频 LLM 能不能"看得长"的瓶颈，早就从 LLM 转移到了视觉编码器本身。

一个被忽视的"瓶颈转移"

让我们先看看主流 Video LLM 的标准架构：一个 Vision Transformer 把视频逐帧编码成 token，对齐到 LLM 的 embedding 空间，LLM 再去做问答、总结、推理。

在朴素实现里，瓶颈很明显——LLM 的 attention 复杂度随 token 数平方爆炸，所以喂 64 帧就已经吃力。社区于是引入了各种 post-hoc token 压缩方法：ToMe、PruMerge、FastVID……它们的共同点是，让冻结的视觉编码器照常把全分辨率特征算出来，再在喂进 LLM 之前把 token 砍掉 4 倍、8 倍乃至 16 倍。

LiteFrame 的作者们做了一件大多数人没做的事——他们把每个组件的延迟分别测了一遍。结果是这样的：

• 当 token 压缩比开到 16×，LLM 的负担确实显著下降；
• 但与此同时，视觉编码器逐帧计算的成本几乎一分都没省下；
• 帧数一旦从 64 拉到 256、512，视觉编码器的累计延迟就反超 LLM，成为新的天花板。

论文管这个现象叫 scaling paradox：你越激进地砍 token，瓶颈就越快从 LLM 跳到 ViT 头上。砍 LLM 的努力，反而让"看更多帧"这件事撞上了一堵更厚的墙。

复杂的压缩方法，不如简单加权平均

在亮出主角之前，论文先做了一段铺垫——post-hoc token reduction 这条路线本身就值得重新审视。

主流方法的核心思路是用 attention 或 bipartite matching 算出"哪些 token 重要"，再合并或删除"不重要"的那些。问题在于，这些得分大多来自 token 的内容而不是位置，结果就是把视频原本规整的时空结构搅乱了——而连续的时空结构恰恰是视频理解最依赖的东西。

LiteFrame 作者提出了一个朴素到几乎让人意外的东西，叫 Weighted Average Pooling (WAP)：把时空特征切成规则的 3D block，每个 block 内用 [CLS] token 与块内每个 token 的相似度做 softmax，再加权平均池化成一个 token。

它同时保留了池化的位置规则性和attention 的语义敏感性。在 InternVL3-8B 上做 16× 压缩，跨 Video-MME、MLVU、LongVideoBench 三个基准平均下来：

• 普通 Average Pooling：60.2%
• ToMe：60.0%
• FastVID：60.6%
• PruMerge：59.7%
• WAP：62.0%

这个结论本身就值得记住——在视频 token 压缩里，规则结构+轻量注意力权重的组合往往比花哨的图匹配/剪枝更稳。

帧数是天花板，不是 token 数

WAP 证明了"激进压缩并不会让精度崩盘"。接下来作者拿它做了第二个铺垫实验：在固定的 token 预算下，到底是塞更多帧划算，还是塞更精细的帧划算？

结论一面倒地倒向前者。横轴拉到 64 帧时，LongVideoBench 等长视频基准的精度仍在攀升，几乎完全没看到饱和的迹象。token 预算如果固定，把它花在"更多帧"上比花在"更精细的单帧"上要值得多。

这两个铺垫合起来就指向同一个结论——我们需要的不是又一个 post-hoc 压缩方法，而是一个从一开始就吐出压缩后 token 的视觉编码器。

LiteFrame：把压缩"焊"进编码器里

LiteFrame 的核心思路一句话能说清：与其让一个 304M 的大 ViT 老老实实算完一整套 dense token、再外挂一个砍刀，不如直接训练一个 87M 的小 ViT，让它天生就输出压缩好的、信息密度高的 token。

它由两大件组成。

第一件：时空压缩式编码器架构

学生 backbone 选了一个标准的 12 层 ViT-Base（768 维），但在每个空间注意力层之后插了一个深度可分离 1D 时序卷积（DW TempConv），用极小的参数代价让模型能感知相邻帧。

更关键的是，作者在第 4 层和第 8 层之后插入了带步长的 DW 卷积，分别按 [2, 2, 2]（时空同时下采样）和 [2, 1, 1]（仅时间下采样）压缩特征图。这意味着越靠近输出层，token 数越少，深层 transformer 的负担也跟着断崖式下降。

论文实测了几种时序建模方案的延迟和 FLOPs（256 帧输入下）：

DW 时序卷积在三个维度上同时拿到最优：参数最少、FLOPs 最少、延迟最低。这是一个非常实用的设计选择。

第二件：Compressed Token Distillation (CTD)

光有一个轻量架构还不够。如果让小 ViT 去拟合大 ViT 那套 dense 特征，它学得很费力——既要重建空间细节又得编码语义，结果两边都做不好。

CTD 的巧思在于改变蒸馏目标。它不让学生去逼近老师的 dense 输出，而是先用前面提到的 WAP 算子把老师的特征压成 16× 紧凑表示，再让学生直接预测这个已经压缩好的目标。

这一步本质上是把 "WAP 这个 attention 加权的池化操作"编译进了学生的静态参数里。推理时学生不需要做任何 attention 池化，但行为上等价于跑了一次 WAP。论文用一个对照组（RTD，Reconstructive Token Distillation，把目标换成自编码重构）做反证，RTD 只到 43.8%，远不如 CTD 的 62.8%——可见蒸馏目标是不是"已压缩"的状态，差别是决定性的。

第三件：Language Model Adaptation (LMA)

CTD 训出来的小 encoder 与 LLM 之间存在一个“模态间隔”——学生的 latent 空间未必正好是 LLM 习惯的格式。为此论文加了一个轻量的 LMA 阶段：用 LoRA 微调 LLM（rank 4，α=8），同时让 encoder 也跟着轻调，目标是常规的视频问答 cross-entropy loss。

这一步还附带了一个隐藏收益：让 LLM 适应长达 512 帧的扩展时序上下文。CTD 解决了 encoder 端的瓶颈，LMA 顺便把 LLM 端的"看得长"也撑了起来。

35% 更快，8 倍更多帧，精度还略升

把上述三件事拼起来，LiteFrame 在 InternVL3-8B 上交出了一份相当扎实的成绩单：

注意这一行里同时发生了三件事：

1. 延迟降 34.6%——不仅 ViT 端快，LLM 端也跟着快，因为输入 token 也跟着压缩到了 16 个/帧；
2. 处理 8 倍帧数（32 → 256）；
3. 平均精度反而比老师高 0.4 个点。

而做到这些只用了 87M 视觉参数（老师 304M）。

放到 Pareto 前沿图上，LiteFrame 把整条曲线整体向左上推——同等延迟下精度更高，同等精度下延迟更低，把 ToMe、FastVID、PruMerge、AutoGaze 这些前作齐刷刷地压在身下。

更有意思的是空间维度的零样本扩展：把高分辨率帧切成 448px 子块独立编码，LiteFrame 在 HLVid 上拿到 54.1，超过了需要 3584px 输入和 1024 帧的 AutoGaze（52.6），而它自己完全没有在高分辨率上训练过。

消融拆解：哪一件最重要？

论文的消融实验把四个组件逐个剥开，让人一眼能看到每件事各值多少分（128 帧，仅 800 epochs）：

两个细节值得停一下。

一是WAP 这个蒸馏目标几乎不可替代：去掉它换成重构目标，精度直接腰斩。这说明"信息密集的压缩表示"本身就是一个高质量的监督信号。

二是LMA 增益不大但稳定：单独的 CTD 已经能在 87ms 内拿到 62.8，LMA 再多 0.6 个点。在工业落地里，LMA 也是把生成质量和长上下文兼容性兜底的关键一步。

它意味着什么？

LiteFrame 不是一个新模型家族，更像是一篇方法论意义上的"打脸论文"——它告诉社区，过去一年大家集中火力优化 LLM 那一端，其实是在优化一个已经被推平的瓶颈。

它带来的几个引申启示也值得记下：

• token 压缩应该内化进 encoder，而不是当后处理。后处理永远绕不开"先全量算一遍"的固定成本。
• 蒸馏的目标比方法更重要。把目标定成"已压缩后的语义稠密表示"，能让小学生网络真正学到东西；定成原始 dense 输出或自编码，学生不堪重负或学不到核心信号。
• 简单方法常常打败复杂方法。WAP 把规则池化和注意力加权揉一起，就足以打败一票 token merging/pruning 的精巧设计。
• "想看更长"的代价正在从存储/算力转向训练投入。LiteFrame 的代价是 8 张 H100 训练 21 天——这是个不便宜的训练账单，但相对于推理端持续节省的延迟和算力，长期看是值得的。

局限与可挖之处

论文也留下了几个需要承认的边界。

第一，整套方案目前只在 InternVL3-8B 一个 backbone 上验证。换成 Qwen2.5-VL、Gemini 系列的视觉栈，CTD 与 DW 时序卷积是否一样吃得开，需要后续工作回答。

第二，训练成本不低。1800 epochs 的 CTD + 25K steps 的 LMA，意味着这条路线对开源社区不太友好——除非有团队愿意开源蒸馏好的 LiteFrame 权重，否则普通研究者难以复现。

第三，512 帧仍然不是终点。Hour-level video（小时级视频）的理解需要的是更长的时序记忆机制，而不仅仅是更多帧；LiteFrame 解决的是"硬件预算固定时怎么塞更多帧"，但"上下文如何高效利用更多帧"仍然是一个开放问题。

总结

把视野拉远一点，LiteFrame 真正提出的问题其实更通用：当一个系统由多个组件串联，瓶颈优化的努力很容易集中在最显眼的那一个，而忽视其余组件的隐藏成本。

视频 LLM 是这样，未来的 agent 系统、推理 + 检索的复合架构，甚至端到端的具身智能链路，可能都会重复这个故事——你最初优化的那个瓶颈，往往不是最终拦住你的瓶颈。

下次再看到"我把 LLM 推理速度提升了 N 倍"的工作时，不妨多问一句：那剩下的那一半延迟，跑在哪里？