Kubernetes AI Gateway: Plattform statt App-Keys 2026

Constantin Budin, Principal Data & AI bei Pexon Consulting | 9 Min. Lesezeit | 04.09.2026

TL;DR: Kubernetes AI Gateway kurz erklärt

Ein Kubernetes AI Gateway macht Modell-Traffic zur Plattform-Infrastruktur: Keys, Token-Budgets, Fallback und Prompt-Cache liegen im Cluster, nicht in jeder App. Pexon Consulting (80 Mitarbeiter, Microsoft Partner, Azure/AWS/GCP) setzt das als zentrale Routing-Schicht. Ergebnis: Azure-OpenAI-Limits fallen auf KServe, Apps sprechen einen Endpoint an und der Audit-Trail bleibt im eigenen Netz.

Das Problem: Modell-Traffic klebt an der App

Drei produktive Chatbots, ein Coding-Agent, eine RAG-Suche: genau die Lage, in der ein Kubernetes AI Gateway die Keys aus den Apps holt. Jedes Team hat seinen eigenen Azure-OpenAI-Key, irgendwo liegt noch ein DeepSeek-Key aus dem Hackathon, und niemand kann sagen, wer letzten Monat 18.000 EUR Token verbrannt hat.

Ein klassisches Ingress oder API-Gateway sieht davon fast nichts. Beide Requests sind POST /v1/chat/completions. Der eine fasst einen Satz zusammen. Der andere schickt einen 200-Seiten-Vertrag an claude-sonnet-4-6 mit 12.000 max_tokens. Token, GPU-Speicher, Streaming-Dauer und Kosten haben nichts miteinander zu tun. Ein Request-per-Second-Limit lügt hier.

Wir raten deshalb davon ab, „noch ein Proxy-Pod“ neben die Apps zu stellen und das Thema für erledigt zu erklären. Was 2026 fehlt, ist eine Plattform-Entscheidung: Modell-Traffic gehört ins Cluster wie DNS, Ingress und Secrets. Nicht in das nächste Sprint-Backlog der Fachanwendung.

Die Kubernetes-Community hat das formalisiert. Laut der Kubernetes-Contributor-Ankündigung vom 09.03.2026 gibt es die AI Gateway Working Group; die Gruppe selbst existiert seit September 2025. Sie schreibt keine neue Gateway-Software. Sie schlägt vor, wie Gateway API Payload-Verarbeitung, Egress zu Fremd-LLMs und modellbewusstes Routing abbilden soll. Wer heute noch Keys in Apps verteilt, baut gegen diese Richtung.

Was ein Kubernetes AI Gateway auf dem Cluster wirklich ist

Die kurze Antwort: eine Policy- und Routing-Schicht zwischen Anwendungen und Modell-Endpunkten, deklarativ wie ein HTTPRoute.

Endpunkte dürfen intern sein (KServe, vLLM) oder extern (Azure OpenAI, Bedrock, direkte OpenAI-API). Die Apps kennen nur einen Cluster-Service. Auth, Token-Budget, Modellwahl, Cache und Telemetrie hängen an der Route, nicht am Framework der jeweiligen App.

Das ersetzt nicht die Gateway API. Es hängt AI-spezifische Policies daran. Die Inference Extension (seit Juni 2025, InferencePool) kümmert sich um GPU-Pools und Prefix-Cache-Nähe. Ein AI Gateway kümmert sich zusätzlich um Provider-Keys, Quoten und Egress. Viele produktive Plattformen brauchen beides in einem Datenpfad. Wer nur „Inference Gateway“ sagt und Azure-Fallbacks ignoriert, löst die halbe Aufgabe.

Pexon Consulting sieht das Muster vor allem dort, wo schon ein AI-Engineering-Stack existiert: mehrere Modelle, mehrere Teams, eine Compliance-Frage. Eine einzelne interne App mit einem Modell braucht das nicht. Dort reicht ein SDK-Wrapper.

# Illustrativ: Token-Budget an einer Gateway-API-Route.
# Felder je nach Implementierung (Envoy AI Gateway Policy vs. LiteLLM).
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: checkout-ai
  namespace: platform-ai
spec:
  parentRefs:
    - name: ai-gateway
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /v1/chat/completions
      backendRefs:
        - name: llm-gateway
          port: 4000

Der Wert sitzt nicht in dieser YAML. Der Wert sitzt in den Policies, die ihr danach anhängt: Wer darf gpt-4o auf Azure rufen, welches Team hat 100.000 Tokens pro Minute, wohin fällt der Traffic, wenn Azure 429 zurückgibt.

CRD oder Sidecar: Werkzeuge, nicht Religion

Unsere klare Empfehlung: zuerst das Pattern festzurren, dann das Produkt. Ein Envoy-basiertes AI-Gateway als CRD-Satz und ein LiteLLM-Deployment als zentraler Proxy lösen dieselbe Plattform-Aufgabe. Sie sehen nur unterschiedlich aus.

