ShallowStream：给视频流理解装一个"浅层雷达"，别让每一帧都跑满全部大脑

你有没有想过，一个能实时看视频、随时回答问题的AI助手，到底需要付出多大的计算代价？

想象你雇了一个私人助理，专门帮你盯着家里的监控摄像头。这个助理有个怪癖：每秒钟看到的每一帧画面，他都要闭上眼睛，把这帧画面从头到尾在脑子里过一遍完整的思考流程，就像在做一道复杂的数学题。哪怕这一帧画面里什么都没发生，只是空荡荡的客厅。你觉得这个助理能撑多久？他的脑子会先累垮，还是你的电费单先爆炸？

这其实就是当前视频流理解AI面临的真实困境。

**核心问题：视频一直在流，但问题很少来**

先弄清楚一件事：所谓"流式视频理解"，跟你平时看的那种"完整视频先下载好再问问题"的模式完全不一样。

离线视频理解*：指AI在回答问题之前，已经拿到了完整的视频文件，可以随意翻看前后内容。

流式视频理解*：指视频像水龙头一样一帧一帧地流进来，AI没法预知未来会发生什么，也不知道用户什么时候会突然提问，必须边看边处理。

这两者的根本区别在于时间的不对称性。摄像头24小时不停地拍，但你可能十分钟才问一次"刚才那个人拿了什么东西"。这就意味着，AI系统绝大多数时间是在"看"，只有极少数时刻是在"答"。既然"看"占了绝对多数的工作量，那处理每一帧画面的成本，就成了整个系统最要命的开销。

现有的做法大多是这样的：来一帧，就让这一帧完整地穿过整个Transformer模型的所有层，从第一层算到最后一层，生成对应的键值缓存。

KV缓存*：Transformer模型处理信息时，每一层都会为输入内容生成一组叫做Key和Value的中间数据，模型靠比对这些数据来"记住"之前看过的内容，层数越深，缓存量越大。

这套做法有个致命问题。论文里提到，一个基于Qwen3-VL-8B的模型有28层，LLaVA-OneVision-7B有32层。如果每一帧都要跑满全部层数，计算开销随着深度线性增长，KV缓存也跟着线性膨胀。后续研究者想了很多办法去压缩、去修剪这些缓存，试图省内存，但问题是：算都已经算完了，钱已经花出去了，你现在压缩的只是"存储成本"，没有省下"计算成本"。

这就好比你已经花大价钱把一整栋楼装修完了，然后发现只用得上一楼，于是开始琢磨怎么把二楼到十楼的家具卖掉换钱。省是省了一点，但装修那笔钱早就打了水漂。

除了计算浪费，还有另一个更棘手的矛盾：怎么在"保留足够的历史证据"和"不撑爆内存"之间找平衡。

如果你狠心地把旧的视频信息压缩、合并甚至直接扔掉，那万一用户十分钟后突然问"三分钟前门口是不是有个可疑的人"，你就傻眼了，因为那段记忆已经被你自己删了。可如果你什么都不删，完整保留所有历史状态，内存很快就会爆炸，还得依赖速度很慢的外部存储搬运数据。

这两难局面，论文作者称之为"有损的证据缩减"问题。还有第三个麻烦：查询的时候到底要不要翻旧账。有些方法选择"每次提问都把整个历史搬出来看一遍"，这样虽然不会漏掉证据，但会拖慢反应速度，还可能干扰AI对当前画面的判断。另一些方法则选择先做一次完整的推理，判断"这个问题需不需要翻旧账"，判断完了如果需要，再做第二次推理去真正回答。这种"先蒙眼猜一次，猜完了再睁眼算一次"的做法，本质上是拿一次完整的大脑运算去换一个"是否需要用大脑"的判断，听着就有点浪费。

那么问题来了：有没有可能，AI不需要用完整的大脑深度，就能判断出"这个问题该不该翻旧账，旧账里哪些片段值得翻"？

作者团队做了一个很关键的实验，答案是肯定的。

**核心发现：浅层大脑已经够用了**

研究者们做了一个对照实验，在LVBench这个长视频理解基准上，只改变"用哪一层的表示去做视频和问题的匹配打分"，其他部分全部固定不变。

结果相当出人意料。对Qwen3-VL-8B这个总共28层的模型来说，只用第4层的表示去做检索，效果就已经和用更深层几乎一样好，甚至在某些点上表现更佳；对LLaVA-OneVision-7B这个32层的模型，第3层就够了。

