LLM Gateway: Was es ist und wann Unternehmen eins brauchen

Pexon Consulting | 11 Min. Lesezeit | 19.06.2026

TL;DR

Ein LLM Gateway ist die zentrale Routing- und Governance-Schicht zwischen euren Anwendungen und LLM-Providern wie OpenAI, Anthropic, Azure OpenAI oder Open-Source-Modellen — quasi ein API-Gateway für Sprachmodelle. Pexon Consulting baut LLM-Gateway-Setups als 2-3-Wochen-Festpreis-Sprint zwischen 28 und 48k EUR mit Kostenkontrolle, DSGVO-Routing und Audit-Trail. Pflicht ab 200+ aktiven AI-Nutzern oder mehreren parallelen Use-Cases.

Was ein LLM Gateway konkret macht

Wir hören das oft in CIO-Erstgesprächen mit Mittelständlern, die ihre ersten 3-4 AI-Use-Cases produktiv haben: „Plötzlich nutzen 8 Teams OpenAI direkt aus ihren Apps, niemand weiß was wir monatlich verbrauchen, und der Datenschutzbeauftragte fragt zum dritten Mal nach Audit-Logs.“

Genau diese Lage löst das LLM-Gateway-Pattern. Statt dass jede Anwendung direkt mit OpenAI, Anthropic, Mistral oder Azure OpenAI spricht, läuft jede Anfrage durch eine zentrale Routing-Schicht. Diese Schicht entscheidet welches Modell die Anfrage bearbeitet, schreibt jeden Aufruf in einen Audit-Trail, prüft Token-Budgets und maskiert PII bevor die Daten den US-Cloud-Anteil sehen.

Die Analogie für IT-Leiter: Ein klassisches API-Gateway (Kong, Apigee, AWS API Gateway) plus LLM-spezifische Funktionen. Statt nur Auth, Rate-Limiting und Routing — auch Token-Counting, Modell-Fallback, Prompt-Caching, Response-Streaming, semantische Cache-Schicht.

Vier Kern-Funktionen, die ein LLM Gateway leistet.

# Vorher: Direkte API-Calls in jeder App
import openai
client = openai.OpenAI(api_key="sk-...")
response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": user_input}]
)

# Nachher: Anfrage über Gateway (z.B. LiteLLM-Proxy)
import openai
client = openai.OpenAI(
    api_key="virtual-team-key-789",
    base_url="https://llm-gateway.pexon-internal.de/v1"
)
response = client.chat.completions.create(
    model="default-german-llm",  # Gateway routet zu Azure DE oder Mistral
    messages=[{"role": "user", "content": user_input}]
)

Der Anwendungs-Code ändert sich kaum. Aber alles dahinter — Modell-Wahl, Region-Lock, Cost-Tracking, Audit-Trail — ist zentral konfiguriert.

Wann ihr eins braucht — und wann nicht

Hier ist die ehrliche Schwellen-Bewertung aus 14+ produktiven Pexon-Setups.

Ihr braucht KEIN Gateway, wenn: Ihr habt 1-2 AI-Anwendungen mit weniger als 50 aktiven Nutzern, alle gegen denselben Provider, kein Compliance-Druck. Ein Gateway wäre Over-Engineering. Direkte API-Calls reichen.

Ihr braucht ein Gateway sobald:

• 200+ aktive AI-Nutzer über mehrere Anwendungen hinweg. Ab dieser Schwelle wird Cost-Sichtbarkeit ohne zentralen Layer praktisch unmöglich. Wer in Apps verteilt API-Keys nutzt, sieht den Verbrauch erst in der monatlichen Rechnung.
• Mehrere Provider parallel (z.B. OpenAI für Coding, Anthropic für komplexe Reasoning, Azure für DSGVO-Workloads). Ohne Gateway müsst ihr in jeder App diese Provider-Logik nachbauen.
• Compliance-Druck durch BaFin, NIS2, KRITIS oder DSGVO. Spätestens dann ist der Audit-Trail nicht optional.
• Cost-Surprises: Wenn der erste OpenAI-Monat unerwartet 12.000 EUR statt 800 EUR kostet, weil ein Endlos-Loop in einer App gelandet ist. Gateway mit Hard-Limits verhindert das.
• DSGVO-Routing-Anforderung: Daten aus HR oder Vertragsmanagement dürfen nur in EU-gehostete Modelle, der Rest darf zu OpenAI. Pro App eigene Logik wäre Pflegehölle.

