LLM Engineering Guide: 45 Konzepte für Production Systems

Viacheslav Dubrov

2026-03-13 · Aktualisiert 2026-08-31 · 61 Min. · Modellentwicklung · KI-Infrastruktur

Automatische Übersetzung Dieser Artikel wurde automatisch aus der englischen Originalversion übersetzt.

Ein LLM-Service kann sein Latency-SLO verfehlen, weil Decode durch die Memory Bandwidth begrenzt ist, weil der KV cache das Batch-Budget aufgebraucht hat oder weil die Queue beides verdeckt. Ein Fine-Tuning-Lauf kann aus einem anderen Grund scheitern, der auf dasselbe Grundproblem hinausläuft: Der Model State passt nicht mehr auf die Hardware. Die richtige Lösung ergibt sich aus dem Bottleneck – nicht aus der längsten Liste von Techniken.

Dies ist eine Referenz für Engineers, die grundlegende ML- und Systems-Konzepte bereits kennen und ein Production-Symptom mit dem relevanten Teil des Stacks verknüpfen müssen. Sie behandelt 45 Konzepte aus den Bereichen Hardware, Inference, Training, Deployment, Applications und Operations. Verwende einen Eintrag, um den Mechanismus, seine praktische Konsequenz und die Bedingung zu identifizieren, die das zitierte Ergebnis begrenzt. Nutze anschließend den verlinkten Deep Dive oder deinen eigenen Benchmark für die Entscheidung.

Hinweis zum Geltungsbereich

Dies ist eine Referenz, kein linearer Kurs. Beginne mit dem Teil, der zur anstehenden Entscheidung passt.

So verwendest du diesen Guide als Hub

Diese Seite ist bewusst breit angelegt. Nutze sie als Landkarte und springe zu den ausführlicheren Beiträgen, sobald die Entscheidung konkreter wird.

Beginne mit dem Bottleneck, verwende den kleinsten Stack, der ihn sichtbar macht, benchmarke den echten Workload und füge Complexity nur dort hinzu, wo die Zahlen sie rechtfertigen.

Part I — Hardware foundations

Arithmetic Intensity, die GPU Memory Hierarchy und die Hardware-Begriffe in diesem Teil erklären viele der später im Guide getroffenen Entscheidungen.

1. Memory-bound vs Compute-bound und das Roofline Model

Der Ausgangspunkt für LLM Performance ist die Arithmetic Intensity: Wie viele nützliche Berechnungen führt die GPU für jedes Byte an Daten aus, das sie aus dem Memory lädt? Dieses Verhältnis entscheidet, ob eine Operation Compute-bound (Warten auf den Processor) oder Memory-bound (Warten auf das Laden von Daten) ist.

Jede GPU hat eine Schwelle für die „Critical Intensity“, bei der ihr maximaler Compute Throughput ihrer Memory Bandwidth entspricht. Für eine NVIDIA H100 SXM mit dichten BF16- oder FP16 Tensor Cores (989 TFLOPS; die 1.979-TFLOPS-Spezifikation setzt Structured Sparsity voraus):

$\frac{989 \text{ TFLOPS}}{3.35 \text{ TB/s}} \approx 295 \text{ FLOPs/byte}$

Batch-one Decode sowie langer oder ausreichend stark gebatchter Prefill liegen typischerweise auf entgegengesetzten Seiten dieser Schwelle:

• Decode ist Memory-bound. Bei der Token-Generierung einzeln nacheinander wird die mehrere Gigabyte große Weight Matrix aus dem Memory geladen, um sie mit einem einzelnen neuen Token zu multiplizieren. In einer vereinfachten Analyse für dichte 16-Bit-Berechnungen mit Batch-one hat die Operation ungefähr 1 FLOP/Byte – rund 295-mal weniger als die Roofline-Schwelle der H100. Diese Lücke erklärt, warum Decode in diesem Regime den maximalen Compute Throughput nicht annähernd erreicht.
• Langer oder ausreichend stark gebatchter Prefill ist häufig Compute-bound. Bei der Verarbeitung vieler Prompt Tokens werden Weights in großen Matrix Multiplications wiederverwendet, wodurch die Arithmetic Intensity über die Roofline-Schwelle steigen kann. Kurze Prompts und kleine Batches können stattdessen durch Memory Traffic oder Kernel-Launch-Overhead begrenzt sein.

Um Decode zu beschleunigen, optimiere die Memory Bandwidth: Verkleinere die Weights mit Quantization, reduziere den KV-Memory-Overhead mit GQA und PagedAttention und erhöhe die Intensity mit Batching. Für lange oder gut gebatchte Prefills können schnellere Matrix-Berechnungen und Berechnungen mit niedrigerer Precision helfen. Profile Workloads mit kurzem Prefill separat.

2. GPU Memory Hierarchy

Eine GPU besitzt vier Memory-Layer, die pyramidenförmig angeordnet sind: unten ein großer, aber langsamer Main Memory (HBM), oben winzige, aber sehr schnelle Registers. Das Verschieben von Daten durch diese Hierarchy ist eine zentrale Performance-Constraint.

Von schnell nach langsam auf einer H100:

1. Registers sind der schnellste Memory und direkt an Processing Threads angebunden. Bei Hoppers WGMMA kann Matrix A aus Registers oder Shared Memory kommen, während Matrix B aus Shared Memory kommt.
2. SRAM (Shared Memory) ist schneller On-Chip-Working-Memory, der lokal zu jedem SM gehört.
3. L2 Cache ist eine gemeinsam genutzte 50-MB-Schicht. Er kann Daten bedienen, die über mehrere SMs hinweg wiederverwendet werden, ohne einen weiteren HBM-Fetch.
4. HBM3 ist der 80-GB-Main-Memory, der Model Weights und den KV cache enthält, mit einer Bandbreite von ~3,35 TB/s.

FlashAttention und Kernel Fusion reduzieren HBM Traffic, indem sie Zwischenergebnisse auf dem Chip halten oder Operationen kombinieren. PagedAttention adressiert ein anderes Problem: Es ordnet logische KV Blocks nicht zusammenhängenden physischen GPU-Memory-Blöcken zu, reduziert Fragmentation und ermöglicht Block Sharing.

3. GPU-Hardware-Glossar

Die folgenden Begriffe tauchen im restlichen Guide immer wieder auf.

HBM (High Bandwidth Memory) besteht aus DRAM Dies, die über Through-Silicon Vias (TSVs) neben dem GPU Die verbunden sind. Zu den Generationen gehören HBM2e (A100, 2 TB/s), HBM3 (H100, 3,35 TB/s) und HBM3e (H200/B200, 4,8–8 TB/s). Die HBM Bandwidth ist in Memory-bound-Decode-Regimes eine direkte Constraint für TPOT.

GDDR (Graphics DDR) ist klassischer Graphics Memory, der in Consumer- und Workstation-GPUs wie RTX 4090 und L40S eingesetzt wird. Er hat eine geringere Bandwidth als HBM, kostet aber weniger pro GB. GDDR6X auf der RTX 4090 liefert etwa 1 TB/s gegenüber 3,35 TB/s HBM3-Bandwidth bei der H100.

Ein SM (Streaming Multiprocessor) ist der grundlegende Compute Block einer NVIDIA GPU. Jeder SM enthält CUDA Cores, Tensor Cores, Shared Memory und einen Warp Scheduler. Die H100 besitzt 132 SMs; die A100 besitzt 108.

Tensor Cores sind spezialisierte Matrix-Multiply-Accumulate-Einheiten innerhalb jedes SM. Sie beschleunigen Mixed-Precision-Matmuls, die den Schwerpunkt der Transformer-Berechnung bilden. Tensor Cores der H100 SXM liefern 494,5 dichte oder 989 sparse TF32 TFLOPS. Beim Vergleich dieses Werts müssen Precision und Sparsity-Modus immer angegeben werden.

CUDA Cores sind universelle Floating-Point- und Integer-Einheiten. Sie verarbeiten Element-wise-Operationen, Activation Functions und andere Nicht-Matrix-Arbeiten, während Tensor Cores unterstützte Matrix-Operationen ausführen.

Ein Warp ist eine Gruppe von 32 Threads, die auf einem SM synchron arbeiten; damit ist er NVIDIAs kleinste Scheduling Unit. Warp Specialization weist unterschiedliche Warps Data Movement und Computation zu, sodass die Aufgaben überlappen können.

NVLink ist NVIDIAs High-Speed-GPU-to-GPU-Interconnect innerhalb eines Nodes. NVLink 4.0 auf der H100 liefert 900 GB/s bidirektionale Bandwidth; NVLink 5.0 auf der B200 erreicht 1,8 TB/s. Diese Bandwidth ist für Tensor Parallelism relevant, weil GPUs nach jeder Transformer-Schicht Teilergebnisse austauschen.

InfiniBand ist eine High-Speed-Network-Fabric für Inter-Node Communication. InfiniBand-Adapter der ConnectX-Klasse stellen die Inter-Node-Fabric für Pipeline-Parallel- oder Distributed-Training-Traffic bereit. Die Bandwidth hängt von Adapter und Port-Konfiguration ab.

RDMA (Remote Direct Memory Access) ermöglicht einem Device den Zugriff auf Memory auf einer anderen Maschine, ohne den Datenpfad über eine CPU zu führen. GPUDirect RDMA unterstützt direkte GPU-to-GPU-Transfers über Nodes hinweg, einschließlich KV-cache-Transfers bei Disaggregated Serving.

NVMe (Non-Volatile Memory Express) ist das SSD-Interface, das für KV-cache Offloading und ZeRO-Infinity Parameter Offloading verwendet wird, wenn GPU- und CPU-Memory nicht ausreichen. Die sequenzielle Bandwidth hängt von Drive und Workload ab und bleibt weit unter der HBM Bandwidth.

TFLOPS und PFLOPS sind Billionen beziehungsweise Billiarden Floating-Point-Operationen pro Sekunde. Ein TFLOPS entspricht $10^{12}$ FLOPS. Die H100 erreicht 989 sparse TF32 Tensor TFLOPS, während FlashAttention-3 etwa 1,2 PFLOPS in FP8 meldet. Diese Werte verwenden unterschiedliche Formate und sollten nicht wie eine einzige Metrik verglichen werden.

Part II — Inference fundamentals

Inference macht aus einem Model einen für User sichtbaren Service. Die folgenden Konzepte trennen die Arbeit, die den ersten Token verzögert, von der Arbeit, die jeden weiteren Token verlangsamt, und machen die Memory-Limits hinter beiden sichtbar.

4. Latency: TTFT, TPOT und Percentiles

Time to First Token (TTFT) ist die End-to-End-Verzögerung von der Übermittlung eines Requests bis zum ersten Output Token. Sie umfasst Queueing, Tokenization, Scheduling, Prompt Prefill, den ersten Decode Step und Network Delivery. Längere Prompts erhöhen normalerweise den Prefill-Anteil, doch jede dieser Stufen kann dominieren. Ziele sind produktspezifisch; MLPerf Inference v5.0 verwendet für das interaktive Llama-2-70B-Szenario ein P99-TTFT-Limit von $\leq$ 450 ms.

Time Per Output Token (TPOT) ist das durchschnittliche Intervall zwischen aufeinanderfolgenden Tokens nach dem ersten. Die Metrik bildet die Decode-Phase ab. Batch-one- oder Low-Intensity-Decode ist üblicherweise durch Memory Bandwidth begrenzt, während ausreichend große Batches Compute-bound werden können:

$\text{TPOT} = \frac{\text{E2E Latency} - \text{TTFT}}{\text{Output Tokens} - 1}$

Diese Definition erfordert mindestens zwei Output Tokens; TPOT ist für eine Antwort mit nur einem Token nicht definiert.

Die durchschnittliche stille Lesegeschwindigkeit Erwachsener bei englischer Sachliteratur beträgt etwa 238 Wörter pro Minute (Brysbaert, 2019). Streaming-Ziele sollten dennoch aus Product Testing hervorgehen. MLPerf verwendet für sein interaktives Szenario ein P99-TPOT-Limit von $\leq$ 40 ms.

P50- versus P99-Latency ist relevant, weil der Median den Tail verbirgt. Ein System mit guter P50- und schlechter P99-Latency kann Probleme mit Batching, Preemption, Queueing oder Workload-Skew haben. Um sie zu unterscheiden, sind Traces erforderlich.

5. Throughput: Tokens pro Sekunde und der Latency-Trade-off

Throughput wird als Output Tokens pro Sekunde über gleichzeitig laufende Requests gemessen. Requests pro Sekunde sind allein betrachtet weniger aussagekräftig, weil eine 10-Token-Antwort und eine 1.000-Token-Antwort sehr unterschiedliche Kosten verursachen. Veröffentliche Benchmark-Zahlen variieren je nach Model, Precision, Hardware, Prompt- und Output-Länge, Concurrency und SLO. Vergleiche vLLM, SGLang und TensorRT-LLM mit demselben Harness, anstatt ihre Headline-Ergebnisse zu kombinieren.

