LLM-Architektur: Systemdesign für KI im Produktivbetrieb
Das Ausführen eines Modells ist ein Infrastrukturproblem. Den Nutzen aus einem Modell zu ziehen, ist ein Architekturproblem.
Die Infrastrukturschicht — Laufzeiten, Hardware, API-Endpunkte — bestimmt, was möglich ist. Die Architekturschicht bestimmt, was mit einer Anfrage tatsächlich passiert: welches Modell sie bearbeitet, wie viel sie kostet, was sie validiert und wie Fehler abgefangen werden.
Die meisten Systeme beginnen mit einem Modell und überhaupt keiner Architektur. Das ist für Prototyping korrekt. In der Produktion wird es zu einer Schwachstelle.
LLM-Architektur umfasst die Designentscheidungen, die „ein aufrufbares Modell“ in „ein vertrauenswürdiges System“ verwandeln.
Wo LLM-Architektur im Stack angesiedelt ist
LLM-Architektur befindet sich in der Mitte eines dreischichtigen Modells:
| Schicht | Was sie abdeckt | Verwandter Bereich |
|---|---|---|
| Modelle | Laufzeiten, Serving, GPU-Setup | LLM-Hosting · LLM-Leistung |
| Architektur | Routing, Kosten, Sicherheitsvorkehrungen (Guardrails), Orchestrierung | Sie sind hier |
| Anwendungen | KI-Assistenten, RAG-Pipelines, Agenten | KI-Systeme · RAG |
Die Architekturschicht wird oft frühzeitig übersprungen. Sie wird essentiell, wenn Sie mehr als ein Modell, mehr als einen Aufgabentyp oder mehr als einen Benutzer haben. Jedes Architekturmuster in diesem Cluster existiert, weil „ein Modell für alles“ nicht mehr funktioniert hat.
Cluster-Karte
Die fünf Themen in diesem Cluster bauen aufeinander auf. Lesen Sie in dieser Reihenfolge für den logischsten Pfad:
- Sie sind hier — diese Säule: Was LLM-Architektur ist, wie die Teile zusammenpassen
- Prompts — Schreiben effektiver Prompts für LLMs — das Fundament: Formung dessen, was das Modell empfängt
- Routing — Model-Routing-Strategien — der Disponent: Welches Modell bearbeitet was
- Kosten — Kostenoptimierung für LLM-Systeme — Token-Budgetierung, Caching, lokale vs. API-Wirtschaftlichkeit
- Sicherheit — LLM-Guardrails in der Praxis — Eingabevalidierung, Ausgabeprüfung, Compliance
- Orchestrierung — Design von Multi-Model-Systemen — sequenzielle, parallele, hierarchische, Ensemble-Muster
Wenn Sie nur Zeit für eines haben, beginnen Sie mit dem Routing. Es ist der Entscheidungspunkt, an dem die Architektur beginnt.
Prompt-Engineering
Prompt-Engineering ist die Schicht, die dem Modell am nächsten ist. Vor dem Routing, vor dem Caching, vor den Guardrails — da ist der Prompt. Was Sie an das Modell senden, bestimmt, was Sie zurückbekommen.
Die praktischen Techniken, die wichtig sind:
- Klarheit und Struktur — klare Anweisungen übertreffen clevere Rahmenbedingungen
- Spezifische Beispiele — Few-Shot-Beispiele verankern das Modellverhalten
- Rollenvergabe — rollenbasierte Prompts schärfen Tonfall und Einschränkungen
- Verschiedene Ansätze — unterschiedliche Formate zeigen, worauf das Modell anspricht
- Kontextmanagement — was Sie einbeziehen, formt, was das Modell gewichtet
Prompt-Engineering ist keine einmalige Aufgabe. Es ist eine kontinuierliche Kalibrierung zwischen Ihren Anforderungen an die Aufgabe und dem Verhalten des Modells.
Vertiefung:
- Schreiben effektiver Prompts für LLMs — praktische Techniken für die Leistung von Sprachmodellen
Model-Routing
Eine Routing-Schicht entscheidet, welches Modell welche Anfrage bearbeitet. Ohne sie geht jede Anfrage an dasselbe Modell — oft zu groß für einfache Aufgaben, zu klein für komplexe.
Vier Routing-Strategien decken die meisten Produktionsfälle ab:
| Strategie | Optimieren für | Am besten, wenn |
|---|---|---|
| Fähigkeitsbasiert | Aufgabenqualität | Workloads mit gemischter Komplexität |
| Kostenbewusst | Token-Ausgaben | Budgetbeschränkte Systeme |
| Latenzbewusst | Antwortzeit | Interaktive Tools und Echtzeit-Chat |
| Hybrid | Alle drei | Produktionsysteme mit realen Einschränkungen |
Eine Fallback-Kette behandelt Fehler: Ordnen Sie Modelle vom besten zum zuverlässigsten, enden Sie mit einem lokalen Modell, das nicht rate-limitiert oder durch einen API-Ausfall abgeschaltet werden kann.
Vertiefung:
- Model-Routing-Strategien: Lokal vs. API, Kostenbewusst, Latenzbewusst — fähigkeitsbasiertes, kostenbewusstes und latenzbewusstes Routing mit Python-Code
Kostenoptimierung
LLM-Kosten skalieren linear mit der Nutzung. Die Strategien, die die Rechnung tatsächlich reduzieren:
Token-Budgetierung setzt Limits pro Sitzung, pro Aufgabe oder adaptiv. Adaptive Budgets verfolgen die tatsächliche Nutzung und verschärfen die Zuordnungen im Laufe der Zeit.
Lokale Inferenz verändert die Kostenstruktur vollständig. Nach der Amortisation der Hardware laufen lokale Modelle zu Stromkosten. Eine GPU bei moderater Auslastung zahlt sich innerhalb von Monaten zurück.
Caching ist die am meisten unterschätzte Optimierung. Exact-Match-Caching fängt wiederholte Prompts ab. Semantisches Caching fängt Prompts ab, die dasselbe bedeuten. Für Systeme mit hohem Verkehrsaufkommen eliminiert semantisches Caching einen großen Teil der API-Aufrufe, bevor sie erfolgen.
Fallback-Ketten reduzieren die durchschnittlichen Kosten pro Anfrage: Bevorzugen Sie teure Modelle, wenn das Budget es zulässt, und greifen Sie im Fortschritt der Sitzung auf günstigere oder lokale zurück.
Vertiefung:
- Kostenoptimierung für LLM-Systeme: Token-Budgetierung, Fallback-Modelle, Caching — reale Hardware-Zahlen, Break-even-Tabellen und funktionierende Python-Muster
Guardrails (Sicherheitsvorkehrungen)
LLMs sind standardmäßig unvorhersehbar. Guardrails begrenzen, was hineingeht und was herauskommt — ohne die Modellkapazität zu entfernen.
Drei Guardrail-Schichten sind in der Praxis wichtig:
Eingabevalidierung stoppt Probleme, bevor sie das Modell erreichen. Prompt-Sanitisierung fängt Injektionsversuche ab. Längengrenzen verhindern Token-Verbrauch. Content-Filter blockieren Verstöße gegen Richtlinien, bevor Inferenz etwas kostet.
Ausgebeprüfung fängt Probleme nach der Generierung ab. Strukturierte Validierung stellt erwartete Antwortformen sicher. Content-Checks blockieren schädliche Ausgaben. Faktenchecks (für kritische Domänen) validieren Behauptungen gegen eine Wissensdatenbank.
Sicherheitsmechanismen schützen das System über die Zeit: Rate-Limiting verhindert Missbrauch, Token-Budgets begrenzen die Kosten pro Anfrage, Context-Window-Management verhindert Überlauf und Datenlecks über Turns hinweg.
Für compliance-lastige Systeme (GDPR, HIPAA, SOC 2) fügen Sie Audit-Logging mit strukturierten, nur anhängenden Einträgen und Data-Residency-Kontrollen hinzu.
Vertiefung:
- LLM-Guardrails in der Praxis: Eingabevalidierung, Ausgabeprüfung, Sicherheit — praktische Guardrail-Muster und Compliance-Hinweise
Design von Multi-Model-Systemen
Wenn ein einzelnes Modell nicht ausreicht, lautet die Architekturfrage: Wie orchestrieren Sie mehrere Modelle, ohne eine Komplexität zu schaffen, die mehr kostet, als sie spart?
Fünf Muster decken den Raum ab:
| Muster | Latenz | Kosten | Qualität | Nutzen, wenn |
|---|---|---|---|---|
| Einzelnes Modell | Niedrigste | Niedrigste | Variabel | Prototyping, einheitliche Workloads |
| Sequenziell (Pipeline) | Hoch | Mittel | Hoch | Mehrstufige Workflows mit Spezialisierung |
| Parallel (Fan-Out) | Niedrig | Hoch | Hoch | Unabhängige Aufgaben, A/B-Tests |
| Hierarchisch (Planner-Executor) | Hoch | Hoch | Höchste | Komplexe Reasoning mit spezialisierter Ausführung |
| Ensemble | Mittel | Höchste | Höchste | Kritische Entscheidungen, die Konsens erfordern |
Die Daumenregel: Beginnen Sie mit dem einfachsten Muster, das Ihre tatsächlichen Einschränkungen bewältigt. Die meisten Produktionsysteme erreichen erst parallele oder hierarchische Strukturen, wenn fähigkeitsbasiertes Routing allein nicht mehr ausreicht.
Vertiefung:
- Design von Multi-Model-Systemen: Wann welches Modell und warum — alle fünf Muster mit funktionierendem Python-Code und Abwägungstabellen
Architektur-Entscheidungsrahmen
Verwenden Sie dies als schnelle Triage dafür, was hinzugefügt werden soll und wann:
| Problem | Lösung | Wann hinzufügen |
|---|---|---|
| Rechnung ist zu hoch | Kostenbewusstes Routing, Caching, lokale Inferenz | Wenn API-Kosten zu einer echten Budgetposition werden |
| Latenz ist zu hoch | Latenzbewusstes Routing, kleinere Modelle | Wenn Benutzer Langsamkeit bemerken |
| Qualität ist inkonsistent | Fähigkeitsbasiertes Routing, Fallback-Kette | Wenn einfache Aufgaben teure Modelle bekommen oder komplexe Aufgaben günstige |
| Benutzer missbrauchen das System | Eingabevalidierung, Rate-Limiting | Wenn Sie Zugriff über ein vertrauenswürdiges Team hinaus öffnen |
| Antworten sind unsicher oder verstoßen gegen Richtlinien | Ausgabeprüfung, Content-Guardrails | Wenn Sie allgemeine Benutzer bedienen |
| Ein Modell bearbeitet alles | Multi-Model-Design | Wenn Workloads genug divergieren, um die Komplexität zu rechtfertigen |
| Prompts funktionieren nicht | Prompt-Engineering-Iteration | Immer — Prompts benötigen Anpassung, da sich Aufgaben entwickeln |
Bauen Sie Architektur von unten nach oben. Prompt-Engineering ist immer im Fokus. Fügen Sie Routing hinzu, wenn die Kosten/Qualitäts-Abwägungen real werden. Fügen Sie Guardrails hinzu, wenn Sie externe Benutzer bedienen. Fügen Sie Multi-Model-Orchestrierung zuletzt hinzu.
Wie LLM-Architektur mit den anderen Themen zusammenhängt
LLM-Architektur liegt an der Schnittstelle mehrerer verwandter Cluster:
Infrastruktur (unterhalb dieser Schicht):
- LLM-Hosting 2026: Lokal, selbst gehostet und Cloud-Infrastruktur im Vergleich — Laufzeiten (Ollama, llama.cpp, vLLM), Hardware und Serving-Entscheidungen. Architekturmuster hängen davon ab, welche Infrastruktur verfügbar ist. Kostenbewusstes Routing ergibt nur Sinn, wenn Sie sowohl lokale als auch API-Modelle laufen haben.
- LLM-Leistung 2026: Benchmarks, Engpässe und Optimierung — Latenzzahlen, VRAM-Grenzen, Throughput-Messungen. Dies sind die empirischen Eingaben für Routing- und Modellauswahlentscheidungen.
Anwendungsschichten (oberhalb dieser Schicht):
- KI-Systeme: Selbst gehostete Assistenten, RAG und lokale Infrastruktur — die Systeme, die Routing-, Guardrail- und Orchestrierungsentscheidungen verbrauchen. Multi-Model-Architektur ist eine Voraussetzung für produktionsreife KI-Assistenten.
- Retrieval-Augmented Generation (RAG) Tutorial — RAG ist selbst ein Architekturmuster: Eine Retrieval-Pipeline, die Kontext in ein LLM einspeist. Die Routing-, Kosten- und Guardrail-Muster aus diesem Cluster gelten auch innerhalb von RAG-Pipelines.
Operative Schicht:
- Observability: Monitoring, Metriken, Prometheus und Grafana Guide — Produktions-LLM-Architektur benötigt Observability. Kostenverfolgung, Latenzmonitoring und Guardrail-Verletzungsmetriken erfordern Instrumentierung auf der Architekturschicht, nicht nur auf der Infrastrukturschicht.
