Die KI, die nicht sprechen wollte: System One lokal auf der eigenen Maschine

Die KI, die nicht sprechen wollte: System One lokal auf der eigenen Maschine

Um 06:16 Uhr an einem Dienstagmorgen landete ein Support-Ticket vor mir: „Ich wurde für September zweimal abgebucht und kündige am Freitag, wenn es nicht erstattet wird.“

Drei Dinge müssen mit diesem Satz passieren. Jemand muss entscheiden, welches Team zuständig ist. Jemand muss einschätzen, wie dringend es ist. Und jemand muss bemerken, dass der Kunde gerade mit Kündigung droht. An einem guten Tag erledigt ein Mensch alle drei Punkte in etwa vier Sekunden und denkt nie wieder darüber nach.

Ich habe getan, was ich mittlerweile immer tue und was fast niemand, mit dem ich spreche, bisher ausprobiert hat: Ich habe die Entscheidung drei Modellen überlassen, die auf meine eigene Festplatte passen und von denen keines einen Satz schreiben kann. Zwei von ihnen brauchten weniger als eine Sekunde. Das kleinste lag bei der Kündigungsdrohung falsch — es schätzte die Wahrscheinlichkeit auf etwa eins zu vier, obwohl der Kunde das Wort „kündigen“ verwendet hatte — und ich wusste nur deshalb, ihm nicht zu trauen, weil dieselbe Antwort eine zweite Zahl enthielt, die mir verriet, dass es riet.

Das ist die Geschichte dieses Morgens und der Modellklasse dahinter. Kein Benchmark-Review, sondern das, was ich tatsächlich gemacht habe: vier Modelle heruntergeladen, sie auf einer Maschine ohne Grafikkarte laufen lassen und aufgeschrieben, was sie sagten. Am Ende können Sie dasselbe tun und wissen, welches der vier Modelle Sie nutzen sollten und welches Sie besser ignorieren.

„Unstrukturierter Zustand rein, getypte probabilistische Entscheidungen raus. Das Modell liest die Situation Ihres Programms einmal und liefert für jede angebotene Antwort eine Zahl.“

Warum die Frage an einen Chatbot der falsche Weg war

Jedes Chatmodell, das Sie bisher genutzt haben — Claude, GPT, Gemini, die offene Llama-Familie — antwortet, indem es schreibt. Es generiert Ihre Antwort Token für Token in Prosa, und dann muss Ihre Anwendung die Bedeutung aus dem String zurücklesen. Sie haben nach einer Kategorie gefragt; Sie erhielten einen Absatz; Sie schrieben einen Regex und hofften.

Genau hier fließt das Geld. Nicht in die Inferenz — sondern in die Infrastruktur drumherum. Der erneute Versuch, wenn das Modell Prosa statt JSON zurückgibt. Der Schema-Validator. Die zwölfzeilige System-Prompt, die es anfleht, mit einem Wort zu antworten. Der vierteljährliche Nachmittag, an dem ein Anbieter stillschweigend sein Format ändert und Ihre Pipeline beginnt, Entscheidungen lautlos zu verwerfen.

Ein Entscheidungsmodell lehnt all das ab. Sie senden einen Block Programmzustand und eine Reihe getypter Fragen, und es liefert getypte Antworten — eine gewählte Option, eine Position auf einer Skala oder die Wahrscheinlichkeit, dass eine Aussage wahr ist — mit angehängten Wahrscheinlichkeiten. Keine Prosa. Nichts zu parsen. Die Modellklasse heißt System One, entlehnt aus Daniel Kahnemans Zwei-System-Theorie des Denkens: System 1 ist das schnelle, automatische Urteil, das Sie über ein Gesicht oder eine Bedrohung fällen; System 2 ist die langsame Abwägung, die Sie bei einer Hypothek anstellen. Ihr Chatmodell ist System 2. Dies hier ist das andere.

TypeSafe AI — ein Labor aus San Francisco, gegründet von Diogo Almeida, einem der Forscher hinter RLHF — kam am 15. September 2026 mit der Idee aus dem Stealth-Modus und 40 Millionen Dollar Seed-Finanzierung und lieferte Jev, das erste öffentliche Modell dieser Klasse aus. Der Name ist eine Anspielung auf William Stanley Jevons, den Ökonomen, der beobachtete, dass die Verbilligung einer Ressource dazu führt, dass mehr davon genutzt wird, nicht weniger. Die Wette lautet: Entscheidungen werden so günstig, dass Software Millionen davon trifft.

Jev ist geschlossen, gehostet und exzellent — und es ist eines von vier Modellen in dieser Geschichte, nicht die ganze Geschichte. Innerhalb von drei Wochen nach dem Launch war das von ihm definierte Wire-Format in llama.cpp und Ollama implementiert, den beiden meistgenutzten Methoden, um ein Modell auf der eigenen Hardware laufen zu lassen, und offene Modelle mit identischer API waren in jeder Größenklasse aufgetaucht. (Ich habe diese Welle in System One Goes Local (/blog/system-one-goes-local) kartiert; dieser Artikel ist die praktische Hälfte dieser Karte.) Das ist der Teil, der verändert, was Sie bauen können.

Die drei Fragen, die ein Entscheidungsmodell beantworten kann

Die gesamte Schnittstelle besteht aus drei Fragetypen. Alles andere ist Buchhaltung.

| Type     | You send                                                             | You get back                                                                   |
|----------|----------------------------------------------------------------------|--------------------------------------------------------------------------------|
|  choice  |  a set of named options, each with a description of when it applies  |  the winning option, plus a probability for every option                       |
|  score   |  2 to 10 ordered levels, lowest first                                |  the expected level — which can land between two levels — plus a distribution  |
|  noul    |  a statement                                                         |  the probability the statement is true                                         |

Hier ist die tatsächliche Anfrage, die ich an diesem Morgen geschickt habe. Es ist das ganze Programm:

{
  "model": "ggml-org/Julia-1-GGUF:Q8_0",
  "state": "I was charged twice for September and I am cancelling on Friday unless it is refunded.",
  "questions": {
    "team": {
      "type": "choice",
      "instructions": "Which team should handle this ticket?",
      "criteria": {
        "billing":   "Payments, invoices, refunds",
        "technical": "Bugs and outages",
        "sales":     "Plans and upgrades"
      }
    },
    "urgency": {
      "type": "score",
      "instructions": "How urgent is this ticket?",
      "criteria": ["Low", "Normal", "High", "Urgent"]
    },
    "churn": {
      "type": "noul",
      "instructions": "The customer threatens to cancel."
    }
  }
}

