LLM-Proxy-Ranking 2026: Vier Tools im Vergleich

LLM-Proxy-Ranking 2026: Ihre Entscheidung für diese Woche

Wählen Sie LiteLLM für ein selbst gehostetes Standard-Gateway, prüfen Sie Switchyard für Coding Agents und offene Modelle, nutzen Sie OpenRouter für schnelles verwaltetes Multi-Provider-Routing und bewerten Sie Portkey für Governance mit Observability. Diese Empfehlung gilt nur, wenn Sie die Bereitstellung nach Teamtyp trennen. Ein pauschales Ranking von eins bis vier wäre bei diesen vier Lösungen fachlich irreführend.

Zeitplan für den 13.08.2026: Am ersten Tag klären Sie Datenpfad, Zugangsschlüssel und Logging. Danach testen Sie Routing, Fallbacks und Kostenkontrolle mit denselben Anfragen. Erst dann entscheiden Sie zwischen Selbsthosting, verwaltetem Routing und einem hybriden Gateway.

Diese Übersicht richtet sich an:

• AI-Plattformteams mit einem einheitlichen Modellzugang,
• Anwendungsentwickler, die mehrere Provider ohne eigene Adapter integrieren wollen,
• Enterprise-Architekten, die Selbsthosting, Managed Services und Hybridbetrieb vergleichen.

Die Bewertung basiert auf offiziellen Projektunterlagen und Produktdokumentationen, nicht auf unbestätigten Angaben zu Durchsatz, Latenz, Kundenzahl oder Marktanteil. Die Daten wurden am 13.08.2026 anhand der verfügbaren Dokumentation zu Routing, Fallbacks, Authentifizierung, Budgetierung, Observability, Deployment und Datenkontrolle geprüft.

Die vier Lösungen nach ihrem Einsatzmodell

Der wichtigste Unterschied liegt nicht in der Modellanzahl. Entscheidend ist, wo die zentrale Kontrollschicht betrieben wird und wer Provider-Schlüssel, Logs und Datenflüsse kontrolliert.

LiteLLM: selbst gehosteter Standard für Plattformteams

LiteLLM stellt einen Proxy beziehungsweise ein AI Gateway bereit, das Anfragen in ein einheitliches Format übersetzt. Die offizielle LiteLLM-Dokumentation nennt Unterstützung für mehr als 100 LLMs und beschreibt Funktionen wie Authentifizierung, virtuelle Schlüssel, Kostenverfolgung, Projektbudgets, Rate Limits, Fallbacks und Load Balancing.

Das ist für Sie interessant, wenn mehrere interne Projekte über einen zentralen Endpunkt laufen sollen. Entwickler können gegen eine einheitliche Schnittstelle programmieren. Das Plattformteam behält die Provider-Schlüssel und kann Budgets je Projekt oder Nutzer begrenzen.

Der versteckte Aufwand liegt im Betrieb. Ein LiteLLM-Proxy ist noch keine vollständige Produktionsplattform. Sie benötigen zusätzlich Secret Management, Datenbank oder Konfigurationsspeicher, Monitoring, Backups, TLS, Netzwerkregeln und einen Update-Prozess. Für hohe Verfügbarkeit kommen mindestens ein getesteter Failover-Weg und eine klare Zuständigkeit für Störungen hinzu.

Switchyard: Routing für Coding Agents und offene Modelle

Switchyard ist laut offiziellem Repository ein Python-Proxy für LLM-Verkehr. Das Projekt übersetzt zwischen OpenAI-Chat-, Anthropic-Messages- und OpenAI-Responses-Formaten. Es kann Anfragen unter anderem an vLLM, NVIDIA NIM, Ollama oder andere OpenAI-kompatible Endpunkte weiterleiten. Zusätzlich werden Routing-Profile und Anfragekennzahlen wie Tokenverbrauch, Kosten und Latenz unterstützt.