Der Trade-off: Bei niedriger Concurrency erhält jeder Request eine sehr gute Latency, während die GPU nicht ausgelastet ist. Eine größere Batch Size erhöht den Throughput nahezu linear, bis die Compute-Kapazität gesättigt ist. Danach steigt die Latency stark an. Goodput, also die Rate von Requests pro Sekunde, die ihre SLO-Ziele erfüllen, verbindet den rohen Throughput mit der tatsächlichen User Experience.

6. KV cache: das Bottleneck hinter den meisten anderen Bottlenecks

Während der autoregressiven Generation attends jeder neue Token auf jeden vorherigen Token. Der KV cache speichert die Key- und Value-Projektionen jedes Tokens in jeder Schicht, um $O(n^2)$ Neuberechnung zu vermeiden. Ohne ihn müsste die Generierung von Token $n$ das erneute Ausführen des Models über alle $n-1$ vorherigen Tokens erfordern.

Der KV cache kann bei langen Sequence Lengths oder hoher Concurrency zum dominanten Faktor für variablen Memory Pressure werden, da er linear mit Sequence Length, Batch Size und Layer Count wächst:

$KVcache = 2 \times L \times h_{kv} \times d_h \times s \times B \times \text{bytes}$

wobei:

• $L$ = Anzahl der Layers
• $h_{kv}$ = Anzahl der KV Heads
• $d_h$ = Head Dimension
• $s$ = Sequence Length
• $B$ = Batch Size
• $\text{bytes}$ = Bytes pro gecachtem Element, festgelegt durch die KV-cache Precision

Konkrete Beispiele mit FP16 und Batch Size 1: Llama 3.1 8B verwendet bei 8.192 Tokens etwa 1,0 GB KV cache, bei 128K Tokens 16 GB. Llama 3.1 70B benötigt bei 128K Tokens für eine einzelne Sequence ~40 GB, also die Hälfte der VRAM einer H100. Bei hoher Concurrency oder langem Context kann der KV cache den Memory-Bedarf der Model Weights übersteigen. Das Ergebnis hängt von Sequence Length, Active Batch Size, KV Precision und der Anzahl der KV Heads ab. Naive Implementierungen verschwenden durch Fragmentation 60–80 % des allozierten KV Memory. Dieses Problem sollte PagedAttention lösen.

Die wichtigsten Optimizations sind GQA (weniger KV Heads), KV-cache Quantization (FP8/INT8), PagedAttention (Block-basierte Allokation mit <4 % Verschwendung) und das Offloading des KV cache auf CPU oder NVMe.

7. Prefill versus Decode: zwei Phasen, zwei Bottlenecks

Die Prefill-Phase verarbeitet den Input Prompt parallel und befüllt den KV cache. Langer oder ausreichend stark gebatchter Prefill wird häufig Compute-bound, weil große Matrix Multiplications verwendet werden. Kurzer Prefill kann weiterhin durch Memory Traffic oder Kernel-Launch-Overhead begrenzt sein. Prefill trägt neben Queueing, Tokenization, Scheduling, dem ersten Decode Step und Network Delivery zu Time to First Token (TTFT) bei. Die Decode-Phase generiert jeweils einen Token. Jeder Step liest Model Weights und den KV cache aus HBM, wodurch Batch-one Decode durch Memory Bandwidth begrenzt wird und zum Haupttreiber der Time Per Output Token (TPOT) wird.

Chunked Prefill teilt den Prompt in Chunks fester Größe auf, statt ihn in einem Schritt zu verarbeiten. Ein Scheduler kann diese Chunks mit Decode Work interleaven, sodass ein langer Prompt keine Iteration monopolisiert. Sarathi-Serve berichtet in den getesteten Workloads bessere Throughput-Latency-Trade-offs. Der Gewinn hängt jedoch von Model, Hardware, Request-Length-Distribution, Chunk Size und Comparison Baseline ab. Zusätzliches Scheduling und kleinere Kernels können die TTFT des neuen Requests erhöhen.

Disaggregated Serving platziert Prefill und Decode auf getrennten GPU Pools, sodass jeder Pool auf ein anderes Bottleneck optimieren kann. Splitwise und DistServe beschreiben dieses Pattern. Die Pools übertragen KV-cache-Daten über ein schnelles Interconnect wie RDMA. Dadurch wird Communication Cost Teil des Designs.

8. GQA und MQA: den KV cache verkleinern

Standard-Multi-Head Attention (MHA) gibt jedem Query Head einen eigenen K- und V-Head. Multi-Query Attention (MQA) teilt einen einzelnen KV Head über alle Query Heads hinweg – eine extreme Reduktion. Grouped-Query Attention (GQA) ist der praktikable Mittelweg: Gruppen von Query Heads teilen sich jeweils einen KV Head.

Llama 3 70B verwendet 64 Query Heads, aber nur 8 KV Heads – eine 8-fache Reduktion des KV cache gegenüber derselben Architektur mit einem KV Head pro Query Head. Llama 3.1 405B verwendet 128 Query Heads und 8 KV Heads, also nach derselben Berechnung eine 16-fache Reduktion (Meta, 2024). Ainslie et al. berichten für ihre getesteten Models eine GQA-Qualität nahe an MHA bei einer Geschwindigkeit nahe an MQA. Ein kleinerer KV cache kann größere Batches ermöglichen. Der tatsächlich erzielte Latency- und Throughput-Gewinn hängt jedoch weiterhin von Kernel und Workload ab.

9. Quantization: Bits gegen Speed und Memory tauschen

Quantization reduziert die Precision von Model Weights und/oder Activations. Die zentralen Trade-offs:

AWQ (Activation-Aware Weight Quantization) identifiziert anhand von Activation Magnitudes besonders wichtige Weight Channels und wendet Per-Channel Scaling an, um diese zu schützen. Der Calibration-Bedarf hängt von Model und Configuration ab. In einem OPT-6.7B-INT3-g128-Vergleich benötigte AWQ 16 Calibration Sequences, GPTQ dagegen 192. Gib in einem reproduzierbaren Setup sowohl die Sequence Count als auch die Sequence Length an. GPTQ verwendet approximierte Second-Order-Informationen für Layer-wise Quantization. bitsandbytes kann beim Model Loading quantisieren, ohne einen separaten Preprocessing-Pass; sein NF4-Format bildet die Grundlage für QLoRA Fine-Tuning. FP8 auf Hopper-Hardware halbiert den Weight Memory gegenüber FP16/BF16, doch Quality und Speed hängen weiterhin von Model, Calibration und Kernel ab.

Der Serving Kernel kann ebenso wichtig sein wie der Quantization Algorithm. Section 10 zeigt ein begrenztes Marlin-Ergebnis und erklärt, warum der Gewinn von der Serving Configuration abhängt.

Part III — Inference optimizations

Die Optimizations in diesem Teil lösen unterschiedliche Constraints. FlashAttention reduziert den HBM Traffic von Attention, PagedAttention verbessert die KV Allocation, und Continuous Batching verhindert, dass abgeschlossene Sequences Batch Capacity blockieren.

10. CUDA Kernels und Kernel Fusion

Ein CUDA Kernel ist eine für die GPU geschriebene Function, die parallel über Tausende Threads ausgeführt wird. Wenn die CPU einen Kernel aufruft, verteilt die GPU die Arbeit auf ihre SMs: Jeder SM führt mehrere Warps mit jeweils 32 Threads aus, und jeder Thread verarbeitet einen Teil der Daten. Jede Operation in der LLM Inference, von Matrix Multiplication bis Token Sampling, ist letztlich ein Kernel Launch. Ein einzelner Forward Pass durch ein 70B Model löst Hunderte bis Tausende Kernel Launches aus. Der Abstand zwischen einem naiven und einem optimierten Kernel kann darüber entscheiden, ob dein System sein Latency-SLO erfüllt.

Die wichtigsten Kernel-Kategorien im LLM Serving:

• GEMM Kernels für Matrix Multiplication, die sowohl Prefill als auch Decode Compute dominieren.
• Attention Kernels wie FlashAttention, die Berechnungen tilen, damit sie in SRAM bleiben, statt in HBM ausgelagert zu werden.
• Fused Kernels, die mehrere Operationen (etwa Add + LayerNorm oder QKV Projection) in einem Launch kombinieren und dadurch die HBM Round-Trips für Zwischenergebnisse vermeiden.
• Sampling Kernels, die Logits über Top-k-, Top-p- oder Temperature Sampling in Token IDs umwandeln.

Kernel Quality kann entscheiden, ob Compressed Weights einen Speedup liefern. Das Marlin Paper berichtet für getestete vLLM-Konfigurationen mit Weight-only INT4 bis zu 2,8-fachen End-to-End-Speedup gegenüber seiner FP16-Baseline. Dieses Ergebnis ist spezifisch für die Models, GPUs, Batch Sizes und Serving Configuration des Papers und daher kein universeller INT4-Gewinn.

Triton senkt die Einstiegshürde für das Schreiben eigener Kernels, indem es GPU Programming über Python statt über Raw CUDA C++ ermöglicht. Damit wird Kernel-Level Optimization auch für ML Engineers und nicht nur für GPU-Spezialisten erreichbar. Die meisten später in diesem Teil beschriebenen Optimizations – FlashAttention, Fused Kernels und PagedAttention – sind entweder bessere Kernels oder intelligentere Formen der Orchestration von Kernel Launches.

Kernel Fusion kombiniert sequenzielle Operationen in einem GPU Kernel und überspringt Intermediate HBM Writes. Übliche Fusions umfassen QKV Projection, Attention plus Softmax, Add plus RMSNorm (FlashNorm) und die SwiGLU Activation (DeepFusionKernel). Triton macht diese Kernels über Python zugänglich. Die konkreten Gewinne bei Launch Count und Utilization hängen von Model Graph, Compiler, GPU und Serving Framework ab. Deshalb sollte der deployte Stack profiliert werden, statt sich auf einen universellen Prozentsatz zu verlassen.

11. FlashAttention: Attention durch Tiling in SRAM halten

Standard-Attention materialisiert die vollständige $N \times N$ Attention Matrix in HBM. Das kostet $O(N^2)$ Memory und erzeugt viel Memory Traffic. Die Idee hinter FlashAttention besteht darin, diese Matrix überhaupt nicht zu materialisieren. Q-, K- und V-Matrizen werden in Blöcke geteilt, die in SRAM passen. Innerhalb jedes Tiles wird partielle Attention berechnet, anschließend werden die Ergebnisse über einen Online Softmax zusammengeführt, der das laufende Maximum und die laufende Summe über die Blöcke hinweg inkrementell verfolgt. Der Memory-Bedarf sinkt von $O(N^2)$ auf $O(N)$, und HBM Reads sinken um eine Größenordnung.

Jede Version adressiert das Bottleneck ihrer GPU-Generation:

• FlashAttention v1 (A100, 2022) zeigte, dass die Kombination aus Tiling und Online Softmax funktioniert. Das Paper berichtete einen Speedup von 2–4x gegenüber Standard Attention, aber nur 25–40 % GPU Utilization, weil das Kernel Scheduling viele SMs idle ließ.
• FlashAttention v2 (A100, 2023) überarbeitete den Parallelism, indem es entlang der Sequence Dimension statt entlang von Batch und Heads aufteilte. Auf der A100 wurden 50–73 % Utilization und ungefähr 2x mehr Speed als bei v1 erreicht.
• FlashAttention v3 (H100 Hopper, 2024) fügte Warp Specialization (separate Warps für Data Movement und Math) sowie GEMM-Softmax Pipelining hinzu, um Memory Loads und Computation zu überlappen. Das Paper berichtet auf der H100 bis zu 740 TFLOPS/s in FP16 (75 % Utilization) und nahezu 1,2 PFLOPS/s in FP8. NeurIPS 2024 Spotlight.
• FlashAttention v4 (B200 Blackwell, 2026) adressiert ein neues Bottleneck: Auf Blackwell skaliert der Tensor-Core-Throughput so schnell, dass Non-Matmul-Operationen (Softmax-Exponentials, Rescaling) zum Limiter werden. FA4 emuliert die Exponentialfunktion per Polynomial Approximations auf FMA Units, verwendet Conditional Rescaling zur Reduzierung des Overheads und speichert Intermediates im dedizierten Tensor Memory (TMEM) von Blackwell statt in Registers. Das Paper berichtet in seinen Tests auf der B200 etwa 1,6 PFLOPS in BF16, 1,3x mehr Speed als cuDNN 9.13 und 2,7x mehr Speed als Triton.

12. FlashDecoding: das Decode-Bottleneck parallelisieren

