← Insights

Strategie 5 Min

Entscheidungsmodelle lokal betreiben: was eine Messung auf deutschen Daten zeigt

Seit Ollama 0.35 laufen Entscheidungsmodelle auf dem eigenen Rechner. Eine Messung auf 76 deutschen Anfragen: Das 4B-Modell tev1 lag vor dem 9B-Modell und dem bisherigen Sprachmodell. Wichtiger als die Größe waren Fragestellung, Schwelle und Fehlerrichtung.

Punktfeld mit einer roten Marke. Sie steht waagerecht auf dem 3. Oktober 2026 und senkrecht auf 8 Abschnitten.

Programmatisch erzeugtes Titelbild. Die Marke steht waagerecht auf dem Veröffentlichungsdatum im Jahr und senkrecht auf der Zahl der Abschnitte. Wie die Titelbilder entstehen

In meinem Cockpit entscheidet ein kleines Modell bei jeder Anfrage, wohin sie geht: Kann ein lokales Sprachmodell sie beantworten, oder braucht es Claude mit Zugriff auf Daten und Werkzeuge? Seit Ollama 0.35 läuft dafür ein Entscheidungsmodell auf dem eigenen Rechner, ohne US-Dienst. Ich habe die drei verfügbaren Modelle auf 76 echten deutschen Anfragen gemessen. Das 4B-Modell tev1 lag mit 96% vorn, vor dem 9B-Modell und vor dem lokalen Sprachmodell, das die Aufgabe bisher hatte. Wichtiger als die Rangfolge war etwas anderes: Wie die Frage gestellt ist, wo die Schwelle liegt und in welche Richtung die Fehler gehen, hat mehr verändert als die Modellgröße. Dieser Text zeigt die Zahlen und das Vorgehen, eine Produktempfehlung ist er nicht.

Worum es geht: Entscheidungen ohne Text

Ein Entscheidungsmodell schreibt keinen Text. Es beantwortet vorher festgelegte Fragen zu einer Eingabe mit Ja/Nein, einer Auswahl aus festen Optionen oder einer Note, jeweils mit Wahrscheinlichkeit. Das passt an jede Stelle in einem Ablauf, an der heute ein Sprachmodell nur gerufen wird, um eine Kategorie zurückzugeben.

Das erste Modell dieser Art war Jev von TypeSafe AI im September 2026. Für mich kam es nicht in Frage, weil es nur in den USA läuft und der Anbieter nicht nach dem EU-US Data Privacy Framework zertifiziert ist. Ollama bildet die Jev-Schnittstelle seit Version 0.35 lokal nach [1]. Dazu gibt es in der Ollama-Bibliothek drei offene Modelle: nimble mit 9 Milliarden Parametern von Bespoke Labs unter Apache 2.0 [3] sowie tev1 mit 4 und tev1:0.8b mit 0,8 Milliarden Parametern von Together AI unter MIT-Lizenz [2]. Eine Anfrage trägt bis zu 64 Fragen auf einmal [1].

Die Weiche in meinem Cockpit sieht so aus:

Anfrage -> feste Regeln -> Entscheidungsmodell -> lokales Sprachmodell (Wissensfrage) oder Claude (Auftrag)

Bis Ende September saß an dieser Stelle Laya, ein sehr kleines offenes Modell [4]. Ohne Nachtraining lag es nur knapp über dem, was man mit Raten erreicht. Es durfte deshalb nur sehr sichere Urteile abgeben, den Rest entschied das lokale Sprachmodell.

Was die Messung zeigt

Gemessen habe ich auf einem Mac mini M4 mit 16 GB. Das Testset besteht aus 76 Anfragen nach dem Vorbild echter Anfragen, jede von Hand der richtigen Stufe zugeordnet. 31 davon habe ich für diese Messung ergänzt, vor allem kurze Fragen, die nach Wissen klingen, aber aktuelle Daten brauchen, zum Beispiel „Ist Jev schnell?“.

ModellGrößeAnbieter-Benchmark [5]eigene Messung, 76 Fälle
tev14B, rund 4,5 GB73,3%96%
nimble9B, rund 9,5 GB75,7%93%
qwen3:4b-instruct (Sprachmodell, bisher)4B–89%
tev1:0.8b0,8B, rund 0,8 GB63,5%89%
Laya multilingual322 Mio. Parameter–64%

