Der LLM-Stack 2026: Modelle, Inferenz, Tooling und Zielkonflikte

Wenn Sie 2026 reale KI-Produkte entwickeln, fragen Sie nicht mehr nur: „Soll ich OpenAI oder Anthropic verwenden?“ Diese Perspektive ist seit zwei Jahren überholt. Sie treffen Dutzende Entscheidungen in einem mehrschichtigen Stack, und die meisten davon sind relevant.

Dieser Artikel zeigt den LLM-Stack 2026 aus der Praxisperspektive eines Architekten: die Bestandteile jeder Schicht, die jeweiligen Zielkonflikte und die Entwicklungsrichtung des Marktes. Diesen Überblick hätten wir gern gehabt, bevor wir jeden vermeidbaren Fehler selbst gemacht haben.

Die Schichten

Der Stack, grob:

┌────────────────────────────────────┐
│       Application Layer            │  Your product / agent / workflow
├────────────────────────────────────┤
│   Orchestration / Frameworks       │  LangGraph, CrewAI, custom, direct
├────────────────────────────────────┤
│   Prompt + Context Management      │  Prompt templates, context engineering
├────────────────────────────────────┤
│   Retrieval / Memory               │  RAG, vector stores, structured memory
├────────────────────────────────────┤
│   Tool / MCP Layer                 │  Tool calling, MCP servers, function APIs
├────────────────────────────────────┤
│   Model Layer                      │  Specific model selection, routing
├────────────────────────────────────┤
│   Inference Layer                  │  Hosted APIs, self-hosted, edge
├────────────────────────────────────┤
│   Observability / Evals            │  Logging, tracing, eval suites
└────────────────────────────────────┘

Jede Schicht bietet mehrere tragfähige Optionen. Eine Entscheidung auf einer Schicht begrenzt die Möglichkeiten auf anderen. Frühe Entscheidungen lassen sich nur schwer rückgängig machen: Die Modellwahl beeinflusst die Inferenzoptionen und diese wiederum die Orchestrierung.

Wir werden jede Schicht einzeln betrachten.

Schicht 1: Modelle

Modelle lassen sich 2026 grob in Leistungsklassen einteilen. Die Auswahl ist die folgenreichste Einzelentscheidung für jeden Aufruf.

Spitzenklassen für Reasoning. Dazu zählen die Denkmodi aktueller Spitzenmodelle – GPT-5.5 mit Reasoning, Claude Opus 4.8 mit adaptivem Denken und Gemini 3.1 Pro Thinking – sowie spezielle Reasoning-Modelle wie DeepSeek R1. Sie eignen sich hervorragend für mehrstufige Probleme, Mathematik, Code und komplexe Analysen, sind aber teuer ($3–30 pro Million Eingabetoken, Ausgaben deutlich teurer) und langsam (5–60 Sekunden). Setzen Sie sie ein, wenn die Reasoning-Qualität den Engpass bildet.

Flaggschiff-Allzweckmodelle. GPT-5.5, Claude Sonnet 5, Gemini 3.1 Pro. Ausgezeichnet für die meisten Wissensarbeiten, schnell (2–5 Sekunden), moderat teuer ($2–5 pro Million Eingabetoken). Die Standardauswahl für hochwertige Nutzerinteraktionen.

Modelle der mittleren Klasse. Claude Haiku 4.5, Gemini 3.5 Flash und OpenAIs mittlere Modellklasse. Gut für einfache bis mittelschwere Aufgaben, schnell (1–2 Sekunden) und günstig ($1–2.50 pro Million Eingabetoken). Im Produktivbetrieb werden sie häufig für Klassifizierung, Extraktion und einfache Generierung eingesetzt.

Kleine und kostengünstige Modelle. Die derzeit kleinsten Klassen der Anbieter (z. B. Gemini 3 Flash Preview) sowie kleine Open-Source-Modelle. Sie genügen für eng umrissene strukturierte Aufgaben, sind sehr günstig ($0.50–1 pro Million Eingabetoken) und sehr schnell (<1 Sekunde). Verwenden Sie sie für Routing, Scoring und Batch-Verarbeitung.

