7 大开源 TypeSafe Jev 替代方案

许多 AI 应用在执行并不需要文本生成的任务时，仍在使用大型语言模型。

一个代理可能只需要决定调用哪个工具、某份文档是否相关、请求有多紧急，或某个操作是否应当升级处理。

TypeSafe AI 的 Jev采用了不同的方法。它不是逐 token 生成答案，而是接收应用状态和结构化问题，直接返回带类型的决策，例如选项、分数、是/否判断和概率。在我们的 Jev API 教程 中查看其实际效果。

TypeSafe AI 将其描述为一种System One Model（系统一模型）的方法：将 AI 用作快速决策层，而非通用文本生成器。

挑战在于我们对 Jev 的内部工作机制仍知之甚少。

TypeSafe AI 分享了关于其并行决策方法和训练方式的一些细节，但完整架构、模型权重、训练数据以及完整训练配方尚未公开。

这使得检查、复现或改造 Jev 本身变得困难。

开源项目正在用可实际审阅并本地运行的架构探索同一理念。

有的使用小型双向模型，有的在 Qwen 上增加专用的决策头，还有的直接从现有语言模型中提取概率。

由于您可以掌控完整栈，也就能对模型大小、量化、批处理、缓存、硬件与服务进行优化，为自己的工作负载打造更快、更便宜的决策层。

在本文中，我将比较七个开源 Jev 替代方案，包括Laya、Nimble、Kev、SemIf、Rizzo Flow、Von 和 NanoJev，介绍各自的工作原理、与 Jev 方法的贴合程度、各自亮点，以及如何在本地运行。

免责声明：本指南涵盖的项目非常新且快速演进。代码示例基于其官方文档与仓库，但并非所有示例都经过端到端的独立测试。

1. Laya：为目的而生的多语言 Jev 替代方案

Laya 是一个为决策而构建的非自回归模型，基于ModernBERT-large，并提供单独的mmBERT 检查点以支持多语言工作负载。

它不生成文本，而是将状态、问题与可用选项一并处理，并在一次前向传播中直接为候选答案打分。它支持 Jev 风格的 choice、score 和 noul 决策，并为英文、多语言及类型化决策工作负载提供专用检查点。

这使 Laya 成为在架构上最接近 Jev 的替代方案之一，因为二者均专为概率性决策而非文本生成而设计。

Laya 的亮点在于其相对小巧的 322M–421M 模型、多语言支持覆盖 100+ 种语言，以及无需运行数十亿参数的生成模型即可高效评估多个问题。

Laya 的工作原理

Laya 接收电子邮件、工单、文档或 JSON 对象等状态，以及 choice、score 或 noul 等类型化问题。

其路由器会为请求选择最合适的检查点，例如英文选择 ModernBERT-large，多语言输入选择 mmBERT-base。

所选模型在一次前向传播中处理状态与问题，随后由决策头为可选项打分并转换为概率。

这形成了从输入，经由路由与编码，直至最终类型化决策的直接流程。

开始使用 Laya

Laya 以 Python 包形式提供：

pip install laya技术支持

该命令会安装 Laya 库及其依赖项，但不会将模型权重一并打包在内。

模型托管在 Hugging Face 上。

当您以 preload=True 创建路由器时，Laya 会立即下载并加载可用检查点，使其在首次请求前就绪。

下载的权重会缓存在本地，因此每次运行应用时无需重复下载。

from laya import Router

router = Router(preload=True)

state = {
    "subject": "Duplicate charge",
    "body": "I was charged twice. Please refund this today."
}

questions = {
    "department": {
        "type": "choice",
        "instructions": "Which department should handle this?",
        "criteria": {
            "billing": "Payments and refunds",
            "technical": "Errors and outages",
            "sales": "Pricing and purchases"
        }
    }
}

result = router.predict(state, questions)

print(result["answers"]["department"]["choice"])技术支持

这里 Router(preload=True) 是关键部分。

首次运行时，Laya 会从其 Hugging Face 仓库获取所需的模型文件并加载至内存。后续运行可复用本地缓存的副本。

若您改用：

router = Router()技术支持

Laya 将采用惰性加载。它会等到确实需要某个检查点时，才在首次使用时下载/构建。

2. Nimble：基于 Qwen 的 Jev 替代方案

Bespoke Nimble 使用 Qwen3.5-9B 作为骨干，并通过 rank-16 LoRA 针对类型化决策进行微调。

您提供一段文本以及包含布尔或枚举问题的扁平模式，Nimble 会返回所选答案以及每个允许选项的概率。

