Intelligentes LLM-Routing: Kosten-, latenz- und qualitätsbewusste Modellauswahl am Gateway

Eine Anwendung im Jahr 2026 kommuniziert nicht mit einem einzigen Modell, sondern mit einer ganzen Auswahl – von Spitzenmodellen über Mittelklasse- und kostengünstige Varianten bis hin zu selbst gehosteten Lösungen. Routing ist die Richtlinie, die pro Anfrage eine Auswahl trifft und dabei drei gegensätzliche Ziele ausbalanciert: Kosten, Latenz und Qualität. Dieser Beitrag erläutert Routing-Strategien von statischen Regeln bis hin zu semantischem Routing und Modell-Kaskaden, die Herausforderung bei der Messung der gewünschten Qualität, warum Routing kein Failover ist und welche Instrumentierung verhindert, dass ein Router unbemerkt versagt.

Dienstag bei Northwind. Omar, ein Plattform-Ingenieur, war das ganze Quartal stolz auf eine Zahl: eine Senkung der LLM-Rechnung des Unternehmens um 41 %. Er hatte einen Router gebaut. Einfache Klassifizierungs- und Absichtserkennungsanfragen gingen an ein günstiges Modell; nur die wirklich anspruchsvollen Aufgaben – mehrstufiges Schlussfolgern, Code-Generierung – erreichten das Spitzenmodell. Es funktionierte. Die Finanzabteilung wurde aufmerksam.

Dann kam die Rechnung für die zweite Woche: dreimal so hoch wie in der ersten, ohne dass der Traffic gestiegen war. Omar ging der Sache nach. Seine Kaskade enthielt einen Prüfmechanismus – die Ausgabe des günstigen Modells wurde auf ein Schema geprüft, und bei einem Fehler wurde die Anfrage an das Spitzenmodell eskaliert. Ein Update auf Anbieterseite hatte das Ausgabeformat des günstigen Modells subtil verändert, die Schema-Prüfung schlug bei den meisten Antworten fehl, und der Router hatte stillschweigend etwa 90 % des Traffics an das teuerste Modell weitergeleitet. Nichts stürzte ab. Nichts löste einen Alarm aus. Der Router tat genau das, was ihm befohlen wurde; er hörte nur auf, das zu tun, was Omar beabsichtigt hatte. Die Eskalationsrate war neun Tage lang gestiegen, ohne dass es jemand bemerkt hatte.

Routing ist oft einer der wirkungsvollsten Hebel für die Kostenoptimierung in einem LLM-Stack und gleichzeitig einer der Bereiche, in denen man am leichtesten unbemerkt Fehler macht. Dieser Beitrag behandelt die Strategien, ihre Vor- und Nachteile sowie die Instrumentierung, die einen Router zuverlässig hält.

Was das AI Gateway von TrueFoundry hier bietet

Die Routing-Strategien in diesem Beitrag sind keine abstrakten Konzepte – sie zeigen, wie das AI Gateway von TrueFoundry konfiguriert ist. Seine Routing-Konfiguration gleicht jede Anfrage nach Modell, Subjekt (Benutzer, Team oder virtuelles Konto) oder einem X-TFY-METADATA Header ab, wertet Regeln von oben nach unten nach dem Prinzip „First-Match-Wins“ aus und sendet die Anfrage an ein Zielmodell – alles als YAML, das direkt am Gateway angewendet wird, anstatt verzweigte Logik in der Anwendung zu benötigen.

Die drei Strategien entsprechen der Hierarchie in Abschnitt 2: gewichtungsbasiert für Aufteilungen und Canary-Deployments, latenzbasiert um das schnellste verfügbare Ziel zu bevorzugen, und prioritätsbasiert für eine geordnete Priorisierung mit Fallback. Zielspezifische Überschreibungen lösen zudem das in diesem Beitrag angesprochene Problem der modellspezifischen Prompts – Sie können einen anderen prompt_version_fqn pro Ziel festlegen, sodass jedes Modell einen darauf abgestimmten Prompt erhält – ergänzt durch zielspezifische Wiederholungsversuche und Fallbacks. (Für neue Setups empfehlen die Dokumentationen Virtual Models, die dieselben Strategien, Wiederholungsversuche und Fallbacks mit klarerer Zuständigkeit und Zugriffskontrolle pro Modell bündeln.)

