LLM Gateway vs. Router vs. Inference Provider: Die Architektur-Grenze

Ein LLM-Gateway, ein Router und ein Inference Provider sind drei verschiedene Ebenen im Model-Serving-Stack. Diese zu verwechseln, ist der häufigste Fehler, den Teams bei der Architektur von KI-Produkten machen. Das Gateway befindet sich am nächsten an Ihrer Anwendung und kümmert sich um Authentifizierung, Normalisierung und Observability; der Router entscheidet, welches Modell oder welcher Provider eine bestimmte Anfrage bearbeitet; der Inference Provider ist die Instanz, die tatsächlich die Gewichte ausführt und Tokens zurückgibt.

Wenn diese Grenze falsch gezogen wird, führt dies zu instabilen Integrationen: Teams hardcodieren das SDK eines einzelnen Providers und stellen Monate später fest, dass das Hinzufügen eines Fallback-Modells oder der Kostenvergleich zwischen Claude Sonnet 5, GPT-5.5 und DeepSeek V4 Flash bedeutet, große Teile ihrer Anforderungsverarbeitung neu schreiben zu müssen. Dieser Artikel trennt die drei Ebenen, zeigt, wo die Verantwortlichkeiten tatsächlich liegen, und bietet einen Entscheidungsrahmen für die Bewertung von Anbietern in jeder Kategorie.

Wichtige Erkenntnisse

• Ein Inference Provider führt die Modellgewichte aus und stellt eine API bereit (OpenAI, Anthropic, Google, DeepSeek oder eine selbst gehostete Engine wie vLLM); ein Router wählt pro Anfrage zwischen Providern oder Modellen aus; ein Gateway ist die anwendungsorientierte Ebene, die Authentifizierung, Formatierung, Logging und Failover über beide hinweg vereinheitlicht.
• Routing-Logik (kostenbasierte, latenzbasierte oder fähigkeitsbasierte Auswahl) kann als eigenständiger Dienst oder als Funktion innerhalb eines Gateways existieren; sie ist nicht dasselbe wie das Gateway selbst.
• Das Selbst-Hosting eines Inference Providers, die Nutzung eines API-basierten Providers und die Verwendung eines Multi-Provider-Gateways schließen sich nicht gegenseitig aus; Produktionssysteme kombinieren oft alle drei, abhängig von Modell und Workload.
• Bewerten Sie Anbieter, indem Sie fragen, auf welcher Ebene sie tatsächlich operieren, da ein Produkt, das als „Router“ vermarktet wird, möglicherweise nur zwischen OpenAI-kompatiblen Endpunkten routet, die es nicht selbst hostet, während ein „Gateway“ Routing plus Governance-Funktionen bündeln kann, die Sie noch nicht benötigen.

Was ein Inference Provider tatsächlich tut

Der Inference Provider ist die Ebene, der die Modellgewichte, die GPUs (oder gleichwertige Beschleuniger) und die Low-Level-Serving-Engine gehören. Dazu gehören kommerzielle API-Anbieter wie Anthropic (Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5), OpenAI (GPT-5.5), Google (Gemini 3.5 Flash), Zhipu (GLM-5.2) und DeepSeek (DeepSeek V4 Pro, DeepSeek V4 Flash) sowie selbst gehostete Deployments von Open-Weight-Modellen wie Qwen3.7 Plus, MiniMax M3 oder Kimi K2.7 Code.

Wenn Sie selbst hosten, ist die Inference-Provider-Ebene Software, die Sie selbst betreiben. Die Serving-Dokumentation von vLLM beschreibt eine Inference-Engine, die auf Continuous Batching und speichereffizienter Attention-Verarbeitung basiert, um LLM-Workloads in großem Maßstab bereitzustellen – dies ist die Art von Komponente, die direkt unter einem selbst gehosteten Modell-Deployment sitzt. Der Betrieb von vLLM (oder einer vergleichbaren Engine) macht Sie zum Inference Provider für dieses Modell, verantwortlich für GPU-Kapazitätsplanung, Skalierung und Uptime, im Austausch für die Kontrolle über Kosten und Datenlokalität.

