AI Router: Modelle gezielt auswählen und richtig testen

Das leistungsstärkste Modell sollte die Aufgaben übernehmen, die seine Fähigkeiten tatsächlich erfordern. Eine Auskunft zum Bestellstatus auf Basis authentifizierter Daten und ein strittiger Erstattungsfall mit widersprüchlichen Unterlagen müssen nicht automatisch denselben Weg nehmen. Die Schwierigkeit liegt darin, den Unterschied rechtzeitig zu erkennen, bevor eine günstige Antwort teure Nacharbeit verursacht.

Die hier beschriebenen Produktfunktionen wurden am 21. Oktober 2026 anhand der aktuellen Dokumentation geprüft. Die Supportfälle und Berechnungen dienen der Veranschaulichung. Es handelt sich weder um Messungen aus dem Produktivbetrieb noch um Einsparungsversprechen der Anbieter.

Wie ein AI Router das passende Modell auswählt

Ein LLM-Router, auch Model Router genannt, wählt für jede Anfrage das antwortende große Sprachmodell aus, kurz LLM. Dahinter steckt eine Regel oder ein trainierter Klassifikator, der Eingaben einer Kategorie zuordnet. Zur Modellauswahl kann der Router etwa den Aufgabentyp der Anwendung, den Gesprächsverlauf, benötigte Tools, den Umfang der Eingabe oder eine Schätzung des Schwierigkeitsgrads heranziehen.

Das Prinzip ähnelt der Aufgabenverteilung in einem Supportteam. Eine Routineauskunft geht an jemanden, der sie effizient erledigen kann; ein strittiger Fall an eine Fachkraft. Zusätzlich braucht es einen Eskalationsweg für Aufgaben, zu deren Erledigung niemand befugt ist.

In einer Anwendung heißt das: Zuerst die Eignung prüfen, dann optimieren. Kann das Modell die Eingabe verarbeiten, die nötigen Tools aufrufen und über einen freigegebenen Anbieter ausgeführt werden? Erst unter den geeigneten Kandidaten wird nach Kosten oder erwarteter Qualität ausgewählt.

Modell-Routing, Anbieter-Routing und Fallback beantworten unterschiedliche Fragen. Modell-Routing bestimmt, welches Modell antwortet. Anbieter-Routing legt fest, wo ein bereits ausgewähltes Modell ausgeführt wird, etwa bei welchem Hostinganbieter. Ein Fallback bestimmt den nächsten Versuch, wenn ein Aufruf scheitert. Ein Gateway als Zugriffsschicht zwischen Anwendung und Modell-APIs kann all diese Funktionen übernehmen. Allein durch den Einbau eines Gateways entsteht jedoch noch keine Modellauswahl, die die Antwortqualität berücksichtigt.

Als Frontier-Modell gilt hier der leistungsstärkste Allzweckkandidat, der für die Anwendung infrage kommt. Auch dieses Modell kann falsch antworten. Routing verteilt Modellleistung; es stellt nicht fest, ob eine Antwort wahr ist.

Drei Ansätze für LLM-Routing

Am Anfang sollten nachvollziehbare Regeln stehen. Eine automatische Auswahl wird dann nützlich, wenn sie Unterschiede erfasst, die diese Regeln übersehen, und dabei weiterhin die festgelegten Abnahmekriterien erfüllt. Die folgenden drei Ansätze überschneiden sich: Ein Gateway kann beispielsweise einen trainierten Router betreiben.

Selbst definierte Regeln

Die Anwendung ordnet bekannte Aufgabentypen und Vorgaben bestimmten Modellen zu. Eine Anfrage an einen Endpunkt für den Bestellstatus, die authentifizierte Bestelldaten und eine freigegebene Antwortvorlage mitbringt, eignet sich eher für ein kleines Modell als eine Nachricht, die allein wegen ihrer Kürze als einfach eingestuft wird.

Regeln helfen, wenn die Anwendung den Ablauf bereits kennt. An ihre Grenzen stoßen sie bei Mehrdeutigkeit: Über denselben Endpunkt kann eine einfache Statusabfrage oder eine Beschwerde mit widersprüchlichen Unterlagen eingehen. Für unklare Fälle sollte deshalb ein eigener Routing-Pfad bestehen bleiben, statt die Auswahl um immer mehr fehleranfällige Schlüsselwortregeln zu erweitern.