Drei Fragen, unabhängig beantwortet, in einem Durchgang. Und die Antwort, die zurückkam, ist der Grund, warum diese Kategorie existiert:

{
  "model": "ggml-org/Julia-1-GGUF:Q8_0",
  "answers": {
    "team":    { "type": "choice", "choice": "billing",
                 "probabilities": { "billing": 0.958, "technical": 0.017, "sales": 0.025 },
                 "confidence": 0.937 },
    "urgency": { "type": "score", "score": 1.42,
                 "legend": { "0": "Low", "1": "Normal", "2": "High", "3": "Urgent" },
                 "probabilities": { "0": 0.339, "1": 0.112, "2": 0.337, "3": 0.212 },
                 "confidence": 0.0 },
    "churn":   { "type": "noul", "noul": 0.269 }
  },
  "usage": { "input_tokens": 118, "output_tokens": 0 }
}

Lesen Sie die letzte Zeile zweimal. output_tokens: 0. Das Modell hat überhaupt keine Tokens erzeugt — es hat den Zustand einmal gelesen und eine Wahrscheinlichkeit aus seinen eigenen Internas abgegriffen. Es gibt keinen Generierungsschritt, der langsam sein könnte, und keinen Text, der auf eine Weise falsch sein könnte, die Ihr Parser nicht sieht.

Drei Urteile stecken darin, und eines davon ist eine Warnung. Ich komme auf die urgency Antwort zurück, denn ihr confidence von genau 0.0 ist das Einzige, was in der Rückmeldung wirklich nützt.

Auf dem eigenen Rechner einrichten

Mein Arbeitsplatzrechner hat keine Grafikkarte. Zwölf CPU-Kerne, 15 GB RAM, ein Linux-Kernel. Hätte das Setup eine GPU gebraucht, wäre ich hier stehengeblieben, und dieser Artikel wäre kürzer ausgefallen.

Braucht es nicht. Alles Folgende ist echter Output von diesem Rechner, datiert mit 14. Oktober 2026.

Schritt eins: Runtime besorgen. llama.cpp hat die Decision-Model-Unterstützung am 2. Oktober 2026 in PR #29818 eingebaut, und das ist der ganze Trick: /v1/systemone ist jetzt eine Route in einem Programm, das Sie vielleicht schon haben. Der Haken, an dem Leute in den ersten zehn Minuten scheitern, ist, dass die Route in keiner älteren Version existierte — eine veraltete Kopie startet Ihr Modell problemlos und antwortet dann 404 page not found, was wie eine kaputte Anfrage aussieht, aber in Wahrheit ein veralteter Binary ist. Der erste Build mit dem Endpunkt war b11361; ich habe b11609verwendet:

curl -LO https://github.com/ggml-org/llama.cpp/releases/download/b11609/llama-b11609-bin-ubuntu-x64.tar.gz
tar xzf llama-b11609-bin-ubuntu-x64.tar.gz
./llama-b11609/llama-server --version
# version: 0.6.0-dev (build 11609, commit fcac19079)

Schritt zwei: Modell starten. Das -hf Flag lädt die Gewichte beim ersten Lauf von Hugging Face und cached sie, sodass der zweite Start sofort erfolgt. Keine Konfigurationsdatei, keine Flags, die man sich merken muss — der Server erkennt ein Decision-Modell anhand von Metadaten in der Datei und schaltet seine Ein- und Ausgabeverarbeitung selbstständig um:

./llama-b11609/llama-server -hf ggml-org/Julia-1-GGUF:Q8_0 --port 8080

Nach zehn Sekunden stand das hier im Log, und ich habe nie ein Modell erlebt, das sich präziser beschrieben hätte:

init: decision model type: laya
model loaded
listening on http://127.0.0.1:8080

Die Metadatenzeile output_modalities: ["decisions"] in /v1/models ist der entscheidende Hinweis: kein Text, Entscheidungen.

Schritt drei: abfragen. curl den Endpunkt mit obigem JSON ansprechen und die Antwort lesen. Das ist der gesamte lokale Aufbau — drei Befehle, einer davon ein Download.

Eine Falle, die Sie kennen sollten, bevor Sie es versuchen: Ein Laufzeitumgebung wie diese auf ein gewöhnliches Chat-Modell zu richten, macht daraus kein Entscheidungsmodell. Fehlt im GGUF die Entscheidungs-Metadaten, antwortet llama.cpp 501 This model is not a decision model — ein klarer Fehler, und weit besser als die Alternative, dass ein Chat-Modell stillschweigend Prosa auf Ihre /v1/systemone Anfrage liefert und Ihr Parser einfach annimmt, was auch immer herauskommt.

Das Urteil: drei Modelle, ein Ticket

Dann habe ich das getan, was aus einer Demo eine Entscheidung macht, und dasselbe Ticket durch drei offene Modelle sehr unterschiedlicher Größe geschickt. Gleiche Maschine, gleiche Fragen, gleiche Wörter im state Feld.

| Metric                           | Julia-1 (144M)  | Laya (421M)     | Kev-4B (4.2B)   |
|----------------------------------|-----------------|-----------------|-----------------|
|  Which team?                     |  billing 0.958  |  billing 0.978  |  billing 0.846  |
|  Urgency                         |  1.42, flat     |  2.46           |  2.18           |
|  Urgent share of mass            |  21%            |  71%            |  49%            |
|  "Customer threatens to cancel"  |  0.269          |  0.986          |  0.715          |
|  Latency, CPU-only               |  0.138 s        |  0.910 s        |  3.496 s        |
|  Tokens generated                |  0              |  0              |  0              |
|  Download size                   |  160 MB         |  429 MB         |  3.03 GB        |

Alle drei leiten das Ticket an die Abrechnung weiter, und alle drei haben recht. Das ist nicht weiter bemerkenswert — es ist keine schwierige Frage.

Die interessante Spalte ist die vierte. Der Kunde schrieb: „Ich kündige am Freitag, wenn nicht erstattet wird.“ Laya antwortet mit 0,986. Kev-4B antwortet mit 0,715. Julia-1 — das 144-Millionen-Parameter-Modell, dessen gesamter Download nur 160 MB groß ist — antwortet mit 0,269, was bedeutet, dass es glaubt, der Kunde drohe wahrscheinlich nicht mit Kündigung. Es hat den offensichtlichsten Satz im Ticket übersehen.

