Pexon Consulting | 10 Min. Lesezeit | 22.05.2026
TL;DR
Ein LLM Gateway ist die Control-Plane zwischen Ihren Apps und OpenAI, Anthropic, Azure OpenAI oder lokalen Modellen. LiteLLM, Portkey und Helicone lösen dasselbe Problem unterschiedlich: einheitliche API, Cost-Tracking pro Team, Caching, Fallbacks und Audit für DORA. Pexon Consulting setzt für DACH-Enterprise meist LiteLLM self-hosted auf AKS — Portkey für Managed-Hybrid, Helicone für Observability-Fokus.
Was ein LLM Gateway tatsächlich macht
Ein LLM Gateway ist ein OpenAI-kompatibler Proxy, durch den sämtlicher LLM-Traffic eines Unternehmens läuft. Statt jede App direkt gegen die OpenAI-API zu programmieren, redet sie mit dem Gateway — und das routet, cached, drosselt, loggt und switcht den Provider. Klingt nach Infrastruktur-Spielerei, ist aber der Hebel, der Token-Kosten halbiert und gleichzeitig DORA-konforme Audit-Logs liefert.
Der Markt liefert die Zahlen, die die Investition rechtfertigen. Menlo Ventures sieht den Enterprise-LLM-Spend zwischen Q4 2024 und Mitte 2025 von 3,5 auf 8,4 Milliarden USD verdoppelt. 37% der Enterprises geben heute über 250.000 USD pro Jahr für LLM-APIs aus, 73% über 50.000 USD. Wer in dieser Größenordnung ohne zentrales Cost-Tracking pro Team operiert, fliegt blind — und merkt erst Quartal später, dass das Dev-Team die Produktionsquota verbrennt.
Drei Probleme lösen LLM Gateways immer wieder: Erstens das Multi-Provider-Problem — 37% der Unternehmen nutzen laut Kong Enterprise AI Survey fünf oder mehr Modelle parallel. Zweitens das Cost-Problem — semantisches Caching senkt LLM-Kosten regelmäßig um 60-75%, in einem dokumentierten VentureBeat-Case von 47.000 auf 12.700 USD im Monat. Drittens das Compliance-Problem — DORA und BaFin verlangen Audit-Trails für ICT-Workforce-Tools, und das ist ohne zentralen Proxy nicht sauber umsetzbar.
LiteLLM: Der Standardfall für DACH-Enterprise
LiteLLM ist mit rund 40.000 GitHub-Stars und 1.300+ Contributors das mit Abstand reifste Open-Source-Gateway. Architektonisch ist es ein Python-Proxy, der OpenAI-API kompatibel spricht und Requests an 100-140 verschiedene Provider weiterleitet — OpenAI, Anthropic, Azure OpenAI, Bedrock, Vertex/Gemini, Cohere, lokale Modelle via Ollama oder vLLM. Im Hintergrund laufen Postgres für State und optional Redis für Caching.
Wir empfehlen LiteLLM als Standardlösung, wenn die Anforderung lautet: BaFin/KRITIS-konform, Azure-OpenAI-Tenant vorhanden, 2-50 produktive Apps, klassischer Spend-Split nach Team und Projekt. Das passt auf 80% der Mittelstand- und Konzernkunden, die wir betreuen. Die Latency-Kosten von 20-80ms p50 sind verschmerzbar, die Kontrolle über die Infrastruktur ist vollständig.
# litellm config.yaml — Multi-Region Azure mit Fallback auf Anthropic
model_list:
- model_name: gpt-4o
litellm_params:
model: azure/gpt-4o-deployment
api_base: https://pexon-eu.openai.azure.com/
api_key: os.environ/AZURE_API_KEY
- model_name: gpt-4o
litellm_params:
model: azure/gpt-4o-deployment
api_base: https://pexon-sweden.openai.azure.com/
api_key: os.environ/AZURE_SWEDEN_KEY
- model_name: claude-sonnet
litellm_params:
model: anthropic/claude-sonnet-4-5
litellm_settings:
cache: true
cache_params:
type: redis
host: redis.pexon.local
success_callback: ["langfuse", "prometheus"]
router_settings:
routing_strategy: usage-based-routing-v2
fallbacks:
- {gpt-4o: ["claude-sonnet"]}Eine ehrliche Warnung: LiteLLM v1.82.7 und v1.82.8 auf PyPI enthielten im März 2026 einen malicious .pth-File mit Credential-Harvester und K8s-Lateral-Movement-Toolkit. Pinned Versions in der Lockfile, SHA-256-Hash-Check in der CI und kein blindes Update auf „latest“ — das ist keine Paranoia, das ist gelebte Supply-Chain-Hygiene. Wir haben den Vorfall bei mehreren Kunden gesehen und seitdem für jeden LLM-Gateway-Stack die Hash-Pinning-Pipeline zur Pflicht gemacht.
Portkey: Wenn Guardrails und Hybrid-Deployment zählen
Portkey kommt aus dem Y-Combinator-Ökosystem und positioniert sich anders: Managed-First, mit optionalem Hybrid-Deployment, bei dem die Data-Plane on-premise läuft und die Control-Plane in der Portkey-Cloud bleibt. Die Provider-Abdeckung ist die breiteste aller drei Tools — 1.600+ Modelle inklusive obskurer Open-Source-Varianten.
Der wirkliche Unterschied liegt in den Guardrails. Portkey bringt PII-Redaction, Jailbreak-Detection, Toxicity-Scoring und Schema-Validation als managed Layer mit, statt sie separat aufbauen zu lassen. Für Unternehmen, die nicht das Engineering-Personal für diese Module haben, ist das ein klarer Kaufgrund.
Wir setzen Portkey ein, wenn drei Bedingungen zusammenkommen: Erstens muss Hybrid-Deployment möglich sein (Data-Plane on-prem, Control-Plane SaaS). Zweitens müssen managed Guardrails Teil der Anforderung sein, weil sonst der Kostenvorteil von OSS dahin ist. Drittens darf das Pricing-Modell zur Roadmap passen — die Sprünge zwischen Free, 49-USD-Production-Tier und Enterprise (2.000-10.000+ USD/Monat) sind hart.
Portkey ist SOC2-, ISO-27001-, GDPR- und HIPAA-zertifiziert mit BAAs. Das ist mehr als LiteLLM von Haus aus liefert, und für regulierte Branchen ein echter Hebel — vorausgesetzt, die Hybrid-Architektur stimmt zur eigenen Compliance-Vorgabe.
Helicone: Observability First, alles andere zweitrangig
Helicone ist die kleinste der drei Optionen, mit rund 600 Stars im Haupt-Repo und einem separaten AI-Gateway-Projekt. Die Stärke ist nicht Provider-Breite oder Routing-Tiefe, sondern Observability: Sessions, Traces, Playground, Prompt-Versionierung, Cost-/Latency-/Quality-Analytics.
Wenn die primäre Frage Ihres Teams lautet „Wir haben 200 produktive LLM-Workflows — welcher kostet wie viel, welcher ist wie schnell, welcher halluziniert wo?“, dann ist Helicone die direkte Antwort. Self-host läuft mit einem Docker-Compose-Befehl, der Cloud-Tier startet bei 0 USD bis 10.000 Requests/Monat.
Was Helicone nicht ist: ein vollwertiges Routing-Gateway. Fallback-Ketten, Multi-Region-Balancing, ausgefeilte Rate-Limits — dafür wurde es nicht primär gebaut. In Setups, wo Observability Top-Priorität und Routing nachrangig ist, passt es. In typischen Banking-Setups, wo Audit-Trail und Provider-Failover gleichberechtigt gefragt sind, kombinieren wir es nicht ungern mit LiteLLM (LiteLLM macht Routing, Helicone die Tiefe der Traces).
Selbst bauen oder Tool nehmen?
Diese Frage stellt sich in fast jedem Architektur-Workshop. Unsere Antwort ist meistens: Tool nehmen. Selbst bauen lohnt sich genau dann, wenn drei Bedingungen zusammenkommen: Air-Gap-Anforderung ohne Vendor-Dependency, eigenes Token-Billing-Modell, das kein Standard-Tool abbildet, und über 100.000 Requests pro Minute mit Sub-Millisekunden-Latency-Budget. In dem Fall lohnt ein Blick auf Bifrost in Go statt LiteLLM in Python.
Für alle anderen Szenarien — und das sind die meisten — verbrennt Eigenbau Engineering-Kapazität, die für Eval-Pipelines und Use-Case-Roadmap besser eingesetzt ist. Ein LiteLLM-Setup auf AKS mit Postgres, Redis und Langfuse-Tracing dauert bei uns drei bis fünf Tage. Eine eigene Lösung auf vergleichbarem Niveau dauert sechs bis neun Monate und kostet im laufenden Betrieb mehr als die LiteLLM-Enterprise-Lizenz.
Architektur-Skizze: LLM Gateway auf Azure
So sieht ein produktives Setup für ein DACH-Versicherungsunternehmen aus, das wir in Q1 2026 implementiert haben:
[App Pods] → [Azure Front Door] → [AKS: LiteLLM 3 Replicas]
| |
[Postgres FS] [Redis Cache]
|
Azure OpenAI: East-US, West-EU, Sweden
Anthropic via API (Fallback)
Bedrock via STS (regional Fallback)Drei Replicas hinter dem Load-Balancer, Redis-Cluster für Cache und Rate-Limits, Postgres als persistente Audit-Quelle. Die LiteLLM-Pods kennen drei Azure-OpenAI-Deployments in unterschiedlichen Regionen — wenn das Sweden-Deployment Quota-Throttling triggert, wandert der Request automatisch nach East-US. Bei Komplettausfall von Azure OpenAI fängt Anthropic über die direkte API ab.
Das Setup läuft seit Februar produktiv mit 1,2 Millionen Requests pro Tag. Der dokumentierte Cost-Effekt: 41% weniger LLM-Spend gegenüber dem vorherigen direkten Routing, davon 32 Prozentpunkte aus Caching und Cross-Region-Load-Balancing, 9 Prozentpunkte aus dem Wechsel von GPT-4 auf GPT-4o, gesteuert über die Routing-Policy.
Was bei LLM Gateway-Setups regelmäßig schiefgeht
Wir raten ab: Single Replica ohne HA. Ein einzelner Gateway-Pod ohne Load-Balancer ist die garantierte Outage am Sonntagmorgen — und wenn alle Apps darauf zeigen, ist die gesamte LLM-Funktionalität weg. Minimum drei Pods hinter einem Load-Balancer, idealerweise Multi-Region.
Wir raten ab: Semantischer Cache mit Threshold unter 0,92. Ein zu aggressiver Semantic-Cache liefert dem User Antworten auf eine inhaltlich abweichende Frage. Das fällt erst auf, wenn der Compliance-Officer den ersten LLM-Halluzinations-Vorfall aufnimmt. Wir betreiben Semantic-Cache in der Regel mit Threshold 0,95 oder höher — und nur für klar definierte Read-Heavy-Endpoints, nicht für freie Chat-Sessions.
Wir raten ab: Secrets im Config-YAML hardcoded. API-Keys gehören in Azure Key Vault, AWS Secrets Manager oder HashiCorp Vault, niemals ins File-System. LiteLLM unterstützt os.environ/ für direkte Env-Variable-Referenzen und Azure Key Vault Reference im Container — beides ist Pflicht in Production.
Vendor-Lock-in durch Portkey-spezifische Routing-DSL oder LangSmith-Cloud-Dependency ist die dritte Falle. Wer die Gateway-Logik direkt an proprietäre Tools koppelt, zahlt beim späteren Wechsel den vollen Migrationspreis. Unsere Empfehlung: Routing-Konfiguration als YAML außerhalb des Tools versionieren, Observability über OpenTelemetry statt LangSmith, Eval-Pipeline vom Gateway entkoppeln.
Häufig gestellte Fragen
Brauchen wir ein LLM Gateway, wenn wir nur Azure OpenAI nutzen?
Ja, lohnt sich auch dort. Selbst Single-Provider-Setups profitieren vom Load-Balancing über mehrere Azure-OpenAI-Deployments (Region-Quotas variieren), Cost-Attribution pro Team und einheitlichem Audit-Log für BAIT/DORA. Der Setup-Aufwand ist mit LiteLLM überschaubar — 3 bis 5 Engineering-Tage für den ersten produktiven Stand.
Self-hosted oder Managed — was sollen wir nehmen?
DSGVO-, BaFin-, KRITIS-Pflicht oder eigener Azure-Tenant mit Compliance-Auflagen: self-hosted, in der Regel LiteLLM oder Helicone OSS. Prototyp, Non-EU-Setup oder kein eigenes Plattform-Team: Managed-Tier von Portkey oder OpenRouter. Wir migrieren später meistens in Richtung self-hosted, sobald die Workloads regulatorisch eingeordnet sind.
Wie hoch ist der Latency-Overhead eines LLM Gateway in Production?
LiteLLM auf AKS: 20-80ms p50 in einer Region, sauber konfiguriert. Bifrost in Go geht unter 1ms, dafür weniger Provider-Breite. Portkey Managed addiert 50-150ms je nach Region — bei Latenz-kritischen Use-Cases wie Voice oder Realtime ist das oft inakzeptabel, bei klassischen Chat- und RAG-Workloads vernachlässigbar.
Was kostet LiteLLM Enterprise konkret pro Jahr?
Die Lizenz ist nicht öffentlich. Aus Kundenprojekten kennen wir den niedrigen fünfstelligen EUR-Bereich pro Jahr für SSO, RBAC, Audit-Log-Archivierung und Premium-Support. Das wird relevant ab Multi-Team-Setup mit DORA-Anforderung — ohne Audit-Log-Archivierung im SIEM ist DORA-Konformität nicht sauber abbildbar.
Wie verhindere ich, dass das LLM Gateway zum Single Point of Failure wird?
Drei Schichten: Mindestens drei Pod-Replicas hinter einem Load-Balancer, Redis-Cluster mit mehreren Knoten und persistenter Postgres für State. Provider-Fallback-Chain konfigurieren (Azure-Primary → OpenAI direkt → Anthropic). Audit-Log extern persistieren, nicht im selben Cluster — sonst ist bei Compromise alles weg.
Nächster Schritt
Wenn Sie gerade evaluieren, ob ein LLM Gateway in Ihre Architektur passt: Wir analysieren Ihren aktuellen LLM-Spend nach Provider, Team und Use-Case, prüfen die DSGVO-/DORA-Lage und schlagen einen konkreten Stack vor — LiteLLM, Portkey oder Helicone, je nach Constraint. Dauer: eine Woche, danach haben Sie eine belastbare Entscheidungsvorlage.
Verwandte Themen
→Platform Engineering Kultur und Internal Developer Platform
→Kubernetes Beratung für produktive AI-Workloads
→Private KI-Infrastruktur für regulierte Branchen