Standard FlashAttention hält die GPU beschäftigt, indem es die Arbeit über Batch Size und Query Length aufteilt. Während Decode generiert das Model exakt einen Token pro Schritt (Query Length = 1). Wenn Batch Size multipliziert mit der Anzahl der Attention Heads kleiner ist als die Gesamtzahl der SMs der GPU (108 auf einer A100), bleibt ein Großteil der GPU idle, während wenige Units sequenziell die Token-History verarbeiten.

FlashDecoding löst dies durch eine neue Parallelization Dimension: die KV Sequence Length selbst. Der KV cache wird in kleinere Chunks geteilt und zur parallelen Auswertung über die sonst idle GPU-Prozessoren verteilt. Anschließend werden die Teilergebnisse mit einer Log-Sum-Exp-Reduction zusammengeführt.

Im Batch-one-CodeLlama-34B-Benchmark von Stanford erreichte FlashDecoding bei Sequence Lengths von 512 bis 64K Tokens bis zu 8x End-to-End-Speedup gegenüber den getesteten Baselines und hielt die Attention Latency bis 64K nahezu konstant. Das Ergebnis ist auf diese Hardware und diesen Benchmark begrenzt und keine allgemeine Decode-Garantie.

13. Continuous Batching versus Static Batching

Static Batching wartet, bis jede Sequence eines Batches abgeschlossen ist, bevor der nächste gestartet wird. Kurze Sequences verschwenden dadurch GPU Cycles, nachdem sie das Ende erreicht haben. Continuous Batching (eingeführt durch das Orca Paper, OSDI 2022) arbeitet auf Iterationsebene: Bei jedem Decode Step werden abgeschlossene Sequences entfernt und neue eingefügt.

Im OPT-13B-Benchmark von Anyscale erreichte optimiertes Static Batching das Vierfache seiner naiven Baseline, Continuous Batching das Achtfache und vLLM mit Continuous Batching plus PagedAttention das 23-Fache (Anyscale, 2023). Continuous Batching erhöht außerdem den Druck auf die KV Allocation. Deshalb wird es häufig mit paged Memory Management kombiniert.

14. PagedAttention: Virtual Memory für den KV cache

vLLMs PagedAttention überträgt die OS-Idee von Virtual Memory auf das KV-cache Management. Der KV cache wird in Blöcke fester Größe aufgeteilt (typischerweise 16 Tokens), Blöcke werden während der Token-Generierung bei Bedarf alloziert, und logische (sequenzielle) Positionen werden über Block Tables physischen (verstreuten) Memory Locations zugeordnet. Mehrere Requests, die einen Prefix teilen (System Prompts, Beam Search), können auf dieselben physischen Blöcke verweisen.

Frühere Systems verschwendeten durch Fragmentation und Pre-Allocation 60–80 % des KV-cache Memory. PagedAttention reduziert diesen Anteil auf <4 %. Dadurch kann der Throughput bei gleicher Latency um das 2- bis 4-Fache und gegenüber Hugging Face Transformers um bis zu 24x steigen (vLLM Blog, 2023).

15. Speculative Decoding: mehrere Tokens pro Forward Pass

Bei Speculative Decoding generiert ein kleines Draft Model $K$ Candidate Tokens. Anschließend bewertet das große Target Model alle $K$ Positionen in einem Forward Pass. Der Decoder akzeptiert Draft Tokens von links nach rechts mit Wahrscheinlichkeiten, die aus den Target- und Draft-Distributionen abgeleitet werden. Nach der ersten Ablehnung zieht er eine Korrektur aus der Residual Target Distribution und verwirft die übrigen Draft Tokens. Dieser modifizierte Rejection-Sampling-Step erhält die Output Distribution des Target Models innerhalb der Hardware-Numerics. Exaktes Token Matching allein tut dies nicht.

Der Gewinn ist bei kleinen Serving Batches und kurzen Draft Lengths am wahrscheinlichsten, wenn das Scoring des Drafts durch Weight-, KV-cache- oder Communication Traffic dominiert wird und nicht durch die zusätzliche Token-Berechnung. Das ursprüngliche Speculative-Sampling-Paper berichtete für sein getestetes 70B-Chinchilla-Setup einen Decode-Speedup von 2–2,5x; EAGLE-3 berichtete in seinen Tests bis zu 6,5x. Varianten umfassen Medusa (zusätzliche Prediction Heads, kein separates Model), Prompt Lookup Decoding (N-Gram-Matching gegen den Input ohne separaten Draft-Model-Forward-Pass) und EAGLE (Feature-Level Extrapolation).

Bei großen Batch Sizes kann zusätzliche Draft- und Verification-Arbeit den Gewinn aufzehren. Speculative Decoding ist am vielversprechendsten, wenn der Serving Batch klein genug und die Draft Acceptance hoch ist. Benchmarke den vollständigen Serving Loop statt nur des Verification Kernels.

16. Prefix Caching und KV-cache Reuse

Statt den KV cache nach Abschluss eines Requests zu verwerfen, hält Prefix Caching ihn für die Wiederverwendung bei neuen Requests vor, die dieselben Prefix Tokens teilen. Dadurch entfällt redundanter Prefill für System Prompts, Few-shot Examples, RAG Context und Multi-turn Conversation History.

vLLMs Automatic Prefix Caching hasht KV Blocks und verwendet für Lookups eine globale Hash Table. SGLangs RadixAttention verwaltet einen Radix Tree gecachter KV Tensors mit Token-Level Granularity. Beide Verfahren hängen von wiederholt auftretenden, Token-identischen Prefixes ab. Deshalb sollte neben Latency oder Throughput auch die Hit Rate angegeben werden.

17. Streaming in der Praxis

Streaming sendet Tokens an den Client, sobald sie generiert werden, statt auf die vollständige Antwort zu warten. Viele Serving Frameworks stellen dies über Server-Sent Events bereit: Der Client öffnet eine langlebige HTTP Connection und der Server sendet jeden Token oder Token Batch als data:-Event. TTFT bestimmt, wann der User erstmals Output sieht; TPOT beeinflusst, wie flüssig sich das Streaming anfühlt. Lege das Ziel durch Product Testing und das gewählte Interaction Model fest.

Auf der Client-Seite erzwingt Streaming Entscheidungen über Buffering. Tokenweise Rendering kann visuellen Jitter verursachen, insbesondere bei Markdown oder Code Blocks, die für eine korrekte Formatierung mehrere Tokens Kontext benötigen. Übliche Patterns sind Word-level Buffering (Tokens bis zu einer Whitespace-Grenze sammeln), Line-level Buffering (bis zu einem Newline warten) und Adaptive Buffering (Prosa sofort rendern, Code Blocks puffern). In der OpenAI Chat Completions API fügt stream_options: {"include_usage": true} vor der data: [DONE]-Message einen abschließenden Usage Chunk hinzu. OpenAI-kompatible Server können sich unterscheiden. Prüfe daher die ausgewählte Implementierung.

Chunked Prefill ist eine Möglichkeit, zu verhindern, dass lange Prefills bei gleichzeitig aktiven Usern die Token-Auslieferung blockieren. Decode-priorisiertes Scheduling kann laufende Requests schützen, während Disaggregated Serving Prefill und Decode auf separaten GPU Pools isoliert.

Part IV — Model architecture

Die Architecture bestimmt den Memory Footprint, das Attention-Verhalten und die Training Dynamics, um die sich die Serving- und Training-Abschnitte herum organisieren.

18. Grundlagen der Transformer Architecture

Ein moderner Decoder-only Transformer (GPT, Llama) ist ein Stack identischer Layers mit jeweils zwei Sub-Blocks: Attention und Feed-Forward. Jeder Sub-Block ist von einer Residual Connection und Normalization umgeben. Die zentralen Komponenten:

Multi-Head Attention ermöglicht jedem Token, Informationen aus den Tokens zu gewichten, die unter der Attention Mask sichtbar sind. Der Input wird in drei Matrizen projiziert: Queries (Wonach suche ich?), Keys (Was enthalte ich?) und Values (Welche Information trage ich?). Anschließend werden Attention Scores berechnet:

$\text{Attention}(Q, K, V) = \text{softmax}\left(\frac{QK^T}{\sqrt{d_k}}\right)V$

Das $QK^T$-Dot-Product misst die Similarity zwischen jedem Token-Paar. Die Division durch $\sqrt{d_k}$ verhindert, dass die Dot Products zu groß werden und Softmax dadurch in Bereiche mit verschwindenden Gradients gedrückt wird. Softmax wandelt Scores in Wahrscheinlichkeiten um, und die Multiplikation mit $V$ erzeugt eine gewichtete Kombination der Value Vectors. Wenn dies parallel über mehrere Heads ausgeführt wird, kann das Model gleichzeitig unterschiedliche Beziehungen berücksichtigen – etwa ein Head für Syntax und ein anderer für Coreference.

Das Feed-Forward Network (FFN) transformiert jede Token Representation unabhängig, nachdem Attention Informationen über Tokens hinweg gemischt hat. Moderne LLMs verwenden häufig SwiGLU anstelle des ursprünglichen zweimatrixigen ReLU-FFN:

$\text{SwiGLU}(x) = \left(\text{Swish}(xW_{gate}) \odot xW_{up}\right)W_{down}$

SwiGLU besitzt drei Weight Matrices gegenüber zwei bei einem ReLU-FFN und verwendet das glatte Swish. Llama, Mistral und Qwen verwenden es; Gemma verwendet ein approximiertes GeGLU. Die bekannte Two-thirds Rule gilt für einen konventionellen Full-MHA-Block mit $d_{ff} \approx 4d$: Seine beiden FFN-Matrizen tragen etwa $8d^2$ Parameters bei, gegenüber etwa $4d^2$ für Attention. Für SwiGLU/GQA Architectures ist dies keine allgemeine Schätzung. In Llama 3 8B machen $d=4{,}096$, $d_{ff}=14{,}336$ und acht Key/Value Heads das FFN pro Layer zu $3d \times d_{ff} \approx 176$M Parameters, gegenüber etwa 42M Attention-Projection-Parameters – also etwa 81 % dieser Projection Weights, vor Embeddings und Normalization.

Residual Connections addieren den Output jedes Sub-Blocks zurück zu seinem Input: $\text{Output} = \text{Input} + \text{Sublayer}(\text{Input})$. Der Skip Path verbessert Signal- und Gradient Propagation durch tiefe Stacks.

RMSNorm ist in modernen LLM Families verbreitet. LayerNorm zentriert durch Subtraktion des Mittelwerts neu und skaliert mit der Standardabweichung. RMSNorm überspringt die Mittelwertsubtraktion und skaliert nur neu. Das Paper berichtet in den getesteten Models 7–64 % Speedup ohne Performance-Einbußen in diesen Experimenten. Auch Pre-norm Placement, bei dem vor Attention oder FFN normalisiert wird, ist verbreitet, weil es die Gradient Stability verbessert.

Parameter Count Estimation für ein Decoder-only Model:

$\text{Total} \approx V \times d + 12 \times L \times d^2$

Dabei ist $V$ die Vocabulary Size, $d$ die Hidden Dimension und $L$ die Layer Count. Der Term $V \times d$ ist die Input-Embedding-Matrix; der Term $12 \times d^2$ approximiert die Attention- und FFN-Weights in jedem Layer. Für Llama 3 8B ($V=128{,}256$, $d=4{,}096$, $L=32$) ergibt die Schätzung etwa $0.53B + 6.44B = 6.97B$ Parameters. Die veröffentlichte Gesamtsumme von 8,03B ist höher, weil die Approximation architektonische Details wie die exakte FFN Width und die separate Output Projection auslässt.

19. Decoder-only Models für General-Purpose Generation

Der ursprüngliche Transformer (2017) besaß sowohl einen Encoder als auch einen Decoder. Seitdem hat sich das Feld in drei Architektur-Families aufgeteilt, von denen eine zum Standard für Generative AI wurde.

Encoder-only Models (BERT, RoBERTa) verwenden Bidirectional Attention: Jeder Token attends in beide Richtungen auf jeden anderen Token. Das erzeugt Rich Representations für Understanding Tasks (Classification, NER, Semantic Similarity), kann aber Text nicht autoregressiv generieren. Encoder-only Models sind weiterhin als Backbone für Embedding Models, Rerankers und Lightweight Classifiers verbreitet – beispielsweise für die BERT-basierten Routers in RouteLLM.

Encoder-decoder Models (T5, BART, der ursprüngliche Transformer) trennen Understanding und Generation. Der Encoder verarbeitet den vollständigen Input mit Bidirectional Attention. Danach generiert der Decoder den Output autoregressiv und attends über Cross-Attention auf die Representations des Encoders. Dies bietet einen natürlichen Vorteil für Sequence-to-Sequence Tasks wie Translation, bei denen Input und Output unterschiedliche Sequences sind. Googles T5 zeigte, dass sich jede NLP Task als Text-to-Text formulieren lässt. Encoder-decoder Models bilden weiterhin die Grundlage einiger spezialisierter Systems, etwa Whisper für Speech Recognition und FLAN-T5 für Instruction Following.

