Multi-Tenant LLM Systeme — Isolation, Security & Skalierung für Enterprise

Stell dir vor, du baust eine KI-Plattform für dein SaaS-Produkt. Drei Kunden nutzen sie: ein Krankenhaus, ein E-Commerce-Startup und eine Anwaltskanzlei. Alle drei stellen Fragen an dasselbe LLM. Dann passiert es: Der Chatbot des E-Commerce-Startups spuckt plötzlich Patientendaten aus. Die Anwaltskanzlei sieht Umsatzzahlen, die ihr nicht gehören. Dein Telefon klingelt. Es ist kein Kunde — es ist dein Anwalt.

Das ist kein hypothetisches Szenario. Semantic Leakage — das unbeabsichtigte Durchsickern von Kontext zwischen Tenants — ist das LLM-Äquivalent einer SQL Injection. Nur dass es schwerer zu erkennen, schwerer zu reproduzieren und potenziell verheerender ist.

Dieser Artikel zeigt, wie du eine Multi-Tenant LLM-Architektur baust, die dieses Problem strukturell unmöglich macht.

Warum Multi-Tenancy bei LLMs anders funktioniert als bei klassischer Software

Wenn du aus der SaaS-Welt kommst, denkst du bei Multi-Tenancy an Row-Level Security, Tenant-IDs in der Datenbank und vielleicht getrennte Schemas. Gelöstes Problem, richtig?

Bei LLMs ist alles anders. Das Modell hat kein Konzept von "Tenants". Es sieht nur Tokens — und wenn die Tokens des einen Kunden im Kontext des anderen Kunden landen, gibt es keine Fehlermeldung. Das Modell antwortet einfach. Höflich, kompetent und mit den falschen Daten.

Drei neue Dimensionen machen klassische Isolationsmodelle obsolet: Datenfluss ist unstrukturiert (Prompts, Kontexte, Embeddings) statt Schema-basiert. State Management passiert im GPU-VRAM über KV-Cache und Konversations-Memory. Sicherheitsrisiken sind Prompt Injection, Semantic Leakage und Cross-Tenant Context Bleeding — nicht nur SQL Injection.

Das bedeutet: Wer ein Multi-Tenant LLM-System baut, muss sowohl klassische Isolation (Netzwerk, Datenbank, Auth) als auch LLM-spezifische Isolation (Prompt-Kontext, Embeddings, Memory, KV-Cache) sicherstellen.

Die drei Architektur-Patterns im Vergleich

Jedes Unternehmen steht vor derselben Frage: Wie viel Trennung brauche ich wirklich? Die Antwort bestimmt Kosten, Komplexität und Risiko. Drei Patterns haben sich in der Praxis durchgesetzt.

Pattern 1: Siloed Deployment (Dedicated per Tenant)

Maximale Isolation — jeder Tenant bekommt eine eigene Modell-Instanz, eigene GPU-Ressourcen, eigenen Vektor-Store. Denk an ein Apartmenthaus vs. ein Einfamilienhaus: Siloed Deployment gibt jedem Kunden sein eigenes Haus mit eigenem Zaun, eigener Alarmanlage und eigener Stromversorgung.

Vorteile: Null Cross-Tenant-Risiko, individuelle Modell-Konfiguration, SLA pro Tenant steuerbar, Compliance-freundlich (DSGVO). Nachteile: Kosten 5–10x höher als Shared-Modelle, GPU-Utilization oft unter 20%.

Wann sinnvoll: Regulierte Branchen (Finanz, Gesundheit), Kunden mit expliziten Datenhaltungs-Anforderungen.

Pattern 2: Pooled Infrastructure mit logischer Isolation

Mittlere Isolation — Shared-Modell, aber strikte logische Trennung über Tenant-Kontext, Row-Level Security und Namespace-Isolation. Alle wohnen unter einem Dach und teilen sich die Heizung — aber jeder hat sein eigenes Schloss.

