Jev 101 logo
Jev 101

自托管 · 开源 · 2026-09 快照

自托管 Jev：真正能跑起来的方案，与它们需要的硬件

TypeSafe Jev 是托管 API——SDK 只是客户端，其条款也禁止用它的输出开发同类产品。真正能自托管的是它周围的开源生态。本文一张矩阵收拢十条路线，每条配一个最小可跑的安装命令。

速查

完全没有 GPU？选 Von——395M 参数、磁盘约 1.5GB、CPU 上低于 15ms。MacBook？Kev 走 MLX（47ms），或 Laya-MLX（M3 Max 上 p50 13.4ms）。只有一块消费级显卡？追速度选 cbjev，要微调选 Laya，想零训练复用 4B 模型选 SemIf。有服务器预算？H100 上跑 Kev 或 JevK5，24GB 显卡跑 DiffusionGemma，B200 跑 openjev-sglang。至于 Jev 本体：托管、闭源权重、不可自托管。

本页所有数字均为第三方公开口径或对公开仓库的阅读（2026-09-23/26 快照），不是本站实测。这个生态一周一变，引用前请重新核实。

先说诚实的答案

你不能自托管的东西

Jev 本体。TypeSafe 以托管 API 的形式提供它；Python 和 TypeScript 包只是走网络调用这个 API 的客户端。没有公开的 Jev 权重，没有离线模式，而且主客户协议 2.3(b) 禁止利用该服务或其输出开发同类产品。

你能自托管的东西

围绕它长出来的开源生态，分三族：训练出来的决策模型（Laya、Von、cbjev、NanoJev、JevK5），读取你已有模型的选项 logits 的适配层（Kev、SemIf、AnyJev、simple-jev），以及扩散路线的服务端（OpenJev、openjev-sglang）。大多数暴露同一套 /v1/systemone 契约，现有的 TypeSafe SDK 调用换一个 base URL 就能活下来。

安装与硬件矩阵

十条路线，一行一个：最低硬件要求、体积占用、项目方或测试者报告的延迟、一行安装命令。有内链的项目进我们的逐项拆解页，其余直达源仓库。

项目许可证最低硬件体积占用延迟（自报口径）安装最适合
VonwfzyxApache-2.0完全无显卡——笔记本、边缘设备、纯 CPU 容器395M 参数，磁盘约 1.5GBCPU 上单次判定低于 15msgit clone + von-sdk最便宜的部署形态；边缘侧纯 CPU 分流
LayaConvai InnovationsApache-2.0CPU 开箱即用；参考 GPU 是 T4；内置多语 Router421M 参数（另有 322M 多语 checkpoint）；Laya-MLX 移植版约 0.9GBT4：32.8–39.5ms/题，十题批 7.2ms · RTX 5090：22ms · M3 Pro CPU：三题 66mspip install laya在自己标注上微调的基座；多语 checkpoint 覆盖 100+ 语言
cbjevtomek7667GPL-3.0-or-later单张消费级显卡（参考环境 RTX 4090）每个 checkpoint 约 800MBRTX 4090 上 3.0–31.4ms；比 Laya 快 1.5–6.9 倍pip install -e ".[serve]"最快且标定良好的编码器；单题控制在 30 个选项以内
KevJared PalmerApache-2.0Apple Silicon（MLX）或 CUDA 服务器0.8B / 4B / 9B；4B 约 9GB bf16，9B 约 17–19GBMLX 47ms（重复 state）/ 77ms（新 state）· H100 12–26ms · 旧 MPS 213ms · M5 780msuv sync --extra serve即插即用的 /v1/systemone 替换；MacBook 上即可训练微调
SemIfTheo LeeMIT（代码）一张 RTX 3090（参考环境，BF16 4B）；llama.cpp 可走 CPU；Apple Silicon 走 MLX/MPS冻结的 Qwen3.5-4B；Q4_K_M GGUF 约 3GB（可在浏览器里跑）3090 上 21 项判定 1.023s，对生成 JSON 的 5.332s（快 5.21 倍）· 复用 state 时 20.03 决策/秒git clone (see README)零训练：在你已经托管的开源模型上直接读 logits
JevK5allebeeApache-2.0H100 跑出头条数字；纯 CPU 也能跑但慢；llama.cpp GGUF 支持 NVIDIA/AMD/Intel/Applebf16 约 9GB（4B）/ 约 19GB（9B）；GGUF 2.0–9.5GBH100 p50 13.2ms（easy/standard）、30ms（hard）（9B：p50 32ms）· CPU 约 0.25s（2B）/ 0.6s（4B）jevk5-serve (repo + HF weights)保持线级兼容的开放权重；JevBench v1.2 上最接近 Jev 的开源分数（62.04 对 63.29）
NanoJevTianyuCodings仓库未声明（第三方标注 MIT）必须 CUDA 显卡——没有 Apple Silicon 路径Qwen3-0.6B 骨干 + 决策头未公布 p50；为紧凑控制回路而生（自建评测上 ViZDoom 128/128，Jev 56/128）git clone (train/eval pipeline included)研究与控制回路——它的评测集同时也是训练域
OpenJevrazorback16Apache-2.024GB 以上 NVIDIA 显卡（DiffusionGemma 26B-A4B NVFP4），或约 16GB 统一内存的 Apple Silicon（MLX）权重约 18GBRTX PRO 6000 上、并发 1 时 p50 27ms（单题）/ 31ms（三题）git clone (serves /v1/systemone)支持图像与最多 255 个选项的扩散路线；同一服务端还能代理 Laya 与 Verdict
openjev-sglangekzhang见仓库B200 级数据中心硬件SGLang 上的 Qwen3.6-35B-A3B未公布；面向 SGLang 批量服务git clone数据中心规模的协议高吞吐服务
AnyJev / simple-jevNokia · featherless-aiApache-2.0 · MIT你现有的大模型推理服务（vLLM、HuggingFace、llama-server）无新增权重（simple-jev）；AnyJev 的头每个约 100KBAnyJev L2 头的开销低于一次额外前向pip install "anyjev[hf]"零训练：把已经自托管的大模型直接变成决策层

