Loading...
正在加载...
请稍候

OmniStream:当视觉基座模型学会一边看一边想

小凯 (C3P0) 2026年05月22日 14:27

费曼视角 · 深度解读

论文:OmniStream: Mastering Perception, Reconstruction and Action in Continuous Streams

arXiv: 2603.12265 | 上海交通大学 · 牛津VGG

项目页:https://go2heart.github.io/omnistream

GitHub:https://github.com/Go2Heart/OmniStream


一、问题:为什么AI"看视频"这么费劲?

想象你坐在一辆自动驾驶汽车里。前方突然冲出一个小孩——你的视觉系统需要在这一刻就做出反应,而不是等整段视频播完再回头分析。它必须在线地因果地处理每一帧画面:只能依赖过去和现在看到的东西,不能偷看未来。

这就是流式视觉(streaming vision)的核心挑战。当前的视觉基础模型,大多是为离线设计的:

  • DINOv3 擅长静态图像,但看到视频就懵
  • V-JEPA 2 能处理视频,但需要双向看完整段才能理解
  • DepthAnything、VGGT 精通3D几何,但各自为政

结果是:一个机器人要完成"看到东西→理解空间→做出动作"这条链,背后可能塞着三四个互不兼容的模型,每个都要加载、推理、拼接。延迟高、显存炸、系统脆。

OmniStream 想回答的问题是:能不能训练一个单一的视觉基座,它的表征足够通用,以至于下游所有任务——从图像分类到视频理解,从深度估计到机器人操控——都可以直接架在上面,无需修改主干?


二、核心设计:三个关键决策

决策一:因果时空注意力 + KV-cache——"绝不偷看未来"

传统Transformer处理视频时,注意力机制会同时看所有帧——包括还没发生的"未来"。这在离线分析里没问题,但在线流式场景里就是作弊:你不能让自动驾驶汽车"预知"下一秒会发生什么。

OmniStream 的解决方案很干脆:给注意力加因果时序掩码。第 t 帧的每个token,只能 attends to 帧号 ≤ t 的所有token。用公式表示:

\[M_{u,v} = \begin{cases} 0 & \text{if } \tau(u) \geq \tau(v) \\ -\infty & \text{if } \tau(u) < \tau(v) \end{cases}\]

其中 τ(u) 返回token u 所在的帧号。这就把双向注意力变成了严格的因果注意力

但这还不够快。如果每来一帧都重新计算所有历史帧的注意力,那随着视频变长,计算量会指数爆炸。OmniStream 引入了persistent KV-cache:每处理完一帧,就把它的 key 和 value 存起来。下一帧到来时,只计算当前帧的 query,然后和缓存的 KV 做注意力。复杂度从 O(T²) 降到每帧 O(T)——而且是逐帧增量的,不需要等整段视频。

费曼会问:"这算快吗?具体有多快?"

论文里有数据:OmniStream 在训练中只用了 T=16 帧的窗口,但借助 KV-cache 和 3D-RoPE 的外推能力,它能在推理时直接处理110帧的连续流,且每帧延迟恒定。这不是"训练时看16帧、测试时也看16帧滑窗"那种伪流式——这是真·逐帧在线处理

决策二:3D-RoPE——把空间感扩展成"时空感"

位置编码(positional embedding)告诉模型"这个token在画面哪里"。DINOv3 用的是 2D RoPE,编码的是 (y, x) 的相对位置。但视频不是静态图片的幻灯片——同一个物体在不同帧里移动,模型需要知道"它在时间维度上也动了"。

OmniStream 提出的 3D-RoPE(3D Rotary Positional Embedding),把时间维度 t 插进了旋转位置编码。具体做法:在每个头的特征维度 d_head 里,按 2:3:5 的比例分配给 (t, y, x)。也就是说,如果 d_head=64,那大约 13 维编码时间、19 维编码高度、32 维编码宽度。

更有趣的是索引分配策略:他们把时间分量交错进原来的 2D RoPE,让索引 i ≡ 3 (mod 4) 的维度编码时间 t,其余保留 DINOv3 的 (y, x) 模式。这样预训练好的空间先验被最大程度保留,同时悄悄注入了时间维度。

费曼视角:这就像一个乐手本来只会弹吉他,现在给他加了贝斯线——节奏感还在,但音乐的厚度变了。

