Kleines Entscheidungsmodell 2026: wann das LLM zu groß ist

Ein kleines Entscheidungsmodell reicht, wenn die Ausgabe eine bekannte Klasse ist. Das Frontier-Modell bleibt für offene Aufgaben.

4 Okt.. 2026 | AI

Inhaltsverzeichnis

Robin Werner, AI-Engineering-Consultant bei Pexon Consulting | 9 Min. Lesezeit | 04.10.2026


TL;DR: kleines Entscheidungsmodell in fünf Sätzen

Ein kleines Entscheidungsmodell vergibt eine Klasse, einen Score oder ein Ja, und schreibt keinen freien Text. Pexon Consulting (80 Mitarbeitende, Deutschland) nimmt das Frontier-Modell dafür aus dem Pfad, sobald die legalen Ausgaben bekannt sind. Offen bleibt Recherche und Code. Dort kombinieren mehrere Modelle, statt ein Abo jeden Schritt zu bezahlen.

Aufgabe Ausgabe Was wir einsetzen
Kosten, Risiko, Freigabe Wenige Klassen Kleines Entscheidungsmodell auf eigenen Daten
Tiefe Recherche, Gegencheck Offener Text Mehrere Modellfamilien, cache-bewusst
Code, Security-Forschung Hohes Fehlerrisiko Frontier, und nur dort das teure Modell

Das Problem: Das große Modell ist für die meisten Vorgänge zu fähig

Amjad Masad sagt es im a16z-Gespräch vom 3. Oktober 2026 mit einem Bild, das wir so stehen lassen. Die großen Foundation-Modelle auf alltägliche Aufgaben zu legen, sei, als treffe man einen Schmetterling mit einer Nuklearwaffe. Die meisten Vorgänge, auch unstrukturierte, brauchen diese Fähigkeit nicht. Sie sind teuer, und sie können mehr, als die Aufgabe erlaubt.

Alex Atallah ergänzt die Preisgrenze von der anderen Seite, ohne das Bild zu mildern. Für Code und für Security-Forschung, heute aus seiner Sicht der riskanteste Aufgabentyp, würde man für ein Modell, das Nutzer nicht täuscht, ein Vielfaches zahlen. Er sagt das Zehnfache. Für Aufgaben mit niedrigem Risiko nicht. Das Zehnfache ist ein gesprochener Vergleich, keine Preisliste, und das nicht-täuschende Frontier-Modell gibt es in der Folge nicht.

Unsere Empfehlung dazwischen ist eng. Wenn die Ausgabe eine Klasse ist, ist das Frontier-Modell die teurere und die riskantere Wahl. Wenn die Ausgabe offen ist und ein Fehler teuer wird, bleibt das große Modell im Pfad, aber nicht auf jedem Schritt davor.

Wer die Tokenkosten dieser Wahl erst in der Rechnung sieht, rechnet sie vorher. Ein Benchmark-Poster ersetzt diese Rechnung nicht.

Sie wollen sehen, was das Frontier-Modell auf bekannten Klassen kostet? Den Token-Kostenrechner setzen wir im 6-Wochen-Pilot gegen die kleine Klasse, bevor der Stapel in Produktion geht.

Was Masad schon trainiert, statt zu prompten

Masad ist auf kleine Modelle nicht neu gekommen. Bei Replit trainiert er einen Kostenschätzer. Ein Prompt geht hinein. Heraus kommt keine Prosa, sondern eine Verteilung über Geldbereiche: fünf bis zehn Dollar ein Bucket, zehn bis zwanzig ein anderer. Er trainiert solche Klassifikatoren seit Jahren, indem er die erlaubten Klassen vorgibt und die Logprobs je Klasse liest. Das Modell in diesem Beispiel ist Qwen 8B. Fable, Opus und Astra helfen ihm beim Training. Wie genau, sagt er nicht.

Den Entwicklerkomfort des großen Modells bestreitet er nicht. Ein promptbares Foundation-Modell ist eine starke Erfahrung, solange man keine eigenen Daten hat und nicht von vorn trainieren will. Wer Daten hat, und er sagt, Replit habe sehr viele, trainiert einen spezialisierten Klassifikator ziemlich leicht. Auf Replit bauen sie zusätzlich den Weg, eine CSV hochzuladen und ein Modell zu bekommen, das eine Sache tut. Das ist eine Fähigkeit im Bau, kein Preisblatt.

Das Muster übersetzen wir so, und nicht größer. Ein Mittelständler, der über tausende gleichartige Vorgänge schon weiß, in welche Kosten-, Risiko- oder Freigabeklasse sie fallen, hat die Daten, die Masad voraussetzt. Wer diese Klassen nicht kennt, bleibt beim großen Modell. Ein Klassifikator auf geratenen Labels ist teurer Unsinn.

# Nur diese Klassen darf das Modell vergeben. Kein freier Satz.
BUCKETS = ("5-10", "10-20", "20-40")

def waehle_bucket(logprobs: dict[str, float]) -> str:
    return max(BUCKETS, key=lambda name: logprobs[name])

