LLM-Gateway für ein Unternehmen: eine API, Schlüssel je Team, Token-Budgets und ein Query-Log

Was ein LLM-Gateway in einer Unternehmensplattform tut

Ein LLM-Gateway, auch KI-Gateway genannt, ist ein Proxy, über den jede Anwendung die Sprachmodelle erreicht. Es bietet einen OpenAI-kompatiblen Endpunkt, prüft den Schlüssel des Aufrufers und leitet jede Anfrage an ein privates Modell weiter oder, nur wo das Unternehmen es freigegeben hat, an eine externe API. Es setzt Rate Limits und Token-Budgets je Anwendung und Team durch und schreibt jede Anfrage in ein Query-Log, das nach einer Aufbewahrungsrichtlinie geführt wird. Auf einer Plattform mit 500 bis 2.000 Nutzern und mehreren Anwendungen ist es außerdem die eine Komponente, die weiß, welches Team wie viele Token verbraucht hat.

Dokumentation von LiteLLM, Agent Router, Envoy Gateway und Kong, abgerufen am 10. Oktober 2026.

Warum der Modellserver ein Gateway vor sich braucht

vLLM prüft statische API-Schlüssel, hat aber keine Benutzerkonten, und seine Dokumentation vermerkt, dass der Parameter user der Chat Completions API ignoriert wird. Mehrere Anwendungen, die sich einen vLLM-Schlüssel teilen, sehen in seinen Logs identisch aus, und wird der Schlüssel widerrufen, stoppt das alle zugleich. Das Gateway gibt eigene Schlüssel aus, weiß, zu welcher Anwendung und welchem Team jeder gehört, und reicht die Anfrage mit einem Schlüssel weiter, den nur das Gateway besitzt. Das funktioniert nur, wenn das Gateway der einzige Zugang ist. Auf Kubernetes lassen Network Policies nur das Gateway, den Endpoint Picker und Prometheus an den Serving-Port, wie unser Leitfaden zu einer privaten LLM-Plattform auf Kubernetes darlegt.

Ein Rechenbeispiel zeigt die Größenordnung; die Zahlen sind eine Illustration, keine Sizing-Regel. Ein Unternehmen mit 1.500 Mitarbeitern betreibt ein Chat-Frontend für alle Beschäftigten, einen RAG-Assistenten für Rechtsabteilung und Vertrieb, einen Coding-Assistenten für 60 Entwickler, Workflows in n8n und einen nächtlichen Batch, der Felder aus eingehenden Dokumenten extrahiert. Mit einem Schlüssel je Anwendung in Test und Produktion hält das Gateway zehn Dienstschlüssel, dazu persönliche Schlüssel für Entwickler, deren IDE-Plugins die API direkt aufrufen. Das Chat-Frontend, dessen Anmeldung unser Leitfaden zur privaten ChatGPT-Alternative behandelt, muss mit jeder Anfrage die Identität des angemeldeten Nutzers mitgeben, sonst hält das Log nur die Anwendung fest.

LLM-Gateway-Optionen: LiteLLM, Agent Router (Envoy AI Gateway) und Kong

LICENSE-Dateien von LiteLLM, Kong Gateway und Inference Extension, Dokumentation von LiteLLM und Agent Router, der Beitrag der Agentic AI Foundation vom 9. September 2026, Plugin-Seiten von Kong und die Website der Gateway API Inference Extension, abgerufen am 10. Oktober 2026.

Der Proxy von LiteLLM hält Schlüssel, Teams und Ausgaben in einer Postgres-Datenbank, die seine Dokumentation für Virtual Keys voraussetzt. Seine Lizenzdatei sagt, dass Inhalte außerhalb des Enterprise-Verzeichnisses „unter der MIT-Lizenz verfügbar“ sind, während dieses Verzeichnis eine eigene Lizenzdatei hat. Die Dokumentation kennzeichnet mehrere Funktionen als solche, die „eine LiteLLM-Enterprise-Lizenz“ erfordern, darunter die JWT-basierte Anmeldung, die Schlüsselrotation, Budgets je Modell auf einem Schlüssel und das Logging an manche Ziele, etwa Cloud-Storage-Buckets und eigene Callback-APIs. Single Sign-on für seine Admin-Oberfläche funktioniert ab v1.76.0 ohne diese Lizenz für bis zu 5 Nutzer.

