Artificial Intelligence

Der LLM-Stack in der Produktion: Was Mitte 2026 wirklich funktioniert

By Anurag Verma•June 5, 2026

Der LLM-Stack im Produktionsbetrieb: Was Mitte 2026 wirklich funktioniert

Produktive LLM-Systeme haben eine Schwelle überschritten, mit der der Großteil der KI-Fachliteratur noch nicht mithalten kann: Die Modelle selbst sind nicht mehr das eigentliche Problem. Eine gute Ausgabe von Claude 3.5 Sonnet oder Gemini 2.0 Flash zu erhalten ist längst Grundvoraussetzung. Die eigentliche technische Herausforderung liegt in allem rund um das Modell: Inferenzeffizienz, Retrieval-Qualität, Agentenzuverlässigkeit und Kostenkontrolle bei den Aufrufvolumen, die reale agentische Workloads erzeugen.

Ich betreibe LLM-gestützte Funktionen seit achtzehn Monaten produktiv, und der Stack hat sich erheblich verändert. Das ist der aktuelle Stand meiner Erkenntnisse, Stand Juni 2026.

Inferenzschicht: vLLM hat gewonnen, vorerst

Wer Modelle selbst hostet, unterschätzt oft, wie wichtig die Wahl des Inferenz-Frameworks ist. Die drei ernsthaften Optionen sind vLLM, SGLang und TensorRT-LLM, und sie dienen unterschiedlichen Zwecken. vLLM ist der richtige Ausgangspunkt für nahezu jedes Team. Es deckt die breiteste Modellpalette ab, erfordert keinen Kompilierungsschritt und liefert durch PagedAttention und kontinuierliches Batching konstant wettbewerbsfähigen Durchsatz. SGLang überzeugt bei Workloads mit gemeinsamen Präfixen, bei denen die Zeit bis zum ersten Token entscheidend ist, etwa bei RAG-Pipelines, die jeder Anfrage denselben langen System-Prompt voranstellen. TensorRT-LLM lohnt den Aufwand nur dann, wenn ein Modell über Monate festgeschrieben ist und man im großen Maßstab jeden letzten Token pro Sekunde herausholen muss.

HuggingFaces TGI befindet sich offiziell im Wartungsmodus. HuggingFace selbst empfiehlt mittlerweile vLLM oder SGLang. Das ist ein deutliches Signal.

Die Produktions-Stack-Architektur für ernsthafte Deployments besteht aus drei Schichten: Inferenz-Engine auf Beschleunigerhardware, eine Serving-Schicht für Routing und API-Verträge (LiteLLM oder Envoy AI Gateway) sowie eine Kubernetes-basierte Orchestrierungsschicht mit KEDA für Autoscaling. Die Leistungsziele, an denen Ingenieure heute gemessen werden, sind TTFT unter 300 ms für Standardworkloads und eine Inter-Token-Latenz im zweistelligen Millisekundenbereich.

Kosten: Die Rechnung hat sich verändert, das Problem nicht

Die API-Preise sind zwischen 2025 und 2026 um rund 80 % gefallen. GPT-4-Klassenleistung kostet heute rund 0,40 $ pro Million Token, verglichen mit 30 $ pro Million Anfang 2023. Das sieht nach einem gelösten Problem aus, bis man berücksichtigt, was agentische Systeme tatsächlich tun: Eine einzige Benutzeraufgabe kann 50 bis 200 LLM-Aufrufe auslösen. Ein günstiger Token-Preis wird sehr schnell zu hohen Kosten pro Aufgabe.

Die Techniken, die wirklich etwas bewirken, sind Prompt-Caching (das die Eingabekosten bei wiederholtem Kontext um bis zu 90 % senkt), FP8-Quantisierung in Kombination mit Flash Attention 3 und spekulativer Dekodierung sowie intelligentes Request-Routing, das einfachere Teilaufgaben an kleinere, günstigere Modelle weiterleitet. Spekulative Dekodierung sollte sorgfältig profiliert werden: Sie verwendet ein kleines Entwurfsmodell, um Kandidaten-Token zu erzeugen, die das Hauptmodell parallel verifiziert. Fällt die Akzeptanzrate jedoch unter etwa 0,5 Token pro Schritt, entsteht zusätzlicher Overhead statt einer Reduzierung.

Meine Einschätzung: Teams, die kein Kosten-Dashboard pro Feature aufbauen, geben blind Geld aus. Die Einsparungen sind real, erfordern aber konsequentes Messen.

RAG: Das Retrieval ist nach wie vor das Problem

Das Muster, PDFs in eine Vektordatenbank zu laden und das als Wissensbasis zu bezeichnen, gilt inzwischen allgemein als unzureichend. Stand 2026 liegt der Ursprung der meisten RAG-Fehler im Retrieval-Schritt, nicht im Generierungsmodell. Das Fehlermuster ist subtil: Das System liefert selbstsicher klingende Antworten, die auf den falschen Chunks basieren, und Nutzer bemerken das nicht.

