冰箱里的大象：一个视频理解模型都不知道该怎么解决的内存难题

你有没有想过一个问题：一部两小时的电影，如果让AI逐帧去看，它需要记住多少东西？

答案可能会让你倒吸一口凉气。假设每一帧画面都要变成几百甚至上千个视觉token塞进模型的脑子里，两小时电影按每秒一帧算，就是七千多帧。乘起来，这个数字大到让任何一块显卡都望而却步。这就是长视频理解领域那头一直蹲在冰箱里、谁都不愿意正视的大象：视频越长，模型要处理的信息量就越大，而且是线性增长，没有上限。

这篇来自中国人民大学、华盛顿大学和北卡教堂山分校研究者的论文，起名就叫"冰箱里的大象"，意思很直白：这个问题明明摆在那里，大到没法忽视，但过去的解决方案大多是绕着走，而不是真正把它解决掉。

问题到底难在哪

先说清楚当下视觉语言模型是怎么"看"视频的。

视觉语言模型（VLM）：一种能同时理解图像和文字的AI模型，通常由一个视觉编码器加上一个语言模型组成，视觉编码器把画面变成一串数字（也就是token），语言模型再去理解这些数字和文字之间的关系

主流做法是把视频拆成一帧一帧的图片，每一帧单独过一遍视觉编码器，生成一批token，然后把所有帧的token拼起来，一股脑交给语言模型。问题就出在这里：帧数越多，token越多，内存消耗和计算时间就跟着线性往上涨，这在学术上写作O(n)复杂度，n就是帧数。

O(n)复杂度：一种描述计算量增长规律的表示法，意思是计算量和输入规模成正比，输入翻倍，计算量也大致翻倍

视频越长，这个n就越大，总有一天会把显卡的内存撑爆。过去几年，研究者们想了不少办法来缓解这个问题，大体分成两条路。第一条路叫token压缩，就是想办法把每一帧产生的token数量削减一些，比如合并相似的token，或者按重要性打分后砍掉不重要的。第二条路叫关键帧选择，干脆不要那么多帧，从整段视频里挑出最重要的几帧，其余的直接丢掉。

这两条路听起来都挺合理，但论文作者指出了一个扎心的事实：不管怎么压缩或者怎么挑选，保留下来的token数量依然会随着视频长度增长，只是增长得慢一点而已，复杂度还是O(n)或者更高。换句话说，这些方法只是把那头大象从冰箱门口挪到冰箱深处，大象还在那儿，迟早会被撞见。

更麻烦的是第二个问题：关键帧选择是一种"非黑即白"的硬性操作，要么留下一帧，要么彻底丢弃。这种做法天然带有信息损失，而且会把时间上连续的动作硬生生切断。想象你在看一段监控录像，想找出"有人把包放下又拿走"这个瞬间，如果模型简单粗暴地只保留每隔几秒的一帧，很可能正好漏掉那个关键的放下和拿起的动作。长视频理解恰恰最依赖这种跨越时间的因果关系，而硬丢帧的方法恰好最容易破坏它。

FramePack-U：给每一帧一个不同的"清晰度待遇"

研究者们的解法有点反直觉：既然问题是"帧数太多token太多"，那就不要在帧数和token数量之间做二选一，而是让每一帧用不同的分辨率。

具体来说，重要的帧保留高分辨率，细节保留得多；不那么重要的帧大幅降低分辨率，只留个大概轮廓。这样一来，不管视频原本有多少帧，经过这套处理后，总的token数量都被死死摁在一个固定预算之内，不会再随视频长度无限膨胀。这就是论文标题里暗示的解法：把大象塞进一个固定大小的冰箱里，不是把大象变小，而是让它换一种"打包"的方式装进去。

这个灵感来自视频生成领域的一篇工作，叫FramePack

FramePack：最初是为视频生成模型设计的一种打包策略，核心思路是给不同重要性的输入帧分配不同长度的处理上下文，离预测目标越近的帧获得越精细的处理

FramePack原本是用来解决视频生成时的计算量问题的，生成模型在预测下一帧时，离当前预测目标越近的历史帧越重要，所以给它们更长的上下文；离得远的帧随便压缩一下就行。但这套逻辑直接搬到"理解"任务上是行不通的，因为理解任务不关心"哪一帧离当前位置近"，而关心"哪一帧和你要问的问题相关"。研究者们把这个思路改造了一下，做出了FramePack-U，这个U既代表Understanding（理解），也暗示了它和原版FramePack的区别。