(Listenpreise überprüft am 2026-07-07 gegen Anbieterpreisseiten; Schichten ändern sich — prüfen Sie vor der Preisangabe erneut.)

Spezialisierte Modelle. Embedding-, Reranking-, Bildverarbeitungs-, Sprach- und Code-Modelle sind bei ihrer jeweiligen Aufgabe günstiger als Allzweckmodelle und meist leistungsfähiger. Ziehen Sie sie für passende Aufgaben stets in Betracht.

Open-Source-Spitzenmodelle. Llama 4, DeepSeek V3 / R2, Qwen 3 und Mistral Large laufen bei Inferenzanbietern wie Groq, Together und Fireworks oder selbst gehostet. Preis und Qualität sind bei vielen Aufgaben mit proprietären Spitzenmodellen konkurrenzfähig; bei manchen Aufgaben liegen sie zurück, insbesondere beim Reasoning über einen langen Zeithorizont.

Die Implikationen:

• Ein Modell passt nicht zu allen Aufrufen in Ihrem System. Routing ist zwingend für Kosten (siehe Schicht 1).
• Die Leistungsgrenze verschiebt sich jedes Quartal. Bauen Sie für austauschbare Modelle statt für Lock-in.
• Open Source ist inzwischen für viele produktive Anwendungsfälle wirklich tragfähig, nicht nur für Experimente.

Schicht 2: Die Inferenzschicht

Wo läuft Ihr Modell tatsächlich?

Anbieter proprietärer APIs – OpenAI, Anthropic und Google. Der schnellste Weg in den Betrieb, mit den besten Modellen und hoher Zuverlässigkeit. Dafür zahlen Sie einen Aufpreis und akzeptieren das jeweilige Daten- und Sicherheitsmodell.

Open-Source-Inferenzanbieter – Groq, Together AI, Fireworks und Replicate. Sie betreiben offene Modelle mit unterschiedlichen Optimierungen, häufig wesentlich schneller als beim Selbsthosting und zu konkurrenzfähigen Preisen. Dieser Markt konsolidiert sich schnell; mehrere Anbieter aus dem Jahr 2024 existieren nicht mehr. Prüfen Sie jeden Anbieter vor einer langfristigen Bindung.

Cloud-native – AWS Bedrock, Azure OpenAI und Google Vertex. Sie verbinden proprietäre und offene Modelle mit Authentifizierung, Abrechnung und Compliance Ihrer Cloud. In vielen Enterprise-Umgebungen ist dies erforderlich.

Selbstgehostet — vLLM, TGI, SGLang, LMDeploy auf Ihren eigenen GPUs. Niedrigste Kosten pro Token bei Skalierung. Höchste operative Komplexität. Meist nur dann sinnvoll, wenn Ihre Inferenzkosten im hohen einstelligen €K/Monat-Bereich liegen (siehe den Artikel „Selbstgehostet vs. gehostet“ für die Break-even-Rechnung).

Edge / on-device — Apple Intelligence, MediaPipe, ONNX, GGUF-Modelle über Ollama oder llama.cpp. Kostenlos pro Aufruf, aber eingeschränkte Modellkapazität. Immer mehr für eng umrissene Anwendungsfälle umsetzbar.

Die Kompromisse:

• Latenz zählt: Sprachagenten und dialogorientierte UX benötigen eine kurze Zeit bis zum ersten Token. Groq, Cerebras und On-Device-Inferenz sind hier führend.
• Durchsatz zählt für Batch: Wenn Sie Millionen von Datensätzen verarbeiten, benötigen Sie hohen Durchsatz, nicht niedrige Latenz.
• Compliance zählt: DSGVO, HIPAA und SOC 2 bestimmen häufig, welche Anbieter und Regionen Sie nutzen können.
• Anbieterrisiko zählt: Die Abhängigkeit von nur einem Anbieter schafft einen Single Point of Failure. Mehrere Anbieter sind eine sinnvolle Grundabsicherung.

