Vier LLM-Gateways im Vergleich: was sie wirklich unterscheidet

TL;DR

Alle vier bündeln Modellzugriffe hinter einer Schnittstelle und können Budgets, Schlüssel und Protokollierung. Die Unterschiede liegen woanders: LiteLLM ist am nächsten an den Modellen, Kong am nächsten an Ihrem bestehenden API-Betrieb, Portkey am bequemsten und am wenigsten souverän, Azure APIM am billigsten, wenn es ohnehin schon läuft.

Wozu ein Gateway überhaupt

Der Einstiegspunkt ist fast immer derselbe: Es gibt drei Anwendungen, die alle direkt gegen einen Modellanbieter sprechen, jede mit eigenem Schlüssel. Am Monatsende kommt eine Rechnung, die niemand einer Abteilung zuordnen kann. Und als jemand fragt, ob man das Modell wechseln könne, stellt sich heraus, dass der Anbietername in drei Codebasen steht.

Ein Gateway löst genau vier Probleme, und es ist hilfreich, sich diese vier vor Augen zu halten, weil sie die Auswahl bestimmen:

1. Eine Schnittstelle für viele Modelle — Anwendungen sprechen ein Format, dahinter hängen beliebige Anbieter
2. Kostenzuordnung — welcher Bereich hat wie viel verbraucht
3. Zugangsverwaltung — wer darf welches Modell nutzen, mit welchem Kontingent
4. Protokollierung — was wurde angefragt, was kam zurück, wie lange dauerte es

Wer nur Punkt 1 braucht, kommt mit einer Bibliothek aus und braucht keinen zusätzlichen Dienst.

Die vier im Überblick

LiteLLM: am nächsten an den Modellen

LiteLLM ist ein Proxy, der eine OpenAI-kompatible Schnittstelle nach vorne stellt und dahinter praktisch jeden Anbieter anspricht — inklusive lokaler Modelle über Ollama oder vLLM. Das ist seine Stärke: Die Modellabdeckung ist die breiteste im Feld, und neue Modelle sind meist innerhalb von Tagen unterstützt.

# config.yaml — Cloud und lokal nebeneinander
model_list:
  - model_name: standard
    litellm_params:
      model: azure/gpt-4o
      api_base: https://ihre-instanz.openai.azure.com
      api_key: os.environ/AZURE_API_KEY
  - model_name: vertraulich          # verlässt das Haus nicht
    litellm_params:
      model: openai/qwen3-30b-a3b
      api_base: http://vllm.intern:8000/v1
      api_key: "nicht-benoetigt"

litellm_settings:
  # Kostenkontrolle: harte Obergrenze pro Schlüssel
  max_budget: 500
  budget_duration: 30d
  # Caching senkt die Rechnung bei wiederkehrenden Anfragen spürbar
  cache: true

Was in Projekten den Ausschlag gibt: die eingebaute Verbrauchsverfolgung. LiteLLM schreibt pro Anfrage die Kosten in eine PostgreSQL-Datenbank, aufgeschlüsselt nach Schlüssel, Team und Modell. Sie können daraus eine Abteilungsabrechnung erzeugen, ohne etwas zu bauen. Wie das konkret aussieht, steht in der Anleitung zur Kostenverrechnung pro Abteilung.

Die Grenze, die man kennen muss: SSO in der Verwaltungsoberfläche ist ab dem sechsten Nutzer kostenpflichtig, ebenso die SCIM-Synchronisierung. Bei einer Architektur, in der Endanwender über eine Chat-Oberfläche kommen und nur wenige Verantwortliche das Gateway direkt bedienen, spielt das keine Rolle. Details dazu in der Entra-ID-SSO-Anleitung.

Zweite Einschränkung, ehrlich benannt: LiteLLM entwickelt sich sehr schnell. Das ist gut für die Modellabdeckung und unangenehm für den Betrieb. Pinnen Sie Versionen und lesen Sie die Änderungshinweise, bevor Sie aktualisieren.

Kong AI Gateway: wenn schon ein API-Betrieb existiert

Kong ist zuerst ein API-Gateway und dann eines für Modelle. Die KI-Funktionen kommen als Plugins: ai-proxy für die Weiterleitung, ai-prompt-guard für Eingabeprüfung, ai-rate-limiting-advanced für Kontingente auf Token-Basis statt auf Anfragebasis.

Der Fall, in dem Kong die richtige Wahl ist, lässt sich in einem Satz beschreiben: Wenn Ihre API-Landschaft bereits über Kong läuft, ist das Modell-Gateway eine Konfiguration, kein neuer Dienst. Sie erben Authentifizierung, Ratenbegrenzung, Protokollierung und Überwachung aus dem, was ohnehin steht.

Der Fall, in dem es die falsche Wahl ist, ebenso kurz: Wenn Sie Kong wegen der KI-Funktionen einführen würden. Dann kaufen Sie eine erhebliche Komplexität für einen Teilaspekt.

Die Kostenverfolgung ist schwächer als bei LiteLLM. Kong protokolliert den Tokenverbrauch, aber die Zuordnung zu Kostenstellen bauen Sie sich selbst aus den Protokolldaten.

Portkey: bequem, mit einer Einschränkung

Portkey macht vieles richtig: eine ausgereifte Oberfläche für Verbrauchsanalyse, semantisches Caching, Wiederholungslogik und Ausweichrouten, dazu eine Prompt-Verwaltung mit Versionierung. Wer schnell Transparenz über Modellnutzung braucht und keine eigene Infrastruktur aufbauen will, ist damit in einem Nachmittag produktiv.

