LLM-Gateways im Vergleich 2026: LiteLLM vs OpenRouter vs Portkey vs RouteLLM

Die meisten Teams hängen ihr Produkt direkt an das SDK eines einzigen Providers. Das funktioniert, bis es das nicht mehr tut. Dann hat der Provider einen Ausfall, und deine App geht mit unter. Dann fragt das Controlling, warum ein außer Kontrolle geratener Job an einem Nachmittag ein Monatsbudget verbrannt hat. Dann erscheint ein neues Modell, das für die Hälfte deines Traffics günstiger und besser ist, und ein Wechsel bedeutet, jede Call-Stelle anzufassen. Also schraubt das Team Retries, ein Spend-Limit, einen zweiten Provider und einen Cache dran und hat binnen eines Quartals eine halbe Agent-Infrastrukturschicht schlecht im eigenen Code nachgebaut, ohne dass jemand sie verantwortet.

Diese fehlende Schicht hat einen Namen: das LLM-Gateway. Ein Endpoint vor vielen Providern kann Fallback, Caching, Spend-Limits und Routing zentralisieren. Das ist eine Engineering-Perspektive, kein Vendor-Pitch. Wir haben die Feature-, Lizenz-, Datenschutz- und Preisangaben unten am 2. September 2026 anhand von Primärquellen geprüft. Kataloge und Gebühren ändern sich, deshalb sollten sie im Einkauf erneut verifiziert werden.

Was macht ein LLM-Gateway eigentlich?

Ein Gateway ist ein Proxy, der zwischen deiner Anwendung und den Modell-Providern sitzt. Dein Code ruft einen Endpoint auf, meist im OpenAI-Request-Format, und das Gateway übersetzt den Call und leitet ihn an den Provider weiter, der ihn bedienen soll. Diese eine Naht ist der Ort, an dem du die Features bekommst, die du sonst von Hand nachbaust:

• Ein Endpoint über viele Provider. Eine gemeinsame Request-Oberfläche reduziert providerspezifischen Code. Lock-in verschwindet nicht vollständig, denn Tools, Schemas, Sicherheitsverhalten und Modellsemantik unterscheiden sich weiter.
• Fallback. Bei einem passenden Fehler oder Timeout kann ein konfiguriertes Gateway ein anderes Deployment, Modell oder einen anderen Provider versuchen. Das verbessert Resilienz, garantiert aber keine Verfügbarkeit.
• Caching. Identische oder semantisch ähnliche Anfragen können eine gespeicherte Antwort zurückgeben und den Modell-Call ganz überspringen, was auf repetitivem Traffic Kosten und Latenz senkt.
• Spend-Limits und Keys. Budgets und Rate-Limits pro Key, pro User oder pro Team, damit ein schlechter Loop das Konto nicht leerräumen kann und du jedem Team einen abgegrenzten Virtual Key geben kannst.
• Routing. Schick die einfache Mehrheit an ein günstiges Modell und die schwere Minderheit an ein Frontier-Modell, per Regel oder per gelernter Policy.
• Observability. Ein Ort, an dem du jede Anfrage siehst, ihre Kosten, ihre Latenz und ihre Tokens, aufgeschlüsselt nach Modell, Key und Feature.

Routing ist der Kostenhebel, wegen dem die meisten kommen, und die Ökonomie dahinter haben wir in wie du LLM-Token-Kosten 2026 senkst behandelt. In diesem Beitrag geht es um die Tools, die dir diesen Hebel plus den Rest der Schicht geben.

Wie unterscheiden sich LiteLLM, OpenRouter, Portkey und RouteLLM?

Diese vier Namen fallen oft zusammen, sind aber nicht dieselbe Produktart. LiteLLM und Portkey bieten Gateway-Software, OpenRouter ist ein gehosteter Aggregator und RouteLLM ein Routing-Forschungs-Framework. Die Übersicht wurde am 2. September 2026 anhand von Primärquellen geprüft.