Wenn Sie eine kommerzielle API nutzen, werden die Infrastruktur und die Rate Limits des Providers zu Ihrer Einschränkung. Jeder Provider hat sein eigenes Authentifizierungsschema, Anforderungs- und Antwortschema, Fehlercodes und Rate-Limit-Verhalten. Dies ist die Ebene, auf der Modellqualität, Kontextfenster und rohe Latenz tatsächlich bestimmt werden. Kein Router oder Gateway kann ändern, wozu ein Inference Provider fähig ist; sie ändern nur, wie Sie ihn erreichen.

Was ein Router tut

Ein Router ist eine Entscheidungslogik, die ein Ziel, ein Modell oder einen Provider für eine eingehende Anfrage auswählt. Routing kann auf mehreren Achsen erfolgen: Kosten (einfache Anfragen an ein günstiges Modell wie DeepSeek V4 Flash oder Gemini 3.5 Flash senden, Claude Opus 4.8 für komplexe Anfragen reservieren), Latenz (den Provider bevorzugen, der für ein gegebenes Modell aktuell am schnellsten antwortet) oder Verfügbarkeit (Failover auf einen zweiten Provider, falls der erste beeinträchtigt ist).

Die öffentliche Erklärung von OpenRouter zum Modell-Routing beschreibt dieses Muster auf Modellebene: Anfragen für ein Open-Weight-Modell können über mehrere Provider geroutet werden, die dieselben Gewichte hosten, sodass ein einzelner logischer Modellaufruf von einem von mehreren Backends erfüllt werden kann. Die Dokumentation zur Provider-Auswahl von OpenRouter beschreibt zudem Parameter zur Angabe von Reihenfolge-Präferenzen und zum Ausschluss spezifischer Provider, was der Mechanismus ist, mit dem ein Aufrufer die Routing-Absicht explizit ausdrückt, anstatt sie vollständig der Plattform zu überlassen.

Der wichtige architektonische Punkt ist, dass Routing eine Richtlinie ist, keine Produktkategorie für sich. Sie können grundlegendes Routing selbst im Anwendungscode implementieren (ein einfaches if/else basierend auf dem Aufgabentyp oder eine Retry-on-Error-Schleife), es als dedizierte Routing-Ebene kaufen oder es gebündelt innerhalb eines breiteren Gateways erhalten. Bewerten Sie die Routing-Fähigkeit, indem Sie fragen, welche Signale sie verwendet (Preis, Latenz, Fehlerrate, Modellfähigkeit) und ob diese Signale konfigurierbar oder fest sind.

Was ein Gateway tut

Ein Gateway ist die Ebene, mit der Ihr Anwendungscode tatsächlich kommuniziert. Seine Aufgabe ist es, eine konsistente Schnittstelle bereitzustellen, unabhängig davon, welcher Inference Provider die Anfrage letztendlich bedient. Ein Gateway umfasst typischerweise:

• Ein einheitliches Anforderungs- und Antwortschema über Provider hinweg, sodass der Wechsel von GPT-5.5 zu Claude Sonnet 5 kein Umschreiben Ihrer Parsing-Logik erfordert.
• Authentifizierung und Schlüsselverwaltung, sodass Provider-Anmeldeinformationen nicht über den Anwendungscode verstreut sind.
• Logging, Nutzungsverfolgung und Kostenzuordnung über jedes verwendete Modell und jeden Provider hinweg.
• Failover- und Retry-Verhalten, wenn ein Provider langsam ist, ein Rate-Limit erreicht oder einen Fehler zurückgibt.
• Optional: Routing-Logik als ein Feature unter mehreren, anstatt als das gesamte Produkt.

Die Modellforschungsseite von TokenLab katalogisiert aktuelle Modelle über Provider hinweg, einschließlich Frontier-Modellen (Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5, GPT-5.5, GLM-5.2, Gemini 3.5 Flash), coding-orientierten Modellen (Claude Sonnet 5, Kimi K2.7 Code, DeepSeek V4 Pro, DeepSeek V4 Flash) und kostengünstigen Routing-Kandidaten (DeepSeek V4 Flash, GLM-5.2, Laguna XS 2.1, Hy3, Qwen3.7 Plus, MiniMax M3). Dies ist die Art von Referenz, die ein Gateway-Nutzer benötigt, wenn er entscheidet, wohin geroutet werden soll. Siehe den Artikel von TokenLab darüber, warum ein einheitliches KI-API-Gateway im Jahr 2026 wichtig ist, für eine umfassendere Behandlung des Vereinheitlichungsproblems selbst.

