LLM-Router: Anfragen routen, Kosten um 60 % senken [2026]

LLM-Router: Anfragen routen, Kosten um 60 % senken [2026]

Ein LLM-Router ist eine schlanke Schicht zwischen Ihrer App und mehreren Sprachmodellen, die entscheidet, welches Modell jede Anfrage bearbeitet. Er prüft die Anfrage (Aufgabentyp, Komplexität, Token-Budget), leitet sie an das passendste Modell weiter und wechselt bei einem Fehler auf ein Backup-Modell. Das Ziel: passend dimensionierte Antworten zu den niedrigsten Token-Kosten.

Ein Frontier-Modell für die Antwort auf „Wie lautet eure Rückgaberichtlinie?" zu bezahlen, treibt die Rechnung in die Höhe. AWS hat die Alternative im April 2025 gemessen: Ein Classifier-Router fügt 0,53 Sekunden Latenz hinzu, ein semantischer Router 0,10 Sekunden, und bis zu 30 % weniger Rechnung beim Routing innerhalb einer Modellfamilie. Rechnet man das mit den Listenpreisen vom Juli 2026 über mehrere Anbieter nach, wie wir es unten tun, erreicht die Einsparung 70 %. Der Großteil der Ersparnis stammt aus einer einzigen Entscheidung, getroffen bevor ein einziges Token erzeugt wird.

Die wichtigsten Erkenntnisse

• Ein LLM-Router entscheidet, welches Modell jede Anfrage bearbeitet, basierend auf Aufgabentyp, Kosten oder gemessener Qualität.
• Es gibt fünf Strategien: regelbasiert, kostenbewusst, latenzbewusst, semantisch (Embeddings) und LLM-Classifier-Routing.
• Regelbasiertes Routing fügt ~0 ms und 0 $ hinzu; Classifier-Routing fügt 300–800 ms plus Classifier-Token-Kosten pro Anfrage hinzu.
• Routing kann die Token-Ausgaben um bis zu 60 % senken, wenn der Großteil des einfachen Traffics auf ein 10- bis 20-mal günstigeres Modell wandert.
• Ein einzelner Anbieter, unter 10.000 Anfragen pro Tag, kein Kostendruck? Überspringen Sie den Router. Einfache Fallbacks genügen.

Was macht ein LLM-Router tatsächlich?

Ein LLM-Router führt vor jedem Modellaufruf einen kleinen Entscheidungsschritt aus: Anfrage lesen, gegen eine Routing-Regel bewerten, ein Modell wählen, den Aufruf senden und bei einem Fehler des ersten Modells auf einem Fallback wiederholen. An Ihrer App ändert sich sonst nichts. Sie stellen weiterhin eine Anfrage und erhalten eine Antwort zurück.

Der Request-Lebenszyklus, der Reihe nach:

1. Anfrage trifft ein am Router-Endpunkt, genau wie bei einer Modell-API.
2. Analysieren. Der Router prüft den Prompt: Schlüsselwörter, Token-Anzahl, ein Embedding oder ein Classifier-Score.
3. Auswählen. Die Routing-Strategie bildet dieses Signal auf eine Modell-Stufe ab (günstig, mittel, Frontier oder lokal).
4. Weiterleiten. Der Aufruf geht über eine OpenAI-kompatible API an das gewählte Modell.
5. Fallback. Bei Timeout, Rate-Limit oder Fehler wiederholt die Anfrage auf der nächsten Stufe in der Kette.

Nutzer suchen nach „llm gateway vs router", weil die Anbieter-Docs die Begriffe verwischen. Ein Satz klärt das: Das Gateway ist die Leitung; der Router ist die Entscheidung. Es sind Schichten, keine Konkurrenten, und die meisten Gateways betten einen Router ein.

Laut der LiteLLM-Dokumentation betreibt derselbe Proxy, der Ihre virtuellen Keys verwaltet, auch den Router. Sie vergleichen speziell die Tools auf Leitungsebene? Unser Überblick über die besten LLM-Gateway-Tools rankt zehn davon.

Brauchen Sie überhaupt einen LLM-Router?

