LLM-Routing und Cascading: günstiges Modell für Einfaches, starkes für Komplexes

Eines der ersten Dinge, die man nach der Inbetriebnahme eines LLM in der Produktion bemerkt, ist die Streuung der Anforderungen. Manche Anfragen sind trivial — eine Zahl aus einem Text extrahieren, eine Adresse umformatieren, ein Format validieren. Andere sind genuín komplex — mehrstufiges Schlussfolgern, Synthese aus mehreren Dokumenten, juristische Analyse. Das Problem: Die meisten Systeme schicken all diese Anfragen an dasselbe Modell. Man zahlt für ein Frontier-Modell, auch wenn es eine Frage beantwortet, die ein Modell zum Bruchteil des Preises problemlos bewältigen würde.

LLM-Routing löst genau das. Die Idee ist einfach: Schätzen Sie vor jedem LLM-Aufruf den Schwierigkeitsgrad der Aufgabe ab und schicken Sie sie an das günstigste Modell, das sie zuverlässig meistert. Rufen Sie das starke Modell nur dann auf, wenn die Situation es wirklich erfordert. In der Praxis bedeutet das, dass 75–90 % der Aufrufe auf das günstigere Modell entfallen und die Gesamtkosten sinken — ohne spürbare Qualitätseinbußen für den Großteil der Anwendungsfälle.

Was Routing ist und was Cascading

Routing (Weiterleitung) ist eine Entscheidung vor dem ersten Aufruf: Wählen Sie auf Basis des Inputs das Modell. Ein Klassifikator bewertet die Anfrage und leitet sie entweder an ein kleines Modell oder direkt an ein starkes weiter.

Cascading (Kaskade) fügt einen zusätzlichen Schritt hinzu: Die Anfrage geht zunächst an das günstige Modell, und dessen Antwort wird bewertet — ist sie hinreichend sicher (Konfidenz-Score, Konsistenz, Format), wird sie dem Nutzer zurückgegeben. Wenn nicht, erfolgt automatisch eine Eskalation an ein stärkeres Modell, und man zahlt dafür nur in diesem Fall. Beide Ansätze lassen sich kombinieren: Der Router entscheidet über das Eingangsmodell, die Kaskade entscheidet über die Eskalation.

Der entscheidende Unterschied: Routing ist proaktiv (Klassifikation vor dem Aufruf), Cascading ist reaktiv (Eskalation nach dem Aufruf, wenn der Output nicht ausreicht).

Warum es funktioniert — Schwierigkeitsverteilung in der Praxis

In realen Produktionssystemen, die wir analysiert haben, gilt in etwa folgende Verteilung:

• 30–40 % der Anfragen sind Routineaufgaben — Extraktion, Klassifikation, Umformatierung, einfache Suche. Ein kleines Modell bewältigt sie, zum Beispiel aus der Phi- oder Gemma-Familie oder dem günstigen Tier von Frontier-Anbietern.
• 40–50 % der Anfragen haben mittlere Komplexität — Zusammenfassung längerer Texte, einfaches Schlussfolgern, FAQ-Antworten mit Kontext. Hier reicht ein mittleres Modell.
• 10–20 % der Anfragen sind wirklich schwer — komplexe Analysen, Multi-Hop-Reasoning, Code-Generierung mit ungewöhnlichen Anforderungen, heikle Entscheidungen. Diese verdienen ein Frontier-Modell.

Wer alles an ein Frontier-Modell schickt, zahlt dessen Preis für jede Anfrage — einschließlich der 30–40 % Routineaufgaben. Frontier-Modelle (z. B. der Klasse Claude Opus, GPT-5.x) kosten rund ~$15–25 pro Million Output-Tokens, während der günstige Tier (Flash/Haiku-Äquivalente) unter $1–2 liegt. Der Unterschied beträgt das 15- bis 25-Fache. Selbst bei bescheidenem Routing, bei dem das kleine Modell nur die Hälfte der Anfragen bewältigt, können die Kosten um 40–60 % sinken.