Envoy AI Gateway ist seit 23.06.2026 GA (v1.0.0). Am 21.08.2026 kam v1.1.0: Token-Zählung über Provider, Stream-Idle-Timeout mit Failover, optionales OpenTelemetry-GenAI-Tracing. Die Steuerungs-API bleibt v1beta1 (AIGatewayRoute, AIServiceBackend, BackendSecurityPolicy, MCPRoute). Das Repo envoyproxy/ai-gateway steht bei rund 1.919 Stars (Abruf 04.09.2026). Wer Gateway API und Envoy Gateway schon im Cluster hat, bleibt in dieser Familie.

LiteLLM ist der andere, in deutschen Mittelstands-Setups häufigere Weg: ein OpenAI-kompatibler Proxy, virtuelle Keys, Team-Budgets, Redis-Cache. Nach Angaben der LiteLLM-Release-Notes liegt die stabile Linie am 01.09.2026 bei v1.99.0. Das Docker-Image v1.99.1 vom 03.09.2026 ist der aktuelle -stable-Stand, ohne eigenes PyPI-Paket für 1.99.1. BerriAI/litellm hat ca. 57.849 Stars (Abruf 04.09.2026). Für Produktion gilt der Stable-Tag, nicht der Dev-Tag v1.101.0-dev.

Wir raten aktuell davon ab, beides parallel „mal schnell“ ins selbe Namespace zu werfen. Zwei Gateways heißen zwei Audit-Wahrheiten. Wer den Produktvergleich braucht, findet ihn im 4er-Vergleich der LLM-Proxys, nicht in einer zweiten Einkaufsliste.

# Smoke-Test gegen den Cluster-Endpoint, nicht gegen api.openai.com
curl -sS https://llm-gateway.platform-ai.svc.cluster.local/v1/models 
  -H "Authorization: Bearer ${VIRTUAL_KEY}"

Wenn dieser Call ein Modellverzeichnis zurückgibt und eure App denselben Base-URL nutzt, habt ihr die Plattformgrenze gezogen. Alles andere ist Kosmetik.

Fallback: Azure OpenAI 429 darf nicht die Fach-App treffen

Kommt drauf an, welches Risiko ihr kauft. Aber ohne schriftliche Fallback-Policy ist ein „Multi-Model-POC“ Theater.

Das Szenario, das wir 2026 ständig sehen: Azure OpenAI gpt-4o ist der Standardweg (Entra, Netz, Vertrag). Unter Last kommt 429 oder ein regionales Cap. Jede App baut dann ihren eigenen Retry. Die eine schluckt den Fehler, die andere wechselt still auf einen privaten DeepSeek-Key. Genau das wollt ihr nicht.

Der Plattform-Weg: der Gateway kennt eine Kette. Primär Azure. Bei Rate-Limit, Timeout oder 5xx ein lokales Modell hinter KServe v0.20 (Release 06.08.2026) als LLMInferenceService mit vLLM. Qualität darf sinken, Verfügbarkeit nicht auf null. Die App merkt einen Modell-Alias, keinen Provider-Wechsel.

# KServe v0.20: lokales Fallback-Modell im selben Cluster
apiVersion: serving.kserve.io/v1alpha1
kind: LLMInferenceService
metadata:
  name: fallback-llama
  namespace: platform-ai
spec:
  model:
    uri: hf://meta-llama/Llama-3.1-8B-Instruct
    name: llama-3-1-8b
  replicas: 2

Das ist Geldverschwendung, wenn das Fallback-Modell nie unter Last getestet wird. Ein Failover, den ihr nur in der Architekturfolie habt, ist keiner. Dreht Azure in Staging zu, messt Time-to-First-Token und Qualität, schreibt den Alias fest. Sonst bleibt KServe eine teure GPU-Heizung.

Zweiter ehrlicher Satz: nicht jedes Haus braucht lokale GPUs. Manche fallen von Azure auf ein zweites Azure-Deployment oder auf Bedrock. Das Pattern bleibt gleich. Der Key bleibt im Gateway, nicht in der App.

Prompt-Cache gehört in die Plattform, nicht ins Notebook

Zentrales Caching ist der Hebel, den Teams am längsten vor sich herschieben, weil der POC ohne Cache „schon ganz gut“ läuft.

Drei Ebenen, die ihr nicht in einen Topf werfen solltet:

1. Exakter Hash-Cache (Prompt plus Modell plus Parameter). Billig, keine Fehltreffer, hilft bei identischen System-Prompts und wiederholten FAQ.
2. Semantischer Cache (Embedding, Schwelle oft 0,92-0,95). Höhere Trefferquote, falsch-positive Antworten möglich. Für Support und Klassifikation oft 25-45% weniger Provider-Kosten in unseren Setups. Für kreative Texte lassen wir ihn aus.
3. Prefix-Cache auf dem Inferenz-Worker (KV-Cache, in KServe v0.20 inkl. Offloading). Round-Robin auf GPU-Replicas ohne Cache-Lokalität verschwendet Speicher. Hier gewinnt die Inference Extension gegen blinden Load-Balancer.