Automatisches Routing im Gateway

Die Anwendung sendet eine Anfrage an einen Routing-Alias, und das Gateway wählt das Modell aus. Je nach Produkt nutzt es dafür einen Klassifikator, konfigurierte Stufen oder andere Signale. Das Verhalten lässt sich damit zentral steuern; zugleich übernimmt die Anwendung aber die Maßstäbe des Routers dafür, welches Modell zu einer Aufgabe passt.

Dieser Ansatz bietet sich an, wenn die eingehenden Aufgaben stark variieren und ein eigener Auswahlmechanismus unverhältnismäßig aufwendig wäre. Der Kandidatenkreis sollte auf freigegebene Modelle beschränkt sein. Außerdem muss protokolliert werden, welches Modell tatsächlich geantwortet hat. Ein Alias bezeichnet nicht dauerhaft dasselbe Modell.

Wie ein trainierter Router aus Ergebnissen lernt

Ein trainierter Router lernt anhand von Beispielen und bewerteten Ergebnissen, welcher Kandidat voraussichtlich besser abschneidet. Entscheidend für das Training ist, ob das stärkere Modell bei einer Anfrage einen Mehrwert liefert. Wie kompliziert der Text wirkt, reicht als Kriterium nicht aus.

RouteLLM ist ein Open-Source-Framework für den Betrieb und die Evaluation von Routern. Die Dokumentation beschreibt eine anhand von Präferenzdaten trainierte Auswahl zwischen stärkeren und schwächeren Modellen sowie die Kalibrierung des Schwellenwerts. Dieser Schwellenwert steuert, wie häufig das stärkere Modell gewählt wird. Die veröffentlichten Ergebnisse belegen nicht, wie das Verfahren bei den eigenen Tickets abschneidet. RouteLLM-Dokumentation.

Der Pflegeaufwand entsteht vor allem, wenn sich die Verteilung der Anfragen verändert: Neue Aufgabentypen oder ausgetauschte Modelle können einen zuvor sinnvollen Schwellenwert unbrauchbar machen. Training und Kalibrierung gehören deshalb auf Entwicklungsbeispiele. Die anschließende Evaluation erfolgt mit separaten Fällen, auf die der Router noch nie abgestimmt wurde.

Eine Routing-Richtlinie für eine Supportanwendung

Klar abgegrenzte, durch Daten belegte Antworten gehen an das kleine Modell; ungeklärte Schlussfolgerungen an das Frontier-Modell. Berechtigungen bleiben Sache der Anwendungsrichtlinien. Kein Modell darf eine Erstattung auslösen, nur weil es sie erklären kann.

Als Beispiel dient ein Händler mit Abonnementgeschäft. Seine Anwendung ruft die Bestellung, die einschlägigen Richtlinien und den Gesprächsverlauf ab, bevor sie eine Antwort entwirft. Die folgende Richtlinie ist ein Vorschlag. Sie behauptet nicht, dass ein bestimmtes kleines Modell diese Anforderungen bereits erfüllt.

Fehlen notwendige Belege, sollte das kleine Modell keine Antwort geben. Die Anwendung kann fehlende Bestellfelder, eine ungültige Ausgabestruktur oder eine angeforderte Aktion außerhalb des erlaubten Ablaufs erkennen. Für sachliche Widersprüche kann eine zusätzliche Prüfinstanz oder eine menschliche Prüfung nötig sein. Eine syntaktisch gültige Antwort kann trotzdem falsch sein.

Das Frontier-Modell übernimmt die schwierigen Fälle. Ein gescheiterter Versuch des kleinen Modells sollte nur dann dorthin eskaliert werden, wenn sich der Fehler erkennen lässt. Fehlende Unterlagen müssen abgerufen oder durch Rückfragen ergänzt werden. Ein größeres Modell kann die Lücke nicht schließen, wenn es dieselben unvollständigen Belege erhält.

Eskalierte Aufrufe mitrechnen