Die Agentic AI Foundation kündigte am 9. September 2026 an: „Envoy AI Gateway ist jetzt Agent Router“, und fügte hinzu: „Die Lizenz bleibt Apache 2.0“. Agent Router läuft auf Envoy Gateway, dessen SecurityPolicy jede Anfrage gegen ein entferntes JWKS auf ein gültiges JWT prüft. Kongs Plugin AI Proxy „nimmt Anfragen in einem von einigen definierten und standardisierten OpenAI-Formaten an“ und übersetzt sie für Anbieter, zu denen vLLM und Ollama gehören. Kongs tokenbasiertes Rate Limiting und sein PII-Sanitizer sind jeweils „nur als Teil unseres Angebots AI Gateway Enterprise verfügbar“.

Die Gateway API Inference Extension bezeichnet sich als „ein offizielles Kubernetes-Projekt, das das Selbst-Hosting generativer Modelle auf Kubernetes optimiert“. Ihr Endpoint Picker teilt dem Gateway mit, welches Replikat eines Modells jede Anfrage bedienen soll. Schlüssel, Budgets und das Log kommen von dem Gateway, das sie implementiert; die beiden Schichten lassen sich also kombinieren: ein Zugangs-Gateway für Schlüssel und Budgets und dahinter das Routing auf Replikate.

API-Schlüssel je Team und Anmeldung über den Identity Provider

LiteLLM erzeugt Virtual Keys über seinen Endpunkt /key/generate. Jeder Schlüssel trägt eine team_id oder user_id, eine Liste erlaubter Modelle und eigene Limits, und die Ausgaben werden für das zugeordnete Team oder den zugeordneten Nutzer erfasst. Die Modellliste legt fest, welches Team welches Modell nutzt, etwa das Coding-Modell nur auf Entwicklerschlüsseln. Dienstschlüssel gehören in den Secret Store der jeweiligen Anwendung, mit einem Rotationsdatum; persönliche Schlüssel enden mit dem Zugang der Person zur Plattform.

Mit JWT Auth validiert LiteLLM Tokens des Identity Providers gegen dessen öffentliche Schlüssel und liest Team, Nutzer und Rolle aus Claims, die in seiner Konfiguration benannt sind; der Zugang endet also, sobald das Konto im Verzeichnisdienst deaktiviert und sein letztes Token abgelaufen ist. Agent Router kann für dieselbe Prüfung die SecurityPolicy von Envoy Gateway nutzen, und sein Beispiel für Rate Limits identifiziert den Nutzer über einen Request-Header, den das Gateway aus dem validierten Token setzen sollte, statt ihn vom Client zu übernehmen.

Rate Limits und Token-Budgets je Nutzer, Team und Abteilung

Rate Limits schützen interaktive Nutzer vor Massenjobs. LiteLLM setzt tpm_limit und rpm_limit, Token und Anfragen pro Minute, auf Schlüssel und Teams, und Limits auf einem Team gelten über alle seine Schlüssel hinweg. Im Rechenbeispiel erhält der Schlüssel der nächtlichen Extraktion ein Token-Limit, das dem Chat-Modell Raum für seine Spitze lässt, falls der Job bis in die Arbeitszeit läuft.