Der Aufruf des Gateways aus einer Anwendung erfordert nur eine einzeilige Änderung, sofern bereits das OpenAI-SDK verwendet wird – derselbe Client, lediglich eine andere Basis-URL und ein anderer Schlüssel. Die Routing-Entscheidung erfolgt dabei im Gateway und nicht in Ihrem Code. Die Anwendung kann zudem einen X-TFY-METADATA Header übergeben, sodass das Gateway Anfragen nach Aufgabe, Umgebung oder Mandant routen kann, ohne dass bedingte Codepfade erforderlich sind:

Aufruf des Gateways mit Python (OpenAI-kompatible API)

from openai import OpenAI

client = OpenAI(
    base_url="https://<your-truefoundry-gateway-url>",   # your gateway endpoint
    api_key="<your-personal-access-token>",              # Bearer-auth'd JWT
)

resp = client.chat.completions.create(
    model="assistant",                                     # logical/virtual model — gateway picks the target
    extra_headers={"X-TFY-METADATA": '{"task": "classify"}'},  # drives the matching rule
    messages=[{"role": "user", "content": "..."}],
)

1. Das Routing-Problem: Viele Modelle, eine Anfrage

Eine Unternehmensanwendung im Jahr 2026 verfügt über eine Auswahl an Modellen mit sehr unterschiedlichen wirtschaftlichen Rahmenbedingungen. Günstige Modelle (Claude Haiku 4.5 für etwa 1 $ pro Million Input-Token) sind um ein Vielfaches kostengünstiger als Spitzenmodelle zu aktuellen Standardtarifen und in der Praxis oft latenzärmer. Mittelklasse-Modelle (Sonnet 4.6 für 3 $ pro Million Input-Token) liegen dazwischen. Selbst gehostete Open-Weight-Modelle (Llama, Mistral) tauschen die Abrechnung pro Token gegen feste GPU-Kapazitäten und Datenkontrolle – bei dauerhaft hoher Auslastung günstiger, bei geringer Auslastung jedoch teuer. Jedes Modell hat zudem ein unterschiedliches Qualitätsprofil je nach Aufgabe: Ein Modell, das exzellent beim Programmieren ist, kann bei der Datenextraktion mittelmäßig abschneiden und umgekehrt.

Routing ist die Richtlinie, die jede eingehende Anfrage einem dieser Modelle zuordnet. Die drei Ziele stehen im Konflikt zueinander: Das günstigste Modell ist selten das qualitativ hochwertigste, das schnellste ist nicht immer das günstigste, und das beste Modell für eine komplexe Aufgabe ist bei einer einfachen Aufgabe verschwendet. Der naive Standardansatz – alles an das beste Spitzenmodell zu senden – maximiert zwar die Qualität, ist aber die teuerste und häufig langsamste Option, da ein Modell mit mehrstufigem Schlussfolgerungsprozess für Anfragen verwendet wird, die ein günstiges Modell in einem Bruchteil der Zeit und Kosten korrekt beantworten würde. Routing ist der Prozess, bei dem diese Kosten-Qualitäts-Grenze Anfrage für Anfrage neu ausgelotet wird.

‍

2. Routing-Strategien: Von statischen Regeln zum semantischen Routing

Routing-Strategien bilden eine Leiter. Jede Sprosse bringt mehr Möglichkeiten, aber auch höhere Kosten. Der richtige Punkt zum Aufhören ist dort, wo der messbare Nutzen die zusätzliche Komplexität nicht mehr rechtfertigt.

Statisch / regelbasiert. Routing nach Endpunkt, Header oder einem vom Aufrufer gesetzten Task-Tag – Klassifizierung geht an das günstige Modell, Codegenerierung an das mittlere Segment. Sub-Millisekunden-Bereich, deterministisch und einfach zu debuggen. Das funktioniert immer dann, wenn der Aufrufer den Aufgabentyp bereits kennt, was häufiger der Fall ist, als Teams annehmen.

Gewichtet / Lastverteilung. Aufteilung des Traffics prozentual auf verschiedene Modelle. Dies ist die Grundlage für A/B-Tests neuer Modelle und Canary-Rollouts: Senden Sie 5 % des Traffics an das neue Modell, beobachten Sie die Metriken und erhöhen Sie den Anteil, wenn die Werte stabil bleiben.

Latenz-optimiert. Wenn mehrere Modelle für eine Anfrage infrage kommen, leiten Sie diese an das Modell mit der aktuell niedrigsten stabilen p95-Latenz weiter. Nützlich für latenzkritische Pfade, bei denen mehrere Modelle die Aufgabe erfüllen könnten.

