Die 7 besten Open-Source-Alternativen zu TypeSafe Jev

Viele KI-Anwendungen setzen große Sprachmodelle für Aufgaben ein, die eigentlich keine Textgenerierung erfordern. 

Ein Agent muss womöglich nur entscheiden, welches Tool aufzurufen ist, ob ein Dokument relevant ist, wie dringend eine Anfrage ist oder ob eine Aktion eskaliert werden sollte.

TypeSafe AI’s Jev geht diese Aufgaben anders an. Anstatt Antwort-Token schrittweise zu generieren, nimmt es den Anwendungszustand und strukturierte Fragen entgegen und liefert typisierte Entscheidungen wie Auswahlen, Scores, Ja/Nein-Bewertungen und Wahrscheinlichkeiten. Sieh dir das in Aktion in unserem Jev API-Tutorial an.

TypeSafe AI beschreibt dies als einen System One Model-Ansatz: KI als schnelle Entscheidungsschicht statt als allgemeiner Textgenerator.

Die Herausforderung: Wir wissen noch relativ wenig darüber, wie Jev intern funktioniert. 

TypeSafe AI hat einige Details über den parallelen Entscheidungsansatz und die Trainingsmethode geteilt, aber vollständige Architektur, Modellgewichte, Trainingsdaten und das gesamte Trainingsrezept sind nicht öffentlich.

Dadurch ist es schwierig, Jev selbst zu inspizieren, zu reproduzieren oder anzupassen.

Open-Source-Projekte erforschen dieselbe Idee mit Architekturen, die wir tatsächlich prüfen und lokal ausführen können. 

Einige nutzen kleine bidirektionale Modelle, andere passen Qwen mit spezialisierten Decision Heads an, wiederum andere lesen Wahrscheinlichkeiten direkt aus bestehenden Sprachmodellen aus. 

Weil du den gesamten Stack kontrollierst, kannst du Modellgröße, Quantisierung, Batching, Caching, Hardware und Serving optimieren, um für deine Workloads eine schnellere und günstigere Entscheidungsschicht aufzubauen.

In diesem Blog vergleiche ich sieben Open-Source-Alternativen zu Jev, darunter Laya, Nimble, Kev, SemIf, Rizzo Flow, Von und NanoJev. Ich zeige, wie sie funktionieren, wie nah sie dem Jev-Ansatz kommen, worin sie sich abheben und wie du sie lokal betreibst. 

Hinweis: Die in diesem Guide vorgestellten Projekte sind sehr neu und entwickeln sich rasant. Die Codebeispiele basieren auf der offiziellen Doku und den Repositories, jedoch wurden nicht alle Beispiele Ende-zu-Ende unabhängig getestet.

1. Laya: Eine speziell entwickelte, mehrsprachige Jev-Alternative

Laya ist ein speziell entwickeltes, nicht-autoregressives Entscheidungsmodell auf Basis von ModernBERT-large, mit einem separaten mmBERT-Checkpoint für mehrsprachige Workloads.

 Statt Text zu generieren, verarbeitet es Zustand, Frage und verfügbare Optionen gemeinsam und bewertet die möglichen Antworten direkt in einem einzigen Forward-Pass. Es unterstützt Jev-typische choice-, score- und noul-Entscheidungen mit dedizierten Checkpoints für englische, mehrsprachige und typisierte Entscheidungs-Workloads.

Damit ist Laya eine der architektonisch nächsten Alternativen zu Jev, denn beide sind speziell für probabilistische Entscheidungen statt Textgenerierung konzipiert. 

Laya punktet mit relativ kleinen 322M–421M Modellen, mehrsprachiger Unterstützung für 100+ Sprachen und der Möglichkeit, mehrere Fragen effizient auszuwerten, ohne ein generatives Modell mit mehreren Milliarden Parametern zu betreiben.

So funktioniert Laya

Laya nimmt einen Zustand wie eine E-Mail, ein Support-Ticket, ein Dokument oder ein JSON-Objekt zusammen mit typisierten Fragen wie choice, score oder noul entgegen. 

Der Router wählt den passenden Checkpoint für die Anfrage, z. B. ModernBERT-large für Englisch oder mmBERT-base für mehrsprachige Eingaben. 

Das ausgewählte Modell verarbeitet Zustand und Fragen in einem Forward-Pass, anschließend bewertet ein Decision Head die verfügbaren Optionen und wandelt sie in Wahrscheinlichkeiten um. 