Decoder-only Models (GPT, Llama, Mistral, Gemini) verwenden Causal (Unidirectional) Attention: Jeder Token attends nur auf vorherige Tokens. Sie sind für General-Purpose Text Generation verbreitet, weil ein Causal-Language-Model-Objective auf unpaired Text skaliert, während Inference Instructions, Few-shot Demonstrations und die Query als Tokens in einem Prefix behandelt. Der wiederholte Decoder Block vermeidet außerdem einen separaten Encoder Stack und einen Cross-Attention Path. Encoder-decoder Models bleiben nützlich, wenn eine Task davon profitiert, den Input separat zu encoden und gegen diese Representation zu generieren, einschließlich Translation und Speech Recognition.

20. Mixture of Experts

MoE ersetzt das dichte FFN in jedem Transformer Layer durch mehrere kleinere Expert FFNs plus einen Lightweight Gating Router. Der Router berechnet für jeden Expert einen Score (typischerweise einen Softmax über gelernte lineare Projections) und wählt die Top-$k$ Experts pro Token. Nur die aktivierten Experts rechnen. Dadurch kann ein Model über enorme Gesamtkapazität verfügen, während die Cost pro Token niedrig bleibt. Dies ist Sparse Conditional Computation: Die Total Parameters bestimmen, was das Model repräsentieren kann; die Active Parameters bestimmen, was der Betrieb kostet.

Der Shared Expert in DeepSeek-V3 wird für jeden Token aktiviert. Er liefert eine Baseline Representation, auf der die Routed Experts spezialisieren können.

Beim Training von MoE treten drei wiederkehrende Probleme auf: Load Imbalance, Expert Collapse und Communication Overhead für Expert Parallelism. Klassische MoE Models fügen einen Auxiliary Loss hinzu, um Imbalanced Routing zu bestrafen. Dieser Loss kann jedoch mit dem Main Objective konkurrieren. DeepSeek-V3 verwendet primär eine Batch-wise, Auxiliary-Loss-free Strategy: Bias Terms außerhalb von Backpropagation senken den Score überlasteter Experts und erhöhen den Score zu wenig genutzter Experts. Zusätzlich wird ein sehr kleiner Complementary Sequence-wise Balance Loss eingesetzt, um extreme Imbalance innerhalb einer Sequence zu verhindern. Das Paper berichtet in seinem Setup eine bessere Routing Balance ohne den Trade-off des zentralen Auxiliary Loss.

21. Tokenization: BPE, SentencePiece und tiktoken

LLMs sehen keinen Text. Sie sehen Sequences aus Integer Token IDs. Ein Tokenizer teilt Raw Text in Tokens (Subword Pieces) und ordnet jedem eine ID zu. Die Wahl des Tokenizers beeinflusst Model Quality, Inference Speed und Multilingual Fairness.

Byte Pair Encoding (BPE) ist der verbreitete Algorithmus. Er merged iterativ die häufigsten benachbarten Paare im Training Corpus. Ein vereinfachtes Beispiel:

1. Beginne mit einem Character-level Vocabulary: [l, o, w, e, r, _]
2. Das häufigste Pair ist (l, o) → Merge zu lo → Vocabulary: [l, o, w, e, r, _, lo]
3. Das nächste häufigste Pair ist (lo, w) → Merge zu low → Das Vocabulary erhält low
4. Fahre fort, bis das Vocabulary die Zielgröße erreicht (z. B. 128K Tokens)

Häufige Wörter wie „the“ werden zu einzelnen Tokens, während seltene Wörter wie „defenestration“ in Subword Pieces wie ["def", "en", "est", "ration"] aufgeteilt werden. Der Trade-off besteht zwischen Vocabulary Size und Sequence Length.

Drei Tokenizer-Implementierungen decken den Großteil des Production-Einsatzes ab:

• SentencePiece trainiert direkt auf Raw Unicode Text ohne Language-specific Pre-Tokenizer. Es erhält Whitespace mit dem ▁ Meta-Symbol und kann optional auf UTF-8 Byte Tokens zurückfallen. Es unterstützt sowohl BPE- als auch Unigram-Models und wird von Llama 1/2, T5 und Mistral verwendet.
• tiktoken ist OpenAIs Rust-basierter Tokenizer mit Byte-level BPE. In seinem veröffentlichten GPT-2-Benchmark lief er 3–6x schneller als die getestete GPT2TokenizerFast-Configuration. Llama 3 wechselte von SentencePiece zum Algorithmus von tiktoken.
• Hugging Face Tokenizers ist eine verbreitete Rust-basierte Library mit Support für BPE, WordPiece und Unigram.

Fertility misst, wie viele Tokens ein Tokenizer pro Wort oder einer anderen gewählten Text Unit erzeugt. Die Metrik variiert nach exaktem Tokenizer, Language, Script, Normalization, Domain und Sample. Miss sie auf repräsentativem Traffic, statt aus einem einzelnen Tokenizer oder einer Sprache zu extrapolieren.

22. Context Windows und Positional Encodings

Das Context Window ist die maximale Anzahl Tokens, die ein Model in einem einzelnen Forward Pass verarbeiten kann. Es ist stark gewachsen:

Unmasked Self-Attention ist Permutation-equivariant: Werden Input Tokens umgeordnet, werden auch die Outputs auf dieselbe Weise umgeordnet. Die Causal Mask eines Decoders begrenzt jedoch bereits jeden Token auf seinen Prefix. Deshalb erzeugt das Umkehren eines Satzes nicht identische Hidden States. Positional Encodings fügen innerhalb dieses sichtbaren Prefix explizite Informationen zu Position und relativer Distanz hinzu.

Drei verbreitete Ansätze sind:

• RoPE (Rotary Position Embeddings) rotiert Query- und Key-Vectors um positionsabhängige Winkel, sodass ihr Dot Product von der relativen Position abhängt. Der Token Content bestimmt weiterhin den Attention Score; RoPE fügt Positionsinformation ohne gelernte Absolute-Position-Embeddings hinzu. Es wird von offenen Model Families wie Llama, Mistral und Qwen verwendet.

• ALiBi (Attention with Linear Biases) überspringt Änderungen an Embeddings und fügt direkt zu den Attention Scores eine Penalty hinzu: Je weiter zwei Tokens voneinander entfernt sind, desto größer ist der negative Bias. Es besitzt keine gelernten Positional Parameters. Im Original-Paper erzielte ein mit 1.024-Token-Sequences trainiertes 1,3B Model bei 2.048 Tokens eine vergleichbare Performance zu einem Sinusoidal-Position-Model, das mit 2.048 Tokens trainiert wurde. Das Verhalten jenseits der getesteten Models und Lengths des Papers ist Model-abhängig.

• YaRN (Yet another RoPE extensioN) erweitert ein RoPE Model über seinen Training Context hinaus. Es gruppiert Frequency Dimensions in drei Kategorien und skaliert jede unterschiedlich. Das Paper berichtet 10x weniger Fine-Tuning Tokens und 2,5x weniger Training Steps als seine Position-Interpolation-Baseline.

Part V — Training and alignment

Dieser Teil unterscheidet zwischen dem Objective, das Capabilities erzeugt, den Techniques, mit denen Training auf die verfügbare Hardware passt, und den Methods, die anschließend das Verhalten eines Models formen.

23. Pretraining, Fine-Tuning und Alignment

Pretraining ist Self-supervised Next-Token Prediction auf einem großen Corpus. Der Compute-Bedarf kann sich über viele Größenordnungen erstrecken; Llama 3 405B verwendete beispielsweise $3.8 \times 10^{25}$ FLOPs. Supervised Fine-Tuning (SFT) passt das Pretrained Model an Task-specific Labeled Data an. RLHF / RLAIF verwendet Preference Data zur Verhaltensformung: Eine klassische RLHF Pipeline sammelt Comparisons, trainiert ein Reward Model und optimiert anschließend die Policy. RLAIF ersetzt einen Teil der menschlichen Bewertungen durch AI-generated Feedback.

Der Compute-Bedarf hängt von Model Size, Sequence Length, Data Volume, Optimizer und Method ab. PPO benötigt außerdem mehr Model State als SFT, weil ein typisches Setup Policy, Reference, Reward und Critic Models umfasst. Das vollständige Decision Framework für Fine-Tuning habe ich im LLM Fine-Tuning Guide behandelt.

24. LoRA und QLoRA: Parameter-efficient Fine-Tuning

LoRA friert die Pretrained Weights ein und injiziert trainierbare Low-Rank-Matrizen $A$ ($r \times k$) und $B$ ($d \times r$), sodass das aktualisierte Weight $W_0 + BA$ ist. Das LoRA Paper reduzierte GPT-3 175B in seinem Setup auf etwa 18 Millionen trainierbare Parameters. Der Rank ist ein Tuning Parameter und keine Regel für Task Complexity. Wähle ihn über einen Quality- und Memory-Sweep. LoRA Adapters können nach dem Training in die Base Weights gemerged werden, um bei Inference einen separaten Adapter Path zu vermeiden.

QLoRA lädt das Base Model in 4-Bit-NF4-Quantization und trainiert LoRA Adapters in BF16. NormalFloat4 platziert mehr Quantization Levels nahe null, wo die Weight Density am höchsten ist. Das Paper fine-tunte ein 65B Model auf einer einzelnen 48-GB-GPU und berichtete Results nahe an seinen 16-Bit-Baselines. Die Runtime- und Memory-Trade-offs sind spezifisch für den getesteten Stack.

25. Mixed-Precision Training

Jedes Floating-Point-Format verteilt seine Bits auf drei Felder: Sign (immer 1 Bit), Exponent (legt den Dynamic Range fest) und Mantissa (legt die Precision fest). Mehr Exponent-Bits bedeuten einen größeren Bereich darstellbarer Magnitudes; mehr Mantissa-Bits ermöglichen feinere Unterscheidungen zwischen benachbarten Werten. Integer-Formate haben überhaupt keinen Exponenten und repräsentieren innerhalb eines festen Bereichs nur gleichmäßig verteilte Ganzzahlen.

BF16 besitzt denselben Range wie FP32, weil der Range durch das Exponent-Feld bestimmt wird und BF16 alle 8 Exponent-Bits von FP32 beibehält. Dafür gibt BF16 Mantissa-Bits auf (7 statt 23) und tauscht Precision gegen eine 2-fache Memory Reduction, ohne viele Range-Probleme, die FP16 Training betreffen. FP16 verfügt nur über 5 Exponent-Bits und begrenzt seinen endlichen Range auf etwa 65K. Viele Gradients sind für FP16 hingegen zu klein und underflowen in Richtung null. Loss Scaling multipliziert den Loss vor Backpropagation, sodass diese Gradients darstellbar bleiben, und entfernt die Skalierung vor dem Optimizer Step wieder. Dynamic Scaling reduziert den Faktor, wenn ein Overflow auftritt. Der größere Exponent-Range von BF16 macht dies normalerweise unnötig.

Integer-Formate sind für die zentrale Training Arithmetic unüblich, weil Backpropagation einen großen Dynamic Range benötigt. Für Inference werden sie häufig eingesetzt, da sich eingefrorene Weights auf kalibrierte Scales abbilden lassen. INT4 Weight Quantization reduziert ein 7B Model vor Runtime Overhead von etwa 14 GB auf 3,5 GB. Quality muss für das ausgewählte Model und die gewählte Method gemessen werden.

FP8 Training auf der H100 über Transformer Engine verwendet E4M3, wenn Precision wichtig ist, und E5M2, wenn ein größerer Range wichtig ist. Das FP8-LM Paper berichtet, dass sein Mixed-Precision Framework GPT-175B unter dem getesteten H100-Setup 75 % schneller als seine BF16-Megatron-LM-Baseline und 37 % schneller als NVIDIA Transformer Engine trainierte. DeepSeek-V3 verwendete Mixed Precision in FP8 und berichtete für seinen finalen Training Run rund $5,6 Millionen an mietäquivalentem Compute, ohne R&D und Infrastructure.

26. Gradient Checkpointing

Jeder Layer des Forward Pass erzeugt einen Intermediate Output, der Activation genannt wird:

$\text{Input} \rightarrow [\text{Layer 1}] \rightarrow \text{activation}_1 \rightarrow [\text{Layer 2}] \rightarrow \text{activation}_2 \rightarrow [\text{Layer 3}] \rightarrow \text{output}$

Normalerweise müssen alle Activations im Memory verbleiben, weil Backpropagation sie zur Berechnung der Gradients benötigt. Bei einem tiefen Transformer können gespeicherte Activations mehr Memory als die Model Weights beanspruchen.

Gradient Checkpointing tauscht Compute gegen Memory, indem die meisten Activations verworfen und während Backpropagation bei Bedarf neu berechnet werden. Die Standard-Strategy (Chen et al., 2016) unterteilt ein Network aus $n$ Layers in $\sqrt{n}$ gleichmäßig verteilte Segments und speichert nur die Boundary Activation jedes Segments. Diese gespeicherten Boundaries sind die „Checkpoints“. Alle Intermediate Activations innerhalb eines Segments werden sofort verworfen.