Budgets werden in LiteLLM als Ausgaben gezählt. Ein Schlüssel oder Team hat ein max_budget und eine budget_duration wie 30d, und die Dokumentation sagt, das Budget „wird am Ende des festgelegten Zeitraums zurückgesetzt“. Überschreitet ein Schlüssel sein Budget, schlagen Anfragen fehl, und max_budget_in_team begrenzt ein Mitglied innerhalb eines Teams. Die Ausgaben ergeben sich aus Kosten je Token; ein privates Modell braucht deshalb einen internen Verrechnungssatz in input_cost_per_token und output_cost_per_token, den LiteLLM nur zur Kostenerfassung nutzt. Sind beide Kosten ausdrücklich auf 0 gesetzt, überspringt LiteLLM für dieses Modell alle Budgetprüfungen; es bleibt dann verfügbar, nachdem ein Team sein Budget aufgebraucht hat, aber seine Anfragen erhöhen die Ausgaben nicht, und seine Nutzung je Abteilung muss in Token gezählt werden. Entscheiden Sie je Modell, welches Verhalten Sie wollen. Die Summen je Abteilung fließen dann in das Showback oder Chargeback, das unser Leitfaden zu einer gemeinsamen GPU-Plattform für Abteilungen beschreibt.

Agent Router zählt Token je Route in llmRequestCosts, mit den Typen InputToken, CachedInputToken, OutputToken, TotalToken und einem CEL-Ausdruck, und setzt Limits über eine BackendTrafficPolicy auf dem globalen Rate Limit von Envoy Gateway durch, gestützt auf Redis. Seine Dokumentation hält fest, dass die Nutzung nach Abschluss einer Antwort verbucht und ein zugelassener Stream nicht unterbrochen wird; die letzte Antwort kann ein Limit also überschreiten. Kongs AI Rate Limiting Advanced zählt Token insgesamt, Prompt- oder Completion-Token oder Kosten.

Routing zu privaten Modellen, Fallbacks und externe APIs

LiteLLM probiert die Fallbacks in der aufgeführten Reihenfolge durch, wenn ein Modell ausfällt, mit eigenen Listen für Anfragen, die das Kontextfenster eines Modells überschreiten, und für Fehler durch Content Policies. Retries und Timeouts werden je Modell gesetzt, und ein Deployment, das pro Minute öfter scheitert als allowed_fails, wird für seine cooldown_time aus der Rotation genommen. Eine Fallback-Liste, die ein externes Modell nennt, schickt Prompts aus dem Unternehmen hinaus, sobald das private Modell nicht verfügbar ist, ohne dass jemand das für diese Daten entschieden hat. Halten Sie Fallbacks unter privaten Modellen, etwa einem zweiten Replikat oder einem Modell mit längerem Kontext. Fügen Sie eine externe API als eigenen Modellnamen hinzu, den nur die Schlüssel freigegebener Aufgaben aufrufen dürfen, sodass jede Anfrage dorthin einen Schlüssel, ein Team und einen Log-Eintrag trägt.

In unserer Leistung Private AI/ML werden öffentliche APIs nur genutzt, wenn Sie den Hybridmodus für eine konkrete Aufgabe freigeben, und was dorthin geht, ist im Query-Log sichtbar. Nennen Sie uns die Anwendungen, die das Gateway aufrufen würden, und die Aufgaben, die ein externes Modell brauchen könnten.

Query-Log, PII-Maskierung und Aufbewahrung

LiteLLM schreibt für jede Anfrage eine Zeile in sein Spend Log in der Datenbank, und disable_spend_logs schaltet das ab. Ob eine Zeile auch den Inhalt von Anfrage und Antwort enthält, legt store_prompts_in_spend_logs oder der entsprechende Schalter in der Admin-Oberfläche fest, und die Dokumentation sagt, dass in der Oberfläche geänderte Einstellungen die Konfigurationsdatei überschreiben; prüfen Sie deshalb vor dem Go-live beides. Die Aufbewahrung wird mit maximum_spend_logs_retention_period gesetzt, und die Dokumentation sagt: „Aufbewahrung und Bereinigung sind Open Source.“ Die Einstellung turn_off_message_logging hält Nachrichten und Antworten von seinen Logging-Callbacks fern, während „Metadaten der Anfrage weiterhin protokolliert werden“. Ein Client kann das Logging je Anfrage mit no-log=True umgehen, sofern der Administrator nicht global_disable_no_log_param setzt, was ein verpflichtendes Query-Log erfordert.

