Was steckt hinter System One und den offenen Jev-Nachbauten?

Am 15.09.2026 hat TypeSafe Jev vorgestellt, als erstes „System-One-Modell“. Der Satz dazu lautete „unstructured state in, typed probabilistic decisions out“. Zehn Tage später lagen auf Hugging Face über ein Dutzend offene Nachbauten, alle mit derselben Schnittstelle, alle mit Vergleichszahlen gegen Jev. Wir haben die wichtigsten davon auf einer Workstation mit einer RTX 4090 nebeneinandergestellt, dazu einen Eigenbau ohne jedes Training und ein großes Sprachmodell als Gegenprobe.

Das Ergebnis vorweg, weil es den Rest des Textes trägt. Hinter dem Hype steckt ein solides, aber altes Verfahren: Ein Sprachmodell wählt per Logits eine Option, statt Text zu schreiben. Die besten offenen Nachbauten sind ein Qwen-Modell mit einer kleinen LoRA darauf. Und sie sind kaum besser als ein untrainiertes 4B-Modell mit 150 Zeilen Code.

Was verspricht System One eigentlich?

Ein System-One-Modell schreibt keinen Text. Gar keinen. Es bekommt einen Zustand, als Text oder JSON, dazu einen Satz typisierter Fragen, und gibt für jede Frage eine Wahrscheinlichkeitsverteilung zurück.

Alle Fragen laufen in einem Aufruf an POST /v1/systemone. Versprochen sind 70 bis 500 ms Antwortzeit, 0,042 $ pro Million Input-Tokens bei kostenlosem Output, kalibrierte Konfidenz und Entscheidungsqualität auf „frontier-level“. Gewichte? Nicht veröffentlicht. Architektur, Parameterzahl und Trainingsdaten auch nicht, und zum Trainingsverfahren „RLCD“ gibt es kein Paper.

Was davon kann man prüfen, ohne die Gewichte zu kennen? Sicher ist nur die Formatgarantie. Die Antwort ist immer eine der erlaubten Optionen. Ob es die richtige ist, steht auf einem anderen Blatt, und dieselbe Garantie liefern Constrained Decoding mit Outlines oder XGrammar schon länger, genauso wie das schlichte Auslesen der Option-Logits eines beliebigen Sprachmodells.

Die Nachbauten übernehmen die Schnittstelle eins zu eins, das offizielle typesafe-sdk läuft per base_url gegen jeden von ihnen. Steckt in ihnen mehr als diese Schnittstelle? Das wollten wir wissen.

Wie wurde gemessen?

Wir haben allen Systemen exakt dieselben Anfragen im Jev-Format geschickt und sie auf demselben Test-Split mit denselben Kennzahlen bewertet. Alles lief zero-shot. Kein Fine-Tuning, keine Beispiele im Prompt.

Gerechnet hat eine Windows-11-Workstation mit einer NVIDIA RTX 4090 und 24 GB Videospeicher, und weil auf die Karte nie zwei dieser Modelle gleichzeitig passen, läuft immer nur eins. Ein Runner startet den Server eines Systems, misst alle Datensätze und beendet ihn wieder. Pro Datensatz geht genau ein Request mit allen Fragen raus, und die Latenz ist die Zeit am Client für diesen einen Request, nach drei Aufwärm-Requests, die nicht zählen. CLM braucht vLLM, das es für Windows nicht gibt, also lief sein Qwen3-8B-Encoder in Docker (vllm/vllm-openai, vLLM 0.27.1, Pooling-Modus).

Die Testfälle

Woran misst man so etwas, wenn man wissen will, ob es im eigenen Agenten taugt? Wir haben zwei Gruppen genommen. Vier eigene Use Cases auf Deutsch, so wie sie in Agenten tatsächlich vorkommen, und vier öffentliche Benchmarks von Hugging Face auf Englisch.

Ein Drittel jedes Datensatzes ist Dev-Split, zwei Drittel sind Test-Split. Die Zuordnung hängt nur am Hash der ID und ist damit für alle Systeme gleich. Auf dem Dev-Split bekommt jedes System eine eigene Temperatur gefittet. Die ändert nie die gewählte Option. Nur die Sicherheit, mit der sie behauptet wird. Gezählt wird ausschließlich der Test-Split: 883 Entscheidungen bei den eigenen Use Cases, 755 bei den Benchmarks.