Und hier liegt der Unterschied zwischen einem erträglichen Fehler und einem gefährlichen: Laya brauchte neun Zehntelsekunden für die Antwort statt einem Zehntel. Der Geschwindigkeitsvorteil des kleinen Modells ist real – und ebenso der Preis.

Die Spalte, die mir verriet, welchem Modell ich vertrauen sollte

Sehen Sie sich noch einmal die urgency Antwort von Julia-1 an. Score 1,42 auf einer vierstufigen Skala, mit 34 % der Wahrscheinlichkeit auf Low, 34 % auf High, 21 % auf Urgent und 11 % auf Normal. Das ist ein Münzwurf in Zahlenkleidung. Und die Antwort sagt das auch – in einem Feld, das die meisten überfliegen würden: "confidence": 0.0.

Sicherheit ist eine zweite Achse, berechnet aus der Form der Verteilung, nicht aus der siegreichen Antwort. TypeSafe dokumentiert sie als geschlossene Funktion der Wahrscheinlichkeiten, und ich habe ihre Formel mit meinen eigenen drei Messungen überprüft — (p_max − 1/n) / (1 − 1/n), wobei n die Anzahl der Optionen ist. Sie stimmte bei allen drei Modellen auf zwölf Nachkommastellen überein. Als 0,958 der Masse auf drei Optionen entfielen, betrug die angegebene Sicherheit 0,9366896510790688; die Formel liefert exakt 0,9366896510790688.

Das ist wichtig, weil es zeigt, was diese Zahl nicht ist. Sicherheit ist eine Statistik über Gewissheit, keine Wahrscheinlichkeit, dass die Antwort richtig ist. Sie drückt aus, ob das Modell sagt: „Die Optionen, die ich bekommen habe, sind klar getrennt“ oder „sind es nicht“ – und das sind unterschiedliche Fragen. Ein Modell kann vollkommen sicher und komplett falsch liegen, oder zögerlich und trotzdem richtig. Nutzen Sie es als Filter, nicht als Garantie.

Zwei weitere Eigenschaften, die ich überprüft habe, weil sie beeinflussen, wie man ein solches System testet:

• Es ist deterministisch. Ich habe dieselbe Anfrage dreimal an Julia-1 und zweimal an Kev-4B geschickt. Byte-identische Verteilungen jedes Mal — exakt 0,9577931007193792, wiederholt. Es gibt kein Sampling und keine Temperatur; das Modell liest eine Verteilung aus einem einzigen Forward-Pass aus und wählt das Größte, sodass dieselbe Eingabe dieselbe Antwort liefert und Ihre Regressionstests aussagekräftig sind.
• confidence: 0.0 ist, ob das Modell ehrlich ist. Bei meiner flachen Vier-Stufen-Dringlichkeitsfrage war der Rohwert negativ und wurde auf null gesetzt. Eine Laufzeitumgebung, die 0.0 statt eines schmeichelhaften Mittelwerts ausgibt, ist nützlicher als eine, die immer eine Meinung hat.

Dann stellte ich eine Frage ohne richtige Antwort

Mittlerweile vertraute ich dem Aufbau und misstraute nichts. Also schickte ich ein zweites Ticket, von der Sorte, die Routingsysteme in Demos schlau und im Betrieb dumm aussehen lässt:

„Hi, kurze Frage zu meinem Konto.“

Dieselben drei Optionen. Drei Modelle, drei verschiedene Antworten:

| Model            | Its answer  | Probability | Confidence |
|------------------|-------------|-------------|------------|
|  Julia-1 (144M)  |  sales      |  0.639      |  0.458     |
|  Laya (421M)     |  billing    |  0.598      |  0.397     |
|  Kev-4B (4.2B)   |  technical  |  0.594      |  0.391     |

Null Übereinstimmung. Jedes Modell wählte ein anderes Team, und jedes war sich seiner Sache relativ sicher — ein 64-%-Favorit ist nicht nichts. Erst die dritte Spalte verrät, dass alle drei geraten haben: Keines von ihnen überschritt 0,46 Konfidenz, und jede Verteilung war über die Optionen gestreut.

Das ist der Fehler, der in der Produktion zuschlägt — und der Grund, warum mir die Konfidenzspalte wichtiger ist als die Genauigkeitsspalte. Eine Routing-Schicht, die mit 64 % „sales“ antwortet, sieht für alles, was danach kommt, exakt so aus wie eine, die mit 96 % „billing“ antwortet. Wenn Ihr Code auf das Siegerlabel verzweigt und die Verteilung ignoriert, landet das vage Ticket trotzdem bei einem Menschen — beim falschen, ohne dass eine Warnung aufleuchtet.

Eine Sache muss ich hier noch ehrlich berichten. Das veröffentlichte Beispiel zu genau diesem vagen Ticket weist 0,25 für Julia-1 und 0,80 für Kev-4B aus. Ich habe keine der beiden Zahlen reproduziert. Meine Werte lagen bei 0,639 und 0,594 — und der Grund dafür ist lehrreich, nicht peinlich: Konfidenz ist eine Eigenschaft der Frage, die Sie stellen, nicht des Modells allein. Ändern Sie die Wörter in criteria , und dasselbe Modell ändert seine Meinung darüber, wie sicher es sich ist. Kopieren Sie einen Konfidenz-Schwellenwert aus einem Blogbeitrag, und er wird nicht übertragen; messen Sie Ihren eigenen.

Ein Modell, das mit 64 % „sales“ antwortet, sieht exakt so aus wie eines, das mit 96 % „billing“ antwortet — es sei denn, Sie lesen die Verteilung.

Jeder Begriff in diesem Code, erklärt

Das Glossar, das Sie brauchen, um das JSON in diesem Artikel zu verstehen. Nichts hier ist Jargon um des Jargons willen — jeder Eintrag ist etwas, das die obige Antwort tatsächlich verwendet.

state — die zu beurteilende Situation. Eine Zeichenkette, ein JSON-Objekt oder ein Array. Es ist das Einzige, was das Modell liest, und alles, was es über Ihre Welt „weiß“, steckt darin. Nichts außerhalb des Zustands wird herangezogen.

