Thinking in Streaming Video¶

会议: ECCV2026
论文: ECCV 原文
代码: https://github.com/CASIA-IVA-Lab/ThinkStream
领域: 视觉语言推理（VLM Reasoning）
关键词: 流式视频、增量推理、语义记忆、回答时机、可验证奖励强化学习

一句话总结¶

ThinkStream 让视频模型逐片段“观察、思考、决定是否回答”，将历史推理保留为被淘汰视觉 token 的语义替代，并用流式 RLVR 联合优化答案与时机，使 Qwen2.5-VL-3B 在 OVO-Bench 的总分从 51.00 提升至 59.66。

研究背景与动机¶

离线视频问答通常先读完整段视频，再生成答案或较长的思维链；实时助手却不能等待录像结束，也不能让未来画面参与当前判断。随着视频不断到来，系统既要记住过去发生过什么，又要在事件出现时及时回应。直接把离线模型反复应用于越来越长的视频前缀，会同时增加视觉编码、注意力和生成开销；只保留最近几秒虽然便宜，却容易遗忘用户稍后才会询问的历史事件。

已有在线视频系统通过视觉记忆或 KV cache 压缩控制上下文，也有方法用分类头、事件触发器决定何时发言，但这些机制不一定维护显式、可连续更新的推理状态。本文关心的是一个更具体的结合点：当前生成的短推理能否同时服务于眼前的回答和未来的记忆？如果一段推理已把“人把砧板放在水槽旁”写入历史状态，旧画面的密集视觉 token 就不必一直存在；但普通逐片段字幕未必能表达事件关系，也未必知道何时已有充分证据回答。

因此，这里的目标不是给每帧附加一篇长解释，而是让有限的推理预算随视频分摊，并在训练中让状态更新与回答时机共同接受反馈。核心 idea：把短推理同时作为在线决策过程和历史语义记忆，只保留近期高密度视觉证据，再用可验证的答案、格式与时间奖励训练整个流式交互轨迹。

方法详解¶

整体框架¶

ThinkStream 以 Qwen2.5-VL-3B 为基础，输入用户指令、当前视频片段和已有历史状态。每个片段到来后，模型先生成简短的 <think>...</think>，再输出 <silent> 或带答案的 <response>；沉默意味着继续观察，不意味着这一轮没有更新记忆。

历史状态由近期视觉 token 与累计的推理、交互 token 共同组成，Reasoning-Compressed Streaming Memory（RCSM，推理压缩流式记忆）只驱逐超过视觉窗口的旧视觉 token。流式上下文 RLVR 在训练期间对完整交互轨迹施加反馈；高效流式后端负责实际执行可变长输入、解码和缓存驱逐。下图实线表示在线状态循环，虚线表示训练过程，奖励计算不是部署时额外调用的判断器。

%%{init: {'flowchart': {'rankSpacing': 24, 'nodeSpacing': 28, 'padding': 6, 'wrappingWidth': 400}}}%%
flowchart TD
    INPUT["新片段 + 指令"] --> LOOP["观察-思考-发言"]
    LOOP --> MEMORY["推理压缩流式记忆"]
    MEMORY -.->|训练轨迹| RL["流式上下文 RLVR"]
    DATA["冷启动轨迹 + 可验证标注"] -.-> RL
    MEMORY -->|在线缓存更新| ENGINE["高效流式后端"]
    RL -.->|训练后的策略| ENGINE
    ENGINE --> OUTPUT["回答或沉默"]
    ENGINE -->|下一片段沿用历史状态| LOOP

关键设计¶

1. 观察-思考-发言：将一次长推理改成连续的短状态更新

新片段触发的推理并非独立字幕，而是结合既有历史去解释新证据：它可以记下刚发生的事件、修正对正在进行的活动的判断，也可以补充时间先后或因果关系。输出的后一部分才是交互动作。这样，“看见新东西”和“现在应不应该对用户说话”在同一次自回归生成中衔接，不需要外部分类器先决定是否唤醒一个问答模型；没有必要回答时，模型仍可把有价值的观察写入自己的历史。

