KI-Model-Routing – das passende LLM pro Anfrage wählen

In vielen GenAI-Projekten entsteht früh ein Muster: Ein großes LLM wird „für alles“ genutzt – von kurzen E-Mail-Entwürfen bis zur juristisch heiklen Formulierung. Das ist einfach zu integrieren, aber im Betrieb oft unnötig teuer, zu langsam oder in sensiblen Fällen zu riskant. KI-Model-Routing löst dieses Dilemma: Anfragen werden anhand definierter Signale an ein passendes Modell (oder an einen passenden Modus desselben Modells) geleitet.

Der Kernnutzen liegt in einer kontrollierten Varianz: leichte Aufgaben laufen über günstige, schnelle Modelle; anspruchsvolle Aufgaben bekommen mehr Kontext, bessere Reasoning-Fähigkeiten oder strengere Sicherheitsmechanismen. Entscheidend ist, dass Routing nicht „magisch“ passiert, sondern als überprüfbarer, auditierbarer Teil der KI-Architektur umgesetzt wird.

Wann Model-Routing den größten Unterschied macht

Routing ist kein Selbstzweck. Es lohnt sich vor allem, wenn die Anfragen im Alltag stark variieren – etwa zwischen kurzen Chat-Nachfragen, strukturierten Extraktionen und fachlich sensiblen Texten. Ein einheitliches Modell wird dann zwangsläufig in mindestens einer Dimension suboptimal sein: Preis, Geschwindigkeit oder Ergebnisqualität.

Typische Einsatzmuster in Unternehmen

• Cost-Aware Inference: Standardfälle laufen über günstige Modelle; nur „harte“ Fälle eskalieren.
• Latenz-Steuerung: Interaktive UI-Anfragen werden priorisiert schnell beantwortet, Batch-Aufgaben dürfen länger dauern.
• Sicherheits- und Compliance-Differenzierung: Sensible Inhalte werden über abgesicherte Modelle/Umgebungen verarbeitet (z. B. mit strengeren Policies oder isolierter Infrastruktur).
• Aufgaben-Spezialisierung: Extraktion/Parsing, Übersetzung, Zusammenfassung oder Code-Review können je nach Modellfamilie unterschiedliche Stärken haben.

Erkennbares Symptom: „Wir zahlen für Premium bei jeder Kleinigkeit“

Wenn Teams anfangen, Prompts zu „verkürzen“, Kontext wegzulassen oder Ausgaben aggressiv zu beschneiden, nur um Kosten zu senken, ist häufig nicht der Prompt das Problem, sondern die fehlende Differenzierung nach Anfrageklasse. Routing erlaubt, Qualität dort zu investieren, wo sie wirklich benötigt wird.

Welche Signale sich fürs Routing eignen

Die Praxis steht und fällt mit robusten Signalen. Idealerweise sind sie stabil, nachvollziehbar und schwer zu „umgehen“. In vielen Setups ergibt sich eine Kombination aus expliziten (vom Produkt vorgegebenen) und impliziten (aus dem Request abgeleiteten) Signalen.

Explizite Signale: Produkt- und Prozesskontext

• Use-Case-Klasse: z. B. „Customer Support“, „Sales Enablement“, „HR“, „Engineering“.
• Kanal: Chat-UI, E-Mail-Composer, API, Batch-Job.
• Interaktionsmodus: „Entwurf“, „final“, „intern“, „extern“ (für Tonalität und Risiko).
• Tenant/Team: unterschiedliche Policies, Budgets oder Qualitätsprofile.

Implizite Signale: Eigenschaften der Anfrage

• Textlänge und erwartete Antwortlänge (grobe Token-Schätzung).
• Sprache(n), Formatvorgaben (JSON, Tabelle, Bulletpoints).
• Komplexitätshinweise: mehrere Anforderungen, widersprüchliche Constraints, umfangreiche Regeln.
• Risikohinweise: potenziell personenbezogene Daten, Vertrags- und Rechtsbezug, medizinische Inhalte, sicherheitskritische Handlungen.

Wichtig: Risikohinweise sollten nicht allein aus dem LLM kommen. Ein zusätzlicher, deterministischer Vorfilter (Regeln/Classifier) erhöht die Vorhersagbarkeit. Bei personenbezogenen Daten kann ergänzend eine vorgelagerte Redaktionsstrecke sinnvoll sein, siehe PII-Redaktion vor GenAI.

Routing-Strategien: von Regeln bis zu lernenden Gateways