Das akademische Projekt RouteLLM (LMSYS / UC Berkeley) zeigte, dass ein gut trainierter Router den Großteil einfacher Anfragen an das günstige Modell schicken und dabei den Großteil der Qualität des starken Modells erhalten kann — in ihren Messungen bedeutete das eine Kostenersparnis von rund 85 % bei Beibehaltung eines wesentlichen Teils der Leistung des starken Modells. Die genauen Zahlen hängen von der Zusammensetzung der Anfragen und der Kalibrierung des Routers ab.

Wie der Schwierigkeitsklassifikator funktioniert

Das Herzstück des Routers ist ein Klassifikator, der auf Basis des Inputs entscheidet, wohin er weitergeleitet wird. Es gibt mehrere Ansätze mit unterschiedlichen Trade-offs:

1. Einfacher heuristischer Router

Eingabelänge, Schlüsselwörter, Aufgabentyp (Extraktion vs. Generierung vs. Analyse). Funktioniert überraschend gut für Systeme mit engem Anwendungsfall und klar getrennten Anfragetypen. Null Overhead, deterministisches Verhalten. Nachteil: spröde, erfordert manuelle Regeln, passt sich nicht an Randfälle an.

2. Embedding-basierter Router

Die Anfrage wird eingebettet (z. B. mit einem kleinen BGE-Modell) und mit repräsentativen Beispielen aus jedem Tier verglichen. Ist die Anfrage nah an der Stichprobe leichter Aufgaben, geht sie an das günstige Modell. Das Embedding-Modell läuft lokal, der Overhead ist minimal (~5–15 ms). Vorteil: erfordert kein Training eines Klassifikators, leicht durch neue Beispiele erweiterbar.

3. Trainierter binärer Klassifikator

Ein kleines Modell (logistische Regression oder kleiner Transformer), trainiert auf die Vorhersage, ob eine Anfrage ein starkes Modell erfordert. RouteLLM bietet genau diesen Ansatz mit vortrainierten Klassifikatoren. Vorteil: hohe Präzision nach Kalibrierung auf eigenen Daten. Nachteil: erfordert einen annotierten Trainingsdatensatz und laufende Aktualisierungen.

4. LLM-as-a-Judge-Router

Ein günstiges Modell bewertet selbst, ob die Anfrage schwierig ist. Paradox, aber in der Praxis funktional — das günstige Modell kann „das ist eine einfache Extraktion" von „das ist eine komplexe Analyse" unterscheiden, auch wenn es die komplexe Analyse selbst nicht gut bewältigt. Overhead: ein kurzer zusätzlicher LLM-Aufruf. Geeignet für Systeme mit Kaskade.

Für die meisten Produktionssysteme empfehlen wir, mit einem embedding-basierten oder einfachen heuristischen Router zu beginnen. Den trainierten Klassifikator fügen Sie hinzu, wenn Sie ausreichend Betriebslogs für das Training haben (in der Größenordnung von Tausenden annotierter Beispiele).

Praktisches Kaskaden-Muster

Cascading sieht in der Praxis so aus:

1. 1.Eine Anfrage kommt ins System.
2. 2.Das kleine Modell generiert eine Antwort und gleichzeitig einen Konfidenz-Score.
3. 3.Überschreitet der Score den Schwellenwert (z. B. 0,85), wird die Antwort dem Nutzer zurückgegeben.
4. 4.Wenn nicht, wird dieselbe Anfrage an das mittlere oder starke Modell geschickt und das Ergebnis des mittleren/starken Modells zurückgegeben.

Den Konfidenz-Score können Sie auf mehrere Arten ableiten:

• Log-Wahrscheinlichkeit der Tokens — die durchschnittliche Log-Wahrscheinlichkeit der generierten Tokens. Ein niedriger Wert deutet darauf hin, dass das Modell „getastet hat". Verfügbar in Serving-Frameworks wie vLLM oder SGLang über den Parameter logprobs.
• Konsistenz beim Sampling — generieren Sie 3–5 verschiedene Antworten (höhere Temperatur) und messen Sie die Übereinstimmung. Widerspricht sich das Modell, eskalieren Sie.
• Verifikations-Prompt — ein sekundärer Aufruf (mit dem günstigen Modell): „Ist diese Antwort richtig und vollständig? Antworte nur mit Ja/Nein."

Der Eskalationsschwellenwert ist ein kritischer Parameter, den es für den konkreten Anwendungsfall zu kalibrieren gilt. Zu hoch: viele unnötige Eskalationen, die Einsparung geht verloren. Zu niedrig: das kleine Modell antwortet auf Dinge, die es nicht bewältigt, die Qualität sinkt.

Für Systeme mit klar definierter Aufgabe (z. B. Klassifikation von Dokumenten in Kategorien, Extraktion strukturierter Daten) ist die Kaskade besonders effektiv — das kleine Modell bewältigt 80–90 % der Fälle, das starke bekommt nur die wirklich mehrdeutigen. Für generative Anwendungsfälle (Freitext, kreatives Schreiben, komplexe Antworten auf offene Fragen) ist die Kaskade schwerer einzustellen, da die „Richtigkeit" einer Antwort automatisch schwer zu bewerten ist.

Kosten des Routings — nicht umsonst

Routing ist nicht kostenlos, und es ist wichtig, seine eigenen Kosten einzurechnen:

• Zusätzliche Latenz — jeder Klassifikationsaufruf kostet Zeit. Embedding-basierter Router: ~5–15 ms. LLM-as-a-Judge: 50–200 ms. Bei interaktiven Echtzeit-Anwendungen kann das spürbar sein.
• Kaskade bei Fehlklassifikation — beantwortet das kleine Modell eine schwierige Anfrage und die Antwort ist schlecht, zahlen Sie für zwei Aufrufe (klein + stark) statt einen. Fehlerhafte Klassifikation senkt also nicht die Kosten, sondern erhöht sie.
• Operative Komplexität — der Router ist eine weitere Komponente im System, die ausfallen, degradieren kann und überwacht und aktualisiert werden muss.
• Cold-Start-Problem — ein neuer Router ohne historische Daten klassifiziert schlecht. Die ersten Wochen können schlechter sein als eine Single-Model-Strategie.

Routing funktioniert daher am besten in Systemen mit hohem Volumen, heterogenen Anfragen und einer klaren Unterscheidbarkeit zwischen leichten und schweren Aufgaben. Wenn Sie 100 Anfragen täglich haben und alle ähnlich schwierig sind, bringt der Router-Overhead keine sinnvolle Einsparung.

Klären Sie vor der Einführung: Wie sieht der tatsächliche Schwierigkeits-Mix Ihrer Anfragen aus? Wenn Sie keine Daten haben, verbringen Sie zwei Wochen mit dem Loggen und der manuellen Annotation einer Stichprobe von 200–300 Anfragen. Diese Übung deckt auch andere Probleme auf — zum Beispiel, dass 40 % der Aufrufe denselben langen System-Prompt enthalten, bei dem Prompt Caching mehr einspart als Routing.

Wann Routing nicht ausreicht und was stattdessen hilft

Routing adressiert einen Aspekt der Kosten — die Modellauswahl. Es gibt Situationen, in denen eine andere Optimierung effektiver ist:

Wiederkehrende Prefix-Prompts → Prompt Caching ist in der Regel der stärkere Hebel. Wenn 80 % Ihrer Aufrufe denselben 3.000-Token-System-Prompt teilen, reduziert Prompt Caching bei Anthropic die Kosten für diese Tokens um 90 %. Routing würde demselben Problem nicht gerecht.

Steigende Kosten durch einen Agenten mit langer Historie → Hier helfen Kontextkürzung und Zusammenfassung, nicht Routing. Siehe Kosten eines KI-Agenten im Produktivbetrieb.