Der Schwerpunkt ist damit ein anderer als bei einem klassischen Enterprise-Gateway. Switchyard ist besonders interessant, wenn ein Coding Agent seine gewohnte API behalten soll, während Sie dahinter offene Modelle, lokale Inferenz oder alternative Endpunkte testen.

Die Reifegrenze müssen Sie jedoch selbst prüfen. Die offizielle Dokumentation beschreibt Launcher, Protokollübersetzung, Routing-Profile und Statistiken. Daraus folgt nicht automatisch, dass alle Enterprise-Anforderungen wie mehrstufige Mandantentrennung, revisionssichere Audit-Logs, Hochverfügbarkeit oder ein vollständiges Budget-Management bereits gleichwertig abgedeckt sind. Für ein kleines Agent-Team kann Switchyard sehr passend sein. Für eine zentrale Unternehmensplattform sollten Sie es zunächst in einer isolierten Testumgebung bewerten.

OpenRouter: verwalteter Zugang zu mehreren Providern

OpenRouter nimmt Ihnen einen großen Teil des Infrastrukturaufwands ab. Sie erhalten einen verwalteten Zugang zu mehreren Modellen und Providern. Die Entscheidung über die Zielanbieter wird damit teilweise an die Routing- und Providerlogik des Dienstes delegiert.

Für schnelle Prototypen, persönliche Projekte und Teams ohne eigene Gateway-Betriebsverantwortung ist das ein klarer Vorteil. Sie müssen keine eigene Proxy-Instanz patchen, keine interne Routing-Schicht aufbauen und nicht sofort mehrere Provideradapter pflegen.

Der Nachteil ist die geringere Kontrolle über den vollständigen Datenweg. OpenRouter dokumentiert Einstellungen für Zero Data Retention, mit denen nur Endpunkte berücksichtigt werden sollen, die eine entsprechende Richtlinie erfüllen. Die Dokumentation zu Zero Data Retention weist zugleich darauf hin, dass sich Richtlinien je Endpunkt unterscheiden können und dass „nicht für Training verwendet“ nicht automatisch „nicht gespeichert“ bedeutet.

Für DSGVO-relevante oder vertrauliche Daten reicht es deshalb nicht, nur einen Schalter im Dashboard zu aktivieren. Sie müssen Provider, konkreten Endpunkt, Logging, Caching, Missbrauchsprüfung und Vertragsbedingungen gemeinsam prüfen.

Portkey: Gateway plus Governance-Schicht

Portkey verbindet ein AI Gateway mit Routing, Fallbacks, Retries, Caching, Guardrails, Budgetgrenzen, Rate Limits und Observability. Die Produktdokumentation zum AI Gateway beschreibt auch Circuit Breaker, Load Balancing, Canary Testing und bedingtes Routing. Das macht Portkey für Unternehmen interessant, die nicht nur Provider abstrahieren, sondern Modellbetrieb kontrolliert ausrollen wollen.

Portkey ist damit nicht einfach „LiteLLM mit anderem Namen“. Der relevante Vergleichspunkt ist die Kombination aus Gateway und verwalteter Governance. Sie sollten unterscheiden, ob eine Funktion im offenen Gateway, im selbst gehosteten Deployment oder in der Plattform enthalten ist.

Portkey dokumentiert außerdem Hybridarchitekturen, bei denen der Gateway lokale Konfigurationen nutzt und Logs an einen zentralen Log Store übertragen kann. Die Beschreibung der Hybridbereitstellung macht sichtbar, dass Gateway, Control Plane und Log Store unterschiedliche Datenpfade bilden können.

Das kann für regulierte Teams sinnvoll sein. Es schafft aber eine zusätzliche Architekturfrage: Welche Daten bleiben im eigenen Netzwerk, welche Konfigurationen liegen in der Control Plane und welche Logs verlassen die eigene Umgebung?

Die Auswahl nach Teamprofil

Einzelentwickler und schnelle Prototypen