这跟很多人对深度学习的直觉是相反的。通常我们会觉得，网络越深，学到的语义信息越高级、越抽象，理解能力应该越强。但这个实验说明，至少在"从一堆历史视频片段里找出和问题相关的那几个"这件事上，浅层网络的表示已经足够精准了。这跟此前一些针对语言模型的研究发现是呼应的：浅层和中间层的表示，有时候反而包含更丰富的语义信息，深层网络更多是在为最终生成任务做进一步的抽象和整合。

而与此同时，计算成本却是随着层数深度不断线性攀升的。也就是说，检索能力在第4层就已经封顶，但如果你非要用到第19层甚至更深，只是白白多花钱，收益却几乎没有增加。

这个发现直接催生了ShallowStream的核心设计思路：既然浅层就能做检索，那就把"看视频、建索引"这件高频发生的事，全部丢给浅层网络去做；把"深度理解、生成答案"这件低频发生的事，留给深层网络，而且只对被检索出来的那一小撮相关片段去做。

这就像是给一个大型档案馆配了两套人马。第一套人马是巡逻保安，他们不需要懂档案里的专业内容，只需要扫一眼每份新进档案，记下关键词和存放位置，速度极快，人数少，成本低。第二套人马是专家研究员，平时闲着，只有当真的有人来查阅某份具体档案、需要深入分析内容时，才会被叫出来，仔细钻研那几份被保安标记出来的档案。如果没有保安这一层筛选，你就得让专家团队天天守在门口，对着每一份新进档案都逐字逐句精读一遍，档案馆的运营成本会直接失控。

**方法拆解一：浅层编码，只留一半的活给深层**

ShallowStream把整个语言模型Transformer分成两段。

浅层MLLM*：模型前面若干层，索引边界记为P，负责给每一帧视频建立可检索的浅层索引。

深层MLLM*：从边界P往后的所有层，只在真正需要深度理解和生成答案时才被激活。

在持续的视频流处理阶段，每来一个视频单元（Qwen3-VL用2帧一组，LLaVA-OneVision用1帧一组），系统只让它过浅层的P层，产生浅层的KV缓存，然后就此打住，不再往深层送。

这一步直接把每帧的计算量从原本的L层砍到P层。以Qwen3-VL-8B为例，P取5，L是28，相当于每帧只跑了不到18%的层数。文章开头提到的52.1倍单帧预填充提速，很大程度上就来自这个设计。

但这里有个巧妙之处：系统同时还保留了每个视频单元最初、还未经任何Transformer层处理的原始视觉编码。这意味着，如果将来某一帧被检索命中，需要深度处理，它可以直接从第0层重新完整地跑一遍全部L层，而不是从浅层的中间状态"接着往下算"。这保证了最终生成答案时用到的表示是完全一致、干净的全深度表示，不会因为"半路接力"引入误差。

**方法二：全历史浅层索引，让记忆一直在线**

光有浅层编码还不够，得让这些浅层信息能被将来的查询检索到。ShallowStream为此维护了一个全历史的浅层缓存，把所有观察过的视频单元在每一个浅层的KV都保留下来。

这个缓存被分成两块：最近的N个单元构成"近期区"，永远保持在场，用来保证AI对当前画面的即时感知不受影响；更早的单元构成"历史区"，只有当问题确实需要回溯历史时才会被调用。

这个设计背后的逻辑，其实就是解决前面提到的"每次提问都翻旧账会干扰当下判断"的问题。想象你在开车，副驾突然问你三天前某次旅行住的酒店名字。如果你非得把大脑切换到"回忆模式"去翻找那段记忆，哪怕只有一两秒钟，也可能让你错过眼前突然变道的车辆。ShallowStream的做法相当于给你配了个副驾专属的"回忆助手"，需要查旧事的时候由它去翻，你自己始终盯着路。

当历史积累得太多，内存实在扛不住的时候，还有一个可选的压缩机制：长聚类压缩。

长聚类压缩*：把时间上相邻、内容相似的旧视频单元合并成一个"代表"，用运行平均的方式更新这个代表的KV缓存和视觉表示，从而把内存占用控制在一个固定的预算范围内。

这就好比你整理旧照片，不会把十年前每一天拍的照片都单独留着，而是把同一次旅行的几十张照片合并成一本相册，挑一张封面代表这次旅行。查的时候，你先看相册封面，觉得有必要再翻开细看。实验数据显示，开启压缩后，即便观察的视频帧数从64帧涨到1024帧，模型占用的GPU显存几乎维持在18GiB左右不怎么变化，而不开压缩的版本会涨到21.76GiB，对比基线方法HERMES和OASIS在长视频下的显存需求还要更高。

