2025年10月22日星期三

破解长视频理解困局!MIT&英伟达最新开源StreamingVLM :统一实时流式视觉语言理解框架

AI生成未来知识星球免费开放!

点击下方卡片,关注"AI生成未来"

👇扫码免费加入AI知识星球,如您有工作需要分享,欢迎联系:aigc_to_future

图片

作者:Ruyi Xu

解读:AI生成未来
图片

文章链接:https://arxiv.org/pdf/2510.09608
Git链接:https://github.com/mit-han-lab/streaming-vlm 
Demo链接:https://streamingvlm.hanlab.ai/

亮点直击

  • 训练与推理统一的流式架构: 通过重叠窗口全注意力SFT,将有限长度训练与无限长度推理自然对齐。
  • 高效KV缓存复用机制: 结合 attention sink、短窗口视觉缓存与长窗口文本缓存,实现低延迟、高稳定的实时视频理解。
  • 真实长时评测基准构建: 构建了首个平均时长超2小时的实时视频评测集 Inf-Streams-Eval,推动长时视频理解领域标准化评测。

总结速览

解决的问题

  • 具体困境
    • 无重叠时打断上下文连贯性;
    • 有重叠时重复计算过多,延迟高。
    1. 全注意力(Full Attention) → 计算与内存成本呈二次增长,无法处理长视频。

    2. 滑动窗口(Sliding Window) →

    3. 训练与推理不对齐 → 模型无法在短视频训练下泛化到无限视频流。

提出的方案

StreamingVLM —— 一个统一的实时流式视觉语言理解框架,核心思路是让训练过程与流式推理机制对齐。

  • 训练阶段(Streaming-aligned SFT): 使用短视频片段的全注意力训练,片段间存在重叠,以此模拟推理时的注意力模式,无需在超长视频上训练。
  • 推理阶段(Streaming Inference): 采用轻量、可扩展的 KV 缓存策略,包括:
    1. Attention Sink:长期保留关键状态;
    2. 短窗口视觉Token缓存:保持最新画面信息;
    3. 长窗口文本Token缓存:维持语言连续性;
    4. 连续位置编码(Contiguous Position IDs):确保推理稳定性。

应用的技术

  • 模型基座:Qwen2.5-VL-7B-Instruct
  • 训练数据集
    • Inf-Streams-Train(超过4000小时体育解说SFT数据集)
    • Inf-Streams-Eval(平均时长2小时的视频评测集,要求逐秒帧-文本对齐)
  • 训练策略:全注意力SFT + 重叠窗口,模拟流式推理
  • 推理优化:KV状态复用 + 分层缓存机制,实现低延迟持续理解

达到的效果

  • 性能表现
    • 在 Inf-Streams-Eval 上对比 GPT-4O mini,胜率 66.18%
    • 在 LongVideoBench 上提升 +4.30OVOBench Realtime 上提升 +5.96
  • 实时性能:在单张 NVIDIA H100 上实现 8 FPS 稳定流式推理
  • 泛化能力:即使未针对VQA微调,也显著提升视频问答能力

方法

模型和数据的方法部分包含三个组成部分: (1) 用于视觉-语言处理的推理方案,支持在无限视频上的低延迟更新; 
(2) 赋予 StreamingVLM 流式推理能力的训练策略;
(3) 提供长时、实时训练数据和新基准 Inf-Streams 的数据处理流程。

STREAMINGVLM 的推理方案

如下图 3 所示,StreamingVLM 推理结构。这些设计选择在保持与下图 1(c) 相当性能的同时,降低了计算量。

图片
图片

流式感知的 KV 缓存关键思想是在流式推理过程中,通过重用先前的状态来维护一个紧凑且稳定的 KV 缓存。随着新的视频帧到达,重用以下状态: (i) 一组文本汇聚(sink)token,包括系统和先前的文本,长度为 ; 
(ii) 最近文本 token 的长窗口,长度为 ; 
(iii) 最近视觉 token 的短窗口,长度为 
在图 3 中,缓存长度为 

