
VideoJev:一个用数字而非句子作答的视频模型
- Orca新Orca: OrcaCyber Zero 1.52026-10-10$3.00 / $7.50 每百万 tokens · 60 tok/s
- openaiOpenAI: GPT-6.1 Sol2026-09-2952智能
- anthropicAnthropic: Claude Sonnet 5.52026-09-2856智能
- typesafeTypeSafe: Jev 1.132026-09-24$0.04 / $0.00 每百万 tokens · 762 tok/s
- OpenAIOpenAI: GPT-6 Luna2026-09-2238智能
- OpenAIOpenAI: GPT-6 Sol2026-09-2248智能
- AnthropicAnthropic: Claude Opus 5.52026-09-2258智能
- xAIGrok 4.72026-09-2146智能
- OrcaOrca: OrcaCyber Zero 1.02026-09-17$3.00 / $7.50 每百万 tokens · 39 tok/s
- OrcaOrca: OrcaVerify Text 1.02026-09-16$2.00 / $0.00 每百万 tokens · 2230 tok/s
- DeepSeekDeepSeek: DeepSeek V4.1 Flash2026-09-1040智能
- OpenAIOpenAI: GPT-6 Astra2026-09-0453智能77代码
- GoogleGoogle: Gemini 3.8 Flash2026-09-0241智能76代码
- AlibabaQwen: Qwen3.8 Max (0902)2026-09-0245智能76代码
- AnthropicAnthropic: Claude Fable 5.12026-09-0153智能82代码
- TencentTencent: Hy4 preview2026-08-28$0.83 / $2.50 每百万 tokens · 57 tok/s
- AlibabaQwen: Qwen3.8 Flash2026-08-26$0.15 / $0.47 每百万 tokens · 122 tok/s
- z-aiZ.ai: GLM 5.3 Flash2026-08-2642智能72代码
- DeepSeekDeepSeek: DeepSeek V4 Flash Vision (Exp)2026-08-21$0.22 / $0.66 每百万 tokens · 204 tok/s
- z-aiZ.ai: GLM 5.32026-08-1845智能75代码
VideoJev是一个视频理解模型系列,从不生成答案。向它询问某个事件的时间戳,它会返回一个由已评分候选槽位拼装而成的区间;向它提出一道关于视频的多项选择题,它会返回得分最高的选项。已有两个发布出来的检查点——VideoJev-4B基于 Qwen3.5-4B,以及 VideoJev-35B-A3B基于 Qwen3.6-35B-A3B——但它们并未被正式推出。没有人发布新闻稿。一篇论文于 2026-10-13 出现在 arXiv 上,权重于 2026-10-10 上传到 Hugging Face,而四天后仓库仍在整理之中:截至 10 月 14 日,它还在收到诸如“用公开附件恢复内联 README 视频”和“添加 arXiv 论文链接和官方 BibTeX 引用”这样的提交。这就是一次静默发布的样子——产物真实且可供检查,却没有任何公告来告诉你作者认为什么才重要。
下文所有内容都来自三个地方之一:arXiv 预印本(2610.18615,cs.CV,2026 年 10 月 13 日提交)、作者发布的模型卡和代码,以及论文自身关于这些数字如何测得的脚注。我尽量把这三者清楚地区分开来,因为这次发布真正有意思的地方不在于那个最显眼的数字——而在于支撑它的根基有多么单薄。

