一张生成的标题卡,眉题是“对比——无共享基准”,主标题是“VideoJev 对比 Jev 1.13”,副标题是“相同的架构赌注——两份不同的工作。一个接收视频并返回带评分的时间区间;另一个接收文本状态并返回带类型的决策。”两个面板分列于一条竖直分隔线的两侧:VideoJev 写着“输入:2 fps 的视频帧,上限 640x640”“输出:一个时间戳,或一个选项索引”“交付:自托管的 Apache-2.0 权重”;Jev 1.13 写着“输入:文本状态——字符串、JSON、数组”“输出:一个带类型的标签、等级或概率”“交付:按量计费的托管端点”。下方一条打叉的横条写着“没有任何任务能被两个模型同时接受——任何头对头对比表都将是凭空编造的。”OrcaRouter 标志合成在右下角。
Guides & Insights

VideoJev 对比 Jev 1.13:理念相同,用途不同

作者

Gideon Frost

发布日期

最新模型 · 20查看全部模型 →
基准测试:Artificial Analysis · 每日更新
返回全部文章

这个比较看起来显而易见,直到你试着把它写出来。VideoJev是南京大学 MCG 实验室发布的一项开放权重研究成果,它会根据视频证据对时间区间和答案选项进行评分,并有两个检查点:VideoJev-4B 和 VideoJev-35B-A3B。Jev 1.13是 TypeSafe AI 的闭源、托管决策模型——正是为它们二者共同所属的类别命名的那个模型。VideoJev 自己的论文将 Jev 引用为其所扩展范式的源头,这让这看起来像是一场正面较量。但大体上并非如此。Jev 1.13 接收文本状态并返回类型化决策。VideoJev 接收视频并返回评分区间或选定的选项。它们在理念上重叠,在输入上几乎毫无重叠,因此有用的问题不是“哪个更好”,而是“哪一个才真正有资格胜任你手头的任务”。

两者都在近期悄然到来,只是方式不同。Jev 1.13 于 2026-09-15 发布——TypeSafe 隐身两年后的首个公开模型——并且一直可通过 OrcaRouter 自有的目录调用,自 2026-09-24 起在 typesafe/jev-1.13 上可用。VideoJev 则完全没有发布:arXiv 预印本于 2026-10-13 上线,两个 Apache-2.0 检查点于 2026-10-10 上传到 Hugging Face,而代码仓库在 2026-10-14 仍在接收 README 修复。如今,两者都算不上发布故事。让这一组合值得一读的是,它们是同一个架构押注应用于两种不同数据类型,而各自交付方式的差异告诉了你做出决定所需的大部分信息。

每行一条,因为摘要很快就会各走各的

Jev 1.13 是一个托管式端点。你向 /v1/systemone POST 一块状态数据以及一组具名问题,每个问题都会返回一个带类型的答案——noul(带校准概率的真/假值)、choice(最多 255 个选项中的一个标签)或 score(有序 2 至 10 级量表上的一个级别)。它不生成内容,因此没有输出 token,TypeSafe 也不对其计费;输入为每百万 token 0.042 美元。其架构、参数量和训练算力均未披露。其输入仅为文本——字符串、JSON、数组——没有图像、音频或视频通路。你并不自行运行它;每次调用都按量计费。

VideoJev则是一种相反的安排。它是一个你可以自行下载并部署的检查点,采用 Apache-2.0 许可,通过在现有多模态 LLM 上进行微调构建:VideoJev-4B 基于 Qwen3.5-4B,VideoJev-35B-A3B 基于 Qwen3.6-35B-A3B。作者去掉了最终的 MLP 和语言模型输出头,并用候选评分器取而代之,因此该模型从不生成答案——它直接对候选区间和候选答案进行评分。两种推理模式对其加以组织:缓存推理将视频编码一次,并让每个新查询从该前缀分支出去,而 联合推理则将一组问题放在同一个视频前缀之后,并在一次前向传播中全部读出。

真正将它们区分开来的维度

• 输入模态 — 视频,2 fps,VideoJev 的帧上限为 640×640,而 Jev 1.13 仅使用文本状态。

• 什么是“决策”——是以秒为单位的时间区间加上选项索引,还是带类型的标签、等级或概率。