通过这种结构,较旧的视觉 token 会首先被移除;早期文本仅在超出预算时才被移除。与重新计算先前 token 不同,这种非对称保留策略在保持生成连贯性的同时,保持了最低的计算量,其性能与带重叠的滑动窗口(图 1(c))相当。

连续 RoPE为了防止在移除后出现位置漂移,应用了连续旋转位置嵌入(RoPE)。当较早的 token 被移除时,后续和新进入的 token 的 RoPE 索引会被平移,以便其位置在数值上与最后保留的 token 连续。 一旦视频长度超过总窗口大小,有效的 RoPE 索引将停止增长并保持在一个有界范围内。这使得位置值保持在分布内,从而稳定长时流式推理。

当应用于使用三维位置嵌入的 Qwen-VL 系列时,我们使用连续的三维 RoPE。RoPE 索引仍然左移以保持连续;对于视觉 token,我们构建三维索引(时间、高度、宽度),并按三维规则组装,匹配交错的视觉-文本布局。

训练策略

为了在保持训练简单的同时,使模型具备图 3 中的流式推理模式,我们采用了重叠片段的全注意力策略(见下图 4)。图 4 左侧面板展示了推理时的注意力模式。在图 4 中,缓存长度与图 3 相同,即 

图片

在训练期间(图 4 中间面板),并不复制推理时使用的精确滑动窗口调度,而是将一个长视频流分割为连续的片段 ,每个片段长度为  帧,相邻片段  与  之间有  帧重叠()。

每个片段被视为一个训练实例,其中视觉和文本 token(V/T)以每秒 1 帧的间隔进行采样和交错。在一个片段内应用全注意力,即每个 token 都可以关注同一片段中的所有 token。

如图 4 右侧面板所示,这种重叠的全注意力监督与推理时的有效注意力模式——即注意力汇聚(sink)、最近文本的较长窗口以及最近视觉的较短窗口——高度近似。训练监督与测试时上下文的对齐,使模型学习到预期的时间新近偏好(recency bias),并在无需在计算量呈二次增长的超长上下文上训练的情况下实现稳定的流式行为。

重要的是,为了与推理时的调度保持一致,在每个训练片段中交错视觉和文本 token——而不是采用常见的"先视觉、后文本"的 VLM 结构。我们仅在与逐秒解说对齐的文本位置上计算损失;当某一秒没有解说时,我们在该位置插入占位符 token "...",同时保持交错的 V/T 布局。 这种监督方式教会模型与流同步生成——学会何时说话、何时保持沉默——从而在推理时赋予 StreamingVLM 可靠的流式解说行为。

数据处理流程

视频收集与语音识别

如下图 5 所示,从五种运动项目中收集了比赛视频:篮球、足球、冰球、棒球和美式橄榄球,包括 712 场篮球比赛、544 场足球比赛、402 场冰球比赛、399 场棒球比赛和 392 场美式橄榄球比赛。解说语言为英语。

图片

为了保证视频质量与读取速度,将视频分辨率限制在 360P–720P,帧率为 24 FPS。首先,使用 WhisperX 模型从这些比赛中提取实时语音(ASR),获得了一个包含超过 6000 小时视频及其实时解说的初始语料库。

数据清洗

在完整的解说视频中,通常包含许多无用片段,如广告和主持人独白。这些片段的视觉内容与 ASR 语义之间联系较弱,使模型无法从画面中推断内容。此外,ASR 模型有时会错误识别球员或球队名称。

因此,制定规则并使用 GPT 清洗这些数据。首先将一场比赛划分为 120 秒的片段,并将每个片段内的解说内容拼接起来,然后拆分为句子。使用该片段及视频标题(包括比赛时间和双方队伍)作为上下文,要求 GPT-5 模型根据规则作出决策,选项包括 "keep"(保留)、"delete"(删除)和 "edit"(编辑)每个句子。

  • "keep" 表示内容为比赛解说且正确;
  • "edit" 表示为解说内容但需要修改细节(如错误的名字),并返回修改后的完整句子;
  • "delete" 表示不符合要求的内容,不应出现在训练数据中。