questions — ein Objekt, das über die von Ihnen gewählten Namen indiziert ist. Ihre Schlüssel gelangen nie zum Modell; sie existieren, damit Sie die Antworten wiederfinden können. Dieselben Schlüssel kommen in answerszurück, weshalb ein falsch zugeordneter Schlüssel null liefert und aussieht, als hätte das Modell keine Meinung.

instructions — die Frage in Worten. criteria — die Beschreibungen Ihrer Optionen. Das sind keine Verzierungen. Die Beschreibungen sind der Bewertungsmaßstab, mit dem das Modell argumentiert, weshalb "technical": "Bugs and outages" besser abschneidet als "technical": "Technical things".

choice / score / noul — die drei Typen. Der ungewöhnliche Name ist wichtig: Ein noul ist kein Boolean. Es ist eine Wahrscheinlichkeit zwischen 0 und 1, also bedeutet 0.5 „echt 50/50“, nicht „mittel“.

probabilities — eine vollständige Verteilung über alle von Ihnen angegebenen Optionen, die sich zu 1 summiert. Dieses Feld sollte protokolliert werden. Der Gewinner ist eine Entscheidung; die Verteilung ist die Begründung dafür.

confidence — eine Statistik, die aus dieser Verteilung berechnet wird, keine separate Schätzung. Siehe oben, was sie bedeutet und was nicht.

legend — für score Fragen die Zuordnung von Stufennummer zurück zu Ihrer Stufenbeschreibung, sodass 2.46 als „zwischen Hoch und Dringend“ gelesen werden kann. Die erwartete Stufe kann zwischen zwei Stufen liegen, weil sie wahrscheinlichkeitsgewichtet ist und nicht einfach ausgewählt wird.

usage — input_tokens ist das, was Sie gesendet haben; output_tokens ist das, was generiert wurde, was bei diesen Modellen immer null ist.

Vorwärtsdurchlauf — ein einmaliges Einlesen der Eingabe durch das Netzwerk. Ein Chatmodell führt pro Ausgabetoken einen Vorwärtsdurchlauf durch, weshalb es Hunderte Millisekunden dauert, bis es zu antworten beginnt. Ein Entscheidungsmodell macht insgesamt nur einen Durchlauf.

Nicht-autoregressiv — „schreibt sich nicht Wort für Wort selbst“. Die Antwort wird aus dem internen Zustand des Modells ausgelesen, statt als Sequenz erzeugt zu werden – das ermöglicht output_tokens: 0 .

Encoder vs. Decoder — die beiden Netzwerkarchitekturen hinter diesen Modellen. Laya ist ein Encoder (ModernBERT) und antwortet in Millisekunden; Kev ist ein Decoder (Qwen3.5) und verarbeitet längere Dokumente besser. Beide antworten über dieselbe API, sodass der Unterschied eine Laufzeitentscheidung und keine Code-Änderung ist.

GGUF — das Dateiformat, das llama.cpp lädt. Eine einzelne Datei mit Gewichten und Metadaten, anhand derer der Server erkennt, ob es sich um ein Entscheidungsmodell oder ein Chatmodell handelt.

Quantisierung und Bezeichnungen wie Q8_0, Q4_K_M, BF16 — die Genauigkeit, mit der jedes Gewicht gespeichert wird. BF16 ist die ursprüngliche Präzision, Q8_0 entspricht etwa 8 Bit pro Gewicht, Q4_K_M etwa 4. Geringere Präzision bedeutet kleineren Download und schnellere Antworten auf langsamer Hardware, allerdings auf Kosten der Genauigkeit. Dasselbe Modell in unterschiedlicher Quantisierung ist ein anderer Kompromiss, kein anderes Modell.

mmap — das Einblenden der Gewichtedatei in den Speicher, weshalb ein 3-GB-Modell auch auf einem Rechner mit nur einem halben Gigabyte freiem RAM geladen werden kann. Die Datei wird bei Bedarf eingelesen, statt komplett in den Arbeitsspeicher kopiert zu werden.

Kontextfenster — das maximale Eingabevolumen, das das Modell verarbeiten kann, in Token. n_ctx_train: 262144 Bei Kev-4B ist das der Trainingskontext; was Sie laden, bestimmt Ihr Server (ich habe 2.048 verwendet). Token entsprechen grob drei Vierteln eines englischen Worts — nicht Zeichen.

Softmax / Argmax — Softmax wandelt die rohen internen Bewertungen des Modells in eine Verteilung mit Summe 1 um; Argmax wählt den größten Wert. Dieses Paar ist der gesamte „Entscheidungsschritt“, und deshalb ist die Ausgabe deterministisch.

Kalibrierung und ECE — Kalibrierung bedeutet, dass das Modell in etwa 80 % der Fälle richtig liegt, wenn es 0,8 angibt. ECE (erwarteter Kalibrierungsfehler) gibt an, wie stark diese Zusage im Schnitt verfehlt wird; niedriger ist besser. TypeSafe hat Jev gezielt dafür trainiert, mit einer Methode namens RLCD — bestärkendes Lernen für kalibrierte Entscheidungen — bewertet nach einer Regel, bei der ehrliche Wahrscheinlichkeitsangaben die einzige Gewinnstrategie sind.

LoRA / Adapter / Decision Head — der günstige Weg, so etwas zu bauen. Kev ist ein kleines trainiertes Add-on (ein LoRA-Adapter) plus ein „Head“: ein winziges Paar Schichten, das jede Ihrer Optionen bewertet und die Verteilung erzeugt, aufgesetzt auf ein eingefrorenes Basismodell. Der Head macht daraus ein Entscheidungsmodell statt eines Chatbots.

Drahtformat / Basis-URL — die Form der Anfrage und wohin sie gesendet wird. Das ist die stille Revolution in dieser Kategorie: Jev, llama.cpp, Ollama, ollajev, ollaya und die offenen Modelle sprechen alle dieselbe /v1/systemone Form, sodass der Wechsel zwischen einem gehosteten Frontier-Modell und einer Datei auf Ihrer Festplatte meist nur eine URL-Änderung bedeutet.

Dasselbe mit Ollama erledigen

Falls Sie bereits Ollama betreiben, können Sie das Tarball überspringen — mit einer Versionshürde.

Ollama hat in /v1/systemone v 0.35.0 am 28. September 2026 eine eigene, mit Jev drahtkompatible Schnittstelle ausgeliefert, und sein Katalog an Entscheidungsmodellen wächst seitdem. Der Ablauf fühlt sich vertraut an:

ollama pull nimble
curl http://localhost:11434/v1/systemone -H 'Content-Type: application/json' -d '{
  "model": "nimble",
  "state": "I was charged twice. Please refund the extra payment.",
  "questions": {
    "team": {
      "type": "choice",
      "instructions": "Which team should handle this ticket?",
      "criteria": { "billing": "Payments and refunds", "technical": "Bugs or integrations" }
    }
  }
}'

Achten Sie auf den Port: Ollama lauscht auf 11434, llama-server auf 8080. Sie kollidieren nicht, Sie können also beide parallel betreiben und am selben Ticket vergleichen.

Zur Versionshürde zeige ich Ihnen lieber den Fehler, als ihn zu beschreiben. Meine eigene Maschine hatte Ollama 0.33.0 installiert. Der Chat-Endpunkt antwortete normal; der Entscheidungs-Endpunkt tat dies:

POST http://127.0.0.1:11434/v1/systemone  ->  404 page not found

Dieser 404 ist kein falsch formulierter Request. Es ist eine Versionsfrage. Entscheidungsunterstützung kam in 0.35.0hinzu, und der Katalog umfasst inzwischen einen Entscheidungsbereich mit acht Modellen — nimble, nimble-v3, tev1, clef, clef-flash, laya, strands-decider und kev. Falls Sie Kev speziell über Ollama nutzen möchten, verlangt das Paket v0.40.4 oder neuer.

Zwei weitere Punkte, die Sie über den Ollama-Weg wissen sollten. Seine Grenzen sind enger als die von llama.cpp: Auswahl- und Bewertungsfragen umfassen 2 bis 26 Optionen (255 ist die allgemeine Obergrenze), und eine Anfrage ohne Bilder muss in 64 KiB passen. Zudem zertifiziert Ollama keine externen GGUF-Entscheidungsdateien. Die Dokumentation beschreibt den Mechanismus — eine CAPABILITY decision Zeile in einer Modelfile — nennt aber nur eigene Modelle. Ollama auf etwa die ggml-org-Laya-GGUF zu richten, ist daher ein nicht unterstützter Versuch und kein dokumentierter Weg. So steht es in der Dokumentation, was sich von dem unterscheidet, was der Code tatsächlich kann.

Falls Sie weder das eine noch das andere betreiben möchten, gibt es eine dritte Option: Kev liefert einen eigenen Server mit, der dieselbe API spricht und direkt eine Hugging Face-Repo-ID entgegennimmt:

uv run --extra serve python -m kev.serve --run jaredpalmer/kev-4b --port 8009

Der Server bindet an 127.0.0.1 und ist offen, sofern Sie nicht KEV_API_KEYsetzen. Ein Stolperstein, den Sie sich notieren sollten: Der Standardport des Codes ist 8008; 8009 ist nur das, was die Beispiele des Projekts explizit übergeben. Kopieren Sie eine Konfiguration aus der Dokumentation ohne das Flag, zeigen Sie auf einen Port, an dem nichts lauscht — und weil das Wire-Format überall identisch ist, ist der falsche Port der häufigste Grund, warum Ihre erste Entscheidung fehlschlägt.

Kev, Nimble, Laya, Jev: vier Antworten auf dieselbe Frage

Vier Modelle definieren die Bandbreite dieser Kategorie, und die ehrliche Lesart ist: Es sind nicht vier Versionen derselben Sache — es sind vier Antworten auf die Frage „Wie viel Modell brauchen Sie eigentlich?“.

Jev — die gehostete Referenz. TypeSafes Frontier-Modell mit geschlossenen Gewichten, ohne lokale Option. Wenn die Entscheidung ‚geschlossen vs. offen‘ für Sie relevant ist — etwa als öffentliche Einrichtung oder in einer regulierten Branche — habe ich diese Frage in Laya vs. Jev: Offene Gewichte und die Souveränitätsfrage (/blog/laya-vs-jev-open-weights-sovereignty) ausführlich behandelt. jev-1.13.0, berechnet mit 0,042 $ pro Million Eingabetokens bei kostenloser Ausgabe, 64k Kontext pro Anfrage (32k für den Zustand plus Ihre längste Frage) und der vom Anbieter angegebenen Latenz von 70–500 ms. Dieses Modell dient als Benchmark für die anderen, und mehreren unabhängigen Messungen zufolge fällt der Vergleich nicht geschönt aus: Jev generiert keine Reasoning-Traces, lässt sich nicht auf eigener Hardware betreiben und ist zugleich das genaueste der vier.

Nimble — ein 9B-Modell, das mit den Frontier-Modellen mithält. Bespoke Labs’ Adapter auf Qwen3.5-9B, Apache 2.0, ~165 MiB zusätzlich zum Basismodell. Bei 324 zurückgehaltenen Beispielen traf er in 90,12 % der Fälle (292/324) die Referenzantwort — gegenüber Jev 1.13.0 mit 93,21 % (302/324). Das reine Qwen3.5-9B-Basismodell erreichte nur 66,36 %, was zeigt, wie viel die Feinabstimmung leistet. Bei einem 13-Datensatz-Makrodurchschnitt über 3.880 menschlich bewertete Entscheidungen lag er bei 74,8 % gegenüber Jev 1.13.0s 76,0 % und führt Jev 1.13.0 bei der Rubrik/Bewertungsteilmenge an (54,6 % gegenüber 50,1 %). Der Haken ist die Hardware: unquantisiert benötigt ein 9B-Modell etwa 18 GB und verlangt eine NVIDIA-GPU mit BF16 oder einen Apple Silicon Mac mit MLX. Es ist kein Laptop-CPU-Modell. Prüfen Sie die Lizenz, bevor Sie darauf aufbauen — das ursprüngliche Nimble steht unter Apache 2.0, aber Nimble v3 unter CC BY-NC 4.0, nicht-kommerziell.