Die meisten kleinen Apps brauchen keinen. Ein Router lohnt sich, wenn sich der Traffic in klar unterschiedliche Aufgabentypen aufteilt, wenn die Token-Rechnung Ihr größter Infrastrukturfaktor ist oder wenn Sie mehr als einen Anbieter betreiben und Failover brauchen. Unterhalb dieser Schwellen kaufen Ihnen einfache Retries plus ein Fallback-Modell die Zuverlässigkeit ohne das bewegliche Teil.

Wir sagen es offen, weil es sonst niemand in diesem Bereich tut: Wenn Sie einen einzelnen Anbieter mit unter 10.000 Anfragen pro Tag betreiben, ist ein Router Overhead, den Sie nicht brauchen. Einfache Fallbacks gewinnen.

Warum so offen? Jede Route ist eine Behauptung („diese Aufgabenklasse ist auf dem günstigen Modell sicher"), die zerfällt, wenn sich Modelle, Preise und Ihr Produkt ändern. Kaufen Sie diese Wartungskosten nur, wenn die Einsparungen sie klar schlagen.

Die 5 LLM-Routing-Strategien (und wann Sie welche nutzen)

Jede LLM-Routing-Strategie beantwortet eine Frage: Welchem Signal vertrauen Sie genug, um ein Modell zu wählen? Regeln vertrauen Schlüsselwörtern. Kosten-Routing vertraut dem Token-Budget. Latenz-Routing vertraut einem Timer. Semantisches Routing vertraut Embeddings. Classifier-Routing vertraut einem anderen LLM. Der Tradeoff hat immer dieselbe Form: mehr Signalqualität, mehr zusätzliche Latenz und Kosten pro Anfrage.

Die Autovervollständigung schlägt diese als „llm routing strategies", „llm task routing", „llm intent routing" und „llm dynamic routing" vor. Sie bilden fünf Muster ab:

Ein Muster zieht sich durch alle fünf: die Kaskade, auch Model-Tiering genannt. Starten Sie günstig und eskalieren Sie nur bei Fehler oder niedriger Konfidenz. Ein Support-Bot antwortet von einem 0,25-$-pro-Million-Token-Modell; fällt seine Konfidenz unter 0,7, wiederholt dieselbe Anfrage auf einem Frontier-Modell. Sie zahlen nur dann für Intelligenz, wenn die günstige Stufe zugibt, dass sie feststeckt.

Für akademische Tiefe: Die LLMRouter-Bibliothek von ulab-uiuc katalogisiert 16+ erforschte Routing-Algorithmen (KNN, SVM, MLP, Matrixfaktorisierung, Elo, Graph und BERT-artige). Wenn semantisches Routing Ihre Wahl ist, entscheiden die Beispiel-Embeddings fast alles; unser Leitfaden zu den besten Embedding-Modellen deckt ab, welche auf echten Korpora bestehen.

Wie baut man einen LLM-Router in Python?

Sie bauen einen mit etwa 80 Zeilen schlichtem Python gegen jeden OpenAI-kompatiblen Endpunkt. Kein Framework nötig. Die vier Router unten steigen im Anspruch: Schlüsselwort-Regeln, eine Kosten-Schwelle, Embedding-Ähnlichkeit und ein Classifier-Modell mit Failover. Jeder gibt das gewählte Modell aus, damit Sie die Entscheidung live beobachten können.

Wenn Sie nach „how to build an llm router" gesucht haben und nur AWS-CDK-Stacks und akademische Repos fanden, ist dieser Abschnitt die schlichte Antwort. Die Referenzimplementierung von AWS ist solide, aber an Bedrock, Lambda und CDK geschweißt. Unsere läuft überall dort, wohin der OpenAI-Client zeigt: OpenAI, Anthropic über einen Proxy, Ollama auf einem Laptop, vLLM auf einer GPU-Maschine. Hier ist der Router, den wir für Kunden zuerst skizzieren.

Schritt 1: Regelbasierter Router (Schlüsselwörter zu Modellen)

Die Null-Latenz-Basislinie. Eine Regex-Map entscheidet; alles ohne Treffer geht an die Frontier-Stufe.

import re
from openai import OpenAI

client = OpenAI()  # works with OpenAI, Ollama, vLLM, or a LiteLLM proxy

def ask(model: str, prompt: str) -> str:
    r = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
    )
    return r.choices[0].message.content

ROUTES = [
    (re.compile(r"\b(refund|cancel|invoice|password|hours)\b", re.I), "gpt-5-mini"),
    (re.compile(r"\b(summarize|translate|rewrite)\b", re.I), "gpt-5-mini"),
]
FRONTIER = "gpt-5"