Die Einschränkung steht in der Zeile "wo liegen die Daten". Im verwalteten Betrieb laufen Ihre Anfragen über die Infrastruktur des Anbieters. Für ein deutsches Unternehmen, das eine KI-Plattform gerade deshalb baut, weil die Daten nicht zu einem beliebigen Dritten sollen, ist das ein Widerspruch. Es gibt eine selbst betriebene Variante im Enterprise-Plan — dann sind Sie allerdings bei einem kostenpflichtigen Produkt für etwas, das LiteLLM quelloffen liefert.

Unsere Empfehlung: Portkey ist gut für eine Bewertungsphase und für Häuser, die ohnehin ausschließlich mit US-Anbietern arbeiten. Als Kern einer souveränen Plattform passt es nicht.

Azure API Management: der unterschätzte Weg

Wenn Ihre Modelle ohnehin über Azure OpenAI laufen und APIM bereits im Einsatz ist, brauchen Sie möglicherweise gar kein weiteres Produkt. APIM hat seit einiger Zeit Richtlinien speziell für Modellzugriffe: Token-basierte Ratenbegrenzung, semantisches Caching, Lastverteilung über mehrere Instanzen.

<!-- Kontingent auf Token-Basis, nicht auf Anfragebasis -->
<azure-openai-token-limit
    counter-key="@(context.Subscription.Id)"
    tokens-per-minute="20000"
    estimate-prompt-tokens="true"
    remaining-tokens-header-name="x-tokens-remaining" />

<!-- Verbrauch als Metrik, aufgeschlüsselt nach Abonnement -->
<azure-openai-emit-token-metric namespace="ki-plattform">
    <dimension name="Subscription" value="@(context.Subscription.Name)" />
</azure-openai-emit-token-metric>

Der große Vorteil: Es steht bereits unter Ihrer Governance, mit Entra ID, Netzwerkregeln und Protokollierung in Ihrer Region. Der Nachteil: Es ist auf Azure-Backends zugeschnitten. Ein lokales vLLM lässt sich anbinden, aber die komfortablen Richtlinien greifen dann nicht mehr vollständig.

Die Entscheidung

Kurz und ohne Bewertungsmatrix:

• Sie betreiben oder planen lokale Modelle → LiteLLM. Kein anderes der vier behandelt eigene und fremde Modelle gleichwertig.
• Kong läuft bereits als API-Gateway → Kong-Plugins, kein zweiter Dienst.
• Alles läuft über Azure OpenAI, APIM steht → APIM-Richtlinien, kein neues Produkt.
• Sie brauchen morgen Transparenz und haben keine Souveränitätsanforderung → Portkey.

Der häufigste Fall im deutschen Mittelstand ist der erste, weil die Frage nach dem lokalen Modell fast immer irgendwann kommt. Wie ein Gateway den Modellwechsel entkoppelt, steht im Beitrag zum Modellwechsel ohne Neuentwicklung.

Häufig gestellte Fragen

Was ist ein LLM-Gateway und wann brauche ich eines?

Ein Dienst zwischen Ihren Anwendungen und den Modellanbietern, der eine einheitliche Schnittstelle bereitstellt und dabei Zugänge, Kontingente, Kosten und Protokolle verwaltet. Notwendig wird es ab der zweiten Anwendung, die Modelle nutzt — spätestens dann, wenn jemand fragt, welche Abteilung welchen Anteil der Rechnung verursacht hat.

Ist LiteLLM kostenlos nutzbar?

Der Proxy selbst ja, unter offener Lizenz, einschließlich Routing, Budgets, Verbrauchsverfolgung und Caching. Kostenpflichtig sind einzelne Unternehmensfunktionen, darunter SSO in der Verwaltungsoberfläche ab dem sechsten Nutzer und die SCIM-Synchronisierung von Gruppen. Für die meisten Installationen im Mittelstand reicht der freie Funktionsumfang.

Kann ein Gateway lokale und Cloud-Modelle gleichzeitig bedienen?

Ja, und das ist einer der stärksten Gründe, überhaupt eines einzusetzen. Sie definieren logische Modellnamen — etwa standard und vertraulich — und hinterlegen dahinter ein Cloud-Modell beziehungsweise ein lokal betriebenes. Die Anwendung entscheidet über den Namen, nicht über den Anbieter, und Sie können die Zuordnung ändern, ohne Code anzufassen.

Wie viel Latenz kostet ein Gateway?

Bei reinem Weiterleiten liegt der Aufschlag im einstelligen Millisekundenbereich und ist gegenüber der Modellantwortzeit vernachlässigbar. Spürbar wird es erst, wenn Sie Prüfungen davorschalten — Eingabefilter, Guardrails, semantische Cache-Abfragen. Diese Aufschläge sollten Sie einzeln messen, statt sie pauschal dem Gateway zuzuschreiben.

Was ist der Unterschied zwischen einem LLM-Gateway und einem API-Gateway?

Ein klassisches API-Gateway zählt Anfragen, ein LLM-Gateway zählt Token — und das ändert alles: Kontingente, Kostenzuordnung und Caching funktionieren anders, weil eine Anfrage mit 200 Token und eine mit 100.000 Token nicht vergleichbar sind. Produkte wie Kong und Azure API Management haben ihre klassischen Gateways deshalb um modellspezifische Funktionen ergänzt.

Der nächste Schritt

Prüfen Sie zuerst, was bereits läuft. Wenn ein API-Gateway oder Azure API Management im Einsatz ist, beginnen Sie dort — ein zweites Produkt für dieselbe Aufgabe ist schwer zu rechtfertigen. Steht nichts, nehmen Sie LiteLLM, weil es Sie bei der Modellwahl am wenigsten festlegt. Bei der Auslegung helfen wir gern.