Vorteile: Kosteneffizient (GPU-Utilization bei 60–80%), zentrale Updates, schnelles Onboarding. Nachteile: Noisy-Neighbor-Problem, Semantic Leakage bei fehlerhafter Kontexttrennung.

Wann sinnvoll: SaaS-Plattformen mit vielen kleinen bis mittleren Kunden.

Pattern 3: Hybrid — Tiered Isolation

Adaptive Isolation — Kombination aus Siloed (für Premium-Tenants) und Pooled (für Standard-Tenants). Das ist das Modell, das in der Praxis am besten funktioniert. Warum? Weil Kunden unterschiedliche Bedürfnisse haben.

Vorteile: Optimales Kosten-Sicherheits-Verhältnis, Upselling-Pfad eingebaut, Compliance flexibel pro Tenant-Klasse. Nachteile: Höchste Architektur-Komplexität, zwei Betriebsmodi bedeuten doppelte Observability.

Wann sinnvoll: Für die meisten Mittelstands-SaaS-Unternehmen die richtige Wahl.

Security-Architektur: Die 5 Isolations-Schichten

Du hast dein Pattern gewählt — aber das Pattern allein schützt dich nicht. Was dich schützt, ist Defense in Depth: fünf Schichten, die jeweils unabhängig voneinander Isolation garantieren.

Schicht 1: Network & Infrastructure Isolation

Die äußerste Mauer. VPC/Subnet-Trennung pro Tenant-Klasse, Private Endpoints für LLM-API-Calls, Egress Controls und mTLS zwischen allen internen Services.

Schicht 2: Authentication & Authorization

Tenant-aware JWT mit tenant_id, org_id und role. RBAC pro Tenant, API-Key-Isolation pro Tenant, ABAC für feingranulare Policies.

Schicht 3: Data & Embedding Isolation

Die kritischste Schicht — hier passieren die meisten Multi-Tenant-Breaches. Das Grundproblem: Wenn der Tenant-Filter nicht vor dem LLM kommt, sondern vom LLM selbst generiert werden soll, bist du einen kreativen Prompt davon entfernt, alle Kundendaten offenzulegen.

Lösung: CTE-basierte SQL-Isolation. Der Tenant-Filter wird vor dem LLM-generierten Query als CTE eingefügt — das Modell sieht nur gefilterte Daten. Vektor-Store mit Namespace- oder Collection-Level-Trennung, RAG-Pipeline mit Pre-Retrieval-Filter (nicht Post-Retrieval).

Schicht 4: Prompt & Context Isolation

System Prompts werden server-seitig injiziert, nie vom Client. Separate Memory-Stores pro Tenant. Bei Shared-GPU-Deployments: Prefix Caching nur innerhalb des Tenant-Kontexts. Agentic Workflows: jeder Tool-Call wird mit Tenant-Kontext validiert.

Schicht 5: Observability & Audit

Tenant-tagged Logging für jeden API-Call, Cost Attribution pro Tenant, Anomaly Detection für ungewöhnliche Prompt-Patterns, lückenloser Compliance-Audit-Trail.

Skalierung: GPU-Ressourcen-Management

Die größte Herausforderung bei Multi-Tenant LLM-Systemen ist die GPU-Allokation. Empfehlung für den Mittelstand: Priority-based Scheduling mit Autoscaling-Fallback — bietet das beste Verhältnis aus Komplexität und Effizienz.

Rate Limiting ist zwingend: Ohne es feuert ein schlecht programmierter Bot 10.000 Requests in einer Minute und degradiert die Performance für alle anderen Tenants. Token Bucket pro Tenant, Priority Queue nach Tier, Burst Capacity für kurze Spitzen.

LLM Gateway: Die zentrale Steuerungsschicht

Das LLM Gateway ist der Portier des Systems — es kennt jeden Tenant, weiß wer wohin darf, zählt Besuche und schlägt Alarm wenn etwas nicht stimmt.