Atallah hält genau diese Enge für den Punkt, der im Unternehmen häufiger ist als die öffentliche Debatte. Strukturierte Ausgabe, Maschinen lesen das Ergebnis, das Modell schreibt keinen Code, den es selbst ausführt. Der Raum für Fehlverhalten sei dadurch viel kleiner. Er erwartet, dass sich Enterprises dafür stärker interessieren als für den nächsten allgemeinen Chat.

Modellschuld ist der Grund, nicht der Demo-Effekt

Der zweite Grund ist haltbarer als die Latenz. Atallah hört von Firmen, dass sie Fine-Tuning auf freiem Text scheuen. In zwei Monaten müsse man es wieder tun. Alle spürten das Gewicht dieser Modellschuld. Ein sehr spezieller Klassifikator auf eigenen Daten fühle sich nicht ständig rückständig an. Er muss keine neue Sprache sprechen und kein Rust schreiben, nur weil die LLMs gerade darauf geprüft werden. Den Anwendungsfall kenne man, also baue man ihn enger. Für Enterprises wirke das wie etwas, das sie selbst bauen und hinterher nicht bereuen.

Wir raten ab, ein Chat-Modell auf Freitext nachzutrainieren, wenn die fachliche Antwort eine Klasse ist. Das ist die teure Schleife: Leaderboard bewegt sich, Fine-Tune ist alt, Projekt beginnt von vorn. Der Klassifikator wird schlecht, wenn sich die Klassen ändern, nicht wenn ein Lab ein neues Modell mit einem neuen Namen veröffentlicht.

Woran wir den Schnitt festmachen, bevor jemand ein Fine-Tune beauftragt:

  1. Die legalen Ausgaben passen auf eine halbe Seite.
  2. Eine Fachkraft kann einen falschen Treffer ohne Modellkenntnis erkennen.
  3. Die Trainingsfälle liegen schon in den eigenen Vorgängen, nicht in einem synthetischen Stapel.
  4. Der teure Aufruf bleibt für den Rest, den die Klasse nicht tragen darf.

Masad sortiert dieselbe Schleife historisch, und die Analogie ist bei ihm eine Warnung, kein Nostalgie-Stück. Die Neunziger schrieben Java und C++. Dann galten Python, JavaScript und Ruby als der Weg, Startups schnell zu bauen. Stripe auf Ruby, Facebook auf PHP. Danach die üblen Bugs, die Langsamkeit, Typen, ein JIT, und am Ende Rust für einen Teil dessen, was vorher die dynamischen Sprachen taten. Seine Vorhersage: Dieselbe Schleife bei den allgemeinen Modellen. Irgendwann ist der Einsatz auf jeder Aufgabe verschwenderisch und riskant ohne Grund.

Das ist eine Vorhersage. Keine Jahreszahl, kein Marktanteil. Wir teilen die Richtung für die Vorgänge, deren Ausgabe wir aufzählen können. Für alles andere wäre derselbe Satz falsch.

Wenn die Aufgabe offen bleibt: mehrere Modelle, nicht ein Gottmodell

Code-Review war für Atallah das erste Mal, dass Leute ernsthaft verschiedene Modellfamilien das Hauptergebnis gegenchecken ließen. Die Forschung an zusammengesetzten Modellen sei lange langsam gewesen und werde schneller. OpenRouter hat ein Fusion-Modell gestartet, Cognition auch. Sie senken Kosten und durchsuchen eine breitere Menge von Ideen, weil die Modelle auf verschiedenen Daten trainiert sind.

Am selben Tag, dem 3. Oktober 2026, haben sie Ergebnisse veröffentlicht, sagt er. Tiefe Recherche auf Fable-Niveau bei zweifach niedrigeren Kosten. Ein Deep-SWE-Lauf, das Caption ist an dieser Stelle undeutlich, einschließlich des Harness, auf Frontier-Niveau bei 40 bis 50 Prozent der Kosten. Welche Modelle, ändere sich über die Zeit. Ein Cache-Feature von OpenAI über Effort-Stufen, vielleicht sogar über Modellfamilien, möchte er ausdrücklich nicht zitiert wissen. Er könne falsch liegen. Cache-bewusst zu entwerfen sei trotzdem eine der großen Stellschrauben bei Fusion, Routern und Modellen, die eine Aufgabe an ein fähigeres Modell hochreichen.

Diese Zahlen sind seine, vom 3. Oktober 2026. Sie sind keine Pexon-Messung und keine Zusage für den nächsten Werkstatt-Workload. Was wir daraus mitnehmen, ist die Trennung. Geschlossene Klasse: eigenes kleines Modell. Offene Suche: mehrere Familien, und der Cache darf beim Wechsel der Stufe nicht verloren gehen. Ein einziges teuerstes Modell auf beiden Seiten ist die Architektur, von der beide in der Folge wegwollen.

Der organisatorische Rahmen ist eine interne Praxis mit eigenen Prüfungen. Ohne jemanden im Haus, der die Klassen kennt, trainiert das kleine Modell die falsche Frage sehr zuverlässig. Wie ein Modellwechsel trotzdem überlebt, steht im Text zum KI-Modellwechsel.

