LLM-Architektur: Systemdesign für KI in der Produktion
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 tatsächlich mit einer Anfrage 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 keiner Architektur. Das ist für die Prototypenentwicklung korrekt. In der Produktion wird es jedoch zu einer Schwachstelle.
LLM-Architektur umfasst die Designentscheidungen, die „ein aufrufbares Modell“ in „ein zuverlässiges System“ verwandeln.
Wo LLM-Architektur im Stack sitzt
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, Sicherheitsgrenzen (Guardrails), Orchestrierung | Sie sind hier |
| Anwendungen | KI-Assistenten, RAG-Pipelines, Agenten | KI-Systeme · RAG |
Die Architekturschicht wird oft am Anfang übersprungen. Sie wird essentiell, wenn Sie mehr als ein Modell, mehr als eine Art von Aufgabe oder mehr als einen Benutzer haben. Jedes Architekturmuster in diesem Cluster existiert, weil der Ansatz „ein Modell für alles“ nicht mehr funktioniert hat.
Cluster-Karte
Die fünf Themen in diesem Cluster bauen aufeinander auf. Lesen Sie sie in dieser Reihenfolge für den logischsten Pfad:
- Sie sind hier — dieser Pfeiler: Was LLM-Architektur ist, wie die Teile zusammenpassen
- Prompts — Schreiben wirksamer Prompts für LLMs — das Fundament: das Formen dessen, was das Modell erhält
- Routing — Strategien zum Modell-Routing — der Disponent: Welches Modell bearbeitet was
- Kosten — Kostensenkung für LLM-Systeme — Token-Budgetierung, Caching, lokale vs. API-Wirtschaftlichkeit
- Sicherheit — LLM-Sicherheitsgrenzen (Guardrails) in der Praxis — Eingabevalidierung, Ausgabe-Filterung, Compliance
- Orchestrierung — Design von Multi-Model-Systemen — sequenzielle, parallele, hierarchische und 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 kommt. Vor dem Routing, vor dem Caching, vor den Sicherheitsgrenzen — da ist der Prompt. Was Sie an das Modell senden, bestimmt, was Sie zurückbekommen.
Die praktischen Techniken, die zählen:
- Klarheit und Struktur — klare Anweisungen sind besser als clevere Rahmenbedingungen
- Spezifische Beispiele — Few-Shot-Beispiele verankern das Modellverhalten
- Rollenzuweisung — rollenbasierte Prompts schärfen Tonfall und Einschränkungen
- Verschiedene Ansätze — unterschiedliche Formate zeigen, worauf das Modell reagiert
- Kontextverwaltung — was Sie einbeziehen, bestimmt, was das Modell gewichtet
Prompt-Engineering ist keine einmalige Aufgabe. Es ist eine fortlaufende Kalibrierung zwischen Ihren Aufgabenanforderungen und dem Verhalten des Modells.
Tiefenanalyse:
- Schreiben wirksamer Prompts für LLMs — praktische Techniken für die Leistung von Sprachmodellen
Modell-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 | Optimiert 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 | Produktionssysteme mit realen Einschränkungen |
Eine Fallback-Kette behandelt Fehler: Ordnen Sie Modelle vom besten bis zum zuverlässigsten an, endend mit einem lokalen Modell, das nicht durch Rate-Limiting oder einen API-Ausfall abgeschaltet werden kann.
Tiefenanalyse:
- Strategien zum Modell-Routing: Lokal vs. API, Kostenbewusst, Latenzbewusst — fähigkeitsbasiertes, kostenbewusstes und latenzbewusstes Routing mit Python-Code
Kostensenkung
LLM-Kosten skalieren linear mit der Nutzung. Die Strategien, die die Rechnung tatsächlich reduzieren:
Token-Budgetierung setzt Limits pro Sitzung, pro Aufgabe oder adaptive Limits. Adaptive Budgets verfolgen die tatsächliche Nutzung und verschärfen die Zuweisungen im Laufe der Zeit.
Lokale Inferenz ändert die Kostenstruktur vollständig. Nach der Amortisierung der Hardware laufen lokale Modelle zu Stromkosten. Eine GPU bei moderater Auslastung amortisiert sich innerhalb von Monaten.
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 Anteil der API-Aufrufe, bevor sie stattfinden.
Fallback-Ketten reduzieren die durchschnittlichen Kosten pro Anfrage: Bevorzugen Sie teure Modelle, wenn das Budget es erlaubt, und wechseln Sie im Fortgang der Sitzung auf günstigere oder lokale Modelle.
Tiefenanalyse:
- Kostensenkung für LLM-Systeme: Token-Budgetierung, Fallback-Modelle, Caching — reale Hardwarezahlen, Break-Even-Tabellen und funktionierende Python-Muster
Sicherheitsgrenzen (Guardrails)
LLMs sind standardmäßig unvorhersehbar. Sicherheitsgrenzen (Guardrails) begrenzen, was hineingeht und was herauskommt — ohne die Modellfähigkeiten zu entfernen.
Drei Schichten von Sicherheitsgrenzen sind in der Praxis wichtig:
Eingabevalidierung stoppt Probleme, bevor sie das Modell erreichen. Prompt-Sanitisierung fängt Injektionsversuche ab. Längenlimits verhindern Token-Verbrauch. Content-Filter blockieren Verstöße gegen Richtlinien, bevor die Inferenz Kosten verursacht.
Ausgabe-Filterung fängt Probleme nach der Generierung ab. Strukturierte Validierung stellt sicher, dass die erwarteten Antwortformen eingehalten werden. Content-Checks blockieren schädliche Ausgaben. Faktenchecks (für kritische Domänen) validieren Behauptungen gegenüber einer Wissensdatenbank.
Sicherheitsmechanismen schützen das System über die Zeit: Rate-Limiting verhindert Missbrauch, Token-Budgets begrenzen die Kosten pro Anfrage, das Management des Kontextfensters verhindert Überlauf und Datenlecks über mehrere Runden hinweg.
Für Compliance-lastige Systeme (GDPR, HIPAA, SOC 2) fügen Sie Audit-Logging mit strukturierten, nur-anhängenden Einträgen und Datenresidenz-Steuerungen hinzu.
Sicherheitsgrenzen steuern die Modellkonversation, aber sobald Agenten Tools aufrufen und Arbeit an andere Agenten delegieren, wird eine zweite Sicherheitsschicht notwendig: Wer darf handeln, in wessen Namen und mit welchem Audit-Trail? Das ist Protokollsicherheit statt Modell-I/O-Filterung.
Tiefenanalysen:
- LLM-Sicherheitsgrenzen in der Praxis: Eingabevalidierung, Ausgabe-Filterung, Sicherheit — praktische Muster für Sicherheitsgrenzen und Compliance-Hinweise
- A2A- und MCP-Agentensicherheit: Identität, Delegation und Audit-Trails — Agenten-Protokollsicherheit jenseits von Prompt-Sicherheit: Identität, Autorisierung, Gateways und Delegationskontrollen
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 | Verwenden, wenn |
|---|---|---|---|---|
| Einzelnes Modell | Niedrigst | Niedrigst | 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 (Planer-Ausführer) | Hoch | Hoch | Höchst | Komplexes Reasoning mit spezialisierten Ausführungen |
| Ensemble | Mittel | Höchst | Höchst | Kritische Entscheidungen, die Konsens erfordern |
Daumenregel: Beginnen Sie mit dem einfachsten Muster, das Ihre tatsächlichen Einschränkungen bewältigt. Die meisten Produktionssysteme erreichen erst dann parallel oder hierarchisch, wenn fähigkeitsbasiertes Routing allein nicht mehr ausreicht.
Tiefenanalyse:
- 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 für das, 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 Budgetlinie 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 erhalten oder komplexe Aufgaben billige |
| Benutzer missbrauchen das System | Eingabevalidierung, Rate-Limiting | Wenn Sie den Zugriff über ein vertrauenswürdiges Team hinaus öffnen |
| Antworten sind unsicher oder nicht konform | Ausgabe-Filterung, Content-Guardrails | Wenn Sie allgemeine Benutzer bedienen |
| Ein Modell erledigt alles | Multi-Model-Design | Wenn Workloads genug divergieren, um die Komplexität zu rechtfertigen |
| Prompts funktionieren nicht | Prompt-Engineering-Iteration | Immer — Prompts müssen angepasst werden, 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 Sicherheitsgrenzen hinzu, wenn Sie externe Benutzer bedienen. Fügen Sie Multi-Model-Orchestrierung zuletzt hinzu.
Wie LLM-Architektur mit anderen Themen zusammenhängt
LLM-Architektur befindet sich an der Schnittstelle mehrerer verwandter Cluster:
Infrastruktur (unterhalb dieser Schicht):
- LLM-Hosting 2026: Lokale, selbstgehostete 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 macht nur Sinn, wenn sowohl lokale als auch API-Modelle laufen.
- LLM-Leistung 2026: Benchmarks, Engpässe und Optimierung — Latenzzahlen, VRAM-Limits, Durchsatzmessungen. Dies sind die empirischen Eingaben für Routing- und Modellauswahlentscheidungen.
Anwendungsschichten (oberhalb dieser Schicht):
- KI-Systeme: Selbstgehostete Assistenten, RAG und lokale Infrastruktur — die Systeme, die Routing-, Guardrail- und Orchestrierungsentscheidungen verbrauchen. Multi-Model-Architektur ist eine Voraussetzung für KI-Assistenten in der Produktion.
- Retrieval-Augmented Generation (RAG) Tutorial — RAG ist selbst ein Architekturmuster: Eine Retrieval-Pipeline, die Kontext in ein LLM speist. Die Routing-, Kosten- und Guardrail-Muster aus diesem Cluster gelten auch innerhalb von RAG-Pipelines.
Operationsschicht:
- Observability: Monitoring, Metriken, Prometheus und Grafana Guide — Produktions-LLM-Architektur benötigt Observability. Kostenverfolgung, Latenzmonitoring und Guardrail-Verstoßmetriken erfordern Instrumentierung auf der Architekturschicht, nicht nur auf der Infrastrukturschicht.
