Wie man das richtige LLM für die Aufgabe auswählt: Matrix Größe-Kosten-Latenz

Regelmäßig sehen wir dasselbe Muster: Ein Unternehmen bindet ein großes Cloud-Modell an jede Operation – vom einfachen Zusammenfügen einer Adresse bis zur Vertragsanalyse. Es funktioniert, solange die Rechnung klein bleibt. Dann steigt der Traffic, Latenzen häufen sich, und die Kosten skalieren linear mit der Anzahl der Anfragen. Das Problem liegt fast nie darin, dass das Modell „zu schwach“ ist. Es liegt darin, dass dasselbe Modell sowohl die Arbeit erledigt, für die ein zehnmal günstigeres Modell ausreichen würde, als auch die, die tatsächlich Leistung erfordert. Die Auswahl des richtigen Modells für die Aufgabe ist der günstigste Hebel in der Architektur – und wird am häufigsten übersehen.

Jede Modellauswahl ist eine Verhandlung zwischen drei Größen, die nicht gleichzeitig maximiert werden können:

• Größe (Qualität) – Ein größeres Modell kommt besser mit Mehrdeutigkeit, mehrstufigem Reasoning und langem Kontext zurecht. Aber „besser“ heißt nicht „notwendigerweise besser“ – bei einer Aufgabe mit einer einzigen richtigen Antwort ist überschüssige Leistung verschwendetes Budget.
• Latenz – Ein größeres Modell antwortet langsamer. Bei einem Live-Chat spürt der Nutzer jede Sekunde; bei der nächtlichen Batch-Verarbeitung ist die Latenz irrelevant. Wo die Aufgabe läuft, verändert die Priorität dieser Achse vollständig.
• Kosten der Inferenz – In der Cloud steigen sie mit der Anzahl der Eingabe- und Ausgabetokens sowie der Modellklasse; beim Self-Hosting ist es die Amortisation der Hardware, verteilt auf das Volumen. Ein kleines Modell macht oft den Unterschied zwischen einer akzeptablen und einer projektgefährdenden Rechnung.

Die Regel, die wir anwenden: Wir fragen nicht „welches Modell ist das beste“, sondern „was ist die niedrigste Qualitätsgrenze, bei der die Aufgabe noch korrekt funktioniert“ – und wählen das günstigste Modell oberhalb dieser Grenze.

Die meisten Geschäftsaufgaben lassen sich in einige Archetypen einordnen. Die folgende Matrix ist ein Ausgangspunkt, keine Dogma – die Schwellen hängen von euren Daten und der geforderten Genauigkeit ab. Die Kostenspannen sind relativ (kleines Modell = Basis 1×):

Praktische Beobachtung aus Implementierungen: Die ersten beiden Zeilen – Extraktion und Klassifizierung – machen oft 60–80% aller Aufrufe in einem typischen System aus. Wenn alles durch ein großes Modell läuft, finanziert der Großteil der Rechnung Arbeit, die diese Leistung nicht benötigt.

Ein kleines Modell wird oft als „Notlösung für Arme“ betrachtet. Das ist ein Missverständnis. Ein kleines Modell ist die richtige Wahl, wenn die Aufgabe ein eng definiertes Ziel und ein überprüfbares Ergebnis hat:

• Das Ergebnis hat eine überprüfbare Struktur. Wenn wir ein JSON mit bekanntem Schema erwarten, fängt structured output plus Validierung Fehler unabhängig von der Modellgröße ab. Kleines Modell + Validator + eine Korrektur liefert ein günstigeres Ergebnis, das oft genauso zuverlässig ist wie ein großes Modell ohne Validierung.
• Die Domäne ist eng. Die Klassifizierung von Tickets in 8 Kategorien erfordert kein Weltwissen – sie erfordert die Unterscheidung von 8 Mustern. Ein kleines Modell, mit einem Prompt optimiert, erledigt das hervorragend. Mehr im Artikel über Klassifizierung und Ticket-Routing.
• Die Aufgabe ist wiederholbar und batchweise. Die Verarbeitung von 50.000 Datensätzen mit einem kleinen statt einem großen Modell macht den Unterschied zwischen einer akzeptablen und einer projektgefährdenden Rechnung.

Wo kleine Modelle versagen: Aufgaben, die Schlussfolgerungen aus mehreren Prämissen gleichzeitig erfordern, Konsistenz über lange Dokumente hinweg oder den Umgang mit echter Mehrdeutigkeit. Hier zahlt sich Sparen am Modell durch Fehler aus, die jemand manuell korrigieren muss. Die Grenze wird durch Messung bestimmt, nicht durch Intuition – siehe Monitoring der Qualität eines AI-Agenten.

Das ist eine Frage der Wirtschaftlichkeit und der Daten, nicht der Ideologie. Beide Ansätze haben ihre Berechtigung – unter unterschiedlichen Bedingungen:

Bei geringem oder variablem Traffic gewinnt die Cloud – keine Einstiegskosten, man zahlt nur für das, was man nutzt. Bei konstant hohem Volumen oder sensiblen Daten beginnt Self-Hosting kostenseitig zu gewinnen und bietet die Sicherheit, dass Daten die Infrastruktur nicht verlassen. Der Break-even-Punkt hängt vom Volumen ab, daher berechnen wir ihn anhand der realen Auslastung, nicht der maximalen Hardware. Den Aspekt der personenbezogenen Daten vertiefen wir in Self-Hosted LLM und RODO, die Wahl der Vektordatenbank in Wie wählt man eine Vektordatenbank aus.

In der Praxis sind die meisten ausgereiften Implementierungen hybrid: Ein kleines lokales Modell für Extraktion und Klassifizierung (günstig, privat, schnell), ein Flagship-Modell in der Cloud nur für Aufgaben, die es wirklich erfordern. Über die Kombination mit einer Wissensdatenbank schreiben wir in Firmen-GPT auf Wissensbasis.

Statt das Modell starr zuzuweisen, leiten wir alle Aufrufe durch einen einzigen LLM-Router. Das ist ein einziger Eingang zur Modellschicht, der für jede Aufgabe entscheidet, wohin sie weitergeleitet wird – und bietet drei Dinge gleichzeitig:

1. Modellauswahl pro Aufgabe. Klassifizierung geht an ein kleines Modell, Vertragsanalyse an ein großes. Die Entscheidung ist deklarativ (Matrix Aufgabe→Modell), nicht im Code verstreut.
2. Fallback und Degradation. Wenn das Zielmodell nicht verfügbar oder überlastet ist, leitet der Router auf ein Ersatzmodell um, statt dem Nutzer einen Fehler zurückzugeben.
3. Telemetrie und Kostenkontrolle. Da alles durch einen Punkt läuft, messen wir Kosten und Latenz pro Aufgabe, sehen, wohin das Geld wirklich fließt, und können Budgets sowie Überlastungsgrenzen setzen.

Der Router ist auch der natürliche Ort für die Maskierung personenbezogener Daten vor der Cloud und für die Durchsetzung der Regel „structured output wird immer validiert“. Ohne diese Schicht bedeutet jede Modelländerung Code-Umstellungen an vielen Stellen; mit ihr ist es eine Änderung einer einzigen Regel. Deshalb ist der Router das Erste, was wir in jedem System mit mehreren Modellen einrichten – nicht ein Add-on am Ende.

Einfacher am Anfang, teurer im Scale. Ein großes Modell für jede Operation führt zu einer Rechnung, die linear mit dem Traffic wächst, und zu höheren Latenzen, wo sie nicht benötigt werden. Ein Router, der das Modell pro Aufgabe auswählt, ist meist die größte einzelne Einsparung, da er 60–80% der Aufrufe auf ein um eine Größenordnung günstigeres Modell verlagert.

Durch Messung, nicht durch Bauchgefühl. Wir sammeln einen Satz realer Beispiele der Aufgabe, lassen sie durch ein kleines und ein großes Modell laufen und vergleichen die Genauigkeit an einer Blindprobe. Wenn das kleine Modell die Qualitätsgrenze bei einer Aufgabe mit überprüfbarem Ergebnis (Extraktion, Klassifizierung) hält, reicht es aus – und der Unterschied in Kosten und Latenz spricht für es.

Nein. Bei geringem oder variablem Volumen ist die Cloud günstiger, da keine Einstiegskosten anfallen – die Hardware für Self-Hosting muss sich über den Traffic amortisieren. Self-Hosting gewinnt bei konstant hohem Volumen oder wenn Daten das Unternehmen nicht verlassen dürfen. Der Break-even-Punkt wird anhand des realen Volumens berechnet, nicht der maximalen Hardware.

Am einfachsten deklarativ: Eine Matrix Aufgabe→Modell weist jeden Aufgabentyp einer Modellklasse zu, und der Router liest den Typ aus den Aufrufmetadaten. Fortgeschrittenere Varianten bewerten die Schwierigkeit einer konkreten Anfrage und eskalieren nur schwierige Fälle an ein größeres Modell. Wir beginnen mit der deklarativen Variante – sie ist vorhersehbar und leicht zu auditieren.

Wenn Modelle an vielen Stellen fest verdrahtet sind – ja. Wenn alles durch einen Router läuft, ist ein Modellwechsel eine Änderung einer einzigen Regel, kein Refaktor. Deshalb bauen wir die Router-Schicht von Anfang an ein: Der Modellmarkt verändert sich schneller, als eure Architektur es sollte, und der Router isoliert das System von diesen Änderungen.