Angenommen, ein beispielhafter Stapel umfasst 1,000 Anfragen. Die Richtlinie schickt davon 700 an das kleine Modell und 300 direkt an das Frontier-Modell. Von den zunächst an das kleine Modell gerichteten Aufrufen bestehen 70 eine Prüfung nicht und werden mit dem Frontier-Modell wiederholt.

Damit fallen Kosten für 700 Aufrufe des kleinen Modells und 370 Frontier-Aufrufe an, zuzüglich Routing und Validierung. Insgesamt sind das 1,070 Aufrufe antwortender Modelle, nicht 1,000. Ein erneuter Versuch verursacht zusätzliche Arbeit, auch wenn für den Nutzer nur die endgültige Antwort sichtbar ist.

Dabei bezeichnet r die durchschnittlichen Routing-Kosten je ursprünglicher Anfrage, s die durchschnittlichen Kosten eines Aufrufs des kleinen Modells, f die durchschnittlichen Kosten eines Frontier-Aufrufs und g zusätzliche Gateway- oder Validierungskosten für den gesamten Stapel. Für dieses vereinfachte Beispiel wird angenommen, dass der Frontier-Durchschnitt bei der Vergleichsbasis, den direkten Aufrufen und den Eskalationen gleich ist:

Kosten mit Routing = 1,000r + 700s + 370f + g

Vergleichsbasis nur mit Frontier-Modell = 1,000f

Routing ist nur günstiger, wenn 700(f − s) > 70f + 1,000r + g gilt. Links stehen die anfänglich eingesparten Antwortkosten auf dem Pfad zum kleinen Modell; rechts die zusätzlichen Frontier-Wiederholungen und der Zusatzaufwand.

Die Kosten pro Aufruf ergeben sich aus den gewählten Modellen und Tarifen: Aufrufkosten = (nicht zwischengespeicherte Eingabetokens × Eingabetarif + zwischengespeicherte Eingabetokens × Cache-Tarif + abgerechnete Ausgabetokens × Ausgabetarif) / 1,000,000, sofern die Tarife je Million Tokens angegeben sind. Separat berechnete Tool- und Anfragegebühren kommen hinzu.

Im Produktivbetrieb werden die vereinfachten Durchschnittswerte durch den tatsächlichen Verbrauch je Aufgabe und Routing-Pfad ersetzt. Schwierige Tickets können längere Antworten erzeugen, Wiederholungen mehr Kontext enthalten und Modellwechsel die Wiederverwendung des Caches verändern. Tokens des Routing-Klassifikators und gegebenenfalls abgerechnete Reasoning-Tokens gehören in die Rechnung, ohne dieselbe Gebühr doppelt zu erfassen. Für beide Systeme muss dieselbe Richtlinie für Wiederholungsversuche gelten.

Entscheidend sind niedrigere Kosten je akzeptierter Lösung, während das geforderte Qualitätsniveau erhalten bleibt. Sinkt die Rechnung, während unbelegte Erstattungszusagen zunehmen, ist dieses Ziel verfehlt.

Was die dokumentierten Routing-Angebote leisten

Vor der Nutzung eines Routing-Endpunkts muss klar sein, wie er auswählt. Die Produkte steuern unterschiedliche Entscheidungen. Dass sie alle das Wort „Router“ verwenden, macht ihr Standardverhalten nicht gleichwertig.

OpenRouter: Auto Router mit Aufgabenklassifikation

OpenRouter ist ein verwaltetes Gateway zu mehreren Modellanbietern und stellt den Auto Router über openrouter/auto bereit. Laut aktueller Dokumentation wird zunächst die Aufgabe klassifiziert. Anschließend werden Modelle anhand der aufgabenspezifischen Ausgaben der Community innerhalb der vergangenen 7 Tage eingeordnet; danach folgen Filter für Kostenband und Eignung. Das ist ein aggregiertes Nutzungssignal, kein Maßstab für die Qualität der eigenen Supportantworten. Dokumentation zum Auto Router.

Für cost_tier stehen low, medium, high, xhigh und max zur Wahl; die Standardeinstellung verhält sich ungefähr wie low. Eine Stufe bezeichnet ein Kostenband, keine feste Ausgabenobergrenze. Mit allowed_models und excluded_models lässt sich der Kandidatenkreis eingrenzen. Das Feld model in der Antwort sollte protokolliert werden. Eine Bindung innerhalb des Gesprächs kann die Auswahl beibehalten, garantiert aber nicht, dass sie unverändert bleibt.