这里有个关键决策点，值得停下来想一想：如果继续沿用原版FramePack那种"按时间远近分配清晰度"的逻辑会怎样？答案是很糟糕。因为对于理解任务来说，重要的证据可能出现在视频任何一个时间点，开头、中间、结尾都有可能，跟时间位置毫无关系。这就好比你在整理一个仓库的货架，原来的规则是"离门口近的货架用最好的灯光"，但顾客真正想买的东西可能堆在最里面的角落，这种按位置分配资源的规则完全没有照顾到真实需求。FramePack-U要做的，就是把分配资源的标准从"位置"换成"和你问题的相关程度"。

FramePack-U分两步走。第一步是找出哪些帧既和问题相关、又彼此不重复；第二步是把挑出来的这些帧按照重要性分配不同的分辨率，塞进固定大小的框里。

第一步：既要相关，又要多样

怎么判断一帧和用户提出的问题相不相关？

研究者用了CLIP

CLIP：一种能同时理解图像和文字的模型，可以计算一张图片和一句话在语义上有多相似，相似度高说明图片内容和文字描述匹配

来给每一帧打分，计算这一帧画面和文字提问之间的语义相似度，相似度越高，说明这一帧越可能包含回答这个问题所需要的线索。

但光看相关性还不够。设想一个场景：有人在问"视频里那只猫最后做了什么动作"，如果相关性打分直接选出得分最高的前N帧，很可能这N帧全都长得差不多，因为猫做那个动作持续了好几秒，连续几帧画面几乎一模一样。这种情况下，你费了半天劲挑出来的"高分帧"实际上提供的信息量极低，等于把有限的高分辨率名额都浪费在了重复信息上。

这就是为什么FramePack-U要加上第二道筛选：多样性。具体做法是一种贪心算法，先选出相关性得分最高的那一帧当作起点，然后每一步都从剩下的候选帧里，挑一个"和已经选中的帧视觉上差异最大"的帧，同时还要兼顾它本身的相关性得分。这个过程反复进行，直到选够指定数量的帧为止。

这套机制背后有个权衡参数，论文里记作λ，用来调节"相关性"和"多样性"这两个目标各自占多少权重，实验里设成了0.7，偏向相关性多一点，但多样性依然会强制拉开被选帧之间的视觉距离。

打个比方，这有点像你去相亲网站上挑对象，光看"条件匹配度"排名前十的人选，可能个个都长得差不多、经历也雷同，因为匹配算法本身就偏好某一类特征。真正聪明的做法是在条件匹配的基础上，刻意多看看彼此之间风格差异大的几个人，这样你了解到的信息面才更广，不会因为算法偏好而错过真正合适但"标签"不那么突出的那个人。如果FramePack-U只做相关性排序而不做多样性筛选，实验数据显示在Video-MME基准上的表现会从76.3掉到69.8，足足掉了6.5个百分点，这就是"只看匹配度不看差异"付出的代价。

第二步：把帧按重要性分层打包

选好了帧，接下来要决定每一帧用多高的分辨率。

论文里提出了一个叫"打包方案"的概念，用数学语言写出来是这样的：把所有帧按降采样因子分组，比如d=1表示原始分辨率，d=2表示长宽各缩小一半，d=4表示再缩小一半。每个分组里有多少帧、用多高的分辨率，都要满足一个总的token预算上限，公式写出来就是每组帧数除以降采样因子的平方，再求和，不能超过预算B。

降采样因子：表示一张图片被缩小的倍数，比如因子为2意味着图片长和宽都缩小到原来的一半，面积就变成四分之一，对应需要处理的token数量也降到原来的四分之一

这个设计的精妙之处在于，同样的内存预算，可以打包出完全不一样数量的帧。论文举了个例子：如果用4帧的内存预算，你可以选择4帧全部用原始分辨率（d1f4），也可以选择16帧全部用1/2分辨率（d2f16），甚至可以混合搭配，比如2帧原始分辨率加上8帧1/2分辨率再加上16帧1/4分辨率（d1f2d2f8d4f16）。在同样的内存开销下，后一种方案能看到的时间范围明显更广。

排好序之后，前面排名靠前的帧（也就是既相关又多样的那些）分配到更高的分辨率，排名靠后的逐级降低分辨率。这样一来，重要的证据被保留得清清楚楚，不那么重要的背景画面哪怕模糊一点，也至少保留了"它存在过"这个事实，没有被彻底丢弃。

这里有个很直观的类比：这就像你整理一本旅行相册，照片太多塞不进一本相册里。与其直接撕掉大半照片，不如把最精彩的那几张放大冲印成大尺寸贴在显眼位置，剩下的照片都缩小成小尺寸的缩略图贴在旁边。相册还是那本相册，页数没有变多，但你翻开的时候，既能看到清晰的高光时刻，又不会完全失去对整趟旅程的时间脉络感。如果直接把不重要的照片全撕掉，你翻相册的时候会觉得故事线断断续续，很多过渡镜头都消失了，整个旅程显得支离破碎。