def rule_router(prompt: str) -> str:
    for pattern, model in ROUTES:
        if pattern.search(prompt):
            return model
    return FRONTIER

prompt = "How do I cancel my subscription?"
model = rule_router(prompt)
print(model)  # gpt-5-mini: regex hit on "cancel"
print(ask(model, prompt))

Eingabe: eine Support-Frage. Entscheidung: Regex-Treffer auf „cancel". Gewähltes Modell: gpt-5-mini. Kein API-Aufruf nötig, um es zu routen, deshalb bleibt das der Standard.

Schritt 2: Kostenbewusster Router (Token-Budget-Schwelle)

Dieselbe Idee, aber das Signal ist die Anfragegröße statt Schlüsselwörter. Kurze Prompts mit kleinem Output-Budget gehen günstig; alles andere geht an Frontier.

def cost_router(prompt: str, max_output_tokens: int = 500) -> str:
    word_count = len(prompt.split())
    if word_count < 60 and max_output_tokens <= 300:
        return "gpt-5-mini"  # $0.25 in / $2 out per M tokens
    return "gpt-5"           # $1.25 in / $10 out per M tokens

prompt = "Write a two-line product description for a ceramic mug."
model = cost_router(prompt, max_output_tokens=120)
print(model)  # gpt-5-mini: short prompt, small output budget

Grob? Ja. Effektiv? Ebenfalls ja, denn das Token-Volumen korreliert besser mit der Aufgabengröße, als die meisten erwarten. Das ist die gesamte Strategie hinter mehreren bezahlten „cheap llm router"-Produkten.

Schritt 3: Semantischer Router (Embeddings zu Beispielen)

Für vage Nutzereingaben, die Schlüsselwörtern ausweichen, betten Sie den Prompt ein und vergleichen ihn mit eingebetteten Beispiel-Prompts. Welcher Cluster am nächsten liegt, dem gehört die Anfrage.

import numpy as np

EXEMPLARS = {
    "gpt-5-mini": [
        "classify this support ticket into a category",
        "extract the shipping address from this email",
    ],
    "gpt-5": [
        "debug this race condition in our worker pool",
        "design a multi-tenant billing schema",
    ],
}

def embed(texts: list[str]) -> np.ndarray:
    r = client.embeddings.create(model="text-embedding-3-small", input=texts)
    return np.array([d.embedding for d in r.data])

CENTROIDS = {m: embed(xs).mean(axis=0) for m, xs in EXEMPLARS.items()}

def semantic_router(prompt: str) -> str:
    v = embed([prompt])[0]
    scores = {
        m: float(np.dot(v, c) / (np.linalg.norm(v) * np.linalg.norm(c)))
        for m, c in CENTROIDS.items()
    }
    return max(scores, key=scores.get)

print(semantic_router("pull the tracking number out of this message"))
# gpt-5-mini: closest to the extraction exemplars

Der Routing-Aufruf kostet ein Embedding (ein paar hundert Tokens) und 50–150 ms. Berechnen Sie die Zentroide beim Start vor, nicht pro Anfrage.

Schritt 4: LLM-Classifier-Router mit Fallback

Das stärkste Signal: Ein günstiges Modell liest den Prompt und bewertet seine Schwierigkeit. Das ist die Strategie, die AWS mit 0,53 Sekunden zusätzlicher Latenz gemessen hat, also verpacken wir sie in eine Fallback-Kette.

def classify_router(prompt: str) -> str:
    verdict = client.chat.completions.create(
        model="gpt-5-mini",
        messages=[{"role": "user", "content":
            "Reply HARD or EASY only. Task: " + prompt}],
        max_tokens=5,
    ).choices[0].message.content.strip().upper()
    return "gpt-5" if verdict.startswith("HARD") else "gpt-5-mini"

def route_and_call(prompt: str) -> str:
    model = classify_router(prompt)
    try:
        return ask(model, prompt)
    except Exception:
        backup = "gpt-5-mini" if model == "gpt-5" else "gpt-5"
        return ask(backup, prompt)  # fallback tier catches the failure

print(route_and_call("Prove this greedy algorithm is optimal."))
# classifier says HARD, so gpt-5 answers

