Was ist ein LLM-Gateway? Aufgabe, Bestandteile, Marktstand Mai 2026

Was ist ein LLM-Gateway?

Ein LLM-Gateway ist eine Software-Schicht zwischen Ihrer Anwendung und den Sprachmodell-APIs (OpenAI, Anthropic, Google, Mistral, Cohere, lokales Ollama). Statt dass jede Anwendung direkt mit jedem Anbieter spricht, schickt sie alle Anfragen an ein zentrales Gateway. Das Gateway entscheidet, welches Modell die Anfrage erhält, prüft Berechtigungen, begrenzt Volumen, dokumentiert Kosten und fängt Ausfälle ab.

Der Begriff ist seit 2024 etabliert und gilt Mai 2026 als Standard-Baustein für Enterprise-AI. Die bekanntesten Projekte sind LiteLLM (Open-Source, BerriAI, Apache 2.0), OpenRouter (gehostet, Marketplace mit über 200 Modellen), Portkey (gehostet, mit Caching und Guardrails), Cloudflare AI Gateway (gehostet, in Cloudflare-Workers-Plattform), AWS Bedrock (gehostet, Provider eines eigenen Modell-Marktplatzes) und Azure OpenAI Service (gehostet, primär für OpenAI-Modelle). Jedes Projekt deckt einen ähnlichen Funktionskern ab, unterscheidet sich aber in Hosting-Modell, unterstützten Modellen und Compliance-Eigenschaften.

Das Prinzip stammt aus dem klassischen API-Gateway-Muster: ein zentraler Punkt für Auth, Routing, Telemetrie. Was beim klassischen API-Gateway HTTP-Endpunkte sind, sind beim LLM-Gateway Modell-Aufrufe – semantisch gleich, technisch mit Eigenheiten (Streaming, Token-Counting, lange Antwortzeiten, Modell-Versionen).

Warum es relevant ist

Ohne Gateway entsteht in einer wachsenden AI-Anwendung schnell Wildwuchs: jede Anwendung hat ihre eigenen API-Keys, ihre eigene Fehlerbehandlung, ihre eigene Kostenlogik. Es gibt keine zentrale Sicht darauf, was wirklich konsumiert wird – und keine zentrale Steuerung im Notfall. Fünf konkrete Probleme treten regelmässig auf, die ein Gateway löst.

Erstens: Key-Sprawl. Ohne Gateway hat jede Anwendung ihren eigenen API-Key. Verlässt ein Mitarbeitender das Unternehmen, muss man wissen, welche Keys mit welcher Anwendung verknüpft sind – eine fast immer luckenhafte Erfassung. Ein Gateway bietet virtuelle Keys: jede Anwendung bekommt einen internen Key, der gegen den Master-Key des Anbieters validiert wird, mit eigenem Budget und eigenen Rechten.

Zweitens: keine Kostenkontrolle. Sprachmodell-Kosten sind nutzungsabhängig und können explodieren (Endlosschleife in Agent, fehlerhafter Batch-Job). Ein Gateway erzwingt harte Limits – pro Key, pro Nutzer, pro Tag, pro Modell. Überschreiten löst Alarm oder Block aus, nicht eine Monatsrechnung im fünfstelligen Bereich.

Drittens: keine Multi-Provider-Fähigkeit. Sobald Sie aus regulatorischen Gründen zwei Anbieter brauchen (z.B. Mistral-EU für Mandantendaten + Claude für Spezialaufgaben), muss die Anwendung pro Aufruf entscheiden, welcher Anbieter passt. Das ist Geschäftslogik, die nicht in jede Anwendung gehört – sondern ins Gateway.

Viertens: keine Resilienz. OpenAI-Ausfälle dauern manchmal Stunden. Ohne Gateway steht die Anwendung still. Mit Gateway läuft ein Fallback-Plan: probiere Claude, wenn das auch ausfällt, dann Gemini, sonst lokales Ollama als Notbetrieb. Auf Anwendungsebene ist das nicht erkennbar.