Ist der API-Schlüssel in der Umgebung gesetzt, lässt sich damit eine minimale Routing-Anfrage senden:

curl --fail-with-body https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openrouter/auto",
    "messages": [{"role": "user", "content": "Rewrite this status politely: Your parcel is in transit."}],
    "plugins": [{"id": "auto-router", "cost_tier": "low"}]
  }'

Für die Evaluation sollte der Kandidatenkreis begrenzt sein. Ändert sich der Modellpool laufend, lassen sich die Qualitätsergebnisse vom Vortag schwerer einordnen.

LiteLLM: Deployment-Routing und Auto Router unterscheiden

LiteLLM ist ein konfigurierbares LLM-Gateway. Es dokumentiert verschiedene Strategien für die Auswahl von Deployments: gewichtete Auswahl, Auswahl nach geringster Auslastung sowie latenz- und kostenbasiertes Routing. Die Standardstrategie simple-shuffle klassifiziert nicht den Schwierigkeitsgrad von Supporttickets. Routing-Dokumentation.

Der separate Auto Router unterstützt laut Dokumentation heuristische und LLM-basierte Klassifikatoren sowie Schlüsselwortregeln und eigene Plugins. Die Stufen SIMPLE, MEDIUM, COMPLEX und REASONING werden konfigurierten Modellen oder Modellpools zugeordnet. Im Dashboard führt der dokumentierte Einrichtungsweg über Models + Endpoints → Add Model → Auto Router, gefolgt von der Konfiguration und Test Routing. Dokumentation zum Auto Router.

Das passt zu Entwicklungsteams, die die Modellkandidaten und das Klassifikationsverhalten selbst steuern wollen. Die Verantwortung für den Betrieb bleibt beim eigenen Team: Eine Zuordnung zu Stufen belegt noch nicht, dass die Abnahmekriterien erfüllt werden. Der Vergleich LiteLLM vs. OpenRouter behandelt diese Infrastrukturentscheidung ausführlicher.

Vercel AI Gateway: Anbieterauswahl und gezielte Routing-Steuerung

Vercel AI Gateway ist eine verwaltete Zugriffsschicht für Modell-APIs. Standardmäßig wählt sie Anbieter anhand der zuletzt beobachteten Verfügbarkeit und Latenz. Die Anbieteroptionen steuern Reihenfolge und Filterung; als Zeichenfolgen angegebene Modell-Fallbacks greifen auf Ersatzmodelle zurück, wenn das primäre Modell scheitert oder nicht verfügbar ist. Das sind nützliche Mechanismen für einen zuverlässigen Betrieb. Sie entscheiden für sich genommen jedoch nicht, ob ein Supportticket ein Frontier-Modell benötigt. Dokumentation zu Anbieter-Routing und Fallbacks.

Die Routing-Regeln des Gateways können außerdem ein angefordertes Modell durch ein anderes ersetzen oder die Anfrage ablehnen. Eine solche Umschreibung kann Anfragen zentral auf ein anderes Modell umstellen. Alle Anfragen an ein bestimmtes Modell umzuleiten ist aber etwas anderes, als den Schwierigkeitsgrad jeder einzelnen Anfrage zu klassifizieren. Dokumentation zu Routing-Regeln.

Für ein ausdrücklich festgelegtes Verhalten dienen diese Funktionen als Grundlage unter einer Auswahlrichtlinie auf Anwendungsebene. Problematisch ist die Annahme, eine automatische Anbieterauswahl würde zugleich nach der erforderlichen Antwortqualität auswählen. Zur grundsätzlichen Wahl dieser Zugriffsschicht siehe KI-Gateways für Anwendungen mit mehreren Modellen.

Microsoft Foundry: ein vom Anbieter betriebener trainierter Router

Der Model Router von Microsoft Foundry ist eine trainierte Modellauswahl, die als Deployment bereitgestellt wird. Microsoft beschreibt eine Auswahl nach Komplexität, erforderlichen Schlussfolgerungen, Aufgabentyp und weiteren Merkmalen. Verfügbar sind die Modi Balanced, Quality und Cost sowie die Möglichkeit, den Modellumfang auf Teilmengen zu begrenzen. Grundlagen des Model Routers.