Ein gängiges Muster im Jahr 2026: gehostete proprietäre Modelle für Nutzerinteraktionen mit höchsten Qualitätsanforderungen, gehostete offene Modelle für hohe Volumina und niedrigere Kosten sowie On-Device-Modelle für eng umrissene, latenzkritische Funktionen. Self-Hosting nur, wenn Skalierung und Wirtschaftlichkeit den betrieblichen Aufwand rechtfertigen.

Schicht 3: Tools und MCP

LLMs allein können nicht viel. Sie werden nützlich, wenn sie Tools aufrufen — Funktionen, die Sie definieren und die ihnen Zugriff auf Daten, APIs und Aktionen ermöglichen.

Natives Function Calling. Jedes große Modell unterstützt eine strukturierte API für Funktionsaufrufe. Sie definieren Funktionen mit JSON-Schemata; das Modell entscheidet, wann es sie aufruft; Sie führen den Aufruf aus und geben die Ergebnisse zurück.

MCP (Model Context Protocol). Ein standardisiertes Protokoll (eingeführt von Anthropic, jetzt weit verbreitet, einschließlich OpenAI, Cursor und anderen) für Toolserver. Ein MCP-Server stellt Tools bereit; ein MCP-Client (ein LLM-Agent) verbindet sich und verwendet sie. Trennt die Umsetzung von Tools von jedem spezifischen Modell.

Direkte Integrationen. Bei hohen Volumina in spezifischen Anwendungsfällen (z. B. ein bestimmtes CRM oder eine bestimmte Datenbank) ist ein direkter Adapter häufig einfacher als ein generischer MCP-Server.

Der Trend 2026 ist klar: MCP setzt sich als Standard durch. Die meisten neuen Tools sollten MCP unterstützen. Direkte Integrationen bleiben für leistungskritische Pfade sinnvoll.

Einige Realitäten der Implementierung:

• Toolbeschreibungen zählen enorm. Eine schlecht beschriebene Funktion wird nicht korrekt verwendet. Tool-Dokumentationen sollten wie Prompts geschrieben werden.
• Die Anzahl der Tools zählt. Modelle mit mehr als 50 verfügbaren Tools schneiden schlechter ab als Modelle mit 5–10 relevanten Tools. Kuratieren Sie konsequent.
• Fehlerbehandlung zählt. Toolfehler müssen dem Modell in strukturierter Weise mitgeteilt werden, damit es sich anpassen kann.
• Autorisierung ist anspruchsvoll. Ein Mehrbenutzersystem, in dem das LLM je nach Nutzer unterschiedliche Berechtigungen hat, ist nicht trivial. Lassen Sie das LLM niemals über Berechtigungen entscheiden; erzwingen Sie sie im Tool-Wrapper.

Schicht 4: Retrieval und Memory

LLMs benötigen Daten, auf die sie nicht trainiert wurden. Dies ist die Retrievalschicht.

Vektordatenbanken. Pinecone, Weaviate, Qdrant, Chroma, PostgreSQL mit pgvector, Turbopuffer. Sie speichern Embeddings und bedienen Nearest-Neighbor-Abfragen. Die Technologie ist ausgereift und gut verstanden – der Standard für semantisches Retrieval.

Hybride Suche. Kombiniert Vektorsuche mit traditioneller BM25-Schlüsselwortsuche. Erfasst sowohl semantische als auch lexikalische Übereinstimmungen. Verwenden Sie Reciprocal Rank Fusion, um sie zu kombinieren. Tools: Elasticsearch, OpenSearch, Vespa.

Wissensgraphen. Neo4j, Memgraph, individuelle Triple Stores. Für Daten mit vielfältigen Beziehungen. Sie kommen in Graph-RAG-Architekturen zum Einsatz. Der Aufbau ist aufwendiger, liefert in beziehungsreichen Domänen aber oft eine höhere Qualität.

