NCA Social Media
Aktualisiert:
Autor:
Roland Golla
Grünes Gateway Tor mit Schriftzug LLM GATEWAY, ein Kabel rein, vier raus

Was ist ein LLM Gateway?

Ein LLM Gateway ist ein Proxy zwischen euren Anwendungen und den Sprachmodellen. Jeder Aufruf läuft über einen Endpunkt in OpenAI kompatiblem Format, egal ob dahinter ein lokales Modell, eine offene Cloud oder eine kommerzielle API steht.
Das Gateway übernimmt dabei die Aufgaben, die sonst jedes Team einzeln nachbaut. Es verteilt eigene Schlüssel statt geteilter Anbieterschlüssel, zählt Token pro Nutzer und Projekt, zieht Budgets, schaltet bei Ausfällen auf ein Ersatzmodell um und schreibt jeden Aufruf in ein Log.
2026 ist aus dem Nischenthema eine eigene Werkzeugklasse geworden. Vier Projekte prägen den Markt: LiteLLM, Portkey, Bifrost und das Envoy AI Gateway. Daneben stehen reine Router, die nicht den Zugang regeln, sondern nur entscheiden, welches Modell eine Anfrage bekommt.

Inhalt

LLM Gateways mit NCA: Schnelle Hilfe vom Experten

Never Code Alone arbeitet aus Duisburg heraus an Softwarequalität und KI gestützter Entwicklung. Ein Gateway betreiben wir selbst, um in Projekten den Überblick über Token und Kosten zu behalten, harte Budgets zu ziehen und MCP Server an die Nutzer zu verteilen. Der Betrieb läuft über eigene Server in Deutschland.
Wir kennen beide Enden der Kette. Auf der einen Seite lokale Modelle über Ollama und offene Modelle wie Qwen, auf der anderen Seite die Frage, welches Gateway zu einem Team passt und wo der Betriebsaufwand größer wird als der Nutzen. Genau diese Einordnung ist die eigentliche Arbeit, nicht die Installation.
Passend dazu beraten wir im Vibe Coding Consulting, richten AI Coding Guidelines für PHP Projekte ein, bauen CI CD Pipelines für KI Code und begleiten den Weg zu Self Hosted KI im Unternehmen mit Mandantentrennung. Für Teams mit hohen Datenschutzanforderungen kommt unser Duisburger Netzwerkpartner Conversis mit gehosteter Inferenz dazu.

Ein Endpunkt für alle Modelle, Kosten im Blick

Finde das passende Angebot für dein Projekt

Anfrage-Konfiguration

Starten Sie Ihre Anfrage

Projektart
Infos
Nachricht

Eliminierung technischer Schulden mit PHPStan, Rector PHP und PHPUnit. Über 20 Jahre Praxiserfahrung in skalierbaren Backends.

CORE EXPERTISE

Gesetzliche Konformität & Inklusion. Optimierung von Performance und Conversion durch radikal nutzerzentriertes, universelles Design.

BFSG COMPLIANT

Skalierbare KI-Systeme mit echtem Code Ownership. CI/CD, Backup-Strategien und Infrastruktur, die mit deinem Team wächst.

ENTERPRISE READY

Warum Teams überhaupt ein Gateway brauchen

Der Schmerz beginnt selten am ersten Tag. Eine Person testet ein Modell, legt einen Schlüssel an, alles läuft. Ein halbes Jahr später hängen drei Anwendungen, zwei Agenten und ein Coding Assistent an vier verschiedenen Anbietern. Vier Schlüssel, vier SDKs, vier Rechnungen.
Dann kommen die typischen Fragen. Welches Projekt hat den Verbrauch letzte Woche verdoppelt? Wer darf welches Modell nutzen? Was passiert, wenn ein Anbieter ausfällt? Und wie tauschen wir ein Modell aus, ohne in zehn Repositories den Code anzufassen?
Ein Gateway beantwortet all das an einer Stelle. Die Anwendung spricht weiter mit einem einzigen Endpunkt, der Rest ist Konfiguration. Genau deshalb sitzt es bei uns vor lokalen Modellen wie Ollama genauso wie vor externer Inferenz.

Was ein LLM Gateway konkret leistet