实验结果：数字说话

研究者们在三个长视频理解的主流测试集上做了验证：LongVideoBench

LongVideoBench：一个专门测试模型理解长视频能力的评测基准，按视频时长分成15秒、60秒、600秒、3600秒等不同档次分别打分

、MLVU

MLVU：全称是多任务长视频理解基准，用来衡量模型在各种长视频任务上的综合表现，论文里主要看它的M-average综合得分

，以及Video-MME

Video-MME：一个多模态大模型在视频分析上的综合评测集，按视频长度分成短、中、长三档分别统计准确率，特别关注长视频那一档的表现

测试用了两个Qwen系列的模型，一个是270亿参数的密集模型Qwen3.6-27B，另一个是350亿参数的混合专家模型Qwen3.5-35B-A3B。

混合专家模型（MoE）：一种模型架构，内部包含多个"专家"子网络，每次推理只激活其中一部分专家，这样可以在参数总量很大的情况下，实际计算量反而比较小

结果相当亮眼。在Qwen3.5-35B-A3B上，使用128帧的内存预算时，FramePack-U相比官方原版方法，在三个测试集上分别提升了12.9%、10.6%和9.7%。换算一下，这意味着原本模型做对的题目，用了FramePack-U之后，大约每10道题里能多做对1道以上，这个幅度在学术评测里已经相当显著。

| 方法 | LongVideoBench | MLVU | Video-MME |

|---|---|---|---|

| 官方原版（128帧） | 59.4 | 71.8 | 66.7 |

| FastVID | 50.3 | 66.7 | 61.5 |

| VisionZip | 52.2 | 65.6 | 60.7 |

| FrameFusion | 56.5 | 63.9 | 61.3 |

| **FramePack-U** | **72.3** | **82.4** | **76.4** |

更值得玩味的是，研究者对比的几个其他训练无需微调的压缩方法，比如FastVID、VisionZip、FrameFusion，在同样内存预算下表现反而比什么都不做的"官方原版"还要差。这说明简单粗暴地砍token或砍帧，不仅没解决问题，反而可能把有用的信息一起砍掉了。而FramePack-U是极少数能让压缩之后的效果比不压缩还要好的方法。

论文还把FramePack-U的最好结果拿去和GPT-5、Gemini 3 Pro这些体量大得多的闭源商用模型对比，发现开源的FramePack-U方案在某些基准上的表现已经能够逼近甚至超过这些重量级选手，这对于一个完全不需要重新训练、直接插到现成模型上就能用的方法来说，已经相当难得。

三个值得深挖的消融实验

论文做了大量消融实验，拆解每个设计到底贡献了多少价值，这里挑几个最说明问题的讲一讲。

第一个实验是单独去掉"多样性"这个环节，只按相关性排序。结果显示，在Video-MME上的表现大幅下滑，掉了6到8个百分点不等，而且几乎在所有打包方案和内存预算下都出现了类似的衰减。这证实了前面提到的猜测：光看和问题的匹配度，很容易选出一堆视觉上大同小异的帧，浪费高分辨率名额。

第二个实验是单独去掉"相关性"，换成一种不依赖文字提问的排序方式，叫二叉树中点排序。

二叉树中点排序：一种不需要任何语义信息的帧排序方法，先取整段视频正中间的那一帧排第一，再分别取左半段和右半段各自的中点，依此类推，像搭建一棵二叉树一样层层细分

这种方法虽然能保证时间上的覆盖比较均匀，但完全不知道用户到底在问什么。实验结果显示，在大多数指标上都比加入相关性判断的完整版本要差，尤其在MLVU上差距能达到1.8到4.8个百分点。这说明，光靠均匀采样时间点是不够的，还是得让模型知道"去哪里找答案"。

第三个实验最有意思，是关于模型规模的。研究者比较了Qwen3.5的4B、9B和Qwen3.6的27B三个不同大小的模型，发现FramePack-U带来的提升幅度，随着模型规模增大而越来越明显。在27B模型上，128帧预算下三个基准的提升分别达到5.6、7.2、3.8个百分点，而在4B小模型上同样的设置提升只有1.7、4.0、1.1个百分点，甚至在某些更大的内存预算下，小模型会出现轻微的性能下降。

这个发现挺耐人寻味的。研究者的解释是，FramePack-U能提供更丰富、更多样的视觉证据，但小模型的"脑容量"有限，未必有能力把这么多信息都整合消化好。这就好比你给一个刚学会认字的小孩一整套百科全书和一个有十年阅读经验的成年人同一套书，成年人能从中提炼出更多有用的知识，小孩反而可能被信息量淹没，抓不住重点。这提醒我们一个朴素的道理：更丰富的输入材料能不能转化成更好的输出，取决于处理这些材料的能力是否跟得上。