Praktischer Daumenwert: Sobald ihr 3+ AI-Apps oder 5+ Engineering-Teams mit AI-Zugang habt, ist das Gateway die richtige Architektur. Mehr zu konkreten LLM-Routing-Pattern mit LiteLLM als Implementierung.

Die wichtigsten Funktionen im Detail

Modell-Routing. Pro Use-Case, pro Team, pro Anfrage-Typ definiert ihr im Gateway welches Modell ausgeführt wird. Beispiel: Coding-Anfragen → GPT-4o, Reasoning-intensive Tasks → Claude Sonnet, DSGVO-sensitive Workloads → Mistral Large auf Azure DE. Der Anwendungs-Code spricht nur „ki-coding“ oder „ki-vertraulich“ — das Gateway entscheidet.

Kostenkontrolle und Budgets. Pro virtuellem API-Key (typisch pro Team) ein hartes Monatsbudget. Bei 80% Verbrauch wird der Team-Lead per Slack gewarnt, bei 100% werden weitere Anfragen abgelehnt. Verhindert die Cost-Surprise-Rechnung am Monatsende.

Multi-Provider-Fallback. Wenn OpenAI eine Stunde down ist (passiert 4-7 Mal pro Jahr), routet das Gateway auf Anthropic oder Azure. Anwendungen merken davon nichts — die kritischen Use-Cases laufen weiter.

Audit-Trail. Jede Anfrage mit Timestamp, User-ID, Tenant-ID, Prompt-Hash, Modell-Wahl, Token-Verbrauch, Latenz. Das ist das Artefakt, das BaFin- und BSI-Auditoren sehen wollen. Mehr zur breiten AI-Landing-Zone für KRITIS-Setups.

Caching. Identische oder semantisch ähnliche Anfragen werden aus dem Cache beantwortet. Bei typischen Knowledge-Bot-Setups senkt das die Kosten um 25-45%, plus reduziert die Latenz auf unter 100 ms.

Rate-Limiting und Quoten. Pro Team, pro Anwendungs-Endpunkt, pro Stunden- und Tagesbudget. Schützt vor versehentlichen Endlos-Loops und absichtlichem Missbrauch.

Die Marktlage 2026 ehrlich

Drei reale Optionen für die Implementierung.

LiteLLM ist der Open-Source-Standard. Self-hosted oder als Managed Cloud, 100+ Provider-Konnektoren, sehr aktive Community. Pexon-Default für die meisten Mittelstands-Setups. Mehr zur konkreten Implementierung im LiteLLM-Router-Pattern.

Portkey, Kong AI Gateway sind die kommerziellen Alternativen. Mehr Out-of-the-Box-Features bei Observability und Enterprise-SLA, aber teurer und Vendor-Lock-in. Wir machen den Vergleich konkret im LiteLLM vs Portkey vs Kong-Vergleich.

Eigenbau auf Basis von Reverse-Proxy + Custom-Logik. Bei einigen Konzernen mit großen Engineering-Teams gesehen. Funktioniert, ist aber 6-12 Monate Engineering-Aufwand und braucht laufende Wartung. Selten wirtschaftlich gegenüber LiteLLM.

Unsere klare Empfehlung für Mittelstand: LiteLLM als Open-Source-Basis, plus Pexon-Setup für Configuration, Audit-Pipeline und Compliance-Layer. Damit habt ihr keinen Lock-in und die Kosten bleiben kalkulierbar.