Auf dem Anbieter-Benchmark mit 13 öffentlichen Datensätzen liegt nimble knapp vor tev1, Jev selbst erreicht dort 76,0% [5]. Auf meinen Fällen war es umgekehrt. Der Unterschied sind zwei bis drei Anfragen, eine allgemeine Rangfolge lässt sich daraus nicht ableiten. Für die eigene Wahl reicht es.

Den Ausschlag gab am Ende der Speicher. tev1 belegte stabil 4,7 GB und passt neben das Sprachmodell für die Antworten. Mit nimble wuchs der Prozess bis auf 18 GB, der Rechner lagerte rund 10 GB zusätzlich aus und verdrängte alles andere, was darauf lief. Die Größenangabe in der Modellbibliothek sagt darüber wenig.

Die Frage zählt mehr als die Größe

Dieselbe Entscheidung lässt sich als Ja/Nein-Frage oder als Auswahl zwischen zwei Optionen stellen. Bei tev1 war die Ja/Nein-Frage mit einer kurzen Beschreibung beider Antworten am besten. Als Auswahlfrage mit vertauschter Reihenfolge der Optionen fiel die Trefferquote von 96 auf 84%. Laya dokumentiert diesen Positionseffekt in seinem Repository selbst [4].

Ein zweiter Befund kam aus dem Radar, das neue Meldungen den Seiten meines Wikis zuordnet. Die Frage, ob eine Meldung zu einer bestimmten Seite gehört, beantwortete tev1 mit Seitentitel und einem Satz Beschreibung deutlich besser als mit einer ausführlichen Aufzählung, welche Art von Änderung gemeint sein könnte. Mehr Erklärung hat das Ergebnis verschlechtert.

Zur Sprache: tev1 ist laut Modellkarte vorwiegend auf Englisch getestet [2]. Auf kurzen deutschen Anfragen und Meldungen hat es gehalten, bei der Frage nach dem KI-Bezug von 72 Meldungen aus Fachquellen waren 97% richtig. Für lange deutsche Dokumente habe ich keine Zahlen.

Schwellen setzt man selbst

Jede Antwort kommt mit Wahrscheinlichkeiten. Ollama weist ausdrücklich darauf hin, dass der mitgelieferte Sicherheitswert nur misst, wie eindeutig die Verteilung ist, und keine Trefferwahrscheinlichkeit darstellt [1]. Ob sich eine Schwelle daran festmachen lässt, zeigt erst die eigene Messung. Bei tev1 ging das: Alle Fehler lagen zwischen 0,51 und 0,64, alle richtig erkannten Wissensfragen bei 0,7 oder darüber.

Alle Fehler aller Modelle gingen in dieselbe Richtung. Ein Auftrag, der Daten braucht, wurde als einfache Wissensfrage eingestuft. Das ist die heikle Richtung, weil dann ein Sprachmodell ohne Zugriff auf aktuelle Informationen antwortet. Daraus folgt die Regel: „Auftrag“ ab 0,5 geht direkt an Claude, „Wissensfrage“ erst ab 0,7 an das lokale Modell, alles dazwischen an Claude. Mit dieser Kette lagen alle 76 Fälle richtig. Fällt das Entscheidungsmodell aus, entscheidet das Sprachmodell wie vorher.

Wo ein Fehler anders kostet, liegt die Schwelle woanders. Beim Zuordnen von Meldungen zu Wiki-Seiten wiegt eine verlorene Meldung schwerer als eine überflüssige. Dort steht die Schwelle bei 0,2: 93% der echten Treffer bleiben, 70% der Fehlzuordnungen fallen weg. Das ist dasselbe Prinzip wie bei Human in the Loop, nur mit gemessener statt geschätzter Grenze. Den unsicheren Teil bekommt der Mensch oder das stärkere Modell.

Zum Vergleich gehört immer die triviale Basis. Hätte der Router einfach jede Anfrage als Auftrag behandelt, wären im ersten, kleineren Testset schon 56% richtig gewesen. Laya kam dort ohne Nachtraining auf 71%.