**方法三：查询时的两道关卡，先判断要不要翻旧账，再决定翻哪一页**

真正的问题来了。当用户提问的那一刻，AI要做出两个判断：这个问题需不需要历史证据？如果需要，该翻哪几段？

ShallowStream设计了一个叫查询逻辑门的轻量级机制来处理第一个判断。

查询逻辑门*：把用户的问题套进一个固定的提示模板，模板里给出两个选项，A代表"需要更早的视频记忆"，B代表"最新片段就够了"，让模型只做一次纯文本的前向计算，比较A和B两个候选词的输出概率高低，概率差超过一个阈值就判定需要检索。

这个设计最妙的地方在于，它完全不需要真的去处理任何视频画面，只是一次极其轻量的文本推理，就能完成路由判断，避免了此前一些方法"先做一次完整推理来判断要不要检索，再做第二次推理真正回答"的双重浪费。

如果没有这道关卡会怎样？论文里的消融实验给出了直接对比：一种极端是所有问题都只用最近上下文，不做检索，另一种极端是所有问题都强制检索。前者在需要回溯的问题上必然丢分，后者会把大量无关的历史片段硬塞进去干扰当前场景判断，整体质量都不如经过校准的动态门控。数据显示，最终版本的门控机制在面对"回溯型"问题时检索率高达48.7%，而面对"实时视觉感知"型问题时检索率只有4.9%，说明这套机制确实学会了区分两类问题的本质差异。

判断完"要不要翻"，第二道关卡是"翻哪几页"，这里用到了一套组合拳。

第一步是浅层Q-K token打分。系统重建问题最后一个token和历史候选视觉token之间的注意力分数，在每一层浅层网络里都挑出得分最高的一批token。

第二步是跨层投票。一个历史视频单元里的某个token，如果在多个浅层里都被选中，就能为这个单元累积"票数"，票数越高说明这个单元和问题越相关。

第三步是最大最小多样性选择。单纯按票数排序容易选出一堆内容高度相似的片段，比如问题问"红白格子的地毯在哪"，模型可能反复选中好几个角度差不多的厨房画面，却漏掉了真正藏着地毯的那个房间角落。最大最小选择法先挑出彼此距离最远的一对候选，然后每次都加入与已选集合"最小距离最大"的那个候选，直到凑够所需数量，从而强迫结果覆盖更广的时间和空间范围。

论文里有一个很直观的案例研究，图示对比了三种检索策略在同一个问题上选出的八个历史片段。只用池化的Q-K相似度，选出的全是相似的厨房场景，最终预测错误；加上多样性选择后，虽然覆盖的时间范围变广了，但选择逻辑仍然被同一个相似度信号主导，答案还是错的；只有当token投票和多样性选择结合起来，才真正选出了覆盖房间不同角落的互补证据，最终答对了正确选项。这说明检索质量的提升，不能只靠"让候选更分散"，还得先保证"候选本身就是和问题真正相关的"。

打个比方，这就像你去图书馆找资料，光靠"随便从不同书架各拿一本书"是没用的，你得先确定哪些书和你的问题真的相关，再在这些相关的书里保证覆盖不同角度，两者缺一不可。

选定要用的历史证据之后，系统会把这些片段最初保留的、未经处理的原始视觉状态拿出来，连同问题一起，完整地跑一遍全部L层深度网络，生成最终答案。整个流程里，只有被选中的那一小撮证据享受了全深度计算的待遇，绝大多数没被选中的历史内容始终只停留在浅层索引状态，从未被昂贵的深层网络碰过。

**实验结果：性能不掉线，速度飞起来**

在OVO-Bench这个专门区分"实时视觉感知"和"回溯追踪"两类能力的基准上，基于Qwen3-VL-8B的ShallowStream拿到了69.5的整体平均分，和当前最强的对比方法OASIS的67.7几乎持平，甚至略高。基于LLaVA-OneVision-7B的版本拿到62.2分，超过了同背景下的HERMES（58.1）和SimpleStream（60.3）。

在更贴近日常连续视频场景的StreamingBench上，Qwen3-VL-8B版本的ShallowStream达到78.2分，同样领先HERMES的76.6分和SimpleStream的76.5分。