Wir sehen bei Kunden, dass Cache-Hits ohne Tenant-Trennung zum Compliance-Vorfall werden. Die Antwort von Team A darf nicht an Team B, nur weil der Prompt ähnlich klingt. Cache-Key ohne Tenant und ohne Modellversion ist fahrlässig.

# Minimaler exakter Cache-Key, den ein Gateway serverseitig bauen kann
import hashlib, json

def cache_key(tenant: str, model: str, messages: list) -> str:
    roh = json.dumps(
        {"tenant": tenant, "model": model, "messages": messages},
        sort_keys=True,
        ensure_ascii=False,
    )
    return hashlib.sha256(roh.encode()).hexdigest()

Das snippet ersetzt kein Redis und keinen semantischen Index. Es zeigt nur, warum die App diesen Key nicht selbst verwalten sollte. Ein App-Cache kennt den Nachbarn nicht und verdoppelt die Tokenrechnung.

Worauf Plattform-Teams 2026 achten sollten

Nicht jedes Cluster braucht diesen Baustein morgen. Diese fünf Punkte trennen Spielzeug von Betrieb:

1. Mehr als eine App oder mehr als ein Provider. Sonst bleibt ihr beim SDK.
2. Provider-Keys verlassen nie das Plattform-Namespace. Rotation und Widerruf laufen über Virtual Keys.
3. Token-Budgets pro Team, zuerst im Report-only-Modus, dann hart.
4. Fallback schriftlich: welcher Alias, welches Qualitätsdelta, welcher Timeout.
5. Telemetrie, die ein AI-Request braucht: Time-to-First-Token, Token in/out, Cache-Hit, gewähltes Modell, abgelehnte Guardrail-Fälle. Request-per-Second allein ist Blindflug.

Wenn ihr gerade evaluiert, ob das „noch ein Tool“ oder echte Infrastruktur ist: zählt die Stellen, an denen heute ein Key in einer CI-Variable liegt. Ab drei Teams ist die Diskussion vorbei. Dann ist ein Kubernetes AI Gateway Plattformarbeit. Der Cluster darunter ist Voraussetzung, nicht der Verkaufshebel für dieses Thema.

Was wir nicht verkaufen: ein Hosting-Paket, nur weil irgendwo YAML steht. Der Job ist die offene KI-Plattform, Routing, Governance. Der Cluster ist Voraussetzung.

Häufig gestellte Fragen

Was ist ein Kubernetes AI Gateway?

Ein Kubernetes AI Gateway ist die zentrale Schicht zwischen euren Apps und LLM-Endpunkten im Cluster oder bei Providern. Es übernimmt Keys, Token-Budgets, Routing, Cache und Audit, damit nicht jede Anwendung Azure OpenAI oder DeepSeek selbst anbindet. Pexon Consulting baut das als Plattform-Baustein, nicht als Sidecar-Spielzeug.

Reicht Ingress oder ein normales API-Gateway?

Für Host, Pfad und TLS ja. Für Tokens, Streaming, GPU-Nähe und Prompt-Inspektion nein. Zwei Calls auf denselben Path können 100 Tokens oder 20.000 kosten. Deshalb reicht NGINX-Annotation nicht.

LiteLLM oder Envoy AI Gateway: was sollen wir nehmen?

Kommt drauf an, aber nicht auf den Lautesten im Slack. Habt ihr Envoy Gateway und wollt CRDs, ist Envoy AI Gateway v1.1.0 (21.08.2026) der kürzere Weg. Braucht ihr Virtual Keys und Team-Budgets in einer UI, ist LiteLLM v1.99 der pragmatische. Beides parallel ist fast immer falsch.

Was kostet ein Kubernetes AI Gateway im Mittelstand?

Der Softwareanteil ist oft Open Source. Der Aufwand sitzt in Policies, SSO, Fallback-Tests und Betrieb. In unseren 6-Wochen-Piloten landet der Korridor meist zwischen 50 und 90k EUR, je nach bestehendem Cluster, GPU-Fallback und Audit-Tiefe. Eine Helm-Installation an einem Nachmittag ist kein Produktionspreis.

Kubernetes AI Gateway vs. Inference Gateway: wo ist der Unterschied?

Das Inference-Gateway (Gateway API Inference Extension) routet zu selbst gehosteten Modellen und achtet auf GPU, Queue und Prefix-Cache. Das AI Gateway steuert zusätzlich Egress, Provider-Keys und Quoten. 2026 brauchen die meisten Plattformen beide Fähigkeiten, nicht das Marketing-Label.

Nächster Schritt

Der POC auf dem Laptop beweist, dass ein Modell antwortet. Er beweist nicht, dass Keys, Fallback, Cache, SSO und Audit clusterweit halten.

Verwandte Themen