Modell-Routing: ein technischer Überblick zum State of the Art

Modell-Routing entscheidet dynamisch, welches Modell und wie viel Compute eine Anfrage bearbeitet, mit dem Ziel, auf der Pareto-Front aus Kosten, Qualität und Latenz zu bleiben. Dieser Beitrag ist ein Überblick über das Feld: die Ansätze, der Forschungsstand, wie viel sich realistisch sparen lässt, die gängigen Router-Architekturen und die bekannten Grenzen und Fehlerbilder. Es geht nicht um eine Bauanleitung, sondern um die Landkarte.

Das Wichtigste in Kürze

• Routing wählt pro Anfrage ein Modell, um Kosten, Qualität und Latenz auszubalancieren; die Grundformen sind Pre-generation und Cascade.

• Paper-Zahlen von 85 bis 98 % sind Obergrenzen; realistischer sind AWS’ 16 bis 56 % je Modellfamilie.

• Reale Router bleiben laut RouterArena deutlich unter dem Oracle; typische Fehlerbilder sind Routing Collapse und Confounder-Gadget-Angriffe.

• Der Hauptnutzen bleibt die Kostenersparnis, ergänzt um Reliability, Observability und, für EU-Produkte, Compliance.

Das konzeptionelle „Warum“, also das günstigste Modell zu nehmen, das die Aufgabe noch löst, steht im Grundlagen-Beitrag zu Price-Performance-Routing. Dieser Text ordnet ein, wie weit die Technik dahinter ist.

Was Routing ist, und was nicht

Ein Router ist eine Funktion, die eine Anfrage aus einem Pool von Modellen genau einem zuweist, um erwartete Qualität unter einem Kostenbudget zu maximieren oder Kosten unter einem Qualitäts-Floor zu minimieren. Der Threshold, ab dem die Wahl aufs stärkere Modell fällt, kodiert den Kompromiss zwischen Kosten und Qualität. In der Literatur heißt er „Willingness-to-pay“.

Die grundlegende Unterscheidung betrifft den Zeitpunkt der Entscheidung.

Davon abzugrenzen sind benachbarte Techniken. Mixture of Experts routet Tokens innerhalb eines einzelnen Modells. Ensembling und Fusion fragen mehrere Modelle und kombinieren die Antworten, tauschen also mehr Kosten gegen mehr Qualität. Speculative Decoding beschleunigt ein einzelnes Modell mit einem Draft-Modell. Model-Routing dagegen wählt genau ein Modell aus, um zu sparen.

Der Forschungsstand

Das Feld ist erstaunlich reif. FrugalGPT (Stanford, 2023) etablierte Cascades, Hybrid LLM (Microsoft, ICLR 2024) den Encoder-basierten Difficulty-Router, RouteLLM (Berkeley, ICLR 2025) die auf Präferenzdaten trainierten Router samt Metriken wie APGR (Average Performance Gap Recovered) und CPT (Call-Performance Threshold). Zur Bewertung dienen RouterBench (Metrik AIQ, mit Zero-Router- und Oracle-Router-Baselines) und, am ehrlichsten, RouterArena (ICLR 2026). Dessen Kernbefund ist ernüchternd: Alle realen Router bleiben deutlich unter dem Oracle, vor allem weil sie schlecht erkennen, wann ein kleines Modell schon ausreicht.

Wie viel Routing spart

Die Forschung nennt spektakuläre Zahlen: FrugalGPT bis zu 98 % Kostenersparnis mit Cascades, RouteLLM über 85 % auf MT-Bench bei 95 % der GPT-4-Qualität. Diese Werte gelten auf den jeweiligen Benchmarks und sind Obergrenzen unter günstiger Schwierigkeitsverteilung, keine erwartbaren Produktionswerte. Näher an der Realität liegen die Durchschnitte, die AWS für Bedrock Intelligent Prompt Routing selbst veröffentlicht: je nach Modellfamilie 16 bis 56 % Ersparnis bei gehaltener Top-Qualität.

Ob Routing sich rechnet, hängt an drei Bedingungen: heterogene Schwierigkeit der Anfragen, breite Preisspanne zwischen brauchbaren Modellen und hohes Volumen. Fehlt eine davon, etwa weil fast alle Anfragen schwer sind, landet ohnehin fast alles im Top-Tier. Bei einer Preisspanne unter etwa Faktor 3 bis 5, oder wenn über 70 bis 80 % der Anfragen ins teuerste Tier gehen, bleibt der Effekt gering.

Die drei Grundstrategien

Praktisch alle Router lassen sich auf drei Grundmuster zurückführen, die in Produktion oft kombiniert werden.