训练与推理并非逐 token 解码答案，而是直接在候选 logits 上运作。

与 Jev 类似，Nimble 围绕“输入状态，输出类型化概率决策”的理念构建，但其实现展示了如何在现有开源 LLM 上添加该行为，而非依赖专有的决策架构。

其主要优势在于过程的开放性：Bespoke Labs 发布了模型、训练配方、评估设置和数据整理流水线，对希望训练或研究自有 Jev 风格模型的开发者尤为有用。

Nimble 的工作原理

Nimble 从上下文与定义允许输出的决策模式开始，例如布尔或枚举中的一个值。

它结合使用 Qwen3.5-9B 与 LoRA 处理上下文与模式，然后读取被允许候选 token 的 logits，而不是生成完整响应。

这些 logits 经 softmax 转换为概率，并作为结构化的类型化输出返回。

开始使用 Nimble

Nimble 需要 Python 3.12，并使用 Bespoke-Nimble-9B 检查点。先克隆仓库并安装依赖：

git clone https://github.com/bespokelabsai/nimble.git nimble
cd nimble

python3.12 -m venv .cache/venvs/nimble
source .cache/venvs/nimble/bin/activate

python -m pip install torch==2.8.0 -r requirements/training.txt技术支持

接着下载并准备模型。官方准备步骤会从 Hugging Face 下载 bespokelabs/Bespoke-Nimble-9B，如有需要，会将其 LoRA 适配器与固定的 Qwen3.5 基础模型合并，并创建 .cache/nimble-model.json。

import json
from pathlib import Path
from huggingface_hub import snapshot_download

repo = "bespokelabs/Bespoke-Nimble-9B"

snapshot = Path(
    snapshot_download(
        repo,
        cache_dir=".cache/huggingface/hub"
    )
)

config = {
    "model_path": str(snapshot.resolve()),
    "model_id": repo,
    "revision": snapshot.name,
    "max_input_tokens": 2048,
}

Path(".cache/nimble-model.json").write_text(
    json.dumps(config, indent=2)
)技术支持

如果下载的发行版是 LoRA 适配器，请使用 Nimble 官方快速入门中的完整准备代码块，以便在推理前将适配器与固定基础模型合并。

在 NVIDIA GPU 上，加载已准备好的模型：

import json
from pathlib import Path
from nimble.scoring.cuda_scorer import CudaCandidateScorer

config = json.loads(
    Path(".cache/nimble-model.json").read_text()
)

scorer = CudaCandidateScorer(**config)
Then make a typed decision:
schema = {
    "priority": {
        "type": "enum",
        "choices": ["HIGH", "LOW"],
        "description": "Urgency based on current business impact."
    },
    "requires_review": {
        "type": "boolean",
        "description": "Whether a human should review this incident."
    }
}

result = scorer.score(
    "The payment service is down for all customers.",
    schema
)

print(result["output"])
print(result["fields"]["priority"]["scores"])技术支持

Nimble 返回所选值及为每个候选分配的概率，而非生成文本响应。

3. Kev：在架构上最接近 Jev 的复刻

Kev 是一组受 Jev 启发的决策模型，基于 Qwen3.5，提供 0.8B、4B 与 9B 变体。

它添加了 rank-16 的 LoRA 适配器和一个小型指针头，用于比较每个选项表示与问题的决策表示。

多个问题可以共享同一状态，Kev 会保持问题隔离，并在不生成文本的情况下返回其概率分布。

Kev 与 Jev 尤为接近，因为其架构明确基于对 Jev 的公开重构，且其服务器实现了 TypeSafe 的 /v1/systemone API 契约。

它支持同样的 noul、choice 与 score 问题类型，因此现有 TypeSafe SDK 代码可以重定向至本地的 Kev 服务器。

其主要优势在于兼具Jev 式行为、开放权重、多种模型规模与开放训练流水线。

Kev 的工作原理

Kev 使用 Qwen 基础模型、LoRA 适配器与小型指针头。

共享状态仅处理一次，并在多个问题间复用，因此模型无需反复处理相同上下文。

对每个问题，Kev 会为选项与决策 token 创建隐藏表示，然后由指针头比较并生成选项分数。

Softmax 将这些分数转换为 choice、noul 或 score 的最终概率。

开始使用 Kev

Kev 以本地 System One 服务器方式运行。

先克隆项目并安装其服务依赖：

git clone https://github.com/jaredpalmer/kev.git
cd kev

uv sync --extra serve技术支持