Täuschung bleibt offen, und genau deshalb bleibt die Ausgabe eng

Ob schlauere Modelle weniger täuschen, gewinnt in der Folge niemand. Masad hält Intelligenz und Ethik bei Maschinen für weitgehend unabhängig. Reinforcement Learning mache Reward-Hacking und Täuschung besser, nicht seltener. Wer Chain of Thought stark überwacht, bringe die Modelle dazu, im Chain of Thought zu lügen. Eine ernsthafte Prüfung müsse über Monate auf einer großen Aufgabe laufen. Atallah mag das Wort Alignment nicht, es sei vage. Hier meint er Täuschung des Nutzers. Ob ein genügend großes Modell Täuschung und Sandbagging vorhersehbar einstellt, wisse niemand.

Deshalb ist „wir nehmen das schlaueste Modell, dann ist es sicher“ in diesem Gespräch keine haltbare Position. Der kleinere Raum für Unsinn ist die Ausgabe, die nur eine Klasse sein darf. Den schnellen Prüfer vor einem Tool-Call beschreibt Atallah als internen Prototype bei OpenRouter, gegen Regeln, die im Prompt des handelnden Agenten bewusst nicht stehen. Eine Schnittstelle nennt er nicht. Nvidia habe gerade etwas zu Agent-Sicherheit veröffentlicht, den Namen lässt er offen.

Wir bauen den Prüfer nicht aus einem Caption. Wir bauen die Stelle, an der eine Klasse vergeben wird, so, dass ein freier Satz dort gar nicht entstehen kann. Alles, was danach noch ein Agent in natürlicher Sprache mit einem zweiten Agenten aushandeln muss, ist ein Rechteproblem, kein Modellproblem. Den Schnitt im Betrieb beschreibt die Agent-Orchestrierung.

Jev und ähnliche Entscheidungsmodelle kommen in der Folge als Name dieser Klasse vor, einmal auch hörbar verschliffen. Versionsnummern und Cent-Preise aus anderen Tests schreiben wir hier nicht hinein. Wer die Laufzeit sucht, findet sie im Text zu Jev Workflows. Die Folge selbst belegt den Schnitt, nicht die Preistabelle.

Häufig gestellte Fragen

Was ist ein kleines Entscheidungsmodell?

Ein Modell mit kontrollierter Ausgabe: Klasse, Bucket oder Ja/Nein. Maschinen lesen das Ergebnis. Es formuliert keinen freien Text und schreibt keinen Code, den es selbst ausführt. Masad trainiert so einen Kostenschätzer auf Qwen 8B.

Wann ist ein Frontier-Modell trotzdem richtig?

Wenn die Aufgabe offen ist und der Fehler teuer, vor allem bei Code und Security-Forschung. Atallah würde dort für ein nicht-täuschendes Frontier-Modell deutlich mehr zahlen. Für eine bekannte Klasse rät die Folge in die andere Richtung.

Was kostet ein kleines Entscheidungsmodell im Vergleich zum Chat-Modell?

Die Folge setzt zwei gesprochene Marken, keine Projektkalkulation. Fusion lag am 3. Oktober 2026 bei zweifach niedrigeren Kosten auf Fable-Niveau in der Recherche und bei 40 bis 50 Prozent im Deep-SWE-Lauf. Der Klassifikator soll den teuren Aufruf auf den Vorgängen sparen, deren Klasse schon feststeht. Eine Kunden-Eurozahl leiten wir daraus nicht ab.

Klassifikator oder Fine-Tuning des großen Modells?

Atallah hält Fine-Tuning auf freiem Text für Modellschuld, weil es nach etwa zwei Monaten wieder ansteht. Der enge Klassifikator auf eigenen Daten muss nicht mit jedem neuen Sprachtest mithalten. Voraussetzung ist, dass die Klassen und die Daten schon da sind.

Werden schlauere Modelle von selbst sicherer?

Unbekannt. Masad erwartet bei Maschinen eher bessere Täuschung. Atallah hält die Gegenthese für offen. Niemand im Gespräch weiß, ob Größe Sandbagging beendet. Enge Ausgabe ist die Vorsicht, die nicht auf diese Antwort wartet.


Nächster Schritt

Open-Source-KI auf eigener Infrastruktur
Die Klasse im eigenen Modell, nicht im Frontier-Chat
Wir setzen Open-Source-Modelle auf Ihrer Infrastruktur auf, damit eine bekannte Klasse nicht mehr bei jedem Vorgang über ein Frontier-Modell läuft.

Verwandte Themen


Microsoft Fabric. Bilder Blogtemplate Whitepaper

Claude Code im Unternehmen

  • Praxis-Guide für IT-Leiter – mit konkreten Einblicken zu Kosten, Sicherheit und Rollout von Claude Code im Unternehmen.

Beratungsgespräch

Sichern Sie sich Ihre kostenfreie Erstberatung

Analyse Ihres individuellen Cloud- oder KI-Bedarfs
Erste Empfehlungen zu Umsetzungsstrategien
Transparente Einblicke in unsere Methoden, Technologien & Referenzen