Wo ich es bewusst nicht einsetze

Bei Freigabe- und Sicherheitsregeln: welche Werkzeuge ein Agent nutzen darf, welche Pfade gesperrt sind. Ein Entscheidungsmodell liest natürliche Sprache und lässt sich über den Eingabetext beeinflussen. Die Modellkarte von tev1 sagt selbst, es solle nicht die einzige Prüfung vor einer folgenreichen Entscheidung sein [2]. Solche Regeln bleiben fest programmiert.

Bei redaktioneller Auswahl: Für meinen täglichen KI-Brief bewertet tev1 jeden Feed-Eintrag nach Thema und Bedeutung für kleine Unternehmen. In neun Läufen mit 134 Einträgen hatte Claude 22 ausgewählt. Keiner davon lag in dem Drittel, das tev1 nach hinten sortiert hätte. Eine hohe Note hatten aber nur 8 der 22. Zum Vorsortieren reicht das, zum Auswählen nicht.

Bei Entscheidungen über Personen: Ein Wahrscheinlichkeitswert über einen Menschen kann nach der Rechtsprechung des EuGH selbst die Entscheidung im Sinne von Art. 22 DSGVO sein. Der lokale Betrieb löst die Frage, wo die Daten verarbeitet werden. Diese Frage löst er nicht.

So gehst du vor

  1. Such dir eine Weiche: eine Stelle, an der heute ein Sprachmodell, eine Stichwortliste oder ein Mensch nur eine Kategorie, ein Ja/Nein oder eine Note liefert.
  2. Sammle 70 bis 130 echte Fälle, stufe sie von Hand ein und nimm die schwierigen bewusst auf. Notier, wie viele richtig wären, wenn man immer dieselbe Antwort gibt.
  3. Miss zwei bis vier Fragestellungen mit zwei Modellgrößen: Trefferquote, Richtung der Fehler, Antwortzeit und Speicher unter echter Last.
  4. Lies die Schwellen an der Verteilung der Wahrscheinlichkeiten ab und verschieb sie nach den Kosten des Fehlers. Das Mittelband geht an die sichere Seite.
  5. Bau das Modell so ein, dass ohne es das alte Verhalten gilt. Sicherheitsregeln fasst du nicht an.
  6. Nimm jede neue Fehlentscheidung als Testfall auf und miss bei jedem Modellwechsel neu.

Für die ersten beiden Schritte braucht es kein Budget, nur einen Nachmittag mit echten Fällen.

Wo es weitergeht

Der Benchmark hätte mir das größere Modell empfohlen. Die Messung auf meinen eigenen Fällen hat ein kleineres ergeben, das genauer war, schneller antwortete und auf den vorhandenen Rechner passte. Wer heute ein Sprachmodell nur um ein Ja oder Nein bittet, hat einen Kandidaten für ein Entscheidungsmodell. Ob es trägt, zeigt kein Datenblatt. Was ein Entscheidungsmodell von einem Sprachmodell und einem klassischen Klassifikator unterscheidet, steht in der Begriffsseite Entscheidungsmodell. Wann ein fester Ablauf die bessere Wahl ist als ein frei entscheidender Agent, steht unter KI-Automatisierung und Agenten.

Quellen

[1] Ollama: System One API, docs.ollama.com/api/systemone (abgerufen am 03.10.2026)

[2] Ollama-Bibliothek: tev1, ollama.com/library/tev1 (abgerufen am 03.10.2026)

[3] Ollama-Bibliothek: nimble, ollama.com/library/nimble (abgerufen am 03.10.2026)

[4] Laya, Repository auf GitHub, github.com/NandhaKishorM/laya (abgerufen am 03.10.2026)

[5] Oliver Posselt: Ollama unterstützt jetzt Entscheidungsmodelle, Caschys Blog, 03.10.2026, stadt-bremerhaven.de/ollama-unterstuetzt-jetzt-entscheidungsmodelle/

Alle übrigen Zahlen stammen aus meiner eigenen Messung vom 25.09. und 03.10.2026. Die Testsets sind klein (45 bis 134 Fälle je Frage, ein Rechner); die Muster sind belastbarer als die einzelnen Prozentwerte.