Pexon-Sprint und Investment

2-3-Wochen-Festpreis-Sprint:

• Woche 1 — Discovery und Konfiguration. Provider-Inventur, Use-Case-Mapping, Audit-Anforderungen, Cost-Budget-Struktur. Initial-Setup LiteLLM oder Portkey je nach Entscheidung.
• Woche 2 — Migration und Compliance-Layer. Anwendungen werden auf den Gateway umgezogen (typisch 30-60 Minuten Code-Change pro App), Audit-Trail-Pipeline an euer SIEM angebunden, DSGVO-Routing-Regeln aktiviert.
• Woche 3 — Schulung und Übergabe. Engineering-Teams plus Compliance-Officer-Schulung, Doku, Übergabe.

Investment-Festpreis: 28-48k EUR je nach Komplexität. Untere Spanne bei einfacher Provider-Landschaft (1-2 Provider, einfacher Audit). Obere Spanne bei Multi-Provider-Setup plus DSGVO-spezifischem Routing.

Laufende Cloud-Kosten: LiteLLM-Self-Hosted auf AKS oder Azure App Service: 200-500 EUR pro Monat. Bei Portkey-Cloud-Lizenz zusätzlich nach Volumen.

Häufig gestellte Fragen

Was kostet ein LLM Gateway im Vergleich zu direkten API-Calls?

Ein Gateway hat eigene Infrastruktur-Kosten (200-500 EUR pro Monat self-hosted), spart aber Cost-Surprises und reduziert API-Kosten durch Caching um typisch 25-45%. Bei einem Mittelständler mit 4.000 EUR pro Monat OpenAI-Verbrauch sind das 1.000-1.800 EUR Caching-Einsparung — Gateway-Kosten amortisieren sich im ersten Monat.

LiteLLM oder Portkey oder Kong — welches ist die richtige Wahl?

LiteLLM ist Open-Source mit größter Community und keinem Vendor-Lock-in — unser Default für Mittelstands-Setups. Portkey hat mehr Observability-Features out-of-the-box, ist aber Vendor-gebunden und teurer ab gewissem Volumen. Kong eignet sich nur, wenn ihr Kong ohnehin für klassisches API-Gateway nutzt. Mehr im LiteLLM vs Portkey vs Kong-Detail.

Wie verhält sich ein LLM Gateway zu Azure AI Foundry?

Azure AI Foundry hat eigene Routing-Funktionen für Azure-OpenAI-Modelle und Azure-AI-Services. Wenn ihr 100% Azure-Stack seid und keine non-Azure-Modelle nutzt, kann Foundry reichen. Sobald ihr Anthropic, Mistral, Open-Source oder On-Prem-Modelle einbindet, braucht ihr ein eigenes Gateway. Mehr zur Foundry-Bewertung im DACH-Vergleich.

Wie schnell ist die Latenz mit Gateway versus direkten Aufrufen?

Ein gut konfigurierter LLM Gateway addiert typisch 8-25 ms Latenz pro Anfrage. Bei semantischem Caching sinkt die mittlere Latenz oft sogar gegen direkte API-Calls. In unseren Setups sehen wir keine spürbare Latenz-Beschwerde durch das Gateway selbst.

Was passiert wenn das Gateway ausfällt?

Single-Point-of-Failure-Risiko ist real. In Production-Setups bauen wir mindestens 2 Replicas hinter einem Load Balancer, plus optionaler Multi-Region-Deployment. Mehr zur produktionsreifen Architektur im LiteLLM-Kubernetes-Setup für High Availability.

Nächster Schritt

Wenn dein Unternehmen 3+ AI-Use-Cases produktiv hat und der Kontroll-Verlust schon spürbar wird: Wir machen einen 30-Minuten-Architektur-Call mit dir und idealerweise dem Engineering-Lead. Du beschreibst die Provider- und Use-Case-Lage, wir skizzieren den 2-3-Wochen-Sprint mit Festpreis.

Verwandte Themen