Wenn Sie in kurzer Zeit mehrere Modelle ausprobieren wollen, ist OpenRouter meist der schnellste Weg. Die Infrastruktur ist geringer. Sie können Modelle vergleichen, ohne für jeden Provider eine eigene Integrationsschicht zu bauen.

Vor der ersten produktiven Nutzung sollten Sie trotzdem vier Punkte prüfen:

1. Werden API-Schlüssel ausschließlich serverseitig verwendet?
2. Ist der ausgewählte Provider für Ihren konkreten Endpunkt dokumentiert?
3. Sind Logging und Datenaufbewahrung passend eingestellt?
4. Gibt es einen manuellen oder automatischen Fallback, wenn ein Endpunkt ausfällt?

LiteLLM ist für Einzelentwickler dann sinnvoller, wenn Sie bereits einen eigenen Server, lokale Modelle oder mehrere interne Testanwendungen betreiben. Der zusätzliche Betriebsaufwand lohnt sich erst, wenn Kontrolle wichtiger wird als der schnellste Start.

Coding Agents und lokale Modellteams

Für Claude Code, Codex-ähnliche CLI-Werkzeuge und andere Coding Agents ist Protokollkompatibilität entscheidend. Ein Proxy muss nicht nur das Modell weiterleiten. Er muss die erwarteten Nachrichtenformate, Streaming-Antworten, Tool-Aufrufe und Fehlercodes korrekt behandeln.

Switchyard verdient hier besondere Aufmerksamkeit, weil es die Übersetzung zwischen mehreren API-Stilen und den Start von Coding-Agent-Launchern in den Mittelpunkt stellt.

Die Auswahl sollte mit einem kleinen Kompatibilitätstest beginnen:

• einfacher Textaufruf,
• Streaming,
• Tool- oder Function-Call,
• große Kontextanfrage,
• absichtlicher Providerfehler,
• Fallback auf einen zweiten Endpunkt,
• Prüfung der Kosten- und Tokenstatistik.

Wenn nur OpenAI-kompatible Endpunkte genutzt werden und Sie zusätzlich Teambudgets benötigen, kann LiteLLM die robustere Plattformbasis sein. Wenn lokale Modelle, Agent-Launcher und flexible Routing-Profile im Vordergrund stehen, ist Switchyard der passendere Prüfkanidat.

Selbst gehostete Plattformen mit mehreren Projekten

Für diese Zielgruppe führt der erste Weg meist zu LiteLLM. Die Kombination aus einheitlicher Schnittstelle, virtuellen Schlüsseln, Ausgabenübersicht, Budgets, Rate Limits und Providerabstraktion passt direkt zum Plattformbetrieb.

Planen Sie die Architektur nicht als einzelnes Docker-Experiment. Teilen Sie sie in fünf Verantwortungsbereiche:

1. Zugang: virtuelle Schlüssel, Rollen, Team- und Projekttrennung.
2. Routing: Modellalias, Providerpriorität, Fallback und Timeout.
3. Kosten: Budget pro Projekt, Nutzer oder Schlüssel.
4. Beobachtung: Request-ID, Modell, Token, Fehler, Kosten und Latenz.
5. Betrieb: Datenbank, Backup, Secrets, Updates und Wiederherstellung.

Ein häufiger Fehler ist, nur die API-Kompatibilität zu testen. In Produktion entstehen Probleme eher durch unklare Schlüsselverwaltung, fehlende Log-Redaktion, unkontrollierte Fallbacks oder ein Budget, das erst nach dem Überschreiten sichtbar wird.

Teams mit verwaltetem Provider-Routing

OpenRouter ist für diese Gruppe dann überzeugend, wenn Geschwindigkeit und Modellbreite höher bewertet werden als vollständige Infrastrukturkontrolle. Die Providerwahl und das Routing können den Integrationsaufwand reduzieren.

Die Prüfung muss aber über das Modellmenü hinausgehen. Erstellen Sie für jedes sensible Projekt eine Datenflusskarte:

• Anwendung,
• Proxy,
• ausgewählter Provider,
• Modell-Endpunkt,
• Logging,
• Caching,
• Missbrauchsprüfung,
• Aufbewahrung,
• möglicher Supportzugriff.

Die Zero-Data-Retention-Einstellung ist hilfreich, aber kein Ersatz für eine Datenschutzprüfung. Providerangaben müssen auf Endpunktebene betrachtet werden. Für nicht vertrauliche Experimente kann das ausreichend sein. Für Quellcode, personenbezogene Daten oder interne Geschäftsdokumente sollten Sie die tatsächlichen Providerbedingungen und Ihre vertraglichen Anforderungen dokumentieren.

Unternehmen mit Governance- und Observability-Anforderungen

Portkey ist in diesem Profil der stärkste Kandidat, wenn mehrere Kontrollfunktionen in einer gemeinsamen Plattform zusammenlaufen sollen. Routing, Fallbacks, Guardrails, Caching, Budgetgrenzen und Protokollierung sind nicht als getrennte Einzelbausteine zu betrachten. Sie greifen in die Betriebsprozesse ein.

Beispiel: Ein neues Modell soll zunächst nur einen kleinen Teil des Traffics erhalten. Dafür benötigen Sie nicht nur eine Modellkonfiguration, sondern auch Canary-Logik, Auswertung, Kostenkontrolle und einen Rückweg. Ein Gateway mit diesen Funktionen kann den Prozess vereinfachen.

Portkey ist jedoch nicht automatisch die beste Wahl für jedes Unternehmen. Wenn Ihre Hauptanforderung lautet, alle Schlüssel und Logs ausschließlich in der eigenen Umgebung zu halten, müssen Sie das Hybrid- oder Self-Hosting-Modell genau gegen Ihre Sicherheitsvorgaben prüfen.

Der belastbare Auswahlprozess

1. Datenklassen festlegen

Teilen Sie Ihre Anfragen mindestens in öffentliche, interne, personenbezogene und streng vertrauliche Daten ein. Legen Sie fest, welche Klasse einen verwalteten Aggregator verwenden darf und welche Klasse nur über einen kontrollierten eigenen oder vertraglich abgesicherten Endpunkt laufen darf.

2. Provider-Schlüssel aus der Anwendung entfernen

Die Anwendung sollte nicht mit vier unterschiedlichen Provider-Schlüsseln arbeiten. Legen Sie die Schlüssel im Proxy oder in einem Secret Manager ab. Entwickler erhalten kurzlebige oder eingeschränkte Zugangsdaten. Prüfen Sie außerdem, ob Logs versehentlich Authorization-Header oder vollständige Prompts enthalten.

3. Einen Modellalias pro Anwendungsfall definieren

Verwenden Sie nicht überall den konkreten Provider-Modellnamen. Legen Sie Aliase wie „coding-fast“, „reasoning-standard“ oder „embedding-internal“ fest. Dahinter können Sie Provider wechseln, ohne jede Anwendung neu auszurollen.

4. Fallbacks mit Grenzen testen

Ein Fallback darf nicht zu einer Kostenexplosion führen. Testen Sie absichtlich einen Fehler und prüfen Sie, ob der Proxy korrekt auf den Ersatzendpunkt wechselt. Prüfen Sie dabei auch, ob Streaming, Tool-Aufrufe und Kontextlängen kompatibel bleiben.

5. Budget und Rate Limits simulieren

Legen Sie für ein Testprojekt ein kleines Budget fest. Senden Sie danach kontrollierte Anfragen und prüfen Sie, wann die Sperre greift. Ein Dashboard ohne erzwingbare Grenze ist keine Kostenkontrolle.

6. Logs auf Datenschutz prüfen

Erfassen Sie nur die Felder, die Sie für Fehlersuche und Abrechnung benötigen. Reduzieren oder anonymisieren Sie Prompts, Antworten und Identifikatoren. Bei einem verwalteten Aggregator prüfen Sie zusätzlich die Datenpolitik des konkreten Endpunkts und nicht nur eine globale Einstellung.

