Model Routing

Model Routing entscheidet für jede einzelne Nutzeranfrage (Prompt), welches Sprachmodell sie beantwortet. Eine kleine Vorschalt-Logik, entweder eine feste Regel oder ein leichtes Bewertungsmodell (Klassifikator), schickt einfache Anfragen an ein günstiges, schnelles Modell und schwierige Anfragen an das teurere Spitzenmodell.

Was ist Model Routing?

Model Routing ist die Auswahlschicht, die vor mehreren Sprachmodellen sitzt. Betreibt eine Anwendung mehrere Modelle parallel, ein starkes und teures Spitzenmodell (etwa Claude Opus oder GPT-5.1), ein solides Mittelklasse-Modell (Claude Sonnet) und ein kleines, günstiges Modell für einfache Fälle (Claude Haiku oder ein frei verfügbares Open-Source-Modell), stellt sich für jede eingehende Anfrage die gleiche Frage: Welches Modell soll antworten? Der Router entscheidet das pro Anfrage, nicht einmalig pro Nutzer-Sitzung und nicht pauschal pro Anwendung. Die aufrufende Anwendung sieht dabei nur einen einzigen Modell-Endpunkt (ein „virtuelles Modell"), das dahinterliegende Ziel-Modell bleibt für sie verborgen.

Vier Bauarten dominieren die Ebene. Statisches Regel-Routing bewertet Prompt-Merkmale wie Länge, Sprache, Domäne oder Konto-Typ und leitet über eine feste Zuordnungstabelle weiter; die Entscheidung ist deterministisch und günstig, deckt aber nur bekannte Fälle ab. Klassifikator-Routing nutzt ein kleines Modell (häufig Embedding-basiert oder ein flaches Neural Network), das anhand des Prompt-Inhalts eine Klasse vorhersagt und daraus das Ziel-Modell ableitet; die Latenz liegt bei 50–100 ms zusätzlich. Router-LLM lässt ein kleines Sprachmodell die Auswahl treffen; das ist flexibler, aber teurer und schwerer nachvollziehbar. Score-basiertes Routing vergleicht die vorhergesagte Antwortqualität mehrerer Kandidaten auf einer Präferenz-Skala; RouteLLM (LMSYS, 2024) hat dieses Verfahren als offene Referenz-Implementierung etabliert und zeigt Kostensenkungen um Faktoren, während rund 95 Prozent der Frontier-Qualität gehalten werden.

Warum die Auswahlschicht einen eigenen Namen bekommt: Ohne Router laufen alle Anfragen auf das teuerste Modell, auch triviale Klassifikationen und einfache Zusammenfassungen. Ein LLMOps-Setup ohne Model Routing zahlt die volle Frontier-Rechnung für Antworten, die ein Zehntel-Modell in gleicher Qualität liefert. Referenz-Implementierungen sind RouteLLM (Score-Routing), LiteLLM Router (provider-übergreifende Routing-Regeln mit Fallback), OpenRouter (Managed Auto Router), Not Diamond und Martian (Managed Score-Routing) sowie die Routing-Module in Gateways wie Portkey, Helicone und der Microsoft Foundry Model Router.

Abgrenzung zu Agent Routing, LLM Gateway und Mixture of Experts

Der Begriff wird häufig mit angrenzenden Konzepten vermischt. Die folgende Tabelle grenzt die Nachbarn ab:

Der Kern-Unterschied zu Agent Routing liegt im Auswahl-Objekt. Model Routing wählt das Modell (Frontier gegen Mid-Tier gegen Small), Agent Routing wählt die Rolle in einem Multi-Agent-System (Recherche-Agent, Ticket-Agent, Refund-Agent). Beide Ebenen können denselben Router-Baustein teilen und in derselben Komponente kombiniert werden, sind aber unterschiedliche Entscheidungen: Der Agent-Router löst „Wer bearbeitet den nächsten Schritt?", der Model-Router löst „Mit welchem Modell?".

Ein LLM Gateway ist die Vermittlungsschicht für Multi-Provider-Zugriffe: Authentifizierung, Rate-Limiting, Kostenzuordnung, Guardrails, Retries und Logging. Model Routing ist eine Funktion, die ein Gateway anbieten kann (Portkey, Helicone, LangDB, Kong AI Gateway tun das), aber nicht seine Kern-Rolle. Der Begriff Model Routing beschreibt die reine Auswahllogik, das Gateway beschreibt die Betriebs-Plattform drumherum.

Mixture of Experts (MoE) ist eine modell-interne Architektur mit spezialisierten Sub-Netzen und einem Gating-Router pro Token, entschieden im Forward-Pass durch das Modell selbst (Mixtral, DBRX, Grok-1). Model Routing entscheidet extern, zwischen ganzen Modellen. MoE ersetzt Model Routing nicht; ein MoE-Modell kann Ziel eines Model Routers sein.

Load-Balancing verteilt Requests auf identische Instanzen desselben Modells zur horizontalen Skalierung. Die Entscheidung ist kapazitätsgetrieben. Model Routing entscheidet zwischen ungleichen Modellen und ist inhaltsgetrieben.

Beispiel: dreistufiger Router im Support-Bot

Ein Support-Bot bearbeitet eingehende Kundenanfragen über einen dreistufigen Router. Die Anwendung ruft ein virtuelles Modell auf, dahinter läuft die Auswahl.

• Stufe 1 (Klassifikator): Ein kleines Klassifikationsmodell (Embedding + flache Klassifizierung, ~80 ms Latenz) liest die Anfrage und bestimmt den Intent: einfache FAQ, mittelkomplexe Beratung, juristisch/technisch komplexe Eskalation oder unklar.
• Stufe 2 (Regel-Overlay): Ein statisches Regel-Set schlägt bestimmte Anfragen zwingend auf das Frontier-Modell durch, etwa Anfragen mit Compliance-Flag oder Konto-Typ „Enterprise".
• Stufe 3 (Modellwahl): FAQ-Fälle laufen auf ein Small-Modell (Claude Haiku, GPT-5.1 Nano) mit rund einem Prozent der Frontier-Token-Kosten. Beratungsfragen laufen auf Mid-Tier (Claude Sonnet). Eskalationen laufen auf Frontier (Claude Opus, GPT-5.1).

Der Router sitzt hinter einem LLM Gateway oder als Modul darin. Beobachtbares Ergebnis-Muster: 70 bis 80 Prozent der Anfragen landen auf Small oder Mid-Tier, die Modell-Kosten reduzieren sich um 40 bis 60 Prozent gegenüber einem Single-Modell-Setup auf Frontier-Niveau. Die Antwortqualität bleibt messbar konstant, weil einfache Anfragen kein Frontier-Modell brauchen und die Eskalationsregel die kritischen Fälle abfängt.