Kosten-optimiert. Wählen Sie das günstigste Modell, das die Qualitätsanforderungen für die Aufgabe erfüllt. Dies erfordert die Definition von Qualitätsmaßstäben pro Aufgabe (Abschnitt 5), was den schwierigen Teil darstellt.

Vorsicht bei der Definition von „günstig“: Routen Sie basierend auf den Gesamtkosten der Anfrage, nicht nach dem nominalen Preis pro Input-Token. Der tatsächliche Wert ergibt sich aus den erwarteten Input- und Output-Token, angepasst an die Cache-Trefferquote, die Wahrscheinlichkeit für Retries und Hedges, die Eskalationswahrscheinlichkeit bei Kaskaden sowie etwaige Multiplikatoren für Regionen, Prioritäten oder Fast-Modes. Tokenizer unterscheiden sich zudem je nach Modellfamilie – Anthropic weist darauf hin, dass Opus 4.7 und neuer bis zu 35 % mehr Token für denselben Text ausgeben können –, sodass ein identischer Prompt bei verschiedenen Modellen zu unterschiedlichen abrechenbaren Mengen führt. Schätzen Sie die Routing-Kosten anhand echter Traces und nicht durch das Kopieren einer Preisliste in eine statische Tabelle.

Die letzten beiden Sprossen – semantisches Routing und Modell-Kaskaden – erhalten eigene Abschnitte. Die meisten produktiven Router sind eine Mischung: statische Regeln für bekannte Task-Tags, eine kosten- oder latenzbasierte Standardeinstellung für alles andere und eine separate Fallback-Liste für die Verfügbarkeit. Die untenstehende Konfiguration dient der Veranschaulichung; das genaue Schema ist vom jeweiligen Gateway abhängig.

Beispielhafte Routing-Richtlinie (konzeptionell – das genaue Schema ist vom Gateway abhängig)

routes:
  - match: { header: "x-task", equals: "classify" }
    target: claude-haiku-4-5            # cheap tier
  - match: { header: "x-task", equals: "code" }
    target: claude-sonnet-4-6
  - default:
      strategy: cost_aware              # cheapest model that passes the task's quality bar
      candidates: [claude-sonnet-4-6, gpt-5.4]
      fallback: [gpt-5.5]               # availability, NOT optimization — see section 6

So sieht die oben genannte Leiter in TrueFoundry's AI Gatewayaus, wo diese Strategien tatsächlich ausgeführt werden. Das Routing ist eine YAML- gateway-load-balancing-config: Jede Regel entspricht einem Teil des Traffics – nach Modell, Team oder einem X-TFY-METADATA Header – und verteilt diesen über die Ziele mittels gewichteter Lastverteilung, latenzbasierteoder prioritätsbasierte Auswahl. Das Hinzufügen eines Modells oder das Ändern einer Aufteilung ist eine Konfigurationsänderung, kein erneutes Deployment:

Wie TrueFoundry diese Strategien ausdrückt (gateway-load-balancing-config)

name: routing-config
type: gateway-load-balancing-config
rules:
  - id: classify-to-cheap                 # static task tag -> cheap tier
    type: weight-based-routing
    when:
      models: [assistant]
      metadata: { task: classify }
    load_balance_targets:
      - target: anthropic/claude-haiku-4-5
        weight: 100
  - id: default-lowest-latency            # everything else -> fastest healthy target
    type: latency-based-routing
    when:
      models: [assistant]
    load_balance_targets:
      - target: anthropic/claude-sonnet-4-6
      - target: openai/gpt-5.4

Jedes Ziel kann zudem Wiederholungsversuche, eine Fallback-Liste und sogar einen zielspezifischen Prompt enthalten (prompt_version_fqn), sodass jedes Modell einen darauf abgestimmten Prompt erhält. Da eine einzige Datei sowohl die Routing-Richtlinie als auch die Fallback-Kette definiert, bleiben beide getrennt und separat beobachtbar – genau die Grenze, die Abschnitt 6 zieht. Das vollständige Schema finden Sie in der Routing-Konfigurationsdokumentation.

Dieselbe Datei steuert auch ein Canary-Rollout – das in diesem Beitrag empfohlene gewichtete Split-Muster für A/B-Tests eines neuen Modells – ganz ohne Verzweigungen auf App-Seite:

Canary-Rollout mit gewichtungsbasiertem Routing (aus der Dokumentation)

name: loadbalancing-config
type: gateway-load-balancing-config
rules:
  - id: gpt4-canary
    type: weight-based-routing
    when:
      models: [gpt-4]
    load_balance_targets:
      - target: azure/gpt4-v1
        weight: 90
      - target: azure/gpt4-v2
        weight: 10

Einige TrueFoundry-spezifische Hebel, die für die Routing-Entscheidungen in diesem Beitrag erwähnenswert sind: für die Routing-Entscheidungen in diesem Beitrag: Virtuelle Modelle sind der empfohlene Ersatz des Gateways für die globale Routing-Konfiguration. Sie bündeln dieselben Strategien für Gewichtung, Latenz, Priorität, Wiederholungsversuche und Fallbacks unter einem einzigen logischen Modellnamen mit eigener Zugriffskontrolle, sodass eine Route befördert oder ausgetauscht werden kann, ohne jeden Aufrufer ändern zu müssen. Exaktes und semantisches Caching schalten sich vor die Routing-Entscheidung und geben bei wiederholten Abfragen eine gespeicherte Antwort zurück, was bei leselastigen Workloads sowohl die Kosten als auch die Tail-Latenz senkt. Und dieselbe Routing-Konfiguration greift bei X-TFY-METADATA, sodass eine einzige Regeldatei für Dev/Prod- und mandantenspezifisches Routing dienen kann – die Routing-Ebene liest, was der Client gesendet hat, anstatt dass der Client die Routenwahl kodieren muss.

3. Semantisches Routing: Einbetten der Anfrage zur Modellauswahl

Statische Tags setzen voraus, dass der Aufrufer die Aufgabe kennt. Manchmal ist das nicht der Fall – ein allgemeiner Assistent stellt einen Endpunkt bereit, an dem alles ankommt. Semantisches Routing leitet die Aufgabe aus der Anfrage selbst ab: Den Prompt einbetten, den nächstgelegenen Intent-Schwerpunkt finden (oder einen kleinen Klassifikator ausführen) und basierend auf dem abgeleiteten Intent routen.

Semantisches Routing – Anfrage einbetten, nach nächstgelegenem Intent routen

emb = embed(req.text)                       # ~5–20 ms, small per-call cost
intent = nearest_centroid(emb, centroids)   # e.g. "sql", "summarize", "chat", "reason"
model = ROUTING_TABLE.get(intent, DEFAULT)  # intent -> specialized model

Die Kosten bestehen aus einem Embedding-Aufruf (etwa 5–20 ms und eine geringe Gebühr pro Token) sowie einem kostengünstigen Klassifizierungsschritt. Man sollte ehrlich sein, wann sich das lohnt: nur dann, wenn der Intent am Aufrufort noch nicht bekannt ist. Wenn der aufrufende Code einen Header wie x-task=classify setzen kann, ist das kostenlos, deterministisch und besser. Semantisches Routing gehört an den Eingang eines allgemeinen Assistenten, bei dem Anfragen nicht gelabelt sind – nicht als Zusatz zu einer internen Pipeline, die bereits weiß, wofür jeder Aufruf gedacht ist. Die Nachteile: Schwerpunkte und Klassifikatoren driften ab, wenn sich die Intents des Produkts ändern, und erfordern Wartung. Zudem führt eine Fehlklassifizierung zum falschen Modell – ein semantischer Router benötigt daher immer einen sinnvollen Standardwert und ein Fallback. Wo auch immer der Einbettungs- und Klassifizierungsschritt ausgeführt wird, ist das Gateway der natürliche Ort, um den abgeleiteten Intent und das ausgewählte Modell im Trace zu protokollieren, was die Sichtbarkeit pro Route ist, die TrueFoundrys AI Gateway bereits für die einfacheren Strategien bietet – und was eine Fehlleitung debuggbar macht, anstatt sie unsichtbar zu lassen.

4. Modell-Kaskaden: Erst günstig, bei Fehler eskalieren

Eine Kaskade versucht es zuerst mit einem günstigen Modell, prüft das Ergebnis und eskaliert nur bei einem Fehler auf ein leistungsfähigeres Modell. Die Prüfung kann eine Schema-Validierung (lässt sich die Ausgabe in die erwartete Struktur parsen?), ein Konfidenz- oder Selbstkonsistenzsignal oder ein „Judge“-Modell sein.

Günstige Kaskade mit Schema-Verifizierung