内存和速度：真金白银的收益

光说准确率提升还不够，研究者还专门测了内存占用和推理延迟。

测试在单张NVIDIA A800显卡上进行，对比了FramePack-U和原版模型在不同视频时长下的内存消耗。结果显示，随着视频从15秒延长到3600秒（也就是一小时），原版模型的内存开销持续飙升，而FramePack-U始终保持在一个恒定的上限内，这正是论文标题里强调的"常数级内存复杂度"的直接体现。

有意思的是，在27B这个最大模型上，FramePack-U的整体延迟反而在极长视频上略高于原版模型，原因并不是算法本身慢，而是因为显存受限的原版模型被迫只能采样最多224帧，而FramePack-U为了充分评估候选帧，会以每秒一帧的速度实际解码多达3600帧视频，解码这么多帧产生的硬盘读取开销，抵消了推理阶段省下来的时间。这其实恰恰反过来证明了一个事实：原版模型之所以显得"快"，是因为它被显存限制，被迫少看很多帧内容，而FramePack-U是在看了更多内容的前提下依然把计算量摁住了。

这套方法目前还有哪些短板

论文很坦诚地列出了几个局限。

第一，前面提到过，小模型未必能充分利用FramePack-U提供的丰富信息，这不是打包策略的锅，而是模型本身理解能力的天花板限制。

第二，FramePack-U目前最适配那种把视频拆成一帧一帧独立处理的模型架构。但有些较新的视频模型会把多帧打包成一个三维的时空网格统一处理，这种架构下想单独调整某一帧的分辨率就没那么容易，需要对视觉编码器做额外改造。

第三，用CLIP做相关性打分终究是个轻量级的代理方案，对于那种需要结合上下文才能理解的细微动作，或者需要推理才能判断重要性的线索，CLIP可能判断不准。

第四，不同的打包方案（也就是高低分辨率帧数的具体配比）在不同基准上表现略有差异，没有一个放之四海而皆准的最优解，这意味着实际落地的时候还需要针对具体场景做一些调优。

写在后面

读完这篇论文，印象最深的其实不是FramePack-U本身的架构设计，而是它对"压缩"这个词的重新定义。

过去提到视频压缩，大家默认的思路都是"丢掉一些东西"，无论是丢帧还是丢token，本质上都是做减法。FramePack-U的巧妙之处在于，它没有真的丢掉任何一帧，只是让不同的帧享受不同程度的"待遇"。这种思路其实在很多工程领域都能看到影子，比如视频压缩编码里的关键帧和中间帧区别对待，比如数据库里的冷热数据分层存储。信息处理这件事，可能从来都不是"留下还是丢弃"这种二元选择，而是"该给多少关注"的连续分配问题。

另一个让人印象深刻的细节是，论文花了相当大的篇幅去对比其他几个看起来思路相似的工作，比如SlowFast-LLaVA按固定帧率分配清晰度、Q-Frame用概率采样决定分辨率、LongVU依赖训练好的视觉相似度模型。这些方法要么是查询无关的、要么依赖额外训练、要么是分离式的两阶段设计。FramePack-U坚持用一个统一的贪心算法同时兼顾相关性和多样性，并且全程不需要任何额外训练。这种"少即是多"的工程哲学，在一个越来越依赖堆参数堆算力的行业里，显得格外朴素，也格外难得。

文章里那个把冰箱里的大象当标题的比喻，其实也在提醒我们一件更普遍的事：很多技术难题不是没人看见，而是大家都选择绕开它、给它披上一层又一层的遮挡布。真正解决问题的方式，有时候不是发明一个全新的冰箱，而是换一种装大象的姿势。

Q&A

Q1：FramePack-U是什么？

A：FramePack-U是一种训练无需微调的视频打包方法，能把任意长度的视频压缩进固定大小的视觉表示中，实现常数级的内存占用，可以直接插入现成的视觉语言模型使用。

Q2：FramePack-U和传统的关键帧选择方法有什么不同？

A：传统方法是硬性丢弃不重要的帧或token，会损失时间连续性。FramePack-U不丢弃任何帧，而是给重要帧更高分辨率、给次要帧更低分辨率，同时保留全部时间范围的信息。

Q3：FramePack-U对小模型和大模型的效果一样吗？

A：不一样。实验显示模型规模越大，FramePack-U带来的提升越明显，在27B模型上提升幅度远超4B小模型，这是因为小模型消化更多视觉信息的能力有限。