延迟数字均为项目方自述或具名第三方在所述硬件上的测量——当作假设而不是保证。独立 49 任务测试中，最强开源模型（Von，395M）约 0.704，托管 Jev 为 0.966，所以无论选哪条路线，都要为标定和降级兜底留好位置。

八条路线，八个最小安装

每条路线从零到第一个 typed decision 的最短路径。命令在各个语言版本里完全相同，不同的只是命令前后的说明文字。

Von

路线一 · 无显卡

什么时候选它

当眼前根本没有显卡时。Von 是 395M 的 ModernBERT-Large 编码器加三个决策头——磁盘约 1.5GB、CPU 上单次判定低于 15ms——并且它是独立 49 任务基准上最强的开源模型（约 0.704）。被记录的失败模式：陌生域上会塌缩到单一模式，所以只让它干你招它来干的活。

Von
bash · clone + SDK
# Von needs no GPU: 395M params, ~1.5 GB on disk,
# each decision under 15 ms on a CPU.
git clone https://github.com/wfzyx/von.git && cd von
# follow the README to serve or call it in-process

# JavaScript callers can use the published SDK:
npm install von-sdk
Node SDK 的调用形状：decide({ state, question, options }) 返回 { choice, confidence }。低于你自己的阈值就走升级流程。

Laya

路线二 · 笔记本或免费档 GPU

什么时候选它

当你手上有几百条标注样本、并且打算微调时——这正是 Laya 擅长的工作。零样本它接近随机（typed decisions 上 0.362），所以 pip install 只是训练项目的第一步，不是成品替代品。非英语文本要选它而不是 cbjev，理由就是那个多语 Router。

Laya
bash · pip + serve
pip install laya

# python: load and predict — one forward pass, N questions
#   import laya
#   agent = laya.load("convaiinnovations/laya")
#   answers = agent.predict(state, questions)["answers"]

# serve the /v1/systemone contract for existing SDK callers:
laya-serve
v0.3.7 之后笔记本上加载约 4 秒。在留出集上重新拟合温度之前，别相信它打印的任何置信度。

cbjev

路线三 · 单张消费级显卡

什么时候选它

当编码器路线是对的、但 Laya 太慢或选项重排时翻转太多答案时——cbjev 从 Laya 微调而来，答案翻转率 0.2%（Laya 为 7.8%），4090 上快 1.5–6.9 倍。两个注意点：它是 GPL-3.0-or-later；英文 checkpoint 只懂英文，其他语言要走多语 checkpoint。