Der Ansatz eignet sich für Anwendungen, die Foundry bereits nutzen und eine verwaltete Auswahl unter geeigneten Modellen benötigen. Entscheidend ist der Kandidatenkreis: Region und Zugriffsrechte beeinflussen die Verfügbarkeit. Außerdem weist Microsoft darauf hin, dass das kleinste Kontextfenster der zugrunde liegenden Modelle begrenzt, welche Eingaben der Router zuverlässig annehmen kann. Die Auswahl sollte daher auf Modelle beschränkt werden, die die eigenen Eingabeanforderungen erfüllen.

Ein Modus mit dem Namen Quality ersetzt keine aufgabenspezifische Evaluation. Die gewählte Teilmenge muss mit den tatsächlichen Gesprächslängen, Tools und Abnahmekriterien getestet werden.

Welcher LLM-Router passt zur Anwendung?

Regeln in der Anwendung genügen, solange sich einfache Aufgaben zuverlässig erkennen lassen. Verwaltetes Auto-Routing kommt infrage, wenn die Vielfalt der Aufgaben diese Regeln fehleranfällig macht. Ein eigener trainierter Auswahlmechanismus lohnt die Prüfung, sobald genügend repräsentative, bewertete Ergebnisse vorliegen, um seine laufende Pflege zu rechtfertigen.

Für weitere Infrastrukturangebote jenseits dieser Mechanismen bietet der Leitfaden zu OpenRouter-Alternativen den nächsten Vergleich. Zuerst müssen jedoch die Routing-Richtlinie und ihre Belege geklärt sein. Eine längere Anbieterliste löst diese Entscheidung nicht.

Wie lässt sich ein Router mit einem Evaluationsdatensatz prüfen?

Gemessen werden die Antworten, die durch das Routing entstehen, nicht die Übereinstimmung mit Etiketten wie „einfach“ und „schwierig“. Ein Auswahlmechanismus kann Aufgabenkategorien korrekt erkennen und trotzdem die falschen Fälle an das kleine Modell schicken.

Ein Evaluationsdatensatz ist eine wiederholt nutzbare Sammlung von Anfragen, Kontext und Abnahmekriterien. Für die Supportanwendung sollte jeder Fall den Gesprächsverlauf, einen eingefrorenen Stand der Bestelldaten, die geltende Richtlinie, erwartete Fakten, unzulässige Aussagen oder Aktionen sowie das vorgeschriebene Eskalationsverhalten enthalten.

Die Auswertung sollte kostspielige Fehler sichtbar machen:

Erfüllt kein Fall die Bedingung im Nenner einer Kennzahl, ist sie als undefiniert auszuweisen, nicht als null. Der Anteil schädlicher Zuweisungen an das kleine Modell wird anhand der unabhängig bewerteten Modellausgaben geschätzt. Zusätzlich werden die endgültigen Fehler nach möglichen Eskalationen erfasst. Fälle, in denen beide Modelle scheitern, müssen separat ausgewiesen werden: Ein Auswahlmechanismus kann aus diesen Kandidaten keine akzeptable Antwort hervorbringen.

Vor dem Test wird festgelegt, welche nichtkritische Qualitätsabweichung noch akzeptabel ist. Jede neue kritische Verschlechterung wird untersucht. Die Konfidenzintervalle müssen zur gepaarten Stichprobe passen. Schließt die verbleibende Unsicherheit noch einen unvertretbaren Qualitätsverlust ein, braucht es mehr Belege, bevor Gleichwertigkeit festgestellt werden kann.

Abschließend läuft der Router im Schattenbetrieb auf einer begrenzten Stichprobe echter Anfragen mit, während das bisherige Modell weiterhin die Kundenantworten liefert. Diese zusätzlichen Aufrufe verursachen Kosten. Nach der Auswertung folgt eine begrenzte Einführung mit der Möglichkeit, sofort zur bisherigen Modellrichtlinie zurückzukehren. Die Überwachung erfolgt weiter nach Anfragetyp. Ändern sich Prompts, Tools, Modelle oder Routing-Verhalten, wird die Evaluation erneut durchgeführt.

