LLM-Architektur für den Mittelstand: Der komplette Guide 2026

Ein mittelständischer Maschinenbauer aus Stuttgart hat 2024 sein erstes LLM-Projekt gestartet. Drei Monate später: 47.000 Euro Kosten, ein frustriertes Entwicklerteam und ein Prototyp, den niemand nutzt. Der Fehler lag nicht an der Technologie — sondern an der Architektur.

Diese Geschichte wiederholt sich täglich in deutschen Unternehmen. Die Frage ist längst nicht mehr ob LLMs im Enterprise-Kontext funktionieren. Die Frage ist: Wie baust du eine Architektur, die skaliert, bezahlbar bleibt und regulatorische Anforderungen erfüllt?

Dieser Guide ist die Antwort. Kein theoretisches Framework — sondern die konsolidierten Learnings aus realen Enterprise-Implementierungen im DACH-Raum.

Was du in diesem Guide lernst

• Welche Architektur-Patterns für welchen Use Case funktionieren
• Wie Multi-Tenant-Systeme Isolation und Kosteneffizienz vereinen
• Wo Token-Optimierung am meisten spart (Spoiler: nicht wo du denkst)
• Warum kleine Modelle in vielen Enterprise-Fällen reichen
• Wie du API-Integration, Middleware und Event-Driven Patterns kombinierst
• Was DSGVO und AI Act konkret für deine Architektur bedeuten

Teil 1: Die Grundlagen — Was Enterprise LLM Architektur wirklich bedeutet

Enterprise LLM Architektur ist nicht "ChatGPT mit API-Key". Es ist ein System-Design, das folgende Anforderungen gleichzeitig erfüllt:

Skalierbarkeit: Von 10 Nutzern im Pilotprojekt auf 10.000 im Rollout — ohne Neubau.

Isolation: Mandantenfähigkeit, Datenhoheit, keine Cross-Contamination zwischen Abteilungen oder Kunden.

Kosteneffizienz: Token-Verbrauch, Modell-Hosting und Infrastruktur müssen in einem Business Case aufgehen.

Compliance: DSGVO, AI Act, branchenspezifische Regulierung — nicht als Nachgedanke, sondern als Architektur-Constraint.

Wartbarkeit: Ein System, das dein Team versteht, debuggen kann und weiterentwickeln will.

Die drei Architektur-Ebenen

Der häufigste Fehler: Teams starten beim Inference Layer ("Welches Modell nehmen wir?") statt beim Integration Layer ("Welche Daten brauchen wir, und wo kommen sie her?").

Teil 2: Architektur-Patterns im Vergleich

Pattern 1: Centralized Gateway

Alle LLM-Anfragen laufen über einen zentralen Gateway. Der Gateway übernimmt Routing, Rate Limiting, Logging und Kostenallokation.

Wann einsetzen: Wenn mehrere Teams oder Produkte dasselbe LLM nutzen, aber zentrale Kontrolle benötigt wird.

Vorteile: Ein Punkt für Monitoring und Cost Management, einfaches Modell-Swapping, zentrale Guardrails.

Nachteile: Single Point of Failure ohne Redundanz, Latenz durch zusätzlichen Hop.

Praxis-Beispiel: Ein Versicherungsunternehmen in München nutzt einen zentralen Gateway für Schadensmeldungen (GPT-4o), Kundenservice-Chatbot (Claude 3.5 Haiku) und interne Dokumentensuche (Llama 3 lokal). Ein Gateway, drei Modelle, eine Kostenrechnung.

Pattern 2: Federated Model Mesh

Jedes Team betreibt seinen eigenen LLM-Endpunkt. Ein Service Mesh verbindet sie und ermöglicht Cross-Team-Nutzung.

Wann einsetzen: Größere Organisationen mit unterschiedlichen Compliance-Anforderungen pro Abteilung.

Pattern 3: RAG-First Architecture

Das Modell ist sekundär — die Retrieval-Pipeline ist das Herzstück. Alle Anfragen durchlaufen erst eine Knowledge-Base-Suche, bevor sie ans LLM gehen.

Dieser Ansatz dominiert im Mittelstand, weil er drei Probleme gleichzeitig löst: Halluzination reduzieren, Unternehmens-Know-how einbinden und Modellkosten senken.