def answer(req):
    draft = call_model("claude-haiku-4-5", req)
    if schema_ok(draft) and confident(draft):
        return draft, "haiku"
    # Escalate — but COUNT it. A rising escalation rate is a cost incident.
    metrics.incr("router.escalation")
    return call_model("gpt-5.5", req), "gpt-5.5"

Die Wirtschaftlichkeit kann überzeugend sein. Wenn die günstige Stufe die meisten Anfragen auflöst, sinken die Mischkosten in Richtung des Preises der günstigen Stufe. Als illustratives Modell: Bei der etwa 5-fachen Standard-Preisdifferenz zwischen Haiku und den genannten Frontier-Modellen führt eine Auflösungsrate von 70 % durch das günstige Modell zu Mischkosten von etwa der Hälfte einer „Frontier-everywhere“-Strategie – selbst nach Einberechnung des günstigen Versuchs bei den 30 %, die eskalieren. (Vergrößert man die Lücke auf das 10-fache, wie es bei einigen Premium-, Pro- oder Priority-Stufen der Fall ist, landet dieselbe Kaskade bei näherungsweise 40 %.) Die tatsächlichen Einsparungen hängen von Ihrer Auflösungsrate und der realen Preisdifferenz ab; messen Sie diese daher, anstatt sie nur anzunehmen.

Eine Kaskade fügt zudem bei jeder eskalierten Anfrage die Latenz des günstigen Modells hinzu – Sie zahlen die Zeit für den günstigen Aufruf plus die Zeit für den Frontier-Aufruf. Für interaktive, latenzempfindliche Pfade kann dieser doppelte Aufwand der falsche Kompromiss sein; Kaskaden glänzen bei durchsatzorientierten oder asynchronen Workloads, bei denen der Vorteil der Mischkosten die Tail-Latenz bei Eskalationen überwiegt.

5. „Qualität“ messen, um danach routen zu können

Das Routing nach Kosten oder Latenz ist unkompliziert, da beides direkt beobachtbar ist. Das Routing nach Qualität ist schwieriger, da Qualität gemessen werden muss, bevor sie optimiert werden kann. Drei Ansätze, in aufsteigender Reihenfolge von Genauigkeit und Kosten:

Offline-Evaluierungssets. Ein kuratiertes, gelabeltes Set pro Aufgabentyp. Lassen Sie jedes Kandidatenmodell dagegen laufen und erstellen Sie die Routing-Tabelle basierend auf den Ergebnissen – dieses Modell für SQL, jenes für Zusammenfassungen. Günstig in der wiederholten Ausführung, aber nur so repräsentativ wie das Evaluierungsset selbst.

Online LLM-as-a-Judge. Stichproben des Produktions-Traffics und Bewertung der Antworten durch ein Judge-Modell. Dies kommt der tatsächlichen Verteilung näher, verursacht jedoch zusätzliche Kosten und Latenz. Zudem ist der Judge selbst fehleranfällig – ein Modell, das dieselben blinden Flecken wie der Generator hat, wird dessen Fehler einfach durchwinken.

A/B-Tests anhand von Geschäftskennzahlen. Der Goldstandard: Leiten Sie einen Teil des Traffics an einen Kandidaten weiter und messen Sie die Kennzahl, die für Sie wirklich zählt – Lösungsrate, positive Bewertungen oder nachgelagerte Conversion. Dies ist zwar langsam und aufwendig, misst aber das eigentliche Ziel statt nur eines Ersatzwerts.

Die gemeinsame Warnung für alle diese Ansätze: Entscheiden Sie nicht nach dem Bauchgefühl. Ein günstiges Modell, das in einer Demo „ganz gut aussieht“, kann eine nachgelagerte Kennzahl über Wochen hinweg schleichend verschlechtern. Koppeln Sie jede Routing-Änderung an ein messbares Qualitäts-Gate und bedenken Sie, dass Qualität aufgabenspezifisch ist – ein Platz auf einer Bestenliste ist keine Routing-Tabelle, da das Modell, das bei einem allgemeinen Benchmark führt, bei Ihrer Extraktionsaufgabe nur mittelmäßig abschneiden kann. Das Produktionssignal, das alle drei Methoden benötigen – welches Modell hat welche Anfrage bearbeitet und was geschah danach – ist genau das, was das Gateway bereits aufzeichnet; TrueFoundrys pro Route erstellte Traces sind eine natürliche Datenquelle für die oben genannten Offline-Evaluierungssets und Online-Stichproben.

