Jev 与 Kev：一个在支持工单上击败 Jev 的 95 美元微调

Jared Palmer 于 2026 年 9 月 20 日发布了 Kev，距 TypeSafe AI 推出 Jev 仅五天；而关键数字并不在基准测试表中，而在 README 里：整件事在 Modal 上消耗的 H100 机时约花费 95 美元，外加用于生成评估数据的 3 美分 Jev API 调用。Kev 采用 Apache-2.0 许可，可自托管，基于 Qwen3.5 基础权重提供三种规模——约 0.8B、4B 和 9B——在冻结的基础模型上外挂了 rank-16 LoRA 适配器和一个指针头，而非从头训练一个决策模型。它完全复刻了 Jev 的类型化决策 API：Choice、Score 和 Noul，兼容到足以与 TypeSafe 自家的 Python SDK 对接。至于 Jev，它于 2026 年 9 月 15 日作为 TypeSafe AI 的闭源托管 System One 模型发布，返回带校准置信度的类型化答案，且完全不包含文本，并且从未公布其架构、参数量、训练算力或权重。因此，这一对比其实并非模型之间的对比。它检验的是：当 Jev 的价值能以一台二手笔记本电脑的价格在一个下午被复现时，其中还有多少能够留存下来。

基准测试实际上怎么说

核心结论是，Kev 已经非常接近，并且在一项范围很窄的任务上取得了胜利。在 Kev 锁定的新来源测试集上，Kev-9B 得分为 0.837，而 Jev 为 0.857。在跨 900 张工单的支持工单路由任务上——即 scienthoon 数据集——Kev-9B 得分为 0.952，而 Jev 为 0.897，这是已发布结果中唯一一个开放复现模型击败其所复现模型的结果。Kev 在一些逻辑识别任务上也略占上风。在 SemiF 决策集（一个包含 144 个问题的结构化集合）上，Jev 以 0.965 对 Kev-9B 的 0.917 胜出。

在 Kev 落败的地方，它输得很惨。域外准确率：Kev-8B 为 79.6%，而 Jev 为 85.7%。MMLU：70% 对 90%。MMLU-Pro：0.515 对 0.840。日期算术（精确到天）：60% 对 93%。模式很一致——Kev 在标签集小且领域固定的狭窄路由和分类任务上具有竞争力，但在任何需要世界知识或多步算术的任务上都会崩溃，因为世界知识并不存在于一个冻结的小型基础模型上的 rank-16 适配器里。

那些数字中的每一个都来自 Kev 自己的测试装置或第三方追踪器，而 Palmer 的 README 明确表示，这不是一次受控比较——Jev 的训练数据未披露，因此根本无法构建这样的比较。README 还声明，训练中未使用任何 Jev 的输出。这两条免责声明都属于让这些数字更可信、而非更不可信的那一类：发布这份比较的人，正是那个告诉你它无法证明什么的人。

花95美元能得到、而从Jev那里无论出多少钱都得不到的东西

成本比较正是这两个产品彻底不再具有可比性的地方。Jev 每百万输入 token 收费 $0.042，输出免费，这种便宜程度在按调用计费的基础上确实难以超越——但它是一个托管的、早期访问 API，还需要排队等候，而且 TypeSafe 表示速率限制可能会在不另行通知的情况下变更。Kev 则是你下载的权重。第一千万次分类的边际成本就是你自己的电费。

由此可以得出四点，而它们都与基准测试分数无关。

• 数据不会离开你的基础设施。Jev 是一个托管端点；你发送给它的每一个状态——支持工单、日志行、医疗记录——都会发送到 TypeSafe。Kev 在你自己的 GPU 上运行，对于受监管的工作负载而言，这不是偏好，而是决定性因素。

• 没有速率限制，没有候补名单，也没有弃用风险。TypeSafe 自己的文档指出，速率限制可能随时变更，恕不另行通知。而本地检查点则没有这样的条款。

• 你可以对它进行微调。Kev 是一个可供专精化的基础，而产出它的 LoRA 配方是公开的。如果你的路由分类体系有 40 个类别，却没有任何通用模型能很好地处理，你可以用自己的标签进行训练——这正是 Palmer 所做的，成本以几十美元计，而不是以一支机器学习团队计。

• 上下文上限由你决定。Jev 文档中记载的请求预算约为 32,000 个 token，而 Choice 字段最多支持 255 个选项。Kev 继承的是 Qwen3.5 的窗口，该窗口要大得多；而选项上限是你自身服务栈的实现细节，并非供应商方面的限制。

