RSI-Jev 与 Jev 1.13：一个供你下载，一个供你调用

把 RSI-Jev v6.1-VL 4B 和 Jev 1.13并排放在一起，调用方注意到的第一件事就是：它们是同一个请求。给其中任意一个传入一个状态和一组带类型的问题——一道是/否题、一道从 k 个中选一的题、一道按评分标准打分的题——两者都会在一次前向传播中为每个选项返回一个校准后的概率，无需解析任何生成的文本。这并非巧合：RSI-Jev 有意遵循 Jev 的通信格式，因此，针对 TypeSafe 的 API 编写的客户端只需更改基础 URL，就能在它上面运行。不一样的是调用周围的一切。Jev 1.13 是 TypeSafe 的闭源商业模型，通过你按量计费的端点提供服务；RSI-Jev v6.1-VL 是一个 4.69B 参数的检查点，采用 Apache-2.0 权重，你可以下载并在自己的硬件上提供服务。两者都不是对方的换牌产品，两家供应商也都不为对方背书，而且这次比较中的几乎每一项数据都来自生成它的那一方。

主题上的日期很关键，因为这个项目大约每天都会发布一个版本。RSI-Jev v6.1-VL 4B 于 2026-10-07 由第三方 Shanghua-Gao/RSI-Jev项目发布——这是一个自我改进的研究循环，训练 Jev 风格的决策模型，并把每一个失败的试验连同成功的试验一并公开。这是该产品线十三天内的第八个版本，它是上一个版本与同一 Qwen3.5-4B-Base 的第二次微调的权重平均。Jev 1.13 是 TypeSafe AI 的模型，于 2026-09-15 发布，并自 2026-09-24 起收录在我们的产品目录中。下面这两个日期都很重要，因为与一个每天都在迭代的项目做比较，其结论的保质期只能以天计。

这两者实际上分别是什么，各用一行说明

Jev 1.13 是一个托管式决策模型，位于专用端点之后——POST /v1/systemone，非流式，输入预算约为 64,000 个 token，涵盖状态以及你的所有问题合计，定价为每百万输入 token $0.042，而输出计费为零，因为没有输出 token。其架构、参数数量和训练算力均未披露；TypeSafe 表示相关细节被严格保密，后续可能会发布一篇论文。你不运行它。你调用它，而每次调用都是一次计量的网络请求。

RSI-Jev v6.1-VL 是另一种完整配置。它是一个端到端微调的 Qwen3.5-4B-Base 塔，在第 16、20 和 32 层设有决策头，并由一个自包含、bf16 下为 9.7 GB 的检查点提供服务。参数量为 4.69B，值得了解这些参数去了哪里：32 个解码器层中 3.57B，词元嵌入中 0.64B，视觉塔中 0.33B，主决策头中 0.05B，两个提前退出头中 0.10B。没有混合专家，也没有第二个模型。你用仓库中的一条 pip 命令安装它，运行其服务器，从那时起，决策就绝不会离开你的基础设施。

• 谁来运行它——一个由你无法控制的按量计费托管端点，还是一个 9.7 GB 的检查点，跑在你自己的 GPU、Apple Silicon 或 CPU 上。

• 价格结构 — 每百万输入 token 收费 0.042 美元，输出免费；按调用付费，而边际成本为零，另加机器与运维成本。

• 输入预算 — 在托管模型上每次请求约为 64,000 个 token，而在该检查点上则为 32,768 个文本 token 外加图像预算；超出的内容会被直接拒绝，而不是截断。

• 权重与许可证——闭源、未公开规模，对比 Apache-2.0 权重、MIT 代码、46.9 亿参数。

• 模态 — Jev 的合同使用文本，而在 RSI-Jev 视觉版本上，每次请求为文本加最多四张图片。

• 所有权 — TypeSafe AI 的商业模式对比一个第三方研究项目，后者在其自己的许可声明中写明“与 TypeSafe AI 无关联”。