Langsame Reaktionszeit bei hoher Last → Hier ist Routing ebenfalls nur eine Teilantwort. Die Wahl des Serving-Frameworks (vLLM vs. Ollama), Continuous Batching und die Größe des KV-Cache haben größeren Einfluss auf den Durchsatz.

Routing nach Inhalt, nicht nach Schwierigkeit → Ein anderer Anwendungsfall: Manche Anfragen sollen an ein für eine bestimmte Domäne trainiertes Modell gehen (z. B. ein fine-getuntes Modell für Fertigungsdokumentation), andere an das Generalmodell. Das ist Content-basiertes Routing und eine eigenständige Architekturschicht, unabhängig von der Kostenoptimierung.

Implementierung: Wo anfangen

Wenn Sie Routing ausprobieren möchten, empfehlen wir folgende Vorgehensweise:

1. 1.Daten sammeln, bevor Sie irgendetwas implementieren. Loggen Sie Anfragen mit Metadaten — Länge, Aufgabentyp, Antwortzeit, Qualitätsscore (falls vorhanden). Ohne Daten kalibrieren Sie jeden Router im Blindflug.

1. 1.Mit einem heuristischen Router bei der offensichtlichsten Trennung beginnen. Wenn Sie wissen, dass 30 % Ihrer Anfragen Klassifikationen in vier Kategorien sind und 70 % generativ, gibt die einfache Regel „wenn Typ=Klassifikation → kleines Modell" sofortige Einsparung ohne ML-Overhead.

1. 1.Qualität des kleinen Modells an realen Daten testen. Verlassen Sie sich nicht auf Benchmark-Zahlen. Nehmen Sie 100 reale Anfragen aus Ihrer Produktion, lassen Sie sie durch das kleine Modell laufen und bewerten Sie manuell. Sie werden sehen, wo das Modell versagt und wo es überrascht.

1. 1.Kaskade mit Logprob-Thresholding implementieren. Sowohl vLLM als auch SGLang exponieren Log-Wahrscheinlichkeiten von Tokens. Setzen Sie den Schwellenwert experimentell: Starten Sie bei 0,80, messen Sie Eskalationen und Falschpositive.

1. 1.Verteilung der Eskalationen im Zeitverlauf überwachen. Wenn der Eskalationsanteil steigt, ändert sich entweder der Anfragetyp, oder das kleine Modell degradiert bei einer Kategorie. Der Router braucht laufende Kalibrierung — es ist kein „Einrichten und Vergessen".

Für einen Open-Source-Einstiegspunkt ist RouteLLM von LMSYS / UC Berkeley (Apache 2.0) eine gute Basis — es liefert vortrainierte Klassifikatoren und ein Evaluierungs-Harness. Für Enterprise-Deployments mit On-Premises-Anforderungen ist der embedding-basierte Ansatz mit BGE-M3-Embeddings und lokalem Vektorspeicher Qdrant aus Sicht der Datensouveränität praktischer.

Wann Routing nicht sinnvoll ist

Trotz der Einsparungen gibt es reale Gegenindikationen für Routing:

• Niedriges Volumen (weniger als einige Tausend Anfragen täglich) — der Implementierungs- und Wartungsaufwand überwiegt die Einsparung.
• Homogener Anwendungsfall — wenn alle Anfragen gleich schwierig sind (z. B. ausschließlich komplexe juristische Analysen), fügt Routing nur Komplexität ohne Nutzen hinzu.
• Hohe Fehlerkosten — in regulierten Umgebungen, wo selbst eine teilweise fehlerhafte Antwort des günstigen Modells ein Problem verursacht (Gesundheitswesen, Compliance, Rechtsentscheidungen), ist die Kaskade riskanter. Hier ist es sicherer, einen engen Aufgabenbereich für das kleine Modell mit 100 % manueller Verifikation zu definieren.
• Modell-Nichtdeterminismus bei Eskalation — wenn Ihre Anwendung Reproduzierbarkeit erfordert (gleiche Anfrage, immer gleiche Antwort), verkompliziert die Kaskade das: Manchmal antwortet das kleine Modell, manchmal das starke, die Ausgaben unterscheiden sich.

