Small Language Model 2026: LLM-Calls gezielt ersetzen

Robin, Consultant für GenAI bei Pexon Consulting | 8 Min. Lesezeit | 20.09.2026

TL;DR: Small Language Model kurz erklärt

Ein Small Language Model ist ein kleines, auf eine feste Aufgabe trainiertes Modell, meist ein Encoder wie ModernBERT. Es klassifiziert Text in 2 bis 5 Millisekunden statt in 200 bis 500, zu rund einem Dreißigstel der Kosten eines Frontier-Calls. Pexon Consulting setzt es dort ein, wo die Antwortmenge feststeht: Triage, Routing, Vorsortierung.

Das Problem: Sie bezahlen Sprachfähigkeit, die Sie nicht abrufen

Ein Posteingang mit 1.500 Mails am Tag braucht keine Sprachfähigkeit. Er braucht pro Mail vier Antworten: gehört zu welchem Team, wie dringend, ist das Spam, muss jemand antworten. Das sind vier Entscheidungen aus einer geschlossenen Menge.

Wer dafür ein Frontier-Modell ruft, kauft ein Werkzeug, das Gedichte schreiben, Code refaktorieren und über Kant diskutieren kann, und nutzt davon nichts. Bezahlt wird trotzdem das ganze Paket, und zwar pro Token und pro Millisekunde Wartezeit.

Im September 2026 ist diese Rechnung sichtbar geworden. TypeSafe AI hat am 15.09.2026 mit Jev ein Modell veröffentlicht, das gar keinen Text mehr erzeugt, sondern nur noch typisierte Entscheidungen mit Wahrscheinlichkeiten zurückgibt, zu 0,042 USD je Million Eingabe-Token bei kostenloser Ausgabe. Das ist kein Nischenprodukt, sondern das Eingeständnis einer ganzen Branche: Der Großteil der Calls in produktiven Agenten sind Klassifikationen, keine Gespräche. Unsere Messung im eigenen Test dazu steht im Kostenvergleich zu Jev TypeSafe.

Was ein Small Language Model vom LLM unterscheidet

Der Unterschied ist die Architektur, nicht die Größe. Ein LLM ist ein Decoder: Er erzeugt das nächste Token, dann das nächste, bis er fertig ist. Deshalb ist er langsam und deshalb kann er in seiner Ausgabe alles Mögliche produzieren, auch etwas, das Ihr Code nicht erwartet.

Ein Encoder liest den gesamten Text in einem Durchgang und gibt eine Verteilung über Ihre Labels zurück. Mehr kann er nicht, und genau das ist der Punkt: Ein Modell, das nur zwischen rechnung, bestellung, reklamation und sonstiges wählen darf, kann kein fünftes Label erfinden. Die Halluzination ist nicht wegtrainiert, sie ist strukturell ausgeschlossen.

ModernBERT ist der aktuelle Referenzpunkt dafür. Das Repository AnswerDotAI/ModernBERT stand am 20.09.2026 bei 1.728 Sternen, die verbreitete Trainings-Bibliothek huggingface/setfit bei 2.812. Beide Zahlen sind klein gegen das, was Agent-Frameworks sammeln, und das führt in die Irre: Encoder-Modelle sind das unspektakuläre Arbeitspferd, das seit Jahren in Produktion läuft, während die Aufmerksamkeit woanders liegt.

# Klassifikation mit einem lokal gehosteten Encoder, kein API-Call nach draußen
from transformers import pipeline

triage = pipeline(
    "text-classification",
    model="answerdotai/ModernBERT-base",   # eigener Fine-Tune, lokal geladen
    device="cuda",
)

# Vier Labels, mehr kann das Modell per Definition nicht zurueckgeben
ergebnis = triage("Rechnung 4711 wurde doppelt abgebucht, bitte um Rückmeldung")
# [{'label': 'reklamation', 'score': 0.94}]

