LLM-Router: Was dieser Begriff wirklich bedeutet

Warum der Begriff verwirrend ist

Fragen Sie drei Teams, was ihr LLM-Router tut, und Sie erhalten drei Antworten, die sich nicht überschneiden. Das eine betreibt GPT-4o sowohl auf Azure als auch bei OpenAI und möchte einen Ausfall nahtlos überstehen. Das zweite hat seine Rechnung erhalten und möchte die einfachen 70 % der Anfragen von einem günstigeren Modell verarbeiten lassen. Das dritte hat eine deutsche Tochtergesellschaft, deren Prompts die EU nicht verlassen dürfen. Alle drei benötigen unterschiedliche Konfigurationen, und zwei der drei könnten mit den Lösungen der anderen nichts anfangen.

Es lohnt sich, die Taxonomie präzise darzulegen, da sie von den meisten Inhalten zum Thema LLM-Routing übergangen wird:

Der entscheidende Unterschied liegt darin, was zur Entscheidung herangezogen wird. Load Balancing liest den Infrastrukturstatus aus, die Modellauswahl den Anfragetext, das Daten-Routing liest Metadaten und Identität. Drei Eingaben, also drei Funktionen — und diese ergänzen sich, anstatt zu konkurrieren.

Art eins: Load Balancing über austauschbare Zielen hinweg

Dies ist die älteste und unspektakulärste Bedeutung des Begriffs, weshalb sie auch die zuverlässigste ist. Sie haben mehrere Wege, um dieselbe Funktion zu erreichen — azure/gpt-4o und openai/gpt-4o, oder zwei Deployments in verschiedenen Regionen — und möchten die Anfragen so verteilen, dass kein einzelner Ausfall Ihr System lahmlegt.

Die Prämisse ist, dass jedes Ziel hinsichtlich der Korrektheit gleichwertig ist. Jedes könnte die Anfrage bedienen; Sie wählen nach Verfügbarkeit, Kapazität und Geschwindigkeit aus. Das macht das automatische LLM-Load Balancing sicher. Die Latenzzeiten der Provider sind jedoch nicht stabil genug, um sie zu ignorieren — sie variieren je nach Modell, Region, Provider und Tageszeit:

TrueFoundry konfiguriert dies über ein virtuelles Modell — einen Namen, den Ihre Anwendung aufruft, wie z. B. my-group/production-chat, mit einer Routing-Strategie und einer Liste echter Zielen dahinter. Drei Strategien qualifizieren sich als Load Balancing:

Zwei Details unterscheiden diese Strategien von einem einfachen Round-Robin-Verfahren.

Latenzbasiertes Routing ist konzeptionell sticky. Das Gateway misst die Zeit pro Output-Token jedes Ziels über die letzten 20 Minuten und wählt dann pro Aufrufer ein Ziel aus, das für eine Epoche von 10 Minuten unverändert bleibt. Über viele Aufrufer hinweg verteilt sich der Traffic umgekehrt proportional zur Latenz, aber jeder einzelne Aufrufer greift lange genug auf dasselbe Ziel zu, damit sich Prompt-Caching auszahlt. Dies müssen Sie nicht konfigurieren; es ist die Funktionsweise der Strategie.

Die Health wird kontinuierlich überwacht. Ein Ziel, das innerhalb eines gleitenden Zwei-Minuten-Fensters zweimal 5xx, 429, 401 oder 403 zurückgibt, wird als ungesund markiert, an das Ende der Liste verschoben und erholt sich, sobald diese Fehler verjährt sind. Prioritätsbasiertes Routing fügt einen optionalen SLA-Schwellenwert hinzu: ein Limit für die Zeit pro Output-Token oder die Zeit bis zum ersten Token, das das Ziel herabstuft, wenn sein dreiminütiger gleitender Durchschnitt dieses überschreitet.

Regeln können auch auf Tenant-Ebene als YAML geschrieben werden, die in Reihenfolge ausgewertet werden, wobei der erste Treffer gewinnt:

Eine Prioritätskette mit Failover bei Rate-Limits:

Dieses YAML befindet sich unter AI Gateway → Configs → Routing Config, kann in Git verwaltet und mit tfy apply angewendet werden, sodass Routing-Änderungen ein PR-Review durchlaufen. Ein Hinweis: Für neue Setups empfiehlt TrueFoundry stattdessen virtuelle Modelle. Das YAML bleibt für bestehende Deployments funktionsfähig, aber virtuelle Modelle bieten eine klarere Zuweisung von Verantwortlichkeiten und Zugriffskontrollen.

Art zwei: Modellauswahl oder Routing nach Anfrageanforderungen

Dies ist die Bedeutung, nach der Teams suchen, wenn sie nach dem besten LLM-Router recherchieren, und es ist ein grundlegend anderes Problem. Die Ziele sind hier nicht austauschbar: Ein günstiges Modell und ein Frontier-Modell antworten zwar beide, aber nicht gleich gut. Der Router trifft eine Qualitätsentscheidung, keine Kapazitätsentscheidung.

Die wirtschaftlichen Vorteile liegen auf der Hand. Der Produktions-Traffic ist nicht gleichmäßig anspruchsvoll — eine Begrüßung, eine Faktenabfrage und die Anforderung, einen verteilten Rate-Limiter zu entwerfen, treffen alle auf demselben Endpunkt ein. Wenn alle drei vom leistungsfähigsten Modell bedient werden, zahlen Sie Höchstpreise für die einfache Mehrheit der Anfragen.

Das Auto Routing von TrueFoundry klassifiziert jede Anfrage in einen von drei Tiers und leitet sie an das Ziel weiter, das Sie für diesen Tier konfiguriert haben. Ihre Anwendung ruft weiterhin denselben virtuellen Modellnamen auf.

Sie wählen Complexity als Routing-Typ, wenn Sie das virtuelle Modell erstellen:

Wählen Sie anschließend aus, wie Anfragen klassifiziert werden. Heuristic ist der Standardwert: in-process, kostenlos, ohne zusätzliche Latenz, vollständig deterministisch. Es bewertet eine feste Gruppe von Signalen — Code-Schlüsselwörter, Phrasen wie „Schritt für Schritt“, technisches Vokabular, Prompt-Länge, mehrstufige Struktur. Zwei eindeutige Reasoning-Phrasen leiten Anfragen immer an den Tier complex weiter, unabhängig von anderen Übereinstimmungen.

Der LLM classifier ruft stattdessen ein kleines, schnelles Modell für Traffic auf, bei dem sich der Schwierigkeitsgrad nicht durch Vokabular ausdrückt:

Seien Sie sich der Kosten bewusst. Jeder Classifier-Aufruf ist eine kostenpflichtige Gateway-Anfrage. Er erscheint in Ihren Logs, seine Tokens werden demselben Tenant und Subjekt wie die auslösende Anfrage zugeordnet, und er fügt einen Hop hinzu, bevor das eigentliche Modell aufgerufen wird. Die Heuristik ist kostenlos, aber grob; der Classifier ist bei mehrdeutigen Prompts genauer, kostet jedoch doppelt — in Cents und in Millisekunden. Eine fallback_strategy ist erforderlich, damit ein Classifier-Timeout die Anfrage nicht fehlschlagen lässt.

Weisen Sie schließlich jedem Tier ein Modell zu:

Was die Zahlen tatsächlich aussagen

TrueFoundry hat Auto Routing damit verglichen, jede Anfrage an ein einziges Top-Modell zu senden. Die Antworten wurden deterministisch bewertet — generierter Code wurde gegen Unit-Tests ausgeführt, Mathematik und Multiple-Choice-Fragen wurden mit Lösungsschlüsseln abgeglichen.

Die durchschnittliche Latenz sank von etwa 7,6 s auf 4,0 s, da die meisten Anfragen das Top-Reasoning-Modell überspringen. [VERIFY — Latenzzahlen sind nicht in den öffentlichen Docs enthalten, dort steht nur, dass Auto Routing „im Durchschnitt schneller“ war.]