效率方面的对比更能说明问题。在NVIDIA RTX 5090单卡、每10秒一次查询的对齐测试协议下，ShallowStream相比HERMES和OASIS，把单帧预填充延迟和端到端延迟分别降低了最多52.1倍和11.9倍。在实时性压力测试里，作者进一步把持续视频流的处理开销和查询计算合并计算，在每80秒查询一次的条件下，ShallowStream只需要约2.6秒计算，而HERMES需要6.2秒，OASIS更是需要50.4秒，几乎逼近实时处理的临界线。

| 方法 | 主干模型 | OVO-Bench均分 | StreamingBench均分 |

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

| HERMES | Qwen3-VL-8B | 57.2 | 76.6 |

| OASIS | Qwen3-VL-8B | 67.7 | — |

| SimpleStream | Qwen3-VL-8B | 66.4 | 76.5 |

| **ShallowStream** | Qwen3-VL-8B | **69.5** | **78.2** |

这张对照表说明了一件事：ShallowStream并没有靠牺牲准确率来换取速度，而是通过一开始就避免浪费计算，从架构层面同时获得了两者。

追根溯源，这个思路并不是凭空出现的。它建立在几条此前的研究脉络之上：ReKV提出了在上下文中检索完整视频KV缓存的思路，为后续的检索式流式方法奠定了基础；HERMES把KV缓存组织成分层记忆结构，用来控制缓存规模；OASIS和WeaveTime则率先探索了"按需触发历史检索"而非每次都翻旧账的思路。ShallowStream可以看作是在这些工作基础上，把"该不该检索"和"检索什么"这两个决策，从原本依赖完整深层推理的重活，下放到几乎免费的浅层计算和文本级门控上，同时把"证据存储"这一步也从全深度状态压缩成浅层状态，从而在计算图的两端同时做了减法。

值得一提的是，作者在实验里还专门验证了检索深度边界P取5这个选择是否真的最优。在OVO-Bench的回溯类问题上做了一次完整的深度扫描实验，从P等于1一路测到P等于19，结果显示P等于5时准确率最高，达到58.27，继续加深到19层反而没有额外收益，但单帧预填充耗时却要多出31%。这个结果印证了前面LVBench上的初步观察，也说明这个浅层边界的选择不是拍脑袋定的，而是有交叉验证支撑的稳健结论。

写在后面

读完这篇论文，我最有感触的地方其实不是那些漂亂的加速倍数，而是那个层级实验本身。它揭示了一个容易被忽略的事实：我们总是默认"更深的网络等于更强的能力"，但检索和生成其实是两种性质完全不同的任务。检索本质上是"匹配"，判断两个东西相不相关，这种能力可能在网络学习的早期阶段就已经稳定下来了；而生成答案需要综合、推理、组织语言，这才是真正需要深度堆叠的地方。把这两种任务混在一起，用同一套深度标准去要求，本身就是一种资源错配。

另一个让我意外的细节是，那个查询逻辑门的设计几乎没有引入任何额外的训练成本。它直接复用了预训练模型自带的输出概率分布，只靠几个示例和一个校准好的阈值就完成了路由判断，甚至这个阈值还是在一个和最终测试基准完全无关的合成数据集上单独校准的，避免了针对某个具体测试集调参的嫌疑。这种"少即是多"的克制感，在一个动辄追求更复杂架构的领域里显得挺难得。

这篇论文没有解决的问题也很明显：浅层检索的可靠性边界在哪里？如果问题涉及的关键证据在浅层表示里根本没有留下足够的痕迹，比如需要理解极其细微的动作变化或者长时间跨度的因果关系，浅层的注意力分数还能不能撑住？这大概是接下来值得追问的方向。

Q&A

Q1：ShallowStream是什么？

A：ShallowStream是一种流式视频理解框架，它只用多模态大模型的浅层网络去持续编码视频流并建立检索索引，只有在用户提问且确实需要历史证据时，才对被检索出的少量片段启动完整深度的模型计算，从而大幅降低持续处理视频的计算和延迟成本。

Q2：ShallowStream比现有方法快多少，效果会不会打折扣？

A：在长视频场景下，ShallowStream相比HERMES、OASIS等方法把单帧预填充延迟降低最多52.1倍，端到端延迟降低最多11.9倍，同时在OVO-Bench和StreamingBench上的准确率与目前最强的流式方法基本持平甚至略优，没有出现明显的性能牺牲。

Q3：为什么浅层网络就能完成视频检索任务？

A：论文通过实验发现，在28层或32层的模型中，仅使用第3到第5层的表示做视频与问题的匹配打分，效果就已经接近甚至超过使用更深层的效果，说明浅层和中间层网络已经包含足够丰富的语义信息来支持检索匹配，而检索能力并不会随层数加深继续显著提升。