这里的因果约束是每一步只能访问当前及过去的片段，不能为了生成看似合理的解释而引用尚未到来的事件。推理也不是等问题出现才从头计算，而是沿视频时间逐渐积累；这使回答可以利用此前已经形成的理解。作者用每秒视频允许生成的最大推理 token 数限制额外开销，最终采用的 20 tokens/s 是推理预算，不是视频帧率，也不是模型每秒能生成的吞吐量。它约束的是每单位视频可以花多少文字去更新状态。

2. 推理压缩流式记忆：淘汰旧画面而保留对旧画面的解释

RCSM 维护一种混合 KV cache：最近一个滑动窗口内的视觉 token 继续保留细节，早期视觉 token 超窗后被驱逐，历次推理与交互动作对应的 token 则继续留在上下文。原文状态定义保留的是推理加动作，因此不能把它误读为只保存一段最新摘要，也不能理解成每次将全部历史重新压成固定长度文本。新推理本身依赖此前记忆，因此可以将“物体在哪”“某动作发生在什么之后”等关系沿时间传递。

这项设计的价值在于旧画面和旧事件不必同时消失：当前问题如果涉及过去，模型可以从保留的语义状态回溯，而近期细节仍可从视觉窗口中读取。代价是信息损失具有选择性；没有写入推理的颜色、文字或位置细节，视觉 token 被删除后未必可恢复。还要区分两种增长：视觉 token 数被窗口约束，推理 token 却仍随时间累计，只是增长较慢。因此本文实验支持所测视频长度内的低成本运行，并不在算法上证明任意长视频的总记忆严格恒定。

3. 流式上下文 RLVR：让状态更新同时接受答案和时机反馈

冷启动训练先教会模型生成带时间依据的短推理及交互格式，随后在真实的流式上下文中采样多条轨迹。每条轨迹逐片段运行，并使用 RCSM 管理历史，因此训练策略面对的也是“只能看到前缀、旧视觉信息会消失”的条件，而不是拥有完整录像的离线推理。作者采用组相对策略优化（GRPO），以同一实例的多条轨迹形成组内比较，并使用带裁剪和 KL 正则的标准优化目标；本地文本中的该目标公式抽取损坏，此处不将其猜补为作者的精确公式。

可验证奖励包含三部分：答案奖励检查是否匹配标准答案，格式奖励检查结构化输出协议，时间奖励检查实际回应与标注回应步骤的距离。为使答案能规则化核验，RLVR 数据限制为选择、是非和计数题，而不是用同一匹配规则评价任意自由文本。时间奖励的清晰文字定义如下，三个分量按正文说明相加；这种联合反馈是在轨迹层面间接鼓励有用的推理，并不是给每句推理都提供事实正确性的独立标签。

\[ R_{\mathrm{time}}=\max\left(0,1-\frac{|t_{\mathrm{resp}}-t_{\mathrm{gt}}|}{w}\right). \]

其中 \(t_{\mathrm{resp}}\) 为模型响应步骤，\(t_{\mathrm{gt}}\) 为标注步骤，\(w\) 为时间容忍窗口。越接近标注时刻，奖励越高；过早和过晚都会受罚，超出窗口后该项为零。这解释了为什么“答案最终正确”仍不够：流式助手提前猜中答案，也可能是不符合当前证据的行为。正文未给出 \(w\) 的具体数值，不能将记忆的 20 秒窗口当成这个奖励窗口。

4. 高效流式后端：保留手动驱逐能力，同时降低解码调度开销

RCSM 需要在持续生成期间按 token 类型和时间修改 KV cache。普通 transformers eager 实现允许这种操作，但频繁启动计算 kernel 会产生额外开销；作者认为已有高吞吐引擎不便直接容纳所需的自定义缓存更新。因此，他们把变长视觉输入的 prefill 留在 eager 模式，让解码和驱逐使用可重放的 CUDA Graph，并通过原位内存移动实现缓存维护。