对于保留的句子,时间戳与 ASR 结果一致;对于编辑的句子,将原句持续时间均匀分配给编辑后句子的每个词(由于一个句子通常持续约 3–5 秒,误差在可接受范围内)。在原始 ASR 数据中,46.32% 被保留,37.89% 被编辑,15.79% 被删除,最终形成了我们数据的原始视频-解说对。

SFT 与评测数据分段

对于训练集和验证集,按如下方式构建数据。在训练设置下,将视频分割为  秒的片段,并设置  秒的重叠。为确保每个样本中有足够的解说标签,我们要求至少有  个词作为最少词数筛选条件。片段之前的所有解说被视为先前文本。在训练过程中,从该先前文本中取出前  个 token 和最后  个 token,以匹配推理设置。

在评测中,创建了一个新基准 Inf-Streams-Eval。它包含 20 场完整比赛,平均长度为 2.12 小时。将每场比赛划分为 100 秒的片段,并选择其中至少包含 200 个词的片段。这些片段的解说被视为真实标签。为了评分,使用更大的模型(此处为 gpt-5)在两个模型输出之间进行投票,并可访问真实参考。获得更多投票(更高胜率)的模型被判定为提供更好的解说。

Inf-Streams-Eval 有两种设置:chunk 和 infinite,分别在后续表格中用 † 和 ∞ 表示。在前图 1 中,chunk 模式对应面板 (b),infinite 模式对应面板 (d)。对于无法进行无限推理的模型,我们将视频切分为多个 chunk;模型接收前文文本和当前 chunk 来生成字幕。对于支持无限推理的模型,模型在整个流上运行;我们保留其先前输出作为前文文本,并持续生成字幕直到视频结束。

高质量退火数据

上述数据集可以微调模型的实时视频理解能力。然而,它包含大量关于球队信息和赛季历史的内容;对于解说任务的人类体验而言,我们更希望模型提供对场上事件的实时解说。因此,我们创建了高质量退火数据。

首先在无重叠的情况下切分所有数据,要求每个片段长度为 16–64 秒,内部静音时间不超过 3 秒;每个片段还必须包含至少 (以秒为单位的持续时间)个词。跨所有比赛,我们共获得了 52,530 个新样本。随后,我们定义"实时解说"的标准。对于每个样本,我们使用 GPT-5 判断"实时解说"比例是否超过 80%,以决定是否保留。最终,仅保留了 14,786 个样本。后续实验(表 6)表明,在使用这部分数据进行微调后,模型的能力和解说质量得到了进一步提升。

实验

首先描述实现细节,然后在视频字幕生成和 VQA 任务上与强基线进行比较。接下来测试 StreamingVLM 的效率。最后,进行消融实验以更好地理解其行为。

实验设置

训练 从 Qwen2.5-VL-Instruct-7B 微调 StreamingVLM。

步骤 1:训练模型以学习无限流式推理模式。我们在自构建的 SFT 数据集(525K 个流式样本)以及 LiveCC 的 Live-WhisperX-526K(526K 个流式样本)上训练。
步骤 2:使用我们高质量的退火数据(14K 个流式样本,每个 16–64 秒,包含详细动作)来增强实时动作解说能力并提升人类体验。经过这两个阶段后,我们得到 StreamingVLM。总计算量约为 128 张 H100 天。

基线模型本文选择强基线与 StreamingVLM 进行比较。

在字幕生成任务中,使用 GPT-4o mini 展示解说能力,并使用 Livecc-7B-Instruct,它在 550 万个 YouTube 视频片段(30–240 秒)和 178K 个视频问答样本上训练,表现出良好的短视频解说性能。包括 ReKV,这是一种无需训练的强流式推理方法。

由于设计限制,GPT-4o mini 在 Inf-Streams-Eval 上仅在 chunk 设置下评测,而 StreamingVLM 使用 infinite 模式。LiveCC-7B-Instruct 在 chunk 和 infinite 两种设置下均进行测试。 在 VQA 任务中,我们使用 Qwen2.5-VL-7B-Instruct(StreamingVLM SFT 前的基础模型)来展示我们的 SFT 流程如何提升基础能力。

