你有没有遇到过这种情况：手机相册里存了一段一小时的会议录屏，想让AI帮你总结重点，结果等了半分钟它还没开始“看”视频，真正的分析反而几秒钟就搞定了。
这不是你的网络问题，也不是AI太笨。这是一个被整个研究领域忽略了很久的秘密：处理长视频最耗时的地方，往往不是AI“思考”的那部分，而是视频解码的那部分。来自中佛罗里达大学、Meta和Axon的研究者们在一篇新论文里把这件事挖了出来，并且顺带发现了另外两个被长期忽视的问题。这三件事合在一起,让他们重新设计了一套处理长视频的方法，叫LoHi。
先说说这件事为什么重要。现在的视觉语言模型（能同时理解图片和文字的AI，比如你用手机问AI“这张截图里写了什么”背后那种模型）处理视频时有一个硬约束：能塞给它的“视觉token”数量是有限的。
视觉语言模型*：一种能同时处理图像、视频和文字的AI模型，比如Qwen、LLaVA这类，你给它一张图或一段视频加一个问题，它能用文字回答你。
视觉token*：AI把一帧画面切成若干小块后，每一块对应的一个数字向量，模型靠处理这些向量来“看懂”画面。帧数越多、分辨率越高，token数量就越大，而模型能处理的token总量通常有上限。
这个限制听起来很技术，但换个说法你就懂了。假设你的手机只能存1000张照片当相册，想记录一年的生活,你要么每天只拍3张(覆盖面广但细节少)，要么只拍30天但每天拍100张(细节丰富但漏掉大半年)。长视频理解面临一模一样的选择：要么采样很多帧但每帧分辨率压得很低，要么只挑几帧但每帧都是高清原图。
过去几年里，几乎所有做长视频效率优化的研究都在纠结同一件事：在“原始高分辨率”这个前提不变的情况下，到底该选哪些帧、该扔掉哪些视觉token。换句话说，大家默认了分辨率必须是满血状态，然后拼命在帧和token上做减法。这篇论文的研究者们觉得，这个默认前提本身就有问题。他们提出,还有两个完全没人碰过的维度：分辨率本身是可以拿来换帧数的，以及视频解码这个“前置工作”花的时间和候选帧池子大小挂钩，根本不是看最终喂给模型的token预算。
这篇论文没有一上来就扔出一个新模型，而是先做了一轮系统性的实验调查，从数据里提炼出三条经验教训，再用这三条教训反推出设计方案。这种“先观察、后设计”的思路,本身就值得说道说道。
密集低分辨率采样：一个反直觉的新配方
先说第一条教训，也是最颠覆直觉的一条。
研究者们在Qwen3-VL、VideoLLaMA3等多个模型上做了对比实验：在token预算完全相同的前提下，比较“16帧原始分辨率”和“256帧四分之一分辨率”这两种采样方式谁更强。
结果是,密集低分辨率碾压稀疏高分辨率。在Qwen3-VL-4B模型上,VideoMME基准测试提升了6.66个百分点，MLVU提升了10.47个百分点，LVBench提升了5.10个百分点。这个幅度不是误差范围内的波动，是实打实的全面胜利。
为什么会这样?你可以这样理解：如果你只给AI看16帧画面来概括一整段视频,就像让一个人通过翻看一本杂志里随机抽出的16页来理解整本书的剧情。哪怕这16页印刷得再清晰、字体再大,只要漏掉了关键的转折页,故事照样讲不通。但如果让他翻完全书256页，哪怕字印得小一点、要眯着眼睛看,至少不会漏掉任何情节走向。时间维度上的完整性,比空间维度上的清晰度，对理解“发生了什么”这件事更重要。
如果不这样做会怎样?论文里专门做了对照:固定分辨率在四分之一,只调帧数从16涨到256,VideoMME上每一个任务类别的准确率都在稳步上升,没有一个例外。这说明默认的“原分辨率、少帧数”配方,本质上是在系统性地丢失时间线上的信息,而且丢失的信息没办法靠把现有几帧拍得更清楚来弥补。
分辨率敏感性因任务而异:密集采样也有软肋
但事情没这么简单。如果密集低分辨率是万能解药,这篇论文写到这里就可以结束了。研究者们接着发现了第二条教训：不同类型的任务对分辨率的依赖程度天差地别。
他们把VideoMME的任务类型按“从满分辨率降到四分之一分辨率后掉分多少”来排序,挑出掉分最狠的两类:OCR(光学字符识别,也就是读视频里的文字)和属性感知(比如看清楚某个人物身上的细节特征)。这两类叫做“分辨率敏感型”任务,剩下的比如动作识别、时序推理,叫做“分辨率不敏感型”。
在同样的token预算下，64帧半分辨率和256帧四分之一分辨率这两种配置,在分辨率敏感型任务上出现了反转:高分辨率配置以72.7%对71.9%小胜;而在不敏感型任务上,高帧数配置以61.8%对58.5%明显领先。
这就好比你去医院体检,医生既要给你拍一张全身CT看整体结构(这时候你不需要每个毛孔都看得清清楚楚,看清骨骼轮廓和器官位置就够了),又需要在发现某个可疑阴影后,凑近用高分辨率设备仔细盯着那个点看(这时候模糊一点点都可能让医生误判)。如果只用一种分辨率设置贯穿始终,要么是拿着显微镜看全身(浪费,而且看不全),要么是拿着广角镜头看细节(看不清要命的那一点)。没有一个单一的(帧数,分辨率)组合能同时伺候好这两类需求,这是论文里一个很关键的结论:任何固定的全局配置,在至少一类任务上都是次优的。
被忽视的前端延迟：候选池子才是真正的开销大头
第三条教训,也是最容易被普通用户直接感知到的一条,回到了开头提到的那个场景:为什么AI“看”视频比它“回答问题”还慢。
这背后涉及视频编码的一个基础知识。现代视频编码器(比如H.264)不会把每一帧都存成完整的独立画面，而是把视频切成一组一组的“图片组”(GoP,Group of Pictures)。
GoP*：视频压缩技术里的一个基本单元,每组以一张完整的自包含画面(叫I帧)开头,后面跟着一串只记录“和上一帧比有什么变化”的差分帧(P帧)。
I帧*：一张完整、独立的画面,不依赖其他帧就能解码出来,通常出现在镜头切换或剧烈运动的地方。
这意味着什么?如果你想随机抽取视频中间某一帧,解码器没法直接跳过去拿,它得先把这一组最前面的I帧解出来,再按顺序把中间所有的P帧挨个解出来,才能拼出你要的那一帧。这就像你想看一本漫画书的第47页,但这本书是“连环画”形式,每一页都画的是上一页“改动了哪里”,你没法直接翻到第47页,必须从本章开头的完整画面开始,一页一页叠加变化,才能拼出第47页长什么样。
这个机制对那些需要“先密集解码全视频、再从里面挑关键帧”的方法(论文里叫decode-then-select,解码后筛选)是个灾难。它们为了建立一个足够大的候选帧池子,往往要按每秒一帧的密度先把整个视频解码一遍,这个解码时间是随着视频时长线性增长的。论文测了10分钟、30分钟、60分钟三种长度的视频,发现这种密集解码方式的延迟差距随时长越拉越大,在60分钟视频上达到了7.4倍的差距,而均匀采样固定256帧的方式,延迟几乎不随时长变化。
更扎心的是,这不是极端压力测试才会出现的现象。即便在VideoMME这种常规基准测试集上,这个延迟差距依然存在且显著。换句话说,很多论文在宣称自己“高效”的时候,只算了喂给AI模型的token数量这一笔账,完全没算前面这笔“为了选出这些token,我先得把整段视频偷偷解码一遍”的隐藏账单。
LoHi:把一个视频拆成两条流
三条教训摆在桌面上,研究者们顺势推导出了解决方案:既然密集采样重要、分辨率敏感任务需要局部高清、解码延迟又必须控制在固定预算内,那能不能设计一套机制,让这三件事不再互相打架?
答案是LoHi,全称是Low-resolution video + High-resolution images(低分辨率视频加高分辨率图像)。这个设计的核心思路说起来其实挺朴素:把“覆盖时间线”和“保留空间细节”这两件事彻底拆开,分别用两条独立的流来处理。
具体来说,LoHi会先在视频通路里跑一条密集但低分辨率的视频流(论文里叫Lo-V,Low-resolution Video),负责把整条时间线盖住,保证不漏关键情节。然后从这条Lo-V的帧序列里,挑出一小撮关键帧,以原始高分辨率重新喂给AI的图像通路,这条叫Hi-I(High-resolution Images),负责补齐那些需要看清楚细节的地方。
这两条流会通过一句自然语言提示词连接起来,告诉模型:“上面这段低分辨率视频提供了时间上下文,接下来这几张高分辨率图片是其中几个关键帧的放大版。”整个过程不需要重新训练模型,直接利用现成视觉语言模型里已经内置的视频处理和图像处理两条通路就能跑起来。
这个设计巧妙在哪里?现代主流视觉语言模型(比如Qwen系列)天生就有两套输入接口:一套是给视频用的,带有一种叫mRoPE的位置编码技术,能让模型知道“这一帧在时间轴上的第几秒”;另一套是给静态图片用的,每张图独立编码,不用管时间顺序。LoHi没有去改造或训练模型,而是顺势而为:密集低分辨率的部分走视频通路保证时序连贯,稀疏高分辨率的部分走图像通路保证细节清晰,两边互不干扰,模型的时间感知能力不会被打乱。
这就像公司年会要做一份年度总结报告。如果你把全年365天每天的工作日志事无巨细地打印出来堆在桌上,老板没时间翻完;但如果你只挑12张你自己觉得重要的照片拼成PPT,很可能漏掉老板真正关心的那个项目的转折点。更聪明的做法是:先用一页纸的时间线图表把全年大事按月列出来(低分辨率但完整),再针对其中三四个关键节点,各配一页详细的数据分析(高分辨率但局部)。老板既能看到全局走向,又不会在关键节点上缺信息。
论文里还专门验证了,这种拆分不会增加模型端的计算负担。因为Lo-V和Hi-I的token总数依然卡在和单流基线相同的预算内,真正节省下来的是解码阶段:原本要解码256帧原始分辨率画面才能凑够预算,现在Lo-V用128帧低分辨率加上从中挑出的几张高分辨率图,解码帧数直接砍半。
三种选帧策略:从免费的编码信息到语义感知的智能筛选
拆成两条流之后,还剩一个问题:Hi-I里那几张高分辨率图,到底该选哪几帧?论文给出了三种由简单到复杂的选帧策略,各有各的算盘。
最简单的叫LoHi-Uniform,就是从Lo-V的128帧网格里按固定间隔直接抽,不做任何计算,几乎零成本。
第二种叫LoHi-Anchor,利用的是前面提到的视频编码知识:I帧天然标记了镜头切换或剧烈运动的位置,往往就是信息量最大的地方。这个策略直接读取解码器里现成的I帧索引信息(不需要额外解码任何像素),找到离每个候选位置最近的I帧,把Lo-V网格里对应的帧换成它。这相当于白捡了一个语义信号:视频压缩算法本来就在悄悄帮你标记“这里发生了变化”,你只是顺手把这份免费情报利用了起来。
第三种是整篇论文里设计最精巧的,叫LoHi-SemDiv,用到了一种叫DPP的数学工具。
DPP*：全称行列式点过程(Determinantal Point Process),一种能同时兼顾“选出来的东西都重要”和“选出来的东西彼此不重复”的数学框架,常用在需要挑选多样化子集的场景。
CLIP*：一种能把图片和文字映射到同一个向量空间的模型,可以用来计算“这段文字”和“这张图”有多匹配。
LoHi-SemDiv的逻辑是这样的:Lo-V已经保证了时间线的完整覆盖,所以Hi-I的名额不需要再追求“覆盖全部”,而应该追求两件事,一是和用户的问题足够相关,二是彼此之间足够不一样。如果选出来的8张高清图里有5张画的都是同一个场景的轻微变体,那等于浪费了5个名额里的4个。DPP的数学性质刚好能同时兼顾这两点,靠一个叫“质量-相似度分解”的核函数,一边用CLIP算出每一帧和问题的相关性打分,一边惩罚彼此太像的帧组合。
这就像你去菜市场只有预算买4样菜做一顿丰盛的晚餐。如果你光图便宜,买回来的可能是4种做法差不多的青菜(虽然都挺实惠,但做出来的菜式单一);聪明的做法是在“这顿饭需要什么”这个前提下,挑4样互相搭配、口味层次不同的食材。DPP干的就是这个活:既要关联菜单需求(质量项),又要保证菜品之间不重样(相似度项)。
论文证明了用贪心算法去逼近这个DPP目标函数,能保证结果至少达到最优解的63%左右(数学上写作1-1/e,大约0.632),这是有理论保证的,不是碰运气。
实验效果:准确率涨了,延迟反而降了
说了这么多设计思路,到底管不管用?论文在VideoMME、MLVU、LVBench三个长视频基准上做了系统测试。
在Qwen3-VL-4B上,最强的LoHi-SemDiv版本在三个基准上分别拿到66.81%、74.38%、45.90%的准确率,相比原始的16帧满分辨率基线,平均提升了10.6个百分点,相比此前最强的效率优化方法BOLT,也还能再提升5.2个百分点。
更值得玩味的是,论文发现仅仅是密集低分辨率这一招(不加任何高清补充),就已经超过了此前所有专门设计的关键帧挑选方法和token剪枝方法的平均表现。这说明过去那些精心设计的选帧算法,可能一直在一个错误的起跑线上努力。
前端延迟方面,LoHi只需要解码128帧,是此前方法256帧的一半,首字响应时间(TTFT,Time to First Token)从5963毫秒降到3906毫秒。更戏剧性的对比发生在和token剪枝方法的较量里:像VisionZip、FlashVid这类方法,因为需要先对原始高分辨率画面完整跑一遍视觉编码器(ViT)才能决定剪哪些token,导致视觉编码这一步要花掉2486毫秒;而LoHi因为从一开始就用的是低分辨率输入,这一步只要195毫秒,整整快了12倍。
这里有个细节值得多说两句。论文还专门拿“直接缩小分辨率”和“先编码再剪枝”做了对比实验,发现在25%和50%的token预算下,简单粗暴的缩小分辨率策略,反而一致性地打赢了所有专门设计的剪枝方法,包括一个专门为极端低保留率场景优化的方法MMTok。这个结果有点打脸整个token剪枝这条技术路线:大家辛辛苦苦设计复杂算法去决定“哪个token该留哪个该扔”,结果不如老老实实把图缩小来得划算,原因是剪枝方法仍然得先在原始分辨率上跑一遍耗时的视觉编码,这笔账省不掉。
论文作者还提到一个解释:视频理解依赖的是画面之间连贯的空间和时间结构,剪枝会在不同帧之间挖掉不规则的区块,把这种连贯性破坏掉;而保留一个完整但分辨率较低的全局画面,比保留支离破碎的高清碎片,对理解动态场景更有价值。
这篇论文还做了不少额外的验证工作,比如在Qwen3-VL-8B、Qwen3.5-4B、VideoLLaMA3-7B、Qwen2.5-VL-7B、VideoChat3-4B等多个不同模型家族上重复实验,结论基本一致,说明这不是针对某个特定模型调出来的巧合结果。他们还设计了一种基于熵值的自适应触发机制,让简单问题只用低分辨率流就能回答,只有模型表现出“不确定”时才调用高清流,这样能在只调用三分之一次数高清流的情况下,基本追平全程使用高清流的效果。
三年后、五年后,这篇论文留下的这套“先把时间和空间维度拆开,再各自优化”的思路,很可能会和编码层面的优化技术(比如直接在压缩域做计算而不完整解码)结合起来,进一步压榨长视频理解的效率空间。论文里也提到,如果能把视频编码时顺便产生的那些中间帧(解码目标帧时必然会捎带解码出来的I帧和P帧)利用起来当作额外的候选池,解码预算甚至不用增加就能拿到更多免费情报。
写在后面
读完这篇论文,我印象最深的不是LoHi这个具体方法,而是它提醒我的一件事:很多时候我们以为自己在优化的那个指标,根本不是真正的瓶颈。
整个长视频理解领域过去几年都在死磕“怎么从一堆视觉token里挑出最有用的那些”,论文一篇接一篇地刷新选择算法的精巧程度,但很少有人停下来问一句:这些token是怎么来的?把视频变成候选帧池子这一步,到底花了多少时间?这篇论文翻出来的数据很直接,7倍的延迟差距,这不是一个可以忽略的小尾巴,这是整个用户体验的瓶颈所在。
另一个让我多想了一会儿的地方是,简单缩小分辨率居然打赢了精心设计的剪枝算法。这多少说明了一件事:有时候一个领域里大家默认不去碰的那个前提假设(这里是“分辨率必须保持原始状态”),可能才是真正限制大家的那道枷锁。一旦有人松动了这个假设,很多原本看起来很复杂精巧的解法,反而显得笨重了。
还没解决的问题也挺有意思。论文里提到,分辨率敏感和不敏感这两类任务目前是靠人工在基准测试集上统计掉分幅度来划分的,那有没有可能让模型自己在推理过程中实时判断“这道题需要我放大看细节吗”,而不是靠一个固定的Hi-I数量K?如果真能做到这一步,那前面提到的熵值触发机制可能只是个开始。
下次你的手机AI助手卡在“正在分析视频”那个转圈圈的界面时,不妨想一想,它可能不是在思考,只是在一帧一帧地啃那些你根本用不上的像素。
Q&A
Q1：LoHi是什么？
A：LoHi是一种训练免费的长视频理解框架，它把视频拆成两条流处理：一条密集但低分辨率的视频流负责覆盖整个时间线，一条稀疏但高分辨率的图像流负责补充关键细节，两条流通过文字提示连接后喂给同一个视觉语言模型。
Q2：为什么密集低分辨率采样比稀疏高分辨率采样效果好？
A：因为长视频理解更依赖时间线的完整覆盖，稀疏采样容易漏掉关键情节，即使画面更清晰也补不回丢失的时间信息。实验显示在相同token预算下，256帧低分辨率比16帧原始分辨率在多个长视频基准上平均提升超过10个百分点。
Q3：为什么视频解码延迟会成为长视频AI理解的瓶颈？
A：因为很多关键帧挑选方法需要先把整段视频按每秒一帧的密度密集解码一遍才能建立候选池，而视频编码采用分组结构导致解码任意一帧都要先解码所在组的起始帧，这个过程耗时随视频时长线性增长，在一小时视频上能比固定帧数采样慢7倍以上。
