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, mit Fallback, Caching, Spend-Limits und Routing an einem Ort. Das ist eine Engineering-Perspektive, kein Vendor-Pitch. Die Feature- und Preis-Punkte unten sind Richtwerte mit Stand Juni 2026, aus den öffentlichen Docs und Seiten der jeweiligen Tools, also prüfe sie vor dem Commit erneut. Die Referenzpunkte stammen aus Wavects Arbeit an KI-Produkten, wo wir ein Gateway vor produktiven Traffic gesetzt und mit den Tradeoffs gelebt haben.

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. Tausche Claude gegen GPT gegen Gemini gegen ein Open-Weight-Modell, indem du einen Config-Wert änderst, nicht eine Call-Stelle. Das Provider-SDK-Lock-in verschwindet.
• Fallback. Wenn ein Provider einen Fehler liefert oder ein Timeout läuft, versucht das Gateway es gegen ein anderes Modell oder einen anderen Provider, damit ein einzelner Ausfall dein Produkt nicht mitreißt.
• 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, aber sie sind nicht dieselbe Art von Ding. Zwei sind vollwertige Gateways, eines ist ein gehosteter Aggregator, und eines ist ein Routing-Forschungs-Framework. Hier die Form von jedem, mit Capabilities, die im Juni 2026 gegen die jeweiligen Docs geprüft wurden. Als Momentaufnahme behandeln und vor dem Commit erneut prüfen.

LiteLLM ist das Open-Source-Arbeitstier: ein Proxy, den du selbst deployst, der 100+ Provider hinter einem OpenAI-Format-Endpoint normalisiert und Virtual Keys, Budgets, Rate-Limits, Fallback und Logging in einer Config-Datei zentralisiert, die du in deinem Repo versionierst. OpenRouter ist ein gehosteter Aggregator: ein Key, hunderte Modelle, für dich betrieben, mit einem Marktplatz-Modell, sodass du ein neues Modell am Tag seines Erscheinens erreichst, ohne bei jedem Provider ein Konto zu haben. Portkey ist ein Gateway, das mit Observability und Guardrails vorangeht; es hat seinen Core 2026 als Open Source veröffentlicht und verkauft zusätzlich eine Cloud-Tier. RouteLLM ist von anderer Art: ein Forschungs-Framework von LMSYS und Berkeley, um die Routing-Entscheidung selbst zu trainieren und zu servieren, nicht das umgebende Gateway.

"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.

• Gehostet (OpenRouter, Portkey Cloud). Du hast die Schicht an einem Nachmittag, ohne Infrastruktur zu betreiben. Der Preis ist eine Abhängigkeit, die du nicht kontrollierst, und bei OpenRouter Daten, die durch einen Dritten laufen, was ein EU-Team gegen seine Datenresidenz-Haltung abwägen muss. OpenRouters Katalogpreise entsprechen weitgehend den veröffentlichten Preisen der Provider, aber prüfe die Plattform- und Kreditkarten-Gebühren, die bei kleinen Top-ups einen spürbaren Prozentsatz draufschlagen können, sowie eine BYOK-Gebühr ab einer monatlichen Request-Schwelle. Aktuelle Gebühren vor dem Budgetieren erneut verifizieren.
• Self-host (LiteLLM, Portkey-Core, RouteLLM). Du betreibst den Proxy auf eigener Infrastruktur, also gehören dir Datenpfad und Upgrade-Kadenz. LiteLLM ist als Open Source gratis ohne Usage-Gebühren, aber du betreibst den Proxy plus Postgres und Redis, und diese Ops-Zeit ist der echte Preis. Für ein Team mit DevOps-Kapazität und einer Compliance-Anforderung ist das meist die richtige Wahl. Für ein zweiköpfiges Produktteam in Eile ist es Overhead, den es noch nicht braucht.

Der ehrliche Default: gehostet starten, um zu beweisen, dass sich die Schicht ihren Platz verdient, und auf Self-host wechseln, wenn Datenresidenz, Kosten bei Volumen oder Kontrolle die Frage erzwingen. Das spiegelt die Build-vs-Buy-Logik, die wir über KI-Produkt-Engagements hinweg anwenden, darunter Arbeit wie Twinsoft AI.

Wie gut sind Kostentracking und Observability?

Der Grund, warum das Controlling deine Rechnung spät bemerkt hat, ist, dass dir das Provider-SDK fast keinen Blick auf Spend pro Feature oder Team gibt. Ein Gateway ist der Ort, an dem dieser Blick lebt, und die vier Tools sitzen auf unterschiedlicher Tiefe.

• LiteLLM trackt Spend pro Key, User und Team, erzwingt Budgets und Rate-Limits und schickt Logs an Tools wie Langfuse und OpenTelemetry. Solide, und weil es dein Deployment ist, bleiben die Daten bei dir.
• Portkey geht mit Observability voran. Logs, Traces und Analytics sind das Produkt, und es berechnet nach aufgezeichneten Logs statt nach reinen Requests, sodass der Preis nachzeichnet, wie viel du beobachtest. Wenn du Dashboard, Guardrails und Audit-Trail out of the box willst, ist das das tiefste der vier.
• 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 gibt dir nichts davon. Es ist die Routing-Entscheidung, nicht die umgebende Plattform, also ist Observability das, was du drumherum baust.

Eine Warnung fügen wir immer an: Spend-Dashboards sagen dir, was du gezahlt hast, nicht, ob die Qualität gehalten hat. Ein Router, der schwerere Anfragen still an ein günstigeres Modell schickt, sieht im Kosten-Chart wie ein Gewinn aus und in der Produktion wie ein Verlust. Du brauchst neben dem Gateway einen Eval-Harness, um das zu fangen, und kein Gateway liefert einen mit. Diese Disziplin liegt bei dir.

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.

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.

Keines davon ist eine dauerhafte Festlegung, solange deine Anwendung mit dem OpenAI-Request-Format spricht. Das ist der stille Vorteil des ganzen Musters: das Gateway ist das, was du tauschen kannst, gerade weil es die Naht standardisiert, von der dein Code abhängt.