LiteLLM Enterprise: Multi-Provider-LLM-Gateway mit Cost-Routing, Governance und DSGVO-Compliance

Wie ein Open-Source-LLM-Gateway den Multi-Cloud-Wildwuchs domestiziert — und welche Architektur-Entscheidungen die Enterprise-Tauglichkeit ausmachen. Ein Praxisbeitrag von Pexon Consulting aus produktiven DACH-Setups.

Mit jedem neuen LLM-Anbieter wächst der Wildwuchs in Unternehmen. Entwickler nutzen Claude für Code, Marketing greift zu GPT-4o für Texte, Engineering setzt Gemini für Long-Context ein — und die IT verliert den Überblick über Kosten, Compliance und Datenflüsse. LiteLLM, ein Open-Source-Gateway aus dem BerriAI-Projekt, hat sich 2025 und 2026 zum De-facto-Standard für genau dieses Problem entwickelt. Dieser Beitrag zeigt, wie Pexon Consulting ein produktives LiteLLM-Enterprise-Setup aufbaut: mit Cost-Routing, Audit-Logging, DSGVO-konformer Sub-Processor-Kette und Integration lokal gehosteter Modelle.

Was ist LiteLLM? Kurzdefinition

LiteLLM ist ein Open-Source-LLM-Gateway (Proxy), das über 100 LLM-Provider hinter einem einheitlichen OpenAI-API-Format bündelt. Es sitzt zwischen Anwendung und Provider, führt Routing-Logik ein, schreibt Audit-Logs und ermöglicht Cost-Tracking pro User, Team und Projekt. Damit wird LiteLLM zur zentralen Kontroll- und Compliance-Schicht für die KI-Nutzung im Unternehmen bzw. in der Existenzgründung — vergleichbar mit einem API-Gateway in der Microservice-Welt. Genau als solche architektonische Schicht setzt Pexon Consulting LiteLLM in regulierten Branchen ein.

1. Das Problem: LLM-Wildwuchs in der Enterprise-IT

In den meisten mittelständischen IT-Abteilungen sind 2026 mindestens drei LLM-Anbieter parallel im Einsatz. Die Folgen sind bekannt:

• Kosten: Jede Abteilung kauft separat. Volumen-Rabatte werden nicht gehoben, Token-Spend wächst unkontrolliert.
• Compliance: Nicht jeder API-Endpunkt erfüllt DSGVO Art. 28. Die OpenAI-Direct-API über die USA ist für personenbezogene Daten nicht freigegeben — Azure OpenAI Frankfurt und AWS Bedrock Frankfurt schon.
• Audit: Wer hat wann welchen Prompt gesendet? In den meisten Setups nicht nachvollziehbar.
• Verfügbarkeit: Fällt ein Provider aus, fällt eine ganze Service-Schicht aus, weil kein Fallback definiert ist.

Genau diese vier Probleme adressiert ein LLM-Gateway wie LiteLLM.

2. Architektur-Übersicht

Ein produktives LiteLLM-Setup besteht aus vier Schichten:

┌─────────────────────────────────────────────────────┐

│  Anwendungen: Claude Code, Open WebUI, n8n,         │

│              eigene Python-Services, RAG-Pipelines  │

└─────────────────────┬───────────────────────────────┘

                      │ OpenAI-API-Format

                      ▼

┌─────────────────────────────────────────────────────┐

│  LiteLLM-Gateway (FastAPI auf Kubernetes)           │

│  – Routing-Rules (Modell × Kosten × Tags)           │

│  – Auth + RBAC (Virtual Keys / Teams)               │

│  – Rate Limits + Budget-Quoten (Redis)              │

│  – Audit-Logging (Postgres + Langfuse + S3)         │

└──┬──────────┬──────────┬──────────┬─────────────────┘

   │          │          │          │

   ▼          ▼          ▼          ▼

┌─────┐  ┌─────────┐  ┌──────┐  ┌────────────────────┐

│Azure│  │Bedrock  │  │Vertex│  │Self-Hosted vLLM/   │

│OpenAI│ │ EU      │  │ AI EU│  │Ollama (on-prem)    │

│Frankf│ │(Claude) │  │      │  │                    │

└─────┘  └─────────┘  └──────┘  └────────────────────┘

LiteLLM läuft als FastAPI-Service in einem Kubernetes-Cluster. Postgres dient als persistente Schicht für Konfiguration und Audit-Logs, Redis cached Rate-Limit-Counter, Cost-Routing-State und Token-Usage. Für die Produktion empfiehlt sich mindestens ein Replica-Pair hinter einem Load-Balancer.

Fakten-Hinweis zu Claude in der EU: Anthropic Claude steht 2026 nicht über eine eigene EU-Region der Anthropic-API zur Verfügung — die First-Party-Claude-API hat nur US-Workspaces. EU-Datenresidenz erreicht man ausschließlich über AWS Bedrock EU (Frankfurt, Dublin, Paris) oder Google Vertex AI EU. LiteLLM kapselt beide Wege transparent.

