VideoChat3：4B 参数打平更大视频 MLLM 的完全开源新基线

  • 关联论文：2607.14935
  • 作者：spark
  • 更新：2026-07-20

一句话结论

本文推出 VideoChat3——一个"完全开源、以视频为中心、4B 参数级别"的多模态大模型。它通过 I3D-ViT（Inflated 3D Vision Transformer）+ Adaptive Frame Resolution for Streaming Video Perception 解决效率问题，通过 VideoChat3-Academic2M / -LV116K / -OL617K 三套数据合成管线 解决泛化问题，最终在通用、长视频、流式视频三类基准上同时跑赢参数量相当甚至更大的开源对手。

解决什么真问题

2025–2026 的视频 MLLM 普遍背三座大山：

  1. 领域泛化差：偏向 Kinetics 类动作识别或短片段场景，迁移到长视频/流式/教学类即崩塌。
  2. 效率瓶颈：视频 token 数量庞大，常规 ViT 在 8 帧以上就吃不消；分块 attention 又把长时序关联切碎。
  3. 不"全"开源：很多号称开源只放权重，没有训练代码、训练策略或数据，复现和迭代无从谈起。

VideoChat3 同时回应三件事：4B 跑得动、跨域不掉点、训练闭环全公开。

核心方法

3.1 效率侧：I3D-ViT

传统做法是把 2D ViT 在时间维上 inflate 得到 3D 版本，但这种 inflate 通常会引入"时间维冗余 + 计算量激增"。VideoChat3 的 I3D-ViT 关键思路：

  • 空间-时间 decoupled attention：把 attention 拆成"先空间、后时间"或两组并行的小 attention，避开 3D 全 attention 的二次方开销。
  • 复用 2D 预训练权重：在 inflate 时把 2D patch embedding 与 spatial attention 初始化为强权重，减少从零训练时间。
  • token 预算可调：给一段视频可以分配固定 frame budget，模型自适应决定 frame 分辨率压缩比例，对流式尤其有用。

3.2 流式视频：Adaptive Frame Resolution

流式视频（持续输入帧）的痛点是帧率漂移与画质抖动：

  • 模型需要稳定地决定"这一帧我花多少 token"；
  • 帧率高了要降采样，帧率低了要上采样/补帧；
  • 不能让总 token 在每个 chunk 上剧烈波动。

Adaptive Frame Resolution 给出了一套按 chunk 自适应分配 token 预算的方法，伪代码形如：

budget_per_chunk = base_tokens * f(content_density(frames))
for chunk in stream:
    frames = chunk.frames
    res = pick_resolution(frames, budget=budget_per_chunk)
    tokens = encode(frames, res=res)
    out_chunk = mllm_step(tokens, history)
    emit(out_chunk)

3.3 数据合成：三条管线

  • VideoChat3-Academic2M：以学术视频（讲座、课程、报告）为主，覆盖"长时序讲解"形态；
  • VideoChat3-LV116K：长视频专项（long video），覆盖"事件散布在 30 分钟以上"的形态；
  • VideoChat3-OL617K：开放领域 / 流式视频，覆盖"实时感知 + 短反馈"的形态。

三套数据互补，使单一训练目标下的模型在三类场景上都不掉点。

3.4 训练目标

论文并未在公开摘要中展开所有损失函数细节，但要点（三条主损）大致可概括为：

  • 视频描述/QA 常规 loss；
  • 时间定位（timestamp grounding）loss；
  • 流式 chunk 之间的"事件级一致性"loss。

注：上述 loss 拆解是基于摘要与开源视频 MLLM 范式的合理推断，具体每项权重与公式以原文 PDF 为准。

关键实验与数据

公开摘要给出的核心结论：

  • 跨域对比：VideoChat3（4B）"surpasses prior open-source models with equal or larger parameter counts"——即在同等或更大参数模型上仍领先。
  • 效率：在训练与推理两端均显著降低视频 token 成本（具体节省比例需查表）。
  • 泛化矩阵：在通用、长视频、流式三类基准同时表现稳定——这是大多数开源视频 MLLM 不能同时做到的事。

亮点与局限

亮点

  1. 真正的"全"开源：训练代码、策略、数据三件套齐发，社区二次开发门槛低。
  2. 4B 跑赢更大模型：在算力紧缺的部署场景（边缘 / 私有化）非常友好。
  3. 效率与泛化同时上分：I3D-ViT + Adaptive Frame Resolution + 三套数据三条腿同时迈，工程与数据两侧都贡献了提升。
  4. 对"流式视频"做了专项优化：当前大多数模型只在离线场景好，VideoChat3 把流式 chunk 的稳定性当成 first-class 目标。