7. Wiederherstellung dokumentieren

Speichern Sie Konfigurationen versioniert. Halten Sie Provider-Schlüssel außerhalb des Repositorys. Dokumentieren Sie, wie Sie Routing, Budgets und Zugangsdaten nach einem Ausfall wiederherstellen. Für LiteLLM gehören diese Aufgaben zum produktiven Betrieb, auch wenn der Proxy selbst schnell gestartet ist.

8. Einen realen Agent- und Produktionslauf durchführen

Ein einzelner Chat-Aufruf reicht nicht. Nutzen Sie einen echten Workflow mit Streaming, Tool-Aufrufen, längeren Kontexten, Fehlern, Kostenlimits und mehreren Nutzern. Erst dieser Test zeigt, ob Switchyard, LiteLLM, OpenRouter oder Portkey zu Ihrem tatsächlichen Betriebsmodell passt.

Datenrisiken und Hybridbetrieb

Ein hybrides Modell ist oft der vernünftigste Kompromiss. Sie können interne Anwendungen über einen eigenen Gateway-Endpunkt führen und für unkritische Experimente einen verwalteten Dienst verwenden. Entscheidend ist eine harte Trennung der Datenklassen und Zugangsschlüssel.

Für regulierte Teams sollten Sie mindestens diese Fragen schriftlich beantworten:

• Wo wird der Request verarbeitet?
• Werden Prompt und Antwort protokolliert?
• Wie lange bleiben Logs erhalten?
• Wird Caching verwendet?
• Welche Provider erhalten die Daten?
• Kann das Routing ohne Freigabe den Provider wechseln?
• Welche Auditdaten müssen unverändert erhalten bleiben?
• Wie werden Löschanfragen und Datenschutzverletzungen bearbeitet?

Wenn Sie für Tests eine kontrollierte Mac- oder Linux-Umgebung benötigen, kann ein separater gemieteter Rechner sinnvoller sein als die direkte Ausführung auf Entwicklergeräten. Prüfen Sie dafür die Informationen zu VPSSpark und trennen Sie Testdaten von produktiven Geheimnissen. Für Teams in Nordamerika können Sie eine Umgebung in US East oder US West als isolierten Evaluierungsstandort betrachten. Standortwahl ersetzt jedoch keine Datenschutzvereinbarung und keine Providerprüfung.

Die vier Rankings nach Publikum

Die folgende Einordnung ist eine Entscheidungshilfe, keine absolute Marktwertung.

Die Tabelle zeigt auch, warum ein Gesamtsieger unseriös wäre. OpenRouter gewinnt beim Starttempo. LiteLLM gewinnt bei eigener Kontrolle. Switchyard gewinnt bei bestimmten Coding-Agent- und Open-Model-Szenarien. Portkey gewinnt bei kombinierter Governance. Die Bewertung hängt vom Bereitstellungsmodell ab.

Was Ihre aktuelle Lösung kostet

Wenn Sie heute jeden Provider direkt aus der Anwendung aufrufen, entstehen meist vier konkrete Nachteile: doppelte Adapterlogik, verstreute Schlüssel, uneinheitliche Fehlerbehandlung und kaum vergleichbare Kosten- oder Latenzlogs. Ein einzelner Managed Aggregator beseitigt zwar Integrationsaufwand, verlagert aber Datenkontrolle und Routingentscheidungen nach außen. Ein selbst gebauter Gateway wiederum bindet Zeit für Authentifizierung, Limits, Fallbacks und Wartung.

Für kurzfristige Modelltests oder Coding-Agent-Experimente kann eine gemietete, getrennte VPSSpark-Umgebung deshalb praktischer sein als die Umrüstung Ihrer lokalen Rechner. Sie erhalten einen kontrollierbaren Ort für Konfiguration, Tests und Providerwechsel, ohne sofort neue Hardware zu kaufen. Für dauerhaft hohe Last, physische Spezialhardware oder streng interne Daten ist eine eigene Infrastruktur weiterhin die bessere Entscheidung. Bewerten Sie zuerst den Betriebsmodus und erst danach den Anbieter.