Welche Versprechen beim Modell-Routing zu weit gehen

„Gleiche Qualität für weniger Geld“ ist ein Ergebnis für eine bestimmte Arbeitslast, keine Eigenschaft eines Routers. Es hängt davon ab, welche Anfragen eingehen, welche Kandidaten verfügbar sind und was als akzeptabel gilt. Keine prozentuale Einsparung aus einem fremden Einsatzszenario ersetzt diese Messungen.

Auch eine erfolgreiche API-Antwort sagt wenig über die inhaltliche Qualität aus. Ein Fehler-Fallback kann einen nicht verfügbaren Endpunkt abfangen. Eine erfundene Richtlinie in einer flüssig formulierten Antwort erkennt er jedoch nicht. Qualitätsbedingte Eskalationen brauchen eine eigene Prüfung, die ihrerseits Kosten verursacht und Fehler machen kann.

Schwierigkeitsbewertungen verdienen dieselbe kritische Prüfung. Die Konfidenz eines Klassifikators entspricht nicht automatisch der Wahrscheinlichkeit, dass das gewählte Modell richtig antwortet. Jeder Schwellenwert muss anhand beobachteter Aufgabenergebnisse kalibriert werden. Nutzereingaben wie „Das ist einfach“ dürfen weder Anwendungsberechtigungen noch Einschränkungen des Kandidatenkreises außer Kraft setzen.

Schließlich kann sich die automatische Auswahl auch dann ändern, wenn der Anwendungscode unverändert bleibt. Bei OpenRouter verändert sich der ausgabenbasierte Kandidatenkreis; Microsoft kann die zugrunde liegenden Modelle seiner aktuellen Model-Router-Version ergänzen. Aufgrund dieser dokumentierten Verhaltensweisen gehören die Protokollierung der Kandidaten und erneute Evaluationen zum laufenden Betrieb. Sie sind keine optionale Nacharbeit.

Für wen sich der Einstieg lohnt und was als Nächstes ansteht

Entwicklungsteams sollten beginnen, sobald sich wiederkehrende Aufgaben mit einem klaren Erfolgskriterium abgrenzen lassen. Für belegbare Statusantworten wird ein Pfad zum kleinen Modell ergänzt. Für unklare Fälle bleibt eine vorsichtige Zuweisung bestehen. Die Richtlinie wird versioniert, damit Fehler reproduzierbar sind.

Betriebsverantwortliche sollten Belege für den gesamten Ablauf verlangen. Eine niedrigere Inferenzrechnung reicht nicht aus, wenn mehr Tickets wieder geöffnet werden, mehr menschliche Prüfungen nötig sind oder die Lösungsdauer steigt. Diese Ergebnisse gehören neben die Offline-Evaluation.

Einkaufsverantwortliche sollten einen Testlauf mit eigenen Fällen verlangen. Es muss erkennbar sein, welche Modelle gewählt werden und wie sich Fallbacks verhalten. Ein allgemeiner Benchmark belegt nicht, dass ein Router die eigene Erstattungsrichtlinie versteht.

Abwarten ist sinnvoll, wenn sich ein korrektes Ergebnis nicht definieren lässt, der Kandidatenpool nicht begrenzt werden kann oder das Anfragevolumen den Betriebsaufwand nicht rechtfertigt. Nutzt eine Anwendung bereits ein validiertes kleines Modell für eine feste, eng umrissene Aufgabe, bringt ein zusätzlicher Auswahlmechanismus möglicherweise wenig.

Der erste praktische Schritt: Eine repräsentative Auswahl von Supportfällen exportieren, die zugehörigen Belege festschreiben und das bisherige Modell gemeinsam mit einem kleineren Kandidaten bewerten. Für die Teilmenge, die der kleinere Kandidat besteht, wird eine eng gefasste Routing-Regel formuliert. Ein automatischer Router erhält erst dann Anfragen, wenn er diese Regel bei den Kosten übertrifft und zugleich dieselben Qualitätsanforderungen erfüllt.

Häufige Fragen zum Modell-Routing

Der Newsletter liefert praktische Leitfäden für die Entwicklung und Evaluation von KI-Anwendungen.