3. Cost-Routing in der Praxis

Das Kern-Feature für die IT-Budgetkontrolle ist das Model-Routing:

# litellm_config.yaml

model_list:

  – model_name: smart-routing-default

    litellm_params:

      model: azure/gpt-4o

      api_base: https://example-azure-eu.openai.azure.com

      api_key: os.environ/AZURE_API_KEY

      timeout: 30

    model_info:

      input_cost_per_token: 0.0000025   # GPT-4o legacy-tier 06/2026

      output_cost_per_token: 0.00001

  – model_name: smart-routing-default

    litellm_params:

      model: bedrock/anthropic.claude-sonnet-4-6

      aws_region_name: eu-central-1

      timeout: 30

    model_info:

      input_cost_per_token: 0.000003

      output_cost_per_token: 0.000015

  – model_name: cheap-classification

    litellm_params:

      model: openai/llama-3.3-70b-instruct

      api_base: http://vllm-internal.svc.cluster.local:8000/v1

      api_key: os.environ/VLLM_INTERNAL_KEY

    model_info:

      input_cost_per_token: 0

      output_cost_per_token: 0

router_settings:

  routing_strategy: cost-based-routing

  fallbacks:

    – {„smart-routing-default“: [„cheap-classification“]}

  num_retries: 2

  redis_host: os.environ/REDIS_HOST          # Pflicht für cost-based-routing

  redis_password: os.environ/REDIS_PASSWORD

litellm_settings:

  drop_params: true

  set_verbose: false

  success_callback: [„langfuse“]

  failure_callback: [„langfuse“, „slack“]

  s3_callback_params:

    s3_bucket_name: „litellm-audit-logs“

    s3_region_name: „eu-central-1“

Der Router verteilt Anfragen für smart-routing-default zwischen Azure OpenAI Frankfurt und Bedrock-Claude-EU nach Latenz und Kosten; cheap-classification-Anfragen (Tagging, Spam-Filter, Routing-Entscheidungen) gehen an das self-hosted Modell. Wer 60 bis 75 Prozent der Anfragen auf das günstige Modell umlenkt, drückt die Total-Cost-of-Inference deutlich — die konkrete Senkung sollte in einer Pilot-Phase über zwei bis vier Wochen gemessen werden.

4. Governance, RBAC und Virtual Keys

Direkt-API-Keys an Entwickler herauszugeben, ist Compliance-Suizid. LiteLLM löst das über Virtual Keys — pro Team ein Sub-Key mit eigenem Budget, eigenen Modell-Berechtigungen und eigenem Audit-Log:

curl -X POST ‚https://litellm.example.com/key/generate‘ \

  -H ‚Authorization: Bearer sk-master-key‘ \

  -d ‚{

    „models“: [„smart-routing-default“],

    „max_budget“: 500.00,

    „budget_duration“: „30d“,

    „metadata“: {„team“: „marketing“, „cost_center“: „MKT-2026“},

    „team_id“: „marketing-de“

  }‘

Welche Modelle ein Team aufrufen darf, wird über die Allowlist im /team/new-Endpoint definiert (LiteLLM nutzt Allowlist-Only, kein blocked_models-Feld):

curl -X POST ‚https://litellm.example.com/team/new‘ \

  -H ‚Authorization: Bearer sk-master-key‘ \

  -d ‚{

    „team_alias“: „marketing-de“,

    „models“: [„smart-routing-default“, „cheap-classification“],

    „metadata“: {„dsgvo_class“: „personenbezogen-erlaubt“}

  }‘

5. LiteLLM und DSGVO: die drei Compliance-Hebel

Die DSGVO-Tauglichkeit von LiteLLM hängt an drei Punkten — genau hier setzt Pexon Consulting bei der DSGVO-konformen LiteLLM-Implementierung an:

Provider-Auswahl. Nur Provider mit EU-Region und AVV sind erlaubt. Azure OpenAI (Frankfurt, Schweden), AWS Bedrock (Frankfurt, Dublin, Paris — auch für Anthropic Claude). Bei jeder Provider-Aufnahme prüft die IT Sub-Processor-Liste, Schrems-II-Risiko und SCC-Paket.

Audit-Logging. Jede Anfrage wird gespeichert — pro User, Prompt-Hash, Modell und Region. Damit ist die Nachvollziehbarkeit für die DSGVO-Auskunftspflicht nach Art. 15 erfüllt.

Daten-Minimierung. Eine vorgeschaltete Redaction-Schicht entfernt personenbezogene Daten aus Prompts, bevor sie an einen externen Provider gehen — über die Presidio-Guardrail-Integration im aktuellen v2-Format:

guardrails:

  – guardrail_name: „presidio-mask-eu“

    litellm_params:

      guardrail: presidio

      mode: pre_call

      presidio_language: de

      pii_entities_config:

        PERSON: „MASK“

        EMAIL_ADDRESS: „MASK“

        IBAN_CODE: „MASK“

        DE_DRIVER_LICENSE: „MASK“

      output_parse_pii: true

Für den EU AI Act (Stichtag derzeit August 2026, Verschiebung im Trilog verhandelt) kann LiteLLM pro Aufruf Provider und Risiko-Klasse in den Audit-Log schreiben — der Nachweis-Pfad fürs Conformity-Assessment.

6. Monitoring und Cost-Tracking

LiteLLM exportiert Prometheus-Metriken nativ:

sum by (team) (litellm_total_tokens_metric)

sum by (model) (rate(litellm_spend_metric[1h]))

rate(litellm_deployment_successful_fallbacks[5m])

histogram_quantile(0.95, rate(litellm_llm_api_latency_metric_bucket[5m]))

Für die Finanzabteilung empfiehlt sich ein wöchentlicher Slack-Hook mit den fünf größten Spendern. Die Langfuse-Integration liefert Prompt-Level-Tracing auf User-Ebene.

7. Lokale und Private-AI-Integration

Die strategische Stärke von LiteLLM liegt darin, parallel zu Cloud-Providern lokale Modelle einzubinden: vLLM für On-Premise-Inferenz (H100, L40s), Ollama für Entwickler-Workstations und Edge, Triton für Custom-Modelle. Compliance-kritische Anfragen lassen sich über Tag-Based Routing zwingend auf das On-Prem-Modell umleiten:

router_settings:

  enable_tag_filtering: true

model_list:

  – model_name: mixtral-onprem

    litellm_params:

      model: openai/mixtral

      api_base: http://vllm-internal.svc.cluster.local:8000/v1

      tags: [„compliance_strict“, „pii_present“, „eu-only“]

Die Anwendung setzt „tags“: [„compliance_strict“], und LiteLLM routet ausschließlich auf tag-matched Deployments — ohne Cloud-Fallback.

8. LLM-Gateways im Vergleich: LiteLLM vs OpenRouter vs Helicone vs Portkey

Kriterium	LiteLLM	OpenRouter	Helicone	Portkey
Open-Source-Kern	Ja, MIT (Enterprise-Add-On proprietär)	Nein, hosted-only	Teilweise	Teilweise
Self-Hosted in EU	Ja, K8s-Helm + Docker-Compose	Nein	Ja, K8s	Ja, K8s
Cost-Routing über Self-Hosted-Modelle	Ja, nativ	Nein	Eingeschränkt	Ja
RBAC + Virtual Keys	Ja	Eingeschränkt	Ja	Ja
PII-Guardrails nativ	Ja, Presidio v2	Nein	Teilweise	Ja
DSGVO-Tauglichkeit	Hoch (Self-Hosted)	Niedrig (US-Routing)	Mittel	Mittel

LiteLLM vs OpenRouter kurz: Wer Compliance-Sicherheit und On-Prem-Modell-Routing braucht, kommt im DACH-Markt um LiteLLM kaum herum — ein ausführlicher LiteLLM-vs-OpenRouter-Vergleich zeigt die Details. Wer reine Cloud-LLM-Konsolidierung ohne Self-Hosting will, ist mit OpenRouter schneller produktiv — handelt aber Datenresidenz gegen Convenience (Stichwort „openrouter dsgvo“: US-Routing ist für personenbezogene Daten problematisch).

9. Wann LiteLLM NICHT die richtige Wahl ist

• Ultra-low-Latency (< 50 ms TTFT): Der LiteLLM-Hop addiert 5 bis 20 ms — Direct-Provider-Pfad bevorzugen.
• Single-Provider-Stacks mit hohem Vendor-Commit: Wer nur Azure OpenAI fährt, baut mit LiteLLM Komplexität ohne Hebel.
• Bursty Batch-Workloads über 100.000 Token/Anfrage: Dedizierte Batch-API-Pipelines sind günstiger.

10. Production-Deployment mit Helm

# values.yaml

replicaCount: 2

image:

  repository: ghcr.io/berriai/litellm

  tag: main-stable

postgresql:

  enabled: true

  primary:

    persistence:

      size: 50Gi

      storageClass: gp3-eu-central-1

redis:

  enabled: true

  auth:

    enabled: true

ingress:

  enabled: true

  className: nginx

  hosts:

    – host: litellm.example.com

config:

  environment_variables:

    LITELLM_MODE: PRODUCTION

    STORE_MODEL_IN_DB: „True“

    LITELLM_MASTER_KEY: <<from-secret>>

    AZURE_API_KEY: <<from-secret>>

    AWS_REGION_NAME: eu-central-1