Jev 仍拥有而 Kev 没有的东西

校准这一主张恰恰是无法干净迁移的那一个，而它正是 TypeSafe 宣传的核心。Jev 使用一种 TypeSafe 称为 RLCD——校准决策强化学习（Reinforcement Learning for Calibrated Decisions）——的方法训练，该方法优化的是让置信度值保持诚实，而不是让答案更受青睐。Jev 的每个答案都会附带一个针对各选项的概率分布，因此你的代码可以设置阈值：在最高区间自动执行，在中间区间标记，在最低区间升级处理。

Kev 产生相同的类型化形状和相同的概率输出，因为该 API 是刻意保持兼容的。至于这些概率是否经过校准，则是另一个问题，而诚实的答案是：两个模型都没有人发表过可靠性图。一项单独的校准审计报告称，Jev 在一项隐藏策略优先级任务中取得了 44.7% 的准确率，期望校准误差为 0.325，这表明 Jev 的校准情况因任务而差异悬殊，而非一种普适属性——而 TypeSafe 本身也告诫用户，应针对自己标注的示例来测试置信度阈值，而不是轻信已公布的行为。

Jev 还有一个特点是，它并不是在 Qwen3.5 上训练的。一个带 rank-16 适配器的 9B 模型存在知识上限，而 MMLU-Pro 上 0.515 对 0.840 的差距，正是这一上限的直观体现。如果你的路由决策偶尔需要知道某个东西是什么，那么 Jev 更大且未公开的架构正在完成 Kev 的适配器无法完成的工作。

延迟与部署形态

Jev 记录的端到端延迟为 70–500 毫秒，而在 TypeSafe 自己的对比中，前沿 LLM 调用为 3–329 秒；而在一次调用中增加问题几乎不会改变这一延迟，因为每个问题都是针对一次共享的状态读取并行评估的。在 H100 上运行 Kev-9B，单次前向传播也将处于同一数量级，但这一比较在任一方向上都不是同类比较：负载下共享 GPU 上自托管的 9B 模型，其延迟与托管式端点不同；而托管式端点也与你自己机架中的一台机器不同。可以不加保留地说的是，两者都足够快，可用于智能体循环中的逐轮使用，而且 Kev 的延迟取决于你控制的硬件，而不是别人承诺给你的服务等级。

对复制品的诚实解读

Kev 竟然存在这一事实本身就是关于 Jev 的证据，值得点明。一个闭源模型的行为，可以由一个人在五天内、花 $95、基于公开基础权重近似复现，这说明了它的优势中有多少来自架构，多少来自训练数据和推理服务。但这并不能推出 Jev 就容易构建——API 表面容易复制，而校准则不然。但这确实意味着，护城河不是接口，任何为生产路径评估 Jev 的人，都应该把这种可能性计入考量：对开放基础模型做一次微调，就能以一小部分投入，让他们走完大部分路。

这也是为什么还不该把生产路径押注在任何一个上的理由。如果你正在评估 Jev，明智的姿态是试用它但不做承诺——而 OrcaRouter 并不提供 Jev，因为 TypeSafe 的模型处于早期访问阶段，且使用自己的请求格式。我们覆盖的是这些决策模型所处工作流中的生成部分：200+ 个模型通过一个 OpenAI 兼容的密钥访问，按提供商标价透传，0% 加价，并具备自动故障转移。一个双模型架构——由廉价的决策层对流量进行分类，生成模型处理其余部分——在我们这边无需第二份供应商合同即可测试，如果决策组件在你的数据上被证明校准不佳，故障转移路径正是防止那演变成事故的关键。

裁决

如果你的决策任务范围狭窄、领域固定、数据量大且对隐私敏感，那么 Kev 是当下更站得住脚的选择，而且优势相当明显——权重归你所有，数据通路由你掌控，你可以用自己的标注做微调，而且在支持工单路由上，9B 检查点凭其自身公布的数据就已胜过 Jev。如果你的决策任务需要世界知识、多步算术，或者一个你打算据此实现自动化的置信度值，那么 Jev 更大的未公开模型及其 RLCD 训练正在发挥实实在在的作用，而 Kev 的适配器无法替代这两者中的任何一个。

两项对比都未能解决的一件事是校准，因为还没有人为任一模型发布过可靠性图。在你针对其中任何一个进行自动化之前，先在你自己的带标签案例上测试这一点——置信度价值是这两款产品中必须通过每次部署来赢取的部分，而速度则是已经商品化的部分。