Spezialisierte RAG-Plattformen. LlamaIndex (inzwischen ausgereift), RAG-Abstraktionen von LangChain, Haystack. Übergeordnete Frameworks für gängige Muster.

Reranking. Cohere Rerank, Voyage, individuelle Cross-Encoder. Nach dem ersten Retrieval werden die besten Kandidaten mit einem leistungsfähigeren Modell erneut bewertet, um die Genauigkeit zu erhöhen. Üblicherweise verbessert dies die Retrieval-Qualität um den Faktor 2–3.

Memory. Für Agenten und Konversationen: strukturierte Memory-Schichten – Mem0, Letta (früher MemGPT) oder individuelle Lösungen. Unterscheiden Sie zwischen kurzfristigem Memory (aktuelle Konversation), mittelfristigem Memory (kürzlich besprochene Themen) und langfristigem Memory (dauerhafte Fakten über den Nutzer oder das Konto).

Die architektonische Frage: Wo liegt diese Schicht?

• In der Anwendung: Der LLM-Aufruf wird von einer durch Ihr Team entwickelten Retrieval-Logik umschlossen.
• Auf der MCP-Schicht: Retrieval wird als Tools bereitgestellt.
• Als Service: Ihre Anwendungen rufen einen dedizierten Retrieval-Service auf.

Für monolithische Systeme mit nur einem Produkt ist die Integration in der Anwendung ausreichend. Bei Organisationen mit mehreren Produkten zahlt sich Retrieval als Service aus – mit einheitlicher Qualität und einheitlichen Richtlinien.

Schicht 5: Prompt- und Kontextengineering

2026 ist „Prompt Engineering“ weitgehend gleichbedeutend mit „Context Engineering“ – also der Steuerung dessen, was bei jedem Aufruf in das Kontextfenster gelangt.

Die Komponenten:

Prompts. Häufig als Vorlagen mit Variablen angelegt. In der Versionsverwaltung gespeichert. Mit Eval-Suiten getestet. Wie Code behandelt.

Prompt-Management. Tools wie Promptfoo, Langfuse, PromptLayer oder interne Systeme. Versionierung, A/B-Tests, Rollbacks. (Helicone und ähnliche LLM-Proxys gehören zur nachfolgenden Observability-Schicht, nicht hierher – beide Kategorien werden leicht verwechselt.)

Kontextstrategie. Entscheidungen darüber, was in jedem Aufruf enthalten sein soll:

• Systemprompt (stabil, definiert Verhalten).
• Abgerufenes Wissen (dynamisch, aus RAG).
• Konversationsverlauf (verwaltet, bei längeren Verläufen oft zusammengefasst).
• Few-shot-Beispiele (dynamisch basierend auf der Abfrage gewählt).
• Toolbeschreibungen (nur relevanten Tools gefiltert).
• Die aktuelle Abfrage des Nutzers.

Kontextkompression. Mit zunehmender Kontextlänge lässt die Modellleistung nach. Strategien: ältere Gesprächsabschnitte zusammenfassen, Schlüsselfakten in ein strukturiertes Memory extrahieren und irrelevante Inhalte entfernen. Dies ist ein aktives Forschungsfeld.

Nutzung langer Kontexte. Kontextfenster mit 1 Mio. Token sind bei aktuellen Spitzenmodellen (Claude, GPT-5.5, Gemini) Standard. Sie funktionieren, doch „Context Rot“ ist real: Bei langen Eingaben nimmt die Qualität ab, auch wenn das Modell diese technisch unterstützt. Nutzen Sie lange Kontexte gezielt; laden Sie nicht alles, nur weil es möglich ist.

Schicht 6: Orchestrierung

Wie koordinieren Sie mehrschrittige LLM-Workflows und Agenten?

Direkte API. Schreiben Sie einfach die Schleife selbst in Python oder TypeScript. Bestes für einfache Fälle und um zu verstehen, was tatsächlich passiert.

LangChain / LangGraph. Weit verbreitet. LangGraph (eine Zustandsmaschine für Agenten) ist deutlich ausgereifter geworden. Umfangreiche Abstraktionen und eine Lernkurve, dafür leistungsfähig.