基准在多个任务上评估实时字幕生成与视频理解性能。

对于字幕生成,使用 Inf-Streams-Eval(平均长度 2.12 小时),测试长时解说能力;以及 LiveSports3K-CC 基准(49 种运动,416 个片段,每个≥10 秒)。

对于视频理解,在四个公开套件上评估 StreamingVLM:

  • VideoMME:多任务集合(问答、字幕、定位),涵盖短视频和长视频的一般理解;
  • MVBench:针对短片的细粒度能力测试(动作、物体、计数、时间顺序);
  • LongVideoBench:需要长时记忆和跨片段推理的长视频问答;
  • OVOBench:测试实时理解与流式感知的视频问答集。

准确率结果

字幕生成

首先在字幕生成任务上将我们的推理策略与 ReKV 进行比较。我们观察到一个无训练的 ReKV 悖论:未经过任务特定微调的模型表现较差,而经过特殊微调的模型(例如 StreamingVLM)依赖于固定的上下文格式,而 ReKV 的淘汰策略会破坏这种格式,常常导致没有输出。相比之下,StreamingVLM 的训练–推理一致性设计解决了这个问题。

图片

然后,在 LiveCC-3K-Sports-CC 和 Inf-Streams-Eval 上评估了 StreamingVLM、Qwen-2.5-VL-7B-Instruct 和 LiveCC-7B-Instruct。如下表1 所示,在 Inf-Streams-Eval 上,Qwen-2.5-VL-7B-Instruct 无法保持连续解说,因此表现较差。LiveCC-7B-Instruct 在分块推理下表现更好。下图6 进一步显示,短块会破坏连贯性;这些设计不支持无限推理,而使用长块时,很快会超出训练长度并导致退化。

图片
图片

相比之下,StreamingVLM 以无限模式运行;其长期记忆和流式视频感知能力使其具有明显优势,在解说质量上超过了 GPT-4o mini。下图2(所示图)展示了一个真实案例,其中 StreamingVLM 保持连贯输出、实时延迟和长期记忆,解决了无限视频流实时感知的核心挑战。在 LiveCC-3K-Sports-CC 上,StreamingVLM 也优于基线,展示了在不同长度视频上的稳定流式字幕生成能力。

图片

VQA

在四个 VQA 任务上评估了 StreamingVLM 及其基础模型 Qwen-2.5-VL-7B-Instruct。如下表3 所示,即使没有任何 VQA SFT,StreamingVLM 在所有任务上都优于基础模型,表明我们的 SFT 改善了通用视觉能力。OVOBench Realtime 测试模型对即时流式场景的理解。在这个流式感知任务上,StreamingVLM 提升了 5.96%。这突出了 Inf-Streams-Train 及我们训练策略的优势,增强了模型的核心能力。

图片

效率测试

如下图 7 所示,报告了图 1 中三种方法在无限解说下的每 token 延迟:分别是具有全注意力的 VLM、滑动窗口注意力(无重叠)、滑动窗口注意力(有重叠)以及 StreamingVLM 的推理策略,它们分别对应图 1 的面板 (a)、(b)、(c) 和 (d)。

图片

实时响应要求延迟低于虚线所示的固定阈值。全注意力很快超过限制并导致显存溢出(OOM)。滑动窗口(无重叠)需要较大的块以保持连贯性,因此显示出周期性延迟模式:在每个块的开始阶段,模型重建上下文,导致解说与过去内容不连贯;在块的后期,延迟急剧上升,无法满足实时需求。滑动窗口(有重叠)由于计算冗余,效率仍然较低。StreamingVLM 保持固定上下文长度并重用 KV,维持较低且稳定的延迟,并能在单个 NVIDIA H100 上以 8 FPS 支持实时解说。

消融研究

连续 RoPE

本文研究了连续 RoPE 索引的效果。由于训练时使用全注意力,训练中仅使用原生 RoPE。在推理时,比较了连续 RoPE 与原生版本。如下表 4 所示,原生 RoPE 在无限流上性能急剧下降,因为其索引增长过快并超出训练范围。将视频分割为 100 秒的块可以部分恢复准确率,但会损害长期连贯性。使用连续 RoPE 时,位置索引保持有界,因此模型能够在无限推理下保持性能不损失。