Kev — die Größenleiter, die Sie tatsächlich ausführen können. Eine Familie von Jared Palmer, Apache 2.0, aufgebaut auf Qwen3.5 und Qwen3.8, veröffentlicht in 0.8B, 4B, 9B und 27B, und das Modell, das ich oben ausgeführt habe. Es weist einen held-out-chance-korrigierten Index von 23,3 / 38,0 / 41,0 / 52,3 über diese Größen auf, und in seinem eigenen Out-of-Distribution-Test erzielte die 27B-Version 0,889 gegenüber Jevs 0,857 auf dem Dev-Set — mit dem Hinweis, den das Kev-eigene README freiwillig gibt: Auf MMLU-Pro erreicht die 27B 0,675 gegenüber Jevs 0,840, und bei einem Fehlerbudget von 5 % kann Jev 0,70 neuer Entscheidungen aus unbekannten Quellen automatisieren, gegenüber 0,52–0,69 bei der Kev-Familie. Kev ist das Modell, das die Portabilitätsfrage beantwortet: dieselbe Architektur vom Laptop bis zur Rechenzentrumskarte, ein einziger URL-Wechsel.

Laya — das Modell, das nicht funktionieren dürfte. Convai Innovations’ 421-Millionen-Parameter-Encoder, trainiert mit derselben RLCD-Methode, Apache 2.0, mit einem 512-Token-Kontext im Basis-Checkpoint und etwa 33 ms pro Entscheidung in der Messung des Anbieters. Es war die Überraschung meines Vormittags: eine Datei kleiner als ein Handyfoto, auf einer CPU laufend, die Stornierungsgefahr mit 0,986 erkannte, während ein 4,2B-Decoder sich mit 0,715 begnügte. Sein eigener feinabgestimmter Checkpoint meldet eine Genauigkeit von 0,766 über 2.000 Entscheidungen auf einem 400-Fälle-Typed-Decision-Benchmark gegenüber Jevs veröffentlichten 0,727. Betrachten Sie ein 421M-Modell als Spezialisten, nicht als Generalisten — aber behandeln Sie „klein“ nicht als „Spielzeug“.

Und eine Anmerkung zu dem Modell, das nicht in Ihren Händen ist: der 27B OpenJev ist die größte offene Option und die einzige, die Bilder liest, aber seine Gewichte unterliegen CC BY-NC 4.0 — nicht-kommerziell — und die 19 GB Q4-Datei verlangt eine 24-GB-Karte. Es ist das Modell, das ein Geschäftsgespräch am ehesten mit einem Anwalt beendet.

Was diese Modelle falsch machen

Ich war mehrere tausend Wörter lang enthusiastisch, und dieser Abschnitt entscheidet, ob irgendetwas davon brauchbar ist. Drei Quellen für schlechte Nachrichten, geordnet nach absteigender Autorität.

Die eigene Liste des Anbieters. TypeSafe veröffentlicht eine Seite zu „Modell-Unebenheiten“ für jev-1.13 — neun dokumentierte Fehlermodi, zuletzt geprüft am 2. Oktober 2026 — und sie ist ungewöhnlich offen. Ein Entscheidungsmodell beantwortet die wörtliche Frage statt der gemeinten. Es ist kein Taschenrechner; Arithmetik gehört in Code. Es liest Datumsangaben als Text, nicht als geordnete Größen, daher sind Datumsvergleiche unzuverlässig. Es verliert an Genauigkeit, wenn Verschachtelungen und doppelte Verneinungen zunehmen. Es leidet unter Kontextverfall — irrelevante Details im Zustand verschlechtern aktiv die Trefferquote. Es behandelt den Zustand nicht als feindlich, sodass eingeschleuste Anweisungen die Antwort verändern können. Und es tendiert zu der Option, die Sie zuerst genannt haben, worauf der Anbieter Sie ausdrücklich hinweist, dies zu testen. Ein Anbieter, der die Fehlerliste seines eigenen Modells veröffentlicht, ist es wert, zweimal gelesen zu werden.

Das Audit, das Ihre Architektur ändern sollte. Ein kontrolliertes Audit zur Selbstwissenprüfung in Blackbox-Entscheidungsmodellen förderte den entscheidenden Fehler zutage: Konfidenz ist bei vertrauten Fragen kalibriert, aber versagt als Indikator für fehlendes Wissen. Jenseits seiner Wissensgrenze wird das Modell nicht zögerlich – es wird selbstsicherer, ein Fehler, den eine Neukalibrierung der Konfidenz nicht behebt. Ihr Nachweis ist der, den man sich merken sollte: Bei einem verdeckten fairen Würfelwurf gab Jev eine Wahrscheinlichkeit von 83 % für eine Seite an und lag in 19 % der Fälle richtig – exakt Zufall. Und unter irreführendem, aber themenverwandtem Kontext sank die Genauigkeit von 0,84 auf 0,75, während die Konfidenz bei 0,83 blieb – selbstsicher, falsch und unbeeindruckt.

Die unabhängigen Benchmarks, die weniger schmeichelhaft sind als das Marketing. Die Startseite von TypeSafe verspricht 193,6-fache Geschwindigkeit und 444,6-fache Kosteneinsparung. Zwei unabhängige Reproduktionen mit realen Aufgaben bestätigten die Richtung, nicht aber das Ausmaß: 3,25- bis 3,62-fache Geschwindigkeit und etwa 40,6-fache Kosteneinsparung gegenüber Claude Sonnet 5 bei einer Aufgabe – rund 50- bzw. 11-mal weniger als die Schlagzeile. Bei einer anderen Aufgabe lagen Jev und Claude Sonnet 5 in der Genauigkeit exakt gleichauf bei einer strukturierten Risikoklassifizierung – was die berechtigte Kritik an dieser gesamten Kategorie unterstreicht: Wenn ein Frontier-Modell mit eingeschränkter Decodierung dieselbe Antwort liefert, liegt der Vorteil des Entscheidungsmodells in Latenz und Kosten, nicht in der Leistungsfähigkeit. Und bei diesem zweiten Benchmark lag der p50-Wert bei 421,6 ms für Jev gegenüber 1371,0 ms für Claude; der erste Benchmark ermittelte für Jev p50/p95/p99-Werte von 176/336/532 ms gegenüber Qwen3.8-27B auf maßgeschneiderter Hardware mit 215/452/912 ms. Echte Fortschritte. Kein anderes Universum.