Drei Fälle aus unseren Projekten, in denen wir den LLM-Call ersetzt haben

Wir haben den Tausch nicht als Prinzip gemacht, sondern jedes Mal, nachdem eine Rechnung aus dem Ruder lief. Drei Muster wiederholen sich.

Inbound-Triage vor dem Assistenten. Ein Kunde ließ jede eingehende Mail durch ein Frontier-Modell laufen, um zu entscheiden, ob der Assistent überhaupt antworten soll. Rund 70 Prozent der Mails waren Benachrichtigungen von Systemen, die nie eine Antwort brauchten. Ein kleiner Klassifikator davor hat diese 70 Prozent abgefangen, bevor teure Token entstehen. Das Frontier-Modell sieht seitdem nur noch die Mails, bei denen es wirklich formulieren muss.

Ticket-Routing im Service. Die Zuordnung zu einer von elf Queues war als Prompt mit elf Beschreibungen umgesetzt, gut 2.000 Token Systemprompt pro Ticket, jedes Mal neu bezahlt. Der Encoder braucht den Systemprompt nicht, die elf Klassen stecken in den Gewichten. Was bei uns den Ausschlag gab, war nicht der Preis, sondern die Varianz: Der Prompt-Router hat bei gleichlautenden Tickets an unterschiedlichen Tagen unterschiedlich zugeordnet, der Encoder nicht.

Vorsortierung vor der Dokumentenstrecke. Vor einer OCR- und Extraktionsstrecke sitzt eine simple Frage: Ist das überhaupt ein Beleg, und wenn ja, welcher Typ. Diese Frage mit einem Vision-Modell zu beantworten kostet das Vielfache der eigentlichen Extraktion. Wie die Strecke dahinter aussieht, steht in unserem Beitrag zur Dokumentklassifizierung mit KI.

Die Zahlen, mit denen im Netz für Entscheidungsmodelle geworben wird, stammen fast alle aus solchen Batch-Läufen: Tausende Mails in Sekunden für Centbeträge. Das stimmt auch. Es verschweigt nur, dass der Batch der einfache Teil ist.

Die Kostenrechnung, ehrlich gerechnet

Die verbreiteten Vergleiche stellen Token-Preis gegen Token-Preis. Das ist die Rechnung des Anbieters, nicht Ihre. Ihre Rechnung enthält eine GPU oder eine CPU-Instanz, die auch dann läuft, wenn nichts zu klassifizieren ist.

Unter 50.000 Entscheidungen im Monat lohnt sich das eigene Modell finanziell nicht. Wir sagen das Kunden auch dann, wenn sie den eigenen Stack schon beschlossen haben. Wer darunter liegt und trotzdem selbst hostet, kauft Datenhoheit, nicht Ersparnis, und sollte das so nennen.

Oberhalb davon kippt es schnell. Bei einer Million Entscheidungen im Monat zahlt die Instanz sich im ersten Monat ab, und ab da ist jede weitere Entscheidung faktisch gratis. Das ist der eigentliche Reiz kleiner Modelle: Die Kosten entkoppeln sich vom Volumen.

Selbst hosten oder fremde Decision-API

Hier trennen sich zwei Wege, und wir raten je nach Datenlage unterschiedlich.

Für Klassifikation über Daten, die ohnehin öffentlich sind oder keinen Personenbezug haben, ist eine fremde Decision-API der schnellere Weg. Kein Training, kein Betrieb, in einer Woche produktiv. Der Haken liegt beim Datenort: Die aktuellen Anbieter hosten in den USA, und ein Ticket-Text enthält fast immer einen Namen. Was das im Detail bedeutet, haben wir am Privacy-Check der Venice-API durchgespielt.

Für Posteingänge, Personalakten, Schadenmeldungen und alles, was unter eine Auftragsverarbeitung fällt, gehört das Modell in die eigene Umgebung. Der Fine-Tune eines Encoders braucht keine GPU-Farm, ein paar tausend gelabelte Beispiele und eine einzelne Karte reichen. Die Hürde ist nie die Rechenleistung, sondern die Labels.