CrewAI. Multi-Agenten-Framework mit Schwerpunkt auf rollenbasierten Agenten. Einfacherer Einstieg als bei LangGraph, aber weniger flexibel.

LlamaIndex-Agenten. Besonders stark für RAG-lastige Workflows.

OpenAI Agents SDK. Einfacher, mit klareren Vorgaben und für OpenAI-Modelle optimiert.

Anthropic Claude SDK. Ähnlich; optimiert für Claude.

Individuelle Lösung. Bei erfahrenen Teams, die produktive Agenten bereitstellen, ist eine eigene Orchestrierung üblich. Frameworks verursachen Kosten – durch Abstraktionsaufwand, komplexeres Debugging und häufige Versionsänderungen –, die ihren Nutzen übersteigen können.

Ein typisches Muster für 2026: Prototypen entstehen in einem Framework, für den Produktivbetrieb wird die Lösung in individuellen Code überführt. Frameworks helfen Ihnen, die passenden Muster zu erkennen; sobald diese feststehen, ist direkter Code einfacher und zuverlässiger.

Schicht 7: Observability

Ohne Observability können Sie keine ernsthafte LLM-Anwendung produktiv bereitstellen. Jedes Produktivsystem benötigt:

Tracing. Jeder LLM-Aufruf wird erfasst: Zeitstempel, Modell, Eingabe, Ausgabe, Latenz, Kosten und Erfolg oder Fehler. Mehrstufige Abläufe werden als Trace-Bäume dargestellt.

Kostenverfolgung. Pro Aufruf, Funktion und Nutzer. Kosten können erheblich und nach oben offen sein; ohne Nachverfolgung bemerken Sie dies erst am Monatsende.

Qualitätsmonitoring. Automatisierte Qualitätsprüfungen anhand einer Stichprobe des Produktivverkehrs. Warnungen bei Qualitätsverlusten.

Erfassung von Nutzerfeedback. Daumen hoch oder runter, ausdrückliches Feedback und implizite Signale (Wiederholungsrate, Abbrüche).

Debuggen. Wenn etwas schiefgeht, müssen Sie die vollständige Aufrufkette sehen. Ein fehlgeschlagener Agentenlauf hat viele mögliche Fehlerpunkte.

Tools: LangSmith, Helicone, Arize, Phoenix, Braintrust, Weights & Biases, Datadog LLM Observability. Jedes hat unterschiedliche Stärken; wählen Sie eines früh und bleiben Sie dabei.

Für kleine Teams gilt: Selbst eine einfache PostgreSQL-Tabelle mit einer Zeile pro LLM-Aufruf liefert 80 % der benötigten Informationen. Wechseln Sie zu einem spezialisierten Tool, wenn Skalierung oder Funktionsumfang es rechtfertigen.

Schicht 8: Evals

Die wichtigste Schicht für ernsthafte Produktionsarbeit.

Offline-Evals. Definierte Datensätze, erwartete Ausgaben und Bewertung. Sie werden vor der Bereitstellung von Änderungen ausgeführt und erkennen Regressionen. (Wir haben dies auf der mittleren Stufe ausführlich behandelt.)

Online-Evals. Stichproben des Produktivverkehrs, automatisch bewertet (LLM-as-a-Judge) oder anhand von Nutzersignalen. Sie erkennen Drift.

Pre-Deployment-Evals. Vor jeder Änderung an Prompts oder Modellen wird die Eval-Suite ausgeführt und geprüft. Sie wird Bestandteil der CI.

Eval-Taxonomie. Unterschiedliche Evals für unterschiedliche Anliegen:

• Verhalten: Tut das System, was wir erwarten?
• Sicherheit: Weigert es sich, was wir ablehnen möchten?
• Qualität: Wie gut ist die Ausgabe?
• Robustheit: Wie geht es mit adversarialen Eingaben um?
• Kosten/Latenz: Sind wir im Budget?