Das ist das gesamte LLM-Router-Beispiel: vier Funktionen, ein Client, keine Infrastruktur über das hinaus, was Sie bereits betreiben. Production-Härtung ist der nächste Abschnitt.

Wie viel spart LLM-Routing tatsächlich?

AWS hat den Router-Overhead mit 107,90–188,90 $ pro Monat pro 100.000 Fragen pro Tag gemessen, wobei Classifier-Routing 0,53 Sekunden pro Anfrage hinzufügt und semantisches Routing 0,10 Sekunden. Die Sparseite übertrifft diesen Overhead bei Weitem. Unser Rechenbeispiel unten, aufgebaut auf den Listenpreisen vom Juli 2026, landet bei 70,7 % Ausgabenreduktion. Der Haken ist der Traffic-Mix: Sie brauchen die Mehrheit der Anfragen, die sich für die günstige Stufe qualifizieren.

Zwei Tabellen. Zuerst, was Sie der Router selbst pro 1.000 Anfragen kostet:

Der AWS-Beitrag vom April 2025 ist die einzige unabhängig veröffentlichte Messreihe in diesem Bereich, also verankern wir uns daran und kennzeichnen unsere Erweiterungen als Schätzungen, nicht als Zahlen, die wir selbst erhoben haben. Bedrock Intelligent Prompt Routing senkte die Kosten innerhalb einer Familie um bis zu 30 %, laut AWS.

Zweitens, das Rechenbeispiel zur Einsparung, das unsere Schlagzeile stützt:

Annahmen, gekennzeichnet: 100.000 Anfragen pro Monat; 800 Input- plus 200 Output-Tokens pro Anfrage im Durchschnitt; eine 80-%-einfach- / 20-%-komplex-Aufteilung; Listenpreise von der Anthropic-Preisseite und der OpenAI-Preisseite Stand Juli 2026, mit der vollständigen Preistabelle in unserem LLM-API-Preisvergleich. Rechnung pro Anfrage: Sonnet 4 kostet 800 x 3 $/Mio. + 200 x 15 $/Mio. = 0,0054 $; GPT-5 mini kostet 800 x 0,25 $/Mio. + 200 x 2 $/Mio. = 0,0006 $.

Das Ergebnis ist eine Reduktion um 70,7 %, daher stammen die 60 % in unserem Titel, mit reichlich Puffer. Ehrliche Einschränkungen: Das ist ein Rechenbeispiel, kein Benchmark, den wir gefahren haben. Es setzt voraus, dass Ihre günstige Stufe 10- bis 20-mal billiger ist und dass sich 80 % des Traffics wirklich qualifizieren. Routing innerhalb einer Familie, das AWS-Szenario, bleibt nahe 30 %. Und Routing ist ein Hebel unter vielen; Prompt-Caching und -Kürzen zahlen sich oft schneller aus, und unser Leitfaden zu Wegen, die LLM-API-Kosten zu senken, rankt alle zwölf.

Production-Routing-Muster

Ein Spielzeug-Router wählt ein Modell. Ein Production-Router wiederholt auch, balanciert Last, cached Wiederholungen und isoliert API-Keys pro Team. Ab ein paar tausend Anfragen pro Tag hören Sie auf, das von Hand zu bauen, und betreiben ein Gateway, das einen Router einbettet.

Die vier Muster, die zählen:

• Fallback-Ketten. Günstige Stufe zuerst, Frontier bei Fehler oder Timeout. Das einzelne Muster mit dem höchsten Wert; der Großteil Ihrer Zuverlässigkeit kommt allein daher.
• Load-Balancing. Verteilen Sie Aufrufe auf doppelte Deployments oder API-Keys, um Rate-Limits pro Key zu umgehen.
• Response-Caching. Identische Prompts geben gecachte Antworten zurück. Support-Traffic wiederholt sich mehr, als man glaubt; 10–30 % Trefferquoten sind üblich.
• Virtuelle Keys und Budgets. Geben Sie Keys pro Team mit monatlichen Caps aus, damit eine durchgegangene Schleife nicht die ganze Rechnung abfackelt.

Das kommt der Konfiguration nahe, die wir auf unserem Staging-Agent-Stack betreiben (Datei: litellm-router.yaml, in den LiteLLM-Proxy-Container gemountet):