Was zählt am Ende? Drei Kennzahlen. Die Trefferquote. Der ECE, also die Lücke zwischen behaupteter Sicherheit und tatsächlicher Trefferquote, in zehn Bins. Und die Zahl, die für Agenten am meisten sagt: automatisierbar bei 5 % Fehler, der Anteil der Entscheidungen, die du nach Konfidenz sortiert ungeprüft übernehmen kannst, wenn davon höchstens 5 % falsch sein dürfen.

Und Jev selbst?

Einen API-Key von TypeSafe hatten wir nicht. Jev ist deshalb nur über Antworten vertreten, die andere veröffentlicht haben: der Autor von jev-bench, mit Jev 1.13.0 und gemessener Latenz, und TypeSafe selbst für evalsafe. Über einen exakten Schlüssel je Datensatz und Frage ließen sich 450 der 755 Benchmark-Entscheidungen zuordnen. Kann man nicht einfach über OpenRouter gehen? Leider nein. Dort gibt es nur typesafe/jev-router, und der leitet Chat-Anfragen an große Sprachmodelle weiter, ohne Verteilungen zurückzugeben.

Was ist in den Nachbauten drin?

Technisch gibt es genau drei Bauweisen, und keine davon ist eine neue Modellklasse. Zwei sind ein gewöhnliches Sprachmodell, das statt Text eine Verteilung über Antwortoptionen ausgibt. Die dritte misst Ähnlichkeit zwischen Embeddings. Die Angaben stammen aus dem installierten Code, den Konfigurationen und den Modellkarten.

Drei Bauweisen hinter den NachbautenMessung 30.09.2026 · RTX 4090 · Test-Split

Option-Logits

Eigenbau, JevK5

1. 1State, Frage und Optionen als A), B), C) in einen Prompt
2. 2ein Forward-Pass, kein generiertes Token
3. 3Logits der Buchstaben an der letzten Position
4. 4Softmax ergibt die Verteilung

Pointer-Head

Kev-4B

1. 1Base-Modell liest State und Optionen
2. 2ein Vektor am decide-Token, einer am Ende jeder Option
3. 3Skalarprodukt je Option, gelernter Kopf
4. 4Softmax mit fester Temperatur

Embedding-Ähnlichkeit

CLM, embed-router (Laya ähnlich)

1. 1State und jede Option getrennt einbetten
2. 2kein gemeinsames Lesen von Text und Frage
3. 3Kosinus zwischen State und Option
4. 4Softmax über die Ähnlichkeiten

Drei der vier Nachbauten stehen auf Qwen, der vierte, Laya, auf mmBERT. Das ist kein Vorwurf. Qwen ist im Moment die naheliegende Basis für so etwas, und offene Gewichte sind genau dafür da. Es hilft aber, die Namen richtig einzuordnen: „Open-Source-Jev“ heißt in der Praxis fast immer Qwen mit einem anderen Ausleseweg. Was in Jev selbst steckt, weiß außerhalb von TypeSafe niemand.

Option-Logits: der Eigenbau und JevK5

Das ist der Kern fast aller Nachbauten, und er ist überraschend einfach. State, Frage und Optionen kommen als A), B), C) in einen Chat-Prompt, das Modell rechnet einen einzigen Forward-Pass, und an der letzten Position liest man die Logits der Buchstaben-Tokens aus. Softmax darüber. Fertig. Weil kein Token generiert wird, kann auch nichts außerhalb der Optionen herauskommen.

import torch
from transformers import AutoModelForCausalLM, AutoTokenizer

MODELL = "Qwen/Qwen3.5-4B"  # Instruct-Variante, ohne Training
tok = AutoTokenizer.from_pretrained(MODELL)
model = AutoModelForCausalLM.from_pretrained(
    MODELL, torch_dtype=torch.bfloat16, device_map="cuda"
)

def entscheide(state, frage, optionen, temperatur=1.0):
    buchstaben = [chr(65 + i) for i in range(len(optionen))]
    liste = "\n".join(f"{b}) {o}" for b, o in zip(buchstaben, optionen))
    prompt = tok.apply_chat_template(
        [{"role": "user", "content": f"{state}\n\nFrage: {frage}\n{liste}\n\nAntworte nur mit dem Buchstaben."}],
        tokenize=False, add_generation_prompt=True, enable_thinking=False,
    )
    ids = tok(prompt, return_tensors="pt").to(model.device)
    with torch.no_grad():
        logits = model(**ids).logits[0, -1]          # ein Forward-Pass
    kandidaten = [tok.encode(b, add_special_tokens=False)[0] for b in buchstaben]
    p = torch.softmax(logits[kandidaten].float() / temperatur, dim=-1)
    return dict(zip(optionen, p.tolist()))