Kernfunktionen: Routing (Tenant → richtiges Modell), Auth & RBAC, Rate Limiting, Cost Tracking (Token-Verbrauch → Billing), Guardrails (Prompt Injection Detection, PII Filtering), Fallback & Retry und Observability.

Empfohlener Tech-Stack: LiteLLM als LLM Gateway, Weaviate als Multi-Tenant-nativer Vektor-Store, Langfuse + Grafana für Observability, Guardrails AI für Prompt-Schutz, Redis mit Namespace per Tenant für Memory.

Agentic Multi-Tenancy: Die nächste Komplexitätsstufe

Agenten machen alles komplizierter: 1 User-Request erzeugt 10–30 LLM-Calls, Tool-Calls überqueren Systemgrenzen, Memory-Persistenz darf nicht tenant-übergreifend leaken.

Isolation-Patterns für Agenten: Per-Tenant Agent Sandbox (isolierter Container pro Agent), Tenant-scoped Tool Permissions, Semantic Checkpointing (tenant-isolierte State-Persistenz) und Egress-Kontrolle.

DSGVO & Compliance im Multi-Tenant LLM-Setup

Ein DSGVO-Verstoß kann bis zu 4% des Jahresumsatzes kosten. Bei Multi-Tenant-Systemen multipliziert sich das Risiko, weil ein architektonischer Fehler alle Tenants gleichzeitig betrifft.

Kernmaßnahmen: PII-Filtering vor LLM-Call (Datenminimierung), gezielte Löschbarkeit in Vektor-Stores, Caches und Logs (Recht auf Löschung), AVV mit LLM-Provider und EU-Hosting bevorzugen, lückenloser Audit-Log.

Häufige Fragen

Was ist Multi-Tenant LLM-Architektur?

Multi-Tenant LLM-Architektur bezeichnet ein System-Design, bei dem mehrere Nutzergruppen (Tenants) — Teams, Abteilungen oder externe Kunden — eine gemeinsame LLM-Infrastruktur nutzen, dabei aber strikt voneinander isoliert sind. Die Isolation umfasst Daten, Prompts, Kosten, Performance und Compliance.

Wie verhindere ich Datenlecks zwischen Tenants in LLM-Systemen?

Durch Defense-in-Depth mit fünf Schichten: Netzwerk-Isolation, Authentifizierung mit Tenant-Kontext, Daten- und Embedding-Isolation (Pre-Retrieval-Filter), Prompt- und Memory-Trennung sowie lückenlose Audit-Logs. Kritischster Punkt: CTE-basierte SQL-Filterung — das LLM darf nie ungefiltertes SQL generieren.

Was kostet eine Multi-Tenant LLM-Plattform?

Ein Pooled Setup für 10 Tenants kostet ab ~$2.300/Monat (~$230/Tenant), ein Siloed Setup ab ~$16.000/Monat (~$1.600/Tenant). Hybrid-Ansätze liegen bei ~$5.500–$13.000/Monat.

Welches Architektur-Pattern passt für meinen Mittelstand?

Für die meisten Mittelständler ist der Hybrid-Ansatz optimal: Standard-Tenants im Shared Pool (kostengünstig), Premium-Tenants auf dedizierten Ressourcen (maximale Isolation). Starte mit Pooled und biete Siloed als Upgrade-Pfad an.

Fazit

Multi-Tenant LLM-Architekturen sind kein optionales Feature — sie sind die Grundlage für jedes skalierbare KI-Produkt. Der Mittelstand, der jetzt die richtige Architektur wählt, spart langfristig 60–80% GPU-Kosten und vermeidet Compliance-Desaster. Der Schlüssel liegt nicht in einem einzigen Pattern, sondern in der richtigen Kombination aus Isolation, Gateway-Steuerung und Observability — abgestimmt auf das eigene Business-Modell.