model_list:
  - model_name: cheap
    litellm_params:
      model: openai/gpt-5-mini
  - model_name: frontier
    litellm_params:
      model: anthropic/claude-opus-5

router_settings:
  routing_strategy: simple-shuffle
  fallbacks: [{"cheap": ["frontier"]}]
  num_retries: 2
  timeout: 30

Wo jedes Tool passt, mit Meinung:

• LiteLLM. Wählen, wenn Sie selbst gehostet und Open Source wollen und bereits Docker betreiben. Unser LiteLLM-Proxy-Einrichtungsleitfaden geht das volle Deployment durch, Keys und Budgets inklusive.
• OpenRouter. Wählen, wenn Sie hunderte Modelle hinter einem Key und null Betrieb wollen. Deren Rankings-Seite dient doppelt als Durchsatz-Datenquelle.
• Portkey. Wählen, wenn Enterprise-Anforderungen (SSO, Audit-Logs, Compliance-Berichte) die Entscheidung treiben.
• Eigener Code aus diesem Beitrag. Wählen, wenn Sie unter ~50.000 Anfragen pro Tag liegen und null neue Infrastruktur wollen.

Wofür Sie sich auch entscheiden, der Überblick über die LLM-Gateway-Tools vergleicht zehn davon direkt miteinander.

Kann man zwischen lokalen Modellen und gehosteten APIs routen?

Ja, und die Token-Rechnung ist verlockend: Ein lokales Modell berechnet 0 $ pro Token, also ist jede Anfrage, die Ollama oder vLLM beantwortet, reine Ersparnis. Der Tradeoff ist Latenz und Qualität pro Watt. Lokal gewinnt bei volumenstarken einfachen Aufgaben auf Hardware, die Sie bereits besitzen; die gehostete API fängt alles ab, was ein Frontier-Gehirn braucht.

Die Mechanik ist unspektakulär, und genau das ist der Punkt. Ollama stellt einen OpenAI-kompatiblen Endpunkt unter localhost:11434/v1 bereit, und vLLM serviert dieselbe Form. Damit funktioniert jeder Router oben unverändert: Zeigen Sie mit base_url auf den lokalen Server, stecken Sie qwen3:8b in den günstigen Slot und behalten Sie gpt-5 als Fallback-Stufe. Für eine selbst gehostete Router-Maschine wird LiteLLM als Docker-Image ausgeliefert, das ist das „llm router docker"-Setup, nach dem Nutzer suchen.

Zwei Ehrlichkeits-Hinweise. Ein 70B-Modell auf einer A100 serviert grob 30–40 Tokens pro Sekunde; gehostete APIs schlagen das beim Burst-Durchsatz, also passt lokales Routing besser zu stetigem Hintergrund-Traffic als zu spitzenlastigem Nutzer-Chat. Und lokale 8B-Modelle stolpern bei mehrstufigen Tool-Aufrufen, also halten Sie die harten Routen auf die Cloud gerichtet. Wenn Sie die Serving-Engine selbst wählen, benchmarkt vLLM vs SGLang die beiden.

Routing treibt auch Multi-Modell-Coding-Agent-Setups an. Ein LiteLLM-artiger Proxy lässt Claude Code über einen Endpunkt mit lokalen und gehosteten Modellen sprechen; siehe verschiedene Modelle in Claude Code nutzen für die genaue Verdrahtung.

Woran erkennen Sie, dass Routing funktioniert?

Sie messen es, oder Sie raten. Loggen Sie, welches Modell jede Anfrage beantwortet hat, bewerten Sie eine Stichprobe der Outputs gegen einen Rubrik und speisen Sie die Scores zurück in die Routing-Regeln. Teams, die diesen Schritt auslassen, landen bei einer statischen Konfiguration, die still vor sich hin fault, während sich Modelle und Preise darunter ändern.

Der Reifepfad läuft über Regeln, dann Kosten, dann gemessene Qualität:

1. Route loggen. Speichern Sie das gewählte Modell, Latenz und Token-Anzahlen pro Anfrage als eine Spalte in Ihren bestehenden Traces.
2. Outputs wöchentlich bewerten. Ein LLM-Judge oder eine menschliche Stichprobe, Bestanden/Nicht-bestanden pro Anfragenklasse. Fünfzig bewertete Outputs pro Klasse genügen zum Steuern.
3. Nachjustieren. Wenn die günstige Stufe 95 %+ in einer Klasse besteht, weiten Sie ihre Regel, um mehr von diesem Traffic zu fangen. Fällt sie unter 90 %, verengen.