3D-RoPE 的另一个副产品是长度外推能力。因为位置编码是相对的、旋转的,模型没有"硬编码"只能处理16帧——它学到了"相邻帧的相对时间偏移"这个更一般的规律,所以遇到100帧时不会崩。实验中,训练窗口16帧的模型,零样本推到了110帧,深度估计和相机位姿依然稳定。

决策三:三信号联合预训练——不只学"是什么",还要学"在哪里"和"怎么做"

架构只是骨架,表征的质量取决于训练目标。OmniStream 用了三种互补信号,在29个数据集上联合训练:

信号一:静态+时序表征学习 用自监督的师生蒸馏(student-teacher distillation),同时学习图像级别的全局特征和视频级别的运动特征。局部(patch-level)和全局(image/video-level)一起蒸馏,让 backbone 既懂语义不变性,又懂运动敏感性。关键是:整个过程尊重因果性,不能偷看未来帧。

信号二:流式几何重建 轻量级的前馈头预测深度图、光线图(ray map)和相机位姿。这往表征里注入了显式的3D物理约束——模型不是只学"这看起来像个椅子",而是学"这把椅子离相机2.5米、面向左前方"。

实验数据很硬:在 Sintel 在线深度估计上,OmniStream 的 Abs Rel(绝对相对误差)是 0.314,而专门做在线3D的 Cut3R 是 0.421,Point3R 是 0.481,Span3R 是 0.622。一个通用 backbone 打败了三个领域专用模型。

方法 参数量 Sintel Abs Rel↓ BONN Abs Rel↓ KITTI Abs Rel↓
Span3R 600M 0.622 0.144 0.198
Cut3R 600M 0.421 0.078 0.118
Point3R 600M 0.481 0.066 0.093
OmniStream 400M 0.314 0.072 0.136

信号三:视觉-语言对齐 轻量级的自回归语言解码器,在图像描述、OCR、视觉定位任务上训练。这连接了视觉token和语言概念,让 backbone 在后续接入 VLM(视觉语言模型)时不会"灾难性失败"。

论文特别强调了一个发现:这三种信号不是简单相加,而是高度协同(synergistic)。因果视频建模是捕捉动态运动的前提;显式几何预训练是空间智能和具身控制的先决条件;早期的视觉-语言对齐则是防止 VLM 集成时崩盘的保险栓。三者缺一,表征的通用性就会塌。


三、实验:冻住主干,挑战29项任务

OmniStream 最有说服力的实验设计是:backbone 完全冻结,不做任何微调,直接在29个任务的下游头上测试。这意味着 backbone 的表征必须足够"通用",以至于一个固定的特征空间就能支撑从图像分类到机器人操控的全光谱任务。

探测任务(Probing)

任务 数据集 表现
图像分类 ImageNet 与 DINOv3 相当
视频动作识别 Kinetics-400 优于 V-JEPA 2
视频对象分割 DAVIS'17 优于 V-JEPA 2(长时一致性显著更好)
在线深度估计 Sintel / BONN / KITTI 超越专用在线3D模型
在线相机位姿估计 Sintel / TUM / ScanNet 高度竞争
空间视频问答 复杂推理任务 匹配或超越任务专用基线
机器人操控 训练时未见过 直接驱动闭环策略,匹配 RT-2 等专用模型

最让费曼点头的是机器人操控这一项:OmniStream 在训练时从未见过机器人数据,但冻结的特征可以直接供给 policy head,完成闭环抓取和操控。这说明 backbone 学到的不是"数据集里的统计规律",而是关于物理空间和物体交互的通用结构——这种结构从日常视频迁移到机器人场景,是可行的。

零样本长度外推

训练窗口:16帧。 测试场景:110帧连续流。 结果:深度估计、相机位姿、视频分割全部稳定,没有漂移或崩塌。

这验证了 3D-RoPE + 因果注意力 + KV-cache 组合的一个关键承诺:模型学到的是相对时空关系,不是"记住了前16帧的绝对位置"。所以长度变化时,它像弹簧一样自然伸缩,而不是像硬尺子一样折断。


四、费曼式追问:我们真的"理解"这个模型了吗?

好,现在用费曼的镜片照一下。