Model-Routing hat mehrere Reifegrade. Eine gute Architektur erlaubt, mit einfachen Regeln zu starten und später datengetrieben zu verfeinern, ohne das Gesamtsystem umzubauen.

Regelbasiertes Routing (Startpunkt mit hoher Kontrolle)

Regeln sind ideal, um sofort Wirkung zu erzielen: nachvollziehbar, auditierbar, schnell implementiert. Beispiele: „Wenn Antwortformat = JSON und Aufgabe = Extraktion, dann Modell A“, oder „Wenn Anfrage sensible Kategorie, dann nur Modell B in isolierter Umgebung“.

Grenze: Regeln skalieren schlecht, wenn zu viele Sonderfälle entstehen. Dann drohen „Policy-Spaghetti“ und unklare Verantwortlichkeiten.

Stufenmodell mit Eskalation („günstig zuerst, stark wenn nötig“)

Ein sehr praxistauglicher Ansatz ist ein mehrstufiger Ablauf: Erst versucht ein günstiges Modell die Aufgabe. Wenn definierte Qualitäts- oder Sicherheitskriterien nicht erfüllt sind, erfolgt eine Eskalation zu einem stärkeren Modell. Das reduziert Kosten, ohne die „Worst-Case“-Qualität zu verlieren.

Der entscheidende Punkt ist das Eskalationssignal: Es muss möglichst zuverlässig sein. Übliche Signale sind Validierungsfehler (Format), Unvollständigkeit, niedrige Selbstkonsistenz oder eine nachgelagerte Qualitätsprüfung über Heuristiken.

Lernendes Routing (nur mit sauberer Messung)

Datengetriebene Router (Classifier oder kleine LLMs als „Gate“) können später feinere Entscheidungen treffen als Regeln. Sie brauchen jedoch eine klare Zielgröße: Was bedeutet „besser“ – günstiger, schneller, genauer, sicherer? Ohne belastbare Evaluierung wird lernendes Routing schnell zum Blindflug. Für eine strukturierte Teststrategie hilft LLM-Evaluierung im Unternehmen.

Entscheidungskriterien: Qualität, Kosten, Latenz, Risiko

Damit Routing nicht zur dauerhaften Debatte wird, sollten Kriterien operationalisiert werden. „Qualität“ allein ist zu vage; praktikabel sind mess- und beobachtbare Indikatoren.

Messbare Qualitätsindikatoren pro Anfrageklasse

• Format-Compliance: stimmt JSON/Schema, sind Pflichtfelder vorhanden?
• Fakten-Treue zum bereitgestellten Kontext (wenn Kontext vorliegt).
• Aufgabenabdeckung: wurden alle Teilfragen beantwortet?
• Stilvorgaben: Tonalität, Länge, interne/externe Form.

Für strukturierte Use Cases lohnt ein fester Prüfschritt (Parser, Schema-Validator, Regex-Checks). Je deterministischer die Prüfungen, desto verlässlicher ist die Eskalationslogik.

Kosten- und Latenzsicht, ohne in Scheinpräzision zu geraten

Im Betrieb zählt nicht nur „Preis pro Token“, sondern die End-to-End-Kette: Vorverarbeitung, Guardrails, eventuelles Nachfragen, Retries und Postprocessing. Routing sollte daher auf Service-Level-Zielen basieren, etwa „p95-Latenz für UI-Anfragen“ und „Budget pro 1.000 Requests“ – ohne unprüfbare Zahlenversprechen. Ergänzend ist ein kontrolliertes Last- und Kostenmanagement relevant, siehe Workload-Management für LLM-Last.

Risikosteuerung als eigenes Routing-Ziel

Viele Unternehmen unterschätzen, dass „bestes Modell“ nicht automatisch „sicherstes Setup“ bedeutet. Risiko entsteht auch durch Kontext, Datenquellen, Tool-Zugriffe und Ausgabekanäle. Routing kann hier gezielt trennen: Modelle ohne Tool-Zugriff für offene Fragen, Modelle mit streng begrenzten Tools für operative Aktionen, und besonders restriktive Pfade für sensible Inhalte.

Praktische Umsetzung: Router als Produkt- und Plattform-Baustein

Ein Router ist mehr als eine if-else-Kette. Er ist ein Baustein, der Policies, Observability und Versionierung braucht. Technisch kann er als eigener Service (Gateway) oder als Bibliothek in einem API-Layer umgesetzt werden. Wichtig ist, dass Entscheidungen protokolliert und später erklärbar sind.

