VideoChat3 登顶 HF 日榜，4B 模型与数据页更新
4B 模型与三套数据已有公开入口，训练代码仍待真正落地和第三方复现。
本文要点
- 论文从 7 月 16 日预印本，变成 7 月 17 日 HF Daily Papers 第 1。
- 项目仓库从早期页面配置，变成有论文说明、资源链接和演示的研究入口。
- 4B 模型和三套数据页在 7 月 17 日更新，但它们并非当天首次创建。
阅读辅助
先看数字、证据和来源，再读正文。
7 月 17 日的增量是 HF 日榜第 1，以及代码仓库、模型页和三套数据页的同窗更新。
2026-07-05T13:47:44Z · VideoChat3-4B 模型仓库创建；这不是 7 月 17 日的新建事件。
VideoChat3 值得关注的原因，不只是又一个视频多模态模型进入榜单，而是它试图用一个 4B 模型同时覆盖细粒度运动、长视频推理、时序定位和在线流式响应，并把模型、代码与数据开放写进同一套研究主张。
确定事实是：论文 v1 于 2026 年 7 月 16 日 12:47:59 UTC 提交 arXiv；到 7 月 17 日，它进入 Hugging Face Daily Papers 第 1。同一天，GitHub 仓库出现一系列 README、论文链接和演示更新，VideoChat3-4B 模型页与 Academic2M、LV116k、OL617k 三套数据页也都更新了 lastModified。
不确定性同样关键。论文中的能力、基准与效率结论均为作者评测，目前没有第三方按相同数据、硬件和推理设置完整复现。论文声称将释放训练代码、训练策略和完整训练数据，但 7 月 17 日仓库 README 仍把训练代码列为未完成 TODO；因此，当前只能确认权重和数据页面已有入口，不能把“完整开放承诺”写成“完整训练栈已被交付并验证”。
对研究者而言，这套材料提供了检查视频 tokenizer、流式分辨率控制和数据合成方案的入口。对部署团队而言，作者在 H200 上报告的长视频效率曲线值得复测，但消费级 GPU、直播延迟和真实帧率下的表现仍是空白。对开源生态而言，真正的分水岭将是外部团队能否从这些入口走到可重复训练，而不是页面数量本身。
新闻锚点：上榜与资源更新，不是模型仓库当天新建
这条新闻必须把各资源的时间逐项拆开。arXiv v1 是 7 月 16 日 12:47:59 UTC 的预印本，不属于 7 月 17 日首次提交；7 月 17 日的新增事实，是 HF Daily Papers 排到 第 1，团队仓库继续提交，模型和三套数据资源在同一窗口更新。
| 资源 | createdAt 或首次事件 | 7 月 17 日状态 | 正确表述 |
|---|---|---|---|
| arXiv v1 | 7 月 16 日 12:47:59Z | 进入 HF Daily Papers 第 1 | 7 月 17 日上榜，不是当天首发论文 |
| GitHub 仓库 | 7 月 6 日 02:31:19Z 创建 | 04:23Z 至 12:54Z 连续提交 | 仓库当天更新，不是当天创建 |
| VideoChat3-4B | 7 月 5 日 13:47:44Z 创建 | 12:16:52Z 更新 | 模型页当天更新，不是当天创建 |
| Academic2M | 7 月 5 日 13:49:37Z 创建 | 11:08:21Z 更新 | 数据页当天更新 |
| LV116k | 7 月 5 日 13:50:01Z 创建 | 19:16:23Z 更新 | 数据页当天更新 |
| OL617k | 7 月 5 日 13:50:30Z 创建 | 11:09:18Z 更新 | 数据页当天更新 |
GitHub 的 7 月 17 日提交也需要按实际内容理解。Add VideoChat3 project README、补充 arXiv 链接、添加 teaser 和 dense captioning demo，说明团队把仓库整理成论文与资源入口；这些提交不能被概括成“训练代码已在当天完整发布”。采集时 README 的 TODO 明确显示“Release model weights and data”已勾选，而“Release training code”仍未勾选。
技术路线：先压缩时空 token，再让模型动态分配视觉预算
VideoChat3 的结构判断从一个现实约束出发：视频帧越多，视觉 token 越快占满大模型上下文。传统做法常把每一帧先当独立图片编码，再把大量视觉 token 交给语言模型；稀疏采样虽然便宜，却可能在进入模型前就丢掉短时运动和关键帧细节。
作者提出的 I3D-ViT 把图像 ViT 的二维空间注意力扩展到局部三维时空注意力。连续帧先按最多 T 帧分组，在组内联合建模，然后沿时间维池化。默认 T=4，再叠加 pixel shuffle 带来的 2×2 空间下采样，论文给出的视觉序列压缩口径约为 4T，也就是 16× 时空压缩。这是视觉 tokenizer 内部的设计压缩比，不等于所有端到端任务都固定获得 16 倍速度提升。
流式场景再加入 Adaptive Frame Resolution。模型在每个视频窗口后输出三种状态之一：
Silence：当前没有与任务相关的证据，继续低成本监看。Standby：可能出现关键证据，但信息还不足，下一窗口提高分辨率。Response：证据足够，生成回答后回到低成本监看。
这套机制的核心不是让所有帧都更清楚，而是让模型按证据状态调节下一段输入的像素预算。论文设置低预算为 224² 像素、高预算为 448² 像素；Standby 触发高预算，Silence 与 Response 后恢复低预算。它把“何时回答”和“下一段看多清楚”连接起来，适合直播监控、实时问答等不能预先看到完整视频的任务。
三套数据与四阶段训练
论文把训练流程分成四阶段：视觉 tokenizer 预训练、视频语言对齐、视频指令微调、长视频与流式视频指令微调。对应的训练样本量分别写为 7.59M、3.47M、10.33M 和 3.41M，最长 packed sequence length 从 8192 增到 98304。这些是训练各阶段的数据混合口径，并不等于三套新发布数据简单相加。
三套 VideoChat3 数据资源各自承担不同任务：
| 数据资源 | 论文定位 | 主要覆盖 | 当前可确认状态 |
|---|---|---|---|
| Academic2M | 重写与整理学术视频数据 | 通用视频描述、问答与时序理解 | HF 公开页面可访问，7 月 17 日更新 |
| LV116K | 合成长视频监督 | 长上下文问答、跨片段证据聚合 | HF 公开页面可访问，7 月 17 日更新 |
| OL617K | 构造在线流式监督 | 证据定位、响应时机与主动回答 | HF 公开页面可访问，7 月 17 日更新 |
论文正文称三套数据合计约 300 万条高质量多模态指令样本。OL617K 的构造尤其值得核查：先定位回答问题所需的视觉线索，再裁剪线索区间做验证，最后把流式窗口标成 Silence、Standby 或 Response。这种标注把普通离线问答转换成“何时证据足够、何时应回答”的因果训练序列。
但“页面存在”只证明资源入口公开。它不能自动证明三套数据已经覆盖论文所称的全部训练样本，也不能证明原始视频、派生标注、数据许可和构建脚本足以让第三方完整重建训练集。这里需要等待文件级审计，而不是从公开页面名称直接推出“完整可复现”。
作者评测：跨场景成绩强，但比较边界要保留
论文在通用视频、长视频、复杂推理、时序定位和在线流式场景上给出大规模比较。作者称 VideoChat3-4B 相对 Qwen3-VL-4B 在 19 个可直接比较指标中提升 18 个，唯一下降来自 VideoEval-Pro 的开放式划分；相对同为 4B 的 Molmo2-4B，也在多数列中持平或更高。
下面只摘录论文表格中的几个代表性指标，所有数字都应读作“作者在论文设置下报告”，不是独立排行榜复现：
| 作者评测指标 | Qwen3-VL-4B | Molmo2-4B | VideoChat3-4B |
|---|---|---|---|
| MotionBench | 58.6 | 61.6 | 61.7 |
| TempCompass | 70.8 | 72.8 | 75.6 |
| Video-MME | 69.3 | 69.6 | 70.1 |
| MMVU | 50.5 | 51.2 | 56.4 |
| TimeLens ActivityNet mIoU | 46.4 | 33.3 | 56.1 |
| MomentSeeker mIoU | 13.8 | 19.9 | 25.9 |
流式评测中，作者报告 VideoChat3-4B 在 ODVBench 得到 72.3，StreamingBench 得到 83.0，OVO-Timing 平均 F1 为 35.5。论文也保留了不占优的结果：在 ProactiveVQA 的四个子集里，它超过 Qwen3-VL-4B 的是三个；面对专门面向流式响应的 MMDuet-2，VideoChat3 并非每个子集都领先。这说明“统一模型”带来的价值是覆盖面，而不是在所有专门任务上都成为最佳。
效率表：长视频获益，短视频并非全面更快
效率对比使用 NVIDIA H200、Hugging Face Pipeline 和 FlashAttention-2。作者控制两种模型每帧使用相同数量的 ViT patch，VideoChat3 输出的视觉 token 是 Qwen3-VL 的一半。代价是 I3D-ViT 的视觉编码更慢；收益是进入语言模型的序列变短，帧数增加后，二次复杂度更高的 LLM 阶段节省开始超过视觉编码开销。
| 输入帧数 | 模型 | 视觉 token | GPU 显存 | 视觉编码延迟 | 总延迟 |
|---|---|---|---|---|---|
| 256 | Qwen3-VL | 25,088 | 20.583 GB | 0.288s | 1.363s |
| 256 | VideoChat3 | 12,544 | 17.663 GB | 1.272s | 1.652s |
| 512 | Qwen3-VL | 50,176 | 32.915 GB | 0.578s | 3.838s |
| 512 | VideoChat3 | 25,088 | 26.676 GB | 2.595s | 3.596s |
| 1024 | Qwen3-VL | 100,352 | 57.581 GB | 1.152s | 12.251s |
| 1024 | VideoChat3 | 50,176 | 44.709 GB | 5.158s | 8.099s |
| 2048 | Qwen3-VL | 200,704 | 106.913 GB | 2.313s | 44.449s |
| 2048 | VideoChat3 | 100,352 | 80.775 GB | 10.297s | 20.412s |
这张表不能被翻译成“VideoChat3 在所有视频长度都更快”。在 256 帧设置下，它的总延迟是 1.652 秒，反而高于 Qwen3-VL 的 1.363 秒；到 512 帧才出现小幅总延迟优势，长到 2048 帧时差距明显扩大。准确结论是：作者设置下，I3D-ViT 把更多计算移到视觉编码器，长序列时以更少 LLM token 换得更低总延迟和显存。
“完整开放”的原话与当前状态
完整开放是 VideoChat3 最需要精确翻译的部分。论文摘要与正文使用的是“By releasing”以及“we fully release”一类表述，列出的对象包括模型权重、训练代码、训练策略、完整训练数据和数据构建管线。项目 README 则把可见状态拆成已完成的“Release model weights and data”和未完成的“Release training code”。
| 原文或页面状态 | 本文采用的中文表述 | 不能外推为 |
|---|---|---|
model weights and the complete training datasets are publicly available | README 称权重与完整训练数据已公开 | 第三方已核验所有文件完整、许可无缺口 |
Release model weights and data 已勾选 | 模型和三套数据已有公开入口 | 7 月 17 日才首次创建这些仓库 |
Release training code 未勾选 | 采集时训练代码仍待发布 | 完整训练栈已经可运行 |
| 论文称释放训练策略与构建管线 | 论文披露配方并作出开放承诺 | 第三方已经从头复现论文结果 |
因此，现阶段最稳妥的结论是三层：第一，论文对“全栈开放”给出了明确范围；第二，HF 模型和三套数据页面已经公开并在 7 月 17 日更新；第三，训练代码 TODO 仍未完成，外部复现证据尚未出现。把这三层合并成一句“VideoChat3 已完整开源并可复现”，会抹掉承诺与交付之间的真实差距。
VideoChat3 最有价值的方向，是把视频模型的三个长期割裂问题放到同一个系统里：短时运动需要密集时空建模，长视频需要压缩 token，在线流式输入还要决定何时提高视觉预算、何时回答。I3D-ViT 与 Adaptive Frame Resolution 的组合，至少给出了一条机制一致的路线，而不是为每个 benchmark 单独外挂一个模块。
这套路线对 4B 规模尤其有意义。视频理解的部署瓶颈常常不只是参数，而是视觉 token 数、上下文长度和持续输入成本。作者效率表显示，早期时空压缩在短视频上要支付更高视觉编码延迟，却在长视频上逐步收回成本。这个“短序列不一定更快，长序列才明显受益”的形状，比单独宣传 16× 压缩更能帮助部署方判断适用场景。
不过，VideoChat3 当天更像一份完整开放计划进入集中检验，而不是开放工程已经完成验收。权重和数据入口是实质进展，训练代码仍在 TODO，性能与效率又全部来自作者评测。模型是否真正降低研究门槛，要看外部团队能否获得同样的数据版本、跑通四阶段训练，并在相同硬件与评测脚本下接近论文结果。
早报判断是，这个项目应以“可复现性资产”而非“榜单冠军”持续跟踪。HF 日榜 第 1 提供了注意力，跨场景作者评测提供了研究假设；真正决定长期价值的，是代码、数据构建管线、版本锁定和第三方复现是否陆续补齐。若这些环节兑现，VideoChat3 才可能成为视频 MLLM 的公共研究底座；若停在页面和权重层，它仍只是开放程度更高的模型发布。
接下来看什么
第一，看训练代码是否真正进入仓库。最低标准不只是把 TODO 勾选，而是出现环境锁定、四阶段训练入口、数据配比、checkpoint 转换、评测脚本和可追踪的版本标签。
第二，看三套数据能否支撑论文的“完整训练数据”措辞。需要逐项核对原始视频可访问性、派生标注、许可与删除机制，并解释论文各阶段数百万样本的混合如何映射到公开资源。
第三，看效率曲线能否跨硬件成立。H200 上的作者结果说明长视频可能获益，但消费级 GPU、不同视频分辨率、不同帧率和真实直播流会改变视觉编码与 LLM 解码的比例。
第四，看第三方复现是否同时覆盖能力和成本。只复跑几个问答 benchmark 不足以验证统一设计；更有价值的复现应同时报告时序定位、在线响应时机、显存、首 token 延迟和端到端吞吐，并保留失败案例。