Ein Punkt, den alle drei Methoden berücksichtigen müssen: Ein Produktions-Router sieht immer nur das Modell, das er ausgewählt hat. Wenn Sie eine Anfrage an Haiku weiterleiten, erfahren Sie nie, ob Sonnet, Opus oder GPT-5.5 besser abgeschnitten hätten – das Kontrafaktische bleibt unsichtbar. Um die Routing-Tabelle aktuell zu halten, sollten Sie einen Teil des Traffics für eine Schatten-Evaluierung abzweigen, echte Anfragen offline mit anderen Kandidaten erneut durchspielen oder regelmäßig Champion/Challenger-Tests durchführen. Ohne dies nutzt ein Router unbemerkt eine veraltete Richtlinie und bemerkt nicht, wenn ein anderes Modell für eine Aufgabe besser, günstiger oder sicherer geworden ist.

6. Routing vs. Failover: Optimierung ist nicht Verfügbarkeit

Routing und Failover nutzen dieselbe Infrastruktur – eine Liste von Modellkandidaten und eine Richtlinie zur Auswahl –, was dazu führt, dass sie leicht verwechselt werden. Es handelt sich jedoch um unterschiedliche Ziele, und ihre Vermischung führt zu Störungen.

Routing ist Optimierung: Wenn alle Kandidaten verfügbar sind, wählen Sie das beste Modell hinsichtlich Kosten, Latenz oder Qualität aus. Failover ist Verfügbarkeit: Wenn das gewählte Modell ausfällt oder die Zeit überschreitet, greifen Sie auf ein anderes zurück, damit die Anfrage dennoch erfolgreich ist (das Thema des nächsten Beitrags in dieser Reihe). Die Unterscheidung ist operativ wichtig. Ein Fallback auf ein günstigeres Modell aufgrund eines Ausfalls kann die Qualität schleichend verschlechtern. Sie möchten, dass dies als „Fallback aufgrund eines Ausfalls des Primärsystems“ protokolliert wird und nicht fälschlicherweise als bewusste Kostenentscheidung interpretiert wird. Umgekehrt sollte ein vorübergehender 500-Fehler ein Failover auslösen, keine dauerhafte Routing-Änderung. Halten Sie beide Richtlinien getrennt und separat beobachtbar: „Routing zu X aus Kostengründen“ und „Fallback zu Y, da X nicht verfügbar war“ sind unterschiedliche Ereignisse, die in Ihren Traces unterschiedlich dargestellt werden sollten. Ein Gateway wie TrueFoundrys ist der Ort, an dem beides nebeneinander existiert, ohne zu verschwimmen – die Routing-Richtlinie und die Fallback-Kette werden als eigenständige Einheiten konfiguriert und nachverfolgt.

7. Wo Routing stattfindet: Das Gateway als Entscheidungspunkt

Routing-Logik kann in der Anwendung liegen, aber das Gateway ist aus zwei Gründen der natürlichere Ort. Erstens normalisiert es bereits die Provider-APIs, sodass die Umstellung einer Route von einem Modell auf ein anderes eine Konfigurationsänderung und keine Codeänderung ist – und der Wechsel zwischen beispielsweise einem OpenAI-Modell und einem Anthropic-Modell erfordert kein Umschreiben der Anfragestruktur. Zweitens enthält es bereits die Telemetriedaten zu Kosten und Latenz, von denen Routing-Entscheidungen abhängen; die Daten, die Sie für ein gutes Routing benötigen, sind genau die Daten, die das Gateway ohnehin bereits erfasst.

Zentralisierung des Routings bei TrueFoundrys AI Gateway Das bedeutet eine einheitliche Richtlinie für alle Dienste, ein zentraler Ort für A/B-Tests neuer Modelle und eine zentrale Stelle zur Überwachung der gemischten Kosten sowie der Eskalationsrate bei Kaskaden, die durch den „Cold Open“ ausgelöst wurden. Das Gateway stellt Routing-Regeln, gewichtetes Load Balancing und Fallback-Ketten für gehostete sowie selbst gehostete Modelle über eine einheitliche, OpenAI-kompatible API bereit. Kosten und Latenz pro Route fließen in dieselbe Attributionsansicht ein, die bereits im Beitrag zur Kostenattribution beschrieben wurde. Die Arbeitsteilung lässt sich klar definieren: Das Gateway übernimmt das Routing und liefert die Daten, während die Anwendung weiterhin die Qualitätsdefinition und die Test-Sets kontrolliert, die entscheiden, welches Modell für die jeweilige Aufgabe am besten geeignet ist.

