Entscheidungsmodelle in Ollama und vLLM: Klassifizieren und Routen über /v1/systemone

/01Was Ollama und vLLM seit dem 28. September ausliefern

Entscheidungsmodelle sind Sprachmodelle, die keinen Text schreiben, sondern getypte Fragen beantworten: Sie wählen eine Option aus einer Liste, geben eine Wahrscheinlichkeit für Ja an oder setzen einen Text auf eine Stufenskala – und liefern zu jeder möglichen Antwort die Wahrscheinlichkeit mit. Seit Ende September bedienen Ollama und vLLM dafür denselben Endpunkt, POST /v1/systemone. Für Ticket-Triage, Modell-Routing und Freigabeprüfungen ist das die erste Bauform, die lokal läuft, in Millisekunden antwortet und deren Ergebnis ein Skript ohne Textzerlegung weiterverarbeiten kann.

Die Chronologie, belegt an den Release-Seiten:

• 28. September 2026, Ollama 0.35.0: Entscheidungsmodelle über /v1/systemone, „based on TypeSafe’s Jev API“. Erste Modelle: Nimble von Bespoke Labs und Tev1 von Together AI. Drei Fragetypen: choice, noul, score.
• 29. September, Ollama-Blog und Ollama 0.35.1: Der Blogeintrag nennt Ticket-Triage, Modell-Routing und Inhalts- oder Sicherheitsmoderation als Einsatzzweck. 0.35.1 bringt Clef (27B) und Clef Flash (9B) von Cloudflare, beide mit Bildern im Zustand.
• 12. Oktober, Ollama 0.40.4: Entscheidungen direkt im Terminal mit ollama run … --ask.
• 14. Oktober, Ollama 0.40.5: Entscheidungsmodelle auch in Ollamas Cloud, über clef:cloud und clef-flash:cloud.
• 18. Oktober, Ollama 0.40.7: pplx-decider, ein 27B-Entscheidungsmodell von Perplexity.
• 18. Oktober, vLLM 0.32.0: 814 Commits von 363 Beitragenden; /v1/systemone beantwortet choice, noul und score, ist standardmäßig eingeschaltet und läuft zusätzlich auf Cloudflare/clef-omni, LiquidAI/d1-3B und DiffusionGemma.

Drei Wochen, zwei Laufzeiten, sechs Modelle. Die folgenden Abschnitte zeigen, was der Endpunkt technisch tut, welche Modelle wohin passen, wie die Aufrufe aussehen – und wo die Sache für den Mittelstand schlicht überflüssig ist.

/02Was ein Entscheidungsmodell anders macht als ein Chatmodell

Ein Chatmodell erzeugt Token für Token; wer daraus eine Kategorie machen will, verlangt JSON, prüft das Ergebnis und hofft, dass das Modell nicht „Kategorie: wahrscheinlich Abrechnung“ schreibt. Ein Entscheidungsmodell liest stattdessen den Zustand (state) und die Fragen und bewertet die erlaubten Antworten direkt. Die Ollama-Modellseite zu Nimble beschreibt das so: Das Modell liest den Prompt einmal je Frage und bewertet die Antwort-Tokens unmittelbar, ohne Denkschritt. Clef und pplx-decider gehen weiter und bewerten laut ihren Modellseiten jede Option jeder Frage gemeinsam in einem einzigen Durchlauf.

Das Ergebnis ist eine Verteilung, keine Formulierung. Bei choice kommt die gewählte Option mit den Wahrscheinlichkeiten aller Optionen und einem confidence-Wert zurück. Bei noul – der Ja/Nein-Frage – kommt eine einzige Zahl, die Wahrscheinlichkeit für „wahr“. Bei score rechnet der Endpunkt einen Erwartungswert über die Stufen; die Ollama-Dokumentation gibt die Formel für drei Stufen an: score = 0 × P(Routine) + 1 × P(Soon) + 2 × P(Immediate).

Zwei Folgen davon sind für den Betrieb wichtiger als jede Benchmark-Zahl:

• Der Ausgabeumfang ist fest. Im Beispiel der Ollama-Release-Notes zu 0.35.0 meldet die Antwort 174 Eingabe- und 1 Ausgabe-Token; Clef Flash meldet im Bildbeispiel 0 Ausgabe-Token. Die Laufzeit hängt fast nur an der Eingabelänge. Das macht Entscheidungen planbar, auch unter Last.
• Das Ergebnis ist maschinenlesbar, ohne Parser. Ein Gateway oder ein Ticket-System liest .answers.team.choice und die Wahrscheinlichkeit, nicht einen Satz. Wer bisher Klassifikation über Structured Output mit einem Chatmodell gebaut hat, kennt den Aufwand für Validierung und Wiederholung; hier entfällt er. Den Weg über erzwungenes JSON beschreibt unser Beitrag zu Structured Output mit vLLM und XGrammar – er bleibt die richtige Wahl, sobald Freitext in die Antwort gehört.

/03Die Modelle: Größe, Basis, Lizenz

Alle derzeit verfügbaren Entscheidungsmodelle sind auf Qwen-Basis feinjustiert. Die Tabelle fasst zusammen, was die Modellseiten bei Ollama und Hugging Face am 22. Oktober 2026 angaben. Die Download-Größe ist der Standard-Tag in der Ollama-Bibliothek, keine VRAM-Angabe; der tatsächliche Speicherbedarf hängt von Präzision und Eingabelänge ab.

Drei Beobachtungen aus der Tabelle. Erstens: Nimble ist auf Hugging Face als LoRA-Adapter auf Qwen3.5-9B veröffentlicht; die Ollama-Bibliothek liefert es als fertiges Modell. Zweitens: Bei Tev1 nennt die Ollama-Seite nur die MIT-Lizenz der Datensatz-Bauer und Trainingsskripte, nicht die der Gewichte – vor einem produktiven Einsatz klären. Drittens: d1-3B trägt auf Hugging Face die Lizenzkennung „other“; das ist kein Ausschluss, aber ein Lesauftrag für die Rechtsabteilung.

Zu den Leistungsangaben: Die Ollama-Seite zu pplx-decider nennt 85,7 % über 11 öffentliche Benchmarks in Perplexitys eigener Auswertung, gegenüber 84,5 % für Jev und 74,8 % für das Basismodell Qwen3.8-27B. Clef führt laut seiner Modellseite den „Decision Index“ an, Cloudflares eigene Rangliste. Beides sind Herstellerangaben über englischsprachige Datensätze. Für deutsche Tickets beweisen sie nichts – dazu mehr in Abschnitt /07.

/04Ollama: /v1/systemone und ollama run --ask

Ollama braucht für Nimble und Tev1 mindestens Version 0.35.0, für die Clef-Modelle 0.35.1, für --ask im Terminal 0.40.4. Lokale Anfragen brauchen keinen API-Schlüssel; der Server bindet laut FAQ standardmäßig an 127.0.0.1:11434. Der schnellste Test ist die Kommandozeile:

ollama --version            # mindestens 0.40.4 für --ask
ollama pull nimble

# Ja/Nein, Auswahl und Skala in einem Aufruf
ollama run nimble --ask "Wird eine Erstattung verlangt?" \
  --ask "Welches Team ist zuständig?" \
  --choice abrechnung="Zahlungen und Erstattungen" \
  --choice technik="Störungen und Fehler" \
  --ask "Wie dringend ist das?" \
  --level "Routine" --level "Bald" --level "Sofort" < ticket.txt

# vollständige API-Antwort statt Kurzform
ollama run nimble --ask "Wird eine Erstattung verlangt?" --format json < ticket.txt

Die Kurzausgabe hat laut Dokumentation dieses Format – eine Zeile je Frage, bei Skalen die wahrscheinlichste Stufe, ihre Wahrscheinlichkeit und der Wert auf der Skala:

Is a refund being requested? yes 97%
Which team should handle this? billing 91%
How urgent is this? Soon 64% 1.2 / 2

