KIVA-Plattform – Architektur

Überblick

Die KIVA-Plattform nutzt eine flexible Gateway-Architektur mit dem LLM Gateway als Kern, die Sicherheit, Flexibilität und Performance optimal vereint. Kong Gateway kann optional als zusätzliche Sicherheitsebene hinzugefügt werden.

⚠️ Hinweis: Die aktuelle Implementierung auf Azure Kubernetes Service (AKS) dient als Proof of Concept (POC) für Evaluierungszwecke. Die Architektur ist cloud-agnostic und kann jederzeit auf andere Cloud-Provider oder On-Premise-Infrastruktur migriert werden.

Architektur-Prinzipien

1. LLM Gateway als zentrales Herzstück

Das Herzstück: LLM Gateway

Die KIVA-Plattform basiert auf einem Fork von LiteLLM v1.74.4 - dem zentralen LLM Gateway, das alle Kernfunktionen bereitstellt:

• Einheitliche API für 100+ LLM-Anbieter (OpenAI-kompatibel)
• Authentifizierung & Autorisierung (API Keys, Teams, User Accounts)
• Budget-Management und Kostenkontrolle
• Rate Limiting und Token-Limits
• Modell-Routing und Load Balancing
• Monitoring, Logging und Metriken (Prometheus)
• Response Caching (Redis)
• Web-Dashboard für Administration

Wichtig: Der LLM Gateway ist ein vollständig eigenständiger AI Gateway und benötigt keine zusätzlichen Komponenten für seine Kernfunktionen.

2. Optionale Infrastructure-Layer (Kong)

Kong Gateway - Enterprise Add-on

Kong kann als optionale zusätzliche Sicherheitsebene hinzugefügt werden:

• Zusätzliche TLS-Terminierung
• Erweiterte DDoS-Protection
• IP-Whitelisting
• Weitere Enterprise-Features

Wichtig: Kong ist nicht notwendig für den Betrieb der Plattform. Der LLM Gateway kann direkt angesprochen werden.

Vorteil: Flexible Architektur - von minimal (nur LLM Gateway) bis enterprise (LLM Gateway + Kong)

Komponenten-Übersicht

Minimale Architektur (Core):

Enterprise Architektur (mit Kong - optional):

Kernprinzipien

LLM Gateway Fork für Souveränität

Eigener Fork für die Verwaltung

Die Plattform nutzt einen Fork von LiteLLM v1.74.4, angepasst für die Anforderungen der öffentlichen Verwaltung:

• MIT-Lizenz: Enterprise-Ordner entfernt, nur Open-Source-Code
• Fokus auf Grundfunktionalitäten: Schlanke Referenzimplementierung
• Souveränität: Volle Kontrolle über Code und Weiterentwicklung
• Upstream-kompatibel: Orientierung an LiteLLM-Standards

Repository: /litellm/ (interner Fork)

Sicherheit Built-In

Der LLM Gateway bringt Sicherheitsfunktionen bereits mit:

1. Authentifizierung: API-Key-Management, User & Team Accounts
2. Autorisierung: Token Limits, Rate Limiting pro User/Team
3. Budget-Kontrolle: Automatische Kostenkontrolle und Limits
4. Audit-Logging: Vollständige Nachverfolgbarkeit aller Anfragen
5. TLS-Support: Verschlüsselte Kommunikation

Optional mit Kong:

• Zusätzliche DDoS-Protection
• IP-Whitelisting
• Weitere Enterprise-Features

Ergebnis: Sicherheit bereits in der Kern-Komponente, Kong nur als Add-on

Modulare Architektur

Jede Komponente ist unabhängig skalierbar:

• LLM Gateway: Mehrere Instanzen für Last-Verteilung (Kern-Komponente)
• Inference Engine (vLLM): GPU-Pods nach Bedarf hinzufügen
• Kong Gateway: Optional, horizontal skalierbar
• Client Apps: Unabhängig deploybar

Vorteil: Optimale Ressourcen-Nutzung, keine Über-Provisionierung. Der LLM Gateway läuft auch standalone.

Cloud-Agnostic Design

Keine Abhängigkeit von spezifischen Cloud-Diensten:

• Standard Kubernetes: Läuft auf Azure, AWS, GCP, On-Premise
• Helm Charts: Plattformunabhängige Deployments
• Portable Konfiguration: Keine cloud-spezifischen APIs

Aktueller POC: Azure Kubernetes Service (West Europe)

Zukünftige Optionen:

• AWS Elastic Kubernetes Service (EKS)
• Google Kubernetes Engine (GKE)
• On-Premise Kubernetes
• OpenShift

Vorteil: Volle Flexibilität bei Infrastruktur-Entscheidungen

