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

Jared Palmer 于 2026 年 9 月 20 日发布了 Kev，五天后 TypeSafe AI 推出了 Jev；而重要的数字并不在基准测试表格里。它在 README 中：整个项目在 Modal 上花费了约 95 美元的 H100 机时，外加用于生成评估数据的三美分 Jev API 调用费。Kev 采用 Apache-2.0 许可，可自托管，提供三种规模，均建立在开放的 Qwe​n3.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 的价值还能剩下多少。两个模型都不是新的——Jev 1.13（typesafe/jev-1.13）是 9 月 15 日的发布版本，而 Kev 在五天后跟进——但最近这个比较中有一件事确实发生了变化：2026 年 9 月 24 日，OrcaRouter 将 Jev 1.13 加入其目录，因此这对组合中的决策部分现在与生成部分使用同一个密钥作答，而不再仅通过厂商自己的端点。

基准测试实际上怎么说

核心结论是，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 美元，输出免费——这是 TypeSafe 自家价格表上的费率，也是我们 typesafe/jev-1.13 的模型卡所载明的费率——按每次调用来看，这种便宜确实很难被超越。它是一个托管 API，而 TypeSafe 自己的主页仍将其描述为处于早期访问阶段；这是厂商自己的措辞，而过去位于其后的等待名单已经没了——TypeSafe 于 2026 年 9 月 21 日将其移除，如今其模型文档公布的取而代之的是服务限制本身：每秒 100,000 个 token，每个账户每秒 40 次请求，并会动态调整，如有变更恕不另行通知。Kev 则是你自行下载的权重。第一千万次分类的边际成本，就是你自己的电费。

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

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

• 没有第三方速率限制，没有受限访问，也没有弃用风险。TypeSafe 自己的文档保留随时调整这些已公布限额的权利，这与你自己磁盘上的检查点有着本质区别。本地检查点没有这样的条款。

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

• 上下文上限由你自行决定更改。Jev 文档中记录的请求预算是 64K token，其中 32,000 是状态加上单个最长的问题，而非单独的配额；Choice 字段最多支持 255 个选项。Kev 继承的是 Qwe​n3.5 的窗口，要大得多，而选项上限是你自己服务栈的实现细节，而非供应商的限制。

Jev 仍拥有而 Kev 没有的东西

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

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

Jev 还具备的一点是，它没有在 Qwe​n3.5 上训练过。一个带有 rank-16 适配器的 9B 模型存在知识上限，而 MMLU-Pro 上 0.515 与 0.840 之间的差距，正是这一上限的可见体现。如果你的路由决策偶尔需要知道某个东西是什么，那么 Jev 更大的未公开架构正在完成 Kev 的适配器无法完成的工作。

延迟与部署形态

Jev 官方记录的端到端延迟为 70–500 毫秒，而在 TypeSafe 自己的对比中，前沿 LLM 调用为 3–329 秒；并且在一次调用中增加问题几乎不会改变延迟，因为每个问题都是针对同一次状态读取并行评估的。对于该厂商的说法，有一个实测的对应数据，而且它来自我们，而非 TypeSafe：自 2026 年 9 月 24 日起，我们的 typesafe/jev-1.13 模型卡为该模型提供服务的这七天里，请求延迟中位数为 151 毫秒，第 95 百分位为 247 毫秒。这是单条路由的服务记录，而不是基准测试。Kev-9B 在 H100 上单次前向传播的延迟会处于同一数量级，但这一比较无论从哪个方向看都不是同类对比：负载下运行在共享 GPU 上的自托管 9B，其延迟与托管端点并不相同，而托管端点也与你自己机架里的一台机器不同。可以毫不含糊地说的是：两者都足够快，可用于智能体循环中的逐轮使用；而且 Kev 的延迟取决于你所掌控的硬件，而不是别人向你承诺的服务等级。

对复制品的诚实解读

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

这也正是目前不应把生产路径押注在二者中任何一个之上的理由。如果你正在评估 Jev，明智的姿态是先试用，而不对其作出承诺——而自 2026 年 9 月 24 日起，这已经可以在我们的密钥上做到：OrcaRouter 以 typesafe/jev-1.13 提供 Jev 1.13，通过与它在各处使用的同一个 POST /v1/systemone 端点、同一种非流式请求格式调用，上下文为 65,536 个 token，输入 token 每百万 $0.042，输出计费为零。决策层与生成层如今位于同一个账户之下：200 多个模型，共用一个 OpenAI 兼容密钥，按提供商标价透传，0% 加价，并具备自动故障转移。一种双模型架构——由廉价的决策层对流量进行分流、由生成模型处理其余部分——可以在我们这边测试，无需再签第二份供应商合同；而如果决策组件在你的数据上校准得很差，故障转移路径正是防止其演变成事故的所在。

裁决

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

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