LLM-Gateways: was sie zwischen App und Modell-API leisten, was sie kosten und wo sie selbst zum Risiko werden (Oktober 2026)

So bin ich vorgegangen und was ich weggelassen habe

Bei jedem Gateway habe ich die Preisseite geöffnet, die Dokumentation zu Routing, Protokollierung und Produktivbetrieb gelesen und die eigenen Sicherheits- und Statusmeldungen des Anbieters durchgesehen. Als Quellen dienen Anbieterseiten und Dokumentation, zwei Pressemitteilungen von Palo Alto Networks und, für den LiteLLM-Vorfall, BleepingComputer und Arthur als Gegenprobe zur Darstellung des Anbieters. Was ich auf keiner Primärseite fand, blieb draußen.

Von den 7 Einträgen der Nische habe ich Artificial Analysis, eine Benchmark-Seite, und Msty, eine Desktop-App, aussortiert. Dataikus LLM Mesh steht im Explorer weiter unten. Eine Prüfung der Aussagen gab es dafür nicht: Der Anbieter nennt keinen Preis, und seine Gateway-Dokumentation habe ich in diesem Lauf nicht durchgesehen. Für die fünf Aussagen bleiben LiteLLM, Portkey, OpenRouter und Orq.ai. Jede Aussage bekommt ein Urteil (Stimmt, Teilweise, Stimmt nicht), und einen Eintrag in unseren eigenen Daten habe ich dabei korrigiert.

Belege: [1][2][3][4][5][6]

Aussage 1, eine Schnittstelle für jedes Modell: Teilweise

Der Aufruf sieht überall gleich aus. Was dahinter passiert, nicht. LiteLLM schreibt, es rufe über 100 LLM-APIs im OpenAI-Format auf. Die öffentliche Modellliste von OpenRouter lieferte am 4. Oktober 2026 466 Modelle, die Anbieterliste 112 Anbieter. Beide habe ich an diesem Tag selbst abgerufen. In unserem eigenen Eintrag standen mehr als 500 Modelle von mehr als 80 Anbietern, ich habe das korrigiert.

Die Unterschiede zeigen sich bei den Parametern. Unterstützt ein Anbieter einen mitgeschickten Parameter nicht, löst LiteLLM standardmäßig einen Fehler aus. Der Parameter wird nur verworfen, wenn Sie drop_params setzen. Laut eigener Dokumentation verwirft das ausschließlich nicht unterstützte OpenAI-Parameter, alles andere reicht LiteLLM als anbieterspezifisch durch. OpenRouter verfährt standardmäßig umgekehrt: Ein Anbieter ohne den Parameter kann die Anfrage trotzdem erhalten und ignoriert, was er nicht kennt, es sei denn, Sie setzen require_parameters.

Derselbe Code kann sich also je nach Gateway und Einstellung anders verhalten. Eine Anfrage mit Tool-Option oder Sampling-Parameter scheitert in einem Aufbau hörbar und läuft in einem anderen still ohne den Parameter durch. Die einheitliche Schnittstelle spart Integrationsarbeit. Die Frage der Kompatibilität wandert dafür in die Konfiguration.

Belege: [7][8][9][10][11]

Aussage 2, es kostet kaum Latenz: Stimmt, nach den Zahlen der Anbieter

Die Benchmark-Seite von LiteLLM beziffert den eigenen Aufschlag bei 1.170 Anfragen pro Sekunde auf vier Instanzen mit je 4 CPUs und 8 GB Speicher: Median 2 ms, 95. Perzentil 8 ms, 99. Perzentil 13 ms. Die gesamte Anfragedauer im selben Lauf lag bei 100, 150 und 240 ms. Das Open-Source-Gateway von Portkey wirbt mit unter 1 ms Latenz bei 122 kb Größe. Neben einem Modellaufruf, der Sekunden dauern kann, sind ein paar Millisekunden wenig.