Die Funktionen sind bei allen Projekten ähnlich, die Tiefe unterscheidet sich stark:
  • Einheitliche API: ein OpenAI kompatibler Endpunkt vor allen Anbietern, Übersetzung der Formate übernimmt das Gateway
  • Virtuelle Schlüssel: jedes Team, jedes Projekt, jeder Agent bekommt einen eigenen Schlüssel
  • Kosten und Budgets: Verbrauch pro Schlüssel zählen, Limits setzen, am Limit hart abschalten
  • Fallback und Load Balancing: fällt ein Anbieter aus, geht die Anfrage automatisch an das Ersatzmodell
  • Caching: identische oder semantisch ähnliche Anfragen werden nicht doppelt bezahlt
  • Observability: jeder Aufruf landet im Log, oft mit Anbindung an Langfuse oder OpenTelemetry
  • MCP Gateway: nicht nur Modelle, auch MCP Server und Werkzeuge werden zentral verteilt und über RBAC abgesichert
Der MCP Teil ist die eigentliche Neuerung von 2026. Agenten rufen nicht nur Modelle auf, sie greifen auf Werkzeuge zu. Wer den Modellzugang regelt, den Werkzeugzugang aber offen lässt, hat nur die Hälfte kontrolliert.

Die Open Source Gateways im Vergleich

Projekt Technik und Stärke Betrieb
LiteLLM Python, OpenAI kompatibel, sehr breite Anbieterliste, Budgets und MCP Verteilung Self Hosted auf jedem Server, kleinstes Setup
Portkey Gateway Seit März 2026 vollständig Apache 2.0, Governance und Guardrails im Kern Self Hosted oder gehostet, seit Mai 2026 bei Palo Alto Networks
Bifrost In Go geschrieben, auf Durchsatz optimiert, Fallbacks und semantisches Caching Self Hosted, Cluster und MCP Gateway im Enterprise Teil
Envoy AI Gateway v1.0 im Juni 2026, CNCF Basis, 16 Anbieter, MCP Gateway, stabile API Kubernetes nativ, Aufsatz auf Envoy Gateway
Reine Router RouteLLM und vLLM Semantic Router entscheiden pro Anfrage über das Modell Ergänzung vor oder hinter einem Gateway, kein Zugangsschutz

LiteLLM: der pragmatische Einstieg

LiteLLM ist das Gateway, das die meisten Teams zuerst anfassen. Python, in Minuten gestartet, eine sehr lange Liste unterstützter Anbieter. Verbrauch und Kosten werden pro Schlüssel, Nutzer, Team und Organisation erfasst.
Der Reiz liegt in der niedrigen Einstiegshürde. Ein Container, eine Konfigurationsdatei, fertig. Dazu verteilt LiteLLM seit den jüngeren Versionen auch MCP Server über denselben Endpunkt, mit Zugriffskontrolle je Schlüssel.
Der Preis dafür ist der Betrieb. Wer LiteLLM in die kritische Anfragekette stellt, betreibt eine Python Anwendung mit Datenbank und muss Updates ernst nehmen. Für kleine und mittlere Teams ist das trotzdem meist die richtige Wahl.

Portkey: offen seit März 2026, seitdem viel passiert

Portkey war lange das Gegenmodell zu LiteLLM. Ein schlanker Open Source Kern, die interessanten Funktionen im bezahlten SaaS. Im März 2026 hat das Unternehmen den kompletten Gateway unter Apache 2.0 gestellt. Governance, Observability, Authentifizierung und Kostenkontrolle wanderten in eine gemeinsame Codebasis, dazu kam ein eigenes MCP Gateway.
Wenige Wochen später folgte der zweite Teil der Geschichte. Palo Alto Networks kündigte Ende April 2026 die Übernahme an und schloss sie Ende Mai ab. Portkey ist seitdem der AI Gateway innerhalb der Sicherheitsplattform Prisma AIRS.
Für die Einordnung heißt das zweierlei. Technisch ist Portkey stark bei Guardrails, PII Filtern und Freigabelogik. Strategisch hängt die Weiterentwicklung jetzt an einem großen US Konzern. Wer ein Open Source Gateway wählt, um genau solche Abhängigkeiten zu vermeiden, sollte das mitdenken.

Bifrost: wenn der Durchsatz zählt