LiteLLM dokumentiert ein OpenAI-kompatibles Gateway und SDK für mehr als 100 LLM-APIs. Das Repository ist überwiegend MIT-lizenziert, Dateien im Enterprise-Verzeichnis stehen jedoch unter einer separaten kommerziellen Lizenz. OpenRouter ist ein gehosteter Aggregator mit konsolidierter Abrechnung, Provider-Routing und großem Katalog. Portkeys Gateway ist MIT-lizenziert und unterstützt Routing, Caching, Retries, Guardrails und Self-hosting; zusätzlich gibt es gehostete und Enterprise-Pläne. RouteLLM ist ein Framework von LMSYS und Berkeley zum Servieren und Evaluieren gelernter Routing-Entscheidungen, keine umgebende Gateway-Control-Plane.

"Drei davon sind Gateways und eines ist ein Router. RouteLLM mit LiteLLM zu vergleichen, heißt, das Gehirn mit dem Körper zu vergleichen. Die meisten Teams brauchen beides, und die meisten greifen zuerst zum Körper."

Self-host oder gehostet: was solltest du wählen?

Das ist die erste echte Entscheidung, und sie entscheidet meist das Tool. Der Tradeoff ist Kontrolle und Datenresidenz gegen Betriebsaufwand.

Wenn LiteLLM bereits Dein wahrscheinlicher Favorit ist, führt Dich unser Production-Guide zum Self-Hosting von LiteLLM durch Postgres, Redis, Key-Management, Patching und Go-live-Controls hinter dem Wort selbst gehostet.

• Gehostet (OpenRouter, Portkey Cloud). Du betreibst das Gateway nicht selbst, fügst aber einen weiteren Auftragsverarbeiter in den Request-Pfad ein. OpenRouter sagt, dass Prompt- und Completion-Logging Opt-in ist, während Request-Metadaten gespeichert werden und die Regeln der Upstream-Provider weiter gelten. Die Datenschutzkontrollen enthalten Providerfilter; Enterprise-Kunden können EU-internes Routing anfragen. Die FAQ nennt durchgereichte Inferenzpreise, 5,5 % Gebühr beim Credit-Kauf mit mindestens 0,80 US-Dollar und separate BYOK-Regeln. Da die Pricing-Seite BYOK-Freigrenzen inzwischen planabhängig ausdrückt, müssen FAQ, Pricing-Seite und Vertrag gemeinsam geprüft werden.
• Self-host (LiteLLM, Portkey-Gateway, RouteLLM). Du kontrollierst Gateway-Deployment und Upgrades, doch Calls erreichen weiterhin den konfigurierten Upstream-Provider. LiteLLMs Open-Source-Komponenten erheben keine Gateway-Gebühr pro Request; kommerzielle Features haben eigene Bedingungen. Persistentes Spend-Tracking und Produktionsarchitekturen können Postgres, Redis und weitere Dienste hinzufügen, aber nicht jede Installation benötigt sie.

Ein sinnvoller Default ist das Deployment-Modell, das deine Vorgaben zu Datenverarbeitung, Zuverlässigkeit und Betrieb bereits erfüllt. Self-hosting ist nicht automatisch compliant, und SaaS nicht automatisch ungeeignet. Prüfe Subprozessoren, Retention, Regionen, Keys und Incident-Verantwortung vor der Entscheidung.

Wie gut sind Kostentracking und Observability?

Provider-Dashboards können Account-Usage zeigen, ein Gateway kann aber die Zuordnung über mehrere Provider konsolidieren und Anwendungsmetadaten anhängen. Die vier Tools decken diese Aufgabe unterschiedlich tief ab.

• LiteLLM dokumentiert mandantenfähiges Spend-Tracking, Budgets, Rate-Limits und Logging-Callbacks. Self-hosting kontrolliert den Speicherort der Gateway-Telemetrie, nicht die Retention der Upstream-Provider.
• Portkey bietet Logs, Traces, Analytics, Feedback und Guardrails. Das Pricing im September 2026 zählt aufgezeichnete Logs: 10.000 pro Monat im Free-Plan und 100.000 im Production-Plan für 49 US-Dollar monatlich vor ausgewiesenen Overages. Requests laufen nach Überschreiten des Free-Limits weiter, weitere Logs werden aber nicht aufgezeichnet.
• OpenRouter gibt dir ein Usage-Dashboard und Analytics über die Modelle, die du aufrufst, was für viele Teams reicht und null Setup braucht.
• RouteLLM enthält Serving- und Eval-Werkzeuge, aber keine mandantenfähige Spend-, Key- und Produktions-Telemetrie-Control-Plane eines Gateways.