• 交付方式 —— 自托管的 Apache-2.0 权重,对比按用量计费的托管端点。

• 价格 — 自建 GPU 机时 vs 每百万输入 token 仅 $0.042,输出不计费。

• 同一上下文上第二次查询的成本——VideoJev 的整个设计难题,靠前缀复用得以解决;Jev 每次调用都会重新发送状态,因为它没有视频规模的前缀可供摊销。

• 已发布细节——一份九页的预印本,包含各基准的逐项表格和消融实验,但未披露架构、参数或训练信息。

• 你可以在哪里运行它 —— 只要你有合适的 GPU,在哪里运行都行,而不像 TypeSafe 的端点以及承载它的那些网关,包括 OrcaRouter 上的 typesafe/jev-1.13。

注意那份清单上没有什么:一个共享的基准测试。没有任何一项是这两个模型都被评过分的,因为没有任何任务两者都能接受。任何把它们并排放在一起的表格,都只是在凭空编造一项对比。

A generated infographic headed 'The dimensions that actually separate them' with the eyebrow 'Where they diverge', listing seven rows that each carry both models on one line: input modality (video at 2 fps capped 640x640 versus text state only); what a decision is (an interval in seconds plus an option index versus a typed label, level or probability); delivery (self-hosted Apache-2.0 weights versus a metered hosted endpoint); price (your own GPU hours versus $0.042 per million input tokens with output billed at zero); second query on the same context (prefix reuse via Cached or Joint inference versus state re-sent per call); published detail (a preprint with per-benchmark tables versus no architecture or training disclosure); and where you can run it. A footer reads that nothing both models are scored on exists, because no task accepts both input types. The OrcaRouter logo is composited in the bottom-right corner.

在传承真实之处,以及它止步之处

智识债务是明示的,而非推断出来的。VideoJev 的引言将其贡献框定为:接过 System One 的前提——模型可以输出一个结构化判断,而不是生成 token——并追问当被判断的对象带有时间线时,会发生什么变化。对于“模型如何在不写作的情况下做出决定?”这个问题,Jev 的答案是:在一个已声明的选项集之上加一个评分头。VideoJev 的答案则是同一个评分头,只不过同时指向时间戳和标签。

那项扩展并非表面功夫,而论文对其中缘由的说明异常具体。当底层上下文是视频时,昂贵的部分是视觉编码,而一个针对同一段素材提出六个问题的智能体,不应为它支付六次代价。VideoJev 的两种推理模式都是为了解决这个问题,而数字显示了它们能换来什么:在一个视频上进行十次定位查询时,VideoJev 为 0.39 秒,而 Instruct 基线为 5.98 秒;在问答方面,十个查询用时 1.67 秒。Jev 没有对应物,因为文本状态重新发送的成本很低——Jev 解决的是每次调用的决策延迟,而 VideoJev 解决的是决策延迟——首次之后每次调用中的延迟。

分界线在于模态。TypeSafe 自己的文档明确指出,System One 的输入是文本——“字符串、JSON 对象和文本数组”——并且不支持图像、音频和视频。因此,这两个模型在任何任务上都不能相互替代。如果你的状态是文档、聊天记录或表单提交,VideoJev 无法处理。如果你的问题是“在这段录像中,穿绿衣服的女人什么时候吃意大利面”,Jev 1.13 也无法处理。

A generated side-by-side graphic headed 'Where they can and cannot meet' with the eyebrow 'Side by side, honestly'. One band for VideoJev reads 'video input - timestamp or option - self-hosted weights'; a second band for Jev 1.13 reads 'text state input - typed label, level or probability - metered hosted endpoint'. A crossed-out strip beneath them reads 'No shared task. No shared benchmark.' A footer reads 'Different inputs entirely - a head-to-head scoreboard would be invented, so there is none here.' The OrcaRouter logo is composited in the bottom-right corner.

这些数字,以及它们是由谁产生的