Häufige Fragen

Welches LLM-Proxy eignet sich 2026 am besten für ein Unternehmen?

Eine allgemeingültige Nummer eins gibt es nicht. Für ein selbst gehostetes Unternehmens-Gateway ist LiteLLM meist der naheliegende Startpunkt, weil Authentifizierung, Budgets, Routing und Provider-Abstraktion zusammengeführt werden. Portkey ist stärker, wenn Governance, Guardrails und Observability als Plattform benötigt werden. Prüfen Sie zusätzlich Datenstandort, Auftragsverarbeitung, Audit-Anforderungen und Hochverfügbarkeit.

Was sollte ein selbst gehostetes LLM Gateway können?

Achten Sie auf ein stabiles API-Format, getrennte Zugangsschlüssel, Projekt- und Nutzerbudgets, Rate Limits, Fallbacks, Protokollierung und einen klaren Betriebsweg für Updates. LiteLLM deckt viele dieser Funktionen ab. Die Software ersetzt jedoch nicht Datenbank, Secret Management, Monitoring, Backup, Netzwerksegmentierung und einen getesteten Hochverfügbarkeitsplan.

Worin unterscheiden sich OpenRouter und LiteLLM?

OpenRouter ist primär ein verwalteter Aggregator mit Provider-Auswahl und Routing-Regeln. LiteLLM ist vor allem ein selbst betreibbarer Proxy beziehungsweise ein Gateway für Ihre eigene Infrastruktur und Ihre eigenen Provider-Schlüssel. OpenRouter reduziert den Betriebsaufwand. LiteLLM gibt Ihnen mehr Kontrolle über Netzwerk, Schlüssel, Logs und interne Zugriffsmodelle.

Ist Portkey für die zentrale Verwaltung mehrerer Modelle geeignet?

Ja, wenn Sie neben Routing auch zentrale Protokollierung, Caching, Guardrails, Budgetgrenzen und Governance benötigen. Portkey bietet dafür Gateway- und Plattformfunktionen. Prüfen Sie aber genau, welche Funktionen im offenen Gateway enthalten sind und welche an die verwaltete Plattform oder bestimmte Vertragsbedingungen gebunden sind. Für ein schlankes internes Proxy genügt oft eine einfachere Lösung.

Welche Datenrisiken müssen Sie bei einem LLM-Proxy prüfen?

Entscheidend sind nicht nur die Einstellungen des Proxys, sondern der gesamte Datenweg: Proxy-Logs, Provider-Endpunkt, Prompt-Caching, Missbrauchsprüfung, Trainingsnutzung, Aufbewahrungsdauer und Supportzugriff. Bei OpenRouter können Sie Zero-Data-Retention-Regeln aktivieren, müssen aber trotzdem die konkrete Provider- und Endpunktpolitik prüfen. Für besonders sensible Daten bleibt Selbsthosting oder ein vertraglich abgesicherter Hybridbetrieb vorzuziehen.

Wenn Sie Ihr Ranking jetzt praktisch anwenden, beginnen Sie nicht mit einer pauschalen Siegerliste. Streichen Sie zuerst alle Lösungen, die Ihr gewünschtes Bereitstellungsmodell, Ihre Datenklasse oder Ihre Betriebsressourcen nicht erfüllen. Danach testen Sie die verbleibenden Kandidaten mit demselben Agent- und Produktionsworkflow. Für temporäre Rechenkapazität oder eine isolierte Validierungsumgebung kann eine gemietete VPSSpark-Umgebung sinnvoll sein. Für dauerhaft hohe Last, physische Spezialhardware oder streng interne Daten bleibt eine eigene Infrastruktur die bessere Wahl.