Beide Zahlen stammen von den Anbietern selbst. Den einzigen direkten Vergleich fand ich in der Dokumentation von LiteLLM: LiteLLM v1.79.1-stable gegen Portkey v1.14.0, 95. Perzentil 150 ms gegen 230 ms. Die Seite vermerkt selbst, dass Portkey ohne Datenbank lief und LiteLLM mit, und nennt keinen unabhängigen Betreiber. Ich habe den Vergleich als Behauptung von LiteLLM über einen Wettbewerber gewertet und nichts damit gereiht.

Die Aussage stimmt für den Weg über den Proxy. Sie sagt nichts darüber, was ein Gateway kostet, wenn es zugleich Cache, Prüfinstanz oder Protokollierer ist. Dafür habe ich keine veröffentlichte Messung gefunden.

Belege: [12][13]

Aussage 3, Open Source heißt keine Gateway-Rechnung: Stimmt nicht

Stimmt nicht, und der Grund ist bei jedem Produkt ein anderer. Hier unterscheiden sich die Gateways am stärksten, deshalb habe ich die Preise so aufgeschrieben, wie die Anbieter sie veröffentlichen.

Das Hauptprojekt von LiteLLM steht unter MIT-Lizenz. Single Sign-on, SCIM, Audit-Logs zu jeder Anfrage und rund um die Uhr erreichbarer Support mit Reaktionszeiten gehören zur Enterprise-Ausgabe, die keinen veröffentlichten Preis und einen 30-Tage-Testschlüssel hat. Der Leitfaden für den Produktivbetrieb verlangt PostgreSQL, einen Pod mit 1 vCPU und 4 Gi Speicher und Redis, sobald mehr als eine Instanz läuft. Einen Serverpreis nennt der Anbieter nicht, deshalb kann ich für den Eigenbetrieb keine Zahl angeben.

Auch das Gateway von Portkey steht unter MIT-Lizenz. Der gehostete Dienst beginnt kostenlos mit 10.000 protokollierten Aufrufen im Monat und 3 Tagen Aufbewahrung der Logs. Production kostet 49 US-Dollar im Monat mit 100.000 Logs, 9 US-Dollar je weitere 100.000 und 30 Tagen Aufbewahrung. Enterprise gibt es auf Anfrage.

OpenRouter schreibt, es schlage nichts auf die Inferenzpreise auf, und erhebt trotzdem eine Plattformgebühr: 5,5 Prozent im Tarif Standard, 8 Prozent im Tarif Business, fällig beim Kauf von Guthaben. Mit eigenen Anbieterschlüsseln bleiben die ersten 25.000 US-Dollar Listenpreis-Inferenz im Monat gebührenfrei, danach gelten 5 Prozent. Orq.ai nimmt 4,5 Prozent auf Guthaben, wenn Sie dessen Schlüssel nutzen. Mit eigenen Schlüsseln ist es bis 1 Million Anfragen im Monat frei, danach gelten 4 Prozent. Beim Gratis-Tarif von OpenRouter passen die Angaben nicht zusammen: Die Preisseite verspricht über 25 kostenlose Modelle, die öffentliche Modellliste enthält 17 Kennungen mit der Endung :free. Beide Zahlen habe ich weggelassen.

Belege: [1][14][2][13][3][15][10][4]

Aussage 4, ein Gateway macht Sie ausfallsicherer: Teilweise, bis das Gateway ausfällt

Die Ausweichwege funktionieren wie beschrieben. Laut FAQ von OpenRouter weicht der Dienst auf den nächsten Anbieter aus, wenn einer einen Fehler meldet. Im Leitfaden zum Routing ist allow_fallbacks standardmäßig an, und Anbieter mit nennenswerten Ausfällen in den letzten 30 Sekunden werden nachrangig behandelt. Das Gateway von Portkey nennt automatische Wiederholungen, Ausweichwege und Lastverteilung, der Proxy von LiteLLM nennt Lastverteilung.

