LLM-Gateways im Vergleich: 10 Optionen für Routing, Audit und Kosten

Was ein LLM-Gateway ist

Ein LLM-Gateway ist eine Proxy-Schicht vor mehreren LLM-Anbietern. Statt dass jede Anwendung direkt mit OpenAI, Anthropic, Mistral oder einem lokalen Ollama spricht, geht der gesamte Traffic über das Gateway. Das Gateway übernimmt vier Aufgaben: Routing (welche Anfrage geht zu welchem Modell), Authentifizierung (virtuelle Keys pro Team oder Mandant), Observability (Audit-Log, Kosten-Tracking, Tracing) und Resilienz (Fallback-Ketten, Retry, Rate-Limit).

Die Architektur ist nicht neu – API-Gateways gibt es seit über einem Jahrzehnt. Was an LLM-Gateways anders ist: sie verstehen das OpenAI-Chat-Completions-Schema, können Token-Zahlen zählen, Kosten pro Modell berechnen und Streaming-Antworten korrekt durchreichen. Wer ein klassisches API-Gateway wie Kong oder NGINX vor LLMs setzt, bekommt diese Fähigkeiten nicht ohne Zusatz-Plugin.

Stand Mai 2026 stehen rund zwei Dutzend Gateways zur Verfügung – von klein und open-source (LiteLLM, Bifrost) bis enterprise-managed (Portkey, TrueFoundry). Diese Seite vergleicht die zehn Optionen, die in KMU- und Treuhand-Kontexten am häufigsten in der Auswahl landen: LiteLLM, OpenRouter, Portkey, Kong AI Gateway, Cloudflare AI Gateway, Helicone, TrueFoundry, Martian, Bifrost und Apache APISIX mit AI-Plugin.

Warum ein Gateway sinnvoll ist

Wer LLM-Anwendungen direkt gegen Provider-SDKs schreibt, baut sich technische Schulden ein. Drei Probleme treten in jedem grösseren Setup auf und ein Gateway löst sie an einer Stelle.

Erstens Lock-in. OpenAI, Anthropic und Mistral haben unterschiedliche SDKs, unterschiedliche Token-Limits, unterschiedliche Fehler-Codes. Eine Code-Basis, die drei Anbieter direkt anspricht, hat drei Fehlerquellen statt einer. Wenn ein Provider teurer wird oder ausfällt, ist der Wechsel ein Refactor, kein Konfigurations-Eintrag. Mit einem Gateway ist der Provider eine Konfigurations-Zeile – Anwendungs-Code bleibt unverändert.

Zweitens Datenschutz-Routing. Eine CH-Treuhand darf Mandanten-PII nicht an US-Provider senden, kann aber anonymisierte Recherche-Anfragen problemlos an GPT-4o stellen. Ohne Gateway liegt diese Regel im Code verstreut; mit Gateway steht sie zentral. Modell-Namen wie mistral-eu-secure, claude-haiku-eu oder local-llama markieren die Stufe, der Proxy entscheidet das Routing automatisch.

Drittens Kosten und Audit. Jeder Provider hat eigene Dashboards und eigene Abrechnungs-Frequenzen. Die Gesamtsicht – wer hat wie viel verbraucht, welcher Workflow kostet wie viel – lässt sich ohne Aggregation-Layer nicht erstellen. Ein Gateway schreibt jede Anfrage in Postgres oder ClickHouse mit Modell, Token, Kosten und Latenz; eine Grafana-Dashboard pro Mandant ist dann zwei Stunden Arbeit. Für einen Auditor unter Art. 957a OR ist diese Logik nachvollziehbar.

Die Wahl zwischen den Gateways hängt an drei Achsen: Self-Host-Fähigkeit (Datenschutz), Provider-Anzahl (Flexibilität) und Observability-Tiefe (Compliance). LiteLLM und Bifrost sind voll self-hostbar, OpenRouter ist nur Cloud, Portkey bietet beide Optionen mit unterschiedlichem Funktionsumfang.