这不是另一个决定答案内容的模型，而是执行同一流式循环的后端，也用于 RLVR 的在线轨迹采样。其分工与输入性质直接相关：新片段产生的 token 数量会变化，而反复解码及驱逐适合复用已捕获的执行图。工程加速与语义压缩各自解决不同开销，不能把后端的 tokens/s 加速比全部归因于“推理更短”。正文把更细实现交给附录，但指定缓存仅包含主文和参考文献，因此这里不补写内核、位置编码或批处理细节。

一个完整示例¶

沿用论文图 1 的厨房情境，可以把流程理解为四次连续更新，而不是四次彼此独立的视频问答。起初画面只有人在炉灶前活动，模型记录场景与动作，没有需要输出的答案，于是保持沉默。下一片段中人走向水槽，模型将新观察与此前烹饪活动联系起来，但这仍不能证明砧板被放在哪里。当用户问“我把砧板放哪了”，后续片段出现人在水槽旁处理砧板的证据，模型更新位置关系，再给出相应回答。再往后进入清理阶段，模型继续记录新的状态，而不必重复回答同一个问题。

如果相应厨房画面后来超出视觉保留窗口，砧板位置仍可能由保留的推理与回答 token 提供。但若用户追问一个当时没有被记录的细小图案，语义记忆就不能保证还原它。这个例子说明“沉默也更新状态”和“保留事件不等于无损保存画面”两点，并非新增的定量实验。

损失函数 / 训练策略¶

数据构建先用 PySceneDetect 切分场景，再由 Qwen3-VL-235B-A22B-Instruct 为片段生成密集描述。带时间戳的描述是后续指令与推理轨迹的事实依据，而不是部署时必须运行的大模型分支。指令组合覆盖实时对话、事件触发、连续输出三种交互模式，以及过去、当前、未来三种时间范围和七类内容语义，过滤后保留 39 种有效场景组合。最后合成逐时刻的推理轨迹，要求每条思考与回答符合其时间点可用的证据。训练规模为 110K 条冷启动实例和 9K 条可验证 RLVR 实例；开放问答可进入指令构建，但 RLVR 使用可确定核验的题型。

冷启动 batch size 为 64，学习率为 \(1\times10^{-5}\)；RL 阶段 batch size 为 8，GRPO 每组 8 条轨迹，学习率为 \(2\times10^{-7}\)。两阶段均用 AdamW，视频采样为 2 FPS，使用模型原生动态分辨率，在单节点 8 张 NVIDIA H20 GPU 上训练。作者在预算实验中选择 20 tokens/s，在视觉缓存实验中选择 20 秒窗口；这两个“20”分别控制文字生成量和近期视觉证据长度。

实验关键数据¶

主实验¶

表 1 摘录原文表 1、2 的评测分数，均越高越好。OVO 总分由实时视觉感知与历史回溯两部分汇总，StreamingBench 只报告 Real-Time 部分，不能当作整个基准所有能力的总分。正文未给出更细的数据划分及各基线统一的采样、硬件设置，因此它们是论文报告的基准比较，不是同资源控制实验。

模型	OVO 实时感知	OVO 历史回溯	OVO 总分	StreamingBench Real-Time
Qwen2.5-VL-3B	60.03	41.98	51.00	67.96
Qwen2.5-VL-32B	64.40	50.33	57.37	74.27
Streamo-3B	61.51	41.76	51.64	未报告
Dispider-7B	54.55	36.06	45.31	67.63
ThinkStream-3B	67.03	52.30	59.66	75.00

与同规模基础模型相比，OVO 总分增加 8.66 分；StreamingBench Real-Time 增加 7.04 分。后者高于原文报告的 GPT-4o 73.28，但低于 Gemini 1.5 pro 的 75.69，不能表述为全面超过闭源模型。离线任务的原始结果为 VideoMME 61.9、LongVideoBench 56.4，表明流式改造后仍保留一定离线理解能力。

消融实验¶

表 2 对应原文表 6，在 ThinkStream 的记忆表示与后训练变体之间比较。平均分是此处三列评测分数的平均，不是上表的 OVO 总分，也不是仅离线任务的平均。