Pattern 4: Event-Driven Reactive Architecture

LLM-Aufrufe werden durch Events getriggert, nicht durch User-Requests. Das System reagiert auf Datenänderungen, Zeitpunkte oder externe Signale.

Wann einsetzen: Monitoring, Alerting, automatisierte Reportgenerierung, Compliance-Checks.

Was Event-Driven bedeutet: In einer Event-Driven Architecture kommunizieren Systeme über Events — Nachrichten, die signalisieren, dass etwas passiert ist.

Event-Driven AI verbindet dieses Architekturprinzip mit LLM-basierten Verarbeitungsschritten:

1. Event tritt ein (neues Support-Ticket erstellt)
2. Event Bus verteilt das Event an Subscriber
3. AI Service konsumiert das Event
4. LLM verarbeitet den Kontext (Klassifizierung, Zusammenfassung, Antwort-Draft)
5. Action wird ausgelöst (Ticket kategorisiert, eskaliert, beantwortet)

Die vier Schichten:

Schicht 1: Event Sources: CRM (neuer Lead, Deal-Stage-Änderung), Ticket-System (neues Ticket, Eskalation), E-Mail (eingehend, Bounce), Monitoring (Alert, Anomalie), Datenbank (CDC).

Schicht 2: Event Bus

Für den Mittelstand: RabbitMQ oder AWS EventBridge. Kafka nur bei > 10.000 Events/Sekunde.

Schicht 3: AI Event Processor

Event empfangen → Kontext anreichern (RAG) → LLM-Call → Output validieren → Aktion auslösen → Event loggen

Schicht 4: Action Layer: Direkte Aktion, Human-in-the-Loop (Draft erstellen, nach Approval ausführen), Neues Event publizieren für nachgelagerte Services.

Drei Beispiele:

Automatische Ticket-Triage:

Event: Neues Support-Ticket → LLM: Kategorie + Priorität bestimmen +
Antwort-Draft generieren → Ticket kategorisieren + richtiges Team routen
Zielwert im Beispiel: 90% der Tickets in < 30 Sekunden triagiert (vorher: 2–4 Stunden)

Echtzeit-Lead-Scoring:

Event: Neuer Lead im CRM → Firmendaten anreichern →
ICP-Fit bewerten → Erstansprache generieren
Ergebnis: Leads werden in Minuten statt Tagen bewertet

Contract Change Detection:

Event: Vertragsdokument aktualisiert → LLM: Änderungen identifizieren +
Risikoanalyse → Bei High-Risk: Legal-Team benachrichtigen

Welches Pattern für welchen Use Case?

Teil 3: Multi-Tenant LLM Systeme — Isolation ohne Kostenexplosion

Sobald mehr als eine Abteilung, ein Kunde oder ein Produkt dasselbe LLM-System nutzt, wird Mandantenfähigkeit zur Pflicht.

Level 1 — Logische Isolation: Shared Infrastructure, getrennte Daten durch Tenant-IDs. Günstig, aber risikobehaftet bei Prompt-Injection-Szenarien.

Level 2 — Namespace Isolation: Getrennte Vector Stores, eigene System Prompts, dedizierte API-Keys pro Mandant. Standard für die meisten Mittelstands-Implementierungen.

Level 3 — Physische Isolation: Dedizierte Modell-Instanzen pro Mandant. Teuer, aber nötig bei regulierten Branchen (Finanz, Gesundheit).

Drei Isolations-Patterns: Siloed, Pooled, Hybrid

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.

Isolations-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 sehr niedrig (NVIDIA nennt für leichte Modelle auf dedizierten GPUs 0 bis 10 %).

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

Isolations-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 (höhere GPU-Auslastung), zentrale Updates, schnelles Onboarding. Nachteile: Noisy-Neighbor-Problem, Semantic Leakage bei fehlerhafter Kontexttrennung.

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

Isolations-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.

Fünf Isolations-Schichten

Isolation ist kein Feature, sondern fünf Schichten übereinander:

• 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.
• 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.
• 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).

• 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.
• 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.

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.

Teil 4: Token-Optimierung — Wo die meisten Unternehmen Geld verbrennen

Die 3 größten Kostentreiber