Häufige Fragen

Woran erkenne ich, ob ich genug Anfragevielfalt habe, damit sich Routing lohnt?

Exportieren Sie eine Stichprobe von 200–300 realen Anfragen und klassifizieren Sie diese manuell in drei Gruppen: leicht, mittel, schwer. Wenn mehr als 30 % in die Kategorie „leicht" fallen, bringt Routing messbare Einsparung. Ist die Verteilung gleichmäßig oder zu „schwer" hin verschoben, bleibt der Effekt marginal.

Wie unterscheidet sich Routing von Load Balancing zwischen mehreren Instanzen desselben Modells?

Load Balancing adressiert Durchsatz und Verfügbarkeit — es verteilt Anfragen auf mehrere Instanzen desselben Modells. Routing adressiert die Modellauswahl — es entscheidet, *welches* Modell (andere Leistungsklasse, anderer Preis) die Anfrage erhält. Beides ist komplementär: Sie können Routing zwischen Modellen und Load Balancing innerhalb jedes Modells kombinieren.

Was tun, wenn das kleine Modell zwar antwortet, die Antwort aber überzeugend wirkt, faktisch jedoch falsch ist?

Das ist das größte Risiko beim Cascading. Konfidenz-Scores aus Log-Wahrscheinlichkeiten erkennen keine faktischen Fehler — das Modell kann „sicher" sein und sich trotzdem irren. Drei Maßnahmen helfen: (1) Das kleine Modell auf Aufgaben mit verifizierbarem Output beschränken (Extraktion, Klassifikation), nicht auf Faktenfragen; (2) Post-Processing-Verifikation des Outputs hinzufügen (per Regex, JSON-Schema, Checkliste); (3) In sensiblen Domänen immer auf das starke Modell eskalieren oder einen Human-in-the-Loop-Schritt einfügen.

Was ist der Unterschied zwischen Routing und einem Multi-Agenten-System, bei dem der Agent selbst entscheidet, was er aufruft?

In einem Multi-Agenten-System orchestriert der Agent weitere Tools und Modelle als Teil der Aufgabenlösung — die Entscheidung liegt innerhalb der LLM-Schleife. Der Router steht vor dem LLM-Aufruf und ist ein externer Klassifikator. Der Router ist schneller und günstiger zu betreiben, hat aber keinen so tiefen Zugang zur Semantik der Aufgabe wie ein Agent. Für komplexe Pipelines siehe KI-Agenten-Architekturen.

Kann ich Routing auch bei lokalen Modellen anwenden, nicht nur bei Cloud-APIs?

Ja, und hier kann der Vorteil sogar ausgeprägter sein. Auf demselben Server können Sie ein kleines 7B-Modell und ein größeres 34B-Modell betreiben. Der Router schickt einfache Anfragen an das 7B (weniger VRAM, kürzere Latenz), komplexe an das 34B. Die Einsparung ist nicht finanzieller, sondern kapazitiver Natur — das 7B bewältigt auf derselben Hardware einen weit höheren Durchsatz, sodass das 34B für schwere Fälle verfügbar bleibt, ohne in eine Warteschlange zu geraten.

*Bei MP Industrial Solutions helfen wir Unternehmen, eine Routing-Strategie zu entwickeln, die zum konkreten Mix ihrer Anfragen passt — von einfacher Heuristik bis zum trainierten Klassifikator mit eigenen Daten. Wenn Sie LLM-Kosten im Produktivbetrieb optimieren oder eine Serving-Infrastruktur für mehrere Anwendungsfälle aufbauen, schauen wir uns Ihre Situation gerne gemeinsam an.*