Bifrost kommt von Maxim AI, ist in Go geschrieben und steht unter Apache 2.0. Der Fokus liegt klar auf Geschwindigkeit. Das Projekt wirbt mit sehr geringem Overhead pro Anfrage bei mehreren tausend Anfragen pro Sekunde und liefert Benchmarks gegen LiteLLM und Portkey gleich mit.
Funktional ist die Liste vollständig: einheitliche API über mehr als zwanzig Anbieter, automatische Fallbacks, Load Balancing, semantisches Caching, ein Web UI zur Konfiguration. Cluster Betrieb, Guardrails und das MCP Gateway gehören zum Enterprise Teil.
Interessant wird Bifrost dort, wo ein Gateway wirklich in der heißen Anfragekette steht und Latenz zählt. Für ein Entwicklerteam mit ein paar hundert Anfragen am Tag ist das kein Argument. Wir ordnen Bifrost ein, setzen es aber nicht als Standard bei uns ein.

Envoy AI Gateway: der Standard für Kubernetes

Das Envoy AI Gateway ist der Neuzugang mit dem stärksten Fundament. Es setzt als zusätzliche Schicht auf dem CNCF Projekt Envoy Gateway auf, also auf dem Proxy, der ohnehin in vielen Clustern läuft. Am 23. Juni 2026 erschien Version 1.0 als erste stabile Ausgabe.
Mit v1.0 kamen eine einheitliche API über 16 Anbieter mit Übersetzung zwischen den Formaten, ein vollwertiges MCP Gateway, multimodale und Audio Endpunkte, Observability und mandantenfähiges Routing mit Kontingenten. Getrieben wird das Projekt von Maintainern bei Tetrate, Bloomberg und Nutanix.
Version 1.1 folgte im August 2026 und brachte unter anderem Token Zählung über Anbieter hinweg, Zugangsdaten pro Anfrage und optionales OpenTelemetry Tracing.
Die Einordnung ist einfach. Wer bereits Kubernetes und Envoy betreibt, bekommt hier den saubersten Weg: keine zusätzliche Fremdkomponente, sondern eine Erweiterung des vorhandenen Proxys. Wer kein Cluster hat, zahlt für genau dieses Fundament einen hohen Einstiegspreis.

Router sind kein Gateway

RouteLLM und der vLLM Semantic Router lösen eine andere Aufgabe. Sie regeln nicht den Zugang, sie entscheiden pro Anfrage, welches Modell antwortet. Eine einfache Frage geht an ein kleines lokales Modell, eine komplexe Analyse an das große.
Der Semantic Router stammt aus dem vLLM Umfeld und wird stark von Red Hat vorangetrieben. Er läuft als Envoy Erweiterung und passt damit in genau dieselbe Kubernetes Welt wie das Envoy AI Gateway. Version 0.3 erschien im Juni 2026.
Wirtschaftlich ist das der spannendste Hebel. Nicht jede Anfrage braucht ein Frontier Modell, und jede Anfrage, die ein lokales Modell beantwortet, kostet nichts extra. Wie weit das trägt, haben wir unter lokale KI wirtschaftlich beschrieben. Ein verwandter Ansatz aus dem NVIDIA Umfeld ist NeMo Switchyard.

Coding aus der Cloud, Datenverarbeitung im eigenen Netzwerk

Ein Gateway ist der Ort, an dem sich diese Trennung technisch durchsetzen lässt. Große Coding Modelle laufen nicht auf Kundenhardware, das ist wirtschaftlich unrealistisch. Die Datenverarbeitung bleibt trotzdem im eigenen Netz.
In der Praxis heißt das: Modelle, die nicht auf eigener Infrastruktur laufen, arbeiten gegen lokale Entwicklungsumgebungen mit Fake Daten. Alles, was echte Daten berührt, geht an lokale Modelle über Ollama, llama.cpp oder vLLM. Das Gateway erzwingt diese Regel über Schlüssel und Routen, statt sie in Dokumentation zu schreiben.
Für europäische Inferenz nutzen wir TensorX mit OpenAI kompatibler API und Zero Data Retention. Für Enterprise Setups mit gehosteter Inferenz kommt unser Duisburger Netzwerkpartner Conversis dazu. Die rechtliche Seite haben wir unter lokale KI für Compliance ausgeführt.

Welches Gateway passt zu welchem Team

Die Entscheidung hängt weniger am Funktionsumfang als am vorhandenen Betrieb:
  • Kein Kubernetes, kleines Team, schneller Nutzen: LiteLLM. Ein Container, Budgets, MCP Verteilung, fertig.
  • Kubernetes und Envoy laufen bereits: Envoy AI Gateway. Der Proxy steht ohnehin, das Gateway ist eine Erweiterung.
  • Guardrails und Freigabelogik im Vordergrund: Portkey, mit dem Wissen über den neuen Eigentümer.
  • Latenz und Durchsatz sind das Problem: Bifrost, dafür ist es gebaut.
  • Kosten pro Anfrage sind das Problem: erst einen Router davorsetzen, nicht das Gateway wechseln.