Das akademische Bild ist das nützlichste von allen, weil es weder ein Anbieter noch ein Konkurrent ist. Eine Evaluierung mit 37 Datensätzen und 346.009 Anfragen an jev-1.13.0 — die insgesamt 9,15 $ kostete, bei durchschnittlich 0,36 s pro Anfrage — zeigte Stärken dort, wo man sie erwarten würde: 96,5 % auf IMDB, 96,4 % auf SST-2, 95,5 % auf HellaSwag, 99,6 % bei der Sprachidentifikation, und es übertraf Qwen3.8-27B in 27 von 37 Datensätzen. Es zeigte aber auch die Grenzen: 57,9 % bei der Fünf-Wege-Stimmungsanalyse, 32,2 % beim Erkennen von echtem versus gefälschtem Text, ein F-Score von 0,204 bei der Analyse juristischer Klauseln und eine mehrsprachige Leistung, die von 97,2 % im Englischen auf 37,4 % für nigerianisches Fulfulde einbricht. Die Bewertung generierter Texte war der einzige Bereich, in dem die generative Baseline überlegen war. Und das Kalibrierungsergebnis ist die Nuance, die man mitnehmen sollte: Der gepoolte ECE von 0,028 über 279.925 Antworten ist tatsächlich gut kalibriert — doch die vorhandene Fehlkalibrierung ist fast immer Überzuversicht, konzentriert genau dort, wo die Genauigkeit am niedrigsten ist.

Und das ist die ganze Lehre. Lesen Sie die Konfidenz, setzen Sie Schranken ein und behalten Sie Ihre Schwellenwerte dort, wo ein Mensch sie überprüft.

Das Fazit

Fünf Dinge, die ich heute jemandem mitgeben würde, der damit beginnt.

Entscheiden und Erklären trennen. Bitten Sie nicht ein einziges Modell, den Pfad zu wählen und gleichzeitig zu begründen. Lassen Sie das Entscheidungsmodell auswählen — in 138 ms, mit einer Verteilung — und Ihr Chatmodell die Erklärung schreiben, falls ein Mensch danach fragt.

Formulieren Sie Ihre Optionen wie eine Bewertungsmatrix, nicht wie eine Speisekarte. Jede Beschreibung, die Sie in criteria schreiben, ist Material für die Schlussfolgerung des Modells. "billing": "Payments, invoices, refunds" ist zehnmal so viel wert wie "billing": "Billing".

Protokollieren Sie die Verteilung und setzen Sie Schranken dafür. Der Sieger ist eine Entscheidung; die Wahrscheinlichkeiten sind der Prüfpfad. Handeln Sie bei sicheren Antworten, leiten Sie den Rest an einen Menschen weiter und behandeln Sie die Größe des Zweitplatzierten genauso ernst wie die des Siegers. Meine flache Dringlichkeitsantwort — 34 % Niedrig gegen 34 % Hoch — ist der Fall, bei dem Sie nicht handeln dürfen.

Messen Sie Ihre eigene Mindestzuversicht. Meine entsprach nicht den veröffentlichten Zahlen, denn die Zuversicht hängt von der Bewertungsmatrix ab, die Sie geschrieben haben, nicht vom Modell. Ein Schwellenwert, der aus einem Blogbeitrag übernommen wurde, ist ein Münzwurf.

Setzen Sie kein 144M-Modell hinter eine Geschäftsregel, auf die es Ihnen ankommt. Es war zwanzigmal schneller und hat das Wort „cancelling“ übersehen. Beginnen Sie mit dem kleinsten Modell, das Ihre eigene Genauigkeitsschwelle erfüllt — und wenn die Antwort wichtig ist, dann sind das Kev-4B, Nimble 9B, Laya oder der gehostete Jev, in der Reihenfolge, die Ihre Hardware und Lizenz zulassen.

Die Modelle, die nicht sprechen, sind für einen überraschend großen Teil der Softwarearbeit genau die, auf die Sie gewartet haben.

Weiterlesen — die Quellen

Jede unten aufgeführte Quelle wurde während des Schreibens abgerufen und geprüft, und jede hat eine Antwort geliefert. Beginnen Sie mit der Dokumentation des Anbieters, wenn Sie nur eine Sache lesen — die Seite zur Zuversicht und die Seite zur Unebenheit sind die beiden, die Ihre Gestaltung rund um diese Modelle verändern.

Die Klasse, das Original und die Funktionsweise