# Klassifikator lokal serven, OpenAI-kompatibel, damit das Gateway nichts merkt
vllm serve ./modernbert-triage-v3 
  --task classify 
  --served-model-name triage 
  --port 8000

# Routing im Gateway: kleines Modell zuerst, großes nur bei Unsicherheit
curl -s localhost:8000/classify -d '{"text":"..."}' | jq '.score > 0.85'

Welches Inferenz-Backend dafür sinnvoll ist, haben wir im Vergleich von Ollama, vLLM und SGLang auseinandergenommen.

Wo wir vom Tausch abraten

Drei Fälle, in denen das kleine Modell der falsche Griff ist.

1. Die Label-Menge steht nicht fest. Wenn heute elf Klassen gelten und nächsten Monat vierzehn, brauchen Sie einen Retraining-Zyklus, den niemand betreiben will. Ein Prompt ändert man in fünf Minuten, ein Modell nicht.
2. Die Entscheidung braucht eine Begründung. Encoder liefern ein Label und eine Zahl, sonst nichts. Wo ein Mensch nachvollziehen muss, warum etwas abgelehnt wurde, fehlt genau das.
3. Es geht um Prognose, nicht um Einordnung. Klassifikatoren sind gut darin, Vorhandenes einzusortieren. Sie sind nicht gut darin, aus Marktdaten eine Kauf- oder Verkaufsentscheidung abzuleiten. Die Demo, an der Entscheidungsmodelle öffentlich am deutlichsten gescheitert sind, war genau diese.

Unsere Empfehlung: Bauen Sie den Tausch als Vorschaltung, nicht als Ersatz. Das kleine Modell entscheidet, das große übernimmt ab einer Konfidenzschwelle. Dann verlieren Sie nichts und sparen trotzdem den Großteil. Wie man diese Schwelle im Gateway verdrahtet, steht im Beitrag zu Kosten beim LLM-Model-Routing.

Häufig gestellte Fragen

Was kostet ein eigener Klassifikator im Betrieb?

Eine kleine GPU-Instanz für einen Encoder liegt bei 150 bis 600 EUR im Monat, abhängig von Anbieter und Redundanz. Dazu kommen einmalig drei bis acht Personentage für Datenaufbereitung und Fine-Tune. Ab rund 50.000 Entscheidungen im Monat ist das günstiger als jeder API-Call.

Small Language Model oder Decision-API wie Jev?

Kommt auf die Daten an. Enthalten Ihre Texte Personenbezug, gehört das Modell in die eigene Umgebung, weil die verfügbaren Decision-APIs in den USA hosten. Ohne Personenbezug ist die API der schnellere Weg, weil Training und Betrieb entfallen.

Wie viele Trainingsdaten brauche ich?

Für eine Handvoll gut getrennter Klassen reichen oft 500 bis 1.000 sauber gelabelte Beispiele pro Klasse. Bei feinen Unterschieden zwischen Klassen steigt der Bedarf deutlich. Der Aufwand liegt fast immer beim Labeln, nicht beim Training selbst.

Kann ein kleines Modell halluzinieren?

Es kann kein Label ausserhalb Ihrer Menge zurückgeben, das schließt die Architektur aus. Es kann aber falsch zuordnen, und zwar mit hoher Konfidenz. Der Schutz dagegen ist eine Schwelle plus Stichprobenprüfung, nicht das Vertrauen in die Architektur.

Läuft das auch ohne GPU?

Ja. ModernBERT-base klassifiziert auf modernen CPUs in zweistelligen Millisekunden. Das reicht für Posteingänge und Ticketströme. Eine GPU brauchen Sie erst, wenn Sie in Batches im sechsstelligen Bereich arbeiten oder unter zehn Millisekunden bleiben müssen.

Nächster Schritt

Verwandte Themen