Für Anwendungen ist der HTTP-Aufruf der eigentliche Weg. Der Zustand darf ein String oder ein JSON-Objekt sein; Fragen tragen einen frei wählbaren Namen. Die Grenzen laut Dokumentation: 1 bis 64 Fragen je Anfrage, bei choice 2 bis 26 Optionen, bei score 2 bis 10 Stufen von niedrig nach hoch.

curl -s http://127.0.0.1:11434/v1/systemone -H 'Content-Type: application/json' -d '{
  "model": "nimble",
  "state": {"betreff": "Rechnung doppelt abgebucht", "text": "Bitte erstatten Sie den zweiten Betrag."},
  "questions": {
    "team": {"type": "choice", "instructions": "Welches Team ist zuständig?",
             "criteria": {"abrechnung": "Zahlungen und Erstattungen",
                          "technik": "Störungen und Fehler",
                          "sonstiges": "Alles andere"}},
    "erstattung": {"type": "noul", "instructions": "Verlangt der Kunde ausdrücklich eine Erstattung?"},
    "dringlichkeit": {"type": "score", "instructions": "Wie dringend ist das Ticket?",
                      "criteria": ["Routine", "Bald", "Sofort"]}
  }
}' | jq '.answers'

Wie die Antwort aussieht, zeigt das Beispiel im Ollama-Blog mit englischem Ticket „I was charged twice“: team = billing mit 0,985 und confidence 0,922; refund mit noul 0,997; urgency mit score 0,815 – aber confidence 0,046 bei den Stufenwahrscheinlichkeiten 0,378 / 0,429 / 0,193. Das ist das lehrreichste Detail des ganzen Blogeintrags: Der Skalenwert sieht nach einer Aussage aus, das Modell ist sich aber kaum sicher. Wer nur score ausliest, routet auf Rauschen.

Ein Betriebsdetail, das in keinem Datenschutzkonzept fehlen darf: Mit dem Suffix :cloud – etwa clef:cloud – geht der Zustand über den lokalen Server an ollama.com, sofern der Server angemeldet ist. Ein Tippfehler im Modellnamen genügt. Wer das ausschließen will, setzt OLLAMA_NO_CLOUD=1 (oder "disable_ollama_cloud": true in ~/.ollama/server.json); das Log bestätigt mit „Ollama cloud disabled: true“.

/05vLLM 0.32: der Endpunkt für jedes Generationsmodell

vLLM geht einen anderen Weg als Ollama. Der Endpunkt kam mit Pull Request #59299 (zusammengeführt am 8. Oktober) und ist seit #60677 ohne Schalter aktiv; #60696 ergänzte am 9. Oktober noul und score. Die vLLM-Dokumentation beschreibt ihn als anwendbar auf Textgenerierungsmodelle mit Chat-Template. Für gewöhnliche autoregressive Modelle liest vLLM die Wahrscheinlichkeit des nächsten Tokens über eigens gewählte Ein-Token-Labels aus („next_token“-Strategie). Ein normales Instruct-Modell, das Sie ohnehin betreiben, beantwortet also /v1/systemone – ohne eigenes Entscheidungsmodell.

Die Grenzen laut #59299: höchstens 64 Fragen je Anfrage, Optionen begrenzt auf die kleinere Zahl aus dem vom Tokenizer unterstützten Label-Satz und 128. Modelle oder Logprob-Modi ohne passende Lesestrategie starten trotzdem, antworten aber mit HTTP 501 – laut #60677 etwa bei --logprobs-mode raw_logits.

# vLLM 0.32.0 – Python 3.10 wird nicht mehr unterstützt
pip install "vllm==0.32.0"

# a) ein vorhandenes Instruct-Modell, nur intern erreichbar
vllm serve Qwen/Qwen3-0.6B --host 127.0.0.1 --port 8000

# b) ein eigenes Entscheidungsmodell (Apache 2.0, rund 64 GB GPU-Speicher in BF16)
vllm serve Cloudflare/clef-omni --host 127.0.0.1 --port 8000