RSI-Jev 自己排行榜上的分数，以及为什么它只能算一半的对比

项目主打的数据是其在 Decision Index 0.3 上的得分：v6.1-VL 4B 为 50.98，高于前一个版本的 46.23。这是默认配置的完整运行结果——140,178 次请求，覆盖率 1.0——并且在项目自己的公开榜单上（日期为 2026-10-06），它追平了该榜单上最好的 4B 模型（50.98 对 ezjev 4B s2 的 50.82，该套件在 0.25 的容差下视为并列），总体在 113 个中位列第 27。在较旧的 Decision Index 0.2.1 上，它的读数为 50.74，而 v6.0-VL 为 46.24。其十五项基准测试套件在报告时未包含open_jev_ood任务（该任务被发现与训练行重叠）的情况下为 0.793，其留出集为 0.729。

那些数字中的每一个都是 RSI-Jev 自己的，是在 RSI-Jev 的测试框架上测得的。Decision Index 是一个公开的基准榜单，但上面没有 Jev 1.13 的读数，因为该项目的测试套件是为给开放决策检查点评分而构建的，而 Jev 是一个封闭端点。因此，把 50.98 与 Jev 在 typed-decisions 基准测试上的 0.727 放在一起比较并宣布胜者，正是应当避免的错误：这两个数字来自不同的测试框架、不同的样本量和不同的数据，而且没有人用一个测试框架同时跑过这两个模型。

唯一存在的头对头比较是 Laya 的，而不是 RSI-Jev 的。

有一项已发表的比较确实将一个 Jev 数值与一个开放检查点并列，而且它并非由这里的任何一方运行。Laya 决策模型的开发者 Convai Innovations 将 TypeSafe 已发布的 Jev 1.13.0 数据与自己的数据进行了对比制表，并自行指出了其中的局限：Jev 数值由第三方发布，从未由 Convai 测量，样本量和提示不同，而且该供应商并未列出该模型自己的基准测试。那张表值得一读，是为了校准，而不是为了下定论——而且它完全没有包含 RSI-Jev，因为该表发布时 RSI-Jev 尚不存在。

它确实展示的，是读者实际在权衡的“托管还是开放”这一问题的轮廓。在选项空间很大、模型必须稳定维持一个宽泛答案集的地方，托管模型领先；开放模型则在单次调用的原始延迟上胜出，因为路径中没有网络。这种模式里没有任何东西能告诉你，这两个具体模型中哪一个更适合你的任务；而诚实的立场是，公开层面还没有答案。

检查点能带来而端点无法带来的东西

RSI-Jev 最有力的论据不是分数，而是权重就在你的磁盘上。对于基于医疗记录、法律文件或客户账户历史做出的路由决策，“数据从不离开这栋楼”不是你可以拿来与基准分数做取舍的偏好——它是一项硬性要求，任何价位的托管端点都无法满足。这一特性同样消除了速率限制：供应商自己针对托管模型的文档指出，其限制会动态调整，并可能在不另行通知的情况下变更，而自托管的检查点除了你的硬件之外，没有这样的上限。

检查点带来的第二项好处是深度控制，而这一点很不寻常。由于决策头位于三个深度，effort设置决定了一个请求最多可以使用多少层：low在第 16 层停止，中位耗时约 23 ms，medium在第 20 层停止，耗时 27 ms，high在第 32 层停止，耗时约 40 ms，而 auto则在第一个足够有把握的出口作答，在该项目的测试套件上平均使用 32 层中的 19.5 层。这些延迟是该项目自己的数据，是在单块 H200 上以 bf16 实测得出，不应与任何托管服务的数字混为一谈——本地前向传播与按量计费的 API 调用并非同一种测量方式，而且 RSI-Jev 自己的文档明确指出，其早先与 Jev 公布的延迟所做的比较，是把本地 GPU 运算与一次网络往返放在一起对照。