Welche Daten in Logs gehören (und welche nicht)

Für Betrieb und Verbesserung sind Router-Logs zentral: gewählte Route, Gründe/Features, Modellversion, Latenzen, Abbruch/Eskalation, Validator-Ergebnisse. Sensible Nutzdaten sollten nur minimiert oder redigiert geloggt werden. Datenminimierung ist auch hier ein Leitprinzip, siehe Datenminimierung für GenAI.

Versionierung: Routing-Regeln sind produktkritisch

Routing-Änderungen beeinflussen Ausgabequalität und Kosten sofort. Deshalb gehören Router-Regeln und -Modelle in eine kontrollierte Auslieferung: Versionen, Rollback, Freigaben und schrittweise Aktivierung. Falls Feature-Toggles bereits etabliert sind, kann das Routing darüber gezielt ausgerollt werden, siehe Feature-Flags für GenAI.

Ein kompakter Ablauf für den Start in zwei Wochen

Der Einstieg gelingt am besten mit einem klar begrenzten Scope: ein Produkt, zwei bis drei Anfrageklassen, zwei Modelle. Das Ziel ist nicht maximale Eleganz, sondern ein stabiler Betrieb mit messbaren Effekten.

Schrittfolge für ein erstes, belastbares Routing

• 2–3 Anfrageklassen definieren (z. B. „kurz“, „strukturiert“, „sensibel“) und pro Klasse Abnahmekriterien festlegen.
• Pro Klasse ein Standardmodell auswählen und ein Eskalationsmodell bestimmen.
• Deterministische Validatoren ergänzen: Schema/Format, Pflichtfelder, einfache Policy-Checks.
• Routing-Regeln als Version artefaktisieren (Konfiguration), inklusive Rollback.
• Observability einbauen: Route, Validator-Status, Latenz, Retry/Eskalation, Fehlerkategorien.
• Mit kleinem Traffic starten, anschließend schrittweise erhöhen und die Regeln pro Woche nachschärfen.

Typische Fehlerbilder und wie sie sich vermeiden lassen

Viele Routing-Probleme wirken anfangs wie „LLM-Qualität“, sind aber Systemeffekte. Wer die häufigsten Fehler kennt, spart Wochen in Debugging und Stakeholder-Diskussionen.

Fehlerbild: Der Router optimiert nur für Kosten

Wird primär auf günstige Modelle geroutet, steigen Retries, Nachfragen und manuelle Korrekturen. Das verschiebt Kosten lediglich in andere Bereiche. Abhilfe: Qualitäts-Gates pro Klasse, Eskalation bei Validierungsfehlern und getrennte SLOs je Kanal.

Fehlerbild: Regeln werden unwartbar

Wenn jede Abteilung eigene Sonderlogiken ergänzt, wird das Routing intransparent. Abhilfe: wenige, stabile Features; klare Ownership; regelmäßige Bereinigung; und ein Prozess, der neue Regeln nur mit Testfällen zulässt.

Fehlerbild: „Smartes“ Routing ohne Testset

Ein lernender Router ohne repräsentative Tests führt zu Drift: In seltenen, aber kritischen Fällen wird falsch geroutet. Abhilfe: kuratierte Beispiele pro Anfrageklasse, Regressionstests bei Regeländerungen und eine rote Liste für sensible Fälle, die immer in restriktive Pfade laufen.

Vergleich: Ein Modell vs. mehrere Modelle mit Router

Wie sich Routing langfristig „gesund“ halten lässt

Nach dem Go-live ist Routing ein lebendes System. Neue Modelle, neue Produktfunktionen und verändertes Nutzerverhalten verschieben die optimale Aufteilung. Daher braucht es eine Routine, die Änderungen datenbasiert erlaubt, ohne die Nutzererfahrung zu destabilisieren.

Wartungsprinzipien für Router und Modellportfolio

• Regelmäßige Regressionen auf einem festen, internen Beispielsatz pro Anfrageklasse.
• Transparente Route-Entscheidungen (Reason Codes), damit Support und Produktteams Fehler einordnen können.
• Klare Deprecation-Strategie: alte Modelle und Routen planbar abschalten.
• Explizite Budgets und SLOs pro Kanal statt „ein Budget für alles“.

Richtig umgesetzt verbindet Routing technische Disziplin (Policies, Tests, Logs) mit pragmatischer Produktsteuerung. Das Ergebnis sind Systeme, die sich an reale Anforderungen anpassen, ohne Kosten und Risiken unkontrolliert wachsen zu lassen.