Hier ist der Satz, den wir Kunden gegenüber ständig wiederholen: Ein Router, den Sie nie nachjustieren, ist nur eine statische Konfiguration mit extra Latenz. Loggen Sie das gewählte Modell, bewerten Sie Outputs, speisen Sie Scores zurück.

Diese Schleife ist Evals plus Observability, angewendet auf Routing. Unser LLM-Evals-Leitfaden deckt die Bewertungs-Rubriken ab; der KI-Observability-Leitfaden deckt ab, wo die Traces liegen.

Wohin entwickelt sich die LLM-Routing-Forschung?

Die akademische Linie behandelt Routing als Lernproblem, nicht als Konfigurationsdatei. LLMRouter von ulab-uiuc, die Bibliothek, die für dieses Keyword auf Platz eins rankt, implementiert 16+ Algorithmen (KNN, SVM, MLP, Matrixfaktorisierung, Elo, Graph, BERT und RL-Router) mit einer Benchmark-Pipeline über 11 Datensätze. Das meistzitierte aktuelle Paper, RouteLLM (Ong et al., arXiv:2406.18665), trainiert Router auf menschlichen Präferenzdaten und berichtet über 2-mal Kostenreduktion ohne Qualitätsverlust auf MMLU und MT-Bench. Die neueste Wendung: Prefill-Aktivierungs-Router, die „Prefill is all you need"-Linie, die die internen Aktivierungen eines Modells während des Prefill liest, um die Schwierigkeit vorherzusagen, bevor die Generierung startet. Die Richtung der Reise sind Router, die sich selbst aus Ihren Eval-Daten trainieren, was genau die Feedback-Schleife aus dem vorherigen Abschnitt ist.

Wie Techsy das angeht: Die Agent-Stacks, die wir für B2B-Kunden ausliefern, betreiben genau dieses Muster, ein Kostenstufen-Router mit Fallback-Ketten, verdrahtet in das Gateway, plus eval-getriebenes Nachjustieren. Wenn Sie abwägen, ob Routing zu Ihrem Stack passt, holen Sie sich eine kostenlose Beratung und wir kartieren Ihren Traffic-Mix mit Ihnen.

Häufig gestellte Fragen

Was ist ein LLM-Router?

Ein LLM-Router ist eine Schicht zwischen Ihrer Anwendung und mehreren Sprachmodellen, die entscheidet, welches Modell jede Anfrage bearbeitet. Er prüft Aufgabentyp, Größe oder Schwierigkeit der Anfrage und leitet sie dann an das passendste Modell weiter, mit einem Fallback, falls dieses Modell versagt. Stellen Sie ihn sich als Fluglotsen für Ihre Modell-API-Aufrufe vor.

Wie funktioniert LLM-Routing?

LLM-Routing läuft in fünf Schritten: Die Anfrage trifft ein, der Router prüft sie (Schlüsselwörter, Token-Anzahl oder ein Embedding), eine Strategie wählt eine Modell-Stufe, der Aufruf wird weitergeleitet und ein Fallback-Modell fängt jeden Fehler ab. Die gesamte Entscheidung passiert, bevor die Generierung startet, also fügt sie Millisekunden hinzu, keine Sekunden, außer ein Classifier-Modell übernimmt die Bewertung.

Ist ein LLM-Router dasselbe wie ein LLM-Gateway?

Nein. Ein Gateway ist die Leitung: API-Keys, Rate-Limits, Budgets und Logs. Ein Router ist die Entscheidung: welches Modell antwortet. Es sind Schichten, keine Konkurrenten, und die meisten Gateways (LiteLLM, Portkey, OpenRouter) betten einen Router ein. Sie können einen Router ohne Gateway betreiben, aber in Production wollen Sie meist beides zusammen.

Spart Modell-Routing tatsächlich Geld?

Ja, wenn sich der Großteil Ihres Traffics für eine deutlich günstigere Stufe qualifiziert. Unser Rechenbeispiel verschiebt 80 % der Anfragen von einem 3-$-/15-$-pro-Million-Token-Modell auf ein 0,25-$-/2-$-Modell und senkt die Rechnung um 70,7 %. AWS berichtete bis zu 30 % für Routing innerhalb einer Modellfamilie. Wenn Ihr Traffic durchgehend komplex ist, schrumpft die Einsparung gegen null.