Ein Fehler taucht dabei immer wieder auf. Teams wählen das Gateway mit der längsten Funktionsliste und betreiben dann eine Komponente, die niemand versteht, in der kritischen Anfragekette. Ein Gateway, das ausfällt, legt jede KI Funktion im Unternehmen still. Die einfachste Lösung, die eure Anforderungen erfüllt, ist hier die richtige.

As autonomous agents join the enterprise workforce, they also become a new, unmanaged attack surface.

Lee Klarich, Chief Product and Technology Officer, Palo Alto Networks – Palo Alto Networks Pressemitteilung

LLM Gateways in der NCA Praxis

Wir bauen den Weg meistens in dieser Reihenfolge. Erst ein Gateway vor die vorhandenen Modelle stellen und messen, wer was verbraucht. Dann Schlüssel und Budgets pro Team ziehen. Erst danach über Router und Modellwechsel reden, weil vorher niemand weiß, wo das Geld wirklich hingeht.
Rundherum hängen die üblichen Bausteine: Langfuse für Observability, Open WebUI als Oberfläche für Kollegen ohne Terminal, LM Studio auf den Rechnern und Qwen als offenes Coding Modell.
Für den Einstieg rechnen wir realistisch mit 15 bis 30 Tagen bis zum ersten belastbaren Ergebnis. Danach kommen ein paar Tage im Monat dazu, damit Regeln, Gates und Agenten mit dem Projekt wachsen. Beides sind Aufwandsschätzungen, kein Festpreis. Wir starten mit einem kostenlosen Kennenlernen, schätzen den Aufwand und rechnen minutengenau ab.
CYPRESS.IO Ambassador und IT Consultant für QA Engenieering und Qualität in PHP Projekten.

NCA Vibe Coding Consulting

Roland Golla ist Entwickler aus Leidenschaft – seit über 20 Jahren. Er hat hunderte Projekte begleitet, von Legacy-Refactoring bis KI-Integration. Bei Vibe Coding verbindet er das Beste aus beiden Welten: Die Geschwindigkeit von KI-generiertem Code mit der Qualität professioneller Softwareentwicklung. Kein Bullshit, keine Agentur-Floskeln – direkte Hilfe von jemandem, der selbst täglich im Code steckt.

E-Mail Kontakt

Häufige Fragen zu LLM Gateways

Die Fragen, die in Projekten und Workshops immer wieder kommen, kurz beantwortet.

Was ist ein LLM Gateway 2026 genau?

Ein Proxy zwischen euren Anwendungen und den Sprachmodellen. Alle Aufrufe laufen über einen Endpunkt in OpenAI kompatiblem Format. Das Gateway vergibt eigene Schlüssel, zählt Token, zieht Budgets, schaltet bei Ausfällen auf Ersatzmodelle um und protokolliert jeden Aufruf. Seit 2026 verteilen die meisten Projekte zusätzlich MCP Server und Werkzeuge über denselben Weg.

Welches LLM Gateway passt 2026 für ein kleines Team?

In den meisten Fällen LiteLLM. Der Einstieg dauert Minuten, die Anbieterliste ist die längste am Markt und Budgets lassen sich pro Nutzer und Projekt ziehen. Ein zusätzliches Kubernetes Cluster braucht ihr dafür nicht. Erst wenn Latenz, Cluster Betrieb oder harte Guardrails zum Thema werden, lohnt der Blick auf die anderen Projekte.

Ist Portkey 2026 noch Open Source?

Ja. Im März 2026 hat Portkey den kompletten Gateway unter Apache 2.0 gestellt, inklusive Governance, Observability, Authentifizierung und Kostenkontrolle. Kurz darauf hat Palo Alto Networks das Unternehmen übernommen und den Abschluss Ende Mai 2026 bekannt gegeben. Der Code bleibt offen, die Richtung der Weiterentwicklung liegt aber bei einem großen US Konzern.

Was hat sich 2026 beim Envoy AI Gateway geändert?