Wenn der Backward Pass einen Layer innerhalb eines Segments erreicht, werden dessen Activations vom nächsten Checkpoint aus neu berechnet. Bei der gleichmäßig segmentierten Strategy sinkt der gespeicherte Activation Memory von $O(n)$ auf $O(\sqrt{n})$. Die tatsächliche Memory Savings und der Recomputation Overhead hängen von Model, Checkpoint Boundaries, Sequence Length, Framework und Implementierung ab. Miss daher beides im Ziel-Training-Run. Aktiviere die Funktion in Hugging Face mit gradient_checkpointing=True.

27. DeepSpeed-ZeRO-Stages

Beim Standard Data Parallelism hält jede GPU eine vollständige Kopie der Model Weights, Gradients und Optimizer States. Bei Adam benötigt jeder Parameter 2 Bytes für das FP16 Weight + 4 Bytes für das FP32 Master Weight + 4 Bytes für Momentum + 4 Bytes für Variance + 2 Bytes für den Gradient – also 16 Bytes pro Parameter. Ein Model mit 7,5B Parameters benötigt etwa 120 GB pro GPU, und jede GPU speichert dieselben Daten. Auf 64 GPUs sind das 64 identische Kopien mit jeweils 120 GB. Eine große Verschwendung.

DeepSpeed ZeRO (Zero Redundancy Optimizer) beseitigt diese Duplizierung, indem diese Komponenten über GPUs geshardet statt repliziert werden:

• Stage 1 – Optimizer States partitionieren. Jede GPU speichert nur 1/N der Optimizer States (FP32 Master Weights sowie Adams erste und zweite Moments, 12 Bytes/Parameter). Wenn eine GPU ein Weight aktualisieren muss, aktualisiert sie nur ihren Slice und broadcastet das Ergebnis. Unter den folgenden Annahmen sinkt der Memory-Bedarf von ~120 GB auf ~41,3 GB pro GPU.
• Stage 2 – zusätzlich Gradients partitionieren. Gradients werden nicht mehr an jede GPU all-reduced. Jede GPU erhält über Reduce-scatter nur den benötigten Gradient Slice. Unter denselben Annahmen sinkt der Memory-Bedarf auf ~28,1 GB pro GPU.
• Stage 3 – zusätzlich Model Weights partitionieren. Jede GPU hält nur 1/N der FP16 Weights. Vor dem Forward oder Backward Pass jedes Layers ruft die GPU All-gather auf, um die vollständigen Layer Weights temporär aus den anderen GPUs zu rekonstruieren. Sie rechnet und verwirft die gesammelten Weights anschließend. Unter denselben Annahmen sinkt der Memory-Bedarf auf ~15,0 GB pro GPU.

Dies sind ungefähre Model-State-Werte für ein Model mit 7,5B Parameters auf 8 GPUs (World Size $N=8$), mit FP16 Weights und Gradients sowie FP32 Adam Master Weights, Momentum und Variance. Activations, temporäre All-gather Buffers, Allocator Fragmentation und Framework-/Runtime-Overhead sind ausgeschlossen. Die Berechnung basiert auf $7.5B \times$ Bytes pro Parameter. Jeder State wird nur dann durch $N$ geteilt, wenn die Tabelle ihn als partitioniert markiert.

Der Trade-off ist Communication. Stage 1 fügt nur minimalen Overhead hinzu, Stage 2 ersetzt All-reduce durch Reduce-scatter bei ähnlichen Kosten. Stage 3 benötigt All-gather Calls vor jedem Layer im Forward und Backward Pass und ungefähr 1,5x Communication Volume gegenüber Standard Data Parallelism.

ZeRO-Infinity erweitert Stage 3, indem partitionierte States auf CPU RAM und sogar NVMe SSDs ausgelagert werden. Dadurch kann Training von Models mit Trillionen Parameters auf begrenzten GPU Clusters möglich werden. Storage Offload erzeugt PCIe- und Storage-Transfer-Kosten. Die gemessene Auswirkung hängt von Drive, PCIe Topology, Partitioning, Prefetch, Transfer Overlap und Workload ab. Verwende es zur Erfüllung von Capacity Requirements, statt einen festen Slowdown anzunehmen, und profile die Ziel-Configuration.

28. FSDP: PyTorch-natives Sharding

Fully Sharded Data Parallel (FSDP) ist PyTorchs integrierte Antwort auf DeepSpeed ZeRO-3. Es shardet Parameters, Gradients und Optimizer States über GPUs nach derselben Kernidee. Die Mechanik für jeden Layer ist ein einfacher Loop:

1. All-gather der vollständigen Parameters von allen GPUs (temporäre Rekonstruktion des vollständigen Layers).
2. Compute des Forward- oder Backward Pass für diesen Layer.
3. Freigeben der gesammelten Parameters unmittelbar danach. Jede GPU behält nur ihren eigenen Shard.
4. Reduce-scatter der Gradients, sodass jede GPU nur ihren zugewiesenen Gradient Slice erhält.

Da FSDP in PyTorch integriert ist, lässt es sich direkt in PyTorch Debugging Tools, Profilers und torch.compile integrieren. Die Performance im Vergleich zu DeepSpeed ZeRO-3 hängt von Wrapping Policy, Communication Topology, Offload Settings und Model Size ab. Vergleiche beide auf demselben Cluster.

FSDP2 (2024–2025) ist ein Rewrite, der die torch.compile-Integration für bessere Kernel Fusion verbessert, über TorchAO FP8 Training ergänzt und die API vereinfacht. Sowohl FSDP als auch DeepSpeed sind über Hugging Face Accelerate zugänglich, sodass du mit einer einzigen Config-Änderung zwischen ihnen wechseln kannst.

29. Scaling Laws und die Chinchilla-Falle

Chinchilla Scaling (DeepMind, 2022) fand unter seinen Annahmen eine Compute-optimale Allokation nahe 20 Training Tokens pro Parameter. Dieses Objective berücksichtigt keine nachgelagerten Serving Costs. Wenn ein kleineres Model mit mehr Data die erforderliche Quality erreicht, kann es über den gesamten High-Volume-Inference-Lifecycle weniger kosten.

Eine Strategie für Lifecycle Cost besteht darin, ein kleineres Model mit deutlich mehr Data zu trainieren:

Dies ist das angezeigte Tokens-per-Parameter-Verhältnis geteilt durch den ungefähren 20-Tokens-per-Parameter-Punkt des Chinchilla-Papers. Es handelt sich um ein deskriptives Verhältnis, nicht um einen gemessenen Quality- oder Cost-Multiplier.

Bei einem mit hohem Volume servierten Model kann zusätzlicher Training Compute für ein kleineres Model die Lifecycle Cost reduzieren. Llama 3 8B illustriert diese Strategy. Ob sie gewinnt, hängt jedoch von der erforderlichen Quality und dem erwarteten Inference Volume ab. „Chinchilla-optimal“ bezieht sich auf die Effizienz des Training Compute und ist ein anderes Objective als Lifecycle Cost.

30. RLHF, DPO, GRPO und die Alignment-Landschaft

Alignment steuert ein Pretrained Model auf gewünschte Instructions, Preferences und Safety Policies zu. Es garantiert nicht automatisch Truthfulness oder Safe Behavior. Die folgenden Methods tauschen Implementation Complexity, Data Requirements, Exploration und Training Stability gegeneinander aus.

Die klassische RLHF Pipeline: SFT → Human Preference Pairs sammeln → ein Reward Model auf diesen Pairs trainieren → die Policy mit PPO (Proximal Policy Optimization) fine-tunen. PPO hält gleichzeitig 4 Model Copies im Memory (Policy, Reference, Critic/Value Model und Reward Model) und reagiert empfindlich auf Hyperparameters. Außerdem ist es anfällig für Reward Hacking, bei dem das Model Eigenheiten des Reward Models ausnutzt – etwa verbose, selbstsicher klingende Antworten –, statt die Quality tatsächlich zu verbessern.

DPO (Direct Preference Optimization) überspringt das gelernte Reward Model und den Online-RL-Loop, indem es einen Loss direkt auf Preference Pairs optimiert. Das vereinfacht die Training Pipeline. Standard-DPO ist offline: Es trainiert auf einem festen Dataset und exploriert im Update Loop keine neuen Responses. Ob diese Einschränkung relevant ist, hängt von Task und Data Coverage ab.

GRPO (Group Relative Policy Optimization, DeepSeek) entfernt den gelernten Critic von PPO, indem es mehrere Completions pro Prompt generiert und Group-relative Rewards als Baseline verwendet. Dadurch sinkt die Model-State-Last gegenüber einem typischen PPO Setup. Anders als DPO ist GRPO On-policy: Das Model generiert während des Trainings frische Responses. DeepSeek-R1 kombiniert GRPO mit RLVR (Reinforcement Learning from Verifiable Rewards) und verwendet Checks wie Math Answers, Code Compilation und Unit Tests. Diese Rewards sind leichter zu auditieren als ein gelernter Preference Score. Unvollständige Tests und Proxy Objectives können jedoch weiterhin ausgenutzt werden.

31. Distillation: Wissen zwischen Models komprimieren

Knowledge Distillation überträgt Capabilities von einem großen Teacher auf einen kleineren Student. Logit-based Distillation trainiert den Student darauf, die Output Distribution des Teachers nachzubilden. Data-based Distillation lässt den Teacher Examples generieren, auf denen der Student fine-getunt wird. Data-based Methods sind für LLMs verbreitet, weil sie architekturübergreifend und mit API-only Teachers funktionieren können. Ihr Wert ist jedoch durch Teacher Quality, Data Coverage, Filtering und Generation Cost begrenzt.

DeepSeek-R1 kuratierte eine Mischung von ungefähr 800.000 Examples – etwa 600.000 Reasoning-bezogene Samples und 200.000 Non-Reasoning Samples – und verwendete sie zur Distillation von Qwen2.5- und Llama-3-Models mit 1,5B bis 70B Parameters. In der Evaluation des Papers:

• DeepSeek-R1-Distill-Qwen-32B erreicht 72,6 % auf AIME 2024 und 94,3 % auf MATH-500 und liegt damit über den im Paper berichteten Werten von OpenAI o1-mini.
• DeepSeek-R1-Distill-Qwen-7B erreicht 55,5 % auf AIME 2024 und liegt damit über dem Ergebnis von QwQ-32B-Preview des Papers, obwohl es ein kleineres Model ist.

In den Small-Model-Experiments von DeepSeek-R1 übertraf Distillation direktes GRPO auf den getesteten Base Models. Dieses Ergebnis spricht in diesem Setup für Distillation; es etabliert kein universelles Ranking zwischen Distillation und RL.

32. Synthetic-Data Generation

LLM-generated Training Data wird in mehreren wiederkehrenden Patterns eingesetzt:

• Self-Instruct bootstrapped aus einem kleinen Seed Set von Human-written Instructions: Das LLM generiert neue Instructions, Inputs und Outputs, die gefiltert und wieder dem Pool hinzugefügt werden. Das Alpaca-Projekt verwendete 52.000 Examples, generiert aus 175 Seeds. Stanford berichtete eine Data Generation unter $500 and fine-tuning under$100 und setzte damit die anfänglichen Reproduction Costs unter $600. Der GPT-3.5-Vergleich war eine begrenzte Project Evaluation und keine breite Äquivalenz.
• Evol-Instruct (WizardLM) nimmt bestehende Instructions und entwickelt sie entlang von Complexity Axes iterativ weiter – etwa durch zusätzliche Constraints, tieferes Reasoning oder konkretere Problems –, um schrittweise schwierigere Training Examples zu erzeugen.
• Microsofts Phi-4 (14B) verwendete für einen großen Teil des Pretraining Synthetic Data, einschließlich Generation, Critique, Self-Revision und Instruction Reversal. Der Technical Report vergleicht die resultierende STEM- und Coding-Performance auf den ausgewählten Benchmarks mit größeren Models.

Das relevante Risiko ist Model Collapse: Wenn Models rekursiv mit Synthetic Data aus vorherigen Generationen trainiert werden, verschwinden die Tails der ursprünglichen Distribution schrittweise. Das Model überschätzt häufige Patterns und verliert seltene, aber wichtige Variationen (Shumailov et al., 2024). Eine separate Ahrefs Classifier Study sammelte im April 2025 pro Domain eine neu erkannte englische Seite aus 900.000 Domains und klassifizierte 74,2 % als Seiten mit einem gewissen Anteil AI-generated Text. Diese Vendor Study ist keine Census des Webs. Die Mitigation beginnt mit dem Mischen synthetischer und realer Data, Filtering und Lineage Tracking, damit rekursiv generiertes Material messbar bleibt.