LiteLLM maskiert personenbezogene Daten über Presidio, dessen Analyse- und Anonymisierungsdienste neben dem Gateway laufen müssen. Im Modus pre_call prüft es die Eingabe vor dem Modellaufruf, im Modus post_call prüft es Eingabe und Ausgabe danach. Je Entitätstyp ersetzt MASK einen Wert durch einen Platzhalter wie <PERSON>, und BLOCK weist die Anfrage ab. Kongs AI Sanitizer nutzt einen Anonymisierungsdienst, der als Container laufen kann. Maskierung ist vor allem auf Routen zu externen APIs wichtig; auf einer privaten Route kann sie Namen entfernen, die eine Vertragsprüfung braucht. Eingeschleuste Anweisungen erkennt sie nicht; diese behandelt unser Leitfaden zu Prompt Injection und LLM-Sicherheit.

Artikel 5 Absatz 1 Buchstabe e DSGVO verlangt, dass personenbezogene Daten „in einer Form gespeichert werden, die die Identifizierung der betroffenen Personen nur so lange ermöglicht, wie es für die Zwecke, für die sie verarbeitet werden, erforderlich ist“, und das Log kann Prompts mit Namen und Kundendaten enthalten. Was das Log speichert, wer es lesen darf und wie lange, ist eine rechtliche Bewertung für Ihre Rechtsabteilung.

Richtlinienentscheidungen vor dem Go-live des Gateways

Eine Beispielrichtlinie; die Entscheidungen treffen Sie. Einstellungen wie in der Dokumentation von LiteLLM benannt, abgerufen am 10. Oktober 2026.

Derselbe Bericht, der die Token je Abteilung zeigt, zeigt auch, ob die Beschäftigten die freigegebene Plattform nutzen oder weiter öffentliche Werkzeuge verwenden; damit befasst sich unser Leitfaden zu Richtlinien und Kontrollen gegen Schatten-KI. Nehmen Sie das Gateway in dieser Reihenfolge in Betrieb.

1. Stellen Sie das Gateway vor jeden Modellserver und schließen Sie alle anderen Wege dorthin.
2. Legen Sie Teams und Schlüssel je Anwendung und Umgebung an, mit erlaubten Modellen und Limits.
3. Binden Sie die Token-Validierung an den Identity Provider an und entfernen Sie gemeinsam genutzte persönliche Schlüssel.
4. Legen Sie Log-Inhalte, Leser und Aufbewahrungsfrist fest und deaktivieren Sie das Opt-out vom Logging.
5. Fügen Sie externe APIs nur als eigene Modellnamen auf den Schlüsseln freigegebener Aufgaben hinzu.

Die Protokollierung von Anfragen und Antworten, mit Daten- und Berechtigungsverwaltung, ist Teil der Plattform, die wir bauen. Beschreiben Sie Ihre Abteilungen, Anwendungen und das Log, das Ihre Rechtsabteilung erwartet, im Formular unten.

Was wir tun

Unsere Leistung Private AI/ML baut eine KI-Plattform unter Ihrer Kontrolle, auf Ihren Servern oder in einem Tier-3-Rechenzentrum in Litauen, bei der nichts an öffentliche Dienste geht, solange Sie es nicht ausdrücklich freigeben. Ein Query-Log, Daten- und Berechtigungsverwaltung und die Protokollierung von Anfragen und Antworten lassen Security und Legal sehen, wer worauf zugreift und wie. Eurokommerz hält den Vertrag und liefert die Hardware, mit Engineering von unserem Engineering-Partner Vixen.UNO und Support unter einem vereinbarten SLA. Das erste Gespräch ist kostenlos, und der Preis des technischen Assessments steht vor Beginn der Arbeiten fest. Den Umgang mit Daten während eines Projekts beschreibt unsere Seite Sicherheit und Compliance.

FAQ