Wie sich die zehn Gateways unterscheiden

Die zehn Optionen lassen sich in vier Gruppen sortieren. Erste Gruppe: voll self-hostbar mit OSS-Lizenz – LiteLLM, Bifrost, Apache APISIX mit AI-Plugin. Diese drei laufen vollständig auf eigener Infrastruktur, ohne Drittland-Transfer der Anfrage-Daten. LiteLLM ist die Standard-Wahl: Python-FastAPI, 100+ Provider-Anbindungen, virtuelle Keys mit Budget, PostgreSQL als Audit-Speicher. Bifrost ist in Go, deutlich latenzärmer (1-3 ms Overhead), aber jünger und mit kleinerem Provider-Katalog. APISIX ist die richtige Wahl, wenn bereits ein API-Gateway-Setup existiert und LLM nur eine Erweiterung ist.

Zweite Gruppe: Cloud-only oder primär Cloud – OpenRouter, Cloudflare AI Gateway, Martian. OpenRouter ist eine Marktplatz-Lösung mit 300+ Modellen, Bezahlung per Credits – sehr schnell zum Testen, aber kein Self-Host und kein EU-Tier. Cloudflare AI Gateway läuft auf Cloudflare Workers Edge, integriert mit Workers AI und Cache; gut für Setups, die bereits in der Cloudflare-Welt leben. Martian ist experimentell: ein Modell-Klassifikator entscheidet automatisch, welches LLM die Anfrage erhält – interessant, aber wenig Kontrolle.

Dritte Gruppe: Enterprise-managed mit Self-Host-Option – Portkey, TrueFoundry, Helicone. Portkey ist die ausgebaute Variante: 1.600+ LLMs, 50+ Guardrails, semantische Caches, Audit-Trails, EU-Hosting. TrueFoundry kommt aus dem ML-Platform-Bereich und passt zu Teams, die schon eine TrueFoundry-Inferenz-Plattform betreiben. Helicone ist primär Observability-fokussiert (Tracing, Cost-Analytics) und hat Gateway-Funktionen zugekauft.

Vierte Gruppe: klassische API-Gateways mit LLM-Erweiterung – Kong AI Gateway. Kong ist seit Jahren ein API-Gateway, das AI-Gateway-Plugin kam 2024. Gut, wenn Kong-Stack vorhanden ist und LLM nur eine Route unter vielen ist.

Alle zehn beherrschen das Kern-Pattern: OpenAI-kompatibles Endpoint, Provider-Mapping per Konfiguration, virtuelle Keys, Cost-Tracking. Die Unterschiede liegen in Observability-Tiefe, Guardrail-Fähigkeit (Inhalts-Filter, PII-Maskierung), Latenz-Overhead und EU-Hosting.

Auswahl in 5 Schritten

1. 01Anzahl Provider und Modelle inventarisieren: ein Provider -> Gateway optional; mehrere -> Gateway lohnt.
2. 02Hosting-Anforderung prüfen: Mandantendaten unter revDSG -> Self-Host (LiteLLM, Bifrost, APISIX); offene Recherche akzeptabel -> Cloud-Optionen.
3. 03Observability-Bedarf klären: nur Cost-Tracking -> Helicone reicht; Audit-Trail unter Art. 957a OR -> LiteLLM/Portkey mit Postgres.
4. 04Latenz-Budget bestimmen: > 50 ms Headroom -> alle Optionen; < 10 ms Overhead -> Bifrost oder direkter Provider-Call.
5. 05Bestehenden Stack einrechnen: Kong/APISIX bereits da -> AI-Plugin nutzen; Cloudflare-Stack -> CF AI Gateway; sonst LiteLLM als Standard.

Wann welches Gateway passt