So entsteht ein direkter Fluss vom Input über Routing und Encoding bis zur finalen typisierten Entscheidung.

Erste Schritte mit Laya

Laya ist als Python-Paket verfügbar:

pip install layaBereitgestellt von

Dieser Befehl installiert die Laya-Bibliothek und ihre Abhängigkeiten, bündelt jedoch keine Modellgewichte im Paket.

Die Modelle liegen auf Hugging Face.

Wenn du den Router mit preload=True erstellst, lädt Laya seine verfügbaren Checkpoints sofort herunter und in den Speicher, sodass sie vor der ersten Anfrage bereitstehen. 

Die geladenen Gewichte werden lokal zwischengespeichert und müssen nicht bei jedem Start der Anwendung erneut heruntergeladen werden.

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"])Bereitgestellt von

Hier ist Router(preload=True) der entscheidende Teil. 

Beim ersten Lauf lädt Laya die benötigten Modell-Dateien aus dem Hugging-Face-Repository und in den Speicher. Weitere Läufe nutzen die lokal gecachten Kopien.

Wenn du stattdessen Folgendes verwendest:

router = Router()Bereitgestellt von

Verwendet Laya Lazy Loading. Es wartet, bis ein bestimmter Checkpoint benötigt wird, und lädt/baut ihn dann beim ersten Gebrauch.

2. Nimble: Eine Qwen-basierte Alternative zu Jev

Bespoke Nimble nutzt Qwen3.5-9B als Backbone und finetunet es mit einer Rank-16-LoRA speziell für typisierte Entscheidungen.

Du übergibst einen Text zusammen mit einem flachen Schema mit Boolean- oder Enum-Fragen, und Nimble liefert die ausgewählte Antwort plus Wahrscheinlichkeiten für jede erlaubte Option. 

Statt eine Antwort Token für Token zu dekodieren, arbeiten Training und Inferenz direkt über den Kandidaten-Logits.

Wie Jev folgt Nimble der Idee: Zustand rein, typisierte probabilistische Entscheidungen raus – zeigt aber, wie sich dieses Verhalten zu einem bestehenden offenen LLM hinzufügen lässt, ohne eine proprietäre Entscheidungsarchitektur zu benötigen. 

Die größte Stärke ist die Offenheit über den gesamten Prozess: Bespoke Labs hat Modell, Trainingsrezept, Evaluations-Setup und die Datenkurations-Pipeline veröffentlicht – ideal für Entwickler, die eigene Jev-ähnliche Modelle trainieren oder untersuchen wollen.

So funktioniert Nimble

Nimble startet mit einem Kontext und einem Entscheidungsschema, das die erlaubten Outputs definiert, z. B. Boolean oder ein Wert aus einem Enum. 

Es nutzt Qwen3.5-9B mit LoRA, um Kontext und Schema zu verarbeiten, und liest anschließend die Logits für die erlaubten Kandidaten-Token aus, statt eine vollständige Antwort zu generieren. 

Diese Logits werden per Softmax in Wahrscheinlichkeiten umgewandelt und als strukturierter, typisierter Output zurückgegeben.

Erste Schritte mit Nimble

Nimble benötigt Python 3.12 und nutzt den Bespoke-Nimble-9B-Checkpoint. Starte mit dem Klonen des Repos und der Installation der Abhängigkeiten:

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.txtBereitgestellt von

Lade als Nächstes das Modell herunter und bereite es vor. Der offizielle Vorbereitungsschritt lädt bespokelabs/Bespoke-Nimble-9B von Hugging Face und verschmilzt bei Bedarf dessen LoRA-Adapter mit dem fixierten Qwen3.5-Basismodell. Anschließend wird .cache/nimble-model.json erzeugt.

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)
)Bereitgestellt von

Wenn der Download ein LoRA-Adapter ist, nutze Nimbles vollständigen Preparation-Block aus dem offiziellen Quickstart, damit der Adapter vor der Inferenz mit dem fixierten Basismodell zusammengeführt werden kann.

Auf einer NVIDIA-GPU lädst du das vorbereitete Modell so:

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"])Bereitgestellt von

Nimble liefert die ausgewählten Werte zusammen mit der Wahrscheinlichkeit für jeden Kandidaten zurück, statt eine Textantwort zu generieren.

3. Kev: Die architektonisch nächste Replik zu Jev