Part VI — Scaling and deployment

Wenn ein Workload nicht mehr auf ein einzelnes Device passt oder sein SLO erfüllt, geht es um die Fragen, wie Arbeit aufgeteilt wird, welcher Runtime die benötigten Controls bereitstellt und ob jeder Request dasselbe Model benötigt.

33. Vier Formen von Parallelism

Tensor Parallelism (TP) teilt einzelne Weight Matrices über GPUs auf und kommuniziert normalerweise nach jedem Layer. Schnelle Intra-Node Links wie NVLink machen diesen Ansatz innerhalb eines Nodes besonders praktikabel. Mehr Shards reduzieren Memory und Compute pro Device, erhöhen aber die Communication. Wähle den Degree mit einem Latency Benchmark.

Pipeline Parallelism (PP) teilt Layers sequenziell über GPUs auf und übergibt Activations zwischen Stages. Das Communication Pattern kann über Nodes hinweg funktionieren, doch Pipeline Bubbles und ungleichmäßige Stage Times reduzieren die Utilization. Große Deployments kombinieren häufig TP innerhalb eines Nodes und PP über Nodes hinweg.

Data Parallelism (DP) repliziert das Serving Model, sodass jedes Replica unabhängige Requests ohne per-Request Cross-replica Communication verarbeitet. Das ist effizient, wenn das Model passt und Traffic ausbalanciert werden kann. Im Training wird DP häufig mit ZeRO oder FSDP kombiniert, um State zu sharden.

Expert Parallelism (EP) verteilt MoE Experts über GPUs und verwendet für Token Routing All-to-all Communication. Die Performance hängt von Token Balance, Expert Placement und Interconnect Topology ab. All-to-all Traffic kann zum dominanten Bottleneck werden.

Eine Ausgangs-Heuristik für Parallelism:

• Model passt auf eine GPU: Beginne mit unabhängigen Replicas und miss die DP-Skalierung.
• Model passt innerhalb eines Nodes: Teste TP innerhalb des Nodes und repliziere die Gruppe anschließend, wenn der Traffic dies erfordert.
• Model erstreckt sich über Nodes: Teste eine Kombination aus TP und PP gegen Interconnect und Latency Target.
• Mixture of Experts: Füge EP nur hinzu, wenn Expert Placement dies erfordert.

34. Serving Frameworks im Vergleich

vLLM bietet paged KV Allocation, Continuous Batching, eine OpenAI-kompatible API und mehrere Parallelism-Modi. Model- und Hardware-Support ändern sich häufig. Prüfe deshalb das Ziel-Model gegen die aktuelle Compatibility Matrix.

SGLang kombiniert RadixAttention für Prefix Reuse, einen Custom Scheduler und Structured Generation. Die veröffentlichten Throughput Gains hängen von Workload und Configuration ab. Vergleiche SGLang mit vLLM und TensorRT-LLM anhand identischer Prompts, Outputs, Hardware und SLOs.

TensorRT-LLM zielt über CUDA Graph Fusion und Kernel Optimization auf niedrige Single-Request-Latency und bietet nativen FP8/FP4-Support. Die veröffentlichten Zahlen sind Hardware- und Model-spezifisch. Der Trade-off ist eine steilere Lernkurve und eine NVIDIA-spezifische Deployment Surface.

TGI integriert sich in das Hugging-Face-Ecosystem und unterstützt mehrere Hardware Backends. Prüfe vor der Auswahl für ein neues Deployment den aktuellen Maintenance- und Feature-Status des Repositories.

Ollama legt den Schwerpunkt auf einen einfachen lokalen Model Workflow. Nutze es für Development Convenience. Wenn hohe Concurrency oder explizite SLO Controls relevant sind, benchmarke einen anderen Serving Stack.

llama.cpp ist eine portable C/C++ Runtime mit ARM-, x86-, Metal-, CUDA-, ROCm- und Vulkan-Pfaden. GGUF unterstützt mehrere Quantization Levels. Die Performance variiert stark nach Model, Quantization, Context und Backend. Verwende das lokale Benchmark Tool für die Zielmaschine.

35. GPU-Auswahl für Inference

Die Tabelle vergleicht veröffentlichte Hardware-Charakteristika. Vendor Precision Support macht Peak-Compute-Zahlen über Formate hinweg nicht direkt vergleichbar. Wähle daher zuerst nach Memory Fit und benchmarke den Ziel-Workload. Prüfe aktuelle Cloud Prices separat, da sie nach Provider, Region, Commitment und Verfügbarkeit variieren.

Wähle zuerst nach Memory Fit, danach nach gemessenem Throughput beim Ziel der Latency. Die 141 GB Kapazität der H200 kann einige Large-Model-Deployments vereinfachen. B200 ergänzt FP4-Support, 180 GB HBM3e und eine neuere NVLink-Generation. Kleinere GDDR-basierte GPUs können für Quantized Models wirtschaftlich sein, wenn ihre Memory- und Interconnect-Limits zum Workload passen.

AWQ und GPTQ bedienen 4-Bit-Models, indem unterstützte Matrix Operations in ein Compute Format wie FP16 oder BF16 dequantisiert werden. Compatibility und Speed hängen weiterhin von Model Architecture, Quantization Format, Serving Backend, Kernel und GPU ab. Prüfe deshalb die Support Matrix des Backends und benchmarke das exakte Artifact. Hopper (H100/H200) und Ada (L40S/4090) beschleunigen FP8 nativ; Blackwell (B200) ergänzt native FP4 Tensor Cores. Alle aufgeführten GPUs unterstützen INT8 Matrix Operations.

LLM Decode ist häufig Memory-bandwidth-bound. Deshalb können HBM Capacity und Bandwidth für Serving Workloads wichtiger sein als Peak TFLOPS. Vergleiche GPUs bei konstantem Model, Precision, Batch Distribution, Context Length und Latency Target.

36. Model Cascading und Routing

Model Routing wählt anhand vorhergesagter Complexity oder Capability, welches LLM einen Query verarbeitet. RouteLLM (LMSYS/UC Berkeley, ICLR 2025) berichtet in seinem MT-Bench-Setup eine Kostenreduktion von 85 % bei Beibehaltung von 95 % der GPT-4-Quality-Baseline. Ob sich Routing lohnt, hängt von aktuellen Prices, Traffic Mix, Router Errors und Quality Floor ab.

Router reichen von Lightweight Classifiers bis zu LLM-based Judges. Cascading ist die sequenzielle Variante: Ein Query startet bei einem günstigeren Model und wird eskaliert, wenn eine Scoring Function die Antwort ablehnt. FrugalGPT berichtet im evaluierten Model Pool bis zu 98 % niedrigere Kosten oder bis zu 4 % höhere Accuracy. Ein Production Cascade benötigt kalibrierte Escalation Criteria und Monitoring für Queries, die das günstige Model fälschlicherweise akzeptiert.

Part VII — Applications

Applications bringen eigene Failure Surfaces mit. Retrieval kann bereits vor Beginn der Generation scheitern, Agents können eine ungültige Action auswählen, und eine Prompt-Änderung kann eine Task verbessern und gleichzeitig eine andere beschädigen.

37. Embedding Models versus Generative Models

Embedding Models encoden Text in Vectors fester Dimension, die semantische Bedeutung erfassen. Anders als Generative Models, die Token Sequences erzeugen, geben sie einen dichten Vector für den Input aus, typischerweise mit einigen hundert bis mehreren tausend Dimensions. Ihre Backbones umfassen Bidirectional Encoder-only Transformers und von Decodern abgeleitete Models, die für Representation Learning angepasst wurden. Eine Pooling Layer reduziert Per-Token Representations häufig über Mean Pooling, einen speziellen Classification Token oder eine Model-spezifische Last-Token-Method zu einem einzelnen Vector. Contrastive Fine-Tuning bringt semantisch ähnliche Texte näher zusammen und drückt unähnliche Texte auseinander.

Aktuelle Embedding Systems decken unterschiedliche Deployment Needs ab. Qwen3-Embedding-8B unterstützt konfigurierbare Output Dimensions und viele Sprachen. Gemini Embedding 2 akzeptiert Text, Images, Video, Audio und Documents. pplx-embed-v1-4B untersucht Dense Embeddings mit niedrigerer Precision. OpenAI text-embedding-3-large unterstützt kürzere Embeddings über seinen Dimensions Parameter. Dies sind Beispiele, kein Ranking. Evaluiere Language, Modality, Task, Dimension und Serving Cost auf demselben Retrieval Set.

Matryoshka Representation Learning (MRL, Kusupati et al., NeurIPS 2022) macht Embedding Dimensions flexibel. Benannt nach russischen Matrjoschka-Puppen strukturiert MRL ein Embedding so, dass seine ersten $m$ Dimensions ebenso informativ sind wie ein unabhängig trainiertes $m$-dimensionales Model. Während des Trainings aggregiert MRL Losses über eine gewählte $O(\log d)$-Menge von Prefix Dimensions, üblicherweise konsistente Halbierungen; das 2048-dimensionale Beispiel des Papers verwendet $\{8, 16, \ldots, 1024, 2048\}$. Der aggregierte Loss sorgt dafür, dass die führenden Dimensions grobe semantische Informationen tragen, während spätere Dimensions feinere Details hinzufügen.

Nach dem Training kann ein MRL Embedding auf eine unterstützte Prefix Dimension gekürzt werden. OpenAI berichtet, dass text-embedding-3-large mit 256 Dimensions text-embedding-ada-002 mit 1.536 Dimensions im zitierten MTEB-Vergleich übertrifft. Das ergibt eine 6-fache Reduktion des Raw Vector Storage. Search Latency und Database Cost hängen außerdem von Index, Metadata, Filtering und Hardware ab.

Das Embedding Model ist eine wichtige Komponente in einer RAG Pipeline, neben Parsing, Chunking, Search, Reranking und Generation. Wenn relevante Evidence nicht retrieved wird, kann ein stärkerer Generator sie nicht zuverlässig wiederherstellen.

38. RAG Architecture in Production

Retrieval-Augmented Generation versorgt ein LLM zur Query Time mit retrieved Documents. Dadurch kann es aktuelle oder private Evidence liefern, die in den Model Weights fehlt. Retrieval garantiert jedoch nicht, dass die Antwort diese Evidence korrekt verwendet. Ein Production-RAG-System ist eine Multi-stage Pipeline, deren Stages separat evaluiert werden müssen.

Die Ingestion Pipeline läuft offline. Raw Documents (PDFs, HTML, Markdown, Databases) werden zunächst in Clean Text geparsed. Das ist schwieriger, als es klingt: Allein PDF Parsing kann Tables, Headers und Formatting verlieren. Anschließend wird der Text in Chunks aufgeteilt, die unabhängig voneinander embedded und indexed werden.

Chunking beeinflusst sowohl Retrieval Recall als auch den Context, der dem Generator zur Verfügung steht. Sinnvolle Sizes hängen von Document Structure, Query Granularity, Embedder Limits und Reranker Limits ab. Häufige Ansätze sind Fixed-size with Overlap, Recursive Splitting entlang von Document Boundaries und Semantic Chunking anhand von Embedding Similarity. Vergleiche sie mit Relevance Labels auf Page- oder Section-Level, statt universell einen Token Range zu übernehmen.

Jeder Chunk wird anschließend mit einem Model wie in Section 37 embedded und in einer Vector Database (Pinecone, Weaviate, Qdrant, pgvector usw.) gespeichert.

Die Retrieval Pipeline läuft zur Query Time. Beginne mit einer messbaren Baseline und füge Stages erst hinzu, wenn Error Analysis zeigt, dass sie einen realen Miss adressieren:

• Hybrid Search kombiniert Dense Vector Retrieval mit Sparse Retrieval wie BM25 und merged die Ergebnisse häufig über Reciprocal Rank Fusion (RRF). Dense Search verarbeitet semantische Paraphrases; Sparse Search findet exakte Identifiers, Error Codes und Acronyms. Vendor Benchmarks berichten Gains gegenüber Vector-only Baselines, aber deren Größe hängt von Corpus und Relevance Labels ab.
• Reranking gibt retrieved Candidates an ein Model, das Query und Document gemeinsam scored. Dadurch kann Fine-grained Relevance steigen, allerdings um den Preis eines weiteren Model Calls. Candidate Count, Retained Count und Latency sollten gemeinsam getuned werden. Die vollständige Multi-stage Pipeline habe ich in Building a Modern Search Ranking Stack behandelt.
• Query Transformation schreibt die User Query vor dem Retrieval um, um Recall zu verbessern. HyDE (Hypothetical Document Embeddings) lässt das LLM eine hypothetische Antwort generieren, die anschließend embedded und für Retrieval verwendet wird. Multi-query Expansion erzeugt mehrere Phrasings derselben Frage. Step-back Prompting stellt zunächst eine allgemeinere Frage, um breiteren Context abzurufen.