VideoJev 的核心数据来自作者自己的评测框架,尚未被独立复现。VideoJev-4B 在三个时序定位基准上的平均 mIoU 达到 65.3,比其 Qwen3.5-4B 主干高 6.7 个点;VideoJev-35B-A3B 达到 67.7,比 Qwen3.6-35B-A3B 高 10.8 个点。在四个视频 QA 基准上,两者平均分别为 74.3 和 79.5,分别比其 Thinking-mode 主干低 0.6 个点和高 0.7 个点,而速度分别是后者的 129 倍和 100 倍。论文还进行了一项受控对比——一个普通的自回归 Qwen3.5-4B,在完全相同的数据和相同训练计划下微调——而 VideoJev 在定位 mIoU 上比它高 1.3 个点,在 QA 分数上高 1.9 个点。该对照是论文中最强的证据,因为它将读出形态与训练数据隔离开来。

如果你打算依赖它,有两点需要注意。论文报告称,在 4B 上平均校准误差为 8.65 分,在 35B-A3B 上为 8.13 分,这意味着这些分数是很好的排序信号,却是很差的概率——把 0.9 当作“排在列表最前面”,而不是“有 90% 的可能性”。此外,根据项目页面,35B 检查点的主打配置是 FP32,因此较大模型的内存占用比参数量所暗示的更重。

Jev 1.13 的数据同样由厂商公布,但它们属于可以通过调用它来核实的那一类:每百万输入 token 固定 0.042 美元,输出成本为零,端到端响应时间为 70–500 毫秒。TypeSafe 也坦率说明哪些说法不可证伪、哪些并非如此,并指出“无类型错误”无法用反例证伪,因为超出你所声明集合的值不是模型能够输出的值。

如果你两者都需要,那你就面临两个采购问题。

正是在这里,交付方式的差异不再停留在哲学层面。VideoJev 是以代码仓库的形式出现的:PyTorch 2.8、CUDA 12.8、FlashAttention 2、trust_remote_code=True,以及一个在长视频设置下默认假设使用 H200 的快速上手示例。目前还没有 vLLM 或 SGLang 支持,所以它不是那种你明天就能拿来以高吞吐提供服务的东西。你接手的是一个推理栈,而不是一段供应商关系。

A headless-browser capture of the OrcaRouter catalogue page for TypeSafe Jev 1.13, showing the model name and the identifier typesafe/jev-1.13, the description of it as a structured decision and evaluation model served through a single non-streaming endpoint, the per-million-token input price of $0.042 with no output token charge, and the end-to-end latency figures.

Jev 1.13 以 API 密钥的形式发布,而这正是 OrcaRouter 直接发挥作用的地方:该模型已上架我们的目录,因此它与你正在构建的任何工作流中生成式的那一半共用同一把密钥——一个 API 覆盖 200+ 模型,0% 加价(按供应商标价原样传递,所以 TypeSafe 的价格一变,这里当天就生效),跨供应商自动故障转移,还有一套路由 DSL,方便你把多个模型组合成一次调用。VideoJev 并不托管在这里,本文也不会假装它托管在这里。要运行它,意味着下载 Apache-2.0 权重并搭建你自己的服务;我们替你卸下的是它周围的一切——撰写结果摘要的总结器、判断这次视频调用到底值不值得发的更便宜的分类器,以及当某个供应商出状况时的回退方案。

决策规则

坦率的总结是:这两者更像同族,而不是竞争关系。选择 Jev 1.13,当判断对象是文本、答案是你预先声明的一组选项之一,并且你希望由别人来运行基础设施和校准工作时。选择 VideoJev,当证据是视频、答案是时间戳或多项选择,并且你有 GPU 和意愿去运行一个未经复现的研究发布时——先严格审视你自己的素材,因为论文记录了它自身的失败模式(小物体计数,即两种规模都会漏掉一个四本书的答案),而你的会不同。

真正会改变局面的是第三个检查点,而不是一个赢家。这两个模型都还远算不上通用视觉智能体:Jev 看不见,而 VideoJev 只能回答它受过训练的两种问题形式。真正有意思的消息会是发布带文本路径的 VideoJev,或者发布能接受帧的 Jev——到那时,两条路线就会汇合,这就不再是两篇关于两种范式的文章,而会变成一篇关于一场争斗的文章。

发布也是回查以往出过哪些问题的时刻:围绕这一类模型,有记录的 AI 事故和智能体故障都汇集在 OrcaRouter AI 事故档案库中,其中每条记录都附有自己的信息来源、严重程度、置信度等级和争议标记。