Das ist das ganze Prinzip. Was der Eigenbau im Test darüber hinaus kann, ist Handwerk: Score-Fragen, bei denen aus der Verteilung über die Skalenstufen ein Erwartungswert wird, noul-Fragen als Ja/Nein-Paar, mehrere Fragen in einem Request und die Jev-kompatible Schnittstelle drumherum, zusammen rund 150 Zeilen.

JevK5 ist exakt diese Technik mit demselben Basismodell und einer kleinen LoRA, trainiert auf den Antworten großer Sprachmodelle. Einer der beiden Lehrer ist Qwen3.6-27B, also dasselbe Modell, das bei uns als große Gegenprobe läuft. Im Kern ist JevK5 damit ein destilliertes Qwen3.6-27B in einem 4B-Modell. Was bringt das Training? Auf Englisch 3,5 Punkte, 67,9 gegen 64,4 %. Auf Deutsch nichts. 82,2 gegen 83,4 %. Ab Werk ist JevK5 besser kalibriert, mit einem ECE von 0,030 gegen 0,136. Das holt der Eigenbau mit einer gefitteten Temperatur allerdings ein (0,027).

Pointer-Head: Kev

Kev nimmt das Basismodell ohne Instruct-Tuning und lernt einen eigenen Kopf, der jede Option mit einem Entscheidungs-Token vergleicht. Jede Frage wird isoliert gerechnet, bis zu 255 Optionen sind möglich. Das ist sauberer gebaut als die Buchstaben-Logits. Es braucht aber Training, weil ein Basismodell diese Aufgabe nicht von selbst kann, und im Test landet Kev unter dem untrainierten Eigenbau: 75,4 gegen 83,4 % auf Deutsch, 63,0 gegen 64,4 % auf den Benchmarks. Die fest eingebaute Temperatur von 2,41 macht Kev auf diesen Daten zu unsicher, der Fit hätte gern 0,59. Fairerweise muss man sagen, dass Kev der am besten dokumentierte Nachbau ist, mit vorregistrierten Runden und gesperrten Tests, und selbst angibt, dass seine Gewinne auf den eigenen Suiten „in distribution“ sind.

Embedding-Ähnlichkeit: CLM, Laya, embed-router

CLM bettet den State und jede Option getrennt ein und vergleicht per Kosinus. Bei choice-Fragen bettet es nur die Beschreibung ein, bei noul vergleicht es „Yes. This is true: …“ gegen „No. This is false: …“. Das ist ein Embedding-Router mit einem 8B-Encoder. So verhält er sich auch. 42,8 % auf Deutsch, gegen 42,7 % beim 0,6B-Embedding-Router. Beide liegen unter dem, was „immer die häufigste Antwort“ schafft, nämlich 45,1 %. Die beworbene „Jev-Parität“ stammt aus Ranking-Aufgaben in Agenten, also Tool-Aufrufen und Spielen, und gilt teils nur mit eigens trainierten Köpfen. Für Klassifikation wurde CLM nie trainiert. Liegt es vielleicht an unserem Aufbau? Wir haben das geprüft, und nein. Mit dem echten vLLM-Setup des Herstellers kommt dasselbe heraus wie mit einem Nachbau des Encoders ohne End-Token.

Laya sitzt dazwischen. Ein kleiner Encoder liest die Optionen zusammen mit dem Text und bewertet jede mit einem Klassifikator, und das ist mit 17 ms die schnellste Lösung im Feld. Die eigene README nennt das Basismodell allerdings „a fast base to specialise, not a zero-shot decision engine“ und berichtet zero-shot selbst 0,362, unter der Mehrheitsbasis von 0,461. Die Schlagzeile „schlägt Jev“ (0,766 gegen 0,727) gilt für einen Checkpoint, der auf genau diesem Benchmark nachtrainiert wurde, und eine Ergebnisdatei dazu ist laut README nicht veröffentlicht. Gemessen: 41,4 % auf Deutsch, 48,7 % auf den Benchmarks. Mit einer Ausnahme. Bei Ticket-Typen erreicht Laya 84 %, den besten Wert aller Systeme. Vermutlich liegt die Domäne nah an seinem Training, belegen lässt sich das nicht.