Am 23. Juni 2026 kam Version 1.0 als erste stabile Ausgabe. Sie bringt eine einheitliche API über 16 Anbieter, ein MCP Gateway, multimodale und Audio Endpunkte sowie mandantenfähiges Routing mit Kontingenten. Version 1.1 folgte im August 2026 mit Token Zählung über Anbieter hinweg und optionalem OpenTelemetry Tracing.

Brauche ich 2026 ein Gateway, wenn nur ein Modell im Einsatz ist?

Meistens noch nicht. Solange eine Anwendung, ein Anbieter und ein Schlüssel im Spiel sind, überwiegt der Betriebsaufwand. Der Punkt kippt, sobald mehrere Personen denselben Schlüssel nutzen oder ein zweiter Anbieter dazukommt. Dann fehlt sonst die Zuordnung, welcher Verbrauch aus welchem Projekt stammt.

Was ist der Unterschied zwischen Gateway und Router?

Ein Gateway regelt den Zugang: Schlüssel, Budgets, Protokollierung, Formatübersetzung. Ein Router entscheidet nur, welches Modell eine konkrete Anfrage beantwortet, etwa ein kleines lokales Modell für einfache Fragen. RouteLLM und der vLLM Semantic Router sind solche Router. Beides schließt sich nicht aus, ein Router sitzt sinnvollerweise hinter oder vor dem Gateway.

Wie viel Latenz kostet ein Gateway?

Je nach Projekt zwischen wenigen Mikrosekunden und einigen Millisekunden. Bifrost und Portkey werben mit sehr geringem Overhead, LiteLLM liegt als Python Anwendung darüber. In der Praxis fällt das gegenüber der Antwortzeit des Modells kaum ins Gewicht. Relevant wird es erst bei sehr hohem Durchsatz oder bei Streaming Anwendungen mit knappen Zeitbudgets.

Kann ein Gateway auch MCP Server verteilen?

Ja, und das ist inzwischen ein Hauptargument. LiteLLM, Portkey, das Envoy AI Gateway und Bifrost im Enterprise Teil bringen alle ein MCP Gateway mit. Damit bekommen Agenten nicht nur Modelle, sondern auch Werkzeuge über einen kontrollierten Weg. Wer nur den Modellzugang absichert, lässt den Werkzeugzugang offen.

Ist ein LLM Gateway automatisch DSGVO konform?

Nein. Das Gateway ist ein Werkzeug, keine Rechtsposition. Es hilft aber sehr, weil sich Regeln technisch erzwingen lassen: welche Route welche Daten sehen darf, welcher Schlüssel auf welches Modell zeigt, was protokolliert wird. Modelle, die nicht auf eigener Infrastruktur laufen, arbeiten bei uns nur gegen Entwicklungsumgebungen mit Fake Daten.

Was passiert, wenn das Gateway ausfällt?

Dann steht jede KI Funktion, die darüber läuft. Genau deshalb gehört ein Gateway in die Überwachung wie jede andere kritische Komponente, mit Sentry und Grafana. Redundanz, saubere Timeouts und ein getesteter Weg zurück auf direkte Anbieterschlüssel gehören zum Setup. Ein Gateway ohne Notfallplan verschiebt das Risiko nur.

Lohnt sich semantisches Caching?

Das hängt am Anwendungsfall. Bei Chatbots und Suchoberflächen mit vielen ähnlichen Fragen spart es spürbar Geld. Bei Coding Agenten fast nie, weil jede Anfrage einen anderen Kontext trägt. Vorsicht ist auch bei sensiblen Daten geboten: ein Cache speichert Anfragen und Antworten, das gehört in die Datenschutzbetrachtung.

Kann ich mit einem Gateway Kosten wirklich deckeln?

Ja, wenn das Projekt harte Limits kennt. Bei LiteLLM lassen sich Budgets pro Schlüssel, Nutzer, Team und Organisation setzen, die am Limit tatsächlich abschalten. Wichtig ist die Ebene: ein Limit pro Organisation verhindert keine Ausreißer in einem einzelnen Projekt. Wir setzen Budgets deshalb immer auf mehreren Ebenen gleichzeitig.

Wie führt Never Code Alone ein Gateway ein?

Wir starten mit einem kostenlosen Kennenlernen und schauen uns an, welche Modelle, Schlüssel und Anwendungen bereits im Einsatz sind. Danach schätzen wir den Aufwand und rechnen minutengenau ab. Feste Pakete gibt es nicht. Für den Einstieg sind 15 bis 30 Tage bis zum ersten belastbaren Ergebnis realistisch, danach einige Tage im Monat.