可本地运行的 Jev 替代品:Laya、零样本编码器与小型 LLM

Jev 是 TypeSafe 的闭源决策模型,只能通过 API 调用。下面的开源模型能在你自己的机器上完成同样的分类、是/否判断和打分,按与 Jev 的接近程度排列。

Jev 是什么,为什么没有本地版

Jev 是 TypeSafe 的 “System One” 决策模型:输入一个状态(文本或 JSON,最多 32,000 token)和类型化问题,它返回 Choice(选择)、Noul(是/否概率)或 Score(打分),并附带校准过的概率,而不是生成文字。它只通过 API 提供(OpenRouter 上的 typesafe/jev-1.13、TypeSafe 自己的 API 和 Cloudflare),按输入 token 计费,没有可下载的权重。下面这些模型可以在你自己的 GPU 或 CPU 上运行。

编码器:最接近的本地替代

小型分类编码器一次前向就能完成 Jev 的工作,占用不到 2 GB。其中只有 Laya 是按 Jev 的接口训练的:类型化的 Choice、Noul 和 Score 问题,并输出校准概率。

模型能回答校准概率权重内存许可证
Laya (English, typed-decisions, multilingual) Choice, Noul, Score 是 249 MB–850 MB
共 24 个文件,见 Laya 页面
GPU 或 CPU 上约 1–2 GB Apache-2.0
ModernBERT-large zeroshot v2.0 Choice, Noul 否 792 MB GPU 或 CPU 上约 1–2 GB Apache-2.0
DeBERTa-v3-large zeroshot v2.0 Choice, Noul 否 870 MB GPU 或 CPU 上约 1–2 GB MIT
GLiClass ModernBERT large v3.0 Choice, Noul 否 1,596 MB GPU 或 CPU 上约 1–2 GB Apache-2.0

零样本编码器把每个标签写成一个假设(“这段文字是关于账单的”),用自然语言推理打分,所以能回答选择题和是/否问题,但没有有序的 Score,也没有针对校准概率训练。它们用 Hugging Face Transformers 的 zero-shot-classification 流水线运行(GLiClass 用它自己的 gliclass 包)。

有多快:每次决策多少毫秒、每秒多少次

这类编码器很少受显存限制,真正要看的是速度。选模型、GPU、每行读多少 token、一次决策要几行,就能看到每次决策的耗时,以及这张卡每秒能处理多少次决策。

Laya:对同一段文本每问一个问题算一行。

– 每次决策

一次只处理一个请求: – 次/秒

许多请求合批处理: – 次/秒

Laya (English),每行 256 token,每次决策一行

GPU每次决策逐个处理合批处理
RTX 4070 12GB9.7–54 ms19–103 次/秒73–103 次/秒
RTX 5070 12GB7.3–53 ms19–138 次/秒77–138 次/秒
RTX 5070 Ti 16GB5.4–49 ms20–184 次/秒110–184 次/秒
RTX 5080 16GB5.1–47 ms21–197 次/秒141–197 次/秒
RTX 30905.2–51 ms20–192 次/秒89–192 次/秒
RTX 40904.8–45 ms22–207 次/秒207 次/秒
RTX 50902.7–44 ms23–367 次/秒262–367 次/秒
L40S2.2–46 ms22–453 次/秒177–453 次/秒
A100 80GB2.4–43 ms23–418 次/秒390–418 次/秒
H100 SXM0.8–41 ms24–1,238 次/秒687–1,238 次/秒
H2000.8–41 ms24–1,238 次/秒984–1,238 次/秒

不做估算:CPU、Apple Silicon、AMD 和 Intel 显卡,以及 NVIDIA 没有公布 BF16 张量算力的型号(RTX 3060、4060、4060 Ti、5060 Ti、4070 Ti Super、4080 Super、RTX PRO 6000、B200、DGX Spark)。