Wer Self-Hosting unter revDSG braucht und mehr als einen LLM-Provider verbindet, ist mit LiteLLM gut bedient. Docker-Container, eine YAML-Konfiguration mit Modell-Mapping, PostgreSQL für Audit. Die meisten produktiven Setups in der Schweiz laufen in genau dieser Konstellation.

Wer maximale Provider-Breite zum Testen will, nimmt OpenRouter. 300+ Modelle hinter einer API, Credit-basiertes Pricing, kein Lock-in beim Modell-Wechsel. Sobald produktive Anwendung mit Mandantendaten kommt, wechselt man auf Self-Host.

Wer Enterprise-Compliance mit Guardrails, Audit-Trails und Multi-Region braucht, schaut auf Portkey oder TrueFoundry. Portkey hat die stärkere Observability, TrueFoundry passt besser zu Teams mit eigener ML-Plattform.

Wer ohnehin in Cloudflare lebt (Workers, Pages, R2), nimmt Cloudflare AI Gateway – die Integration ist tief, der Cache niedrig-latent. Wer schon Kong-Setup hat, fügt das AI-Plugin hinzu statt eine zweite Gateway-Schicht zu betreiben.

Für reine Beobachtung – wenn die Anwendungen bereits direkte Provider-Calls machen und nur Tracing dazukommt – ist Helicone die richtige Wahl. Helicone lässt sich als reines Logging-Proxy einsetzen, ohne Modell-Routing zu übernehmen.

Bifrost lohnt für Echtzeit-Workloads, in denen jede Millisekunde zählt – Voice-Bots, Streaming-Chat mit niedriger TTFB. Apache APISIX passt für Plattform-Teams, die schon ein API-Gateway betreiben und LLM nur eine weitere Route ist. Martian bleibt experimentell und passt für Setups, die explizit Modell-Klassifikation pro Anfrage testen wollen.

Wann kein Gateway nötig ist

Bei einer einzelnen, überschaubaren Anwendung mit genau einem Provider und ohne Mandanten-Trennung ist ein Gateway Mehraufwand ohne Mehrwert. Ein Wochenend-Projekt mit der OpenAI-Library braucht keinen Proxy. Auch ein interner Prototyp, der von einem Entwickler betreut wird, gewinnt nichts durch zusätzliche Komponenten.

Ungeeignet sind Gateways in extrem latenz-kritischen Real-Time-Anwendungen, in denen jede Millisekunde zählt. Ein Proxy fügt typisch 10-30 ms hinzu (Bifrost ist mit 1-3 ms die Ausnahme). Bei Voice-Streaming mit TTFB-Budget unter 200 ms können 30 ms relevant sein – dort lohnt die direkte Provider-Anbindung mit handgeschriebenem Fallback.

Für Anwendungen, die ausschliesslich in Azure-OpenAI-Service oder AWS-Bedrock leben, sind diese Plattformen selbst bereits ein Gateway: Content-Filter, Guardrails, Audit-Log und Multi-Region sind eingebaut. Eine zusätzliche Proxy-Schicht ist redundant – ausser man will später auch andere Provider anbinden.

Ungeeignet auch dort, wo das Team kein Container-Wissen hat und kein Budget für einen managed Service vorgesehen ist. Ein Gateway ohne Monitoring, ohne Updates und ohne Backup ist eine Single-Point-of-Failure-Komponente, die im Worst Case alle LLM-Anfragen blockiert.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. LiteLLM Proxy Server documentation (config, virtual keys, fallbacks) · 2026-05
2. Portkey AI Gateway – features, pricing, EU hosting · 2026-05
3. Cloudflare AI Gateway documentation – caching, rate limiting, analytics · 2026-04
4. OpenRouter – model marketplace and pricing · 2026-05
5. Helicone – open-source LLM observability and gateway · 2026-04
6. TECHSY analyst report – Stop Juggling LLM APIs: 8 Gateways Ranked 2026 · 2026-05