curl -s 127.0.0.1:8000/v1/systemone -H 'Content-Type: application/json' -d '{
  "model": "Qwen/Qwen3-0.6B",
  "state": {"team": "billing", "language": "French"},
  "questions": {
    "team": {"type": "choice", "instructions": "Which team does the message name?",
             "criteria": {"billing": null, "shipping": null, "security": null}}
  },
  "seed": 7,
  "chat_template_kwargs": {"enable_thinking": false}
}'

Die Antwort aus dem Pull Request enthält gegenüber Ollama ein zusätzliches Feld, das für den Betrieb Gold wert ist:

"answers": {"team": {"type": "choice", "choice": "billing",
  "probabilities": {"billing": 0.955, "shipping": 0.008, "security": 0.037},
  "confidence": 0.955}},
"usage": {"input_tokens": 254, "output_tokens": 2},
"diagnostics": {"team": {"label_mass": 0.998, "argmax_is_label": true}}

label_mass sagt, welcher Anteil der Wahrscheinlichkeit überhaupt auf die erlaubten Labels fiel. Ein Wert deutlich unter 1 heißt: Das Modell wollte eigentlich etwas anderes sagen, und die Softmax über die Labels hat es gezwungen. In #60696 lag label_mass bei Qwen3-4B für Skalenfragen im Modus „mapped“ bei 0,84 – ein Generalist liefert also brauchbare, aber weichere Entscheidungen als ein dafür trainiertes Modell. Derselbe Pull Request zeigt auch, wie stark die Reihenfolge der Optionen wirkt: Qwen3-4B kam bei denselben Ja/Nein-Fragen auf 48 von 74 Treffern mit „no“ zuerst und auf 42 von 74 mit „yes“ zuerst.

Clef-Omni ist ein Mixture-of-Experts-Modell, das vLLM als Pooling-Modell mit eigenem Bewertungskopf betreibt; laut #61064 bearbeitet es eine Anfrage in einem Vorwärtsdurchlauf, auch mit Bildern, Audio und Video im Zustand. Für die Latenz gibt es einen Messpunkt aus #60676: d1-3B spielte Snake über den Endpunkt mit 23 ms Median je Anfrage auf einer B300. Das ist eine Demo auf Rechenzentrums-Hardware, kein Wert für Ihre Karte.

Zur Sicherheit: vLLM 0.32.0 schränkt laut Release Notes die standardmäßig erlaubten CORS-Ursprünge ein und schließt drei Advisories. Ein Entscheidungsendpunkt, der Ticket-Inhalte sieht, gehört trotzdem nicht ins offene Netz. Wie Sie Ollama- und vLLM-Endpunkte abschotten, steht in unserem Beitrag zu LLMjacking und Endpoint-Härtung.

/06Routing im Gateway: Schwellen statt Bauchgefühl

Der naheliegende Einsatz im Mittelstand ist das Vorschalten: Bevor eine Anfrage ein großes Modell erreicht, beantwortet ein Entscheidungsmodell zwei, drei Fragen – Datenklasse, Aufwand, Zuständigkeit – und das Gateway wählt danach Ziel und Weg. Das kostet einen Aufruf mit festem, kleinem Ausgabeumfang und spart große Modelle für die Anfragen, die sie brauchen. Ein kleines Entscheidungsmodell ist dabei die konsequente Fortsetzung dessen, was unser Beitrag zu Small Language Models beschreibt: kleine Modelle für eng umrissene Aufgaben.

Das folgende Skript ist ein lauffähiges Gerüst für diesen Vorschalt-Schritt. Es fragt Nimble über Ollama, liest Wahl, Konfidenz und Skalenwert aus und gibt ein Ziel aus. Die Schwellen 0,80 und 1,2 sind Startwerte, die wir als Ausgangspunkt setzen – keine belegten Werte. Kalibrieren Sie sie an einem eigenen Satz von Tickets mit bekannter Ground Truth.