• System One — TypeSafe-KI-Dokumentation: Definition der Klasse und die eigene Einordnung des Anbieters, wofür sie gedacht ist. — https://docs.typesafe.ai/concepts/system-one
• Primitives (Fragen) — TypeSafe-KI-Dokumentation: `choice`, [`score`](https://docs.typesafe.ai/primitives/score) und [`noul`](https://docs.typesafe.ai/primitives/noul) vollständig, inklusive der Optionen- und Stufenbegrenzungen. — https://docs.typesafe.ai/primitives
• Confidence — TypeSafe-KI-Dokumentation: die geschlossene Confidence-Formel, die ich mit eigenen Messungen verifiziert habe, sowie die klare Aussage des Anbieters, dass es sich um eine Verteilungsstatistik handelt. — https://docs.typesafe.ai/confidence
• Jev 1.13 Unregelmäßigkeiten — TypeSafe-KI-Dokumentation: neun dokumentierte Fehlermodi. Die ehrlichste Seite in diesem Ökosystem. — https://docs.typesafe.ai/model-jaggedness/jev-1.13
• API-Referenz — TypeSafe-KI-Dokumentation: und [Modelle](https://docs.typesafe.ai/models) — exakte Anfrage- und Antwortkörper, Preise, Kontext- und Ratenlimits. — https://docs.typesafe.ai/api
• System One Models & Jev vorgestellt — TypeSafe KI: die Launch-Einordnung und das „maschinennative“ Argument. — https://typesafe.ai/blog/introducing-system-one-models-and-jev
• Lügen, verdammte Lügen und Benchmarks — TypeSafe KI: der Anbieter argumentiert, dass Benchmarks leicht manipulierbar sind, und verzichtet auf die Veröffentlichung einer Standardtabelle. — https://typesafe.ai/blog/antibenchmaxxing
• Was ist Jev? — OpenRouter: und [Jev-Dokumentation — OpenRouter](https://openrouter.ai/docs/guides/community/jev) — der einfachste Weg, Jev ohne separates Konto aufzurufen, sowie der Rat zur Audit-Trail. — https://openrouter.ai/blog/insights/what-is-jev/
• Jev (KI-Modell): ) und [Jevons-Paradoxon](https://en.wikipedia.org/wiki/Jevons_paradox) — woher die Namen stammen. — https://en.wikipedia.org/wiki/Jev_(AI_model
• Maps of Bounded Rationality — Daniel Kahneman, Nobel-Vortrag (PDF): die ursprüngliche System-1-/System-2-Unterscheidung, nach der die Klasse benannt ist. — https://www.nobelprize.org/uploads/2018/06/kahnemann-lecture.pdf

Lokal auf dem eigenen Rechner betreiben

• Neu in llama.cpp: Entscheidungsmodelle — ggml-org / Hugging Face: der Endpunkt, die Modelltabelle, der Konfidenzschwellen-Ratschlag und der Beginn der lokalen Geschichte. — https://huggingface.co/blog/ggml-org/decision-models-in-llamacpp
• llama.cpp PR #29818: die eigentliche Implementierung und die Build-Historie, die zeigt, welche Versionen die Route enthalten. — https://github.com/ggml-org/llama.cpp/pull/29818
• Decision — Ollama-Dokumentation: und [System One API — Ollama-Dokumentation](https://docs.ollama.com/api/systemone) — die Ollama-Route, ihre Grenzen und die Versionssperre. — https://docs.ollama.com/capabilities/decision
• Ollama unterstützt jetzt Jev-ähnliche Entscheidungsmodelle — Ollama-Blog: die Version 0.35, die es nativ einführt. — https://ollama.com/blog/ollama-now-supports-jev-style-decision-models
• Modelfile-Referenz — Ollama-Dokumentation: die Zeile `CAPABILITY decision`, um Ollama auf ein eigenes GGUF-Entscheidungsmodell zu verweisen. — https://docs.ollama.com/modelfile
• ollajev: und [ollaya](https://github.com/ollaya-dev/ollaya) ([Schnellstart](https://ollaya.dev/docs/quickstart), [TypeSafe-Kompatibilität](https://ollaya.dev/docs/typesafe-compatibility)) — die beiden Drittanbieter-Runtimes, die sich wie Paketmanager für Entscheidungsmodelle verhalten, mit eigenen Modellregalen und Hardware-Hinweisen. — https://github.com/nvkudva/ollajev

Die vier Modelle

• jaredpalmer/kev: README, die [Versionshinweise zu 1.0](https://raw.githubusercontent.com/jaredpalmer/kev/main/docs/releases/kev-1.0.md), der [Serving-Einstiegspunkt](https://raw.githubusercontent.com/jaredpalmer/kev/main/kev/serve.py) und das [Long-Context-Issue #48](https://github.com/jaredpalmer/kev/issues/48). — https://github.com/jaredpalmer/kev
• kev — Ollama-Bibliothek: die gepackte Version, falls Sie lieber keinen eigenen Server betreiben möchten. — https://ollama.com/library/kev
• Bespoke-Nimble-9B — Hugging Face: und [nimble — Ollama-Bibliothek](https://ollama.com/library/nimble) — die Modellkarte, die kontrastive Trainingsmethode und der veröffentlichte Vergleich mit Jev. — https://huggingface.co/bespokelabs/Bespoke-Nimble-9B
• convaiinnovations/laya: , [laya-typed-decisions](https://huggingface.co/convaiinnovations/laya-typed-decisions) und [laya-multilingual](https://huggingface.co/convaiinnovations/laya-multilingual) — der 421M-Encoder, seine Benchmark-Tabelle und sein mehrsprachiges Pendant. — https://huggingface.co/convaiinnovations/laya
• ggml-org/Laya-GGUF: , [Julia-1-GGUF](https://huggingface.co/api/models/ggml-org/Julia-1-GGUF/tree/main) und [Kev-4B-GGUF](https://huggingface.co/api/models/ggml-org/Kev-4B-GGUF/tree/main) — die genauen Dateien, Größen und Quantisierungen, die ich ausgeführt habe. — https://huggingface.co/ggml-org/Laya-GGUF
• Entscheidungsmodelle — Ollama-Modellsuche: der aktuelle Katalog, damit Sie sehen, was seit der Veröffentlichung dieses Artikels hinzugekommen ist. — https://ollama.com/search?c=decision

Die Belege, inklusive der unvorteilhaften Teile

• Evaluierung und Benchmarking des System One-Modells Jev — arXiv:2609.37647: ([vollständiges HTML](https://arxiv.org/html/2609.37647v1)) — 37 Datensätze, 346.009 Anfragen, 9,15 $ und die Zahlen pro Datensatz einschließlich der Fälle, in denen Jev verliert. — https://arxiv.org/abs/2609.37647
• Jenseits der Antwortsicherheit: Eine kontrollierte Prüfung von Selbstwissen in einem Blackbox-Entscheidungsmodell — arXiv:2610.01006: die Erkenntnis, dass Sicherheit kein Selbstwissen ist und das Modell jenseits seiner Wissensgrenze noch sicherer wird. — https://arxiv.org/html/2610.01006v1
• Jev würfelt nicht — Kanta Hayashi: die Würfel-Demonstration des selbstbewussten Ratens. — https://kantahayashiai.github.io/posts/jev-does-not-play-dice/
• themsquared/jev-benchmark: und [iammrduncan/typesafe-ai-benchmark](https://github.com/iammrduncan/typesafe-ai-benchmark) — zwei unabhängige, reproduzierbare Benchmarks, die gemeinsam der Grund dafür sind, dass die 193,6-fache Schlagzeile eher als Obergrenze denn als Erwartung zu lesen ist. — https://github.com/themsquared/jev-benchmark
• Jevs Architektur enthüllt — Archer Hume: eine Blackbox-Rekonstruktion aus rund 10.000 instrumentierten Aufrufen, einschließlich einer unabhängig gemessenen ECE von 0,0313. — https://archerhume.com/posts/jevs-architecture-unmasked/
• Entscheidungsmodelle in llama.cpp: Was /v1/systemone tatsächlich evaluiert — eine praxisnahe Einschätzung, was der Endpunkt leistet, und der `501`-Fehler, den man erhält, wenn man ihn auf ein Chatmodell richtet. — https://ai.thesatyajit.com/articles/llamacpp-decision-models

Alle Messungen, die in diesem Artikel mit „meine Maschine“ gekennzeichnet sind, wurden am 14. Oktober 2026 durchgeführt, ausschließlich auf der CPU, mit llama.cpp-Build b11609 und ggml-org-GGUF-Dateien. Sie sind mit den Befehlen im Setup-Abschnitt reproduzierbar.