可本地运行的 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 12GB | 9.7–54 ms | 19–103 次/秒 | 73–103 次/秒 |
| RTX 5070 12GB | 7.3–53 ms | 19–138 次/秒 | 77–138 次/秒 |
| RTX 5070 Ti 16GB | 5.4–49 ms | 20–184 次/秒 | 110–184 次/秒 |
| RTX 5080 16GB | 5.1–47 ms | 21–197 次/秒 | 141–197 次/秒 |
| RTX 3090 | 5.2–51 ms | 20–192 次/秒 | 89–192 次/秒 |
| RTX 4090 | 4.8–45 ms | 22–207 次/秒 | 207 次/秒 |
| RTX 5090 | 2.7–44 ms | 23–367 次/秒 | 262–367 次/秒 |
| L40S | 2.2–46 ms | 22–453 次/秒 | 177–453 次/秒 |
| A100 80GB | 2.4–43 ms | 23–418 次/秒 | 390–418 次/秒 |
| H100 SXM | 0.8–41 ms | 24–1,238 次/秒 | 687–1,238 次/秒 |
| H200 | 0.8–41 ms | 24–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 上下文下的估算;每个模型页有全部量化和上下文长度。
| 模型 | GGUF 文件 | 显存 |
|---|---|---|
| MiniCPM5 2B | 1,616 MB | 2.42 GB |
| Granite 4.2 3B | 2,317 MB | 3.46 GB |
| Nemotron 3 Nano 4B | 2,900 MB | 3.10 GB |
| Gemma 4 E4B | 4,977 MB | 5.64 GB |
| Qwen3 8B | 5,028 MB | 6.81 GB |
| Granite 4.2 8B | 5,539 MB | 7.32 GB |
| Qwen3.5 9B | 5,681 MB | 6.76 GB |
| Gemma 4 12B | 7,122 MB | 8.57 GB |
| gpt-oss-20b | 12,110 MB | 14.8 GB |
怎么选
- 现在在用 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),概率也没有校准。
更多计算器
- 微调显存计算器 Transformers 或 Unsloth 中全参数微调、LoRA、QLoRA 需要的显存,并与公开实测对比。 打开 →
- 图像与视频模型显存计算器 FLUX.2、Wan 2.2、LTX-2 和 Qwen-Image 在 ComfyUI 中的峰值显存与系统内存,按精确文件大小计算,并与公开实测核对。 打开 →
- Laya 显存需求 Laya 决策编码器三个模型的真实文件大小、运行内存,以及 PyTorch、ggmlc、llama.cpp 三种运行方式。 打开 →
- Bonsai 2 27B 显存需求 Ternary Bonsai 2 27B 各文件的真实大小、8–24 GB 显卡能开的最长上下文,以及 5.95 GB 与 8.60 GB 两种说法的来源。 打开 →
- vLLM KV cache 与并发计算器 vLLM 分配的 KV cache 池有多少 token、能同时处理多少请求,并给出 vllm serve 命令。 打开 →
- 我的电脑能跑什么? 在浏览器里识别你的 GPU,列出它能跑的本地大模型,以及最佳量化和速度。 打开 →
更新于