WEBVTT

00:00.000 --> 00:03.120
视频还没播完,MOSVIA Real Time已经开始描述画面。

00:03.120 --> 00:07.800
他先认出咖啡店和走进门的一男一女,随后又跟到了柜台前的交谈。

00:07.800 --> 00:11.200
后面的人物继续出现,文字也继续往下涨。

00:11.200 --> 00:15.520
这不是等视频结束以后再做总结,模型正在跟着画面一起走。

00:15.520 --> 00:21.200
它是MOS智能推出的110亿参数开放全入模型,专门处理持续进入的视频流。

00:21.200 --> 00:24.600
普通的视频问答往往要先看完整段再统一回答。

00:24.600 --> 00:29.680
事实版把等待拆开了,新画面不断进来,理解和文字生成也可以同时继续。

00:29.680 --> 00:34.680
按照官方介绍,你可以在视频播放过程中插入问题、证据还不够时。

00:34.680 --> 00:39.880
它可以先保持沉默,后面的画面改变了情境,它还能补充或者修正此前的判断。

00:39.880 --> 00:44.280
边看边答,主动沉默和动态更新构成了这个版本最核心的区别。

00:44.280 --> 00:46.480
同系列还有基础版和指令版。

00:46.480 --> 00:50.600
基础版适合继续训练,指令版面向完整视频的深入问答。

00:50.600 --> 00:53.200
实施版才专门面对持续视频流。

00:53.200 --> 00:58.080
官方标注的256000上下文,表示一次能够参考的信息容量,

00:58.080 --> 01:04.680
不是固定的视频分钟数。抽针越密,对话越长,能够容纳的视频时长就会跟着变化。

01:04.680 --> 01:08.600
接下来是我最关心的问题,消费机显卡能不能把它跑起来。

01:08.600 --> 01:13.560
官方给出了4比特量化版本,按照一张R4G显卡设计,我没有这张卡,

01:13.560 --> 01:18.160
于是改用两张4070Ti Super让程序自动拆分模型。

01:18.160 --> 01:21.160
本地部署走的是一条完整的成功路径。

01:21.160 --> 01:25.880
仓库拉到本地以后,我创建独立环境,装好运行依赖,再下载官方量化权重。

01:25.880 --> 01:29.040
启动实施推理程序时,三个权重分片依次加载。

01:29.040 --> 01:32.160
加载完成以后,模型开始按时间接收视频。

01:32.160 --> 01:34.440
两张显卡也同时参与推理。

01:34.440 --> 01:39.840
画面继续进入,文字随之更新,终端最后显示36帧全部送达,

01:39.840 --> 01:41.760
这次本地部署正式跑通。

01:41.760 --> 01:46.080
测试输入是一段30多秒的咖啡店视频,程序每秒取一帧,

01:46.080 --> 01:50.240
模型先认出了门店和进场人物,随后描述男子走向柜台,

01:50.240 --> 01:55.240
店员递出纸杯,场景继续变化,他又跟到了后面的人物冲突。

01:55.240 --> 02:00.040
整段输出不是最后一次性出现,而是随着视频推进不断补充。

02:00.040 --> 02:05.080
我又在视频播到约10秒时插入一个问题,问现在画面里有几个人,

02:05.080 --> 02:06.240
他先回答两个人。

02:06.240 --> 02:09.840
7秒以后,柜台后的电源进入画面,他没有等我再问,

02:09.840 --> 02:14.320
直接把答案更新成3个人,到了26秒我再问刚才发生了什么变化。

02:14.320 --> 02:19.040
他先认出电源正在介绍三种杯子,随后又补充男子已经走到柜台前,

02:19.040 --> 02:23.720
两次提问都发生在播放过程中,后面的画面也没有被第一轮回答挡住。

02:23.720 --> 02:27.160
这次运行也给出了一个很直接的硬件结论,

02:27.160 --> 02:32.280
我用两张4070Ti Super跑完了这段视频,扣掉系统本来的占用,

02:32.280 --> 02:37.840
模型额外使用的显存大约13.3G,这个结果只对应当前样片和参数,

02:37.840 --> 02:42.040
但至少证明这套双卡配置可以完成一次本地实施推理。

02:42.040 --> 02:46.000
输出中间还有一段很值得看画面没有明显变化时,

02:46.000 --> 02:50.440
终端没有继续增加描述,后面的人物进入以后文字才重新出现。

02:50.440 --> 02:55.560
原始接口会把这种状态写成控制标记,真正做成应用时需要先过滤,

02:55.560 --> 02:58.760
对观众来说更重要的是模型知道什么时候先观察,

02:58.760 --> 03:00.680
而不是每一帧都重复说话。

03:00.680 --> 03:04.680
不过,实时不代表每个瞬间都不会漏掉,当前测试每秒只取一帧,

03:04.680 --> 03:07.560
视频里一个非常短的击打动作就没有被稳定识别。

03:07.560 --> 03:11.560
它看到了动作前后不等于看见了中间的每一刻,

03:11.560 --> 03:16.680
提高采样频率可能保留更多细节,也会同时增加输入和缓存压力。

03:16.680 --> 03:22.760
这种持续更新来自模型的输入方式,视觉信息不是等到整段结束再交给语言部分,

03:22.760 --> 03:28.680
每个采样画面还带着自己的时间位置,所以事件先后和状态变化能够进入同一段推理。

03:28.680 --> 03:33.560
官方代码除了读取本地视频还支持摄像头、屏幕和外部发送的视频帧,

03:33.560 --> 03:39.000
它可以成为直播辅助实验观察、流程提醒或者屏幕任务监控的视觉底座。

03:39.000 --> 03:45.960
模型负责持续理解和回答,真正上线是告紧规则、权限控制和人工复合仍然要由应用层补上。

03:45.960 --> 03:52.040
所以Mousewell Real-Time的优势很明确,视频还在发声,问题和答案就能一起向前推进。

03:52.040 --> 04:00.040
它的限制也同样明确,采样会漏掉短动作,长上下文会继续消耗缓存,原始输出也不是装好就能使用的监控产品。

04:00.040 --> 04:05.480
如果你的任务只是等视频结束以后再总结,指令版会更直接。

04:05.480 --> 04:12.440
如果你需要在视频进行中观察、提问等待,再根据新画面更新判断,实施版才真正对口。

04:12.440 --> 04:17.400
项目地址和官方资料放在评论区,感兴趣可以拿自己的视频试一遍。