Was ist der beste Open-Source-LLM-Router?

Für Production: LiteLLM, selbst gehostet, aktiv gewartet, und es kombiniert ein Gateway mit einem Router. Für Algorithmen auf Forschungsstand implementiert LLMRouter von ulab-uiuc 16+ Routing-Strategien aus der akademischen Literatur. RouteLLM ist der stärkste Qualität-pro-Dollar-Router, trainiert auf Präferenzdaten. Die meisten Teams sollten mit LiteLLM starten und nur dann zu den Forschungs-Bibliotheken greifen, wenn sie eigenes Scoring brauchen.

Wie baue ich einen LLM-Router in Python?

Starten Sie mit dem OpenAI-Client und etwa 80 Zeilen Code: eine Regel-Map von Schlüsselwörtern zu Modellen, eine Kosten-Schwelle auf Token-Anzahlen, Embedding-Ähnlichkeit zu Beispiel-Prompts oder ein günstiges Classifier-Modell, das die Schwierigkeit bewertet. Alle vier Muster stehen im Build-Abschnitt oben, lauffähig gegen OpenAI, Ollama oder vLLM ohne Änderungen.

Kann ich zwischen lokalen Modellen und Cloud-APIs routen?

Ja. Ollama (localhost:11434/v1) und vLLM stellen beide OpenAI-kompatible Endpunkte bereit, also zeigt derselbe Router-Code auf ein lokales Modell für günstigen Traffic und eine gehostete API für harten Traffic. Lokale Tokens kosten 0 $, aber Ihnen gehören Hardware und Latenz. Das ist das Muster hinter den meisten Multi-Modell-Claude-Code-Setups.

Was ist semantisches Routing?

Semantisches Routing bettet jeden eingehenden Prompt ein und vergleicht ihn mit eingebetteten Beispiel-Prompts, wobei die Anfrage an das Modell geht, dem der nächste Beispiel-Cluster gehört. Es handhabt vage, umformulierte Nutzereingaben, die Schlüsselwort-Regeln verpassen, zu Kosten von 50–150 ms plus Embedding-Tokens pro Anfrage. AWS hat es mit 0,10 Sekunden zusätzlicher Latenz gemessen.

Wie viel Latenz fügt ein LLM-Classifier-Router hinzu?

AWS hat 0,53 Sekunden zusätzliche Latenz für LLM-gestützte Klassifizierung gemessen, gegenüber 0,10 Sekunden für semantisches Routing. Regelbasiertes und kostenbewusstes Routing fügen grob null hinzu, weil sie reine Code-Pfade sind. Wenn Ihr Produkt ein enges Antwortzeit-SLA hat, bevorzugen Sie Regeln, Kosten-Schwellen oder Embeddings und heben Sie den Classifier für Offline- oder Queue-Workloads auf.

Quellen

• Seifi, N. und Chugh, M. (2025-04-09). „Multi-LLM routing strategies for generative AI applications on AWS." AWS Machine Learning Blog. https://aws.amazon.com/blogs/machine-learning/multi-llm-routing-strategies-for-generative-ai-applications-on-aws/ (abgerufen am 30. Juli 2026)
• AWS-Beispielcode: sample-multi-llm-dynamic-prompt-routing. https://github.com/aws-samples/sample-multi-llm-dynamic-prompt-routing (abgerufen am 30. Juli 2026)
• LiteLLM-Dokumentation. https://docs.litellm.ai (abgerufen am 30. Juli 2026)
• Anthropic-Preise. https://www.anthropic.com/pricing (abgerufen am 30. Juli 2026)
• OpenAI-API-Preise. https://openai.com/api/pricing (abgerufen am 30. Juli 2026)
• ulab-uiuc LLMRouter. https://github.com/ulab-uiuc/LLMRouter (abgerufen am 30. Juli 2026)
• Ong, I. et al. (2024). „RouteLLM: Learning to Route LLMs with Preference Data." arXiv:2406.18665. https://arxiv.org/abs/2406.18665 (abgerufen am 30. Juli 2026)
• OpenRouter-Rankings. https://openrouter.ai/rankings (abgerufen am 30. Juli 2026)