Apache APISIX AI: OSS-API-Gateway mit LLM-Plugins (ai-proxy, decorator, rate-limiting)

Was ist Apache APISIX AI?

Apache APISIX (apisix.apache.org) ist ein Open-Source-API-Gateway unter Apache-2.0-Lizenz, gehostet von der Apache Software Foundation. Das Projekt entstand 2019 und ist seit 2022 Top-Level-Project bei Apache. Stand Mai 2026 liegt die stabile Version bei APISIX 3.x; die Engine basiert auf NGINX/OpenResty und ist konzeptuell vergleichbar mit Kong, allerdings vollständig OSS ohne Enterprise-Tier-Pflicht. Die Hauptentwicklung kommt von der chinesischen Firma API7.ai (die kommerzielle Support-Verträge anbietet), die meisten Plugins sind in der Community-Edition enthalten.

Das AI-Gateway ist eine Sammlung von Plugins, die APISIX um LLM-spezifische Funktionen erweitern. Stand Mai 2026 die wichtigsten: ai-proxy (Routing zu OpenAI, Anthropic, Mistral, Cohere, Google, Azure OpenAI, AWS Bedrock, Ollama, weitere OpenAI-kompatible Endpoints), ai-prompt-decorator (System-Prompts und Template-Präfixe vor dem Upstream), ai-prompt-template (Templates mit Variablen-Substitution), ai-rate-limiting (Token-basiertes Rate-Limit statt Request-basiert), ai-rag (RAG-Pipeline-Plugin mit Vektor-Datenbank-Anbindung), ai-content-moderation (Inhalts-Filter über externe Klassifikatoren). Anders als bei Kong ist semantisches Caching kein eingebautes Plugin; eine Anbindung an Redis mit Embedding-Vergleich lässt sich aber als Custom-Plugin realisieren.

Die Lizenz-Frage ist klar: alles ist Apache-2.0 OSS. API7.ai bietet kommerziellen Support, Schulungen und ein managed Cloud-Angebot (API7 Cloud), aber das Gateway selbst plus alle Plugins laufen ohne Lizenz-Schlüssel. Das macht APISIX zur richtigen Wahl, wenn Procurement-Anforderungen explizit OSS verlangen oder das Budget keine kommerzielle Lizenz hergibt.

Für fairlane.systems ist APISIX AI in zwei Setups relevant. Erstens für Mandate, die bereits APISIX als allgemeines API-Gateway betreiben – dann kommt das AI-Plugin als kleine Erweiterung. Zweitens für reine OSS-Stacks mit Kubernetes-Affinität und ohne Bereitschaft zu kommerzieller Lizenz. In beiden Fällen ist APISIX eine valide Alternative zu Kong (mit dessen Enterprise-Plugins) und zu LiteLLM (mit Python-Runtime statt NGINX/OpenResty).

Warum es im OSS-Umfeld zählt

Drei Eigenschaften machen APISIX im OSS-Umfeld attraktiv. Erstens: vollständig Apache-2.0 ohne versteckte Enterprise-Tier-Pflicht. Bei Kong liegen Schlüssel-Plugins wie ai-semantic-caching, ai-rate-limiting-advanced und ai-azure-content-safety in der kostenpflichtigen Variante; bei APISIX sind die äquivalenten Plugins (ai-rate-limiting, ai-content-moderation, ai-rag) in der OSS-Edition. Das Lizenz-Modell ist sauber, Procurement-Prüfungen verlaufen ohne Diskussion.

Zweitens: Kubernetes-Operator und Ingress-Controller. APISIX bietet einen Apache-2.0-Ingress-Controller für Kubernetes, der Routes als CRDs verwaltet (ApisixRoute, ApisixUpstream, ApisixConsumer). Das passt zu GitOps-Workflows mit Argo CD oder Flux. Eine deklarative Konfiguration in Git, Rollout per kubectl apply, Versionierung via Helm – alles standardkonform.

Drittens: NGINX-Performance. Wie Kong basiert APISIX auf NGINX/OpenResty und liefert konstant unter 5 ms Latenz-Overhead pro Request, auch unter Last. Bei einer Plattform mit mehreren tausend RPS ist das ein realer Vorteil gegenüber Python-basierten Gateways.