这会安装 Kev 本身，但未必包含所有模型权重。

通过以下命令启动 Kev-4B：

KEV_DTYPE=bf16 \
uv run --extra serve python -m kev.serve \
    --run jaredpalmer/kev-4b \
    --port 8009技术支持

首次运行时，Kev 会自动从 Hugging Face 下载 Kev 适配器/检查点及其 Qwen 基础模型。

后续启动会复用缓存的模型文件，无需再次下载。

服务器启动后，您可以配合 TypeSafe SDK 使用：

from typesafe_sdk import Choice, TypeSafeClient

client = TypeSafeClient(
    api_key="local",
    base_url="http://127.0.0.1:8009",
    model="kev-latest",
)

response = client.system_one(
    state="I was charged twice.",
    questions={
        "team": Choice(
            instructions="Which team owns this?",
            criteria={
                "billing": None,
                "technical": None,
            },
        )
    },
)

print(response.choices["team"].choice)技术支持

因此在 Kev 中，服务器命令也兼作模型加载步骤：首次启动会自动下载所需权重。

4. SemIf：无需微调的直接 logits 型 Jev 替代方案

SemIf 采用更简单的方法：它根本不训练新的决策模型。

相反，它使用现有的开源模型（如 Qwen3.5-4B），直接读取被允许答案的 logits。

状态、准则与类型化选项传入模型后，SemIf 会将原生的选项 logits 转换为概率，而无需采样或生成答案。

这复现了 Jev 的一个重要实用特性——在无自回归输出的情况下进行决策，同时避免对专用检查点的需求。

SemIf 的灵活性尤为突出：您可以在其之下更换不同开源模型、在多个问题间复用长状态，并在 CUDA、Apple Silicon 或量化的浏览器模型上试验直接打分。

当您希望在未先训练专用模型的情况下测试 System One 思路时，它尤其有用。

SemIf 的工作原理

SemIf 接收非结构化状态、运行时准则与一组允许选项，并将它们传入现有开源模型。

它不会要求模型生成答案，而是直接读取这些预定义选项的 logits。

随后将这些 logits 转换为概率分布，让应用在无需生成文本、也无需事后解析响应的情况下做出类型化决策。

开始使用 SemIf

SemIf 没有专用的基础模型检查点，而是基于现有开源模型执行决策打分。

克隆并安装：

git clone https://github.com/TheoLeeCJ/SemIf.git
cd SemIf

python -m venv .venv
source .venv/bin/activate

pip install -e '.[test]'技术支持

这会安装 SemIf，但尚未下载 Qwen。

运行打分器：

CUDA_VISIBLE_DEVICES=0 semif-score \
    --mode direct \
    --model Qwen/Qwen3.5-4B \
    --revision 851bf6e806efd8d0a36b00ddf55e13ccb7b8cd0a \
    --input examples/decisions.jsonl \
    --output results.jsonl技术支持

首次运行时，所选 Qwen 模型会从 Hugging Face 下载并存入其缓存。SemIf 文档甚至建议将 HF_HOME 设置到大容量磁盘，因为模型文件可能占用较大空间。

例如：

export HF_HOME=/path/to/large-drive/huggingface技术支持

模型缓存完成后，后续运行可复用本地副本。

因此 SemIf 本身相对小巧。下载体积主要取决于您所选的底层开源模型。

5. Rizzo Flow：以本地为先、硬件灵活的 Jev 替代方案

Rizzo Flow 是一个以本地为先的 Jev 风格推理系统，基于开源 Spark-X2.5 模型与 llama.cpp 服务框架。

它不会生成 JSON 答案，而是将每个决策转换为受限的可能答案 token 集，读取这些 token 的 logits，并转换为概率。

状态可处理一次并在多个问题间复用，从而减少重复计算。

与 Jev 一样，Rizzo Flow 接收非结构化状态并返回类型化决策，如是/否判断、选项、分数与数值输出。

它还镜像了 TypeSafe 的 HTTP 接口，使以本地端点替换托管调用相对容易。

Rizzo Flow 在本地部署与硬件灵活性方面尤为出色，它结合开源模型、量化与熟悉的 API，而非试图复刻 Jev 的专有训练架构。

Rizzo Flow 的工作原理

Rizzo Flow 对状态进行一次处理，并将结果存储在模型的 KV 缓存中。

随后多个问题可复用该缓存状态，而无需再次处理完整上下文。每个问题会被转换为多项选择问题，候选答案以 A、B 或 C 等字母表示。