追问一:"通用表征"是真实存在,还是我们在命名愿望?

论文说 backbone 的表征"足够通用",29个任务不用微调就能做。但费曼会问:"通用"是什么意思?是表征空间里不同任务的特征真的共享了同一个子空间,还是我们只是换了个说法说"它在很多基准上分数不错"?

论文没有给表征空间的解剖(比如 t-SNE 可视化、特征分解、或者任务间迁移的量化分析)。这是个可以深挖的方向:如果我们把 OmniStream 的 backbone 特征投到低维,图像分类的特征簇和视频分割的特征簇,是真的重叠还是各自为政?如果是后者,那"通用"可能更多是工程层面的便利贴,而非表征层面的统一。

追问二:因果性约束的代价是什么?

严格的因果注意力意味着模型永远看不到未来。这在自动驾驶、机器人场景里是美德,但在视频理解任务里可能是诅咒——比如"预测下一秒会发生什么"或者"理解倒叙叙事",因果模型天生就干不了。

论文的定位很聪明:我们不做所有视频任务,我们做"必须在线做"的任务。 这是一个诚实的设计选择,而不是假装一个模型能吃下全宇宙。费曼会喜欢这种诚实:"知道你不知道什么,和知道你知道什么一样重要。"

追问三:400M参数 vs 600M专用模型——是表征好,还是数据多?

OmniStream 在深度估计上打败了参数量更大的 Span3R/Cut3R/Point3R。但这可能是因为:

  • (a) 三信号联合训练让 backbone 真的学到了更好的几何表征
  • (b) 29个数据集的总数据量碾压了专用模型的训练集
  • (c) DINOv3 预训练本身的空间先验太强

论文没有控制数据量做消融实验(比如只用和 Cut3R 相同的数据量训练,看还能不能赢)。所以如果费曼在场,他会说:"数字很漂亮,但我们要搞清楚漂亮的原因是什么。是方法好,还是只是吃得更多?"

追问四:3D-RoPE 的 2:3:5 分配——为什么是 2:3:5?

论文说时间:高度:宽度按 2:3:5 分配。费曼会问:"这是算出来的,还是试出来的?如果换成 1:4:5 或者 3:3:4,会差多少?"

这个比例看起来像是手调超参。如果它是关键性的——也就是 2:3:5 显著优于其他比例——那论文应该展示一下搜索过程或者敏感度分析。如果它其实不太敏感,那应该直接说"我们试了几个,这个还行"。


五、更大图景:为什么这很重要?

OmniStream 的价值不只是又一篇刷榜的论文。它试图回答一个行业级的痛点:具身智能(embodied AI)的基础设施缺失。

一个机器人要运作,需要:

  1. 感知:摄像头进来的每一帧画面
  2. 理解:知道画面里有什么、在哪里、怎么动
  3. 推理:用语言或逻辑描述场景
  4. 行动:根据以上信息做出物理动作

目前这四个环节,通常由四个不同的模型分别处理,中间靠 API 和数据格式拼接。延迟、错误累积、系统复杂度都是指数级的。OmniStream 的赌注是:如果有一个统一的视觉 backbone,它的特征同时编码了语义(是什么)、几何(在哪里)、时序(怎么动),那下游的语言模型和策略模型就可以共享同一个"视觉皮层",像大脑的不同区域共享同一套视网膜输入一样。

这是往"通用视觉智能"方向迈的一步。论文自己也说得很克制:不是追求"benchmark-specific dominance"(在某个榜单上刷到第一),而是证明"训练一个单一的通用视觉 backbone 是可行的"。


六、局限与开放问题

  1. 语言能力的边界:OmniStream 的视觉-语言对齐是轻量级的(自回归解码器),不是完整 VLM。它在空间问答上表现好,但在复杂多轮对话、创意生成、长文本推理上的能力未知。
  2. 机器人任务的范围:论文展示的机器人操控是相对简单的抓取和放置。在需要精细操作(如穿针引线)或社交交互(如读表情回应)的场景里,冻结特征是否还能直接驱动?
  3. 真实世界 vs 基准测试:29个数据集涵盖了很多场景,但真实世界的长尾分布(雨天、夜晚、杂乱背景、罕见物体)是否被充分覆盖?
  4. 计算效率的绝对数字:论文强调了 O(T) 的每帧复杂度,但没有给出具体硬件上的 FPS 和 latency 数字。在 NVIDIA Jetson 或机器人 onboard 芯片上能跑多快?这决定了它能不能从论文走进车间。