Betrachten Sie die 98 % objektiv. Es ist kein Versprechen, dass das Routing auf niedrigere Tiers ohne Kompromisse ist. Es ist der gemessene Wert dessen, was Sie abgeben: zwei Prozentpunkte der Bestehensquote, erkauft mit einer Ersparnis von etwa zwei Dritteln der Rechnung. Bei einigen Workloads ist das ein hervorragender Deal, bei anderen nicht — weshalb die Zahl veröffentlicht und nicht auf „kein Qualitätsverlust“ aufgerundet wird. Im Vergleich zu einem Top-Modell der vorherigen Generation liegt die Ersparnis näher bei 50 %, und die kostenlose Heuristik verliert bei kurzen, aber schwierigen Prompts an Genauigkeit. Gemessen im August 2026.

Art drei: Daten-Routing, wohin die Anfrage gelangen darf

Die dritte Bedeutung hat nichts mit Kosten oder Durchsatz zu tun. Eine Anfrage einer deutschen Tochtergesellschaft muss möglicherweise von einem EU-Deployment bedient werden, und das dazugehörige Log muss eventuell in einem EU-Bucket verbleiben. Keine Gewichtungsanpassung kann das abbilden. Zwei Dinge werden als Daten-Routing bezeichnet, und TrueFoundry setzt sie mit unterschiedlichen Funktionen um:

Für die Verarbeitung enthalten Ziele einen metadata_match-Block. Ein Ziel bleibt nur dann qualifiziert, wenn jedes Paar mit den aufgelösten Metadaten der Anfrage übereinstimmt. Auf dem SaaS-Gateway wird jede Anfrage automatisch mit tfy_gateway_region und tfy_gateway_zone derjenigen der über 12 Regionen getaggt, die sie verarbeitet hat, sodass der Client nichts senden muss:

Die Filterung erfolgt, bevor die Reihenfolge für das Load Balancing berechnet wird, sodass ein nicht passendes Ziel gar nicht erst berücksichtigt wird. Diese Reihenfolge ist entscheidend: Daten-Routing schränkt die Menge der Kandidaten ein, Load Balancing wählt daraus aus.

Für die Speicherung gibt es eine separate Data-Routing-Seite unter AI Gateway → Controls → Data Routing:

Benutzerdefinierte Ziele sind eine Enterprise-Funktion und leiten Traces basierend auf Bedingungen weiter — benutzerdefinierte Metadaten wie metadata.app oder wer die Anfrage erstellt hat. Die Auswertung der Ziele erfolgt von oben nach unten, der erste Treffer gewinnt; platzieren Sie daher spezifische Regeln über generischen:

Jedes Ziel ist entweder von der Control Plane verwalteter Speicher — mit einer auf SaaS wählbaren Region für die Datenresidenz — oder Ihr eigener S3-, GCS- oder Azure Blob-Bucket:

Zwei Einschränkungen sollten Sie beachten. Metriken werden immer an das Standardziel gesendet und dauerhaft aufbewahrt — nur Traces können benutzerdefiniert geroutet werden. Zudem werden bei der Änderung einer Speicherkonfiguration keine Daten migriert: Bestehende Daten werden nicht gelöscht, sind aber vom neuen Standort aus nicht mehr zugänglich.

Häufige Fehler von Teams

Das falsche Problem lösen. Ein Team, das sich Sorgen um die Ausgaben macht, baut eine gewichtete Aufteilung über drei Provider auf. Gewichtungen erkennen nicht, welche Anfragen schwer sind, sodass sich die Rechnung kaum ändert. Ein Team, das Ausfälle befürchtet, aktiviert Complexity Routing und ist überrascht, wenn ein Provider-Vorfall es dennoch lahmlegt. Definieren Sie das Problem, bevor Sie den Mechanismus wählen.

Annehmen, dass die Health-Herabstufung überall gilt. Bei gewichtungs-, prioritäts- und latenzbasiertem Routing wird ein fehlschlagendes Ziel an das Ende der Liste herabgestuft. Beim Auto Routing ist dies nicht der Fall — die Zielreihenfolge entspricht immer der Tier-Reihenfolge, und die Eskalationskette dient als Failover-Pfad. Retries pro Ziel, Fallback-Statuscodes, Rate-Limits und Budgets gelten weiterhin; das Cooldown-Verhalten jedoch nicht.