#!/usr/bin/env bash
# route.sh – Vorschalt-Entscheidung für ein Gateway. Aufruf: ./route.sh anfrage.txt
set -euo pipefail
STATE=$(jq -Rs . < "$1")
ANTWORT=$(curl -s http://127.0.0.1:11434/v1/systemone -H 'Content-Type: application/json' -d "{
  \"model\": \"nimble\", \"state\": $STATE,
  \"questions\": {
    \"klasse\": {\"type\": \"choice\", \"instructions\": \"Welche Datenklasse hat der Text?\",
      \"criteria\": {\"intern\": \"Keine Personen- oder Kundendaten\",
                     \"vertraulich\": \"Kunden-, Vertrags- oder Personaldaten\"}},
    \"aufwand\": {\"type\": \"score\", \"instructions\": \"Wie anspruchsvoll ist die Aufgabe?\",
      \"criteria\": [\"Kurze Auskunft\", \"Zusammenfassung\", \"Mehrstufige Analyse\"]}}}")

KLASSE=$(jq -r '.answers.klasse.choice'      <<< "$ANTWORT")
K_KONF=$(jq -r '.answers.klasse.confidence'  <<< "$ANTWORT")
AUFWAND=$(jq -r '.answers.aufwand.score'     <<< "$ANTWORT")
A_KONF=$(jq -r '.answers.aufwand.confidence' <<< "$ANTWORT")

# Unsicher bei der Datenklasse? Dann wie "vertraulich" behandeln.
if awk "BEGIN{exit !($K_KONF < 0.80)}"; then KLASSE=vertraulich; fi
# Unsicher beim Aufwand? Dann das größere Modell.
if awk "BEGIN{exit !($A_KONF < 0.80 || $AUFWAND >= 1.2)}"; then GROSS=1; else GROSS=0; fi

case "$KLASSE/$GROSS" in
  vertraulich/1) echo "ziel=lokal-gross" ;;
  vertraulich/0) echo "ziel=lokal-klein" ;;
  intern/1)      echo "ziel=freigegebenes-grossmodell" ;;
  *)             echo "ziel=lokal-klein" ;;
esac
echo "klasse=$KLASSE konf=$K_KONF aufwand=$AUFWAND konf=$A_KONF" >&2

Die Logik dahinter in Tabellenform – das ist die eigentliche Entscheidung, das Skript setzt sie nur um:

Zwei Regeln stecken darin, die sich in der Praxis bewähren. Erstens fällt jede Unsicherheit zur sicheren Seite: Wer die Datenklasse nicht sicher kennt, behandelt sie als vertraulich. Zweitens entscheidet die Konfidenz, nicht nur der Wert – das Ollama-Beispiel mit 0,046 aus Abschnitt /04 ist genau der Fall, den die zweite Zeile abfängt. Die Ollama-Dokumentation sagt es selbst: Ein höherer Konfidenzwert bedeutet nicht, dass die Antwort richtig ist.

Derselbe Aufbau taugt als Freigabeprüfung vor Werkzeugaufruf eines Agenten: Clef nennt „Moderate a tool call“ ausdrücklich als Einsatz, mit dem geplanten Aufruf als Zustand und einer Ja/Nein-Frage nach Schaden. Als einzige Guardrails-Schicht reicht das nicht, als schnelle zusätzliche Prüfung schon.

/07Grenzen: wann ein Entscheidungsmodell die falsche Wahl ist

Ehrlich: Für die meisten Mittelständler ist ein Entscheidungsmodell heute ein Zusatz, kein Pflichtbaustein. Diese Fälle sprechen dagegen.