第三件事是图像。Jev 的合约是输入文本，输出结构化的 JSON。RSI-Jev 视觉版本每次请求接收一到四张图像，以 base64 数据 URL 形式，状态通过标记引用每一张，并且 v6.1-VL 在项目的留出图像集上得分为 0.834。如果你的决策是“照片是否显示可见损坏”，那是托管合约根本不提供的能力。

你放弃的东西也是真实存在的，项目也公开了这一点。本次发布中校准变得更差，而非更好：最终期望校准误差在第 32 层为 0.048，使用 自动模式时为 0.055，而上一版本为 0.036 和 0.024。默认的单一阈值 0.95 在发布时明确未经确认——它是一条选择规则的兜底方案，而该规则自己选出的 0.85 在一半开发数据上都未能达到项目的深度上限。提前退出分支只读取文本，因此任何带图片的问题都会运行全部 32 层，无论 effort 设置如何。而且五个图像训练来源是非商业性或仅限研究用途的，项目明确表示，用非商业数据训练的权重是否会继承这些条款，目前尚无定论。

在哪里调用托管版本，以及在哪里不要调用

这是比较中与我们利害相关的那部分，因此值得精确对待。我们将 TypeSafe 的商业模型以 typesafe/jev-1.13 的形式部署在专用的 systemone 端点上——采用向 /v1/systemone 发起 POST 请求的方式，而非 OpenAI chat-completions 那种形态；为非流式，对应我们目录中所列的 65,536 词元上下文。它与 RSI-Jev 所实现的请求与应答形态相同，来自该项目所复制其合约的那个模型。RSI-Jev 本身我们并不托管；我们的目录中既没有 rsi-jev 这个 id，也没有 shgao 这个 id，想要该模型的读者需自行下载。

这里之所以要区分二者，原因很具体，也很有限。决策层很少构成整个工作流——它通常与一个生成式模型并排放置，由后者撰写回复、摘要或代码。这在过去意味着两份契约。对于托管的那一半而言，如今已不必如此：Jev 1.13 与 200 多个其他模型共用同一个密钥，按 供应商标价原样传递，0% 加价，因此如果 TypeSafe 调整费率，我们这边当天就会生效，而不是等到下一个计费周期。自托管的那一半从来不存在这个问题，因为供应商就是你自己。在两者之间做抉择，干净的做法是：先拿你自己标注的少量案例试试商业契约，看看开箱即用的表现是否好到足以据此自动化，然后再去判断自己运行一个 4.69B 检查点是否值得那些运维投入。

你究竟该选哪一个

如果决策必须留在你的边界内，如果你需要同时基于图像和文本做出决策，如果你的选项集达到数百个（该检查点每题最多接受 5,120 个选项），或者如果你想按请求调整深度和延迟，那就选 RSI-Jev v6.1-VL 4B。开始前请清楚，你采用的这个项目在十三天内变动了八次，其最新版本以校准换取了准确率，而且它自己的模型卡还列出了退出策略中它无法确认的部分。

如果你希望决策在无需服务栈的情况下也能运作，如果你看重一个由别人负责维持运行的端点，并且如果每百万输入 token 0.042 美元的价格——没有输出 token 需要计量——相对于你的调用量来说足够便宜，那就选 Jev 1.13。但也要明白，你调用的是一个闭源模型：其规模未披露，速率限制可能未经通知就发生变化，其公布的基准测试也不是你能重新跑一遍的。

两者共同拥有的东西比它们之间的差异更有用，而这正是这样的比较值得一写的根本原因。两个模型都不生成文本，因此二者都不会引入那种源自模型忘记闭合花括号或凭空捏造字段的失败类型。两者都返回概率，而在两种情况下，概率都是你在基于它自动化之前，必须用自己标注的数据加以验证的部分——延迟已经商品化了，而置信度值才是每次部署都必须靠自己赢得的东西。无论你落在下载与调用这条线的哪一边，先测试校准。