Den Classifier als kostenlos betrachten. Die Heuristik ist es tatsächlich. Der LLM-Classifier ist ein zweiter Modellaufruf bei jedem unbestimmten Turn, der wie jede andere Anfrage abgerechnet und getraced wird. Oft lohnt sich das — aber er gehört in Ihr Kostenmodell, um Überraschungen auf der Rechnung zu vermeiden.

Routen ohne Ausgabenobergrenze. Kostenbewusstes Routing senkt die durchschnittlichen Kosten pro Anfrage, deckelt jedoch nicht die Gesamtausgaben. Eine unkontrollierte Agenten-Schleife macht die Ersparnisse eines Quartals zunichte. Modell-Routing steuert die Effizienz, Budgetregeln setzen das Limit — Sie benötigen beides.

Möchten Sie Complexity Routing mit Ihrem eigenen Traffic testen?

Erstellen Sie ein virtuelles Modell, weisen Sie drei Tiers drei Modellen zu und vergleichen Sie die Rechnung nach einer Woche.

Kostenlos starten

Ein praktisches Beispiel

Ein Support-Produkt sendet alle Anfragen an ein Frontier-Modell. Die Rechnung ist hoch, ein Provider hatte letzten Monat Ausfälle und die Rechtsabteilung fragt, wo die Gespräche von EU-Kunden verarbeitet werden. Alle drei Problemstellungen in einer einzigen Anwendung.

Schritt eins: Modellauswahl. Erstellen Sie ein virtuelles Modell support/assistant mit Complexity Routing. Weisen Sie simple einem kleinen, schnellen Modell zu, medium einem Mid-Tier-Modell, complex dem Frontier-Modell und lassen Sie den heuristischen Classifier aktiviert. Die Anwendung ändert lediglich einen String — den Modellnamen.

Das Verhalten bei Mehrfach-Dialogen erfordert keine Konfiguration. Jeder Turn wird klassifiziert, und das Pinning bewegt sich nur nach oben: Wenn Turn vier schwieriger ist, steigt die Konversation auf; wenn Turn fünf „danke“ lautet, bleibt sie auf dem höheren Tier. Ein Pin bleibt bei zehn Minuten Inaktivität bestehen und wird bei jedem Turn aktualisiert. Sobald eine Konversation complex erreicht, überspringen spätere Turns die Klassifizierung vollständig.

Schritt zwei: Load Balancing innerhalb eines Tiers. Weisen Sie dem Tier complex ein zweites Ziel bei einem anderen Provider zu. Ziele desselben Tiers werden vor einer Eskalation in der Deklarationsreihenfolge ausprobiert, sodass das Frontier-Modell einen Partner für das Failover hat. Das Dashboard erlaubt ein Ziel pro Tier, daher erfordert dieses Muster tfy apply oder die API.

Schritt drei: Daten-Routing. Fügen Sie metadata_match: { tfy_gateway_region: EU } zu einem in der EU deployed Ziel mit einer Catch-All-Regel darunter hinzu. Erstellen Sie anschließend ein Data-Routing-Ziel, das Traces mit metadata.region gleich eu an einen EU-Bucket sendet.

Schritt vier: Das Limit festlegen. Eine Budgetregel auf Ebene der virtuellen Modell-ID deckelt die Ausgaben unabhängig vom Routing-Verhalten:

Budget-Regel-Scope-Filter mit Subjects-, Models- und Metadata-Bedingungen

Eine solche Regel passt sowohl auf die ID des virtuellen Modells als auch auf das konkrete Ziel, auf das es aufgelöst wird — beide verhalten sich jedoch sehr unterschiedlich. Ein überschrittenes Budget für ein virtuelles Modell im Enforce-Modus blockiert die gesamte Anfrage, bevor ein Backend ausgeführt wird, und Fallback-Ziele werden nicht versucht. Ein überschrittenes Budget für ein konkretes Ziel überspringt nur dieses Ziel, und das virtuelle Modell weicht auf ein anderes aus. Dieselbe Funktion, aber mit völlig unterschiedlicher Auswirkung.