Kennen die Nachbauten den Test schon?

Teilweise. Kev hat auf den Train-Splits von banking77, boolq, mnli, sst5 und yelp trainiert, und genau diese Aufgaben stecken in jev-bench und tasksource, dort aus den Test-Splits. Einzelne Items sind also wahrscheinlich nicht bekannt, die Aufgaben und Labelräume schon. Bei JevK5 steht die Liste der 26 Train-Splits nur in der Online-Modellkarte, eine Überschneidung ist plausibel. Zu evalsafe gibt es bei keinem Nachbau einen Hinweis. Die Vorteile von Kev und JevK5 auf jev-bench sind deshalb eher Ober- als Untergrenzen.

Wer liegt vorn?

Unter den lokalen Systemen liegen drei eng beieinander: JevK5, der Eigenbau und Kev. Der Eigenbau ohne Training ist so gut wie die trainierten Nachbauten. Laya und CLM liegen zero-shot auf oder unter dem Niveau von „immer die häufigste Antwort“.

Trefferquote je SystemMessung 30.09.2026 · RTX 4090 · Test-Split

Eigene Use Cases, Deutsch (883 Entscheidungen)

• Qwen3.6-27B (JSON)94,8 %
• Eigenbau (Qwen3.5-4B)83,4 %
• JevK5 v0.382,2 %
• Kev-4B75,4 %
• CLM-v0.1-8B42,8 %
• embed-router 0,6B42,7 %
• Laya multilingual41,4 %

┆ immer die häufigste Antwort: 45,1 %

HF-Benchmarks, Englisch (755 Entscheidungen)

• Qwen3.6-27B (JSON)69,7 %
• JevK5 v0.367,9 %
• Eigenbau (Qwen3.5-4B)64,4 %
• Kev-4B63,0 %
• Laya multilingual48,7 %
• CLM-v0.1-8B33,6 %
• embed-router 0,6B30,5 %

Auf den englischen Benchmarks liegen alle niedriger. Die Aufgaben sind schwerer, und die Labels sind teils unscharf. An der Reihenfolge der drei 4B-Modelle ändert das wenig.

Das große Sprachmodell gewinnt auf Deutsch deutlich, mit 94,8 %. Es kostet aber pro Request rund drei Sekunden statt hundert Millisekunden. Lohnt sich das? Kommt darauf an, wie oft dein Agent entscheiden muss.

Tempo gegen TrefferquoteMessung 30.09.2026 · RTX 4090 · Test-Split

Ein Forward-Pass statt Generierung macht die besten 4B-Modelle 18- bis 34-mal schneller als das 27B-Modell, 43 bis 101 ms gegen 1,4 bis 3,1 Sekunden. Auf Deutsch liegen sie dafür 11 bis 13 Punkte zurück. Bei einem Agenten, der in einer Schleife zwanzig kleine Routing-Entscheidungen trifft, ist das der Unterschied zwischen zwei Sekunden und einer Minute. Spürbar.

Und gegen Jev?

Jev ist nur auf 450 der 755 Benchmark-Entscheidungen vertreten. Auf genau diesen 450 sieht der Vergleich so aus:

Die 450 Fälle mit Jev-AntwortMessung 30.09.2026 · RTX 4090 · Test-Split

Trefferquote

• Jev 1.13.084,9 %
• Qwen3.6-27B (JSON)83,1 %
• JevK5 v0.378,7 %
• Kev-4B76,2 %
• Eigenbau (Qwen3.5-4B)76,0 %
• Laya multilingual44,0 %
• CLM-v0.1-8B34,9 %

gleiche Antwort wie Jev

• Jev 1.13.0-
• Qwen3.6-27B (JSON)86 %
• JevK5 v0.382 %
• Kev-4B78 %
• Eigenbau (Qwen3.5-4B)80 %
• Laya multilingual44 %
• CLM-v0.1-8B39 %

Jev ist auf den verfügbaren Fällen das genaueste System, mit 84,9 %. Das 27B-Modell liegt knapp dahinter, JevK5 sechs Punkte. Woher kommen diese sechs Punkte?

Wo der Abstand zu Jev entstehtMessung 30.09.2026 · RTX 4090 · Test-Split