Rizzo Flow 只读取这些答案字母的 logits，应用 softmax，并将所得概率转换为布尔、选择、分数或数值等类型化输出。

开始使用 Rizzo Flow

Rizzo Flow 需要 Python 3.11+、Git 和 uv。

安装时，请选择与您机器匹配的计算后端。例如，在带 NVIDIA GPU 的 Linux 上：

git clone https://github.com/Rizzo-AI-Academy/rizzo-flow
cd rizzo-flow

uv sync --locked --extra cuda
source .venv/bin/activate技术支持

Apple Silicon 使用 --extra mlx；仅 CPU 的系统可使用 --extra cpu。

接下来，下载默认的 Spark-X2.5 模型及其本地运行时：

rizzo download技术支持

然后启动服务器：

rizzo serve技术支持

模型将以本地方式运行于 http://127.0.0.1:8017。

您可以用真实决策测试 Jev 兼容端点：

curl http://127.0.0.1:8017/v1/systemone \
  -H 'Content-Type: application/json' \
  -d '{
    "state": "My payouts have been failing for three days.",
    "model": "rizzo-latest",
    "questions": {
      "is_urgent": {
        "type": "noul",
        "instructions": "Does this convey urgency?"
      },
      "department": {
        "type": "choice",
        "instructions": "Which team should handle this?",
        "criteria": {
          "billing": "Payments and refunds",
          "technical": "Bugs and outages",
          "sales": null
        }
      }
    }
  }'技术支持

Rizzo Flow 直接返回答案与概率分布，而无需逐 token 生成输出响应。

6. Von：紧凑型的 System One Jev 替代方案

Von 是一个为 System One 而生的模型，基于 3.95 亿参数的双向 ModernBERT 架构。

它不解码文本，而是使用 OptionMarker 表示同时评估状态与候选准则，直接生成 Choice、Noul 和 Score 决策的 logits。

它还会进行训练后校准，使所得概率分布可直接供应用逻辑使用。

Von 在接口层面与 Jev 非常相似：非自回归、支持三种核心决策原语、在一次前向中评估多个问题，并实现 /v1/systemone 协议。

其主要优势是体量小、面向本地推理：模型参数为数亿级而非数十亿级，并支持 CUDA、ROCm、Apple Silicon 与 CPU 执行。

Von 的工作原理

von 使用紧凑的双向 ModernBERT 模型，将状态、问题与候选准则一并处理。

其 Option-Marker 机制为可能答案创建表示，并转换为候选 logits。

随后应用温度缩放以改进概率分布，最后返回 choice、noul 或 score。

同一架构也可在一次前向传播内评估多个问题。

开始使用 Von

Von 的接口非常简洁。

安装 Python SDK：

pip install von-sdk技术支持

这会安装 Von 软件。实际模型以 wfzyx/von-1.0 发布在 Hugging Face。

首次加载模型时，其 ModernBERT 检查点会通过 Hugging Face/Transformers 的模型加载系统下载并缓存在本地。

缓存完成后，后续推理可使用本地副本，无需再次下载权重。

随后即可进行决策：

import von

result = von.decide(
    state="Database replication lag exceeded 45 seconds.",
    choices={
        "infrastructure": "Database or network failures",
        "billing": "Payments and invoices",
        "feature": "Requests for new functionality",
    },
    instructions="Classify the root cause.",
)

print(result.choice)
print(result.confidence)
For a binary decision:
p_blocking = von.judge(
    state="Requests are timing out.",
    instructions="Is this actively blocking customers?"
)

print(p_blocking)技术支持

因此首次调用可能用时更长，因为需要下载并初始化模型。之后，推理将在本地进行。

7. NanoJev：可训练、轻量级的 Jev 复刻

NanoJev 是一个0.6B 的 Jev 复刻，基于 Qwen3-0.6B，并为结构化输出提供专用决策头。

每个请求包含状态、问题与候选集合，这些内容会传入骨干网络后，由共享的头部产生完整的概率分布。

Choice 使用集合注意力与标量头，布尔决策使用 sigmoid，Score 评估有序等级并同时给出分布与期望分数。

NanoJev 与 Jev 的设计尤为接近：支持并行决策、动态候选集、完整概率分布与零输出解码。

其亮点在于极小的骨干网络与明确的端到端训练流水线。

它可将多个状态、问题与候选路径在一次骨干前向中批处理，对希望在紧凑且可训练的 Jev 风格架构上试验、而非改造更大型通用 LLM 的开发者来说，是一个有趣选择。

