MULTI-LLM GATEWAY · SERVICE
Multi-LLM Gateway: Acht Anbieter, ein Eingang, Compliance-Routing
LiteLLM-Gateway mit Auth, Routing nach Kosten/Tempo/Datenschutz, Nutzungs-Dashboard. Modul ab CHF 1000, Projekt mit Observability CHF 4500.
Recherche & Faktencheck: DuneDive LLC · Stand: 2026-05
Was ist ein Multi-LLM Gateway?
Ein Multi-LLM Gateway ist ein zentraler Eingangspunkt für alle KI-Anfragen Ihres Betriebs. Statt acht verschiedene API-Schlüssel über acht verschiedene Anwendungen zu verteilen, gibt es eine Adresse: Ihren Gateway. Anwendungen sprechen mit ihm in einem einheitlichen Protokoll (OpenAI-kompatibel). Der Gateway entscheidet, welches Modell die Anfrage tatsächlich bearbeitet – nach Regeln, die Sie definieren.
Wir bauen das auf LiteLLM, dem etablierten Open-Source-Gateway (mehr als 17000 GitHub-Sterne im Mai 2026, aktive Releases im Wochentakt). LiteLLM unterstützt über 100 LLM-Anbieter und übersetzt deren native APIs in das OpenAI-Format. Sie schreiben Ihre Anwendung gegen ein einziges Protokoll und können Modelle wechseln, ohne Code anzufassen.
In unserem Standard-Build sind acht Provider angebunden: OpenAI (das jeweils aktuelle GPT-Spitzenmodell, GPT-4o), Anthropic (das aktuelle Claude-Spitzenmodell und 3.5), Mistral (Large, Codestral) als EU-gehosteter Anbieter, Cohere (Command R+) ebenfalls EU-tauglich, Google (Gemini 2.5 Pro), Meta-Modelle via Together oder Groq, DeepSeek (V3 und Coder) als Kostenoption, und ein lokales Modell via Ollama (Llama 3.3 70B oder Qwen 2.5) für Daten, die das Haus nicht verlassen dürfen.
Varianten: Modul (CHF 1000) als reiner LiteLLM-Setup mit Authentifizierung und Routing-Regeln. Projekt mit Observability und SSO (CHF 4500) zusätzlich mit Langfuse zur Nachverfolgung jeder Anfrage, SSO-Anbindung an Ihren Identity-Provider, und einem Nutzungs-Dashboard pro Abteilung mit monatlichem Kosten-Report.
Warum es wichtig ist
Drei Probleme löst der Gateway zugleich.
Vendor-Lock-in. Wenn Ihre 30 internen Apps direkt gegen OpenAI sprechen und OpenAI verdoppelt morgen den Preis oder drängt ein neues Tier auf, sind Sie gefangen. Mit Gateway wechseln Sie an einer Stelle die Routing-Regel – das Modell wird zu Mistral oder Claude umgeleitet, die Apps merken nichts.
Compliance-Routing. Das eigentliche Datenschutz-Argument. Sie definieren pro Anwendung oder pro Datenklasse, welche Modelle erlaubt sind. Mandantendaten gehen nur an „EU-only" (Mistral, Cohere, Ollama-lokal). Allgemeine Code-Vorschläge dürfen zum günstigsten Anbieter. Marketing-Texte können zum stärksten gehen. Eine zentrale Regel, statt acht App-Konfigurationen.
Kostenkontrolle. Der Gateway misst jede Anfrage: welche Abteilung, welches Modell, wie viele Token, welche Latenz. Das verhindert das klassische KMU-Phänomen, in dem ein Praktikant in der Marketing-Abteilung eine Schleife in GPT-4 baut und am Monatsende 8000 CHF Rechnung steht. Mit Limits pro Schlüssel und Team – ein Standard-Feature von LiteLLM – können Sie pro Abteilung Budget setzen und im Voraus blocken.
LiteLLM ist seit 2023 produktiv im Einsatz bei Unternehmen wie Netflix, Spotify und vielen anderen – die Software ist stabil, das Pattern erprobt.
Wie es funktioniert
Architektonisch ist der Gateway ein einzelner Container, der vor Ihren Anwendungen steht.
Eingang. Anwendungen sprechen über HTTPS mit dem Gateway, über das OpenAI-Format (POST /v1/chat/completions, /v1/embeddings, /v1/audio/speech). Jede Anwendung bekommt einen virtuellen API-Schlüssel (sk-...), gebunden an ein Team oder eine Person mit Budget-Limit.
Authentifizierung. Der Gateway prüft den Schlüssel gegen seine interne Postgres-DB. Bei der Projekt-Variante kommt SSO dazu: Anwendungen authentifizieren über Ihren Identity-Provider (Azure AD, Google Workspace, Authentik), und der Gateway erkennt Person und Abteilung am OIDC-Token.
Routing. Jetzt entscheidet der Router. Er kennt für jedes „Modell-Label" (z.B. `gpt-4`, `claude`, `cheap`, `eu-only`) eine Liste von hinterlegten Backend-Deployments. Standard-Strategie ist simple-shuffle mit Gewichten – bei Ausfall fällt er auf das nächste Deployment zurück. Sie können tag-basiert routen („`tag=client-data`" zwingt das Request zu `eu-only`), gewichtet (70 Prozent zum günstigeren Modell), oder mit Fallback-Ketten (zuerst Mistral Large, bei Rate-Limit das aktuelle Claude-Spitzenmodell).
Beobachtung. Mit Langfuse oder dem eingebauten OpenTelemetry-Export wird jede Anfrage protokolliert: Prompt-Hash, gewähltes Modell, Token-Counts, Kosten, Latenz, Fehler. Das geht in Ihre Postgres-DB plus Grafana-Dashboard. Bei sensiblen Daten kann das Logging redacted werden – Prompts werden gehashed, nicht im Klartext gespeichert.
Provider-Aufruf. Der Gateway übersetzt den OpenAI-Request in den jeweiligen Provider-Dialekt (Anthropic-Messages-API, Google Vertex, Cohere v2, etc.), holt die Antwort, normalisiert wieder ins OpenAI-Format. Die Anwendung sieht denselben Response, egal welches Modell tatsächlich antwortet.
Gateway-Setup in 6 Schritten
- 01Provider-Liste festlegen: welche 4 bis 8 Modelle decken Ihre Use-Cases ab?
- 02Datenklassen definieren: öffentlich / intern / vertraulich / Berufsgeheimnis – und welches Modell darf welche Klasse sehen?
- 03LiteLLM-Container deployen, Postgres-DB anbinden, virtuelle Schlüssel pro Team erzeugen.
- 04Routing-Regeln schreiben: Tag-basiert, Fallback-Ketten, Lastverteilung mit Gewichten.
- 05Observability anbinden: Langfuse für Request-Trace oder OpenTelemetry-Export zu Grafana.
- 06Budget-Limits pro Schlüssel setzen, Alert bei 80 Prozent Verbrauch – und an Anwendungen ausrollen.
Wann ein Gateway lohnt
Ein Gateway lohnt sich, wenn (a) Sie mehr als ein KI-Modell einsetzen oder einsetzen wollen, (b) Sie verschiedene Datenklassen verarbeiten (öffentlich, intern, vertraulich, Berufsgeheimnis), (c) mehrere Abteilungen oder Teams KI nutzen und Sie pro Bereich Budgets brauchen, oder (d) Sie eine nachvollziehbare Vendor-Strategie brauchen, weil Compliance oder Audit es verlangen.
Konkrete Auslöser, die wir gesehen haben: Eine Anwaltskanzlei nutzt Claude für Mandanten-Korrespondenz (EU-tauglich via Anthropic Bedrock in Frankfurt) und DeepSeek für allgemeine Recherche-Aufgaben – bei einem Schlüssel pro Anwalt mit Monatsbudget. Eine Treuhand mixt Mistral Large für Texte und Ollama-lokal für Mandantendaten, die das Haus nicht verlassen. Ein KMU mit drei Standorten leitet je nach IP-Range an unterschiedliche Provider – Marketing-Standort darf alles, Buchhaltung nur EU-Modelle.
Der Break-even ist bei rund 200 CHF Modell-Ausgaben pro Monat erreicht. Darunter lohnt sich die Setup-Komplexität meist nicht – eine direkte Provider-Anbindung mit einem einzigen Schlüssel ist einfacher.
Wann NICHT
Ein Gateway ist die falsche Wahl, wenn (a) Sie nur ein einziges Modell nutzen und nie wechseln wollen, (b) Ihre Anwendung nur über einen einzelnen, gut beobachtbaren Dienst spricht (z.B. nur ChatGPT Team), oder (c) Sie heute weniger als 50 KI-Anfragen pro Tag haben.
Gleichzeitig: Wenn Sie kein eigenes Hosting wollen und nur eine kuratierte Cloud-Lösung suchen, gibt es Managed-Gateway-Anbieter (z.B. OpenRouter, Portkey, Helicone). Das geht – aber Sie geben den zentralen Kontroll-Vorteil teilweise wieder ab, weil alle Anfragen über einen US-Cloud-Dienst gehen. Für den Schweizer Markt mit Berufsgeheimnis-Daten ist self-hosted-LiteLLM das aufrichtigere Modell.
Und: Ein Gateway löst nicht das Halluzinations-Problem. Er routet, misst, kontrolliert – er macht das Modell aber nicht klueger. Wer korrekte Antworten aus eigenem Wissen braucht, braucht zusätzlich RAG (siehe „RAG mit eigenem Wissen").
Vor- und Nachteile
STÄRKEN
- Vendor-Wechsel an einer Stelle, ohne Code-Anpassung in den Anwendungen
- Compliance-Routing nach Datenklasse – sensible Daten nur an EU-Modelle
- Kostenkontrolle pro Schlüssel und Team mit Hard-Budgets
- Vollständige Observability: jede Anfrage geloggt, Token-Counts, Latenz, Fehler
- OpenAI-kompatibel – keine App muss ihren Code ändern
SCHWÄCHEN
- Eine zusätzliche Komponente, die mit gewartet werden muss
- Single-Point-of-Failure bei Single-Instance-Setup – Failover nötig für hohe Verfügbarkeit
- Setup-Aufwand lohnt sich unter ca. CHF 200/Monat Modell-Ausgaben meist nicht
- Löst nicht Halluzination – dafür braucht es RAG zusätzlich
Häufige Fragen
Was passiert, wenn LiteLLM selbst ausfällt?
Der Gateway läuft in der Standard-Konfiguration als systemd-Service mit Auto-Restart und Health-Check. Bei Bedarf können wir zwei Instanzen hinter nginx mit Failover betreiben – für 99.95 Prozent Verfügbarkeit. Bei einzelner Instanz und Maschinen-Ausfall ist die Wiederherstellung in Minuten, sofern die DB-Replik vorhanden ist.
Funktioniert das mit Streaming?
Ja. LiteLLM leitet Server-Sent-Events transparent durch – Anwendungen, die Token-für-Token-Streaming brauchen (Chat-UIs, Code-Assistenten), arbeiten ohne Änderung. Latenz-Overhead durch den Gateway: wenige Millisekunden.
Wie integriert sich das mit OpenAI SDK oder LangChain?
Direkt. Beide Bibliotheken brauchen nur einen `base_url`-Parameter – Sie zeigen ihn auf Ihren Gateway statt auf api.openai.com. Der Code bleibt identisch. Embedding-Bibliotheken (LlamaIndex, Haystack, LangChain) funktionieren ebenfalls über den Embedding-Endpoint.
Was kostet der Gateway-Betrieb selbst?
Der Container braucht 256 MB RAM und vernachlässigbare CPU. Auf einem bestehenden Server fällt das nicht ins Gewicht – Sie zahlen die Modell-Kosten der jeweiligen Provider, plus eine kleine Postgres-DB. LiteLLM selbst ist Open-Source und kostenfrei.
Verwandte Themen
Quellen
PASSEND ZU IHREM STACK?