Modellrouter: ein Tor, viele KI-Modelle

Ihr baut eine Funktion, die Nutzertexte zusammenfasst. Die meisten Anfragen sind harmlos, ein Dreizeiler reicht. Ab und zu kommt aber ein 40-seitiges Dokument mit verschachtelten Tabellen, das ein starkes Modell braucht. Nehmt ihr für alles das teure Modell, zahlt ihr die Oberklasse auch für die Dreizeiler. Nehmt ihr das billige, scheitert ihr an den harten Fällen.

Genau diese Entscheidung, welches Modell welche Anfrage bekommt, nimmt euch ein Modellrouter ab. Er liegt zwischen eurer Anwendung und den Modellen, schaut sich jede Anfrage kurz an und schickt sie an das Modell, das am besten passt. Nach außen bleibt es eine einzige Adresse, ein API-Format. Dahinter kann sich alles ändern.

Warum es Modellrouter gibt

Kein Modell ist für alles das beste, und der Markt macht das jede Woche deutlicher. Es gibt teure, starke Modelle und billige, schnelle. Es gibt Spezialisten für Code, für Bilder, für sehr lange Kontexte. Modelle fallen aus, laufen in Rate-Limits oder werden über Nacht abgekündigt. Und niemand will seinen Code an einen einzigen Anbieter ketten.

Ein Router löst diese Probleme an einer einzigen Stelle, statt sie in eure Anwendung zu verteilen:

• Kosten pro Aufgabe senken. Die einfachen 80 Prozent der Anfragen laufen auf ein günstiges Modell, nur die harten gehen an die Oberklasse. Das ist derselbe Gedanke wie in Sonnet 5: gleicher Preis, doppelte Realkosten, nur automatisiert.
• Ausfälle abfangen. Antwortet ein Anbieter nicht, geht die Anfrage automatisch an einen zweiten. Eure Nutzer merken nichts.
• Ein API-Format für viele Modelle. Ihr sprecht den Router an, nicht ein Dutzend verschiedene APIs. Ein neues Modell auszuprobieren heißt: eine Zeile Konfiguration ändern, nicht Code umbauen.

Kurz: Der Router trennt die Frage "welches Modell" von eurem Anwendungscode. Das ist der eigentliche Gewinn, die Kostenersparnis ist nur die sichtbarste Folge davon.

Wie Modellrouter arbeiten

Das Prinzip ist immer gleich: Anfrage rein, Modell raus. Interessant wird es bei der Frage, wie der Router entscheidet. Denn die Entscheidung selbst kostet auch etwas, Zeit und manchmal Geld, und je klüger sie sein soll, desto teurer wird sie.

flowchart LR
  A["App<br/>ein API-Format"] --> R["Modellrouter<br/>klassifiziert &amp; entscheidet"]
  R -->|einfache Aufgabe| C["günstiges Modell"]
  R -->|harte Aufgabe| S["starkes Modell"]
  R -->|Bild / Vision| V["multimodales Modell"]
  R -.Ausfall / Rate-Limit.-> F["Fallback-Modell"]
  class R success
  classDef success fill:#14532D,stroke:#22C55E,color:#86EFAC

Für das "wie" haben sich vier Verfahren herausgebildet. Sie schließen sich nicht aus, echte Router kombinieren sie oft.

Die Faustregel dahinter: Je flexibler die Entscheidung, desto mehr kostet sie selbst. Ein LLM-Richter versteht Nuancen, die keine Regel trifft, aber er verdoppelt im schlimmsten Fall die Latenz und einen Teil der Kosten. Ein semantischer Router ist in Millisekunden durch, kann aber nur das erkennen, wofür ihr ihm Beispiele gegeben habt. Deshalb starten die meisten Teams regelbasiert und werden erst dann klüger, wenn die einfachen Regeln nicht mehr reichen.

Vorteile und Nachteile, ehrlich

Ein Router ist kein Selbstläufer. Er löst echte Probleme und schafft neue.

Was er bringt:

• Niedrigere Kosten, weil teure Modelle nur die Anfragen sehen, die sie wirklich brauchen.
• Robustheit, weil Fallbacks Ausfälle einzelner Anbieter überbrücken.
• Beweglichkeit, weil ein Modellwechsel eine Konfigurationsänderung ist, kein Refactoring.
• Weniger Lock-in, weil eure Anwendung nur noch mit dem Router spricht, nicht mit einem bestimmten Anbieter.

Was er kostet:

• Ein neuer Single Point of Failure. Fällt der Router aus, fällt alles aus. Ausgerechnet die Schicht, die Ausfälle abfangen soll, wird selbst zum Risiko, wenn ihr sie nicht redundant auslegt.
• Falsche Entscheidungen. Schickt der Router eine harte Anfrage ans billige Modell, bekommt der Nutzer eine schlechte Antwort, und ihr seht es nicht sofort. Routing-Qualität muss man messen, nicht annehmen.
• Undurchsichtigeres Debugging. Wenn nicht mehr feststeht, welches Modell eine Antwort erzeugt hat, wird Fehlersuche schwerer. Gutes Logging der Routing-Entscheidung ist Pflicht.
• Eine Datenschutzfrage. Bei einem gehosteten Router laufen alle eure Prompts über einen weiteren Anbieter. Wer sieht die Daten, wo werden sie verarbeitet? Für DSGVO-relevante Inhalte ist das eine bewusste Entscheidung, kein Detail. Die Überlegungen aus Digitale Souveränität für KI-Teams gelten hier eins zu eins.

Router aus verschiedenen Bereichen

Routing ist nicht auf Chat-Modelle beschränkt. Es taucht überall dort auf, wo es plötzlich viele austauschbare Modelle gibt.

