Kapitel 10 — Die LLM-Engine-Schicht

Zehnter Beitrag im Kapitel-für-Kapitel-Walkthrough zu LLM Primer VI: KI-Systeme skalieren. Das Kapitel benennt die Grenze zwischen Engine und Plattform und geht die fünf Engines ab, die diese Schicht 2026 dominieren.

Warum es dieses Kapitel gibt

Die Kapitel 1–9 haben die Maschinerie beschrieben, die ein einzelner Forward-Pass berührt: die autoregressive Schleife, den KV-Cache, das GPU-Substrat, die Quantisierung, die es schrumpft, das Batching, das Leerlauf verbirgt, und das spekulative Dekodieren, das seine sequenzielle Abhängigkeit bricht. Nichts davon liefert sich als Bibliothek aus, die man pip installt und vergisst. Jemand verdrahtet all das in eine Einzelknoten-Laufzeit, die ein Modell umhüllt, den KV-Cache besitzt, Anfragen auf einen Continuous Batch scheduled und eine Inferenz-API exponiert. Diese Laufzeit ist die Engine. Kapitel 10 benennt die Aufgabe der Engine-Schicht, grenzt sie von der Plattformschicht ab (Kapitel 11) und geht die fünf Engines ab — vLLM, TensorRT-LLM, SGLang, TGI, Ollama —, die auf derselben Aufgabe unterschiedliche mechanische Kompromisse eingehen.

10.1 vLLM ist der Python-native Standard

vLLM ist die Engine, zu der die meisten Produktionsteams zuerst greifen sollten, denn sie trifft auf jeder Achse, an die eine Anfängerin nicht denkt, die richtige Standardentscheidung — und das in Python. PagedAttention gibt ihr den Zusammenbruch der Fragmentierung von 60–80 Prozent auf einstellig, was die erreichbare Batchgröße auf derselben GPU ungefähr verdoppelt. Continuous Batching legt sich natürlich darüber, wobei Chunked Prefill in derselben Iteration Prefill- und Dekodierarbeit mischt, sodass die Grenze zwischen ihnen keine Totzeit ist. Copy-on-write-Präfix-Sharing ist aus dem Block-Tabellen-Design kostenlos. Die Schnittstelle ist ehrlich offline-batch oder OpenAI-kompatibles HTTP in wenigen Zeilen, und jede neue Modellarchitektur landet dort schnell, weil die Community breit ist. Sie ist die Engine, die man standardisiert, wenn die Betreiberin keinen bestimmten Grund hat, etwas anderes zu wählen.

10.2 TensorRT-LLM kauft Durchsatz mit einer Build-Pipeline

Das Angebot von TensorRT-LLM ist schmal. Wenn die Flotte ausschließlich NVIDIA ist, jeder Prozentpunkt Durchsatz pro Dollar zählt und das Team eine Engineering-Steuer für pro Hardware-Generation kompilierte modellspezifische Engine-Dateien zahlt, holt TRT-LLM auf derselben Hardware 15–35 Prozent mehr Durchsatz als vLLM. Der Mechanismus liegt auf Kernel-Ebene: den Transformer-Graphen in eine NVIDIA-spezifische IR absenken, angrenzende Kernel fusionieren (LayerNorm + Matmul + Aktivierung in einen einzigen Launch), pro Shape optimale Kernel aus einer vorab getunten Bibliothek auswählen, eine serialisierte Engine produzieren und unter Triton Inference Server ausführen. Fusion zählt, weil der Kernel-Launch-Overhead 5–10 μs pro Stück beträgt und ein naiver 70B-Forward-Pass Tausende davon pro Token dispatcht. Die Steuer ist die Build-Pipeline selbst — ein Kompilierschritt pro Modell, pro GPU, pro Batch-Regime, dessen operative Kosten die meisten Teams unterschätzen. SGLang ist die andere Spezialisierung: RadixAttention speichert den KV-Cache für jedes Prompt-Präfix, das die Engine je gesehen hat, in einem Radix-Baum, sodass zwei Anfragen, die ein k-Token-Präfix teilen, den KV für genau diese k Tokens über Batches und über die Zeit hinweg teilen. Auf agentischen Arbeitslasten mit langen geteilten System-Prompts und kurzen Varianten-Suffixen liefert SGLang 2–6-fachen Durchsatz gegenüber vLLM, und ihre DSL für strukturierte Ausgabe erzwingt JSON-Schemas auf Logit-Ebene, sodass die Ausgabe garantiert validiert.

10.3 Der Entscheidungsbaum läuft über die Form der Arbeitslast, nicht über den Schlagzeilen-Durchsatz

Die fünf Engines fächern sich auf einem kleinen Entscheidungsbaum auf. Entwicklerlaptop oder Edge mit gemischten Beschleunigern → Ollama. Produktions-GPU-Flotte, ausschließlich NVIDIA, hohe QPS, Durchsatz-ROI rechtfertigt die Build-Pipeline → TensorRT-LLM. Gemischte Hardware oder häufige Modellwechsel, Arbeitslast von präfixlastigen strukturierten Mustern dominiert (Agenten, Tool-Aufrufe, lange geteilte Prompts) → SGLang. Gemischte Hardware, allgemeiner Chat-Traffic, tiefe Hugging-Face-Integration → TGI. Alles andere → vLLM. Die Entscheidung ist nicht endgültig: Engines sind an der API-Grenze austauschbar — sie sprechen alle OpenAI-artiges HTTP —, sodass ein Router auf Plattformebene Traffic pro Modell, pro Arbeitslast oder pro Region verschieben kann, ohne den Client-Code zu ändern. Viele Produktions-Stacks fahren zwei oder drei Engines nebeneinander. Vorsicht vor dem Schlagzeilen-Benchmark: „Tokens pro Sekunde auf Llama-2-7B bei Batch 1" beantwortet eine Frage, die keine Produktions-Arbeitslast stellt. Benchmarke gegen dein eigenes Modell, deine eigene Prompt-Verteilung, dein eigenes Nebenläufigkeitsprofil; ein halber Tag, spart Monate.

Was Kapitel 10 vorbereitet

Jede in diesem Kapitel beschriebene Engine hört an derselben Grenze auf. Sie weiß über Kernel, KV-Blöcke und Continuous Batching Bescheid; sie weiß nichts über Replicas, Tenants, Ketten oder Authentifizierung. Kapitel 11 geht die Plattformschicht ab, die sich um diese Belange kümmert — Ray Serve, KServe, BentoML, Triton Inference Server — und zeigt, dass die Wahl viel weniger von Features als davon abhängt, welches Betriebsmodell zur bestehenden Infrastruktur und den Kompetenzen des Teams passt.

Als Nächstes — Kapitel 11: Die Plattform- und Orchestrierungsschicht. Ray Serve, KServe, BentoML, Triton — die vier Plattformen über der Engine, gewählt nach dem Passen zur Ops-Kultur.