Spend-Dashboards sagen dir, was du gezahlt hast, nicht, ob die Qualität gehalten hat. Einige Plattformen bieten inzwischen Eval-Funktionen oder Integrationen, darunter Portkeys Eval-Templates und Batch-Eval-Anleitungen. Trotzdem brauchst du einen auf deine Aufgabe zugeschnittenen Acceptance-Datensatz und Release-Gate.

Wo passt RouteLLM hin, und sind die Zahlen echt?

RouteLLM ist als einziges der vier rein auf die Routing-Entscheidung ausgerichtet: schick eine Anfrage an das starke oder das günstige Modell. Die veröffentlichten Zahlen sind wirklich stark und sorgfältig zu zitieren. Das Team von LMSYS und Berkeley berichtet, dass ihr Matrix-Faktorisierungs-Router mit augmentierten Trainingsdaten rund 95 % der Performance von GPT-4 erreicht, während er nur 14 % der Calls ans starke Modell schickt, was sie auf rund 75 % günstiger als eine Random-Baseline beziffern, und über 85 % Kostensenkung auf dem MT-Bench-Eval.

Lies diese Zahlen als Richtwerte und so, wie die Quelle sie rahmt: sie stammen aus dem ursprünglichen RouteLLM-Paper, gebenchmarkt auf bestimmten Datensätzen (MT Bench, MMLU, GSM8K) gegen ein GPT-4-Klasse-Starkmodell, veröffentlicht 2024 und auf der ICLR 2025 präsentiert. Dein Traffic ist nicht diese Benchmarks, also werden die Einsparungen auf deinem Workload abweichen. Die ehrliche Botschaft ist die Form, nicht der exakte Prozentsatz: ein gelernter Router kann den Großteil der Qualität halten und nur eine Minderheit der Calls ans teure Modell schicken. Du musst es trotzdem auf deinem eigenen Eval beweisen, bevor du ihm vertraust.

In der Praxis wählst du RouteLLM nicht anstelle eines Gateways. Du kannst RouteLLM als Routing-Gehirn laufen lassen und ein Gateway für Fallback, Keys, Caching und Observability drumherum legen, oder du nutzt die einfacheren Routing-Regeln eines Gateways und sparst dir das Framework. RouteLLM verdient sich seinen Platz, wenn Routing dein größter einzelner Kostenhebel ist und regelbasiertes Routing Einsparungen liegen lässt.

Prüfst du konkret OmniRoute? Trenne diese Produktfrage vom Kategorievergleich. Unser OmniRoute-KI-Routing-Setup mit Produktions-Checkliste deckt Routendesign, Zugriffshärtung, Ausfalltests und die Eval Gates vor dem Rollout ab.

Wie solltest du wählen?

Ordne das Tool der Einschränkung zu, die dich tatsächlich bindet, nicht der längsten Feature-Liste:

1. Brauchst es heute, keine Infra zu betreiben. Greif zu einer gehosteten Option. OpenRouter für Modell-Breite hinter einem Key, Portkey Cloud, wenn du auch Observability und Guardrails ab Tag eins willst.
2. Datenresidenz oder volle Kontrolle zählen. Self-host. LiteLLM, wenn du einen schlanken, weitverbreiteten Open-Source-Proxy willst; Portkeys Open-Source-Core, wenn Observability und Guardrails erstklassige Anforderungen sind.
3. Observability und Guardrails haben Priorität. Portkey ist um sie herum gebaut. Die anderen loggen; Portkey macht das Log zum Produkt.
4. Routing ist dein größter Kostenhebel. Füge RouteLLM als Routing-Gehirn in das gewählte Gateway ein und beweise die Einsparungen auf deinem eigenen Eval.
5. Du bist unsicher. Starte mit einem gehosteten Gateway, instrumentiere es, und lass zwei Wochen echte Spend-pro-Feature-Daten dir sagen, was du optimieren sollst. Die Daten beantworten die Frage schneller als die Vergleichstabelle.

Eine schmale OpenAI-kompatible Schnittstelle kann Wechselarbeit reduzieren, macht Gateways aber nicht austauschbar. Teste Streaming, Tool Calls, Structured Outputs, Fehler, Authentifizierung und providerspezifische Erweiterungen vor einer Migration.