1. Überladene System Prompts: Ein System Prompt mit 2.000 Tokens wird bei jedem API-Call mitgeschickt. Bei 10.000 Calls pro Tag sind das 20 Millionen Tokens — nur für den System Prompt.

2. Fehlende Caching-Strategie: Gleiche Fragen bekommen gleiche Antworten. Ohne Semantic Caching generiert das Modell jedes Mal neu. Ein Caching-Layer mit Embedding-Similarity kann einen großen Teil der Calls eliminieren; in einer Studie mit eigenem Query-Set waren es bis zu 68,8 % (Regmi und Pun 2024).

3. Falsches Modell für den Task: GPT-4o für Klassifikationsaufgaben, die ein Llama-3-8B genauso gut löst — aber 20x günstiger.

Die Token-Optimierungs-Pyramide (von oben nach unten): Model Routing → Semantic Caching → Prompt Compression → Batch Processing → Output Limiting.

Die meisten Teams starten unten (Output Limiting) statt oben (Model Routing).

Teil 4b: Performance-Tuning — Wo die Zeit verloren geht

Bevor du optimierst, musst du verstehen, wo die Latenz entsteht. Ein LLM-Call ist kein einzelner Vorgang — es ist eine Kette von Schritten, und jeder frisst Zeit.

Die vier Phasen eines LLM-Calls: Phase 1 ist Network und Preprocessing mit 50–200ms, Phase 2 ist Prefill (TTFT) mit 200ms–2s, Phase 3 ist Decode (TPOT) mit 15–80ms pro Token, Phase 4 ist Postprocessing und Delivery mit 10–50ms.

TTFT (Time to First Token) misst die Zeit bis das erste Token beim User ankommt und bestimmt die gefühlte Geschwindigkeit. TPOT (Time per Output Token) bestimmt die Lesegeschwindigkeit — unter ~80ms/Token kann der User mitlesen. E2E Latency ist die Gesamtzeit vom Request bis zum letzten Token.

Die magische Grenze liegt bei 500ms TTFT. Darunter fühlt sich die Interaktion flüssig an. Darüber beginnt der User, die KI als "langsam" wahrzunehmen.

Drei Optimierungsebenen

Drei Ebenen, sortiert nach Aufwand:

Modell-Optimierung: Quantisierung senkt die Präzision der Gewichte auf INT8 (laut SmoothQuant bis 1,56x schneller bei halbem Speicherbedarf, laut Kurtic et al. 1 bis 3 % Genauigkeitsverlust) oder INT4; INT8 ist der Sweet Spot für Production. Speculative Decoding lässt ein kleines Draft-Modell Tokens vorschlagen, die das große Modell gebündelt prüft (2 bis 3x auf der Decode-Phase). Distillation trainiert ein kleines Modell auf die Outputs des großen, lohnend ab rund 10.000 Requests am Tag bei klar definiertem Use Case.

System-Optimierung: Continuous Batching rückt den nächsten Request nach, sobald einer fertig ist (mehr Durchsatz und niedrigere P50-Latenz, siehe Anyscale). PagedAttention teilt den KV-Cache in Pages wie virtuellen Speicher (2 bis 4x mehr parallele Requests bei gleichem VRAM). Inference Engines: vLLM als Allrounder, TensorRT-LLM für maximale Leistung auf NVIDIA-Hardware, SGLang für Multi-Turn und Structured Output.

Applikations-Optimierung: Streaming senkt die gefühlte Latenz deutlich, weil die ersten Tokens sofort erscheinen. Context Engineering ersetzt zehn blind gewählte RAG-Chunks durch die drei besten aus einem Re-Ranker. Call-Parallelisierung routet unabhängige Schritte gleichzeitig (LLMCompiler: bis 3,7x schneller als sequenzielles ReAct).

Womit anfangen

Streaming aktivieren senkt die gefühlte Latenz mit einer Zeile Code, sofort umsetzen. Context Engineering (weniger Tokens) senkt vor allem die Kosten; auf die Latenz wirkt kürzerer Input laut OpenAI nur wenig. Model Routing (einfach zu klein) senkt die Kosten laut RouteLLM je nach Aufgabe um 35 bis über 85 %.

Teil 5: Modell-Strategie — Warum kleine Modelle große schlagen