图片

滑动窗口与 Sink

首先验证训练过程中清除文本的价值。然后我们搜索  的最佳推理设置。

首先,下表 5 左表对注意力 sink 和文本窗口的长度进行了消融实验。这里  和  分别是训练和推理中保留的先前注意力 sink 和文本窗口的长度。我们取 SFT 数据的篮球子集并训练两个模型:一个使用文本清除( 和 ),一个不使用清除。在 Inf-Streams-Eval(篮球子集)上,我们根据各自匹配的策略(清除 vs 不清除)评估每个模型。表 5 左表显示,对于无限推理,清除先前的文本 token 很重要并能提升性能。

图片

接下来,研究不同的  选择。表 5 右表显示,16 秒的视觉窗口是一个不错的选择:它足够长以覆盖最近的动作,同时又足够短以保持高效。相反,将视觉上下文设为 0 秒会导致明显的性能下降,这验证了保留最近的视觉 token 对连续动作理解至关重要。

训练策略与数据集

本文研究了 SFT 数据和高质量退火数据的效果。SFT 数据集教会模型无限流式推理模式,而高质量退火数据进一步提升了解说质量。

SFT 策略 如下表 6 所示,采用重叠训练策略后,SFT 子集帮助模型适应交错的视觉–文本模式,并理解超长视频。与仅在 Live-WhisperX-526K 上训练的模型相比,在重叠 SFT 数据上训练的模型增强了对无限视频的感知,在 Inf-Streams-Eval 上相较 GPT-4o-mini 的胜率提升 +31.29,在 Livecc-Sports-3K cc 上相较 LLaVA-Video-72B-Qwen2 的胜率提升 +3.68。

图片

高质量退火数据 高质量退火数据专注于实时内容,并进一步提升了模型能力。如表 6 所示,我们比较了使用和不使用高质量退火数据进行训练的情况。可以观察到,在字幕生成和 VQA 基准测试上均有显著提升。

结论

StreamingVLM,一个统一的训练–推理框架,为现有 VLM 带来了实时流式感知能力。首先提出了一种高效的流式 VLM 训练策略和数据构建流程,两者共同提升了在流式任务和 VQA 上的性能。接着,在真实场景中展示了我们的推理设计如何实现实时视频理解,能够在单个 NVIDIA H100 上以最高 8 FPS 稳定解说超过 3 小时的视频。最后,发布了 Inf-Streams,一个新的 SFT 数据集和基准,用于测试平均时长超过 2 小时视频的秒级实时理解。总体而言,这项工作为实际场景中的部署铺平了道路。

参考文献

[1] StreamingVLM: Real-Time Understanding for Infinite Video Streams

技术交流社区免费开放

这是一个👉️完全免费👈️的高质量AIGC技术社群。

涉及 内容成/理解(图像、视频、语音、文本、3D/4D等)、大模型、具身智能、自动驾驶、深度学习及传统视觉等多个不同方向。这个社群更加适合记录和积累,方便回溯和复盘。愿景是联结数十万AIGC开发者、研究者和爱好者,解决从理论到实战中遇到的具体问题。倡导深度讨论,确保每个提问都能得到认真对待。

图片
欢迎扫码免费加入
图片



技术交流

加入「AI生成未来社区」群聊,一起交流讨论,涉及 图像生成、视频生成、3D生成、具身智能等多个不同方向,备注不同方向邀请入群!可添加小助手备注方向加群!

图片

没有评论:

发表评论

GitHub 淘到 1 个「AI 控制浏览器」插件,一句话帮你干活。

逛 GitHub 的时候,发现了一个浏览器自动化开源项目,是个 Chrome 插件。 对小白也挺友好的,分享一下。 这个叫 Nanobrowser 的开源项目,现状有 1 万多 Star。 安装后,就会 在你浏览器出现一个侧边栏,说句话它就可以操纵你的浏览器,帮助你完成任何你...