8. Latenz und Overhead: Was Routing kostet

Routing ist nicht kostenlos, und der Overhead variiert je nach Strategie. Eine statische Regel wird in weit unter einer Millisekunde ausgewertet. Latenzabhängiges Routing benötigt Live-p95-Telemetrie, deren Abruf kostengünstig ist. Semantisches Routing fügt den Embedding-Aufruf hinzu – etwa 5–20 ms – plus einen leichtgewichtigen Klassifikator. Eine Kaskade verursacht bei jeder Anfrage, die eskaliert, die volle Latenz des günstigeren Modells.

Das Designprinzip besteht darin, die Routing-Entscheidung im Vergleich zum nachfolgenden Modellaufruf kostengünstig zu halten. Eine Sub-Millisekunden-Regel fällt bei einer Generierungszeit von über 500 ms kaum ins Gewicht; ein semantischer Schritt ist am Eingang eines Assistenten problemlos vertretbar; die doppelte Latenz einer Kaskade bei Eskalationen ist der Punkt, den man bei interaktiven Pfaden genau prüfen sollte. Fügen Sie nicht für jede Route einen „Judge-Model“-Aufruf zur Qualitätsmessung hinzu, es sei denn, der Qualitätsgewinn oder die Kaskade rechtfertigt den zweiten Modellaufruf pro Anfrage eindeutig – die Stichprobenprüfung eines Teils des Traffics für Online-Evaluierungen liefert meist die nötigen Signale ohne die Zusatzkosten pro Anfrage. Da die Routing-Entscheidung und der Modellaufruf auf demselben Trace liegen, ist der Overhead der Entscheidung messbar statt nur eine Annahme: TrueFoundrys AI Gateway zeichnet die Latenz pro Route auf, sodass Sie bestätigen können, ob der semantische Schritt oder der Kaskadensprung tatsächlich so kostengünstig ist, wie Sie erwarten.

9. FAQs

Sollte das Routing im Gateway oder in der Anwendung stattfinden?

Die Logik gehört ins Gateway – es normalisiert Provider-APIs und speichert die Kosten-/Latenz-Telemetrie, sodass Routing zu einer Konfigurationssache statt zu einer Programmieraufgabe wird. Die Anwendung behält die Kontrolle über die Qualitätsdefinition und die Test-Sets, die bestimmen, welches Modell für welche Aufgabe am besten geeignet ist. Man kann es sich so vorstellen: Das Gateway entscheidet basierend auf einer Richtlinie, wohin die Anfrage gesendet wird; die App legt fest, wie diese Richtlinie aussehen soll.

Schadet das Routing an günstigere Modelle nicht der Qualität?

Nur, wenn man nach dem „Bauchgefühl“ routet. Der Kernpunkt von Abschnitt 5 ist, dass eine Routing-Änderung vor der Implementierung einen gemessenen Qualitäts-Gate-Test pro Aufgabe bestehen sollte. Ein günstiges Modell, das die Anforderungen für die Klassifizierung erfüllt, ist keine Qualitätsverschlechterung; eine Verschlechterung tritt erst ein, wenn man ein günstiges Modell ohne Messung einfach als „gut genug“ annimmt.

Wie wähle ich einen Kaskaden-Prüfer (Verifier) aus?

Schema-Validierung ist der günstigste und zuverlässigste Prüfer, wenn die Ausgabe strukturiert ist – sie ist deterministisch und erfordert keinen zusätzlichen Modellaufruf. Bei offenen Ausgaben ist ein „Judge-Model“ leistungsfähiger, kostet aber einen zweiten Aufruf und kann Fehler machen. Egal, wofür Sie sich entscheiden: Überwachen Sie die Eskalationsrate und richten Sie Alarme ein, denn ein ungenauer Prüfer ist ein häufiger Grund dafür, dass eine Kaskade unbemerkt zu einem Kostenproblem wird.

Verursacht semantisches Routing zu viel Latenz?