NanoJev 的工作原理

NanoJev 接收状态、问题以及模型允许选择的候选答案。

每个候选会与相关输入组合，并传入共享的 Qwen3-0.6B 骨干。

NanoJev 随后使用专用决策头直接为候选打分：Choice 使用集合注意力与 softmax，Boolean 使用 sigmoid，Score 则对有序等级产生概率分布。

由于这些概率直接来自前向传播的读取，因此可在不生成输出 token 的情况下返回完整的类型化分布。

开始使用 NanoJev

NanoJev 将模型下载与仓库安装分离。

先安装项目：

git clone https://github.com/TianyuCodings/NanoJev.git
cd NanoJev

python -m pip install \
    -r requirements-toy.txt \
    huggingface_hub技术支持

然后下载固定的公共检查点：

from huggingface_hub import snapshot_download

snapshot_download(
    repo_id="C-Tianyu/NanoJev",
    revision="unified-games-v1",
    local_dir="checkpoints/NanoJev-unified",
    allow_patterns=[
        "best.safetensors",
        "config.json",
        "tokenizer/*",
        "backbone_config/*",
    ],
)技术支持

启动本地推理服务器：

CUDA_VISIBLE_DEVICES=0 python scripts/serve_decisions.py \
    --checkpoint-dir checkpoints/NanoJev-unified \
    --web-root web \
    --host 127.0.0.1 \
    --port 8765 \
    --precision bf16技术支持

创建请求：

cat > data/request.json <<'JSON'
{
  "states": [{
    "id": "living_room",
    "state": "The living room is 29 degrees. The target is 24 degrees. The window is closed and someone is home.",
    "questions": {
      "action": {
        "type": "choice",
        "instructions": "Choose the action that most directly lowers the room temperature.",
        "criteria": {
          "cool": "Turn on air conditioning",
          "light": "Turn on the lights",
          "wait": "Keep the current settings"
        }
      },
      "occupied": {
        "type": "boolean",
        "instructions": "Someone is home."
      }
    }
  }]
}
JSON技术支持

然后将其发送至 NanoJev：

curl http://127.0.0.1:8765/api/evaluate \
  -H 'Content-Type: application/json' \
  --data-binary @data/request.json技术支持

服务器会常驻加载检查点，并为每个问题返回概率分布。NanoJev 也可在同一请求中批处理多个状态与问题。

7 大 Jev 替代方案对比

主要差异在于各项目如何产出决策。

Laya 与 Von 使用专为选项打分而构建的小型双向编码器。

Kev、Nimble 与 NanoJev 则在 Qwen 模型上通过专门训练或决策头进行改造。

SemIf 与 Rizzo Flow 采取更轻量的方法，直接从现有生成模型中提取概率。

在实践中，专用编码器优先考虑速度与效率；改造过的 Qwen 模型保留更强的一般语言能力；而直接 logits 方法更易于试验，因为所需的专门训练更少。

应选择哪种 Jev 替代方案？

对于小型、专用的决策模型，Laya、Von 与 NanoJev 颇具看点，参数规模约在 322M 到 600M 之间。

如果您需要多语言决策，Laya 以基于 mmBERT 的专用检查点覆盖 100+ 种语言而脱颖而出。

若您的应用基于TypeSafe System One API，Kev 与 Von 提供尤为贴合的集成路径，而 Rizzo Flow 则镜像相同的 HTTP 接口用于本地服务。

在训练与实验方面，Nimble 发布了数据整理与 LoRA 微调配方，NanoJev 则提供覆盖数据生成、训练、评估与服务的完整流水线。

如果您希望在无需训练专用决策模型的情况下进行试验，SemIf 是一个有用的基线：它直接从 Qwen 等现有开源模型读取选项概率，而非生成答案。

结语

Jev 的具体架构或许是新的，但其底层理念并不新。

零样本 NLI 分类器多年前就已通过模型 logits 为任意候选标签打分，远早于 Jev 的出现。

TypeSafe AI 带来的，是为此目的打造的架构、并行输出、校准概率，以及将这一理念转化为可编程决策层的整洁 API。

开源生态表明，构建类似系统并不需要封闭服务。

诸如 Kev、Von 与 Rizzo Flow 等项目可以在本地运行并暴露 Jev 风格接口，其他项目也允许您下载权重、进行量化，或使用如 llama.cpp 等运行时。

真正的要点不在于 Jev 发明了 AI 决策，而在于它让人们重新关注一个重要理念：如果您的应用只需要一个决策，或许根本不需要文本生成。