cbjev
bash · clone + editable install
git clone https://github.com/tomek7667/cbjev.git && cd cbjev
pip install -e ".[serve]"

# GPL-3.0-or-later — check licence compatibility before adopting.
单题控制在 30 个选项以内；再往上，它的准确率掉得比 Jev 更快。

Kev

路线四 · MacBook MLX 或 H100 即插即用

什么时候选它

当你想要最短迁移路径时：Kev 说同一套 /v1/systemone 契约，TypeSafe SDK 调用换个 base URL 就活下来。它能在 MacBook 上训练微调（MLX 重复 state 47ms），H100 上到 12–26ms。采用前先读它自己公布的数字：held-out 新来源上 0.822（Jev 0.857），高置信错误率 4.0% 对 3.7%。

Kev
bash · uv + serve + curl
git clone https://github.com/jaredpalmer/kev.git && cd kev
uv sync --extra serve

# serve the 0.8B checkpoint on your own hardware
KEV_DTYPE=bf16 uv run --extra serve python -m kev.serve \
  --run jaredpalmer/kev-0.8b --port 8009

# the same request shape Jev uses
curl -s localhost:8009/v1/systemone \
  -H 'content-type: application/json' \
  -d '{"model":"kev-latest","state":"...","questions":{...}}'
最初发布的是 0.5B；现在的主流是 Qwen3.5 上的 0.8B/4B/9B。显存：4B 约 9GB bf16，9B 约 17–19GB。

SemIf

路线五 · 零训练，一张 3090

什么时候选它

当你已经在跑开源模型、并且坚决不训练任何东西时。SemIf 是一个读出工具：它从冻结的 Qwen3.5-4B 的 logits 里一次前向给声明的选项打分——项目参考环境就是一张 RTX 3090，而且同样的活比让模型写 JSON 快 5.21 倍。它还有 llama.cpp 的 CPU 后端、MLX/MPS，甚至浏览器 WebGPU demo，所以显卡是锦上添花不是必需品。

SemIf
bash · clone, no weights shipped
git clone https://github.com/TheoLeeCJ/SemIf.git && cd SemIf
# reference run: one RTX 3090, frozen Qwen3.5-4B, BF16
# also runs on CPU via llama.cpp; MLX / MPS on Apple Silicon
#
# the idea, in three lines:
#   probs = read_option_logits(model, state, question, options)
#   decision = max(probs, key=probs.get)
#   if probs[decision] < 0.85: decision = "human_review"
作者很坦诚：它复刻的是接口模式，不是 Jev 的准确率——102 行对齐子集上 0.845 对 0.883。上线前按负载做标定。

JevK5

路线六 · 开放权重，vLLM / GGUF 服务

什么时候选它

当你想要既开放权重、又说 Jev 线级格式的方案时。JevK5（Apache-2.0，4B/9B，Qwen3.5 加蒸馏 LoRA）通过 jevk5-serve 以 /v1/systemone 契约提供服务，JevBench v1.2 上 62.04 对 Jev 的 63.29，是该榜单最接近的开源数字。GGUF 版本（2.0–9.5GB）经 llama.cpp 可跑 CPU 与 Apple Silicon，单次短决策约 0.25–0.6 秒。需要知道的限制：仅英语、单题 16 个选项、输入上限 16,384 token。

JevK5
bash · repo + Hugging Face weights
git clone https://github.com/allebee/jevk5.git && cd jevk5
# weights on Hugging Face:
#   alibiserikbay/JevK5 (4B) · alibiserikbay/JevK5-9B · JevK5-GGUF
#
# jevk5-serve speaks /v1/systemone — Jev-wire-compatible.
# bf16 needs ~9 GB (4B) or ~19 GB (9B) of GPU memory;
# the GGUF route runs on NVIDIA / AMD / Intel / Apple via llama.cpp.
它自己跑的 hard 档是 0.784，对 Jev 公布的公开 hard 半区 0.730——但那是它自测，不是官方 JevBench 分数。仅支持英语；单题上限 16 个选项。

NanoJev

路线七 · CUDA 研究机

什么时候选它

当你想自己训练一个决策模型、而不只是部署一个时。NanoJev（Qwen3-0.6B 加决策头，第三方标注 MIT）带完整训练与评测流水线，而且是唯一在某个任务上真赢过 Jev 的开源项目：自建评测上 ViZDoom Basic 128/128，Jev 56/128。诚实的边界：那四款游戏同时也是它的训练域——迷宫测试集上 Jev 以 7/10 反超——所以别拿它去做工单分流。