Ein Gateway ist aber auch eine weitere Stelle, die ausfallen kann. OpenRouter hat für Februar 2026 zwei Ausfälle beschrieben. Am 17. Februar scheiterten API-Anfragen 38 Minuten lang ab 5:27 Uhr UTC, am 19. Februar 35 Minuten lang ab 7:36 Uhr UTC. Zuerst fielen etwa 20 Prozent der Anfragen aus, später 80 bis 90 Prozent. Ursache war eine externe Caching-Komponente, ein Denial-of-Service-Angriff am 17. verdeckte sie anfangs. Autorisierungsabfragen, die wegen der Infrastruktur scheiterten, kamen als 401 zurück, was nach einem falschen Schlüssel aussieht. Inzwischen liefert OpenRouter dort 503.

Wer selbst hostet, macht die Verfügbarkeit des Gateways zur eigenen Aufgabe. Laut Leitfaden von LiteLLM sind ohne die Datenbank Modelle, die nur dort definiert sind, nicht erreichbar, und nicht zwischengespeicherte Abfragen virtueller Schlüssel schlagen fehl. Schlüssel im Cache funktionieren standardmäßig 60 Sekunden weiter.

Belege: [15][9][16][13][7][14]

Aussage 5, Eigenbetrieb nimmt das Anbieterrisiko weg: Stimmt nicht

Am 24. März 2026 wurde das PyPI-Konto eines Maintainers von LiteLLM übernommen, und die Versionen 1.82.7 und 1.82.8 erschienen mit einem Schadcode, der Zugangsdaten abgreift. LiteLLM gibt an, sie seien um 10:39 Uhr UTC veröffentlicht worden und etwa 40 Minuten online gewesen, bis PyPI sie sperrte. Kunden mit dem offiziellen Docker-Image des Proxys waren nicht betroffen, weil dieser Weg seine Abhängigkeiten festschreibt. Wer das Paket ohne feste Version installiert hatte, sollte alle Zugangsdaten auf diesem System als kompromittiert behandeln. Arthur nennt ein Fenster von unter fünf Stunden ab etwa 8:00 Uhr UTC. Ich folge hier der Darstellung des Anbieters und vermerke den Unterschied.

Der Anbieter führt die Ursache auf einen kompromittierten Trivy-Scanner in seiner Build-Pipeline zurück, der an Release-Geheimnisse kam. Am 30. März folgte die saubere Version 1.83.0 mit neu aufgebauter Release-Pipeline. Ein Gateway hält für jeden Anbieter, an den es weiterleitet, einen Schlüssel. Deshalb ging bei einem übernommenen Rechner so viel auf einmal verloren.

Es blieb nicht bei dieser Meldung. LiteLLM veröffentlichte am 18. März einen Fehler, bei dem die Protokollierung von Guardrails Authorization-Header im Klartext preisgab, am 21. April eine Befehlsinjektion, die einen Admin-Schlüssel braucht, am 29. April eine SQL-Injektion bei der Schlüsselprüfung ohne Anmeldung und am 1. Juni eine Umgehung der Authentifizierung über den Host-Header. Diese fünf Meldungen habe ich gelesen, sie fallen in 75 Tage. Der Sicherheitsindex des Anbieters führt in diesem Zeitraum zwei weitere Beiträge, ein Update zur Townhall und eine Zusammenfassung zur Härtung. LiteLLM veröffentlicht die Fälle und nennt die betroffenen Versionen, das ist ein Pluspunkt. Beim SQL-Fehler erwähnt der Beitrag keine Ausnutzung.

Die Eigentümerfrage ist ein zweites Anbieterrisiko. Palo Alto Networks kündigte am 30. April 2026 an, Portkey zu übernehmen, und schloss den Kauf am 29. Mai ab. Die Website heißt jetzt Prisma AIRS AI Gateway. Die Pressemitteilung sagt bestehenden Kunden weiteren Support zu und erwähnt das Open-Source-Gateway nicht.

Belege: [17][18][19][20][21][22][23][24][25][26][2]