Schritt fünf: Überprüfen. Jede Antwort enthält den Header x-tfy-applied-rules mit dem bedienten Tier, der Ursache und der vollständigen Kette sowie x-tfy-resolved-model mit dem Modell, das geantwortet hat. Der Zähler ai_gateway_complexity_routing_decisions_total schlüsselt nach decided_tier, resolved_tier und cause auf — multiplizieren Sie den Traffic-Anteil jedes Tiers mit der Preisdifferenz, um Ihre tatsächliche Ersparnis zu berechnen.

Bereit, Ihren eigenen Tier-Mix zu messen?

Leiten Sie einen Teil des Traffics über ein virtuelles Modell und lesen Sie die Zahlen aus Ihren eigenen Logs ab.

Kostenlos auf TrueFoundry starten

Fallstricke, die Sie kennen sollten

Auto Routing funktioniert nur mit virtuellen Modellen. Es ist kein gültiger Regeltyp im Routing-YAML auf Tenant-Ebene und wird für Embedding-, Image-, Audio-, Rerank- und Moderation-Modelltypen abgelehnt — unterstützt werden nur Chat, Completion und Responses. Gemischte Listen schlagen ebenfalls fehl: Das Deklarieren von sowohl Chat als auch Embedding wird beim Speichern abgelehnt.

Eskalation deckt auch Tiers ab, die Sie nie konfiguriert haben. Wenn nur simple- und complex-Ziele definiert sind, wird alles, was als medium klassifiziert wird, zu complex eskaliert und im Header ausgewiesen. Dies ist ein unterstütztes Two-Tier-Setup — wenn jedoch decided_tier und resolved_tier aus einem anderen Grund als session_pin dauerhaft voneinander abweichen, fehlt ein Tier oder ist falsch konfiguriert.

Der Classifier liest nur zwei Nachrichten. Die letzte User-Nachricht und die letzte System- oder Developer-Nachricht, begrenzt auf 8.000 bzw. 2.000 Zeichen. Frühere Turns, Antworten des Assistants und Tool-Nachrichten werden ignoriert. Die Konsistenz über eine Konversation hinweg entsteht durch Pinning, nicht durch das Lesen des Verlaufs.

Verwandte Artikel

• Was ist ein LLM-Router? Ein vollständiger Leitfaden — die Einführung
• OpenRouter vs. AI Gateway — wo ein Router aufhört und ein Gateway beginnt
• Bifrost vs. LiteLLM — Open-Source-Routing-Layer im Vergleich
• Die besten OpenRouter-Alternativen — Routing-Optionen mit erweiterter Kontrolle
• Aufbau eines AI Governance Frameworks — die Policy-Schicht rund um das Routing

Fazit

„LLM-Router“ wirkt wie eine ungenaue Kategorie, weil sich drei verschiedene Kategorien hinter einer Bezeichnung verbergen. Load Balancing ist ein Verfügbarkeits-Tool, bei dem die Ziele austauschbar sind. Die Modellauswahl ist ein Kosten-Tool, bei dem die Ziele dies ausdrücklich nicht sind. Daten-Routing ist ein Compliance-Tool, das die Menge der Optionen einschränkt, bevor die anderen beiden zum Zug kommen.

Einzeln betrachtet ist jede Entscheidung überschaubar. Verlieren Sie Anfragen durch Ausfälle, zahlen Sie zu viel für einfache Anfragen oder müssen Sie Vorgaben zum Speicherort von Daten erfüllen? Das Erste erfordert eine Prioritätskette, das Zweite Complexity-Tiers, das Dritte Metadaten-Abgleich und ein Speicherziel. Die meisten Teams benötigen eine dieser Lösungen dringend und die anderen im Laufe der Zeit.

Wenn Sie die Kostenoptimierung anstreben, sollten Sie die veröffentlichten Zahlen realistisch betrachten. Eine Ersparnis von 69 Prozent ist möglich — ebenso wie der Qualitätsunterschied von zwei Prozentpunkten.

Konfigurieren Sie Ihren ersten LLM-Router auf TrueFoundry

Kostenlos starten