记忆配置	StreamingBench Real-Time	OVO 历史回溯	OVO 实时感知	平均分
无记忆	69.6	41.8	59.2	56.9
离散字幕记忆	59.0	36.9	50.1	48.7
冷启动 CoT 记忆	70.6	47.6	63.3	60.5
RLVR 优化的 CoT 记忆	75.0	52.3	67.0	64.8

表 3 对应原文表 4，改变每秒视频的最大推理 token 预算。延迟按原文表格单位列出；正文没有完整交代该消融的计时粒度及单卡配置，不能直接解释成任意设备上的单帧延迟。

推理预算（tokens/s 视频）	StreamingBench Real-Time	OVO 历史回溯	延迟（ms）
0	69.6	41.8	130
5	70.2	46.9	193
10	72.3	49.7	255
20	75.0	52.3	380
30	75.0	52.6	505

关键发现¶

推理记忆不是简单的字幕拼接：离散字幕的平均分为 48.7，低于无记忆的 56.9；但这组实验不能单独证明所有字幕压缩方案都无效。
RLVR 将冷启动 CoT 记忆的平均分从 60.5 提升至 64.8，即增加 4.3 分；原文未进一步单独消融格式、时间和答案奖励，不能把增益全部归给时间奖励。
20 到 30 tokens/s 只让历史回溯增加 0.3 分，延迟却从 380 增至 505 ms。原文表 5 中，视觉窗口从 5 秒增到 20 秒使回溯分数由 46.7 升到 52.3，再增至 30 秒则为 51.6。
原文 §6.3 报告 batch size 为 1 时，定制后端与 eager 基线分别为 154.07 和 30.06 tokens/s；batch size 为 8 时分别为 766.87 和 276.10 tokens/s。图 4 在所测长度内报告端到端延迟低于 0.5 秒，但这不是无限长度或所有硬件的保证。

亮点与洞察¶

推理文字被复用为记忆，而不是生成后丢弃的解释。这样，推理成本同时服务于当前交互和未来历史回溯，但也要求关注错误推理被长期保留的风险。
沉默被纳入生成动作空间，回答时机与答案内容一起训练。这为需要等待证据的交互任务提供了可迁移的建模方式，而不必把“是否回答”完全交给外部触发器。
方法与后端的对应关系清楚：语义记忆减少视觉历史负担，CUDA Graph 减少循环执行开销。部署评估应分别度量二者，避免把算法收益与硬件优化混在一起。

局限与展望¶

作者明确以短推理和视觉窗口控制成本，但主文没有独立的局限性章节。上述效率结论来自有限范围的实验，不应扩展成对无限视频的严格复杂度结论。
笔记分析：历史推理持续累积，且视觉证据可能已被删除，早期错误有机会成为后续推理的前提。值得测试分层文本压缩、记忆纠错及少量关键画面保留，但这些不是本文已实现的组件。
笔记分析：时机学习依赖标注响应步骤和容忍窗口；开放式对话中可能存在多个合理回答时刻，而选择、是非、计数题的可验证奖励未必覆盖这些歧义。
数值边界：原文表 3 将 61.9 相对 61.5 的提升写成 0.8，将 56.4 相对 54.2 的提升写成 1.8；按所列原始值相减应分别为 0.4、2.2，本文不沿用这两项提升标注。表 6 的基础模型 StreamingBench 分数为 68.9，表 2 为 67.96，主文未解释设置差异。
复现边界：指定全文未包含正文所引用的附录，无法据此核对数据来源划分、完整提示词、时间窗口超参及后端实现细节。代码链接来自论文披露，本次未联网验证仓库内容。

评分¶

新颖性: 4/5。把在线推理、交互时机和记忆复用结合得较完整，但各基础技术已有前例。
实验充分度: 4/5。覆盖在线、离线、记忆、预算与效率，仍缺独立奖励消融及更长时域验证。
写作质量: 3/5。核心机制清楚，但数值提升标注与跨表基线不一致影响结论核对。
价值: 4/5。提供了紧凑流式视频助手的实用方向，真实长期部署仍需检查信息丢失和记忆增长。