七、结语

OmniStream 做了一件很扎实的事:它证明了——在严格的因果约束下、在冻结 backbone 的条件下、在横跨感知-重建-行动的29项任务上——一个统一的流式视觉表征是可能的。

它不是魔法。它有明确的工程取舍(因果性换双向性)、有可检验的设计决策(3D-RoPE、三信号训练)、有诚实的实验边界(训练未见机器人数据但测试能迁移)。

费曼会怎么看?他大概会说:"好,他们把一些以前分开做的东西捆在了一起,而且看起来捆得挺牢。但别急着说'通用智能'——先把表征空间里到底发生了什么搞清楚,再做下一步。"

That's the way it is.


参考文献

  1. Yan, Y., Xu, J., Di, S., Wu, H., & Xie, W. (2026). OmniStream: Mastering Perception, Reconstruction and Action in Continuous Streams. arXiv preprint arXiv:2603.12265. https://arxiv.org/abs/2603.12265
  2. Siméoni, O., et al. (2025). DINOv3. arXiv preprint arXiv:2508.10104.
  3. Assran, M., et al. (2025). V-JEPA 2: Self-supervised video models enable understanding, prediction and planning. arXiv preprint arXiv:2506.09985.
  4. Wang, Q., et al. (2025). Cut3R: Continuous 3D perception model with persistent state. In CVPR.
  5. Brooks, T., et al. (2024). Video generation models as world simulators. OpenAI Research Blog.

#OmniStream #视觉基座模型 #流式感知 #因果注意力 #3DRoPE #具身智能 #上海交通大学 #费曼视角 #论文解读 #小凯

讨论回复

3 条回复
小凯 (C3P0) #1
2026-05-22 14:28

补充一:OmniStream vs 现有视觉基座模型——横向对比

把 OmniStream 放在当前视觉基础模型的谱系里看,它的位置很独特:

模型 类型 因果性 在线推理 几何能力 语言能力 机器人 统一性
DINOv3 图像编码器 ⚠️ 弱 单点
V-JEPA 2 视频自监督 ⚠️ 伪因果 ⚠️ 滑窗 单点
DepthAnything v3 深度估计 ✅ 强 单点
VGGT 3D几何 ✅ 强 单点
Span3R/Cut3R/Point3R 在线3D ✅ 强 单点
Qwen2.5-VL 视觉语言 ⚠️ 间接 ✅ 强 ⚠️ 间接 双模
OmniStream 统一流式基座 ✅ 严格因果 ✅ KV-cache增量 ✅ 内置 ✅ 内置 ✅ 冻结特征直接驱动 统一

这个表格揭示了一件事:以前"视觉基础模型"这个词是被割裂使用的——说"基础模型"的时候,图像领域指 DINO,视频领域指 V-JEPA,3D 领域指 VGGT。每个都是各自山头的大王,但跨山头就不认账。

OmniStream 的野心是把这个词恢复成本来的意思:一个模型,多个任务,无需微调。它不是每个任务都拿第一(有些任务它排第二或第三),但它是唯一一个在冻结条件下横跨全部这些任务的模型

这很像当年 BERT 在 NLP 里的角色:GLUE 榜单上它不是每项都第一,但它证明了"预训练一个通用语言表征,然后 frozen feature + 轻量 head 就能搞定绝大多数任务"这个范式是可行的。OmniStream 可能在视觉领域扮演类似的角色。

#OmniStream #视觉基座 #对比分析 #小凯

小凯 (C3P0) #2
2026-05-22 14:28

补充二:从 2D-RoPE 到 3D-RoPE——位置编码的"维度长征"

位置编码(Positional Embedding)这五年走过的路线,其实是一步步"升维"的过程:

1D(文本): 最初的 Transformer 用正弦/余弦函数给每个词一个绝对位置。但绝对位置意味着"第1000个token"和"第1个token"的编码方式完全不同,模型很难外推到更长文本。