Es kommen etwa 5–20 ms für das Embedding plus ein günstiger Klassifizierungsschritt hinzu – das ist bei einer Generierungszeit von mehreren hundert Millisekunden meist akzeptabel. Bei Klassifizierungen unter 100 ms oder internen Pfaden mit hoher QPS ist es jedoch nicht vernachlässigbar, daher sollten Sie es in Ihrem eigenen Pfad messen, anstatt von einer vernachlässigbaren Größe auszugehen. Die eigentliche Frage ist nicht die Latenz, sondern ob Sie es überhaupt benötigen: Wenn der Aufrufer die Aufgabe mit einem Header kennzeichnen kann, ist das kostenlos und deterministisch. Semantisches Routing lohnt sich erst dann, wenn Anfragen ohne Kennzeichnung eingehen.

Wie wirkt sich das auf die Kostenattribution und das Failover aus?

Routing-Entscheidungen und die daraus resultierenden gemischten Kosten werden derselben Trace-basierten Attribution zugeordnet, die im Kosten-Beitrag behandelt wurde, sodass Sie sehen können, welche Routen die Kosten treiben. Failover ist ein separates Thema – es geht um Verfügbarkeit, nicht um Optimierung – und wird im nächsten Beitrag behandelt. Halten Sie beide als getrennte, separat protokollierte Ereignisse, damit ein durch einen Ausfall erzwungener Fallback niemals wie eine Kostenentscheidung aussieht.

Omars Router war nicht falsch; er wurde nur nicht überwacht. Die Strategien in diesem Beitrag sind nur so sicher wie die Zahlen, die Sie begleitend dazu beobachten – die Eskalationsrate, die gemischten Kosten pro Route und das Qualitäts-Gate bei jeder Modelländerung. Routen Sie aggressiv, aber messen Sie zuerst.

Über TrueFoundry

TrueFoundrys AI Gateway ist eine Enterprise-Control-Plane, die zwischen Ihren Anwendungen und über 1.600 Modellen vermittelt – von OpenAI, Anthropic, Google, AWS Bedrock und Azure OpenAI bis hin zu Ihren eigenen, selbst gehosteten Modellen – und das alles über eine einzige OpenAI-kompatible API. Sie verwandelt die in diesem Beitrag beschriebenen Routing-Strategien von Code in Konfiguration: gewichtetes, latenzbasiertes und prioritätsbasiertes Routing, Modell-Kaskaden, Fallbacks und zielspezifische Prompt-Overrides werden einfach als YAML definiert und pro Route angewendet.

Da das Gateway jeden Anbieter normalisiert und Kosten, Latenz sowie Anfrage- und Routing-Metadaten pro Route erfasst, wird Routing hier messbar – ein zentraler Ort für A/B-Tests von Modellen, die Überwachung der Eskalationsrate von Kaskaden und die Zuordnung gemischter Kosten. Verknüpfen Sie diese Traces mit den Evaluierungs- und Feedback-Daten, die Sie an anderer Stelle sammeln, und Sie erhalten zusätzlich eine Qualitätsübersicht. Das Gateway bietet exaktes und semantisches Caching, RBAC, Budgets, Ratenbegrenzungen und Guardrails. Es lässt sich als SaaS, in Ihrer VPC, On-Premise oder in Air-Gapped-Umgebungen bereitstellen, ist SOC 2-, HIPAA- und ITAR-konform und wird im Gartner Market Guide für AI Gateways geführt. Lesen Sie die Dokumentation zu Routing und Load-Balancing oder die Übersicht zum AI Gateway für weitere Details.

Referenzen

• TrueFoundry AI Gateway – Routing, Load-Balancing und Fallbacks
• Anthropic – Claude API-Preise (Haiku / Sonnet / Opus Tarife)
• OpenAI – API-Preise und Modelle
• Unsere Beiträge zu Kostenzuordnung und Multi-Provider-Failover – zur Kostenaufschlüsselung pro Route und dem Verfügbarkeits-Gegenstück zum Routing.

Northwind und Omar dienen lediglich der Veranschaulichung. Modellnamen und Preise pro Token spiegeln die öffentlichen Preislisten der Anbieter mit Stand Juni 2026 wider und können sich ändern. Die Zahlen zu Kosten und Latenz – wie die etwa 5-fache Preisdifferenz, das Beispiel mit 70 % günstigerer Auflösung oder der Embedding-Overhead von 5–20 ms – sind repräsentative Annahmen zur Verdeutlichung der Kompromisse und keine exakten Messwerte. Testen Sie Routing-Strategien unbedingt mit Ihrem eigenen Traffic und Ihren Evaluierungs-Sets, bevor Sie diese produktiv einsetzen.