Die Architektur-Grenze, konkret

Die Grenze lässt sich am einfachsten erkennen, indem man eine einzelne Anfrage durch alle drei Ebenen verfolgt.

1. Ihre Anwendung sendet eine Chat-Completion-Anfrage an den Gateway-Endpunkt und spezifiziert einen Aufgabentyp oder eine Modellpräferenz.
2. Das Gateway authentifiziert die Anfrage, normalisiert sie in das erwartete Schema jedes in Frage kommenden Providers und übergibt sie an die Routing-Logik.
3. Der Router bewertet seine konfigurierte Richtlinie (Kostenobergrenze, Latenzziel oder explizite Provider-Reihenfolge) und wählt ein Ziel aus, zum Beispiel Claude Sonnet 5 über die API von Anthropic oder eine selbst gehostete DeepSeek V4 Pro-Instanz, die über vLLM bereitgestellt wird.
4. Der Inference Provider führt das Modell aus und gibt Tokens zurück.
5. Das Gateway normalisiert die Antwort zurück in eine konsistente Form und protokolliert das Ergebnis (Latenz, Kosten, verwendeter Provider, Erfolg oder Fehler) für Ihre Observability-Ebene.

Jede Ebene kann unabhängig ausfallen. Ein Provider-Ausfall ist ein Problem der Inference-Ebene; eine schlechte Routing-Entscheidung (Senden von Anfragen mit langem Kontext an ein Modell mit kleinem Kontextfenster) ist ein Problem der Router-Ebene; ein inkonsistentes Antwortschema, das Ihren Parser beschädigt, ist ein Problem der Gateway-Ebene. Zu verstehen, welche Ebene einen bestimmten Fehler verursacht hat, macht das Debugging handhabbar. Der Artikel von TokenLab über Zuverlässigkeitsinfrastruktur für KI-APIs behandelt die Fehlerisolierung über diese Ebenen hinweg detaillierter.

Entscheidungs-Checkliste

Verwenden Sie diese Checkliste, wenn Sie bewerten, ob Sie ein Gateway, einen Router, eine direkte Provider-Integration oder eine Kombination benötigen.

Frage	Wenn ja	Wenn nein
Nutzen Sie heute mehr als ein Modell oder einen Provider oder erwarten Sie dies innerhalb von 12 Monaten?	Sie benötigen eine Gateway- oder Router-Ebene, keine direkten SDK-Aufrufe pro Provider.	Eine direkte Provider-SDK-Integration kann kurzfristig ausreichen.
Benötigen Sie automatisches Failover, wenn ein Provider beeinträchtigt oder ratenbegrenzt ist?	Sie benötigen Logik auf Router-Ebene mit Health-Checks und Fallback-Reihenfolge.	Manuelle Retries im Anwendungscode können anfangs akzeptabel sein.
Benötigen Sie modellgenaue Kosten- und Nutzungstransparenz über Provider hinweg an einem Ort?	Sie benötigen Logging und Zuordnung auf Gateway-Ebene.	Provider-eigene Dashboards decken Ihre Bedürfnisse möglicherweise vorerst ab.
Hosten Sie selbst Open-Weight-Modelle (GLM-5.2, DeepSeek V4 Pro, Qwen3.7 Plus, Kimi K2.7 Code)?	Sie betreiben auch eine Inference-Provider-Ebene und benötigen Serving-Infrastruktur wie vLLM.	Sie können sich vollständig auf kommerzielle API-Provider verlassen.
Müssen Sie nach Aufgabentyp routen (günstiges Modell für Klassifizierung, Frontier-Modell für Reasoning)?	Sie benötigen eine explizite Router-Richtlinie, nicht nur Failover.	Ein einzelnes Standardmodell kann ausreichen.

Beispiel für die Anforderungsstruktur