Tools: Promptfoo, Braintrust, LangSmith, benutzerdefinierte Suiten. Alle haben einen Platz; Promptfoo ist der einfachste Start.

Schicht 9: Die Anwendungsschicht

Hier lebt Ihr spezifisches Produkt. Die Entscheidungen hier:

Agent vs. Workflow. Agenten (ein LLM in einer Schleife mit Tools) sind leistungsfähig, aber schwieriger zuverlässig zu gestalten. Workflows (eine feste Abfolge von LLM-Aufrufen) sind einfacher und häufig ausreichend. Verwenden Sie standardmäßig Workflows und greifen Sie nur dann auf Agenten zurück, wenn diese wirklich erforderlich sind.

Synchron vs. asynchron. Nutzerseitige Echtzeitverarbeitung? Hintergrund-Batches? Streaming? Dies beeinflusst Modellauswahl, Infrastruktur und UX-Design.

Single-Tenant vs. Multi-Tenant. Kundenspezifische Anforderungen an die Datenisolierung bestimmen wesentliche Architekturentscheidungen.

On-Premises vs. Cloud. Compliance, Sicherheit oder Kosten können eine On-Premises-Bereitstellung erforderlich machen. Die betriebliche Komplexität ist wesentlich höher.

Randfälle. Halluzinationen, Prompt Injection und Missbrauch. Produktivsysteme benötigen Schutzmechanismen. Stellen Sie sie nicht ohne diese bereit.

Relevante Zielkonflikte

Einige Kompromisse, die explizit erwähnenswert sind:

Qualität vs. Kosten vs. Latenz

Das grundlegende Dreieck. Sie können normalerweise zwei optimieren; der dritte wird schlechter.

• Hohe Qualität + geringe Latenz = teuer.
• Geringe Kosten + geringe Latenz = geringere Qualität.
• Hohe Qualität + geringe Kosten = hohe Latenz (Batchverarbeitung, oder Reasoning-Modelle).

Wählen Sie Ihre Prioritäten pro Aufgabe. Optimieren Sie nicht alle drei; dieser Weg führt zu Mittelmäßigkeit in allen.

Eigenentwicklung vs. Zukauf

Für jede Schicht können Sie bauen oder kaufen.

• Eigenentwicklung: mehr Kontrolle, mehr Wartung, höhere Kosten (Entwicklungszeit), differenzierende Fähigkeiten.
• Zukauf: schnellerer Start, weniger Kontrolle, dauerhaftes Anbieterrisiko, Auslagerung nicht differenzierender Fähigkeiten.

Eine gute Heuristik: Kaufen Sie Standardschichten (Vektorspeicher, grundlegende Observability) und entwickeln Sie differenzierende Schichten selbst (Ihre spezifische Orchestrierung, Ihre Prompts, Ihre Evals). Das Gegenteil – die eigene Differenzierung einzukaufen und Standardinfrastruktur selbst zu bauen – ist ein häufiger Fehler.

Open Source vs. proprietär

Eine Realität des Jahres 2026: Open-Source-Modelle sind bei vielen Aufgaben wettbewerbsfähig. Bei einigen sind sie besser – schneller und günstiger. Bei anderen, etwa Reasoning über einen langen Zeithorizont, liegen proprietäre Frontier-Modelle weiterhin vorn.

Die Entscheidungsfaktoren:

• Qualitätsanforderungen. Bei Spitzenleistungen für eine bestimmte Aufgabe gewinnen proprietäre Modelle weiterhin.
• Kosten bei Skalierung. Selbst gehostete Open-Source-Modelle werden bei hohem Volumen günstig.
• Datenschutz/Compliance. Für sensible Daten ist Self-Hosting in Ihrer Infrastruktur häufig erforderlich.
• Anpassung. Fine-Tuning und individuelles Training erfordern Open Source.
• Betriebliche Kapazität. Proprietäre APIs sind betrieblich unkompliziert; Self-Hosting verursacht erheblichen Aufwand.