Was das Gateway sieht: Prompts, Logs und ihre Wege

Ein Gateway sieht jeden Prompt, deshalb habe ich nachgelesen, was jedes standardmäßig speichert. OpenRouter hält Metadaten wie Tokenzahlen und Latenz und standardmäßig weder Prompts noch Antworten. Die Protokollierung ist eine Option zum Einschalten. Mit einer zweiten Option darf OpenRouter Ihre Ein- und Ausgaben nutzen und gibt dafür 1 Prozent Rabatt. Die FAQ der Preisseite sagt, OpenRouter trainiere nicht mit Ihren Daten. Beim Routing gilt ein anderer Standard: data_collection steht auf allow und erlaubt Anbieter, die Daten dauerhaft speichern und damit trainieren dürfen. Mit deny oder zdr beschränkt sich das Routing auf Anbieter mit passenden Richtlinien.

Portkey zeichnet standardmäßig die rohen Anfrage- und Antwortobjekte auf und zeigt sie in den Logs. Die Aufbewahrung beträgt im Gratis-Tarif 3 Tage und in Production 30 Tage. Die Einstellung DO NOT TRACK reduziert einen Eintrag auf Tokens, Kosten und Latenz. Zum Speicherort sagt die Logging-Dokumentation, die ich gelesen habe, nichts.

Für europäische Daten nennt sich Orq.ai EU-built und EU-hosted. OpenRouter bietet mit eu.openrouter.ai einen EU-Endpunkt, an dem Anfragen in der Region entschlüsselt und verarbeitet werden und mit 404 scheitern, wenn dort kein Anbieter das Modell bereitstellt. Das gibt es nur in den Tarifen Business und Enterprise. Unser Verzeichnis zeigt 1 Produkt der Nische mit EU-Region.

Ein gehostetes Gateway, das Prompts mit personenbezogenen Daten verarbeitet, handelt in Ihrem Auftrag. Nach Art. 28 DSGVO braucht es dafür einen Vertrag, der unter anderem die Verarbeitung nur auf dokumentierte Weisung und Bedingungen für Unterauftragsverarbeiter regelt. Die Nutzungsbedingungen von OpenRouter verweisen für gewerbliche Nutzer auf einen Auftragsverarbeitungsvertrag.

Arbeiten Beschäftigte über ein firmeninternes Chatfenster mit dem Gateway, kommt das Betriebsverfassungsrecht ins Spiel. Nach § 87 Abs. 1 Nr. 6 BetrVG hat der Betriebsrat mitzubestimmen bei der Einführung technischer Einrichtungen, die dazu bestimmt sind, das Verhalten oder die Leistung der Arbeitnehmer zu überwachen. Ob ein Gateway mit Prompt-Protokollen darunter fällt, klären Sie mit Rechtsberatung. Das Protokollierungsverhalten oben ist die Auskunft, die Sie dafür brauchen.

Belege: [27][9][3][28][29][30][2][4][31][32][6]

Wann ein Gateway seinen Platz verdient

Bei einem Anbieter und einer Anwendung fügt ein Gateway einen Zwischenschritt, eine Abhängigkeit und einen zweiten Ort für Ihre Schlüssel hinzu, hat aber noch keine Aufgabe. Mit mehreren Anbietern, mehreren Teams oder dem Wunsch nach Budgets je Schlüssel beginnt es sich zu lohnen. Dann lautet die Frage, wer es betreibt.

Ein gehostetes Gateway kostet einen Prozentsatz oder eine Monatsgebühr und verlagert Betrieb und Datenhandhabung zu einem Anbieter, dessen Vertrag Sie lesen müssen. Ein selbst betriebenes kostet keine Lizenz, aber eine Betriebsroutine samt schnellem Einspielen von Updates. Unser Verzeichnis führt 43 Produkte der KI-Infrastruktur, die 7 der Gateway-Nische sind nur ein Anfang dieser Liste.

Belege: [14][19][28][6]