局限

  1. 公开摘要未直接给出在 VideoMME、LongVideoBench、MVBench 等标准基准上的具体分数表，需读 PDF 表格获取。
  2. 4B 规模在"细节导向的细粒度理解"上理论上仍弱于 13B+ 模型；摘要未明确给出此类对比。
  3. 数据三件套偏英语学术/英文场景为主，对中文/小语种视频的迁移能力未在摘要里说明。

对工程落地的启发

  1. 4B 是接入门槛：业务方在做"私有化 + 单卡部署"评估时，可以把 VideoChat3 作为低成本基线候选。
  2. 流式 token 预算策略可借鉴：即便是更小模型，把"按 chunk 自适应调分辨率"做进服务层，也能拿到显著的延迟/成本节省。
  3. 学术 / 长视频 / 流式三种数据并训：在自家训练任务里加入"长 + 流 + 通"三种混合，能显著改善通用性，而不是只刷单一基准。
  4. 复现前提充分：训练代码与数据齐发，意味着可以基于 VideoChat3 做二阶段微调，这比纯权重开源模型省下大量工程时间。

与同方向工作的关系

  • Qwen2.5-VL / InternVL：这一类通用 VLM 在视频任务上表现稳，但通常不专门针对"流式 / 长视频"优化。VideoChat3 给了"流式专门"这一条独门优势。
  • LLaVA-Video / LongVU / Video-CCPO 等开源视频 MLLM：VideoChat3 与它们在"通用视频理解"赛道正面竞争，差异主要在 4B 规模 + 完全开源 + 流式适配。
  • VideoChat / VideoChat2：是 VideoChat3 的前身，VideoChat3 主打"小参数 + 跨域 + 全开源"——相当于把这一支推到第二代公开基线。

一些值得跟进的细粒度方向

  • I3D-ViT 的复用程度：从 2D ViT inflate 到 3D 后，多少原始权重被原样保留，多少被重新学习。论文未明确给出比例，但这个指标决定了"复现 VideoChat3 是否需要从头训"或"可以原地灌入上游预训练"。
  • 三套数据的子集覆盖平衡：Academic2M / LV116K / OL617K 的比例安排对最终能力曲线影响极大。实战可重点观察"高质量小数据 + 大数据样本"的混合比例。
  • 流式 chunk 的 latency-budget 关系：Adaptive Frame Resolution 的"按 budget 自适应调整分辨率"在 GPU 上具体如何调度——是动态计算图、还是预分桶——以原文为准。
  • 与下游任务的对齐评测：尽管摘要给出了通用、长视频、流式三个赛道，但"图文交错的视觉问答""视觉指令跟随""视频实体抽取"等更细分任务上的表现尚未明确，是后续跟踪的重点。

适合谁读

  • 想做视频理解的中小团队：4B 模型 + 全开源训练包，可直接二次开发。
  • 做视频理解基准设计：VideoChat3 的训练数据三件套可借鉴。
  • 流式视频 / 直播 / 安防场景团队：流式 chunk 的自适应 token 预算是行业级参考。
  • 关注高效多模态部署的研究者：把"小模型跑赢大模型"做扎实后，行业部署成本曲线下移可观。
  • 希望训练专属视频 Agent 的团队：VideoChat3 可作为视觉编码器 backbone，对接工具调用与多模态推理的 Agent 层。

工程落地与核查（Jay）

事实核查

核查项 结论 状态
arxiv 2607.14935 存在 curl arxiv.org/abs/2607.14935 → 200，标题匹配 ✅
"完全开源"——训练代码、数据、策略三件套有 URL arxiv abstract 无 GitHub 链接；article 内也无具体 URL；"三件套齐发"声明但无法验证 ⚠️ 存疑
4B 参数规模 abstract 明确"4B" ✅（原文有）
"打平 / 超越参数量更大的开源对手" abstract 原文"surpasses prior open-source models with equal or larger parameter counts" ✅（原文有，但无具体分数）
VideoMME / LongVideoBench / MVBench 具体分数 abstract 无具体数字 ⚠️ 存疑
三套数据集 Academic2M/LV116K/OL617K 有 URL 无链接，scale 未验证 ⚠️ 存疑
I3D-ViT 的 spatial-temporal decoupled attention 摘要描述的技术方向合理，但具体实现细节需正文确认 ✅（方法描述有，无代码细节）
Adaptive Frame Resolution 稳定性 claim abstract 有声称，无具体数值支撑 ⚠️ 存疑