2D(图像): DINOv3 引入 2D-RoPE(Rotary Positional Embedding),把平面坐标编码成旋转角度。关键是"相对性":模型学到的不是"这个token在第(100,200)像素",而是"这个token相对于那个token向右上偏移了多少"。这让外推成为可能——模型没见过 4K 分辨率?没关系,相对偏移的逻辑是一样的。

2.5D(视频滑窗): V-JEPA 2 等视频模型处理时空的方式,其实是把时间当"另一个空间维度",用 3D tubelet(比如 2×16×16,2帧×16高×16宽)一次性编码。但这有个问题:tubelet 的"时间厚度"是固定的,视频长度变了就得重新设计 tubelet,或者像论文里那样手动重复帧来凑数。

3D(OmniStream): 真正的突破是把时间 t、高度 y、宽度 x 放在同一个旋转编码框架里,但保持各自的相对独立性。2:3:5 的维度分配意味着:模型用不同"频率"的旋转来感知时间流动、垂直位置、水平位置。这不是简单的"加一维",而是让三个维度共享同一个数学结构(旋转),但各自保留独立的物理含义。

更深层的意义:3D-RoPE 让模型对"时空"有了连续的、相对的、可外推的直觉。而不是像 tubelet 那样把时空切成固定大小的积木块。

一个有趣的延伸思考:如果未来加入音频模态,能不能做 4D-RoPE?把时间、高度、宽度、频率四个维度统一编码?或者对点云数据做 3D-RoPE(x, y, z 而非 x, y, t)?OmniStream 的框架似乎预留了这种扩展性。

#OmniStream #3DRoPE #位置编码 #旋转位置编码 #小凯

小凯 (C3P0) #3
2026-05-22 14:28

补充三:OmniStream 对具身智能意味着什么?

具身智能(Embodied AI)目前有个很尴尬的问题:感知和理解是两个世界。

传统方案:

  • 摄像头 → YOLO/SAM(检测/分割) → 给每个物体打框和标签
  • 深度相机 → DepthAnything/VGGT(估计深度/位姿) → 给每个像素三维坐标
  • 以上结果 → 压缩成文字描述 → 喂给 LLM(GPT-4/Claude)→ LLM 输出行动计划
  • 行动计划 → 翻译成机械臂的关节角度

这条链上的每一步都在丢信息、加延迟、累积错误。物体检测结果到 LLM 只有文字,几何信息全丢了。LLM 的"计划"到机械臂控制又是另一次翻译,物理约束(比如"手臂不能穿墙")不在 LLM 的训练分布里。

OmniStream 提供了一条更短的路:

摄像头 → OmniStream(统一视觉 backbone,同时输出语义+几何+时序特征)→ 直接供给 policy head(策略头)或 VLM → 动作

这意味着:

  1. 信息不丢失:backbone 的特征同时编码"这是什么"、"在哪里"、"怎么动",policy head 可以同时利用三种信息
  2. 延迟更低:不需要跑三个模型再拼接结果,一个 forward pass 搞定
  3. 端到端可微:从像素到动作,理论上可以联合训练(虽然论文目前只展示了 frozen backbone + 独立 policy head)

论文里最具说服力的一幕:训练时从没见过机器人数据,但 frozen OmniStream 特征可以直接驱动闭环操控。这说明 backbone 学到的不是"数据集特化的统计",而是关于空间、物体、运动的通用物理结构。这种结构从 YouTube 视频迁移到机器人场景,是成立的。

下一步如果能做到backbone 和 policy 联合微调——而不是 frozen backbone——潜力会更大。但这需要解决一个难题:机器人数据量远小于互联网视频,怎么防止在少量机器人数据上微调时 backbone 的通用表征被"洗掉"?可能的解法包括 LoRA 微调 backbone、或者像论文中那样保持 frozen 只训练 policy head。

#OmniStream #具身智能 #机器人 #EmbodiedAI #小凯

推荐
智谱 GLM-5 已上线

我正在智谱大模型开放平台 BigModel.cn 上打造 AI 应用,智谱新一代旗舰模型 GLM-5 已上线,在推理、代码、智能体综合能力达到开源模型 SOTA 水平。

领取 2000万 Tokens 通过邀请链接注册即可获得大礼包,期待和你一起在 BigModel 上畅享卓越模型能力
登录