Fünftens: keine Audit-Spur. Für Compliance (revDSG, EU AI Act Art. 12, Berufsgeheimnis StGB 321) brauchen Sie die Antwort: wer hat wann welches Modell mit welchem Prompt aufgerufen, was kam zurück, wie lange hat es gedauert. Auf der Ebene der Anwendung ist dieser Log meist unvollständig. Im Gateway ist er Pflichtbestandteil.

Funktionen im Detail

Ein vollwertiges LLM-Gateway implementiert sieben Funktionsgruppen.

1. Multi-Provider-Routing. Eine einheitliche API (typischerweise im OpenAI-Chat-Completions-Format) wird auf verschiedene Anbieter abgebildet. LiteLLM unterstützt Mai 2026 über 100 Anbieter – von OpenAI über Anthropic, Google, Mistral bis zu Open-Source-Modellen via Ollama, vLLM, TGI. Die Anwendung schreibt einmal in der OpenAI-Syntax, das Gateway übersetzt zur Laufzeit.

2. Auth und virtuelle Keys. Statt dass Anwendungen die echten Provider-Keys kennen, bekommen sie einen internen Schlüssel vom Gateway. Pro Schlüssel: Budget (z.B. CHF 200/Monat), erlaubte Modelle, erlaubte Endpunkte, Rate-Limits. Wird der Schlüssel kompromittiert, deaktiviert man ihn im Gateway – die Provider-Keys bleiben unverändert.

3. Rate-Limiting. Pro Schlüssel oder pro Nutzer ein Limit: Requests pro Minute, Tokens pro Minute. Verhindert versehentliche oder bösartige Last-Spitzen.

4. Fallback-Chain. Pro logischem Modell-Namen eine geordnete Liste echter Modelle. Beispiel: "smart-de" -> primary: claude-4.7-sonnet, fallback: gpt-4.1, last-resort: mistral-large-eu. Bei 429-Fehler oder Timeout schaltet das Gateway transparent weiter. Die Anwendung sieht nur "smart-de", nie die einzelnen Modell-Namen.

5. Observability. Pro Request ein strukturierter Log-Eintrag: Zeitstempel, Schlüssel, Modell, Input-Tokens, Output-Tokens, Latenz, Kosten (in USD/CHF), Erfolg/Fehler. Mai 2026 exportieren alle Gateways Prometheus-Metriken und tragen via OpenTelemetry in Grafana, Datadog oder eigene Stacks ein.

6. Cost-Tracking. Pro Schlüssel, pro Modell, pro Zeitraum eine Abrechnung. Wichtig: Provider veröffentlichen Preise pro Modell, das Gateway hält die Preistabelle aktuell. Bei Preisänderung (z.B. OpenAI hat Mai 2026 GPT-4o auf -25% gesenkt) zieht das Gateway nach – die Anwendung muss nichts ändern.

7. Caching, Guardrails, weitere Funktionen. Optional, aber Mai 2026 oft mitgeliefert: Antwort-Caching für wiederholte identische Prompts (LiteLLM-Cache, Portkey, Cloudflare AI Gateway), PII-Filter, Prompt-Injection-Filter, Policy-Engine für Inhalte. Diese Schicht wächst rasch und wird in 2026/27 zu einem zentralen Compliance-Werkzeug.

Gateway-Auswahl in 5 Schritten

1. 01Anforderungen klären: wie viele Anbieter, wie viele Anwendungen, welche Compliance-Vorgaben (revDSG, EU AI Act, FINMA), welches Hosting-Modell?
2. 02Self-hosted oder managed entscheiden: Self-hosted (LiteLLM) für Daten-Souveränität und Kostenkontrolle; managed (OpenRouter, Portkey, Cloudflare AI Gateway) für schnelle Inbetriebnahme.
3. 03Funktionsdeckung prüfen: virtuelle Keys, Rate-Limit, Fallback-Chain, Audit-Log, Cost-Tracking, optional Caching und Guardrails. Mai 2026 decken alle Hauptprodukte den Kern ab.
4. 04Pilot mit zwei Anbietern: einer für Standard, einer für Fallback. Eine Anwendung migrieren. Latenz, Logs, Kosten messen.
5. 05Ausrollen: alle Anwendungen auf das Gateway umstellen, virtuelle Keys pro Anwendung vergeben, Monitoring in Grafana einbinden, Alerts in Telegram/Slack.