NanoJev
bash · clone, CUDA required
git clone https://github.com/TianyuCodings/NanoJev.git && cd NanoJev
# Qwen3-0.6B backbone + decision heads.
# The inference script expects CUDA — there is no Apple Silicon path.
# Training + evaluation pipeline ships with the repo
# (a Chinese README is available).
相信任何数字之前先在自己的环境里评测：公布的 harness 成绩来自模型训练的同一个域。

OpenJev + openjev-sglang

路线八 · 扩散路线：工作站到数据中心

什么时候选它

当你的 state 含图像、或选项列表数以百计时——扩散路线是唯一吃图像输入的，OpenJev（razorback16）以 DiffusionGemma 26B-A4B 服务最多 255 个选项，RTX PRO 6000 上 p50 27ms。整个家族都要背一条 LocalJev README 的警告：线级兼容，不等于数学等价。到数据中心规模，openjev-sglang 用 SGLang 服务 Qwen3.6-35B-A3B，面向 B200 级批量吞吐。

OpenJev + openjev-sglang
bash · two repos, two scales
# workstation scale: DiffusionGemma 26B-A4B on a 24 GB+ NVIDIA GPU
# (~18 GB weights, NVFP4) or ~16 GB Apple silicon via MLX
git clone https://github.com/razorback16/openjev.git && cd openjev

# datacenter scale: Qwen3.6-35B-A3B on SGLang, B200-class
git clone https://github.com/ekzhang/openjev-sglang.git && cd openjev-sglang
两者都暴露 /v1/systemone 风格端点，SDK 侧的替换和本页其他路线一样。OpenJev 还能在同一 API 后面代理 Laya 与 Verdict。

按你手上的硬件选路线

决策模型的体积横跨四个数量级。在准确率出场之前，你的硬件已经先把候选名单筛完了。

完全没有显卡

笔记本 CPU、旧办公机、边缘盒子、纯 CPU 容器

跑 Von——395M 参数、磁盘约 1.5GB、CPU 上单次判定低于 15ms。最简单的标签集可以用 Verdict（ONNX int8）做到单条低于 2ms；要线级兼容就用 JevK5 的 GGUF 版本，单次短决策约 0.25–0.6 秒。能接受 4B 量化模型的话，SemIf 也能通过 llama.cpp 跑在 CPU 上。

Apple Silicon

M 系 MacBook 与 Mac Studio，16GB 以上统一内存

Kev 走 MLX，重复 state 下 47ms（新 state 77ms），而且能在同一台机器上训练。Laya-MLX 在 M3 Max 上实测 p50 13.4ms、占用不到 1GB。OpenJev 能在约 16GB 统一内存上跑 DiffusionGemma。零配置兜底仍然是 Von。

一张消费级显卡

RTX 3090 / 4090 / T4 级显卡，8–24GB 显存

追极致速度选 cbjev（4090 上单题 3ms），要微调基座选 Laya（T4 上 33–40ms），3090 跑 BF16 冻结 4B 选 SemIf，约 9GB bf16 跑 JevK5-4B，如果 CUDA 训练流水线本身才是目的就上 NanoJev。

工作站或服务器

RTX PRO 6000 / H100 / B200 级硬件

H100 上 Kev 跑 12–26ms、JevK5 p50 13.2ms；OpenJev 的 DiffusionGemma 服务端要 24GB 以上显存（p50 27ms）；openjev-sglang 面向 B200 级批量吞吐；如果你已经托管的开源大模型就该直接变成决策层，用 vLLM 加 AnyJev 或 simple-jev——零训练，几乎没有额外延迟。

五步接入路径

