LLM Gateway: selbst gehostetes Routing und Kostenkontrolle für LLM-Anfragen

Welches Problem der Gateway adressiert

Sobald eine Anwendung mehr als einen LLM-Anbieter anspricht, entstehen drei wiederkehrende Aufgaben: Zugangsdaten an mehreren Stellen pflegen, Antwortformate der Anbieter aufeinander abbilden und nachvollziehen, welches Modell welchen Anteil an Tokens und Kosten verursacht. Das README beschreibt LLM Gateway genau als diese Zwischenschicht: eine Middleware zwischen Anwendung und Providern, die Anfragen weiterleitet, API-Schlüssel zentral verwaltet und Nutzung sowie Antwortzeiten erfasst. Die Zielgruppe ergibt sich daraus: Entwicklungsteams, die mehrere Provider parallel nutzen oder einen Wechsel vorbereiten, sowie Betreiber, die Ausgaben pro Modell sehen wollen, ohne dafür eine externe Plattform einzuschalten. Der Gateway ist ausdrücklich kein Modell und kein Inference-Anbieter. Er leitet weiter und protokolliert.

OpenAI-kompatible Schnittstelle als Migrationspfad

Die zentrale Designentscheidung ist die Kompatibilität zum OpenAI-API-Format. Das README nennt sie als Feature und liefert ein Beispiel, das gegen api.llmgateway.io/v1/chat/completions geht, mit Authorization-Header vom Typ Bearer und einem Nutzlast-Objekt aus model und messages. Wer bereits gegen die OpenAI-API entwickelt hat, ändert damit im Idealfall nur Basis-URL und Schlüssel. Der Preis dieser Entscheidung ist, dass alles, was nicht in dieses Schema passt, entweder abgebildet oder weggelassen werden muss. Das README zeigt keine anbieterspezifischen Parameter, keine Werkzeugaufrufe und keine Streaming-Beispiele. Ob Funktionen wie Tool-Calling oder strukturierte Ausgaben über den Gateway verlustfrei durchgereicht werden, lässt sich aus dem vorliegenden Material nicht belegen. Wer darauf angewiesen ist, muss das vor dem Umstieg selbst prüfen, und zwar an der eigenen Nutzlast, nicht an einem Hello-World-Beispiel.

Aufbau des Repositories: Monorepo mit getrennten Diensten

Die Ordnerstruktur zeigt ein Monorepo mit klar getrennten Rollen. apps/gateway enthält den eigentlichen Routing-Dienst für LLM-Anfragen, apps/api das Hono-Backend, apps/ui das Next.js-Dashboard. Dazu kommen apps/playground mit einer Chat-Anwendung namens Lounge, apps/code für Coding-Werkzeuge, apps/airside als Self-Serve-Portal für Anbieter sowie apps/docs. packages/db hält das Drizzle-ORM-Schema samt Migrationen, packages/models die Definitionen von Modellen und Providern, packages/shared gemeinsame Typen. ee/admin ist ein internes Administrationsdashboard und liegt damit bereits im Enterprise-Verzeichnis. Diese Aufteilung ist praktisch relevant: Wer Modelle oder Provider ergänzen will, arbeitet in packages/models, nicht im Gateway-Code. Wer das Datenbankschema ändert, braucht Migrationen aus packages/db. Die Anwendungen oberhalb des Gateways sind für den Betrieb nicht zwingend, aber sie erklären, warum das Repository deutlich größer ist als ein reiner Proxy.

Betrieb: Docker, Volumes und die zwei Secrets

Das README beschreibt zwei Wege. Für den gehosteten Dienst genügt ein Konto und ein API-Schlüssel. Für den Selbstbetrieb führt der dokumentierte Weg über ./scripts/run-unified-container.sh, vorher werden zwei Umgebungsvariablen gesetzt: LLM_GATEWAY_SECRET und GATEWAY_API_KEY_HASH_SECRET, beide erzeugt mit openssl rand -base64 32. Alternativ zeigt das README einen einzelnen docker run gegen ghcr.io/theopenco/llmgateway-unified:latest mit den Ports 3002, 3003, 3005, 3006, 3007, 4001 und 4002 sowie zwei benannten Volumes, llmgateway_postgres auf /var/lib/postgresql/data und llmgateway_redis auf /var/lib/redis. Bemerkenswert ist die ausdrückliche Warnung: kein Bind-Mount eines Host-Verzeichnisses auf /var/lib/postgresql/data, weil die PostgreSQL-Initialisierung im Container dort Berechtigungen setzen muss und das je nach Host-Dateisystem und Eigentümerschaft fehlschlägt. Das ist eine konkrete Betriebsfalle, die in vielen Anleitungen fehlt. Für die Entwicklung nennt das README pnpm i && pnpm run setup, danach pnpm dev, für den Produktionsbuild pnpm build. Der Hinweis auf WSL2 mit aktivierter Docker-Desktop-Integration deutet darauf hin, dass dieser Pfad häufiger Probleme macht.

Analyse und Guardrails: was das README zusagt und was offen bleibt

Als Funktionen nennt das README Nutzungsanalysen über Anfragen, Tokens, Antwortzeiten und Kosten sowie Leistungsvergleich zwischen Modellen. Die Themenliste des Repositories enthält zusätzlich rate-limiting und guardrails. Wie diese beiden umgesetzt sind, geht aus dem vorliegenden Material nicht hervor: keine Konfigurationsschlüssel, keine Beispiele, keine Grenzwerte. Das ist eine Lücke, die vor einem Produktiveinsatz zählt, denn Rate-Limits und Inhaltsfilter sind genau die Teile, bei denen die Semantik wichtig ist. Interessant ist an dieser Stelle die Lizenzaufteilung: erweiterte Datenaufbewahrung, also unbefristet statt 30 Tage, gehört laut README zu den Enterprise-Funktionen. Die 30 Tage beziehen sich auf den gehosteten Dienst; wie die Aufbewahrung im Selbstbetrieb aussieht, regelt der Gateway selbst, weil die Daten in der eigenen PostgreSQL-Instanz liegen. Wer aus Compliance-Gründen lange Historien braucht, findet im Selbstbetrieb also möglicherweise die günstigere Antwort als im Enterprise-Tarif.