Benchmark · Typ	Jev 1.13.0	Qwen3.6-27B	JevK5 v0.3	Kev-4B	Eigenbau
evalsafe · choice	97	99	93	82	93
evalsafe · score	95	84	65	66	67
evalsafe · noul	99	99	99	97	97
jev-bench · choice	80	80	80	74	70
jev-bench · score	49	52	52	51	44
jev-bench · noul	88	86	86	87	84

Fast der ganze Vorsprung kommt aus einer einzigen Zelle: Score-Fragen auf evalsafe, TypeSafes eigenem Eval-Set. Dort erreicht Jev 95 %, die 4B-Modelle 65 bis 67. Auf dem von Menschen gelabelten jev-bench liegt Jev mit 72,5 % gleichauf mit JevK5 und dem 27B-Modell. Und bei evalsafe-noul lauten 91 % der Labels „nein“. Dort kommt jedes System nahe an 100 %, das einfach „nein“ sagt.

Für die evalsafe-Zahlen muss man im Kopf behalten, woher die Labels stammen. Sie sind ein Konsens zweier großer Modelle, und das Set kommt von TypeSafe selbst. Ein Modell, das auf ähnlich erzeugten Labels trainiert wurde, ist dort im Vorteil.

Wozu dann das Ganze?

Wegen der Konfidenz. Eine Verteilung statt eines Textes ist für Agenten-Entscheidungen die bessere Form, weil du mit ihr einen Regler bekommst: Sichere Entscheidungen laufen durch, unsichere gehen an einen Menschen oder an ein größeres Modell. Das kann aber nur funktionieren, wenn die behauptete Sicherheit stimmt. Tut sie das?

Kalibrierung des Eigenbaus (HF)Messung 30.09.2026 · RTX 4090 · Test-Split

• wie ausgeliefert (ECE 0,136)
• nach Temperature Scaling, T = 1,86 (ECE 0,027)

Wie ausgeliefert ist der Eigenbau auf Englisch deutlich zu selbstsicher. Bei behaupteten 86 % trifft er 64 %. Eine einzige Zahl, die Temperatur, auf ein paar hundert Fällen des Dev-Splits gefittet, legt die Kurve auf die Diagonale. Das ist nicht mehr als ein Nachmittag Arbeit. Und es entscheidet darüber, ob du der Zahl im Betrieb trauen kannst, denn ein Schwellwert auf einer unkalibrierten Konfidenz sortiert zuverlässig die falschen Fälle durch.

Automatisierbar bei höchstens 5 % FehlerMessung 30.09.2026 · RTX 4090 · Test-Split

Deutsch, eigene Use Cases

• Jev 1.13.0-
• Eigenbau (Qwen3.5-4B)64 %
• JevK5 v0.351 %
• Kev-4B9 %
• Laya multilingual0 %
• CLM-v0.1-8B0 %

Englisch, HF-Benchmarks

• Jev 1.13.072 %
• Eigenbau (Qwen3.5-4B)24 %
• JevK5 v0.333 %
• Kev-4B7 %
• Laya multilingual0 %
• CLM-v0.1-8B0 %

Auf den deutschen Use Cases lassen sich mit dem Eigenbau 64 % der Entscheidungen ohne Prüfung übernehmen, bei höchstens 5 % Fehlern, mit JevK5 51 %. Auf Englisch sind es 24 bis 33 %, bei Jev 72 %, allerdings nur auf den zwei Benchmarks, für die es Antworten gibt. Das 27B-Modell liefert keine Verteilung und hat deshalb keinen solchen Regler. Es hat nur seine Trefferquote.

Was davon ist Hype?

Die Idee hinter System One ist richtig. Neu ist sie nicht. Der Wert liegt in Schnittstelle, Preis und Latenz, nicht in einer neuen Art Modell. Und die meisten Schlagzeilen der Nachbauten halten einer neutralen Messung nicht stand.

„Kann nicht halluzinieren“ heißt nur, dass die Antwort immer eine erlaubte Option ist. Falsch sein kann sie trotzdem, auch mit hoher Sicherheit. Dieselbe Garantie hat jedes Sprachmodell, dessen Buchstaben-Logits man ausliest.

Jevs Vorsprung ist schmal und hängt am eigenen Testset. Auf dem unabhängigen jev-bench liegt Jev gleichauf mit JevK5 und dem 27B-Modell, und den Abstand macht fast allein die Score-Zelle auf evalsafe, einem Testset, das TypeSafe selbst gebaut und mit Labels aus dem Konsens zweier großer Modelle versehen hat.