Häufige Failure Modes:

• Retrieval Failure – Das korrekte Document existiert, wird aber nicht retrieved. Teste Chunking, Query Transformation, Hybrid Search und Metadata Filtering gegen den Miss.
• Context Poisoning – Irrelevante retrieved Chunks führen das LLM in die Irre. Teste Reranking, Context Filters und kleinere Retained Sets.
• Lost-in-the-middle – In den getesteten Multi-document-Question-Answering- und Key-Value-Retrieval-Settings fanden Liu et al., dass die Answer Performance im Allgemeinen am höchsten war, wenn relevante Information am Anfang oder Ende des Inputs erschien, und niedriger, wenn sie in der Mitte stand.

GraphRAG (Microsoft, 2024) ergänzt Vector Retrieval durch einen extrahierten Entity- und Relationship-Graph. Es zielt auf Corpus-level und Relationship-heavy Questions, die Flat Chunk Retrieval möglicherweise verfehlt. Der Trade-off besteht in zusätzlicher Extraction-, Indexing-, Storage- und Evaluation-Arbeit.

Practitioner Guides veröffentlichen Latency Ranges für Embedding, Search, Reranking und Generation. Diese Zahlen variieren jedoch nach Region, Corpus, Hardware und Model. Miss jede Stage in Traces und evaluiere die Quality-Änderung, bevor du zusätzliche Latency akzeptierst.

39. Agent Architectures und Tool Calling

LLM Agents verwenden Models, um Tool Calls rund um einen sich verändernden State auszuwählen und zu sequenzieren. Drei nützliche Orchestration Patterns sind:

• ReAct – wechselt zwischen Action Selection und Observations. Es kann sich nach jedem Tool Result anpassen, doch eine wachsende History erhöht Token- und Latency Costs.
• ReWOO – plant Tool Calls mit Placeholders, führt unabhängige Arbeit parallel aus und synthetisiert anschließend. Das Paper berichtet Token Savings gegenüber ReAct. Der fixe Plan benötigt jedoch einen expliziten Recovery Path für den Fall, dass ein Tool fehlschlägt.
• Planner-executor – trennt Planning und Execution und kann nach einem Failure eine Re-planning Policy hinzufügen. Dies erlaubt Model Specialization, fügt aber Orchestration State und eine weitere Decision Boundary hinzu.

Function Calling ist ein verbreiteter Mechanism für Tool Invocation. APIs stellen Tool Definitions bereit und geben Structured Arguments zurück, wodurch der Bedarf an der Auswertung von Free-form Text sinkt. Schema-valide Arguments können trotzdem das falsche Tool auswählen oder ungültige Values enthalten. Parallel Function Calling kann Round Trips reduzieren, wenn Operations unabhängig voneinander sind.

Structured Output und Constrained Decoding erzwingen ein Schema, indem die verfügbaren Tokens bei jedem Generation Step eingeschränkt werden. Engines wie xgrammar, die in vLLM und SGLang verwendet werden, können in unterstützten Configurations viele Syntax- und Parsing Failures mit geringem Overhead beseitigen. Sie garantieren nicht, dass extrahierte Values oder Decisions korrekt sind. Schema-Guided Reasoning (SGR) nutzt Field Order und Schema Structure, um Intermediate State vor der finalen Decision inspizierbar zu machen. Seine drei Patterns sind Cascade (sequenzielle Steps), Routing (Union Types als semantische Switches) und Cycle (begrenzte Lists).

Tool-Selection Quality, End-to-End-Latency und Token Cost verschlechtern sich normalerweise, wenn Tool Set und Action Depth wachsen. Miss diese Curves mit den tatsächlichen Tool Descriptions und der Failure Distribution. Frameworks wie LangGraph können State und Recovery Paths explizit machen, nehmen dir aber nicht die Evaluation ab.

40. Prompt Engineering für Production

Production Prompting ist ein Evaluation Problem: Ändere einen Teil des Prompts oder Contexts und miss anschließend Task Quality und Failure Modes. Die folgenden Techniques sind übliche Startpunkte, keine universelle Reihenfolge.

Few-shot Examples sind häufig effektiv zur Kontrolle des Output Formats. Beginne mit 3–5 Examples, die Empty Inputs, Ambiguous Queries und Multipart Answers abdecken, und miss das Ergebnis auf einem Held-out Set. Die Examples sollten die reale Input Distribution abdecken, nicht nur den Happy Path. Mehr Examples verbrauchen Context und garantieren keine weiteren Gains.

Chain-of-thought (CoT) Prompting fordert ein Model auf, Intermediate Reasoning vor der Antwort offenzulegen. Kojima et al. berichteten in ihren getesteten Reasoning Tasks Gains durch das Suffix „Let’s think step by step“. Der Effekt variiert jedoch je nach Model, und neuere Reasoning APIs stellen möglicherweise keine Hidden Traces bereit. Für Production solltest du eine inspizierbare Task Decomposition oder eine knappe Rationale bevorzugen, wenn sie für den Evaluator nützlich ist. Self-consistency (Wang et al., 2023) sampled mehrere Reasoning Paths und aggregiert die Answers. Das tauscht zusätzliche Inference Costs gegen Robustheit bei geeigneten Tasks.

Structured Output mit expliziten JSON Schemas (Section 39) beseitigt viele Parsing Failures. Constrained-Decoding Engines wie xgrammar können die unterstützte Grammar während der Generation erzwingen. Factual Accuracy und Semantic Validity müssen weiterhin evaluiert werden, und nicht unterstützte Schema Features benötigen möglicherweise zusätzliche Behandlung.

Prompt Chaining zerlegt eine Task in fokussierte Stages, zum Beispiel Intent klassifizieren → Context retrieven → Response generieren → Output validieren. Dadurch lassen sich Failures lokalisieren, unterschiedliche Models pro Stage einsetzen und cachebare Intermediate States offenlegen. Es fügt jedoch Interfaces und Latency hinzu. Vergleiche es daher mit einer Single-call-Baseline.

Temperature verändert die Sampling Distribution. Niedrige Values sind ein sinnvoller Ausgangspunkt für Classification oder Extraction; höhere Values können die Diversity bei Ideation erhöhen. Das exakte Verhalten unterscheidet sich zwischen Model APIs und interagiert mit top_p, top_k und Provider Defaults. Sweep daher die unterstützten Settings für die konkrete Task, statt einen Bereich zu kopieren.

Die Trennung von System- und User Messages hält persistente Policy von Request-spezifischem Content getrennt. Chat Templates und Instruction Tuning geben diesen Roles unterschiedliche Priorität, machen eine System Message jedoch nicht zu einer Enforcement Boundary. Lege stabiles Verhalten in die System Message, halte untrusted Data in User- oder Tool Content und setze harte Constraints wie PII Removal zusätzlich außerhalb des Models durch.

Context Engineering erweitert die Prompt-Arbeit auf die Zusammenstellung von Retrieved Documents, Tool Results, Conversation History und Examples. Liu et al. fanden einen Lost-in-the-middle-Effekt in den von ihnen getesteten Long-context Models. Die Position sollte daher Teil der Evaluation sein und nicht als irrelevant angenommen werden. Den umfassenderen Workflow habe ich in Context Engineering for AI Agents behandelt.

Part VIII — Production operations

Production Operations übersetzt die vorherigen Konzepte in Admission Limits, Load Tests, Alerts und Capacity Decisions unter realem Traffic.

41. Rate Limiting für Requests mit variablen Kosten

Traditionelles Requests-per-Second Rate Limiting setzt ungefähr gleiche Kosten pro Request voraus. LLMs brechen diese Annahme. Ein 10-Token-Classification-Prompt und eine 100K-Token-Dokumentanalyse treffen denselben API Endpoint, unterscheiden sich bei den Kosten aber um vier Größenordnungen. Rate Limiting nach RPS lässt entweder teure Requests unkontrolliert passieren oder benachteiligt günstige Requests unnötig.

Production Systems benötigen Token-based Rate Limiting über mehrere Dimensions. OpenAI dokumentiert Request- und Token Limits nach Usage Tier. Anthropic trennt Input-Token- und Output-Token-Limits. Exakte Quotas und Algorithms können sich ändern. Behandle daher die Provider Documentation als Source of Truth. Der architektonische Punkt ist, Requests und Tokens unabhängig zu budgetieren.

Das praktische Implementation Pattern ist eine Multi-dimensional Limit Hierarchy (User → Application → Organization → Global) mit Priority Tiers für Premium Access. Auf Request Level ist Token Budget Reservation entscheidend: Schätze beim Admission Time die Total Tokens (Input + max_tokens), ziehe sie vom Bucket ab und korrigiere nach Abschluss des Requests mit der tatsächlichen Usage. So verhindert das System, dass ein Burst langer Generation Requests die Capacity erschöpft, bevor überhaupt Output produziert wird.

Für Self-hosted Deployments entspricht dies Provisioned Throughput: dedizierte GPU Capacity für Ziel-Token-Rates reservieren. Bei vLLM Deployments bedeutet das, Admission Control um Active Decode Slots und KV-cache Pressure statt nur um Request Count herum zu konfigurieren. Wie Section 5 erklärt, benötigen Throughput und Admission beide Token-aware Limits.

42. Failure Modes, gegen die du designen solltest

LLM Serving bringt Failure Modes mit sich, die an variable Sequence Lengths, KV Memory und lang laufende Decode-Arbeit gekoppelt sind. Entwirf und Load-teste die Gegenmaßnahmen, bevor Production Traffic von ihnen abhängt.

Out-of-Memory (OOM) ist ein häufiger Failure. Ein 70B FP16 Model benötigt allein für die Weights etwa 140 GB. Der KV cache für eine einzelne Sequence mit 128K Context bei Llama 3.1 70B kann unter den Annahmen in Section 6 weitere 40 GB benötigen. Die Lücke zwischen „passt in Memory“ und „OOM unter Load“ ist kleiner, als sie aussieht, weil ein Batch aus Long-context Requests mehr KV Memory verbrauchen kann als erwartet. Prevention kombiniert eine gemessene Memory Reserve mit Quantization und Paged KV Allocation. Für Workloads mit hohem KV Pressure kann LMCache KV Data auf CPU Memory oder Disk auslagern. Verwende seine veröffentlichten Results als Startpunkt und benchmarke die lokale Memory Hierarchy.

Preemption tritt auf, wenn KV-cache Pressure den Scheduler zwingt, Arbeit zu evicten oder neu zu berechnen. Die exakte Strategy hängt von Serving Version und Configuration ab. Aus Usersicht zeigt sich das als höhere End-to-End-Latency ohne offensichtlichen Application Error. Beobachte Preemption Counts und korreliere sie mit KV Use, Queue Depth und Request Lengths.

Tail Latency kann ansteigen, wenn große Prefills Decode Work verzögern. Chunked Prefill (Section 7) und Length-aware Scheduling adressieren diese Interferenz. Das Learning-to-Rank-Scheduler-Paper und CascadeInfer berichten in ihren evaluierten Workloads Verbesserungen gegenüber ihren Baselines. Das genaue Ergebnis hängt jedoch von Request-Length-Distribution und Scheduler Configuration ab.

Cascading Failures können entstehen, wenn langsame Requests die Queue vergrößern, Upstream Clients timeouten und Retries zusätzlichen Load erzeugen. Gegenmaßnahmen umfassen Admission Control, Per-tenant Concurrency Limits, Output Caps, Retry Budgets und Gateway Circuit Breakers. Disaggregated Prefill- und Decode-Pools können helfen, wenn Load Tests anhaltende Phaseninterferenz zeigen.

43. LLM Systems monitoren

LLM Monitoring unterscheidet sich in einigen grundlegenden Punkten von klassischem API Monitoring. Jeder Request hat variable Costs, zwei unterschiedliche Phases mit verschiedenen Bottlenecks und einen Memory Footprint, der sowohl von Input Length als auch Generation Length abhängt. Standard Metrics wie Request Latency und Error Rate übersehen den größten Teil des Relevanten.

Goodput ist die Anzahl von Requests pro Sekunde, die alle definierten SLO Thresholds wie TTFT, TPOT und Total Latency erfüllen. Das ist eine nützliche kombinierte Metrik, weil Raw Throughput gesund aussehen kann, während Latency SLOs verfehlt werden: Ein System, das 100 Requests pro Sekunde verarbeitet, aber bei 40 % die Thresholds verfehlt, hat einen Goodput von 60 Requests pro Sekunde. Optimierung auf Goodput hält die Performance Distribution sichtbar, statt nur den Mean zu melden.

vLLM stellt unter /metrics einen Prometheus Endpoint bereit mit laufenden und wartenden Requests, KV-cache Use, Generation-Length-Distributions und Prefix-Cache-Statistics. Metriknamen können sich zwischen Releases ändern. Binde Dashboards daher an die deployte Version. Ein typischer Stack verwendet Prometheus für Metrics, Grafana für Visualization und OpenTelemetry-kompatible Traces über Application- und Serving-Komponenten hinweg.