Rule-based Tiering ordnet Anfragen deterministisch einem Tier zu, anhand von Signalen wie Task-Typ, Query-Länge oder benötigten Capabilities. Der Ansatz ist transparent und braucht kein ML, ist aber starr und setzt voraus, dass der Task-Typ bekannt ist. Laut RouterArena holt schon gutes Tiering einen großen Teil der erreichbaren Ersparnis.

Classifier Routing schätzt die Komplexität vorab mit einem kleinen, schnellen Modell. In der Forschung dominiert der Encoder-Classifier (BERT, DeBERTa, ModernBERT) mit einem Forward-Pass im Millisekundenbereich; RouteLLM fand die winzige Matrix Factorization am kosteneffizientesten. Die bekannte Schwäche: Router überfitten auf ihre Trainingsverteilung und fallen out-of-domain auf Zufallsniveau, solange die Trainingsdaten nicht augmentiert werden.

Cascade Routing arbeitet post-generation. Erst antwortet das günstige Modell, dann wird dessen Confidence bewertet, und nur bei Unsicherheit eskaliert die Anfrage auf ein stärkeres Modell. Das ist robuster, weil eine echte Antwort vorliegt, kostet aber Zusatzlatenz und mehrere Calls. Confidence-basiertes Deferral ist laut Forschung (Jitkrittum et al., NeurIPS 2023) oft, aber nicht immer optimal.

Router-Architekturen und Latenz

Die Wahl der Router-Architektur ist selbst ein Kosten-Latenz-Kompromiss, denn der Overhead der Entscheidung darf die Ersparnis nicht auffressen. In der Praxis liegen brauchbare Router im Bereich von 10 bis 50 ms.

Routing ist zuerst ein Constraint-Problem

Bevor Kosten überhaupt eine Rolle spielen, schränken harte Capabilities den Pool ein: Context Window, Tool Calling, JSON-Schema-Support, Multimodalität, Streaming und, bei einem EU-Produkt, die Verarbeitungsregion. Ein Modell, dem eine benötigte Capability fehlt, ist unabhängig vom Preis keine gültige Wahl. Bei großen Modell-Pools ist Routing deshalb zuerst eine constrained optimization über den zulässigen Teil-Pool und erst danach eine Kostenfrage. Data Residency zählt dabei zu den harten Constraints: Ein Failover, der eine Anfrage still in eine Nicht-EU-Region schickt, macht aus einem Ausfall einen Compliance-Verstoß.

Die Prompt-Cache-Ökonomie

Der am häufigsten unterschätzte Effekt ist keine ML-Frage, sondern Buchhaltung. Wechselt eine Folgeanfrage den Provider, ist dessen Prompt-Cache-Prefix verloren, und das nominal günstigere Modell kann netto teurer werden. Dazu kommt, dass Tokenizer sich unterscheiden: Derselbe Prompt hat je Modell eine andere Token-Zahl und damit einen anderen Preis. Die realen Kosten einer Route setzen sich also aus Input- und Output-Tokens, Cache-Read- und Write-Anpassungen sowie erwarteten Retry- oder Cascade-Kosten zusammen. Daraus stammt die verbreitete Faustregel „if you route, pin“: Session Pinning hält den Cache warm, sobald mehr als ein Modell im Spiel ist.

Semantic Caching

Semantic Caching speichert Antworten nach Embedding-Ähnlichkeit der Query statt per Exact Match. Ein Treffer schließt das Routing komplett kurz, weil kein Modellaufruf nötig ist. Der Preis dafür sind mögliche False-Positive-Hits, wenn der Similarity-Threshold zu locker gesetzt ist. Für FAQ-artige Workloads mit vielen Wiederholungen ist es der größte einzelne Sparhebel.

Failure Modes

Routing Collapse. Mit steigendem Kostenbudget kippen viele Router systematisch ins teuerste Modell, auch wenn ein günstiges reichen würde. Die Arbeit „When Routing Collapses“ (2026) beschreibt das und führt es auf einen Objective-Decision-Mismatch zurück: Router sagen skalare Scores voraus, treffen aber diskrete Vergleichsentscheidungen, und kleine Fehler kippen die Reihenfolge. Als Gegenmaßnahme schlägt sie mit EquiRouter einen decision-aware, ranking-basierten Ansatz vor.

Confounder Gadgets. „Rerouting LLM Routers“ (COLM 2025) zeigt query-unabhängige Token-Ketten, die jeder Anfrage vorangestellt den Router zuverlässig ins teure Modell zwingen. Ein solcher Denial-of-Wallet-Angriff verschlechtert die Antwortqualität nicht und umgeht Perplexity-Filter. Als Schutz gelten Input-Screening und eine Cost-Anomaly-Detection pro Nutzer.

Die GPT-5-Lektion. Die öffentlichste Lektion lieferte OpenAI selbst. Beim GPT-5-Start fiel der Auto-Router aus, wodurch schwere Anfragen im günstigen Modell landeten und das System „dümmer“ wirkte; parallel leitete ein stiller Safety-Router bestimmte Prompts undokumentiert um. Der Fall gilt seither als Beleg, dass intransparentes, stilles Umrouten ein Vertrauensrisiko ist.