Kev ist eine Familie von Jev-inspirierten Entscheidungsmodellen auf Basis von Qwen3.5, mit Varianten in 0.8B, 4B und 9B. 

Es ergänzt einen Rank-16-LoRA-Adapter und einen kleinen Pointer Head, der jede Optionsrepräsentation mit der Entscheidungsrepräsentation der Frage vergleicht. 

Mehrere Fragen können denselben Zustand teilen, während Kev die Fragen isoliert hält und deren Wahrscheinlichkeitsverteilungen zurückgibt, ohne Text zu generieren.

Kev ist Jev besonders nah, da seine Architektur explizit auf einer öffentlichen Rekonstruktion von Jev basiert und sein Server TypeSafes /v1/systemone API-Contract implementiert. 

Es unterstützt dieselben Fragetypen noul, choice und score, sodass bestehender TypeSafe-SDK-Code auf einen lokalen Kev-Server umgebogen werden kann. 

Der Hauptvorteil ist die Kombination aus Jev-ähnlichem Verhalten, offenen Gewichten, mehreren Modellgrößen und einer offenen Trainings-Pipeline.

So funktioniert Kev

Kev nutzt ein Qwen-Basemodell mit LoRA-Adapter und einen kleinen Pointer Head. 

Der gemeinsame Zustand wird einmal verarbeitet und über mehrere Fragen hinweg wiederverwendet, sodass das Modell denselben Kontext nicht wiederholt verarbeiten muss. 

Für jede Frage erzeugt Kev Hidden-Repräsentationen für die Optionen und das Entscheidungstoken. Der Pointer Head vergleicht diese und produziert Optionsscores. 

Softmax wandelt diese Scores in Wahrscheinlichkeiten für das finale choice, noul oder score um.

Erste Schritte mit Kev

Kev läuft als lokaler System-One-Server.

Starte mit dem Klonen des Projekts und der Installation der Serving-Abhängigkeiten:

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

uv sync --extra serveBereitgestellt von

Dadurch wird Kev selbst installiert, jedoch nicht zwingend alle Modellgewichte.

Starte Kev-4B mit:

KEV_DTYPE=bf16 \
uv run --extra serve python -m kev.serve \
    --run jaredpalmer/kev-4b \
    --port 8009Bereitgestellt von

Beim ersten Start lädt Kev automatisch sowohl den Kev-Adapter/Checkpoint als auch das Qwen-Basemodell von Hugging Face herunter. 

Spätere Starts nutzen die gecachten Modelldateien, statt sie erneut zu laden.

Sobald der Server läuft, kannst du das TypeSafe SDK dagegen verwenden:

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)Bereitgestellt von

Bei Kev fungiert also der Server-Startbefehl zugleich als Modelllade-Schritt: Beim ersten Start werden die benötigten Gewichte automatisch heruntergeladen.

4. SemIf: Eine Direct-Logit-Alternative zu Jev ohne Fine-Tuning

SemIf wählt einen einfacheren Weg: Es trainiert gar kein neues Entscheidungsmodell. 

Stattdessen nutzt es bestehende offene Modelle wie Qwen3.5-4B und liest die Logits direkt für die erlaubten Antworten aus. 

Zustand, Kriterien und typisierte Optionen werden dem Modell übergeben, und SemIf wandelt die nativen Options-Logits in Wahrscheinlichkeiten um – ohne Sampling oder Antwortgenerierung.

Dies reproduziert eine der wichtigsten praktischen Eigenschaften von Jev: Entscheidungen ohne autoregressiven Output, und das ohne spezialisierten Checkpoint. 

SemIf überzeugt durch Flexibilität: Du kannst unterschiedliche offene Modelle darunter einsetzen, einen langen Zustand über viele Fragen hinweg wiederverwenden und mit direktem Scoring auf CUDA, Apple Silicon oder quantisierten Browser-Modellen experimentieren.

Besonders nützlich ist es, wenn du die System-One-Idee testen willst, ohne zuerst ein dediziertes Modell zu trainieren.

So funktioniert SemIf

SemIf nimmt einen unstrukturierten Zustand, Laufzeit-Kriterien und einen Satz erlaubter Optionen und schickt sie durch ein bestehendes offenes Modell. 

Statt das Modell um eine generierte Antwort zu bitten, liest es direkt die Logits für diese vordefinierten Optionen aus. 