论文实际上声称的是什么
VideoJev 采用预训练的多模态 LLM,删除最后的 MLP 和语言模型输出头,并在它们的位置放置一个候选打分器。两个新 token,<|option_end|> 和 <|decide|>,产生读出值。决策状态和每个候选状态被投影到 512 维,经过归一化,然后进行点积;时间区间用 sigmoid 打分,并组合成一个 span,答案选项用 softmax 打分并归一化。两个任务都通过同一个头运行。没有任何东西被自回归地解码,因为没有什么需要解码。
该论文的三个核心数据,全部由厂商报告,且全部来自作者自己的评估框架:
• 定位质量 — VideoJev-4B 在三个时序定位基准测试上达到 65.3 的平均 mIoU,比其 Qwen3.5-4B 主干高出 6.7 个百分点。VideoJev-35B-A3B 达到 67.7,比 Qwen3.6-35B-A3B 高出 10.8 个百分点。
• 无需推理即实现 QA 持平——在四个视频问答基准上,两个模型的平均得分分别为 74.3 和 79.5,分别比其在思考模式下的骨干模型低 0.6 分和高 0.7 分。
• 延迟 — 在定位任务上比这些骨干模型快 2.8–3.1 倍,在 QA 上快 100 倍以上。QA 的实测倍数为 4B 时 129 倍,35B-A3B 时 100 倍。

对速度主张的诚实表述是:它是在与一个推理模型作比较,而后者所做之事远比任务所要求的困难得多。Qwen3.5-4B 在 Thinking 模式下,在 LVBench 上每道题消耗 144.9 秒,得分 74.9;VideoJev-4B 花 1.123 秒,得分 74.3。129× 是根据论文自身延迟表算出的真实算术结果,同时也是任何选择不思考的模型都会得到的算术结果。有趣的问题不在于这一加速是否真实——而在于能否构建出一个系统,使这种取舍是正确的。
其背后的论点:决策,而非生成
比基准表更有意思的地方在于其架构主张。作者在一个普通的自回归 Qwen3.5-4B 上,用 完全相同的后训练数据、相同的单一阶段、相同的设置进行微调,并让它生成区间或回答字母。论文中的表 3 显示,VideoJev-4B 比该对照组在平均 grounding mIoU 上高 1.3 分,在平均 QA 得分上高 1.9 分。两个模型看到的监督完全相同;只有读出形态不同。
如果这一点成立,那么收益不在于数据,也不在于规模——而在于,让模型对结构化候选项输出概率分布,比要求它生成字符串、再把这个字符串解析回决策,更适合结构化决策。这正是 TypeSafe 在 Jev 1.13 及其 System One 系列上所做的同一场押注,只不过从文本状态推广到了视频。论文明确指出,它是在这一研究方向的基础上继续推进,而不是发明了这个类别。
有两个实现细节比那些头条数字更值得关注,因为它们才是让它真正可用、而非仅仅是快的关键。缓存推理把视频编码并预填充一次,让随后到达的查询都从这一缓存前缀分支出去——每个查询只需一次前向传播。联合推理把多个查询放在同一个视频前缀之后,并为每个查询读出各自的 <|decide|>,因此一组问题总共只需一次前向传播。在一段视频上针对十个 grounding 查询,论文测得 VideoJev 为 0.39 秒,而 Instruct 基线为 5.98 秒;在 QA 方面,十个查询的耗时为 1.67 秒。论文还检查了联合推理显而易见的失效模式——即较早的问题会把答案泄露到较晚的问题中——并报告称已验证没有参考答案或预测答案被插入共享前缀。值得注意的是,这是作者自己做的验证,而且联合推理的得分优于孤立的缓存模式(4B 规模下 65.3 对 64.5 mIoU),他们将其归因于在相同的联合布局上进行了训练。
这张卡没有告诉你的事
有四件事明显缺失,而如果你正在判断它是否已达到生产就绪,它们比上面任何内容都更重要。
• 训练数据未公开。该仓库记录了格式,并提供了构建你自己的 JSONL 的工具,但语料库、其规模及来源均未说明。你无法针对它所报告的七个基准评测数据污染情况。
• 35B 权重以 FP32 起步。项目页面指出,Cached 推理使用 FP32,Joint 使用 BF16——因此,规模更大的模型其主推配置恰恰是显存占用更重的那个,而页面并未给出二者各自的显存数字。
• 置信度往往过度自信。论文报告称,4B 的平均校准误差为 8.65 个百分点,35B-A3B 为 8.13。该分数是一个可用的排序信号,而不是一个你可以不经自行调校阈值就直接据以分支的概率。
• 没有人独立验证过这些数字。这里的每一个数字都来自训练这些模型的团队。截至本文写作时,尚无第三方复现,没有榜单收录,也没有任何框架支持落地——其推理路径是在自定义架构上使用 trust_remote_code=True,且至少需要 PyTorch 2.8/CUDA 12.8 和 FlashAttention 2。