Datenfluss

Typische Anfrage-Verarbeitung

Minimale Architektur (ohne Kong):

1. Client sendet Anfrage an LLM Gateway
   ↓
2. LLM Gateway prüft:
   • API-Key gültig?
   • Rate Limit erreicht?
   • Budget verfügbar?
   • Welches Modell verwenden?
   ↓
3. Modell-Auswahl:
   • Lokales vLLM? → Keine externen Kosten
   • Externe API? → Kosten tracken
   • Cache verfügbar? → < 50ms Antwort
   ↓
4. Antwort wird zurückgegeben
   • Kosten werden erfasst
   • Logs werden geschrieben
   • Metrics werden aktualisiert (Prometheus)

Mit Kong (Enterprise):

1. Client sendet Anfrage
   ↓
2. Kong Gateway prüft (optional):
   • TLS-Verbindung gültig?
   • IP-Whitelist?
   • DDoS-Protection
   ↓
3. LLM Gateway prüft:
   • API-Key gültig?
   • Rate Limit & Budget?
   • Modell-Routing
   ↓
4. Modell-Inferenz & Antwort

Durchschnittliche Latenz:

• Lokale Modelle (vLLM): 500-1500ms
• Externe APIs: 1000-3000ms
• Cache-Hit: < 50ms

Skalierbarkeit

Horizontale Skalierung

Alle Komponenten sind stateless:

Kong Gateway:     2-10 Pods (Auto-Scaling, optional)
LLM Gateway:      2-8 Pods (Auto-Scaling)
Inference Engine: 1-4 GPU-Pods (nach Bedarf)
Redis Cache:      3 Pods (High Availability)

Auto-Scaling-Trigger:

• CPU-Auslastung > 70%
• Request-Queue-Länge
• Antwortzeit > Threshold

Lastverteilung

Intelligentes Load Balancing:

1. Kong (optional): Round-Robin über LLM Gateway-Instanzen
2. LLM Gateway: Modell-basiertes Routing
   • Lokale Modelle bevorzugt (kostenfrei)
   • Fallback auf externe APIs bei Überlast
3. Inference Engine: Continuous Batching für GPU-Effizienz

Hochverfügbarkeit

Fallback-Mechanismen

Automatische Fehlerbehandlung:

Modell-Gruppe: gpt-4
  1. Primär: vllm/local-llama (lokal)
     ↓ (bei Ausfall/Überlast)
  2. Fallback 1: azure/gpt-4-turbo
     ↓ (bei Ausfall)
  3. Fallback 2: openai/gpt-4

Automatische Erkennung:

• Timeouts (> 30s)
• HTTP-Fehler (500, 502, 503)
• Rate-Limits überschritten

Disaster Recovery

Backup-Strategien:

• Konfiguration: Versioniert in Git (GitOps)
• Daten: PostgreSQL Backups (täglich)
• Secrets: Verschlüsselt in Kubernetes Secrets
• Monitoring: Prometheus Daten-Retention 30 Tage

Recovery Time Objective (RTO): < 1 Stunde

Recovery Point Objective (RPO): < 24 Stunden

Monitoring und Observability

Drei-Ebenen-Monitoring

1. Infrastruktur-Ebene:

• Kubernetes Cluster Health
• Node-Ressourcen (CPU, RAM, GPU)
• Network-Metriken

2. Anwendungs-Ebene:

• Kong Request-Metriken (optional)
• LLM Gateway Performance
• Inference Engine GPU-Auslastung

3. Business-Ebene:

• Kosten pro Team
• Modell-Nutzung
• Budget-Auslastung

Tools: Prometheus, Grafana, Azure Monitor

Sicherheits-Architektur

Netzwerk-Segmentierung

Internet
  ↓
[Azure Load Balancer]
  ↓
[Kong Gateway] ←→ [External Proxy]
  ↓
[LLM Gateway]
  ↓ ↓
[Inference Engine] [Redis]

Network Policies:

• Nur Kong hat externe IP
• Interne Services nur über Service-Mesh
• Outbound-Traffic über kontrollierten Proxy

Secrets Management

Sensitive Daten geschützt:

• API-Keys: Kubernetes Secrets
• Zertifikate: Cert-Manager
• Datenbank-Passwörter: Azure Key Vault (POC) / Vault (Production)
• Rotation: Automatisch alle 90 Tage

Deployment-Architektur

GitOps mit Helmfile

Deklarative Infrastruktur:

Code-Änderung → Git Push → ArgoCD erkennt → Deployment

Vorteile:

• Vollständige Versionskontrolle
• Automatische Rollbacks bei Fehlern
• Reproduzierbare Deployments
• Audit-Trail aller Änderungen

Zusammenfassung