LLM Gateway: Definition, Funktionen und Abgrenzung

Ein LLM Gateway (Large Language Model Gateway) ist eine Vermittlungsschicht zwischen den eigenen Anwendungen und den Sprachmodellen (LLMs, KI-Modelle für Textverarbeitung) verschiedener Anbieter. Statt dass jede Anwendung direkt bei OpenAI, Anthropic oder anderen Anbietern anfragt, gehen alle Anfragen zuerst durch den Gateway. Er entscheidet, welches Modell antwortet, hält Zugangsdaten zentral, zählt die Kosten pro Team und protokolliert alle Anfragen für Audit und Compliance.

Was ist ein LLM Gateway?

Ein LLM Gateway ist eine Zwischenschicht (im Englischen „Middleware") vor dem eigentlichen KI-Modell. Er bietet den Anwendungen eine einheitliche Schnittstelle (API-Endpunkt), hinter der sehr unterschiedliche Modelle stehen können: fertige Modelle aus der Cloud (bei OpenAI, Anthropic, Google, Azure OpenAI oder AWS Bedrock), offene Modelle, die das Unternehmen selbst betreibt, oder eigene, auf interne Daten trainierte Varianten. Die Anwendung spricht immer nur mit dem Gateway und muss weder wissen, welcher Anbieter dahintersteht, noch welche Zugangsdaten (API-Keys) verwendet werden. Als gemeinsame Schnittstellen-Sprache hat sich das OpenAI-kompatible Format durchgesetzt, dadurch lässt sich das dahinterliegende Modell wechseln, ohne dass am Anwendungscode etwas geändert werden muss.

Die Kategorie hat sich 2024 bis 2026 als eigene Plattform-Schicht etabliert, weil produktive LLM-Landschaften parallel mehrere Anwendungen und mehrere Anbieter betreiben. Ohne Vermittlungsschicht entstehen API-Keys, Rate-Limits, Content-Filter, Audit-Logs und Kostenzuordnung pro Anwendung neu, mit divergierendem Verhalten unter Last. Am Markt haben sich verwaltete Plattformen wie Portkey, Tray.ai, Maxim und Helicone als eigenständige Schicht positioniert; Cloud-Anbieter führen den Databricks Mosaic AI Gateway und Azure API Management for AI; Open-Source-Projekte wie LiteLLM, Kong AI Gateway und Envoy AI Gateway besetzen den Eigenbau-Pfad.

Vier Funktionsblöcke tragen einen produktiven Gateway. Routing entscheidet pro Anfrage, welcher Anbieter und welches Modell antwortet: bevorzugter Anbieter mit Fallback bei Ausfall, Latenz-basiertes Load Balancing oder aufgabenbezogenes Modell-Routing (günstiges Modell für Klassifikation, stärkeres für Reasoning). Caching verhindert wiederholte Anfragen an den Anbieter über einen exakten Prompt-Cache und einen semantischen Cache auf Embedding-Basis. Cost und Governance zählen Tokens pro virtuellem Key, setzen Budgets pro Team, halten Rate-Limits, schreiben Audit-Logs mit Prompt und Antwort und wenden PII- sowie Content-Filter an. Observability und Eval liefern Tracing mit Latenz-, Token- und Fehler-Metriken, Hooks für LLM-as-a-Judge-Scores und eine Telemetrie-Anbindung. Über OpenLLMetry hat sich 2026 ein OpenTelemetry-konformes Format für LLM-Calls durchgesetzt, das Backend-Wechsel offen hält.

Der Audit-Trail eines LLM Gateway (Prompt, Antwort, Modell, Token-Verbrauch, Latenz, App-Metadaten) deckt Aufzeichnungsanforderungen aus dem EU AI Act (Artikel 12) sowie BAIT/VAIT- und ISO-42001-Vorgaben auf der Zugriffs-Ebene ab, ohne dass jede Anwendung eigenes Logging aufbaut.

Abgrenzung zu AI Gateway, API-Gateway und Model Serving

Der Begriff wird häufig mit angrenzenden Komponenten verwechselt. Die folgende Tabelle ordnet die Unterschiede ein:

Komponente	Ebene im Stack	Kern-Funktion
LLM Gateway	Vermittlung vor der LLM-Inferenz	Multi-Anbieter-Routing, Caching, Cost & Governance, Observability für LLM-Aufrufe
AI Gateway	Vermittlung vor beliebigen KI-Aufrufen	Breiterer Rahmen als LLM Gateway (bündelt neben LLMs auch Vision-, Audio- und Klassifikations-Modelle)
API-Gateway (klassisch)	Netzwerk-/App-Ebene	Schützt beliebige HTTP-APIs; kennt keine Token-Kosten und keine Prompt-Semantik
Model Serving	Inferenz-Ebene	Hostet die Modell-Inferenz (Endpoint, Skalierung, GPU-Zuweisung); der Gateway ruft es auf
Inference Engine	Runtime im Serving-Endpoint	Optimiert die Modell-Ausführung selbst (vLLM, TensorRT-LLM, SGLang)
Agent Routing	Kontrollfluss in Multi-Agent-Systemen	Verteilt zwischen spezialisierten Agenten oder Rollen, eine Ebene über dem Modell-Routing

„AI Gateway" ist der konzeptuell breitere Begriff. Er bezeichnet dieselbe Vermittlungs-Idee, deckt aber neben LLMs auch andere KI-Modalitäten ab. Ein LLM Gateway ist der eng gefasste Sub-Case, der ausschließlich LLM-Traffic kontrolliert; in Marktkommunikation und Anbieter-Positionierung werden beide Begriffe häufig synonym verwendet.

Ein klassisches API-Gateway wie Kong, NGINX oder Azure API Management kann HTTP-APIs schützen und routen, versteht jedoch keine Prompts, keine Token-Semantik und keine LLM-spezifischen Kostenmodelle. Model Serving liegt eine Ebene tiefer als der Gateway und stellt die eigentliche Inferenz bereit; eine Inference Engine sitzt innerhalb eines Serving-Endpoints und optimiert die Modell-Ausführung. Agent Routing arbeitet oberhalb des Gateway auf semantischer Ebene und entscheidet, welcher Agent den nächsten Schritt macht; die dabei ausgelösten Modell-Aufrufe laufen wieder durch den Gateway.

Beispiel: drei GenAI-Anwendungen mit gemeinsamem Gateway

Ein Unternehmen betreibt drei produktive GenAI-Anwendungen: einen internen Wissensassistenten auf Azure OpenAI, eine Vertragsanalyse auf Anthropic Claude und einen Support-Copilot auf einem selbst-gehosteten Llama-Modell. Ohne LLM Gateway pflegt jedes Team eigene API-Keys, eigene Rate-Limits und eigenes Prompt-Logging. Die Modellrechnung erscheint als Sammelposten pro Anbieter, ohne Zuordnung zu Anwendungsfall oder Kostenstelle. Ein Wechsel des Modells bedeutet Code-Änderungen an der Anwendung.

Mit LLM Gateway laufen die drei Anwendungen gegen einen OpenAI-kompatiblen Endpunkt. Der Gateway prüft ein virtuelles Token pro Team, wendet einen PII-Filter auf Prompts vor externem Anbieter-Aufruf an, cached identische Anfragen, schreibt Prompt und Antwort mit App-ID und Team-Metadaten in ein Audit-Log und ordnet den Token-Verbrauch dem jeweiligen Budget zu. Fällt Anthropic aus, greift eine konfigurierte Fallback-Route auf einen anderen Anbieter; die Anwendung merkt davon nichts. Ein Modellwechsel für die Vertragsanalyse wird als Routing-Regel am Gateway umgestellt, ohne dass die Anwendung angefasst wird.