Nützliche Alert Patterns umfassen Folgendes. Leite die Thresholds aus Load Tests ab, statt diese Beispiele unverändert zu übernehmen:

• Preemption Count steigt stark an – Die Runtime swapped oder recomputed Work, was ohne Application Error zusätzliche Latency erzeugt.
• KV-cache Utilization nähert sich der getesteten Preemption Region – Füge Capacity hinzu oder shed Load, bevor Evictions kaskadieren.
• Queue Depth liegt dauerhaft über dem getesteten Batch Envelope – Admission Control sollte beginnen, Requests abzulehnen oder nachrangig zu behandeln.
• TTFT steigt, während TPOT konstant bleibt – Diese Divergenz weist zuerst auf Queueing, Admission, Network oder Prefill Pressure hin, nicht auf Decode Throughput. Verwende Traces und Queue Metrics, um die Ursachen zu unterscheiden.

44. Cost Optimization: eine kumulative Strategy

Provider Prices und Input-to-output Price Ratios ändern sich. Hole vor einer Purchasing Decision aktuelle Rates ein. Model Tier und Output Length können die Rechnung bereits vor Infrastructure Optimizations dominieren.

Mehrere Ansätze lassen sich kombinieren, aber erst nachdem gemessen wurde, welche auf den Workload zutreffen:

1. Quantization von FP16 zu INT4 reduziert den Weight Memory um 75 %. Ob dies die Rechnung senkt, hängt von Kernel Speed, Batch Size und Hardware Utilization ab (Section 9).
2. Model Routing sendet geeigneten Traffic an günstigere Models. Miss die False-accept Rate des Routers und die End-to-End-Quality, bevor du den Anteil des günstigeren Models erhöhst (Section 36).
3. Prompt Caching reduziert wiederholte Prefix-Arbeit. Provider Discounts und Rate-limit Treatment ändern sich im Lauf der Zeit. Kombiniere deshalb die gemessene Hit Rate mit den aktuellen Terms (Section 16).
4. Batch APIs können Non-real-time Work wie Evals, Synthetic-data Generation und Bulk Classification günstiger machen. Prüfe aktuelle Prices und Completion Windows.
5. Self-hosting kann bei dauerhaft hoher Utilization gewinnen. Es gibt jedoch keinen universellen Token-volume Break-even. Berücksichtige neben GPU Rental auch Engineering, Orchestration, Observability, Capacity Slack und On-call Costs.

Die Multiplikation der illustrativen Factors ergibt eine große theoretische Reduction. Die Inputs sind jedoch nicht unabhängig: Quantization verändert Throughput, Routing verändert den Quality Mix, und Caching und Batching gelten nur für geeigneten Traffic. Erstelle die Schätzung aus gemessenen Traffic Shares und validiere sie gegen die Invoice.

45. Capacity Planning und Autoscaling

Capacity Planning für LLM Serving muss variable Request Costs, lang laufende Decode-Arbeit und sequenzabhängigen Memory-Bedarf berücksichtigen. Je nach Workload kann die limitierende Resource KV Memory, Memory Bandwidth, Compute oder Interconnect sein.

Das theoretische Memory Ceiling für Concurrent Requests ergibt sich aus dem KV-cache Budget:

$\text{max concurrent sequences} = \frac{\text{GPU memory} - \text{model weights} - \text{overhead}}{\text{per-sequence KV cache size}}$

Für die Capacity-Arithmetic nehmen wir an, dass die Runtime ein KV Budget von 40 GiB für Llama 3.1 70B mit FP16 KV cache bereitstellt. Jede 4K Sequence verwendet etwa 1,25 GiB, jede 128K Sequence etwa 40 GiB. Dieses Budget reicht damit vor Allocator-, Runtime-, Workload-Variance- und SLO-Overhead für höchstens etwa 32 4K Sequences oder eine 128K Sequence. Deshalb treiben GPU Selection und KV-cache Optimization den Capacity Plan direkt.

Die Capacity Formula für Fleet Sizing:

$\text{required GPUs} = \frac{\text{peak tokens/s} \times \text{safety-factor multiplier}}{\text{per-GPU tokens/s at target SLO}}$

Konvertiere beide Rates vor der Division in dieselbe Zeiteinheit. Entscheidend ist „at target SLO“. Ein Safety-factor Multiplier wie 1,3 reserviert 30 % Headroom. Wähle ihn anhand gemessener Burstiness, Failures und Recovery Time. Peak Token Throughput und SLO-compliant Throughput können bei steigender Concurrency stark auseinanderlaufen. Benchmarke mit der realen Prompt- und Output-Length-Distribution bei den erforderlichen TTFT- und TPOT-Thresholds, statt einen theoretischen Maximalwert zu verwenden.

GPU Utilization reicht als einziges Autoscaling Signal nicht aus, weil sie sowohl bei gesundem Processing als auch bei Overload hoch bleiben kann. Kombiniere sie mit Queue Depth, KV-cache Utilization und Goodput Degradation. Tune Thresholds anhand von Load Tests. Werte wie 80 % KV Utilization sind Startpunkte, keine universellen Limits. Diese Metrics werden in Section 43 eingeführt.

Scale-to-zero kann für Development- und Staging-Umgebungen mit langen Idle Periods geeignet sein. Serverless Inference Platforms und Kubernetes-basierte Autoscaler wie KEDA können Idle Capacity entfernen. Savings und Cold-start Time hängen jedoch von Model Size, Image- und Weight-Caching sowie Infrastructure ab. Miss Startup Time, bevor du dieselbe Policy für Latency-sensitive Production Traffic verwendest.

Verwende den Guide, um die nächste Messung auszuwählen

Die Konzepte interagieren, führen aber dennoch zu einer kleinen Menge nützlicher erster Measurements. KV-cache Demand begrenzt die Batch Size zusammen mit Weight Memory, Runtime Overhead und Request Lengths. Größere Batches können die Arithmetic Intensity erhöhen, während Continuous Batching den KV-allocation Churn steigert und PagedAttention die daraus resultierende Fragmentation reduziert.

Auf der Training-Seite kann Lifecycle Cost dafür sprechen, ein kleineres Model mit mehr Tokens zu trainieren, wie Llama 3 8B zeigt. GRPO reduziert die Critic-State-Last von PPO. Im getesteten Small-Model-Setup von DeepSeek-R1 übertraf Distillation direktes RL. Dies sind Optionen zur Evaluation, keine Rezeptur.

Routing, Caching, Quantization und Hardware Choice kumulieren nur dann, wenn jede Maßnahme gegen dasselbe Quality- und Latency Target evaluiert wird. Wähle ein Symptom, etabliere diese Baseline und mache die nächste Änderung leicht rückgängig.

Weiterführende Literatur

Verwandte Deep Dives aus diesem Blog, nach Topic organisiert:

• LLM Fine-Tuning Guide – wann Fine-Tuning gegenüber RAG und Prompt Engineering sinnvoll ist
• Open-Source LLM Variants and File Formats – Model Variants und Quantized Formats passend zur Hardware auswählen
• LoRAX Serving Guide – Tausende LoRA Adapters in Production serven
• Scaling Large Language Models – Multi-GPU- und Multi-Node-Strategien
• Local LLMs on macOS – praktisches Setup mit llama.cpp und Ollama
• AI Agent Reasoning Loops in 2026 – Deep Dive in ReAct-, ReWOO- und Planner-executor-Loops
• AI Agent Memory Architecture in 2026 – Checkpoints, Vector Stores und Document Memory für Stateful Agents

References

Nach Themenbereichen organisiert.

Inference und Attention

• FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness – Dao et al., NeurIPS 2022
• FlashAttention-2: Faster Attention with Better Parallelism and Work Partitioning – Dao, 2023
• FlashAttention-3: Fast and Accurate Attention with Asynchrony and Low-precision – Shah et al., NeurIPS 2024
• Flash-Decoding for long-context inference – Dao et al., 2023
• Efficient Memory Management for Large Language Model Serving with PagedAttention – Kwon et al., SOSP 2023
• Orca: A Distributed Serving System for Transformer-Based Generative Models – Yu et al., OSDI 2022
• GQA: Training Generalized Multi-Query Attention – Ainslie et al., 2023
• Triton: an intermediate language and compiler for neural network computations – Tillet et al., MAPL 2019
• FlashNorm: Fast Normalization for LLMs – 2024
• Deep Kernel Fusion for Transformers – DeepFusionKernel, 2026

Speculative Decoding

• Accelerating Large Language Model Decoding with Speculative Sampling – Chen et al., 2023
• EAGLE-3: Scaling up Inference Acceleration of Large Language Models – Li et al., NeurIPS 2025
• Medusa: Simple LLM Inference Acceleration Framework with Multiple Decoding Heads – ICML 2024

Quantization

• AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration – MLSys 2024 Best Paper
• GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers – Frantar et al., ICLR 2023
• Marlin: Mixed-Precision (FP16xINT4) LLM Inference Kernel – Frantar et al., 2024

Training und Fine-Tuning

• LoRA: Low-Rank Adaptation of Large Language Models – Hu et al., ICLR 2022
• QLoRA: Efficient Finetuning of Quantized LLMs – Dettmers et al., NeurIPS 2023
• ZeRO: Memory Optimizations Toward Training Trillion Parameter Models – Rajbhandari et al., SC20
• ZeRO-Infinity: Breaking the GPU Memory Wall for Extreme Scale Deep Learning – Rajbhandari et al., 2021
• Self-Instruct: Aligning Language Models with Self-Generated Instructions – Wang et al., ACL 2023
• WizardLM: Empowering Large Language Models to Follow Complex Instructions – Xu et al., ICLR 2024
• Phi-4 Technical Report – Microsoft, 2024
• AI models collapse when trained on recursively generated data – Shumailov et al., Nature 2024

Alignment

• Direct Preference Optimization: Your Language Model is Secretly a Reward Model – Rafailov et al., NeurIPS 2023
• DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models – GRPO eingeführt
• DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning – DeepSeek, 2025

Scaling und Architecture

• The Llama 3 Herd of Models – Meta, 2024
• LLaMA: Open and Efficient Foundation Language Models – Touvron et al. (Meta), 2023
• Llama 2: Open Foundation and Fine-Tuned Chat Models – Touvron et al. (Meta), 2023
• Qwen3 Technical Report – Qwen Team (Alibaba), 2025
• Training Compute-Optimal Large Language Models – Hoffmann et al. (Chinchilla), NeurIPS 2022
• RoFormer: Enhanced Transformer with Rotary Position Embedding – Su et al., 2021
• YaRN: Efficient Context Window Extension of Large Language Models – Peng et al., ICLR 2024
• SGLang: Efficient Execution of Structured Language Model Programs – Zheng et al., NeurIPS 2024
• Mixtral of Experts – Jiang et al. (Mistral AI), 2024

Embeddings

• Matryoshka Representation Learning – Kusupati et al., NeurIPS 2022
• pplx-embed-v1: Diffusion-Pretrained Dense and Contextual Embeddings – Perplexity AI, 2026

Agent Architectures

• ReAct: Synergizing Reasoning and Acting in Language Models – Yao et al., ICLR 2023
• ReWOO: Decoupling Reasoning from Observations for Efficient Augmented Language Models – Xu et al., 2023

Routing

• RouteLLM: Learning to Route LLMs with Preference Data – Ong et al., ICLR 2025

Benchmarks

• MLPerf Inference v5.0 Results – MLCommons, April 2025

Serving Architectures

• Taming Throughput-Latency Tradeoff in LLM Inference with Sarathi-Serve – Agrawal et al., OSDI 2024 (Chunked Prefill)
• Splitwise: Efficient Generative LLM Inference Using Phase Splitting – Patel et al., ISCA 2024 (Disaggregated Serving)
• DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving – Zhong et al., OSDI 2024 (Disaggregated Serving)

Serving Frameworks

• vLLM – PagedAttention-based Serving Engine
• SGLang – RadixAttention und Structured Generation
• TensorRT-LLM – NVIDIA-optimierte Inference
• llama.cpp – Portable C/C++ Inference
• DeepSpeed – Microsoft Distributed-Training-Library
• Ollama – Lokaler LLM Runner

Operations

• Efficient LLM Scheduling by Learning to Rank – Fu et al., NeurIPS 2024 (vLLM-LTR)
• CascadeInfer: Length-Aware Scheduling of LLM Serving with Low Latency and Load Balancing – Yuan et al., 2025
• Goodput metric as measure of ML productivity – Google Cloud, 2024
• vLLM Optimization and Tuning – vLLM Documentation
• vLLM Metrics – vLLM Documentation
• LMCache: KV Cache Management for LLM Serving – KV-cache Offloading
• OpenAI Rate Limits – OpenAI API Documentation
• Anthropic Rate Limits – Anthropic API Documentation