• Wenige Entscheidungen am Tag. Wer 50 Tickets täglich verteilt, gewinnt mit 91 ms statt einigen Sekunden nichts, was jemand bemerkt. Ein vorhandenes Chatmodell mit Structured Output oder eine Schlagwortregel genügt.
• Deutsche Texte ohne eigene Messung. Nimble ist auf Hugging Face nur mit der Sprachkennung „en“ versehen; die genannten Benchmarks sind englischsprachige Datensätze. Ob „Gutschrift“, „Storno“ und „Rückbuchung“ zuverlässig als Erstattungswunsch erkannt werden, zeigt nur eine Evaluation mit 100 bis 200 echten, anonymisierten Tickets Ihres Hauses.
• Offene Antworträume. Wer die Optionen nicht vorher aufzählen kann – „Welches Produkt meint der Kunde?“ bei 4.000 Artikeln –, ist mit 26 Optionen bei Ollama oder 128 bei vLLM am Ende. Dafür gibt es Retrieval, nicht Klassifikation.
• Begründungspflicht. Ein Entscheidungsmodell gibt Wahrscheinlichkeiten, keine Begründung. Wo ein Mensch die Entscheidung nachvollziehen muss – Ablehnung eines Antrags, Personalsachen –, ist eine Zahl allein keine Grundlage.
• Experimentelle Modelle. Tev1 heißt bei Ollama ausdrücklich „experimental“; die Lizenz der Gewichte ist auf der Modellseite nicht genannt. Für produktive Wege kommen derzeit nur Modelle mit klarer Lizenz in Frage.
• Nicht reproduzierbare Ergebnisse. Laut #60696 lieferte DiffusionGemma bei zwei Läufen unveränderter Anfragen 121 und 122 richtige Antworten. Wer Entscheidungen protokollieren und nachprüfen muss, fixiert Modellversion, Seed und Fragewortlaut und speichert Wahrscheinlichkeiten mit.

Hinzu kommt der Reifegrad. Der Endpunkt ist in vLLM drei Wochen alt; ein Pull Request für ein OpenAI-ähnliches Entscheidungsformat (#60465) wurde am 13. Oktober geschlossen, nicht zusammengeführt. Das Format kann sich noch bewegen. Bauen Sie deshalb eine dünne eigene Schicht zwischen Anwendung und Endpunkt – das Skript aus Abschnitt /06 ist genau so eine –, damit eine Formatänderung eine Datei betrifft und nicht zehn Anwendungen.

/08Entscheidung: welches Modell für welche Hardware

Die Wahl folgt der vorhandenen GPU, nicht umgekehrt. Ein Entscheidungsmodell soll neben dem eigentlichen Arbeitsmodell laufen, nicht ihm den VRAM wegnehmen.

• Eine 24-GB-Karte oder ein Arbeitsplatzrechner: nimble (9,3–9,5 GB Download) oder clef-flash (11–12 GB) über Ollama. Daneben passt kein großes Arbeitsmodell mehr – auf solcher Hardware ist das Entscheidungsmodell entweder der Hauptzweck oder es läuft auf einem zweiten Gerät.
• Ein GPU-Server mit 48 bis 96 GB: clef (18–20 GB) oder pplx-decider (17 GB) neben einem mittelgroßen Arbeitsmodell, oder – ohne eigenes Entscheidungsmodell – /v1/systemone direkt auf dem vLLM-Instruct-Modell, das ohnehin läuft. Das ist der günstigste Einstieg: kein zusätzlicher Speicher, nur ein weiterer Endpunkt.
• Ein System mit 192 GB VRAM wie das ki·spezial System im Vollausbau: clef-omni (rund 64 GB in BF16 laut Modellkarte) auf eigener Karte, wenn Bilder, Audio oder Video entschieden werden sollen; sonst reicht eines der kleineren Modelle.

Die Reihenfolge, die wir empfehlen: zuerst den Endpunkt auf dem vorhandenen Instruct-Modell testen, mit 100 bis 200 eigenen Fällen und label_mass im Blick. Erst wenn Trefferquote oder Latenz nicht reichen, ein dediziertes Entscheidungsmodell daneben stellen – und dann eines mit Apache-2.0-Lizenz. Das ist keine Formsache: Ein Router, der unbemerkt falsch entscheidet, schickt vertrauliche Anfragen dahin, wo sie nicht hingehören. Die Kalibrierung ist deshalb Teil des Model Serving, nicht ein Projekt danach.