估算方法

  • 实测基准。ModernBERT 论文(表 2)在一张 RTX 4090 上实测了每秒处理的 token 数:ModernBERT-large 在 512 token 时 52,300、8,192 token 时 46,800;ModernBERT-base 为 148,100 和 123,700;DeBERTa-v3-large 在 512 token 时 24,600,输入长短不一、需要补齐时只有一半。Laya English 和 typed-decisions 是 ModernBERT-large;Laya multilingual 是 mmBERT-base,结构和非嵌入参数量与 ModernBERT-base 相同(mmBERT 论文第 3.1 节)。
  • 换算到其他 GPU。编码器的耗时一部分是矩阵运算,随张量算力变化;一部分是显存读写,随带宽变化。所以相对 RTX 4090 的速度落在两个比值之间,范围的两端分别按这两个比值算。张量算力用 NVIDIA 公布的 BF16 稠密值(RTX Blackwell 架构白皮书附录,L40S、A100、H100、H200 页面,稀疏值除以 2);带宽与LLM 速度计算器用的相同。
  • 每次决策。下限是 GPU 满负荷处理你这一个请求,且不低于把权重读一遍的时间。上限再加上每次调用 40 ms 的固定开销:laya 包公布的单问题耗时在 Tesla T4 上是 39.5 ms 和 32.8 ms,ggmlc 在 RTX 4050 笔记本上是 25 ms(模型卡);对短问题来说,这些时间大多花在分词、Python 和内核启动上,而不是计算。编译过模型、合批处理的服务接近下限;每个请求单独调用一次 laya 包接近上限。
  • 合批处理。请求足够多、每次前向都能把 GPU 占满时,每秒能完成的决策数:每秒 token 数除以一次决策的 token 数。在 RTX 4090 上就是论文的实测值,所以两端相同;在其他卡上,实际服务应落在这个范围内;如果把请求补齐到同一长度,会更低(ModernBERT 会去掉补齐,不受影响)。
  • 没有建模的情况:ggml 和 llama.cpp 运行时(F32 激活、不同的内核)、TensorRT 等 INT8/FP8 引擎、笔记本 GPU 和功耗限制。核对日期:2026-09-29。

支持 JSON Schema 输出的小型 LLM

任何对话模型都能回答 Jev 式的问题:把回复强制约束为一个 schema(例如 llama-server --json-schema 或 Ollama 的 format 字段),再从 token 对数概率里读出每个选项的概率。它能在你平时聊天用的 GPU 上运行,但答案是逐 token 生成的,比编码器慢,概率也没有校准。显存是本站在 Q4_K_M (MXFP4 for gpt-oss)、8K token 上下文下的估算;每个模型页有全部量化和上下文长度。

怎么选

  • 现在在用 Jev,想离线问同样的问题:选 Laya,它接受同样的类型化问题。
  • 只有英文标签或是/否检查,并且已经在用 Transformers:选零样本编码器。
  • 每段文本要打多个标签:选 GLiClass,一次前向给所有标签打分。
  • 决策更需要常识或推理而不是速度,并且有 3–16 GB 显存:选支持 JSON Schema 输出的小型 LLM。

Jev 的信息来自 OpenRouter 的 Jev 指南和 TypeSafe 文档;编码器大小来自 Hugging Face API;均于 读取。

常见问题

Jev 能在本地运行吗?

不能。Jev 只通过 OpenRouter、TypeSafe 和 Cloudflare 的 API 提供,没有公开权重。本地最接近的是开源的 Laya,它接受同样的 Choice、Noul 和 Score 问题。

最接近 Jev 的开源模型是哪个?

Laya。它是按 Jev 的接口复现的决策编码器(Apache-2.0),返回校准概率,文件小于 1 GB,4 GB 显卡或纯 CPU 都能跑。

可以用普通 LLM 代替 Jev 吗?

可以,但有代价。用 JSON Schema 约束输出后,Gemma 4、Qwen3 这类小模型也能回答选择题和是/否问题,只是速度更慢、显存更大(Q4_K_M 约 2.4–15 GB,gpt-oss 为 MXFP4),概率也没有校准。

更多计算器

更新于