Diese Logits werden in eine Wahrscheinlichkeitsverteilung umgewandelt, sodass die Anwendung eine typisierte Entscheidung treffen kann, ohne Text zu generieren oder eine Antwort nachträglich zu parsen.

Erste Schritte mit SemIf

SemIf hat keinen eigenen Foundation-Checkpoint. Stattdessen führt es Decision Scoring auf einem bestehenden offenen Modell aus.

Klonen und installieren:

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

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

pip install -e '.[test]'Bereitgestellt von

Damit installierst du SemIf, aber Qwen wird noch nicht heruntergeladen.

Starte den Scorer:

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

Beim ersten Lauf wird das gewählte Qwen-Modell von Hugging Face heruntergeladen und im Hugging-Face-Cache gespeichert. Die SemIf-Dokumentation empfiehlt sogar, HF_HOME auf ein großes Laufwerk zu setzen, weil die Modelldateien viel Platz beanspruchen können.

Zum Beispiel:

export HF_HOME=/path/to/large-drive/huggingfaceBereitgestellt von

Nachdem das Modell gecacht ist, können spätere Läufe die lokale Kopie wiederverwenden.

SemIf selbst ist also relativ klein. Der Großteil des Downloads stammt von dem offenen Modell, das du darunter ausführst.

5. Rizzo Flow: Lokale Jev-Alternative mit Hardware-Flexibilität

Rizzo Flow ist ein lokal orientiertes Jev-ähnliches Inferenzsystem rund um offene Spark-X2.5-Modelle und llama.cpp-basiertes Serving. 

Anstatt eine JSON-Antwort zu generieren, wandelt es jede Entscheidung in eine eingeschränkte Menge möglicher Antwort-Token um, liest die den Token zugewiesenen Logits und macht daraus Wahrscheinlichkeiten. 

Der Zustand kann einmal verarbeitet und über mehrere Fragen hinweg wiederverwendet werden, was wiederholte Berechnung reduziert.

Wie Jev akzeptiert Rizzo Flow unstrukturierten Zustand und liefert typisierte Entscheidungen wie Ja/Nein-Bewertungen, Auswahlen, Scores und numerische Outputs. 

Es spiegelt auch die HTTP-Schnittstelle von TypeSafe, wodurch sich ein gehosteter Aufruf relativ leicht durch einen lokalen Endpoint ersetzen lässt. 

Rizzo Flow sticht vor allem für lokale Deployments und Hardware-Flexibilität heraus – es kombiniert offene Modelle, Quantisierung und eine vertraute API, statt Jevs proprietäre Trainingsarchitektur nachzubauen.

So funktioniert Rizzo Flow

Rizzo Flow verarbeitet den Zustand einmal und speichert das Ergebnis im KV-Cache des Modells. 

Mehrere Fragen können dann auf diesen gecachten Zustand zugreifen, statt den vollen Kontext erneut zu verarbeiten. Jede Frage wird in ein Multiple-Choice-Problem umgewandelt, wobei Kandidatenantworten durch Buchstaben wie A, B oder C repräsentiert werden. 

Rizzo Flow liest nur die Logits für diese Antwort-Buchstaben, wendet Softmax an und wandelt die resultierenden Wahrscheinlichkeiten in typisierte Outputs wie Boolean, Choice, Score oder Zahl um.

Erste Schritte mit Rizzo Flow

Rizzo Flow benötigt Python 3.11+, Git und uv. 

Wähle bei der Installation das Compute-Backend für deine Maschine. Zum Beispiel unter Linux mit NVIDIA-GPU:

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

uv sync --locked --extra cuda
source .venv/bin/activateBereitgestellt von

Für Apple Silicon nutze --extra mlx; CPU-only-Systeme können --extra cpu verwenden.

Lade als Nächstes das Standardmodell Spark-X2.5 und die lokale Laufzeit:

rizzo downloadBereitgestellt von

Starte dann den Server:

rizzo serveBereitgestellt von

Das Modell läuft nun lokal unter http://127.0.0.1:8017. 

Du kannst den Jev-kompatiblen Endpoint mit einer echten Entscheidung testen:

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
        }
      }
    }
  }'Bereitgestellt von

Rizzo Flow liefert Antwort und Wahrscheinlichkeitsverteilung direkt, ohne Ausgabe-Token schrittweise zu generieren.

6. Von: Eine kompakte System-One-Alternative zu Jev