serviceMonitor:

  enabled: true

11. Output-Caching als Cost-Hebel #2

litellm_settings:

  cache: true

  cache_params:

    type: redis

    host: os.environ/REDIS_HOST

    port: 6379

    ttl: 1800

    similarity_threshold: 0.95

    supported_call_types: [„completion“, „acompletion“, „embedding“]

Bei semantischem Caching mit Schwellwert 0,95 trifft der Cache typischerweise 15 bis 30 Prozent der Anfragen. Wichtig: PII-maskierte Prompts nur in verschlüsselten Cache (Redis mit TLS + rotierende Keys).

12. Threat-Model: Was LiteLLM nicht löst

• Prompt-Injection: LiteLLM prüft Inputs nicht inhaltlich — vorgeschaltete Sanitizer wie Llama Guard 3 nötig.
• Tenant-Isolation: Virtual Keys regeln Zugriff, nicht Datentrennung — Tenant-ID an die Embedding-Suche durchreichen.
• Provider-Side-Channels: Metadaten (Token-Counts, Latenz-Pattern) verlassen den Tenant — nur On-Prem löst das.

13. Migration von OpenAI-direct zu LiteLLM

1. LiteLLM-Proxy parallel betreiben — Anwendungen ändern nur die Base-URL und erhalten einen Virtual Key.
2. Audit-Phase über zwei bis vier Wochen — Token, Latenz, Fehler vergleichen.
3. Routing schrittweise einführen — erst Tag-Routing für PII, dann Cost-Routing, dann Caching.
4. Direct-API-Pfad abklemmen + Master-Key-Rotation.

Der Wechsel ist niedrigschwellig, weil das OpenAI-API-Format bleibt — LangChain, LlamaIndex, n8n und MCP-Server-Setups sprechen LiteLLM ohne Code-Änderung.

14. Fünf Fallstricke aus der Praxis

Aus produktiven LiteLLM-Implementierungen von Pexon Consulting wiederholen sich fünf Fehler: Single-Replica (mind. zwei hinter Load-Balancer), Audit-Logs im Config-Postgres (nach S3/Loki auslagern), Virtual Keys ohne Budget-Limit (max_budget ist Pflicht), PII-Masking erst im Provider (muss vor dem Outbound-Call laufen), keine Routing-Tests (Modell-Outage-Szenarien simulieren).

15. Fazit

LiteLLM ist 2026 die De-facto-Antwort auf den LLM-Wildwuchs. Der MIT-lizenzierte Kern deckt RBAC, Audit-Logs und Cost-Tracking ab; das enterprise/-Verzeichnis ist eine proprietäre Erweiterung. Vier Messgrößen zeigen nach 90 Tagen, ob die Architektur trägt: Cost-per-Mio-Token im Mix (−30 bis 50 %), Provider-Outage-Resilienz, DSGVO-Audit-Bearbeitungszeit (von Tagen auf Minuten) und Time-to-Production neuer Use-Cases (auf Stunden). Wer diese etabliert, hat aus LiteLLM keine taktische Cost-Optimierung gemacht, sondern eine strategische Plattform-Entscheidung.

Häufige Fragen (FAQ)

Was ist LiteLLM? LiteLLM ist ein Open-Source-LLM-Gateway, das über 100 Provider hinter einem einheitlichen OpenAI-API-Format bündelt und zentrales Routing, Audit-Logging und Cost-Tracking ermöglicht.

Ist LiteLLM DSGVO-konform? Ja — self-hosted in einer EU-Region, mit ausschließlich AVV-gedeckten EU-Providern (Azure Frankfurt, AWS Bedrock EU), Audit-Logging und vorgeschalteter PII-Redaction (Presidio). Die DSGVO-Konformität ist eine Frage der Architektur, nicht des Tools allein.

LiteLLM vs OpenRouter — was ist der Unterschied? LiteLLM ist self-hostbar mit On-Prem-Modell-Routing und hoher DSGVO-Tauglichkeit; OpenRouter ist hosted-only mit US-Routing und damit für personenbezogene Daten kritisch.

Was kostet LiteLLM Enterprise? Der Open-Source-Kern (MIT) ist kostenlos und deckt die meisten Mittelstands-Setups ab. Das Enterprise-Tier (proprietäres enterprise/-Verzeichnis) wird nutzungs- bzw. lizenzbasiert abgerechnet.

Über den Autor: Phillip Pham ist Gründer und CEO der Pexon Consulting GmbH, einem deutschen Cloud- und KI-Dienstleister mit Sitz in München. Pexon begleitet Unternehmen beim Aufbau DSGVO-konformer KI-Architekturen auf Azure, Kubernetes und Open-Source-Stacks wie LiteLLM. Mehr über Pexon Consulting.