Die meisten Produktivsysteme sind 2026 hybrid: proprietäre Modelle für einige Aufrufe, offene Modelle für andere – abhängig von der Abwägung je Aufruf.

Latenz vs. Reasoning-Tiefe

Reasoning-Stufen (GPT-5.5 Thinking, Claude mit Adaptive Thinking) tauschen bei schwierigen Problemen Latenz gegen Qualität. Manchmal lohnt sich das, manchmal kann der Nutzer keine 30 Sekunden warten.

Ein Muster: Leichte Abfragen an schnelle Modelle, schwere Abfragen an Reasoning-Modelle routen. Verwenden Sie einen Router (kleines Modell oder Heuristik), um zu entscheiden.

Langkontext vs. RAG

Sie können den Kontext in das Modell laden (über ein Kontextfenster mit einer Million Token) oder relevante Abschnitte per RAG abrufen.

• Langer Kontext: einfacher, keine Retrieval-Infrastruktur, aber teuer pro Aufruf – und „Context Rot“ ist real.
• RAG: günstiger pro Aufruf, mehr Aufwand, Retrieval-Qualität ist ein eigenes Engineering-Problem.

Die ausgereifte Antwort für 2026: in der Regel RAG für den Produktivbetrieb; lange Kontexte für Prototypen, besondere Einzelfälle oder Situationen, in denen die Retrieval-Qualität so schlecht ist, dass sie das Ergebnis beeinträchtigt.

Agenten vs. Workflows

Besprochen oben. Standard auf Workflows; verwenden Sie Agenten, wenn Sie wirklich Flexibilität benötigen. Viele „Agenten“-Systeme, die wir sehen, sollten Workflows sein.

Eine Referenzarchitektur für 2026

Um all dies greifbar zu machen, zeigt die folgende Darstellung ein typisches Produktivsystem für ein mittelgroßes SaaS-Produkt mit KI-Funktionen:

User → Application (React/Next.js)
    ↓
API gateway / auth
    ↓
LLM Service (your wrapper)
    ↓
  Router (small model or heuristic)
    ├→ Simple tasks: a mid-tier model (Claude Haiku 4.5 class)
    ├→ Standard tasks: Claude Sonnet 5 or GPT-5.5
    ├→ Hard tasks: Claude Opus 4.8 or a reasoning tier
    └→ Special: vision/voice/embedding specialists
    ↓
Tool layer (MCP servers + direct integrations)
    ↓
Retrieval layer (Pinecone + hybrid + reranker)
    ↓
Observability (Helicone or LangSmith)
    ↓
Eval suite (Promptfoo, runs in CI)

Kosten pro aktiven Nutzer/Monat: typischerweise €1–10 je nach Nutzungshäufigkeit. Engineering-Aufwand für die Umsetzung: 6–12 Wochen für ein erfahrenes Team. Betriebskosten: je nach Datenverkehr niedrig bis moderat.

Was häufig schiefgeht

Fehlermuster, die sich über Produktions-LLM-Stacks wiederholen:

Muster 1: Ein Modell für alles. Kostenüberschreitungen, Qualitätsschwierigkeiten. Lösung: Routing.

Muster 2: Keine Observability. Kein Debugging, keine Messung, keine Verbesserung. Lösung: frühzeitig instrumentieren.

Muster 3: Keine Evals. Qualitätsschwankungen werden nicht bemerkt. Lösung: Evals ab Tag 1.

Muster 4: Framework-Lock-in. Das Debugging von LangChain oder CrewAI wird zur Vollzeitbeschäftigung. Lösung: Nutzen Sie Frameworks nur, wenn sie mehr einsparen, als sie kosten. Überführen Sie die Lösung in direkten Code, sobald die Muster klar sind.

Muster 5: Infrastruktur selbst entwickeln, die eingekauft werden sollte. Eine individuelle Vektordatenbank? Wahrscheinlich Zeitverschwendung. Eine individuelle Observability-Lösung? Wahrscheinlich ebenfalls. Kaufen Sie die Standardschichten.