Für viele typische Business-Tasks (Klassifikation, Extraktion, Summarization, einfache Generation) reichen Modelle mit 7–13B Parametern, bei einem Bruchteil der Kosten.

Wann große Modelle wirklich nötig sind:

• Komplexes Reasoning über mehrere Dokumente
• Kreative Textgenerierung mit Nuancen
• Multi-Step Planning mit vielen Variablen
• Code-Generierung für komplexe Systeme

Wann kleine Modelle reichen:

• Klassifikation (Sentiment, Intent, Kategorie)
• Strukturierte Datenextraktion aus Formularen oder E-Mails
• FAQ-Beantwortung auf Basis definierter Wissensdatenbank

Teil 6: API-Integration und Middleware

Direct API Integration: Das LLM wird direkt aus der Applikation aufgerufen. Einfach, aber fragil.

Middleware / Abstraction Layer: Eine Zwischenschicht abstrahiert das LLM von der Applikation. Du tauschst das Modell aus, ohne eine Zeile Applikations-Code anzufassen. Das ist der Standard für produktive Systeme.

Event-Driven Integration: Das LLM reagiert auf Events aus bestehenden Systemen.

Der Middleware-Stack übernimmt alles, was nicht modellspezifisch ist: Authentifizierung, Retry-Logic, Fallback bei Provider-Ausfall, Kosten-Tracking, Prompt-Versionierung.

Drei Integrationsmuster: REST, Streaming, Function Calling

Integrationsmuster 1: Synchrones REST (Request-Response)

Sende eine Anfrage, warte auf die vollständige Antwort.

Wann verwenden: Backend-Prozesse ohne User-Interaktion (Batch-Verarbeitung), kurze Antworten (Klassifikation, Extraktion), wenn die gesamte Antwort benötigt wird.

Vorteile: Einfachste Implementierung, einfaches Error Handling (HTTP Status Codes), einfaches Caching.

Nachteile: User wartet auf vollständige Generierung (bei langen Antworten: 5–30 Sekunden), Timeout-Risiko.

Integrationsmuster 2: Streaming (Server-Sent Events)

Die Antwort wird Token für Token gestreamt, während sie generiert wird.

Wann verwenden: Chat-Interfaces, lange Antworten, immer wenn ein Mensch auf die Antwort wartet.

Vorteile: Time-to-First-Token typischerweise unter 500ms, deutlich bessere UX, kein Timeout-Risiko.

Best Practices: Token-Buffer für wortweise statt zeichenweise Anzeige. Kopie des gesamten Streams für Logging halten. Mid-Stream-Fehler: bisherige Antwort + Fehlermeldung zeigen.

Integrationsmuster 3: Function Calling (Tool Use)

Das LLM entscheidet, welche Funktionen es aufrufen muss, und liefert strukturierte Parameter zurück.

Wann verwenden: Agentic Workflows, strukturierte Datenextraktion (JSON statt Freitext), Multi-Step-Prozesse.

Sicherheits-Regeln: NIEMALS das LLM direkte Datenbankzugriffe oder System-Commands ausführen lassen. Jeder Tool Call muss validiert und autorisiert werden. Maximale Anzahl an Tool Calls pro Anfrage definieren.

Retry-Strategien

Circuit Breaker Pattern: Wenn ein Provider mehr als 50% der Anfragen in den letzten 60 Sekunden fehlschlägt: Circuit öffnen, alle Anfragen an Fallback-Provider routen.

Multi-Provider-Strategie

Die LLM-API-Integration ist nicht der spannendste Teil eines KI-Projekts. Aber sie ist der Teil, der darüber entscheidet, ob dein System in Produktion überlebt.

Middleware als Abstraktionsschicht

Eine KI-Middleware ist ein Abstraction Layer zwischen deiner Anwendung und den LLM-Anbietern. Sie entkoppelt Geschäftslogik von der spezifischen API eines Anbieters.

Warum du eine Middleware brauchst:

1. Vendor Independence: Anbieter-Wechsel ohne Code-Änderungen in den Services
2. Einheitliche Observability: Ein Dashboard, ein Logging-Format, ein Alerting-System
3. Compliance und Governance: Zentrale Audit-Logs, zentrale Policy-Enforcement
4. Kostenoptimierung: Semantic Caching, Model Routing, Token-Budgets — nur möglich durch zentralen Punkt