Wie Routing bewertet wird

Belastbare Vergleiche laufen gegen vier Baselines: Random Routing, das Oracle als Obergrenze, das beste Einzelmodell und ein kostengleiches Einzelmodell. Übliche Kennzahlen sind Kosten bei iso-Qualität, Qualität bei iso-Kosten sowie APGR, CPT oder AIQ. In Produktion kommen Shadow-Deployments (der Router läuft mit, ohne seine Wahl zu servieren), Canary auf einem kleinen Traffic-Anteil und Offline-Replay aus Logs hinzu. RouterArena zeigt, dass reale Router hier durchweg unter dem Oracle bleiben, vor allem weil sie zu selten erkennen, wann ein kleines Modell reicht.

Zwei Trends, die Routing verändern

Zwei Entwicklungen verändern das Bild, ohne den Kernnutzen aufzuheben. Fallende Frontier-Preise verkleinern die Preisspanne etwas, und die Provider bauen Routing zunehmend selbst ein: der interne Router von GPT-5, Geminis Thinking Budgets und der reasoning_effort-Parameter entscheiden schon vor einem externen Router, wie viel Compute eine Anfrage bekommt.

Der greifbarste Grund für Routing bleibt trotzdem die Kostenersparnis. Solange Aufgaben unterschiedlich schwer sind und die Preisspanne breit ist, spart das günstigste passende Modell real Geld, in der Praxis oft im Bereich von 60 bis 80 Prozent. Ein Gateway macht diesen Hebel praktikabel und legt Reliability durch Failover, Observability und, für EU-Produkte, Compliance obendrauf. Kostenersparnis und Kontrolle kommen aus derselben Ebene, sie schließen sich nicht aus.

Wo ein EU-Gateway wie kontinent.ai einzuordnen ist

Für ein EU-Produkt kommt beides zusammen: die Kostenersparnis aus dem Routing und die Kontrolle darüber. Ein Gateway, das OpenAI, Claude, Gemini, Mistral und weitere Modelle hinter einem OpenAI-kompatiblen Endpoint bündelt, schickt jede Anfrage ans günstigste passende Modell und macht den Modellwechsel zu einem String-Tausch statt zu einem Integrationsprojekt. Läuft die Verarbeitung EU-gehostet, ist Data Residency über den gesamten Pool hinweg eine harte Constraint statt einer Aufgabe pro Anbieter, inklusive EU-only Failover. Dort ordnet sich kontinent.ai ein: als EU-gehosteter Zugang zu 167 Modellen in 240 Anbieter-Varianten, der reale Kostenersparnis mit Compliance, Reliability und Observability verbindet, statt sie gegeneinander auszuspielen.

Häufige Fragen

Pre-generation oder Cascade: was ist der Unterschied?

Pre-generation (predictive) entscheidet vor dem Generieren allein aus der Query, günstig und latenzarm, aber blind gegenüber der tatsächlichen Schwierigkeit. Cascade entscheidet nach einer echten Antwort und ist robuster, kostet dafür Zusatzlatenz und mehrere Calls. In der Praxis werden beide kombiniert.

Wie viel spart Routing realistisch?

Nicht die 85 bis 98 % aus den Papern, das sind Benchmark-Obergrenzen. Realitätsnäher sind AWS’ eigene Durchschnitte von 16 bis 56 % je Modellfamilie, und auch das nur bei heterogener Schwierigkeit, breiter Preisspanne und hohem Volumen.

Was ist Routing Collapse?

Das Phänomen, dass Router mit wachsendem Budget alles ins teuerste Modell schicken, obwohl günstige reichen würden. Ursache ist die Vorhersage skalarer Scores bei eigentlich diskreten Entscheidungen.

Warum kann ein günstigeres Modell netto teurer sein?

Weil beim Providerwechsel der Prompt-Cache-Prefix verloren geht. Ein warmer Cache ist oft mehr wert als der niedrigere Listenpreis, weshalb sich die Faustregel „if you route, pin“ etabliert hat.

Ist externes Routing angesichts fallender Preise noch relevant?

Ja. Der größte Hebel bleibt die Kostenersparnis: Solange Anfragen unterschiedlich schwer sind, spart das günstigste passende Modell real Geld. Fallende Preise und provider-internes Routing verkleinern den Effekt nur an den Rändern. Dazu kommen Reliability, Observability und, für EU-Produkte, Compliance aus derselben Ebene.

Stand: August 2026 · kontinent.ai. Forschungszahlen (FrugalGPT, RouteLLM, RouterArena, AWS Bedrock u. a.) sind Benchmark- bzw. Herstellerangaben und keine zugesicherten Produktionswerte.