Muster 6: Infrastruktur einkaufen, die selbst entwickelt werden sollte. Prompts an Dritte auslagern. Evals auslagern. Beides bildet Ihren Wettbewerbsvorteil; behalten Sie die Kontrolle darüber.

Muster 7: Prompt Injection ignorieren. Ein Produktivsystem ohne Eingabebereinigung für nutzergenerierte Inhalte. Ein großes Risiko, das frühzeitig gemindert werden muss.

Muster 8: Agenten in hochriskanten Abläufen vertrauen. Ein LangGraph-Agent, der Rückerstattungen ohne menschliche Prüfung autorisiert. Das wird irgendwann schiefgehen. Binden Sie bei folgenreichen Aktionen einen Menschen in den Prozess ein.

Muster 9: Falsches Optimieren. Optimierung der Inferenzkosten, wenn die Gesamtkosten von Engineering-Zeit dominiert werden. Oder Optimierung der Latenz, wenn Nutzer sie nicht bemerken. Messen Sie, was tatsächlich zählt.

Muster 10: Kein Multi-Provider-Plan. Wenn – nicht falls – Ihr primärer Anbieter ausfällt, ist Ihr Dienst nicht verfügbar. Konfigurieren Sie einen Fallback.

Drei Wetten, datiert (prüfen Sie Mitte 2027)

Vorhersagen sind billig; datierte, falsifizierbare sind nicht. Drei, über die wir öffentlich falsch sein können:

1. In der EU gehostete Inferenz erreicht bis Mitte 2027 praktische Preisparität für Modelle der mittleren Leistungsklasse. EU-souveräne Kapazitäten gehen schnell in Betrieb, und der Preisaufschlag gegenüber Endpunkten in US-Regionen sinkt. Wird die Parität erreicht, ändert sich unsere Standardempfehlung für DSGVO-sensible Workloads von „hybrid mit Schwärzung“ zu „standardmäßig in der EU gehostet“. Konfidenz: mittel.

2. Die Framework-Schicht konsolidiert sich weiter; die Protokollschicht setzt sich durch. In den vergangenen 18 Monaten hat Microsoft seine beiden Agenten-Frameworks zusammengeführt und OpenAI sein eigenständiges Browser-Agenten-Produkt wieder in ChatGPT integriert, während MCP von einer Ankündigung zum anbieterübergreifenden Standard wurde. Wir konzentrieren den Integrationsaufwand auf Protokolle (MCP, strukturierte Ausgaben) und halten das Orchestrierungs-Framework austauschbar. Konfidenz: hoch.

3. Routing mit kleinen Modellen ist keine Optimierung mehr, sondern wird zur Standardarchitektur. Bleiben die Preise der Spitzenmodelle stabil, während sich kleine Modellstufen weiter verbessern, wird „Spitzenmodell für alles“ für einen Cloud Engineer so wirken wie „Bare Metal für alles“. Konfidenz: hoch für kostensensible KMU.

Was wir absichtlich nicht vorhersagen: Modellranglisten. Jede spezifische Rangliste, die hier gedruckt wird, wäre veraltet, bevor diese Seite erneut überprüft wird.

Die Architektur richtig gestalten

Der 2026 LLM-Stack ist real, mehrschichtig und die Entscheidungen zählen. Die Teams, die gewinnen, sind diejenigen, die:

• Den gesamten Stack verstehen, nicht nur die Teile, die sie berühren.
• Explizite Abwägungen (Qualität, Kosten, Latenz) je Aufruf treffen.
• Die Teile bauen, die differenzieren; die Teile kaufen, die nicht.
• Frühzeitig instrumentieren (Observability, Evals).
• Flexibel bleiben (modellportabel, mit mehreren Anbietern).

Die Teams, die verlieren, haben sich für einen Anbieter entschieden, dessen API hart codiert, nie instrumentiert und nie gemessen – und stehen nun vor einem teuren, fragilen und kaum verbesserbaren System.

Die Architektur richtig gestalten. Alles andere wird einfacher.