Layer 1: API Abstraction

Einheitliches Interface für alle LLM-Anbieter. Der Service muss nicht wissen, ob er mit OpenAI, Anthropic oder einem Self-Hosted-Modell spricht.

Layer 2: Routing und Load Balancing

• Model Routing: Einfache Anfragen → günstiges Modell
• Provider Routing: Primary → Fallback bei Fehler
• Cost Routing: Bei Budget-Limit → Downgrade auf günstigeres Modell
• Geographic Routing: EU-Daten → EU-Region

Layer 3: Cross-Cutting Concerns

• Caching (Exact Match + Semantic Cache)
• Rate Limiting (per Service/Team/User Token-Budgets)
• Security (Input Sanitization, PII-Detection, Output Filtering)

Layer 4: Observability

Structured Logging, Metriken (Latenz, Token-Usage, Kosten, Error Rates), Tracing.

Nicht alles auf einmal migrieren: Middleware deployen → einen Service migrieren → validieren → nächsten Service migrieren → Direktintegrationen entfernen.

Middleware: Build oder Buy

Empfehlung für den Mittelstand: Starte mit LiteLLM als Basis. Es deckt die meisten Anforderungen ab.

Teil 7: RAG — Unternehmenswissen als Wettbewerbsvorteil

Die RAG-Pipeline im Enterprise:

1. Ingestion: Dokumente werden in Chunks zerlegt
2. Embedding: Jeder Chunk wird als Vektor gespeichert
3. Retrieval: Bei einer Anfrage werden die ähnlichsten Chunks gefunden
4. Augmentation: Die Chunks werden als Kontext ans LLM gegeben
5. Generation: Das LLM antwortet auf Basis des bereitgestellten Kontexts

Vector Database Auswahl: Pinecone (managed, schnell skalierbar), Weaviate (Open Source, Hybrid Search, DSGVO-kompatibel), Qdrant (performant, Rust-basiert), Chroma (leichtgewichtig, ideal für Prototypen).

Teil 8: Compliance by Design — DSGVO und AI Act als Architektur-Constraint

DSGVO-Anforderungen:

• Datenminimierung: Nur die Daten senden, die für die Aufgabe nötig sind
• Zweckbindung: Prompts und Responses dürfen nicht für andere Zwecke verwendet werden
• Löschpflicht: Bei Löschungsanfragen müssen alle gespeicherten Daten entfernt werden können
• Auftragsverarbeitung: Bei Cloud-LLMs ist ein AV-Vertrag Pflicht

AI Act Anforderungen (ab 2026):

• Risiko-Klassifizierung
• Transparenzpflicht gegenüber Nutzern
• Dokumentationspflicht
• Human Oversight bei Hochrisiko-Systemen

Teil 9: Der 90-Tage-Implementierungsplan

Tage 1–30: Foundation

• Use Cases priorisieren (max. 3 für den Start)
• Architektur-Pattern wählen
• Modell-Strategie definieren
• Compliance-Check mit Datenschutzbeauftragtem
• Team zusammenstellen

Tage 31–60: Build

• Middleware / Gateway aufsetzen
• RAG-Pipeline für ersten Use Case implementieren
• Monitoring und Logging einrichten
• Erste Integration mit bestehendem System

Tage 61–90: Scale

• Pilotgruppe onboarden (20–50 Nutzer)
• Feedback-Loop einrichten
• Kosten-Report erstellen
• Zweiten und dritten Use Case starten

Die Architektur-Checkliste

Vor dem Start:

• Architektur-Pattern gewählt und dokumentiert?
• Modell-Strategie definiert?
• Multi-Tenant-Anforderungen geklärt?
• DSGVO und AI Act Compliance sichergestellt?
• Token-Budget kalkuliert?
• Monitoring und Alerting geplant?
• Rollback-Strategie vorhanden?

Weiterlesen: Die Deep Dives

• Token-Optimierung
• KI-Wissensdatenbank aufbauen: Architektur, RAG-Patterns, Tools und ROI
• Vector Database Vergleich
• KI-Governance Framework
• DSGVO-konforme KI-Implementierung