„Open-Source-Jev“ ist meist ein bekanntes Verfahren mit neuem Namen. Der stärkste Nachbau, JevK5, ist das Basismodell plus LoRA, destilliert aus Qwen3.6-27B und GPT-6 Luna. Gegenüber 150 Zeilen ohne Training bringt das auf Englisch 3,5 Punkte. Auf Deutsch keinen.

Die Vergleiche mit Jev stammen fast immer aus eigenen Suiten. Kev misst auf eigenen Dev-Sets. Laya schlägt Jev nur mit einem auf den Benchmark nachtrainierten Checkpoint. CLM meint mit „on par“ Ranking in Agenten-Spielen mit feinjustierten Köpfen. JevK5 nennt einen Rang, den die getestete Version v0.3 nie bekommen hat, und v0.2 enthielt laut Changelog sogar Testitems von MMLU-Pro.

Mehr Parameter helfen nur, wenn die Bauweise stimmt. CLM mit 8B ist zero-shot exakt so gut wie ein 0,6B-Embedding-Router, weil es dasselbe tut. Es misst Ähnlichkeit, statt den Text gegen die Frage abzuwägen.

Und Jev? Jev selbst ist gut. Auf den verfügbaren Fällen ist es das genaueste und am besten kalibrierte System, mit 186 ms übers Internet. Nur ist der Abstand zu einem lokalen 4B-Modell kleiner, als die Ankündigung vermuten lässt.

Was heißt das für eigene Projekte?

Musst du also auf Jev warten? Nein. Für deutsche Entscheidungen, die lokal laufen sollen, reicht heute ein offenes 4B-Instruct-Modell mit Option-Logits und einer Temperatur, gefittet auf ein paar hundert eigenen gelabelten Fällen. Das ist der Eigenbau. JevK5 ist eine gleichwertige fertige Alternative, solange die Inhalte englisch sind.

Was die Nachbauten nicht liefern, kann nur Training auf der eigenen Domäne liefern. Der nächste sinnvolle Schritt ist deshalb Fine-Tuning mit 200 bis 500 geprüften eigenen Beispielen, mit Kev, mit Laya oder als LoRA auf dem Eigenbau. Ein weiterer Zero-Shot-Klon bringt erfahrungsgemäß nichts Neues.

Jev lohnt sich als Messlatte und für englische, unkritische Daten. Ob es auf Deutsch vorn liegt, können wir erst mit einem TypeSafe-Key messen. Bis dahin bleibt die Frage offen.

Wo sind die Grenzen dieses Tests?

Was darf man aus diesen Zahlen herauslesen und was nicht? Sie reichen für eine Rangfolge und für grobe Abstände. Unterschiede von zwei bis drei Prozentpunkten sind bei 62 bis 89 Testfällen je Frage nicht belastbar.

• Jev ist nur indirekt gemessen. Es gibt veröffentlichte Antworten auf zwei Benchmarks, keine auf Deutsch. Ob Jev auf den eigenen Use Cases die 83 % der besten 4B-Modelle schlägt, ist offen.
• Die eigenen Labels sind ungeprüft. Texte und Soll-Antworten haben Sprachmodelle geschrieben, gegengelesen hat sie niemand. Das begünstigt vermutlich das 27B-Modell, das ähnlich „denkt“ wie die Label-Autoren.
• Ticket-Prioritäten sind kaum aus dem Text ableitbar. Kein System kommt über 52 %, diese Spalte misst eher Rauschen.
• Nur zero-shot. Laya und Kev sind laut Hersteller als Basis für Fine-Tuning gedacht. Wie gut sie nach 200 bis 500 eigenen Beispielen sind, misst dieser Test nicht.
• Die Prompts sind nicht optimiert. Die Fragen sind für alle Systeme gleich formuliert, bei den eigenen Use Cases auf Deutsch. Modelle mit englischem Trainingsprompt verlieren dadurch womöglich etwas.
• Die Latenzen sind Laborwerte. Eine Anfrage nach der anderen, kein Batching, keine Last. Jevs 186 ms enthalten den Weg übers Internet und stammen aus der Messung des jev-bench-Autors.
• Nur 4B-Größen. kev-9b und kev-0.8b sind registriert, aber nicht gelaufen.