Unter CH-DSG-Sicht ist APISIX gut positioniert. Vollständig self-hostable, keine Cloud-Komponente erforderlich. Daten verlassen die eigene Infrastruktur nur in Richtung der konfigurierten Upstream-LLMs. Audit-Log lässt sich über das file-logger- oder http-logger-Plugin in jedes Backend schreiben – Loki, Elasticsearch, Postgres, S3. Eine WORM-Schicht hinter dem Logging-Backend bringt Art.-957a-OR-Konformität.

Die Schwächen sind im LLM-Plugin-Ecosystem zu suchen. Stand Mai 2026 sind die AI-Plugins jünger und weniger ausgereift als die von Kong oder die LiteLLM-Features. Semantisches Caching fehlt nativ, das Prompt-Repository ist minimaler, die Observability hängt am Standard-APISIX-Logging-Layer ohne LLM-spezifische Cost-Reports. Wer das nicht selbst nachrüsten will, sollte Kong oder LiteLLM prüfen.

Wie es funktioniert

Die Installation läuft entweder über Docker-Compose (gut für Pilot- und Single-Node-Setups) oder über das Apache-APISIX-Helm-Chart für Kubernetes. APISIX braucht einen etcd-Cluster als Konfigurations-Speicher (idealerweise 3 Nodes für HA); für kleine Setups lässt sich etcd als embedded-Variante starten.

Die Konfiguration erfolgt entweder über die Admin-API (curl-Aufrufe gegen /apisix/admin), über das Dashboard (apache/apisix-dashboard) oder über Kubernetes-CRDs. Eine typische LLM-Route via Admin-API:

curl -X PUT http://apisix:9180/apisix/admin/routes/llm-mistral \ -H "X-API-KEY: ${APISIX_ADMIN_KEY}" \ -d '{ "uri": "/llm/mistral/*", "upstream": {"type": "roundrobin", "nodes": {"api.mistral.ai:443": 1}, "scheme": "https"}, "plugins": { "ai-proxy": { "auth": {"header": {"Authorization": "Bearer ${MISTRAL_API_KEY}"}}, "model": {"provider": "mistral", "name": "mistral-large-2411"} }, "ai-rate-limiting": {"limit_strategy": "token", "limit": 1000000, "time_window": 3600} } }'