Doppellizenz: AGPLv3 im Kern, kommerzielles ee/-Verzeichnis

Das Repository steht unter einer Doppellizenz. Der Kern ist AGPLv3, die kommerziellen Funktionen im Verzeichnis ee/ benötigen eine Enterprise-Lizenz, und die Multi-Organisations-Administration zusätzlich eine White-Label-Lizenz. Der Lizenzhinweis in den Metadaten lautet NOASSERTION, was zur gespaltenen Struktur passt. Für die Praxis heißt das: Wer den Gateway als Netzwerkdienst betreibt und angepassten Code einsetzt, muss die AGPLv3-Pflichten prüfen, insbesondere die Bereitstellung des Quellcodes für Nutzer des Dienstes. Das ist keine Rechtsberatung, sondern der Hinweis, dass diese Frage vor dem Forken und Anpassen geklärt werden sollte. Zusätzlich ist die Liste der Enterprise-Funktionen im README ausdrücklich offen formuliert: nach der Aufzählung steht der Satz, weitere Funktionen würden noch definiert. Wer heute auf ein bestimmtes Feature im ee/-Verzeichnis plant, plant gegen eine bewegliche Grenze. Das gilt auch für die Abgrenzung selbst: das interne Admin-Dashboard liegt bereits in ee/admin, nicht im offenen Teil.

Wo der Gateway die falsche Wahl ist

Der Gateway löst ein Mehrfach-Provider-Problem. Wer nur ein einziges Modell über einen einzigen Anbieter anspricht, baut mit ihm vor allem zusätzliche Infrastruktur auf: ein Gateway, eine API-Schicht, PostgreSQL und Redis, dazu sieben veröffentlichte Ports. Der Nutzen beschränkt sich dann auf Protokollierung, die sich auch mit den Bordmitteln des Anbieters abbilden lässt. Ein zweiter Fall ist die Latenz. Jede Anfrage nimmt einen zusätzlichen Netzwerksprung, und das README macht keine Angaben zu Overhead oder Durchsatz. Für Anwendungen mit engen Latenzbudgets ist das ein ungeklärter Punkt, der vorher gemessen werden muss. Drittens die Betriebsverantwortung: das Warnbeispiel zum Bind-Mount zeigt, dass die Inbetriebnahme nicht trivial ist. Wer keine Person hat, die PostgreSQL-Migrationen aus packages/db und die Container-Volumes betreut, sollte den gehosteten Weg wählen. Und wer anbieterspezifische Funktionen nutzt, die das OpenAI-Schema nicht abbildet, verliert sie möglicherweise an der Gateway-Grenze.

Alternative: direkte Provider-SDKs oder ein schlanker Proxy

Die naheliegende Alternative ist, die SDKs der Anbieter direkt zu verwenden und die Schlüssel über die eigene Konfiguration zu verteilen. Der Unterschied liegt nicht im Funktionsumfang, sondern im Ort der Zuständigkeit: Beim direkten Weg bleibt die Anbieterauswahl im Anwendungscode, jede Anpassung ist ein Deployment, und Nutzungsdaten liegen bei den Anbietern, verteilt über mehrere Abrechnungen. Der Gateway verschiebt genau das nach außen, in einen Dienst mit einer Datenbank und einer einheitlichen Schnittstelle. Dafür bekommt man eine zusätzliche Ausfallkomponente: fällt der Gateway aus, fällt jede Provider-Anfrage aus, auch die, deren Anbieter gerade erreichbar wäre. Ein zweiter Vergleichspunkt ist der Umfang. LLM Gateway bringt neben dem Routing ein Dashboard, ein Playground-Chat, ein Anbieterportal und ein Admin-Werkzeug mit. Wer nur Routing und Kostenprotokollierung will, betreibt mehr Code als nötig. Ein selbst geschriebener Reverse Proxy mit Logging wäre kleiner, aber er hätte keine Modell- und Providerdefinitionen in packages/models und keine Migrationspfade. Die Wahl ist damit eine zwischen Betriebsaufwand und Eigenbau, nicht zwischen zwei gleich großen Produkten.

Redaktionelles Fazit

Sinnvoll ist LLM Gateway für Teams, die mehrere Provider-Zugänge zentral verwalten und Nutzungsdaten selbst speichern wollen, ohne eine kommerzielle Plattform zu nutzen. Wer nur einen einzigen Provider anspricht oder keine Betriebsverantwortung für PostgreSQL und Redis übernehmen will, sollte beim Hosted-Angebot bleiben oder direkt gegen die Provider-API gehen. Vor dem Selbstbetrieb zu klären: ob die gewünschten Funktionen im AGPLv3-Kern oder im ee/-Verzeichnis liegen, welche Ports (3002, 3003, 3005, 3006, 3007, 4001, 4002) in der eigenen Netzwerkumgebung gebraucht werden und ob die Datenhaltung in PostgreSQL den eigenen Aufbewahrungsanforderungen entspricht.

Offizielle Quellen

1. Issues
2. Project website
3. README
4. Releases
5. theopenco/llmgateway on GitHub