Hybrides Retrieval, das dichte Vektorsuche mit BM25 kombiniert und anschließend einen Cross-Encoder-Reranker einsetzt, ist die aktuelle Baseline für Produktionssysteme. Reine Vektorsuche allein schneidet bei präzisionsempfindlichen Anfragen schlechter ab. Graph-erweitertes Retrieval gewinnt in Domänen mit strukturierten Beziehungen zwischen Entitäten an Bedeutung. Die Frage der Wissensquellen-Governance, konkret wer für die Aktualität von Chunks, Deduplizierung und Qualitätsprüfung verantwortlich ist, ist eine Produktentscheidung, die Engineering-Teams immer wieder aufzuschieben versuchen, bis sie sie einholt.

Agenten und MCP: Ein Standard, der sich durchgesetzt hat

Anthropic's Model Context Protocol, Ende 2024 eingeführt, hat sich als dominanter Standard für die Anbindung von Tools an LLM-Agenten etabliert. OpenAI übernahm es im März 2025 und kündigte anschließend die Abkündigung der Assistants API an, die Mitte 2026 eingestellt werden soll. Diese Kombination zwang das Ökosystem zur Konvergenz. Cursor, Cline und die meisten ernsthaften agentischen Entwicklungsumgebungen erwarten mittlerweile MCP-kompatible Tool-Server.

Das hat praktische Konsequenzen. Eine standardisierte Tool-Schnittstelle bedeutet, dass man das zugrunde liegende Modell austauschen kann, ohne die Tool-Konnektoren neu schreiben zu müssen. Es bedeutet auch, dass die Angriffsfläche für Prompt-Injection und Tool-Missbrauch nun vorhersehbar und prüfbar ist. Beides galt vor achtzehn Monaten noch nicht.

Observability: Kein optionales Extra mehr

Langfuse wurde im Januar 2026 von ClickHouse übernommen, was etwas darüber aussagt, wohin sich der Markt entwickelt: Tracing-Pipelines benötigen Datenbanken, die mit den Schreibvolumen mithalten können, die Produktionsagenten erzeugen. Die führenden Plattformen in diesem Bereich sind LangSmith (die natürliche Wahl für LangChain-lastige Stacks), Langfuse (beste Self-Hosted-Option) und Arize Phoenix (stärkste Option für RAG-lastige Retrieval-Workflows).

Was traditionelles APM nicht beantworten kann: welcher Retrieval-Schritt irrelevanten Kontext zurückgegeben hat, warum ein Agent in eine rekursive Schleife geraten ist, ob die Ausgabequalität über Modellversionen hinweg von der Baseline abweicht. Diese Fragen erfordern LLM-natives Tracing, das Anfragen gemeinsam durch LLM-Aufrufe, Retrieval-Schritte, Tool-Aufrufe und Agenten-Entscheidungszweige verfolgt, nicht isoliert.

Halluzination: Eine Metrik, kein Binärwert

Halluzination bleibt das primäre Hindernis für hochkritische Produktions-Deployments. Der wichtige Wandel in 2026 besteht darin, dass Teams sie überwiegend nicht mehr als binäres Bestanden/Nicht-Bestanden behandeln, sondern als Rate messen. LLM-as-Judge-Erkennung erfasst je nach Prompt-Design 60 bis 75 % halluzinierter Ausgaben. Bei retrieval-gestützten Aufgaben sinken die Raten in gut entwickelten Systemen unter 2 %. Laufzeit-Guardrails, die Ausgaben vor der Auslieferung prüfen und markierte Antworten zur Überprüfung weiterleiten, sind mittlerweile Standard, obwohl die Erkennungslatenz von 200 bis 500 ms das Latenzbudget spürbar belastet.

Die praktische Empfehlung: Bauen Sie von Anfang an eine Halluzinations-Stichprobenschleife in Ihre Evaluierungspipeline ein. Bewerten Sie täglich eine Zufallsstichprobe aus Live-Produktionstraces. So erkennen Sie Modell-Drift, veraltete Retrieval-Indizes und Prompt-Regressionen, bevor Nutzer sie melden.

Was das für den Stack bedeutet

Das Modell ist eine Commodity. Das Inferenz-Framework, die Retrieval-Qualität, das Tool-Protokoll, die Observability-Schicht und die Kostendisziplin bei agentischen Aufrufvolumen sind die Bereiche, in denen echter Engineering-Hebel in 2026 liegt. Teams, die diese als Nebensache behandeln, werden weiterhin ständig Brände bekämpfen. Teams, die sie als erstrangige Anliegen behandeln, liefern zuverlässige Produkte.