Damit ist die Route /llm/mistral/* eingerichtet, leitet Anfragen an Mistral La Plateforme weiter und begrenzt jedes API-Token auf 1 Mio. Tokens pro Stunde. Consumers (das äquivalent zu Virtual Keys) werden separat angelegt mit key-auth oder JWT-Credentials.

Das ai-prompt-decorator-Plugin hängt sich vor den Upstream-Call und kann System-Prompts injizieren oder den User-Prompt um Präfixe ergänzen. Beispiel: jede Anfrage an /llm/mistral/* bekommt automatisch den System-Prompt "Antworte auf Deutsch, kurz und faktisch" vorgesetzt – ohne dass die Anwendung das mitschickt. Das vereinfacht Multi-Tenant-Setups, in denen Mandanten unterschiedliche System-Prompts haben sollen.

Observability läuft über die Standard-Logger-Plugins: file-logger, http-logger, syslog, kafka-logger, loki-logger. Pro Request lässt sich ein JSON-Eintrag mit Method, Path, Upstream, Status, Latenz, Token-Count (via ai-proxy-Erweiterung) in das Logging-Backend schreiben. Eine LLM-spezifische Cost-Report-UI gibt es nicht out-of-the-box – Cost-Reporting wird über Loki/Grafana selbst gebaut, indem man Token-Counts und Modell-Preise in einer Grafana-Variable hinterlegt.

APISIX-AI-Setup in 5 Schritten

1. 01APISIX 3.x via Docker-Compose oder Helm-Chart deployen, etcd-Cluster (3 Nodes für HA), Admin-Key generieren.
2. 02Provider-Upstreams (Mistral, Anthropic, OpenAI, Ollama) als APISIX-Upstreams anlegen, ai-proxy-Plugin pro Route konfigurieren.
3. 03Consumers für Mandanten/Anwendungen anlegen, key-auth oder JWT-Credentials ausstellen, ai-rate-limiting auf Token-Budgets setzen.
4. 04ai-prompt-decorator-Plugin pro Route für mandanten-spezifische System-Prompts aktivieren, falls nötig.
5. 05Logger-Plugin (loki-logger oder http-logger) global aktivieren, Loki/Grafana für Cost-Reports und Latenz-Dashboards einrichten.

Wann APISIX AI passt

Erstens, wenn APISIX bereits als allgemeines API-Gateway läuft. Eine bestehende Installation mit 40 Routes für REST-Services bekommt drei zusätzliche LLM-Routes – der Operations-Overhead bleibt minimal.

Zweitens, wenn das Procurement Apache-2.0 ohne Enterprise-Tier verlangt. APISIX ist in dieser Hinsicht klarer positioniert als Kong (das viele LLM-Features hinter der Konnect-Lizenz versteckt). Für öffentliche-Hand-Mandate und einige akademische Setups ist die Lizenz-Sauberkeit ein hartes Kriterium.

Drittens für Kubernetes-Plattformen mit GitOps. APISIX-CRDs (ApisixRoute, ApisixUpstream, ApisixConsumer) lassen sich in Git versionieren und über Argo CD oder Flux deployen. Das passt zu Plattformen, die alles deklarativ verwalten.

Viertens für Setups mit hohem Volumen und harten Latenz-Anforderungen. Wie Kong liefert APISIX unter 5 ms Overhead. Bei mehreren tausend RPS ist das ein klarer Vorteil gegenüber Python-Gateways.

Fünftens für Multi-Tenant-Plattformen mit mandanten-spezifischen System-Prompts. Das ai-prompt-decorator-Plugin lässt sich pro Route oder Consumer konfigurieren – jeder Mandant bekommt seinen eigenen System-Prompt automatisch, ohne dass die Anwendung das wissen muss.

Wann NICHT

Erstens bei kleinen Setups ohne Kubernetes. APISIX lässt sich als Docker-Compose betreiben, aber sein Sweet-Spot ist die Kubernetes-Welt. Für ein KMU mit einer einzelnen VM und drei Anwendungen ist die etcd-Komplexität plus die NGINX-Lua-Plugin-Logik Overkill. LiteLLM auf einem Single-VM-Setup ist einfacher zu betreiben.

Zweitens, wenn das Team kein OpenResty/Lua-Wissen hat. Plugin-Anpassungen und Debug-Sessions brauchen Kenntnisse in OpenResty. Wer in Python-Stacks zuhause ist, kommt mit LiteLLM oder Helicone schneller voran.

Drittens für Setups mit Prompt-Versionierung, A-B-Tests und Eval-Workflows. APISIX-AI bietet basale Prompt-Templates, aber kein vollausgebautes Prompt-Repository. Wer 30+ Prompts versioniert verwaltet, sollte Langfuse oder Portkey parallel betreiben.

Viertens, wenn semantisches Caching zwingend ist. APISIX hat kein eingebautes Semantic-Cache-Plugin (Stand Mai 2026). Eigenbau mit Redis-Search ist machbar, kostet aber Entwicklungs-Zeit. Kong (Enterprise), Portkey oder LiteLLM mit Redis-Cache decken das besser ab.

Fünftens, wenn LLM-spezifisches Cost-Reporting out-of-the-box gefragt ist. APISIX schreibt Logs in beliebige Backends, aber ein UI mit Cost-pro-Mandant/Modell muss selbst gebaut werden. Portkey und Helicone haben das eingebaut.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. Apache APISIX Documentation – installation, plugins, admin API · 2026-05
2. APISIX AI Gateway Plugins – ai-proxy, ai-prompt-decorator, ai-rate-limiting · 2026-04
3. Apache APISIX 3.x Release Notes and Changelog · 2026-05
4. API7 Blog – APISIX AI Gateway introduction and use cases · 2026-03