Wann ein Gateway sich lohnt

Faustregel: ab zwei Modellen oder ab zwei produktiven Anwendungen lohnt sich der Gateway-Aufwand. Mai 2026 ist es der Standard für jede AI-Lösung, die über einen einzelnen Prototypen hinausgeht.

Konkrete Auslosepunkte: (a) Sie nutzen produktiv mehrere Modelle (z.B. GPT-4 für Standardfälle, Claude für Lange-Kontext-Aufgaben, Mistral-EU für Mandantendaten). (b) Sie betreiben zwei oder mehr AI-Anwendungen (Chat-Tool intern, RAG-Assistent für Mandanten, Automatisierungs-Pipeline). (c) Compliance-Anforderungen (revDSG-DSFA, EU AI Act Art. 12-Logging, Berufsgeheimnis-Audit) verlangen zentrale Audit-Spur. (d) Sie wollen Kostenkontrolle pro Team, pro Mandant, pro Projekt. (e) Sie planen eine Anbieter-Strategie mit Ausweich-Option (Resilienz-Architektur).

Ein Gateway lohnt sich besonders dann, wenn das Risiko eines Anbieter-Ausfalls hoch ist. OpenAI-Inzidenz-Geschichte 2024-2026 zeigt mehrere mehrstündige Ausfälle. Eine Anwendung mit Gateway und Fallback lief in jedem dieser Fälle weiter; eine ohne stand still.

Self-hosted versus managed: LiteLLM läuft auf Hetzner-EU oder Cloudron-Server. Wer keine Lust hat, ein weiteres Service-Bauteil zu betreiben, nimmt OpenRouter, Portkey oder Cloudflare AI Gateway. Compliance-Präferenz: Self-hosted (LiteLLM) ist die revDSG-konformere Variante, weil keine Daten an Dritte gehen – aber managed-Gateways haben zunehmend EU-Optionen.

Wann KEIN Gateway

Drei klare Fälle, in denen ein Gateway übersteuert ist.

Erstens: einzelner Prototyp, einzelner Nutzer, einzelnes Modell. Ein Streamlit-Demo, ein Jupyter-Notebook für ein Forschungsprojekt – hier bringt das Gateway Komplexität ohne Nutzen. Direkter Aufruf der Provider-SDK reicht.

Zweitens: streng on-premise mit nur einem lokalen Modell. Wer ausschliesslich Ollama oder vLLM auf eigener Hardware betreibt und keine Cloud-Modelle nutzt, kann die Modell-Server direkt ansprechen. Ein Gateway davor lohnt sich erst, wenn mehrere Modelle gewechselt werden oder die Audit-Anforderungen es verlangen.

Drittens: kritische Sub-Millisekunden-Latenz. Ein Gateway fügt 5-20 ms Latenz hinzu (lokal) bzw. 50-150 ms (managed). Für typische Chat-Anwendungen ist das irrelevant (Generierungszeit dominiert). Für Inline-Code-Completion in einer IDE oder Voice-Agent mit Echtzeit-Anforderung kann diese Latenz spürbar werden – dann direkter SDK-Aufruf oder ein Gateway als sehr leichter Proxy ohne Caching/Guardrails.

Achtung Fallstrick: ein selbst betriebenes Gateway ist eine zusätzliche Komponente, die ausfallen kann. Wer LiteLLM einsetzt, betreibt damit auch LiteLLM – mit Health-Checks, Updates, Backups. Bei Single-Person-Setups mit wenig Ops-Kapazität ist ein managed-Gateway (OpenRouter, Portkey) oft die ruhigere Wahl.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. LiteLLM – Documentation (BerriAI, Apache 2.0) · 2026-05
2. OpenRouter – Model Marketplace and Gateway · 2026-05
3. Cloudflare AI Gateway – Documentation · 2026-04
4. Portkey – AI Gateway with Guardrails · 2026-03