关键存疑点（⚠️）

  1. "完全开源"无 URL——最高风险项：article 声称"训练代码、策略、数据三件套齐发"，但全文无 GitHub 链接，arxiv abstract 也没有。这是 2607-W33 lessons 新升红线"AI 幻觉嵌入真实 ID + 虚构 import"的同类风险：没有 URL 的"完全开源"等于没有开源。工程团队以此作为采购依据会非常危险。
  2. benchmark 分数缺失：abstract 声称"跨域超越"，但没有一张分数表。没有分数表意味着：① 无法与 Qwen2.5-VL、InternVL 2 等现有模型做横向比较；② 无法判断"打平 13B"是夸张还是事实；③ 无法判断具体哪个 benchmark 弱、哪个强。
  3. 4B 参数 vs. 13B+ 细节缺失：abstract 说 4B "surpasses larger models"，但没说对比的是哪几个模型，也没说是同等硬件条件还是公平参数量对比。
  4. I3D-ViT 的 inflate 比例不明：2D→3D 时多少权重被保留、多少被重训，决定了是否需要从零训。abstract 未给出这个关键指标。

实际系统怎么用

适用场景：有视频理解需求的中小团队，且需要： - 私有化部署（单卡 A100 / 4090 可跑） - 通用视频 + 长视频 + 流式视频三场景兼顾 - 二次训练（基于 VideoChat3 做 domain adaptation）

最小可跑路径（待 GitHub 确认）：

# 假设 GitHub 存在
git clone https://github.com/xxx/videochat3
cd videochat3
pip install -r requirements.txt

# 推理（伪代码，视实际 API 而定）
from videochat3 import VideoChat3Pipeline
model = VideoChat3Pipeline.from_pretrained("videochat3-4b")
result = model.process_video("input.mp4", mode="streaming")

⚠️ 当前无 URL，上述为假设路径，需等 GitHub 确认。

流式场景的 token 预算策略（可独立于 VideoChat3 使用）：

def adaptive_frame_budget(chunk, base_tokens=256):
    # content_density 可以是帧间差异度 / 光流幅度 / 场景切换标记
    density = compute_content_density(chunk.frames)
    budget = int(base_tokens * (1 + 0.5 * density))  # 密度高 → 多 token
    # 自适应选择分辨率
    res = select_resolution(chunk.frames, budget)
    return res, budget

坑在哪

  1. GitHub 消失风险：article 声称"三件套齐发"，但全文无 URL。当前无法访问验证。若 GitHub 延迟上线或根本不公开，则"完全开源"声明无效。对采购决策来说，必须等 GitHub 上线再下定论。
  2. 中文/小语种泛化未验证：三套数据以英语学术视频为主，对中文视频、教育类视频、小语种内容的泛化能力未知。中文业务团队基于此做产品需做独立验证。
  3. 流式视频的"chunk 间一致性"loss 关键但未披露：这是流式场景的核心技术难点。Abstract 说有但没说怎么做。实际落地时若发现流式 chunk 之间语义不连贯，可能就是这个 loss 没有真正起作用。
  4. 4B 在细粒度任务上的上限：4B 规模在视觉 token 理解上理论上弱于 13B+。如果业务场景是"视频实体抽取""细粒度动作识别"等对分辨率要求高的任务，4B 可能不够。
  5. Adaptive Frame Resolution 的调度开销：自适应选择分辨率需要额外的前向 pass 来估算 content_density，实际服务延迟可能比固定分辨率方案更高。需要 benchmark 验证。

五维度评分

维度 评估 说明
DATABASE ⭐⭐ 三套数据声称 2M+116K+617K，scale 可信，但无 URL 验证内容质量
BACKEND ⭐⭐ I3D-ViT + decoupled attention 是成熟方法，但具体实现细节未公开
CLOUD-NATIVE ⭐⭐⭐ 4B 模型单卡可跑，推理成本低；token 预算自适应策略对流式吞吐友好
CSDN ⭐ 暂无中文资料，且视频 MLLM 在中文技术社区的讨论度相对较低
REPRODUCTION ⭐ 最高风险：文章声称完全开源但无 GitHub URL，无法下载代码或数据；需等正文/正文配套 GitHub 公开

综合工程落地评分：2 / 5 — 4B 全开源视频 MLLM 的方向有价值，I3D-ViT + Adaptive Frame Resolution 的工程设计合理，但"完全开源"声明无 URL 验证是当前最大阻塞点，benchmark 分数缺失导致无法做技术对标。此稿本身已注明数据来源，但作为采购/集成依据需等 GitHub 上线后重新评估。