Das folgende Beispiel veranschaulicht die allgemeine Struktur einer Anfrage im Gateway-Stil, die sowohl eine primäre Modellpräferenz als auch eine Fallback-Liste ausdrückt – ein Muster, das damit übereinstimmt, wie die Dokumentation zur Provider-Auswahl von OpenRouter das Ausdrücken von Routing-Präferenzen beschreibt. Betrachten Sie Feldnamen als illustrativ; überprüfen Sie die genauen Parameter anhand der aktuellen API-Referenz Ihres gewählten Gateways, bevor Sie produktiv gehen.

POST /v1/chat/completions
Content-Type: application/json
Authorization: Bearer <api_key>

{
  "model": "claude-sonnet-5",
  "fallback_models": ["gpt-5.5", "deepseek-v4-flash"],
  "routing_policy": {
    "strategy": "cost_then_latency",
    "max_cost_per_1k_tokens": 0.01
  },
  "messages": [
    {"role": "user", "content": "Summarize the attached incident report."}
  ]
}

In dieser Struktur ist das Gateway für die Anforderungsnormalisierung und den Antwortvertrag verantwortlich, der Router für die Interpretation von routing_policy und fallback_models, und welcher Provider letztendlich ausgewählt wird, ist für die tatsächliche Generierung der Completion verantwortlich. Bestätigen Sie das genaue Anforderungs- und Antwortschema anhand der aktuellen Dokumentation, bevor Sie sich in der Produktion auf einen bestimmten Feldnamen verlassen.

Einschränkungen

Die öffentliche Dokumentation von OpenRouter und vLLM beschreibt allgemeine Routing- und Serving-Mechanismen, keine universellen Garantien. Die genaue Latenz, Preisgestaltung und das Failover-Verhalten variieren je nach Provider und ändern sich im Laufe der Zeit. Überprüfen Sie daher aktuelle Zahlen direkt anhand der Provider-Dokumentation und nicht anhand dieses Artikels. Selbst-Hosting mit vLLM verlagert die betriebliche Verantwortung (Kapazitätsplanung, Skalierung, Patching) auf Ihr Team; es eliminiert keine Infrastrukturarbeit, es verlagert sie. Keine Routing-Richtlinie kann eine grundlegend falsch gewählte Modellentscheidung kompensieren, wie z. B. das Senden einer Aufgabe, die Reasoning mit langem Kontext erfordert, an ein Modell, das dafür nicht geeignet ist; die Router-Konfiguration ist kein Ersatz für die Bewertung der Modellfähigkeit gegenüber Ihrem Workload, weshalb die Pflege einer aktuellen Modellreferenz wie TokenLabs Modellforschung wichtig ist.

FAQ

Ist ein Gateway dasselbe wie ein Router? Nein. Ein Router ist eine Entscheidungslogik zur Auswahl eines Modells oder Providers; ein Gateway ist die breitere anwendungsorientierte Ebene, die Routing als eine mögliche Funktion neben Authentifizierung, Normalisierung und Logging beinhaltet.

Kann ich mein eigener Inference Provider sein und trotzdem ein Gateway nutzen? Ja. Selbst gehostete Modelle, die über eine Engine wie vLLM bereitgestellt werden, können hinter demselben Gateway wie kommerzielle API-Provider sitzen, solange das Gateway benutzerdefinierte oder OpenAI-kompatible Endpunkte unterstützt.

Benötige ich alle drei Ebenen vom ersten Tag an? Nicht unbedingt. Eine direkte Integration eines einzelnen Providers ist für einen frühen Prototyp angemessen. Sobald Sie Failover, Kostenkontrolle für mehrere Modelle oder einen Provider-Vergleich benötigen, wird die Einführung eines Gateways mit Routing den technischen Aufwand wert.

Wenn Sie bewerten, welche Ebene Sie zuerst einführen sollten, überprüfen Sie die aktuellen Modelloptionen auf TokenLabs Modellforschungsseite und beginnen Sie mit einem Gateway-Setup, das es Ihnen ermöglicht, Routing und Provider schrittweise hinzuzufügen, anstatt sich im Voraus auf eine einzige Integration festzulegen.