最后一点也适用于更小的模型,而且它违背了显而易见的假设。VideoJev-4B 正是你会期待能在普通硬件上运行的那个,但该模型卡自带的快速入门假设使用 H200、2 fps、最多 2,048 帧。还有一个更便宜的演示——一段十秒的片段、十个候选区间、打印出的概率——但论文的长视频结果使用固定的 262,144 token 上下文,帧上限为 640×640。4B 小的是参数量,未必是服务成本。
尝试一下,但不押注于此
因为检查点才是真正存在的东西,所以低风险的入门方式是:在基于 VideoJev 构建任何东西之前,先在本地用你自己的素材运行它——演示路径只需一次下载和十几行代码,而论文本身记录的失败案例(Video-MME 上的小物体计数,其中两种规模都漏掉了四本书的答案)正是你想在自己的数据上、而不是在 Charades 上遇到的。VideoJev-4B 和 VideoJev-35B-A3B 采用 Apache-2.0 许可,所以没有什么能阻止你。
OrcaRouter 的用武之地是工作流的另一半。视频决策界面本身很罕见;常见的是这样一种流水线:它还需要一个生成模型来写摘要、一个廉价分类器来门控昂贵的调用,以及某种在两者之间进行路由的组件。OrcaRouter 将 200+ 个模型置于一个 API 之后,0% 加价——供应商标价原样传递,因此供应商降价当天就能在这里生效——并具备 跨提供商自动故障转移、一个用于将多个模型组合成一次调用的路由 DSL,以及用于面板的模型融合。VideoJev 的检查点都不托管在这里,本文也不打算假装事实并非如此;它有两处能体现其价值:一是作为一条流水线的第二段,而这条流水线的第一段是本地模型;二是作为一个理由,让像这样的研究模型无需为周边的一切再签一份供应商合同就能试用。
什么能让这件事成为更大的新闻?
这篇报道的把关异常干净,因此值得直说:VideoJev 是一次研究发布,而不是一次产品发布。没有更新日志,没有定价页面,没有托管端点,没有候补名单,也没有厂商博客文章。存在的只有一份 2026 年 10 月 13 日提交的预印本、两个于 10 月 10 日上传的 Apache-2.0 检查点,以及一个在 10 月 14 日——也就是本文发表前一天——仍在被编辑的仓库。没有公告并不构成存在问题的证据,但这确实意味着,定调必须是“这些产物说了什么”,而不是“供应商声称了什么”。
有三种进展会改变这一格局。第三方评估在相同协议下、针对相同骨干网络复现 +6.7 和 +10.8 mIoU 的提升。一个 vLLM 或 SGLang 实现,这会把它从需要 trust_remote_code 的新奇玩物,变成能以高吞吐量对外提供服务的东西。或者由某方提供的托管端点,这会让 100× 的说法变成你能在自己视频上测得的数字,而不是从第六页表格里拿来的数字。在其中任何一项落地之前,有用的立场正是论文本身所持的立场:直接评分接口是一种真正不同的构建视频智能体的方式,而目前支持它的证据只是一个团队的一篇九页预印本。
把演示 notebook 一直开着,拿你手头最不体面的素材去跑它,并且在你自己完成校准之前,把置信度分数只当作一个排序来用。
发布也是回查以往出过哪些问题的时刻:围绕这一类模型,有记录的 AI 事故和智能体故障都汇集在 OrcaRouter AI 事故档案库中,其中每条记录都附有自己的信息来源、严重程度、置信度等级和争议标记。