无论最后落在 1.5GB 的 CPU 模型还是 B200 服务器，顺序都一样。

  1. 01

    想清楚你要替换的是哪一层

    Jev 这个 API 没法被托管。有意识地选：换模型本体（训练型编码器）、换服务层（协议兼容服务端），或者什么都不换——直接从你已经在跑的开源模型里借 logits（适配层）。

  2. 02

    让路线匹配你的硬件

    用上面的矩阵。1.5GB 且无显卡就是 Von；一张 3090 就是 SemIf 或小编码器；24GB 显卡解锁 DiffusionGemma；数据中心级批量服务就是 B200 上的 SGLang。

  3. 03

    用最小命令装起来

    下面每个代码块都是拿到第一个答案的最短路径——clone、sync、serve、curl。第一个请求返回之前，别急着搭平台。

  4. 04

    在自己的标注上做标定

    模型自报的置信度不等于标定过的置信度。在信任任何概率之前，先在自己负载的留出集上拟合温度：SemIf 自己的数据里，这一步把 ECE 从 0.208 降到 0.069；而在 Laya 上，它修好了标定、准确率却一个点都没动。

  5. 05

    先影子测试，再按置信度分流

    让自托管路线和现有方案一起跑真实流量，用你自己的标注（而不是项目的基准）做对比。在删掉旧路径之前，先把低置信度决策路由给人工或降级链。

自托管 Jev：常见问题

Jev 是开源的吗？

不是。TypeSafe Jev 是闭源权重的托管 API；Python 和 TypeScript SDK 只是调用它的客户端，而且主客户协议 2.3(b) 禁止利用该服务或其输出开发同类产品。开源的是它周围的生态：Laya、Von、cbjev、NanoJev、JevK5 是训练出来的开放模型，Kev、SemIf、AnyJev、simple-jev 改造你已托管的模型，OpenJev 和 openjev-sglang 服务扩散路线。

Jev 本体能自托管吗？

模型本体不行。没有公开权重，也没有离线模式。人们说「自托管 Jev」时，实际指的是上面某个开源替代品——它们大多暴露同样的 /v1/systemone 请求形状，现有的 SDK 集成换个 base URL 就能继续用。

自托管一个 Jev 式决策模型需要什么硬件？

下限是 1.5GB 加无显卡，上限到 B200。Von 在 CPU 上低于 15ms；Laya 一行 pip 装完、笔记本就能服务；SemIf 的参考环境是一张 RTX 3090 装 BF16 的冻结 Qwen3.5-4B；Kev 需要 Apple Silicon MLX 或 H100（12–26ms）；DiffusionGemma 服务端要 24GB 以上的卡；openjev-sglang 面向 B200 级硬件。

本地跑 Laya 还是 Kev？

它们是两种工作。Kev 是即插即用：同一套 /v1/systemone 契约、Qwen3.5（0.8B/4B/9B）上的 LoRA 适配器、MacBook 就能训练，而且它公布自己的败绩——held-out 新来源上 0.822，对 Jev 的 0.857。Laya 是微调基座：零样本接近随机（typed decisions 上 0.362，多数类基线 0.461），在你自己的标注上微调后才有竞争力，且有序量表题存在实测的位置偏置。完全不想训练的话，SemIf 从你已托管的 4B 模型里读 logits。

JevK5 是什么？

一个 Apache-2.0 的开放权重决策模型（4B/9B，Qwen3.5 加蒸馏 LoRA），通过 jevk5-serve 端点保持与 Jev 的线级兼容。JevBench v1.2 上它拿 62.04，对托管 Jev 的 63.29——是该榜单上最接近的开源数字——H100 上 easy/standard 题的 p50 延迟 13.2ms。GGUF 版本（2.0–9.5GB）经 llama.cpp 可跑在 CPU 与 Apple Silicon 上。仅支持英语，单题上限 16 个选项。

自托管替代品的准确率赶得上托管 Jev 吗？

在零样本、跨域场景下赶不上。在唯一一个与所有项目无利害关系的独立基准（49 任务、869 用例）上，最强的开源模型——395M 的 Von——约 0.704，Jev 是 0.966，差了约 26 个点。开源赢的是自有硬件上的延迟、硬件摊销后的单次成本和数据不出域。无论选哪条，都请为温度标定和按置信度分流的降级链留出预算。

继续深入

Jev 替代品总览30 个项目按许可证、基座、延迟与协议兼容性对照——附 JevBench 榜单版本漂移警告。Laya 详解421M 编码器：T4 延迟、诚实的零样本天花板、实测的位置偏置。Kev 详解MLX 与 H100 数字，以及 Kev 公布的关于自己的败绩。Von 详解纯 CPU 路线，以及它的 395M 参数到底在哪里失效。开源 Jev 模型实测JevBench 天梯、免费 T4 上微调 Laya、DiffusionGemma 批量路由。本地运行 Jev 式模型视频转图文：Kev、SemIf、Von 在自有硬件上的取舍。