Von ist ein speziell entwickeltes System-One-Modell auf Basis einer bidirektionalen ModernBERT-Architektur mit 395M Parametern. 

Statt Text zu dekodieren, bewertet es Zustand und Kandidatenkriterien gemeinsam mithilfe von OptionMarker-Repräsentationen und erzeugt direkt Logits für Choice-, Noul- und Score-Entscheidungen. 

Zudem wird eine nachträgliche Kalibrierung angewendet, damit die entstehenden Wahrscheinlichkeitsverteilungen direkt in der Anwendungslogik genutzt werden können.

Von ähnelt Jev auf Interface-Ebene sehr: nicht-autoregressiv, unterstützt dieselben drei Kern-Entscheidungsprimitive, wertet mehrere Fragen in einem Forward-Pass aus und implementiert das /v1/systemone-Protokoll. 

Seine Hauptstärke ist die kleine Modellgröße und das lokale Inferenz-Design: Das Modell hat Hunderte Millionen statt Milliarden Parameter und unterstützt CUDA, ROCm, Apple Silicon und CPU.

So funktioniert Von

von nutzt ein kompaktes, bidirektionales ModernBERT-basiertes Modell, um Zustand, Frage und Kandidatenkriterien gemeinsam zu verarbeiten. 

Der Option-Marker-Mechanismus erzeugt Repräsentationen für die möglichen Antworten, die in Kandidaten-Logits umgewandelt werden. 

Anschließend wird Temperature Scaling angewandt, um die Wahrscheinlichkeitsverteilung zu verbessern, bevor von das finale choice-, noul- oder score-Ergebnis zurückgibt. 

Dieselbe Architektur kann auch mehrere Fragen in einem einzigen Forward-Pass auswerten.

Erste Schritte mit Von

Von hat eine der einfachsten Schnittstellen.

Installiere das Python-SDK:

pip install von-sdkBereitgestellt von

Damit installierst du die Von-Software. Das eigentliche Modell ist separat als wfzyx/von-1.0 auf Hugging Face veröffentlicht.

Beim ersten Laden wird der ModernBERT-Checkpoint heruntergeladen und lokal über das Hugging-Face/Transformers-Ladesystem gecacht. 

Nach dem Caching kann die spätere Inferenz die lokale Kopie nutzen, statt die Gewichte erneut zu laden.

Du kannst dann eine Entscheidung treffen mit:

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)Bereitgestellt von

Der erste Aufruf kann länger dauern, weil das Modell heruntergeladen und initialisiert werden muss. Danach findet die Inferenz lokal statt.

7. NanoJev: Eine trainierbare, schlanke Jev-Replik

NanoJev ist eine 0.6B große Jev-Replik auf Basis von Qwen3-0.6B mit dedizierten Decision Heads für strukturierte Outputs. 

Jede Anfrage enthält einen Zustand, eine Frage und eine Kandidatenmenge, die durch das Backbone laufen, bevor gemeinsame Heads vollständige Wahrscheinlichkeitsverteilungen erzeugen. 

Choice nutzt Set Attention und einen Skalar-Head, Boolean verwendet eine Sigmoid-Funktion, und Score bewertet geordnete Stufen und erzeugt sowohl eine Verteilung als auch einen erwarteten Score.

NanoJev folgt Jevs Design besonders eng: Es unterstützt parallele Entscheidungen, dynamische Kandidatenmengen, vollständige Wahrscheinlichkeitsverteilungen und null Output-Decoding. 

Hervorzuheben sind das sehr kleine Backbone und die explizite End-to-End-Trainingspipeline.

Mehrere Zustände, Fragen und Kandidatenpfade können zu einem gemeinsamen Backbone-Forward-Pass gebatcht werden – spannend für Entwickler, die mit einer kompakten, trainierbaren Jev-Architektur experimentieren wollen, statt ein größeres General-Purpose-LLM anzupassen.

So funktioniert NanoJev

NanoJev nimmt einen Zustand, eine Frage und die Kandidatenantworten, aus denen das Modell wählen darf. 

Jeder Kandidat wird mit den relevanten Eingaben kombiniert und durch ein gemeinsames Qwen3-0.6B-Backbone geschickt. 

NanoJev nutzt dann dedizierte Decision Heads, um die Kandidaten direkt zu bewerten: Choice mit Set Attention und Softmax, Boolean mit Sigmoid, und Score erzeugt eine Wahrscheinlichkeitsverteilung über geordnete Stufen. 