Gateways für Sprachmodelle. Das ist die sichtbarste Kategorie. OpenRouter bündelt hunderte Modelle hinter einem OpenAI-kompatiblen Format und bietet mit dem Auto Router eine automatische Modellwahl pro Anfrage. LiteLLM ist das verbreitete quelloffene Gegenstück zum Selbsthosten, mit Budgets pro Nutzer und mehreren Routing-Strategien. Portkey und die AI-Gateways von Cloudflare und Kong zielen auf denselben Job, mit unterschiedlichem Schwerpunkt zwischen Managed-Komfort und eigener Infrastruktur.

Quelloffene Verfahren und Forschung. RouteLLM von lm-sys und Anyscale ist weniger Produkt als Baukasten: ein trainierter Klassifikator, der einfache Anfragen ans günstige und harte ans starke Modell schickt. Das Projekt nennt bis zu 85 Prozent Kostenersparnis bei rund 95 Prozent der GPT-4-Qualität, was zeigt, wie viel Spielraum in der Modellwahl steckt. Der vLLM Semantic Router dreht die Frage um: Er entscheidet nicht nur welches Modell, sondern ob eine Anfrage überhaupt aufwändiges Nachdenken braucht.

Generative Medien. Der jüngste Zuwachs kommt aus der Bild- und Video-Ecke. Runway hat im Juli 2026 einen Media Router vorgestellt, der pro Anfrage das passende Bild-, Video- oder Audio-Modell aus einer Reihe von Drittanbietern wählt, je nachdem ob Qualität, Tempo oder Preis zählt. Dasselbe Muster wie bei Text, nur für Pixel und Töne.

Modell-intern. Auch ohne eigenes Werkzeug begegnet euch Routing längst: Mehrere große Anbieter bauen die Modellwahl direkt in ihre Produkte ein und entscheiden im Hintergrund, welche interne Modellvariante eure Anfrage bearbeitet. Ihr routet dann, ohne es zu merken.

Ein einfacher Router zum Anfassen

Man muss keinen Dienst kaufen, um das Prinzip zu verstehen. Ein regelbasierter Router ist ein paar Zeilen Code. Das folgende Beispiel spricht OpenRouter über das OpenAI-kompatible Format an und wählt anhand einer simplen Heuristik zwischen einem günstigen und einem starken Modell.

from openai import OpenAI

client = OpenAI(
    base_url="https://openrouter.ai/api/v1",
    api_key="DEIN_OPENROUTER_KEY",
)

GUENSTIG = "openai/gpt-5.6-luna"
STARK = "anthropic/claude-opus-4.8"

def route(prompt: str) -> str:
    # Simple Regel: lange oder als komplex markierte Aufgaben ans starke Modell
    braucht_stark = len(prompt) > 2000 or "analysiere" in prompt.lower()
    return STARK if braucht_stark else GUENSTIG

def frage(prompt: str) -> str:
    modell = route(prompt)
    antwort = client.chat.completions.create(
        model=modell,
        messages=[{"role": "user", "content": prompt}],
    )
    print(f"[Router] -> {modell}")
    return antwort.choices[0].message.content

Das ist bewusst naiv: Textlänge und ein Stichwort sind eine grobe Heuristik. Aber es zeigt den Kern, eine Entscheidung vor dem Modellaufruf, und es ist der Punkt, an dem in echten Systemen die Verfahren aus der Tabelle oben ansetzen.

Wer die Entscheidung nicht selbst treffen will, überlässt sie dem Anbieter. OpenRouters Auto Router übernimmt genau diesen Schritt und lässt sich über einen einzigen Regler steuern:

antwort = client.chat.completions.create(
    model="openrouter/auto",          # Router wählt das Modell
    messages=[{"role": "user", "content": prompt}],
    extra_body={"cost_quality_tradeoff": 7},  # 0 = max. Qualität, 10 = min. Kosten
)

Der cost_quality_tradeoff reicht von 0 bis 10 (Standard 7): 0 nimmt immer das fähigste Modell, 10 immer das günstigste. Ein zusätzlicher Aufpreis für den Router fällt laut OpenRouter nicht an, ihr zahlt den regulären Preis des gewählten Modells.

Ein lauffähiges Mini-Beispiel mit beiden Varianten (eigener Regel-Router und Auto Router) liegt als Repository bereit: github.com/pcornelissen/kiberblick-modellrouter-demo. Klonen, eigenen Key eintragen, ausprobieren.

Lohnt sich ein Router für euch?

Ehrlich eingeordnet: Nicht jedes Projekt braucht einen. Wer ein Modell für einen klar umrissenen Zweck nutzt und mit dessen Kosten gut lebt, holt sich mit einem Router vor allem zusätzliche Komplexität ins Haus.

Interessant wird es an drei Stellen. Erstens bei Volumen: Wenn ihr täglich tausende Anfragen fahrt, zahlt sich das Trennen von einfach und schwer schnell aus. Zweitens bei Verfügbarkeit: Wenn ein Ausfall eures Anbieters euch weh tut, sind Fallbacks Gold wert. Drittens bei Wahlfreiheit: Wenn ihr Modelle regelmäßig vergleichen oder wechseln wollt, ist ein Router die Schicht, die das schmerzfrei macht.

Und ein DSGVO-Gedanke zum Schluss: Ein selbstgehosteter Router wie LiteLLM kann Anfragen sogar an ein lokales Modell leiten, wenn sensible Daten im Spiel sind, und nur den unkritischen Rest an externe Anbieter. So wird aus dem Router nicht nur ein Kostenwerkzeug, sondern ein Baustein für Datensparsamkeit. Wie lokale Modelle das ergänzen, steht in Ollama: KI lokal und DSGVO-konform nutzen.