Da diese Wahrscheinlichkeiten direkt aus dem Forward-Pass gelesen werden, kann es vollständige typisierte Verteilungen zurückgeben, ohne Output-Token zu generieren.

Erste Schritte mit NanoJev

NanoJev trennt den Modelldownload von der Repository-Installation.

Installiere zunächst das Projekt:

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

python -m pip install \
    -r requirements-toy.txt \
    huggingface_hubBereitgestellt von

Lade dann den fixierten öffentlichen Checkpoint herunter:

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/*",
    ],
)Bereitgestellt von

Starte den lokalen Inferenzserver:

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 bf16Bereitgestellt von

Erstelle eine Anfrage:

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."
      }
    }
  }]
}
JSONBereitgestellt von

Sende sie dann an NanoJev:

curl http://127.0.0.1:8765/api/evaluate \
  -H 'Content-Type: application/json' \
  --data-binary @data/request.jsonBereitgestellt von

Der Server hält den Checkpoint geladen und gibt die Wahrscheinlichkeitsverteilung für jede Frage zurück. NanoJev kann auch mehrere Zustände und Fragen in einer Anfrage batchen.

Vergleich der Top 7 Jev-Alternativen

Der Hauptunterschied liegt darin, wie die Entscheidung jeweils erzeugt wird.

Laya und Von nutzen kleine bidirektionale Encoder, die speziell für das Scoring von Optionen entwickelt sind. 

Kev, Nimble und NanoJev passen Qwen-Modelle mit spezialisiertem Training oder Decision Heads an. 

SemIf und Rizzo Flow gehen leichtergewichtig vor, indem sie Wahrscheinlichkeiten direkt aus bestehenden generativen Modellen extrahieren.

In der Praxis priorisieren spezialisierte Encoder Geschwindigkeit und Effizienz, angepasste Qwen-Modelle behalten mehr allgemeine Sprachfähigkeit, und Direct-Logit-Methoden sind leichter zu erproben, weil sie weniger spezialisiertes Training erfordern.

Welche Jev-Alternative solltest du wählen?

Für kleine, spezialisierte Entscheidungsmodelle sind Laya, Von und NanoJev besonders interessant und decken grob 322M bis 600M Parameter ab.

Wenn du mehrsprachige Entscheidungen brauchst, überzeugt Laya mit einem dedizierten mmBERT-basierten Checkpoint für 100+ Sprachen.

Für Anwendungen rund um die TypeSafe System One API bieten Kev und Von besonders naheliegende Integrationspfade, während Rizzo Flow dieselbe HTTP-Schnittstelle für lokales Serving spiegelt.

Für Training und Experimente veröffentlicht Nimble seine Datenkurations- und LoRA-Fine-Tuning-Rezepte, während NanoJev eine vollständige Pipeline von Datengenerierung über Training und Evaluation bis zum Serving bereitstellt.

Wenn du ohne spezialisiertes Entscheidungsmodell experimentieren willst, ist SemIf eine hilfreiche Baseline: Es liest Optionswahrscheinlichkeiten direkt aus bestehenden offenen Modellen wie Qwen, statt eine Antwort zu generieren.

Abschließende Gedanken

Jevs exakte Architektur mag neu sein, die zugrundeliegende Idee ist es nicht. 

Zero-Shot-NLI-Klassifizierer bewerten seit Jahren beliebige Kandidatenlabels anhand von Modell-Logits – lange vor Jev. 

Was TypeSafe AI hinzufügt, sind eine speziell entwickelte Architektur, parallele Outputs, kalibrierte Wahrscheinlichkeiten und eine saubere API, um diese Idee in eine programmierbare Entscheidungsschicht zu verwandeln.

Das Open-Source-Ökosystem zeigt, dass du keinen geschlossenen Dienst brauchst, um etwas Ähnliches zu bauen. 

Projekte wie Kev, Von und Rizzo Flow laufen lokal und bieten Jev-ähnliche Schnittstellen, während andere dir erlauben, die Gewichte herunterzuladen, zu quantisieren oder Runtimes wie llama.cpp zu nutzen.

Die eigentliche Erkenntnis ist nicht, dass Jev KI-Entscheidungen erfunden hat, sondern dass es die Aufmerksamkeit auf eine wichtige Idee lenkt: Wenn deine Anwendung nur eine Entscheidung braucht, musst du möglicherweise gar keinen Text generieren.