2026-03-13 · Aktualisiert 2026-07-15

[!NOTE] Automatische Übersetzung Dieser Artikel wurde automatisch aus der englischen Originalversion übersetzt.

LLM Ingenieurhandbuch: 45 Konzepte für Inference, Schulung, Architektur und Betrieb

Produktions-LLM-Systeme beziehen gleichzeitig Ressourcen aus GPU-Hardware, Systemingenieurwesen sowie ML-Theorien. Dasselbe begrenzte Konzeptensemble kommt zum Tragen, egal ob man TTFT für einen Chatbot optimiert oder DeepSpeed ZeRO für einen Fine-Tuning-Lauf konfiguriert. Diese Anleitung bündelt all diese Aspekte an einem Ort.

TL;DR: Dieser Leitfaden behandelt 45 Konzepte in acht Abschnitten – von Hardware und Inference über das Training, Deployment, bis hin zu den Betriebsabläufen. Jeder Eintrag definiert das jeweilige Konzept, erläutert seine praktischen Auswirkungen, gibt bei Bedarf numerische Beispiele zur Veranschaulichung der Größenordnung und verweist auf verwandte Abschnitte. Die angeführten Daten erstrecken sich vom Jahr 2024 bis Anfang 2026.

Dieser Leitfaden setzt voraus, dass Sie mit den grundlegenden Prinzipien von ML (Backpropagation, Gradientenabstieg, Softmax) sowie mit einigen Grundkenntnissen zu Systemarchitekturen vertraut sind – insbesondere zu Speicherverhältnissen in Hierarchien und grundlegenden Netzwerkkonzepten.

!!! Hinweis „Hinweis zum Anwendungsbereich“

Dies ist eine umfangreiche Referenz und kein linearer Leitfaden. Verwenden Sie die untenstehende Tabelle, um direkt zu dem Abschnitt zu springen, der zu Ihrer aktuellen Entscheidung passt.

Wie man dieses Handbuch als zentrales Referenzwerk nutzen kann

Diese Seite ist absichtlich weit gefasst. Nutzen Sie sie als Übersichtskarte und wechseln Sie anschließend zu den detaillierteren Beiträgen, sobald eine Entscheidung feststeht.

Der Weg mit dem höchsten Ertrag besteht in der Regel darin, das Bottleneck zu verstehen, den kleinstmöglichen Stack auszuwählen, der es unter Verwendung der tatsächlichen Arbeitslast Benchmark bereitstellt, und anschließend nur dort Komplexität hinzuzufügen, wo die Ergebnisse dies rechtfertigen.

Teil I – Hardwaregrundlagen

Die hier vorgestellten Konzepte – die arithmetische Intensität, die GPU-Speicherverwaltungshierarchie sowie die entsprechenden Hardwarebegriffe – kommen in diesem Leitfaden an allen anderen Stellen ebenfalls vor.

1. memorybasierte vs. rechenintensive Systeme sowie die Obergrenze Model

Der Ausgangspunkt für die Leistung von LLM ist die Arithmetikintensität: Für jeden Byte an Daten, den der GPU aus dem Speicher lädt, wie viele sinnvolle Berechnungen werden dabei durchgeführt? Dieses Verhältnis bestimmt, ob eine Operation rechenlastbedingt ist (durch Wartezeiten auf den Prozessor) oder speicherallastbedingt (durch Wartezeiten auf das Laden der Daten).

Jeder GPU weist einen Schwellenwert für die „kritische Intensität“ auf, ab dem seine Rechenleistung genau mit ihrer Speicherbandbreite ausbalanciert ist. Bei einem NVIDIA H100 (Datenblatt, 2023):

$\frac{989 \text{ TFLOPS}}{3,35 \text{ TB/s}} \approx 295 \text{ FLOPs/Byte}$

Die beiden Phasen von LLM Inference liegen auf entgegengesetzten Seiten dieses Schwellenwerts:

• Decode ist durch Speichermengen begrenzt. Die schrittweise Erzeugung von Tokens bedeutet, dass die mehrere Gigabyte große Weight-Matrix aus dem Speicher geladen werden muss, um sie mit einem einzelnen neuen Token zu multiplizieren. Bei einer vereinfachten 16-Bit-Analyse mit Batch-Verarbeitung liegt die Rechenleistung bei etwa 1 FLOP/Byte, was fast 300-mal unter dem Leistungsgrenzwert des H100 liegt. Dieser Unterschied erklärt, warum Decode in diesem Szenario nicht die maximale Rechenleistung von Throughput erreichen kann.
• Prefill ist durch Rechenleistung begrenzt. Die Verarbeitung der Eingabedaten Prompt erfordert zwar nur einen einmaligen Ladevorgang der Weights-Werte, doch es werden gleichzeitig Hunderte oder Tausende von Tokens damit multipliziert. Dadurch steigt die Rechenintensität deutlich über 295 an und führt zur Sättigung der Recheneinheiten.

Um Decode zu beschleunigen, ist es daher erforderlich, an der Speicherkapazität zu arbeiten: Man muss den Weights verringern. Quantization, die Speichernutzung für KV-Paare reduzieren durch GQA und PagedAttention, und die Intensität erhöhen mit Bündelung. Um Prefill zu beschleunigen, muss an der rohen Berechnung gearbeitet werden: schnellere GPUs- und FP8-Berechnungen.

2. GPU-Hierarchie

Ein GPU verfügt über vier Speicherschichten, die wie eine Pyramide angeordnet sind: einen großen, aber langsamen Hauptspeicher (HBM) am Boden sowie winzige, jedoch äußerst schnelle Register an der Spitze. Der Datenverkehr nach oben und unten in dieser Pyramide stellt die größte Engpassstelle dar. Die anspruchsvollste Bottleneck befindet sich zwischen HBM und SRAM, wobei SRAM in der Regel 10-mal schneller ist.

Von schnellstem bis langsamstem auf einem H100:

1. Register – das schnellste Speichermedium, das direkt an die Verarbeitungsschritte angebunden ist. Hier findet tatsächlich die mathematische Berechnung statt; die Daten müssen hier geladen werden, damit die Tensor Cores sie nutzen können.
2. SRAM (Shared Memory) – der Arbeitsspeicher mit einer Bandbreite von etwa 33 TB/s.
3. L2-Cache – eine Zwischenschicht mit einem Umfang von 50 MB und einer Geschwindigkeit von rund 12 TB/s. Er dient als Puffer, sodass mehrere SMs, wenn sie denselben Weights benötigen, nicht alle aus HBM abrufen müssen.
4. HBM3 – der 80 GB große Hauptspeicher, der Model Weights sowie KV cache enthält, und weist eine Bandbreite von ~3,35 TB/s auf.

Die Kombination aus FlashAttention, Kernel Fusion sowie PagedAttention verringert den Datenverkehr zwischen diesen Schichten. Dadurch bleibt die Daten in der schnellen SRAM länger gespeichert, und es werden keine wiederholten Übertragungen an HBM erforderlich.

3. GPU Hardware-Glossar

Die unten aufgeführten Begriffe kommen im weiteren Verlauf des Leitfadens immer wieder vor.

HBM (High Bandwidth Memory) — Gestapelte DRAM-Chips, die über durch-Silizium-Leitungen (TSVs) miteinander verbunden sind und direkt im Package neben dem GPU-Chip untergebracht werden. Generationen: HBM2e (A100, 2 TB/s), HBM3 (H100, 3,35 TB/s), HBM3e (H200/B200, 4,8–8 TB/s). Warum das für LLMs von Bedeutung ist: Da Decode durch die Speicherbandbreite begrenzt wird, bestimmt die Bandbreite von HBM direkt den TPOT.

GDDR (Graphics DDR) – Herkömmliche Grafikspeicher (GDDR6, GDDR6X), die in Consumer-GPUs-Geräten wie der RTX 4090 oder L40S eingesetzt werden. Sie weisen ein geringeres Bandbreitenniveau im Vergleich zu HBM auf, sind aber pro Gigabyte günstiger. GDDR6X wird in RTX 4090 Es erreicht eine Durchsatzrate von etwa 1 TB/s im Vergleich zu den 3,35 TB/s des HBM3 der H100.

SM (Streaming Multiprocessor) – Der grundlegende Recheneinheitsträger von NVIDIA GPUs. Jeder SM umfasst CUDA Kerne, Tensor Cores, gemeinsamen Speicher (SRAM) sowie einen Warp-Scheduler. H100 verfügt über 132 SMs; A100 verfügt über 108.

Tensor Cores – Spezialisierte Einheiten für Matrix-Multiplikation und Akkumulation innerhalb jedes SM. Sie beschleunigen Mischgenauigkeits-Matrixmultiplikationen (FP16, BF16, FP8, INT8), die einen Großteil der Rechenarbeit bei Transformern ausmachen. Die Tensor Cores des H100 bieten 989 TFLOPS im TF32-Format im Vergleich zu etwa 67 TFLOPS, die allein von den CUDA Kernen erzeugt werden.

CUDA Kerne – Allgemein einsetzbare Einheiten für Fließkommazahlen und Ganzzahlen. Sie führen elementweise Operationen, Activation Funktionen sowie Aufgaben durch, die keine Matrizenmultiplikation erfordern. Tensor Cores übernehmen die schwierigsten Berechnungen für LLMs; die CUDA Kerne kümmern sich um alles Weitere.

Warp – Eine Gruppe von 32 Threads, die auf einem SM synchron ausgeführt werden. Die kleinste Scheduling-Einheit bei NVIDIA GPUs. Warp-Spezialisierung weist für unterschiedliche Aufgaben – wie das Laden von Daten im Vergleich zur Berechnung – unterschiedliche Verzerrungsstrategien zu, um einen Pipelining-Prozess zu ermöglichen.

NVLink – eine Hochgeschwindigkeits-Verbindungsstrecke von GPU zu GPU innerhalb eines Nodes. NVLink 4.0 (H100) bietet eine bidirektionale Übertragungsgeschwindigkeit von 900 GB/s; NVLink 5.0 (B200) erreicht hingegen 1,8 TB/s. Dies ist entscheidend für das Tensor-Parallelisieren, bei dem GPUs in jedem Layer Activations austauschen müssen.

InfiniBand – Hochgeschwindigkeits-Netzwerkstruktur für die Kommunikation zwischen Knoten unter Verwendung von GPU. NVIDIA ConnectX-7 Er bietet eine Übertragungsgeschwindigkeit von 400 Gb/s pro Port. Er wird zur Realisierung von Pipeline-Parallelität sowie für das verteilte Training über mehrere Knoten eingesetzt.

RDMA (Remote Direct Memory Access) – Es ermöglicht es einem GPU, den Speicher eines anderen Rechners zu lesen bzw. zu schreiben, ohne dass dabei die CPU involviert wird, wodurch die Latency minimiert werden. GPUDirect RDMA Ermöglicht direkte Übertragungen von GPU zu GPU zwischen Knoten. Wird in dezentralisierten Serving-Architekturen für KV cache-Übertragungen eingesetzt.

NVMe (Non-Volatile Memory Express) — Eine Hochgeschwindigkeits-SSD-Schnittstelle, die zur Abwicklung von KV cache genutzt wird. ZeRO-Infinity Parameter-Offloading bei unzureichender Speicherkapazität von GPU/CPU. Die sequenziellen Lesegeschwindigkeiten betragen 5–7 GB/s pro Laufwerk (PCIe Gen 4), wobei neuere Gen-5-Laufwerke Geschwindigkeiten von 10–14 GB/s erreichen.

TFLOPS / PFLOPS – Teraberechnungen bzw. Petaberechnungen im Fließkommensbereich pro Sekunde. 1 TFLOPS entspricht 10¹² FLOPS. Die gängige Einheit zur Messung von Rechenleistung. GPU Berechnen Throughput. Der H100 liefert 989 TFLOPS im TF32-Format. FlashAttention-3 erreicht etwa 1,2 PFLOPS bei FP8.

Teil II – Grundlagen von Inference

Inference ist der Teil des Systems, den die Benutzer tatsächlich wahrnehmen. Latency, die KV cache sowie die zweistufige Ausführung Model, Attention und Quantization bestimmen gemeinsam, wie schnell, wie kostengünstig und wie zuverlässig eine Dienstleistung bereitgestellt werden kann.

4. Latency: TTFT, TPOT und Prozentile

Zeit bis zum ersten Token (TTFT) ist die Verzögerung vom Einreichen der Anfrage bis zur ersten Ausgabe Token. Sie wird durch die Prefill-Phase bestimmt: Der Model muss den gesamten Prompt verarbeiten, bevor er etwas generieren kann, wodurch längere Prompts-Werte in der Regel zu einem höheren TTFT führen. Die Ziele hierfür sind produktbezogen; MLPerf Inference v5.0 wird für sein interaktives Szenario mit Llama 2 70B mit einer P99-TTFT-Grenze von $\leq$ 450 ms genutzt.

Zeit pro Ausgabe Token (TPOT) ist der durchschnittliche Zeitabstand zwischen aufeinanderfolgenden Tokens ab dem ersten. Dieser Wert bezieht sich auf die Decode-Phase, in der jeder Schritt durch die Speicherkapazität begrenzt wird:

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

Die durchschnittliche Lesegeschwindigkeit erwachsener Englischsprachiger beim leisen Lesen liegt bei etwa 238 Wörtern pro Minute für Sachbücher.Brysbaert, 2019). Die Streaming-Ziele sollten weiterhin aus den Produkttests stammen; MLPerf verwendet für sein interaktives Szenario eine P99-TPOT-Grenze von $\leq$ 40 ms.

P50 gegen P99 Latency sind von Bedeutung, da der Median die Ausreißer im Datensatz verdeckt. Ein System mit einem guten Wert für P50, aber einem schlechten Wert für P99 weist möglicherweise Probleme im Bereich des Batchings, der Preemption, der Queuing-Logik oder einer ungleichmäßigen Lastverteilung auf; Traces sind erforderlich, um solche Fälle voneinander zu unterscheiden.

5. Throughput: Tokens pro Sekunde sowie der Latency-Kompromiss

Throughput wird in Ausgaben Tokens pro Sekunde bei gleichzeitigen Anfragen gemessen. Der Wert „Anfragen pro Sekunde“ ist an sich weniger aussagekräftig, da eine Antwort mit einer Latenz von 10-Token und eine Antwort mit einer Latenz von 1.000-Token völlig unterschiedliche Ressourcenkosten verursachen. Die veröffentlichten Benchmark-Werte hängen von der Model, der Genauigkeit, der Hardware, den Prompt sowie der Länge der Ausgaben, der Konkurrenzlast und den SLO ab. Vergleichen Sie daher vLLM, SGLang, und TensorRT-LLM mit einem einzigen Harness anstelle der Kombination ihrer Hauptergebnisse.

Der Kompromiss: Bei geringer Konkurrenz erhält jede Anfrage eine hohe Latency, doch die GPU wird nicht voll ausgenutzt. Eine Erhöhung der Batch-Größe führt zu einer nahezu linearen Steigerung der Throughput, bis die Rechenkapazität erschöpft ist; danach steigt die Latency stark an. Goodput, also der Anteil der Anfragen, die die definierten SLO-Ziele erfüllen, ist der Indikator, der die rohen Werte der Throughput mit der tatsächlichen Zufriedenheit der Nutzer verbindet.

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

Während der autoregressiven Generierung berücksichtigt jeder neue Token alle vorherigen Token. Der KV cache speichert die Schlüssel- und Wertprojektionen aller Token in jeder Schicht, um eine Rechenlast im Umfang von $O(n^2)$ zu vermeiden. Ohne ihn würde die Erzeugung von Token für $n$ Einträge erfordern, dass der Model für alle $n-1$ vorherigen Tokens erneut ausgeführt wird.

Der KV cache stellt in der Regel den dominierenden Faktor für den Speicherdruck dar, da er linear mit der Sequenzlänge, der Batch-Größe sowie der Anzahl der Schichten zunimmt:

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

wohin:

• $L$ = Anzahl der Schichten
• $h_{kv}$ = Anzahl der KV-Köpfe
• $d_h$ = Dimension pro Kopf
• $s$ = Länge der Sequenz
• $B$ = Batch-Größe

Konkrete Beispiele mit FP16 und einer Batch-Größe von 1: Llama 3 8B bei 8.192 Tokens verbraucht etwa 1,0 GB an KV cache; bei 128 K Tokens sind es 16 GB. Llama 3 70B benötigt bei 128 K Tokens etwa 40 GB für eine einzige Sequenz – das entspricht der Hälfte des VRAM eines H100-Chips. Bei produktiven Batch-Größen übersteigt der KV cache-Verbrauch leicht den Model Weight-Speicherbedarf. Naive Implementierungen verschwenden aufgrund von Fragmentierung 60–80 % des zugewiesenen KV-Speichers, was ein erhebliches Problem darstellt. PagedAttention wurde entwickelt, um folgendes zu lösen.

Die wichtigsten Optimierungen sind GQA (weniger KV-Kopfzeilen), KV cache Quantization (FP8/INT8), PagedAttention (Blöcken basierende Zuweisung mit <4 % Abfall), sowie die Übertragung von KV cache an CPU oder NVMe.

7. Prefill gegen Decode: Zwei Phasen, zwei Bottlenecks

Die Prefill-Phase verarbeitet die Eingabe Prompt parallel und füllt den KV cache auf. Aufgrund der damit verbundenen großen Matrixmultiplikationen ist sie rechenintensiv, wodurch Prefill maßgeblich über die Zeit bis zum ersten Token (TTFT) entscheidet. Die Decode-Phase erzeugt jeweils einen Token nach dem anderen. In jedem Schritt werden dabei Model Weights sowie der KV cache gelesen. HBM, dass Decode an die Speicherbandbreite gebunden wird und somit der Hauptfaktor für die Zeit pro Ausgabe Token (TPOT) darstellt.

In Blöcken aufgeteilte Prefill-Verarbeitung teilt den Prompt in Blöcke fester Größe auf (zum Beispiel 512 Tokens), anstatt ihn auf einmal vollständig zu verarbeiten. Ein langer Prefill blockiert nicht mehr laufende Decode-Anfragen, rechenintensive sowie memoriensintensive Aufgaben werden auf derselben GPU koordiniert, und vLLM Benchmarks weisen eine Steigerung um +50% Throughput auf.Agrawal et al., 2024). Der Preis für die neue Anfrage ist leicht höher als bei TTFT.

Getrennte Serving platzieren Prefill und Decode in separate GPU-Pools, wodurch jeder Pool auf ein unterschiedliches Bottleneck abzielen kann. Splitwise und DistServe Beschreiben Sie das Muster. Die Pools übertragen KV-Cache-Daten über eine schnelle Interkonnektionsstrecke wie RDMA, Dadurch wird der Kommunikationsaufwand integraler Bestandteil des Designs.

8. GQA und MQA: Verkleinerung des KV cache

Standard Mehrkopflicher Attention (MHA) jeder Abfragenkopf erhält seinen eigenen K- und V-Kopf. Mehrfachabfragen Attention (MQA) er teilt einen einzigen KV-Head mit allen Abfragescheiteln, was eine extrem starke Reduzierung darstellt. Gruppierter Abfragen Attention (GQA) Dies stellt den praktikablen Kompromiss dar: Mehrere Abfrageschädel teilen sich einen einzigen KV-Schädel.

Llama 3 70B verwendet 64 Abfrageschädel, doch lediglich 8 KV-Schädel, was einer 8-fachen KV cache-Reduktion entspricht, im Vergleich zur gleichen Architektur mit einem KV-Schädel pro Abfrageschädel. Llama 3.1 405B setzt hingegen 128 Abfrageschädel sowie 8 KV-Schädel ein, was nach derselben Berechnung einer 16-fachen Reduktion gleichkommt.Meta, 2024). Ainslie et al. berichten, dass die Qualität von GQA in ihren getesteten Models der von MHA nahekommt, während gleichzeitig Geschwindigkeiten im Bereich von MQA erreicht werden. Ein kleinerer KV cache ermöglicht es, größere Datensätze zu verarbeiten, doch der tatsächliche Gewinn hinsichtlich Latency und Throughput hängt weiterhin von der Kernel sowie von der Arbeitslast ab.

9. Quantization: Tausch von Rechenoperationen gegen Geschwindigkeit und Speicherkapazität

Quantization verringert die Präzision von Model Weights und/oder Activations. Die wesentlichen Kompromisse:

AWQ (Activation-Aware Weight Quantization) identifiziert den <1 % der herausragenden Weights anhand der Werte von Activation und wendet eine kanalweise Skalierung an, um diese zu schützen. Dafür sind lediglich 128–1.024 Calibration Tokens erforderlich, und das Verfahren erhielt den MLSys 2024 Best Paper Award. GPTQ nutzt Informationen aus dem zweiten Ordnung-Hessian zur schichtweisen Verarbeitung von Quantization und benötigt mehr Calibration Data. bitsandbytes (Tim Dettmers’ Bibliothek) quantisiert während des Model-Ladens ohne zusätzliche Vorbereitungsphase; ihre NF4-Formatierung ermöglicht die Verarbeitung von QLoRA Fine-Tuning. FP8 auf Hardware der Hopper-Klasse verringert den Weight-Speicherverbrauch im Vergleich zu FP16/BF16 erheblich, wobei Qualität und Geschwindigkeit weiterhin von den Faktoren Model, Calibration und Kernel abhängen.

Der Serving Kernel kann genauso wichtig sein wie das Quantization-Algorithmen. Im in der Diskussion behandelten Vergleich Abschnitt 10, dieselben quantisierten Weights weisen im Bereich von Throughput** eine Differenz von **2,6‑Mal** auf, je nach Kernels.

Teil III – Optimierungen von Inference

Dieser Abschnitt befasst sich mit den Softwaretechniken, die ein funktionsfähiges Inference-System in ein schnelles umwandeln. Jede dieser Techniken zielt auf einen spezifischen Bottleneck ab: FlashAttention nutzt die Lücke im SRAM-HBM-Verhalten, PagedAttention beseitigt die KV cache-Fragmentierung und Continuous Batching hält den GPU beschäftigt.

10. Fusion von CUDA Kernels und Kernel

Ein CUDA Kernel ist eine für den GPU entwickelte Funktion, die parallel über Tausende von Threads ausgeführt wird. Wenn der CPU einen Kernel aufruft, verteilt der GPU die Arbeit auf seine SMs: Jeder SM führt mehrere Warps mit jeweils 32 Threads aus, wobei jeder Thread einen Teil der Daten verarbeitet. Jede Operation in LLM Inference – von der Matrixmultiplikation bis zur Token-Stichprobenziehung – ist letztendlich ein Kernel-Aufruf. Ein einziger Vorwärtslauf durch einen 70B großen Model löst Hunderte bis Tausende von Kernel-Aufrufen aus, und der Unterschied zwischen einer naiven Kernel-Implementierung und einer optimierten kann darüber entscheiden, ob das System seine Latency-SLOs erfüllt.

Die wichtigsten Kategorien von Kernel in LLM Serving:

• GEMM Kernels zur Matrixmultiplikation, die sowohl bei den Berechnungen von Prefill als auch bei denen von Decode eine dominante Rolle spielen.
• Attention Kernels wie FlashAttention, die Berechnungen in Blöcken durchführen, um im Rahmen zu bleiben. SRAM anstatt in HBM abzurutschen. – Fusionierte Kernels, die mehrere Operationen (wie Addition plus Layer-Norm oder QKV-Projektion) zu einem einzigen Aufruf zusammenfassen, um die mittleren HBM-Wege zu vermeiden. – Stichprobenziehung Kernels, bei der Logits mithilfe von Top-k-, Top-p- oder Temperaturstichprobenziehung in Token-IDs umgewandelt werden.

Kernel Qualität spielt oft eine wichtigere Rolle als die Quantization Algorithmus. Derselbe. INT4- quantisiert Weights über einen Agenten bereitgestellt Marlin Mit einem optimierten FP16xINT4 Kernel erreicht das System eine Leistung von 712 Tokens/s, im Vergleich zu 276 Tokens/s bei der herkömmlichen GPTQ-Variante – das entspricht einem 2,6-fachen Throughput Unterschied, der ausschließlich auf einer besseren GPU-Auslastung beruht. Marlin erreicht diese Leistung durch asynchrone Speicherabrufe sowie gemeinsame Speicherkolonnen, die die Tensor Cores kontinuierlich mit Daten versorgen, anstatt auf HBM warten zu müssen. Triton Es senkt die Hürden für die Entwicklung eigener Kernels, indem es das Programmieren mit GPU über Python statt über reines CUDA C++ ermöglicht. Dadurch werden Optimierungen auf Kernel-Ebene auch für ML-Entwickler zugänglich, und nicht nur für GPU-Spezialisten. Die meisten Optimierungen, die später in diesem Abschnitt vorgestellt werden (FlashAttention, gefusionierte Kernels, PagedAttention), sind im Grunde entweder bessere Kernels-Lösungen oder intelligente Methoden zur Steuerung der Ausführung von Kernel.

Kernel Fusion kombiniert sequenzielle Operationen zu einem einzigen GPU Kernel und überspringt dabei die intermediären HBM Schreibvorgänge. Zu den gängigen Fusionen gehören die QKV-Projektion, Attention in Kombination mit Softmax sowie Addition zusammen mit RMSNorm.FlashNorm), sowie SwiGLU Activation (DeepFusionKernel). Triton macht diese Kernels über Python zugänglich. Die genauen Vorteile hinsichtlich der Anzahl der Ausführungen sowie der Auslastung hängen vom Model-Graphen, dem Compiler, GPU sowie den Serving Framework ab, weshalb es sinnvoll ist, den eingesetzten Stack zu profilieren, anstatt sich auf einen universellen Prozentsatz zu verlassen.

11. FlashAttention: Flächendeckende Verwaltung von Attention im SRAM

Standard Attention materialisiert die vollständige $N \times N$ Attention-Matrix in HBM, was $O(N^2)$ an Speicher erfordert und zu erheblichem Speicherdurchsatz führt. Die Idee hinter FlashAttention besteht darin, diese Matrix überhaupt nicht zu materialisieren. Stattdessen werden die Q-, K- und V-Matrizen in Blöcke aufgeteilt, die in SRAM, Es werden partielle Attention innerhalb jedes Tiles berechnet, wobei die Ergebnisse mithilfe eines online Softmax-Algorithmus zusammengeführt werden – dabei werden der laufende Maximalwert sowie die Summe schrittweise über die Blöcke erfasst. Dadurch sinkt der Speicherverbrauch von $O(N^2)$ auf $O(N)$, und die Kosten für HBM verringern sich um einen Größenordnungskoeffizienten.

Jede Version richtet sich auf die Bottleneck ihrer GPU-Generation aus:

• FlashAttention Version 1 (A100, 2022) hat gezeigt, dass das Konzept aus Tiling in Kombination mit Online-Softmax funktioniert. Es erzielt eine 2–4-fache Beschleunigung im Vergleich zu herkömmlichen Attention-Lösungen, weist jedoch aufgrund einer durch Kernel-Scheduling-Strategien bedingten Inaktivität vieler SMs nur eine GPU-Auslastung von 25–40 % auf. FlashAttention v2 (A100, 2023) hat die Parallelisierungsstrategie überarbeitet, sodass sie nun entlang der Sequenzdimension statt über Batch-Einheiten und Kopfmodule erfolgt. Dadurch wurde eine 50–73 %ige Auslastung auf dem A100 erreicht, was einer Geschwindigkeitssteigerung von etwa 2 Mal im Vergleich zur v1 entspricht.
• FlashAttention v3 (H100 Hopper, 2024) verfügt nun über eine spezialisierte Warp-Verwaltung (getrennte Warps für Datenbewegung und mathematische Operationen) sowie über Pipelining für GEMM-softmax-Ausführungen, um die Speicherläufe mit der Berechnung zu überlappen. Dadurch wird eine Auslastung von 75–85 % auf der H100 erreicht, wobei Leistungen von bis zu ~1,2 PFLOPS in FP8 möglich sind. Fokusthema bei NeurIPS 2024. FlashAttention v4 (B200 Blackwell, 2026) behandelt ein neues Bottleneck: Auf der Blackwell-Beschleunigerarchitektur skalieren die Tensor-Core Throughput derart schnell, dass nicht-matmul-Berechnungen (wie Softmax-Funktionen oder Exponentialfunktionen sowie Reskalierungsoperationen) zum Leistungslimit werden. Die FA4-Software emuliert die Exponentialfunktion mithilfe polynomieller Approximationen auf den FMA-Einheiten, wendet bedingtes Reskalieren an, um Overhead zu reduzieren, und speichert Zwischenergebnisse in Blackwells dedizierter Tensor-Speicherstruktur (TMEM) anstelle in Registern. Das Ergebnis sind 1.605 TFLOPS/s auf dem B200 in BF16 – das entspricht einer Geschwindigkeitssteigerung von 1,3x gegenüber cuDNN 9.13 sowie einer Steigerung von 2,7x im Vergleich zu Triton.

Jede Generation stieß auf eine andere Hardware-Beschränkung, und jede Version von FlashAttention wurde von Grund auf neu entworfen, beginnend bei Kernel, um dieser Beschränkung entgegenzuwirken.

12. FlashDecoding: Parallelisierung von Decode Bottleneck

Der Standard FlashAttention hält den GPU beschäftigt, indem er die Arbeit auf Batch-Größe und Abfragenlänge aufteilt. Während des Decode erzeugt der Model jeweils genau 1 Token pro Iteration (Abfragenlänge = 1). Wenn die Produktmenge aus Batch-Größe und Anzahl der Attention Heads kleiner ist als die Gesamtanzahl an SM-Einheiten des GPU (108 auf einem A100), bleiben die meisten GPU ungenutzt, während nur wenige Einheiten nacheinander durch die Token-Historie arbeiten.

FlashDecoding Es wird dieses Problem dadurch gelöst, dass eine neue Parallelisierungsdimension hinzugefügt wird: die Länge der KV-Sequenz selbst. Dabei wird die KV cache in kleinere Abschnitte aufgeteilt und diese auf alle sonst untätigen GPU-Prozessoren verteilt, um sie parallel auswerten zu können. Anschließend werden die teilweisen Ergebnisse mithilfe einer Log-Sum-Exp-Reduktion zusammengeführt.

Das Ergebnis zeigt eine 8-fache Beschleunigung von Ende zu Ende bei Decode für lange Sequenzen (64 K Kontextlänge), während die Decode-Zeit pro Token im Wesentlichen konstant bleibt. Die Erstellung von Token‑Elementen in der Anzahl von 60.000 ist nahezu genauso schnell wie die Erstellung von Token‑Elementen in der Anzahl von 100.

13. Continuous Batching im Vergleich zur statischen Batching-Verarbeitung

Statische Batchverarbeitung wartet darauf, dass jede Sequenz in einem Batch abgeschlossen ist, bevor mit der nächsten begonnen wird. Dadurch verschwenden kurze Sequenzen nach Erreichen des Ende der Sequenz unnötig GPU Zyklen im Leerlauf. Continuous Batching (eingeführt durch den Orca-Paper, (OSDI 2022) arbeitet auf der Ebene der Iterationen: In jedem Decode Schritt werden abgeschlossene Sequenzen entfernt und neue hinzugefügt.

In Anyscale’s OPT-13B Benchmark erreichte die optimierte statische Batching-Methode ein Vielfaches von 4 im Vergleich zur einfachen Baseline, Continuous Batching erreichte 8 Mal den Baseline-Wert, und vLLM in Kombination mit Continuous Batching sowie PagedAttention sogar 23 Mal den Baseline-Wert.Anyscale, 2023). Continuous Batching erhöht zudem den Druck auf die Zuweisung von KV-Paaren, weshalb es in der Regel mit einer paginierten Speichermanagement-Strategie kombiniert wird.

14. PagedAttention: Virtuelles Speicher für KV cache

der vLLM- PagedAttention Es wendet das Konzept der virtuellen Speicherung des Betriebssystems auf die Verwaltung von KV cache an. Der KV cache wird in Blöcke fester Größe aufgeteilt (in der Regel 16 Tokens); diese Blöcke werden nach Bedarf zugewiesen, sobald Tokens erzeugt werden, und logische (sequenzielle) Adressen werden über Blocktabellen auf physische (verstreute) Speicheradressen abgebildet. Mehrere Anfragen, die denselben Präfix teilen (System Prompts, Beam-Search), können auf dieselben physischen Blöcke verweisen.

Frühere Systeme verschwendeten 60–80 % des KV cache-Speichers auf Fragmentierung und vorzeitige Zuweisung. PagedAttention senkt diesen Wert auf <4 %, wodurch Throughput bei derselben Latency-Leistung um das 2–4‑Fache steigen kann – im Vergleich zu HuggingFace Transformers sogar um bis zu 24 Mal.vLLM Blog, 2023).

15. Spekulative Dekodierung: mehrere Tokens pro Vorwärtslauf

Ein kleiner Draft Model erzeugt $K$ Kandidaten Tokens, wobei der große Target Model alle $K$ Tokens in einem einzigen Vorwärtslauf überprüft. Korrekte Tokens werden akzeptiert; bereits die erste fehlerhafte wird abgelehnt. Die Ausgabequalität ist mathematisch identisch mit der einer reinen Verarbeitung durch den Target Model, wodurch eine verlustfreie Beschleunigung erreicht wird.

Es funktioniert, weil LLM Decode durch die Speicherbreite begrenzt ist: Die Überprüfung von $K$ Tokens kostet in etwa genauso viel Zeit wie die Erstellung von 1, da beide Vorgänge alle Model Weights einmal laden müssen. Typische Geschwindigkeitssteigerungen liegen zwischen 1,5‑ und 3‑Mal, wobei Methoden wie EAGLE-3 bis zu 6,5-fach. Zu den Varianten gehören Medusa (zusätzliche Vorhersageköpfe, ohne separate Model), Prompt-basierte Abfrage-Decodierung (freies n-gramm-basiertes Abgleichen mit der Eingabe) sowie EAGLE (Extrapolation auf Feature-Ebene).

Bei hohen Batch-Größen können zusätzliche Arbeitsschritte zur Erstellung von Entwürfen und zur Überprüfung die erzielten Vorteile wieder aufheben; ein zitiertes Bewertungsbericht weist in diesem Fall eine 1,4–1,8-fach langsamere Ausführungsgeschwindigkeit aus. Spekulative Dekodierung zeigt das größte Potenzial, wenn der Serving-Batch klein genug ist und die Akzeptanz der Entwürfe hoch ist.

16. Prefix Caching und KV cache werden wiederverwendet

Anstatt den KV cache nach Abschluss einer Anfrage zu vernichten, behält der Prefix Caching ihn bei, um ihn bei neuen Anfragen mit dem gleichen Präfix Tokens erneut verwenden zu können. Dadurch werden überflüssige Prefill für System Prompts, Few-Shot-Beispiele, den RAG-Kontext sowie die Historie mehrteiliger Konversationen vermieden.

Die automatische Prefix Caching von vLLM Es werden Hash-Blöcke für Schlüssel/Werte erstellt, und zur Abfrage wird ein globales Hash-Table verwendet. SGLangs RadixAttention Es wird ein Radixbaum mit gespeicherten KV-Tensoren auf der Ebene von Token-Granularität aufrechterhalten. Da sowohl der Radixbaum als auch die Abfragen von wiederholten Token-identischen Präfixen abhängen, wird die Trefferquote zusammen mit Latency oder Throughput ausgewiesen.

17. Streaming in der Praxis

Streaming sendet Tokens an den Client, sobald diese erzeugt werden, anstatt auf die vollständige Antwort zu warten. Viele Serving Frameworks stellen dies über Server-Sent Events bereit: Der Client öffnet eine langzeitige HTTP-Verbindung, und der Server sendet jede Token oder Token-Gruppe als data: Ereignis. TTFT bestimmt, zu welchem Zeitpunkt der Benutzer zum ersten Mal eine Ausgabe sieht; TPOT hilft dabei, die Geschmeidigkeit des Feedbacks einzuschätzen. Legen Sie das Ziel durch Produkttests sowie die gewählte Interaktionsmethode Model fest.

Auf der Client-Seite erzwingt das Streaming Entscheidungen bezüglich des Pufferns. Die Darstellung von Token mittels Token kann zu visuellen Flackern führen, insbesondere bei Markdown- oder Code-Blöcken, die einen mehrfach-Token kontextbezogenen Formatierungsprozess benötigen. Häufige Ansätze sind das Wortebene-Puffern (Anhäufen von Tokens bis zu einem Leerzeichenabschnitt), das Zeilenebene-Puffern (Warten auf ein Zeilenumbruch vor der Darstellung) sowie das adaptive Puffern (unverzügliche Darstellung von Prosa und Puffern von Code-Blöcken). stream_options: {"include_usage": true} Der Parameter in den OpenAI-kompatiblen APIs liefert die Token-Werte im endgültigen SSE-Ereignis, wodurch eine genaue Kostenverfolgung bei streambasierten Antworten möglich wird.

In Blöcken strukturierte Prefill Das ist es, was dafür sorgt, dass das Streaming unter Last stabil bleibt. Ohne dieses Konzept kann ein einziger langer Prefill die Token-Übertragung für alle anderen gleichzeitigen Benutzer zum Stocken bringen.

Teil IV – Model-Architektur

Wie LLMs konstruiert werden: der Transformer-Block, Tokenization, die Handhabung des Kontexts sowie die Architekturvarianten, die schließlich zum Standard wurden. All diese Elemente bilden die Grundlage sowohl für Inference als auch für den Trainingsprozess.

18. Grundlagen der Transformer-Architektur

Ein moderner rein-dekodierender Transformer (GPT, Llama) besteht aus einer Reihe identischer Schichten, wobei jede Schicht zwei Unterblöcke aufweist: Attention sowie einen Feed-Forward-Block. Jeder dieser Unterblöcke ist außerdem durch eine Residualverbindung sowie eine Normalisierungsschicht umgeben. Die wichtigsten Komponenten sind:

Multi-Head Attention – das Mechanismus, der es jedem Token ermöglicht, alle anderen Token zu betrachten, um festzulegen, was relevant ist. Die Eingabe wird in drei Matrizen projiziert: Queries (Wonach suche ich?), Keys (Was enthalte ich?) und Values (Welche Informationen trage ich mit?). Anschließend werden die Attention-Werte wie folgt berechnet:

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

Das Skalarprodukt von $QK^T$ misst die Ähnlichkeit zwischen jedem Paar von Tokens. Durch Division durch $\sqrt{d_k}$ wird verhindert, dass die Skalarprodukte zu groß werden – andernfalls würde dies den Softmax-Funktion in Bereiche mit verschwindenden Gradienten führen. Der Softmax wandelt die Scores in Wahrscheinlichkeiten um, und die Multiplikation mit $V$ erzeugt eine gewichtete Kombination der Wertvektoren. Durch Ausführung dieses Vorgangs parallel in mehreren Heads kann der Model gleichzeitig auf unterschiedliche Beziehungen achten (ein Head für Syntax, ein anderer für Koreferenz usw.).

Feed-Forward Network (FFN) – sobald Attention entschieden hat, welche Tokens relevant sind, bestimmt die FFN, was mit diesen Informationen unternommen werden soll. Moderne LLMs nutzen SwiGLU anstelle der ursprünglichen ReLU-FFN mit zwei Matrizen:

$\text{SwiGLU}(x) = \text{Swish}(xW_1) \otimes xW_2$

SwiGLU verwendet drei Weight-Matrizen anstelle von zwei sowie einen glatten Swish Activation statt von ReLU. Er wird von Model-Familien wie Llama, Mistral, Qwen und Gemma eingesetzt. Der FFN macht in der Regel etwa zwei Drittel der gesamten Model-Parameter aus, wobei der genaue Anteil von der Architektur abhängt.

Residuale Verbindungen – jeder Unterblock fügt seine Ausgabe wieder zu seiner Eingabe hinzu: $\text{Ausgabe} = \text{Eingabe} + \text{Unterschicht}(\text{Eingabe})$. Ohne diese Sprungverbindung verschwinden die Gradienten beim Rückpropagieren durch 80–128 Schichten. Die Residualverbindung schafft einen Pfad, über den Informationen und Gradienten direkt von den frühen Schichten zu den späten Schichten fließen können.

RMSNorm – kommt in modernen LLM-Familien häufig vor. LayerNorm normalisiert, indem der Mittelwert subtrahiert wird, um die Werte zu zentrieren, und anschließend durch die Standardabweichung geteilt wird, um sie neu zu skalieren. RMS-Norm Es wird die Subtraktion des Mittelwerts übersprungen und lediglich eine Neuskalierung vorgenommen; die entsprechende Veröffentlichung berichtet von 7–64 % Geschwindigkeitszuwächsen bei allen getesteten Models, ohne dass dabei in diesen Experimenten Leistungsverluste auftreten. Eine Vornormalisierung, bei der die Normalisierung vor Attention oder dem FFN erfolgt, ist ebenfalls gängig, da sie die Gradientenstabilität verbessert.

Schätzung der Parameteranzahl für einen reinen Dekoder Model:

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

Dabei steht $V$ für die Größe des Wortschatzes, $d$ für die verborgene Dimension und $L$ für die Anzahl der Schichten. Der Term $V \times d$ repräsentiert die Eingabematrix Embedding; der Term $12 \times d^2$ approximiert die Attention-Strukturen sowie die FFN Weights in jeder Schicht. Für Llama 3 8B ($V=128{,}256$, $d=4{,}096$, $L=32$) beträgt die geschätzte Anzahl an Parametern etwa $0{,}53B + 6{,}44B = 6{,}97B$. Der veröffentlichte Wert von 8,03 B ist höher, da bei dieser Approximation architektonische Details wie die genaue Breite der FFN sowie die separate Ausgabeprojektion weggelassen werden.

19. Warum Decoder-only-Architekturen dominieren

Der ursprüngliche Transformer (2017) verfügte sowohl über einen Encoder als auch über einen Decoder. Seitdem hat sich das Feld in drei architektonische Familien aufgeteilt, wobei eine davon zum Standard für generative AI wurde.

Einfach-Encoder Models (BERT, RoBERTa) nutzen bidirektionale Attention-Strukturen: Jeder Token bezieht Informationen von jedem anderen Token in beide Richtungen heran. Dadurch entstehen detaillierte Repräsentationen, die für Verständnisaufgaben (Klassifizierung, NER, semantische Ähnlichkeit) nützlich sind, doch es ist nicht möglich, Texte autoregressiv zu generieren. Einfach-Encoder Models bleiben dennoch als Grundlage weit verbreitet. Embedding Models, Reranker sowie leichte Klassifikatoren (zum Beispiel der auf BERT basierende Routers in RouteLLM).

Encoder-Decoder Models (T5, BART, der ursprüngliche Transformer) trennen das Verstehen von der Generierung. Der Encoder verarbeitet die gesamte Eingabe mithilfe von bidirektionalen Attention, wobei der Decoder anschließend autoregressiv Ausgabe erzeugt und dabei über Cross-Attention auf die Repräsentationen des Encoders zurückgreift. Dies bietet einen klaren Vorteil bei sequenz-zu-sequenz-Aufgaben wie der Übersetzung, bei denen Eingabe und Ausgabe grundsätzlich unterschiedliche Sequenzen sind. Googles T5 zeigte außerdem, dass jede NLP-Aufgabe als Text-zu-Text-Aufgabe formuliert werden kann, und Encoder-Decoder Models werden weiterhin in einigen spezialisierten Systemen eingesetzt (zum Beispiel Whisper für die Spracherkennung oder FLAN-T5 für die Befolgung von Anweisungen).

Nur Decoder Models (GPT, Llama, Mistral, Gemini) nutzen eine kausale (eindeutige) Attention Struktur: Jeder Token bezieht sich ausschließlich auf die vorherigen Tokens Elemente. Dabei wird alles als Vorhersage für den nächsten Schritt Token interpretiert – der „Eingang“ stellt den Anfang der Sequenz dar und der „Ausgang“ ihre Fortsetzung. Es gibt vier Gründe, warum diese Architektur dominierend geworden ist:

1. KV cache Effizienz. Der KV cache aus dem vorherigen Tokens bleibt weiterhin gültig, da neue Tokens erzeugt werden, wodurch er niemals verworfen oder neu berechnet werden muss. Encoder-Decoder-Models müssen zwei getrennte Attention-Caches pflegen (Self-Attention zusätzlich zu Cross-Attention für die Encoder-Ausgabe), was zu einem erhöhten Speicherverbrauch sowie zu größerer architektonischer Komplexität führt.

2. Einfachheit der Schulung. Das Schulungsziel besteht lediglich darin, eine einfache Vorhersage für den nächsten Token anhand von Rohtexten vorzunehmen. Es sind weder gepaarte Eingabedaten/Output-Daten erforderlich (wie es bei Übersetzungen Models der Fall ist), noch eine maskierte Token Rekonstruktion nötig (wie es bei BERT der Fall ist). Man kann somit mit praktisch jedem Text aus dem Internet, Büchern oder Code ohne spezielle Vorbereitungsschritte trainieren – was einen erheblichen Vorteil darstellt, wenn die Datenmengen auf Billionen von Tokens skaliert werden sollen.

3. Architektonische Einfachheit. Ein einziger Modul kümmert sich um alles: derselbe Transformer-Block, wiederholt $L$ Mal. Es gibt weder Encoder-Decoder Cross-Attention-Schichten noch einen separaten Encoder-Stack. Dadurch werden Strategien zur Parallelisierung einfacher umsetzbar.Abschnitt 33), und verringert somit die zu optimierende Ingenieurfläche. FlashAttention, Quantization sowie spekulative Dekodierung müssen lediglich ein einziges Attention-Muster berücksichtigen.

4. In-Kontext-Lernen. Decoder-only Models-Modelle eignen sich auf natürliche Weise gut für das Few-Shot-Lernen, da Beispiele, Anweisungen sowie die Abfrage alle einfach als Tokens in derselben Sequenz vorliegen. Der Model unterscheidet nicht zwischen „Eingabe“ und „Ausgabe“; er prognostiziert den nächsten Token anhand aller vorangegangenen Informationen. GPT-3 zeigte dieses Verhalten erstmals im großen Maßstab, wodurch Decoder-only Models-Modelle zu einer hervorragenden Wahl für die Rolle eines universellen Assistenten wurden.

20. Mischung aus Experten

MoE ersetzt die dichte FFN in jeder Transformer-Schicht durch mehrere kleinere Experten-FFNs sowie eine leichte Steuerung Router. Die Router berechnet für jeden Experten einen Score (in der Regel über eine Softmax-Funktion auf gelernten linearen Projektionen) und wählt pro Token die besten $k$ Experten aus. Nur die aktivierten Experten werden verarbeitet, wodurch eine Model eine enorme Gesamtkapazität aufweisen kann, ohne dass die Kosten pro Token hoch bleiben. Dabei handelt es sich um sparsame bedingte Berechnungen: Die Gesamtanzahl der Parameter bestimmt, was die Model darstellen kann, während die Anzahl der aktiven Parameter den Betriebsaufwand bestimmt.

Der shared expert in DeepSeek-V3 wird für jeden Token aktiviert. Er liefert eine Basissprrepräsentation, auf der die zugeordneten Experten spezialisieren können.

Das Training von MoE weist drei wiederkehrende Probleme auf: Lastunverteilung, Expertenkollaps sowie Kommunikationsaufwand. expertenbasierte Parallelisierung. Herkömmliche MoE Models-Methoden fügen einen Hilfsverlust hinzu, um ein ungleichmäßiges Verteilungsverhältnis von Routing zu bestrafen, doch dieser Verlust kann mit dem Hauptziel in Konkurrenz treten. DeepSeek-V3 Anstelle dessen werden Bias-Terme außerhalb der Backpropagation verwendet: Das System senkt die Bewertung überlasteter Experten und erhöht die Bewertung untergenutzter Experten. In der Veröffentlichung wird ein besseres Gleichgewicht durch Routing ohne den Kompromiss einer zusätzlichen Verlustfunktion in der jeweiligen Architektur berichtet.

21. Tokenization: BPE, SentencePiece und tiktoken

LLMs Man sieht keinen Text. Sie erkennen lediglich Sequenzen von Ganzzahlen. Token IDs. Ein Tokenizer teilt den Rohtext in Tokens (subwortartige Fragmente) und weist jedem davon eine ID zu. Die Tokenizer Die gewählte Option beeinflusst Model Qualität Inference Geschwindigkeit sowie mehrsprachige Fairness.

Byte-Paar-Kodierung (BPE) Es handelt sich um den gängigen Algorithmus. Er fügt im Iterativverfahren die häufigsten benachbarten Paare im Trainingskorpus zusammen. Ein vereinfachtes Beispiel:

1. Beginnen Sie mit einem Wortschatz auf Zeichenebene: [l, o, w, e, r, _]
2. Das häufigste Paar ist (l, o) → in einen Merge übernehmen lo → Wortschatz: [l, o, w, e, r, _, lo]
3. Das nächsthäufigste Paar ist (lo, w) → in einen Merge übernehmen low → Das Vokabular wird erweitert. low
4. Setzen Sie den Vorgang fort, bis das Wortschatzvolumen die gewünschte Größe erreicht hat (z. B. 128 K Tokens)

Häufig vorkommende Wörter wie „der“ werden zu einem einzigen Tokens, während seltene Begriffe wie „Defenestration“ in ihre Bestandteile aufgeteilt werden. ["def", "en", "est", "ration"]Der Kompromiss besteht aus der Größe des Wortschatzes im Vergleich zur Länge der Sequenz.

Drei Implementierungen von Tokenizer decken den Großteil der Produktivnutzung ab:

• SentencePiece er behandelt die Eingabe als einen rohen Byte-Stream ohne sprachspezifische Vorausverarbeitung (ohne vorherige Tokenization durch Leerzeichen oder Satzzeichen), wodurch er sprachunabhängig ist – was insbesondere für nicht-lateinische Schriftsysteme von großer Bedeutung ist. Er unterstützt sowohl BPE-Modelle als auch Unigramme. Er wird von Llama 1/2, T5 und Mistral genutzt. tiktoken Ist OpenAI’s auf Rust basierender Tokenizer ein Ansatz, der auf Byte-Ebene BPE arbeitet? Sein kompiliertes Rust-Kernmodul ist 3–6-mal schneller als pythonbasierte Alternativen. Llama 3 wechselte von SentencePiece zum Algorithmus von tiktoken.
• Hugging Face Tokenizers Es handelt sich um eine weit verbreitete auf Rust basierende Bibliothek, die BPE, WordPiece sowie Unigram unterstützt.

Die Größe der Wörterbücher wächst kontinuierlich, was erhebliche Auswirkungen auf die Effizienz hat:

Fertility (Tokens pro Wort) gibt die Komprimierungsleistung an. Je niedriger dieser Wert ist, desto besser: Weniger Tokens bedeuten kürzere Sequenzen, geringere Kosten und es passt mehr Inhalt in den Context Window. Im Englischen liegt dieser Wert in der Regel bei etwa 1,0–1,3 Tokens pro Wort, doch bei Schriftsystemen, die nicht aus dem lateinischen Alphabet stammen – wie Chinesisch, Japanisch, Koreanisch oder Arabisch – kann er aufgrund englischzentrierter Wörterbücher 2–4-mal höher sein. Derselbe Inhalt kostet Nutzer:innen, die keine Englischsprachigen sind, 2–4-mal mehr in Tokens, was ein anhaltendes Gleichheitsproblem darstellt, das nur teilweise durch umfassendere und ausgewogenere Wörterbücher gelöst werden kann.

22. Context Windows und positionale Kodierungen

Der Context Window gibt die maximale Anzahl an Tokens an, die ein Model in einem einzigen Vorwärtslauf verarbeiten kann. Er hat deutlich zugenommen:

Es gibt hier ein grundlegendes Problem: Das Attention-Mechanismus behandelt seine Eingabe als Menge und nicht als Sequenz. Er verfügt über kein eingebautes Konzept für die Wortreihenfolge. Ohne positionale Informationen würden Ausdrücke wie „Die Katze saß auf der Matte“ und „Die Matte saß auf der Katze“ zu identischen Repräsentationen führen. Positionale Kodierungen fügen diese Reihenfolge hinzu, damit das Model kennt, wo sich jeder Token befindet.

Drei gängige Ansätze sind:

• RoPE (Rotationsposition Embeddings) kodiert die Position jedes Token, indem die zugehörigen Query- und Key-Vektoren um einen Winkel gedreht werden, der proportional zur Position ist. Tokens, die sich nahe beieinander befinden, erfahren ähnliche Drehungen, wodurch ihr Skalarprodukt (der Attention-Score) hoch bleibt. Tokens, die weit voneinander entfernt sind, erhalten sehr unterschiedliche Drehungen, was die relative Entfernung widerspiegelt. RoPE ist aufgrund seiner guten Handhabung von relativen Positionen sowie seiner geringen Rechenlast der Standard für nahezu alle modernen offenen LLMs-Modelle (Llama, Mistral, Qwen).

• ALiBi Bei der Verwendung von (Attention mit linearen Biasen) werden die Embedding-Anpassungen übersprungen und eine Strafe direkt zu den Attention-Werten hinzugefügt: Je weiter zwei Tokens voneinander entfernt sind, desto größer ist der negative Bias. Es werden keine Parameter gelernt und es erfolgt keine zusätzliche Berechnung. Dadurch ist eine gewisse Extrapolation über die Länge des Trainingsdatensatzes möglich, doch die Leistung verschlechtert sich deutlich, wenn der Kontext um das Zweifache oder mehr vergrößert wird.

• YaRN (Eine weitere Erweiterung von RoPE) erweitert das Konzept von RoPE Model über seinen ursprünglichen Trainingskontext hinaus. Dabei werden die Frequenzdimensionen in drei Kategorien eingeteilt, wobei jede Kategorie unterschiedlich skaliert wird. In der Veröffentlichung wird berichtet, dass im Vergleich zur Baseline mit Position interpolierung 10-mal weniger Fine-Tuning Tokens sowie 2,5-mal weniger Trainingsschritte erforderlich sind.

Teil V – Training und Ausrichtung

Durch das Training werden die erforderlichen Fähigkeiten entwickelt. Dieser Abschnitt behandelt Pretraining, effiziente Fine-Tuning-Methoden (LoRA, gemischte Präzision), Skalierungsgesetze sowie Methoden zur Ausrichtung der KI-Modelle.

23. Pretraining, Fine-Tuning und Ausrichtung

Pretraining stellt eine selbstüberwachte Vorhersage des nächsten Token auf der Grundlage eines großen Korpus dar. Die dafür erforderliche Rechenleistung liegt Spans um viele Größenordnungen höher; Llama 3 405B, Zum Beispiel werden dabei $3{,}8 \times 10^{25}$ FLOPs genutzt. Überwachtes Fine-Tuning (SFT) passt das vortrainierte Model an spezifische, gelabelte Datensätze für eine bestimmte Aufgabe an. RLHF / RLAIF nutzt Präferenzdaten, um das Verhalten zu gestalten: Ein herkömmliches RLHF Pipeline sammelt Vergleiche, trainiert einen Belohnungs-Model und optimiert anschließend die Strategie. RLAIF ersetzt einige menschliche Beurteilungen durch durch AI erzeugte Rückmeldungen.

Die Rechenleistung hängt von der Größe von Model, der Länge der Sequenz, dem Datenvolumen, dem Optimierer sowie der verwendeten Methode ab. PPO benötigt außerdem mehr Model Zustandsinformationen als SFT, da eine typische Konfiguration Policy-, Referenz-, Belohnungs- und Kritiker-Models Komponenten umfasst. Ich habe den gesamten Prozess der Fine-Tuning Entscheidungsfindung Framework bereits behandelt. Leitfaden für LLM und Fine-Tuning.

24. LoRA und QLoRA: parametereffizienter Fine-Tuning

LoRA Es werden die vortrainierten Weights festgehalten, und es werden lernbare, niedrig-rangige Matrizen $A$ ($r \times k$) sowie $B$ ($d \times r$) eingefügt, sodass der aktualisierte Weight den Wert $W_0 + BA$ annimmt. In der LoRA veröffentlichten Arbeit wurde GPT-3 175B in ihrer Implementierung auf etwa 18 Millionen lernbare Parameter reduziert. Der Rang stellt dabei einen Einstellparameter dar und keine Regel zur Bestimmung der Aufgabenkomplexität; er wird mithilfe von Qualitäts- und Speichermessungen ausgewählt. Nach dem Training können LoRA-Adapter in den Basis-Weights integriert werden, um einen separaten Adapterpfad bei Inference zu vermeiden.

QLoRA Während des Trainings von LoRA-Adaptern in BF16 wird die Basis Model in Form von 4-Bit-NF4 Quantization geladen. NormalFloat4 platziert mehr Quantization Werte in der Nähe von Null, wo die Weight-Dichte am höchsten ist. In der Veröffentlichung wurde ein 65B Model auf einem einzigen 48 GB GPU feinabgestimmt, wobei Ergebnisse erzielt wurden, die denjenigen der 16-Bit-Referenzmodelle nahekamen. Die Kompromisse hinsichtlich der Runtime-Leistung und des Speicherverbrauchs sind spezifisch für den getesteten Technologiestack.

25. Training mit gemischter Präzision

Jeder Fließkommaformat verteilt seine Bits auf drei Bereiche: das Zeichen-Bit (immer 1 Bit), den Exponenten, der den dynamischen Dynamikumfang bestimmt, sowie die Mantisse, die die Genauigkeit festlegt. Mehr Exponenten-Bits ermöglichen einen größeren Bereich an darstellbaren Größenwerten; mehr Mantisse-Bits führen zu feineren Unterscheidungen zwischen benachbarten Werten. Ganzzahlformate verfügen überhaupt keinen Exponenten und repräsentieren ausschließlich gleichmäßig verteilte Ganzzahlen innerhalb eines festgelegten Bereichs.

BF16 weist denselben Wertebereich wie FP32 auf, da der Wertebereich durch das Exponentenfeld festgelegt wird, und BF16 übernimmt alle 8 Exponentenbits von FP32. Stattdessen werden Bits der Mantisse aufgegeben (7 gegenüber 23), wodurch man zwar an Präzision verliert, aber die Speichernutzung um das Zweifache reduzieren kann – ohne dabei die Überlauf- und Unterlaufprobleme zu erleben, die beim Training mit FP16 auftreten. FP16 verfügt nur über 5 Exponentenbits, wodurch sein Wertebereich auf etwa 65 K begrenzt ist. Gradienten überschreiten diese Grenze regelmäßig, weshalb beim Training mit FP16 eine Verlustskalierung erforderlich ist: Der Verlustwert muss vor der Backpropagation mit einer großen Konstante multipliziert und danach die Gradienten geteilt werden. BF16 macht eine solche Verlustskalierung überflüssig.

Ganzzahlformate kommen in der Haupttrainingsarithmetik selten zum Einsatz, da die Backpropagation einen großen Dynamikumfang erfordert. Sie werden hingegen häufig bei Inference verwendet, wobei gefrorene Weights auf kalibrierte Skalen abgebildet werden können. Durch INT4, Weight und Quantization sinkt die Größe eines 7B großen Model-Modells von etwa 14 GB auf 3,5 GB – noch vor den zusätzlichen Overhead-Kosten durch Runtime. Für die gewählte Model-Architektur sowie Methode muss daher stets die Qualität überprüft werden.

FP8 Training auf H100 über Transformer-Engine Es werden E4M3 eingesetzt, wo Präzision entscheidend ist, und E5M2, wo ein größeres Spektrum erforderlich ist. Laut NVIDIA beträgt die Geschwindigkeitssteigerung im getesteten 175B-Modell bis zu 75 % im Vergleich zur herkömmlichen Rechenzeit. DeepSeek-V3 Beim letzten Trainingslauf wurde FP8 mit gemischter Präzision eingesetzt, wodurch eine Rechenleistung im Umfang von etwa 5,6 Millionen US-Dollar im Vergleich zu Mietkosten erzielt wurde – ohne Berücksichtigung von Forschungs- und Entwicklungskosten sowie Infrastrukturkosten.

26. Gradient-Checkpointing

Jede Schicht des Forward-Passes erzeugt eine Zwischenergebnis, das als Activation bezeichnet wird:

$\text{Eingabe} \rightarrow [\text{Schicht 1}] \rightarrow \text{Activation}_1 \rightarrow [\text{Schicht 2}] \rightarrow \text{Activation}_2 \rightarrow [\text{Schicht 3}] \rightarrow \text{Ausgabe}$

In der Regel müssen alle Activations im Speicher verbleiben, da die Rückpropagierung sie zur Berechnung der Gradienten benötigt. Bei einem tiefen Transformer können die gespeicherten Activations mehr Speicher beanspruchen als die Model Weights selbst.

Gradienten-Checkpointing tauscht Rechenleistung gegen Speicher, indem der Großteil dieser Activations weggeworfen wird und sie während des Backpropagierens dynamisch neu berechnet werden. Die gängige VorgehensweiseChen et al., 2016) Es teilt ein Netzwerk mit $n$ Schichten in $\sqrt{n}$ gleichmäßig verteilte Abschnitte auf und speichert lediglich die Grenzen Activation jedes Abschnitts. Diese gespeicherten Grenzen bilden die “Checkpoints”. Alle dazwischenliegenden Activations innerhalb eines Abschnitts werden unverzüglich weggelassen.

Wenn der Rückwärts-Pass eine Schicht innerhalb eines Segments erreicht, werden deren Activations erneut aus dem nächstgelegenen Checkpoint berechnet. Dadurch sinkt der Speicherverbrauch von Activation von $O(n)$ auf $O(\sqrt{n})$, was in der Praxis einer 60–70 %igen Reduktion entspricht – mit dem Aufwand eines zusätzlichen Vorwärts-Passes (~20–33 % mehr Rechenleistung). FlashAttention wendet dasselbe Prinzip innerhalb von Attention an, indem die vollständige Attention-Matrix nicht materialisiert wird. Dies kann in HuggingFace aktiviert werden, indem man gradient_checkpointing=True.

27. DeepSpeed ZeRO-Ebenen

Im Standard-Data-Parallelism enthält jeder GPU eine vollständige Kopie des Model Weights, der Gradienten sowie des Optimierer-Zustands. Bei Adam benötigt jeder Parameter 2 Bytes für die FP16 Weight, 4 Bytes für den FP32-Master- Weight, 4 Bytes für die Impulskomponente, 4 Bytes für die Varianz und 2 Bytes für den Gradienten – insgesamt also 16 Bytes pro Parameter. Ein Modell mit 7,5 Milliarden Parametern wie Model verbraucht somit pro GPU etwa 120 GB, wobei jeder GPU genau dieselben Daten speichert. Auf 64 GPUs ergibt sich somit die Existenz von 64 identischen 120-GB-Kopien – was erhebliche Ressourcenverschwendung darstellt.

DeepSpeed ZeRO (Der Optimierer für Null-Redundanz) beseitigt diese Duplikation, indem er diese Komponenten über GPUs verteilt anstatt sie zu replizieren:

• Phase 1 – Partitionierung der Optimierer-Zustände. Jeder GPU speichert lediglich 1/N der Optimierer-Zustände (Adams-Momentum und Varianz, 8 Bytes/Parameter). Wenn ein GPU einen Weight aktualisieren muss, werden nur seine jeweilige Teilmenge aktualisiert und das Ergebnis ausgestrahlt. Dadurch sinkt der Speicherverbrauch von etwa 120 GB auf etwa 31 GB pro GPU.
• Phase 2 – Ebenfalls Partitionierung der Gradienten. Die Gradienten (2 Bytes/Parameter) werden nicht mehr vollständig zu jedem GPU reduziert. Jeder GPU erhält über den Algorithmus „reduce-scatter“ lediglich die für ihn benötigte Gradiententeilmenge. Der Speicherverbrauch verringert sich somit auf etwa 16 GB pro GPU.
• Phase 3 – Ebenfalls Partitionierung der Model Weights. Jeder GPU enthält nur 1/N der FP16 Weights. Vor dem Forward- bzw. Backward-Pass einer Schicht ruft der GPU den Algorithmus „all-gather“ auf, um vorübergehend die vollständige Schicht Weights aus allen anderen GPUs wiederzubilden, die Berechnungen durchzuführen und anschließend die gesammelten Weights zu löschen. Dadurch sinkt der Speicherverbrauch auf etwa 1,9 GB pro GPU.

Der Kompromiss liegt in der Kommunikation. In Phase 1 entsteht nur ein minimales Overhead. In Phase 2 wird „all-reduce“ durch „reduce-scatter“ ersetzt – mit ähnlichen Kosten. In Phase 3 sind hingegen vor jeder Schicht sowohl im Vorwärts- als auch im Rückwärtslauf „all-gather“-Aufrufe erforderlich, was zu einem Kommunikationsvolumen von etwa 1,5-fach im Vergleich zum Standard-Datenparallelismus führt.

ZeRO-Infinity Erweitert Stufe 3, indem geteilte Zustände auf RAM-Systeme mit CPU sowie sogar auf NVMe-SSDs ausgelagert werden, wodurch das Trainieren von Models-Modellen mit Billionen an Parametern auf begrenzten GPU-Clustern möglich wird. Der Nachteil besteht dabei in einem erheblichen Geschwindigkeitsverlust (NVMe ist etwa 500-mal langsamer als HBM); daher wird ZeRO-Infinity eingesetzt, wenn die Model-Modelle tatsächlich nicht in die gemeinsame GPU + CPU-Speicherkapazität passen.

28. FSDP: PyTorch-basierte Sharding-Methode

Vollständig geschardete Datenparallelität (FSDP) Es handelt sich um die eingebaute Lösung von PyTorch für DeepSpeed ZeRO-3. Dabei werden Parameter, Gradienten sowie Optimiererzustände auf mehrere GPUs aufgeteilt, wobei dasselbe Grundprinzip angewandt wird. Die Verarbeitung pro Schicht erfolgt durch einen einfachen Schleifenprozess:

1. All-gather alle Parameter aus allen GPUs (rekonstruieren vorübergehend die vollständige Schicht).
2. Compute den Vorwärts- oder Rückwärtsfluss für diese Schicht.
3. Free die gesammelten Parameter umgehend. Jeder GPU speichert lediglich seinen eigenen Teil.
4. Reduce-scatter die Gradienten, sodass jeder GPU nur seinen zugewiesenen Gradientenschnitt erhält.

Da FSDP im PyTorch nativ enthalten ist, integriert es sich direkt mit den Debugging-Tools, Profilern von PyTorch. torch.compile. Die Leistung im Vergleich zu DeepSpeed ZeRO-3 hängt von der Wrapping-Strategie, der Kommunikationstopologie, den Offload-Einstellungen sowie der Größe von Model ab, weshalb sie auf derselben Cluster-Umgebung verglichen werden sollten.

FSDP2 (2024–2025) ist eine Überarbeitung, die die Leistung verbessert. torch.compile Integration zur Verbesserung der Kernel-Fusion, die zusätzlich Unterstützung bei der FP8-Schulung bereitstellt. TorchAO, und vereinfacht den API. Sowohl FSDP als auch DeepSpeed sind über HuggingFace Accelerate, was es ermöglicht, mithilfe einer einzigen Konfigurationsänderung zwischen ihnen zu wechseln.

29. Skalengesetze und die Chinchilla-Falle

Chinchilla-Skalierung (Laut DeepMind, 2022) wurde unter den dortigen Annahmen eine rechenoptimale Zuweisung von etwa 20 Trainings Tokens pro Parameter ermittelt. Dieses Ziel berücksichtigt nicht die damit verbundenen Kosten im nachgelagerten Prozessschritt Serving. Wenn ein kleinererer Model, der mit mehr Daten trainiert wird, die erforderliche Qualität erreicht, kann dies im Rahmen eines umfangreichen Lebenszyklus bei Inference geringere Kosten verursachen.

Die Lösung besteht darin, kleinere Models mithilfe von weitaus mehr Daten überanzurechnen. Der Fortschritt ist auffällig:

Für einen Model, der in großem Umfang bereitgestellt wird, kann die Investition in mehr Rechenleistung für einen kleineren Model die Lebenszykluskosten senken. Llama 3 8B veranschaulicht diese Strategie, doch ob sie vorteilhaft ist, hängt von der erforderlichen Qualität sowie vom prognostizierten Inference-Volumen ab. „Chinchilla-optimal“ bezeichnet dabei die Effizienz der Trainingsrechenleistung – ein anderes Kriterium als die Lebenszykluskosten.

30. RLHF, DPO, GRPO sowie das Alignment-Landschaft

Ausrichtung lenkt einen vortrainierten Model in Richtung der gewünschten Anweisungen, Präferenzen sowie Sicherheitsrichtlinien. Sie garantiert jedoch nicht von selbst Richtigkeit oder sicheres Verhalten. Die unten aufgeführten Methoden bringen Implementierungskomplexität, Datenanforderungen, Explorationsmöglichkeiten und Trainingsstabilität miteinander ins Gleichgewicht.

Der klassische RLHF Pipeline: SFT → Erfassung von Paaren menschlicher Präferenzen → Trainieren eines Belohnungs- Model anhand dieser Paare → Feinabstimmung der Strategie mithilfe von PPO (Proximal Policy Optimization). PPO speichert gleichzeitig 4 Model Kopien im Speicher (Strategie, Referenz, Kritiker/Wert- Model, Belohnung Model), ist empfindlich gegenüber Hyperparametern und anfällig für Reward-Hacking, wobei der Model Unregelmäßigkeiten in der Belohnungs- Model-Struktur ausnutzt – beispielsweise um ausführliche oder selbstsichere Antworten zu liefern – anstatt die Qualität tatsächlich zu verbessern.

DPO (Direkte Präferenzoptimierung) umgeht die erlernte Belohnung Model sowie den Online-Reinforcement-Learning-Zyklus, indem sie direkt eine Verlustfunktion für Präferenzpaare optimiert. Dadurch wird das Training Pipeline vereinfacht. Der herkömmliche DPO-Ansatz arbeitet hingegen offline: Er trainiert anhand einer festen Dataset und erkundet während des Aktualisierungszyklus keine neuen Reaktionen. Ob diese Einschränkung von Bedeutung ist, hängt vom jeweiligen Auftrag sowie von der Datenabdeckung ab.

GRPO (Group Relative Policy Optimization, DeepSeek) entfernt den gelernten Kritiker von PPO, indem es für jede Prompt-Aktion mehrere mögliche Abschlüsse erzeugt und die gruppenbezogenen Belohnungen als Grundlinie verwendet. Dadurch wird die Last des Model-Zustands im Vergleich zu einer herkömmlichen PPO-Konfiguration verringert. Im Gegensatz zu DPO erfolgt bei GRPO ein On-Policy-Lernen: Der Model erzeugt während des Trainings neue Antworten. DeepSeek-R1 Es kombiniert GRPO mit RLVR (Reinforcement Learning unter Verwendung überprüfbarer Belohnungen), wobei dabei Prüfungen wie die Korrektheit von Mathematikaufgaben, die erfolgreiche Kompilierung von Code sowie Unit-Tests herangezogen werden. Solche Belohnungen sind im Vergleich zu aus gelernten Präferenzmustern ermittelten Scores leichter zu auditen, doch unvollständige Tests sowie Ersatzziele können dennoch ausgenutzt werden.

31. Destillation: Komprimierung von Wissen über Models

Durch Knowledge Distillation werden Fähigkeiten von einem großen „Teacher“-Modell auf ein kleineres „Student“-Modell übertragen. Bei der logitbasierten Destillation wird das Student-Modell so trainiert, dass es die Ausgabendistribution des Teacher-Modells nachahmt. Bei der datenbasierten Destillation erzeugt der Teacher Beispiele, anhand derer das Student-Modell feinjustiert wird. Datenbasierte Methoden sind für LLMs häufig geeignet, da sie unabhängig von der Architektur sowie mit Teacher-Modellen, die ausschließlich API nutzen, funktionieren können. Ihr Nutzen ist jedoch durch die Qualität des Teachers, die Datenabdeckung, Filterungsmöglichkeiten sowie die Kosten der Erzeugung begrenzt.

DeepSeek-R1 Es wurden 800.000 Reasoning Beispiele generiert und genutzt, um Qwen2.5 sowie Llama 3 Models von 1,5 Milliarden auf 70 Milliarden Parameter zu verfeinern. In der Bewertung im Paper:

• DeepSeek-R1-Distill-Qwen-32B erzielt 72,6 % bei AIME 2024 sowie 94,3 % bei MATH-500 – Werte, die über den im Paper gemeldeten Ergebnissen des OpenAI o1-mini liegen.
• DeepSeek-R1-Distill-Qwen-7B erreicht 55,5 % bei AIME 2024, was ebenfalls höher ist als das Ergebnis des QwQ-32B-Preview aus dem Paper, allerdings mit einem geringeren Model.

In den kleinen Experimenten mit DeepSeek-R1-Model zeigte sich, dass die Destillation im Vergleich zur direkten GRPO-Methode bei den getesteten Basis-Models-Modellen bessere Ergebnisse lieferte. Dieses Ergebnis spricht für die Verwendung von Destillation in dieser Konfiguration; es legt jedoch keine allgemeine Rangfolge zwischen Destillation und Reinforcement Learning fest.

32. Erzeugung synthetischer Daten

LLM – Die generierten Trainingsdaten werden in mehreren wiederkehrenden Mustern genutzt:

• Selbstinstruktion erstellt sich aus einer kleinen Anfangsmenge an von Menschen verfassten Anweisungen selbst: Der LLM erzeugt neue Anweisungen, Eingaben und Ausgaben, die gefiltert und wieder in den Pool aufgenommen werden. Alpaca Das Projekt nutzte 52.000 Beispiele aus 175 verschiedenen Quellen und gab einen Generierungskostenbetrag von rund 600 US-Dollar an; der Vergleich mit GPT-3.5 stellte lediglich eine eingeschränkte Projektbewertung dar und keine umfassende Gleichwertigkeit.
• Evol-Instruct (WizardLM) nimmt bestehende Anweisungen und entwickelt sie iterativ entlang von Komplexitätsachsen weiter – indem es Einschränkungen hinzufügt, Reasoning vertieft und die Probleme konkreter gestaltet – um so allmählich schwierigere Trainingsbeispiele zu erzeugen.
• Microsofts Phi-4** (14B) wurde für den größten Teil von Pretraining mit synthetischen Daten genutzt, insbesondere bei der Erstellung, Kritik, Selbstüberarbeitung sowie Umkehrung von Anweisungen. Sein technischer Bericht vergleicht die daraus resultierenden Leistungen im Bereich STEM und Programmierung mit denen größerer Models auf den ausgewählten Benchmarks.

Das hier relevante Risiko ist der Model-Kollaps: Wenn Models rekursiv anhand synthetischer Daten früherer Generationen trainiert werden, verschwinden allmählich die Randbereiche der ursprünglichen Verteilung. Dadurch überbewerten die Model häufige Muster und vernachlässigen seltene, aber wichtige Abweichungen.Shumailov et al., 2024). Eine weitere Studie von Ahrefs klassifizierte 74,2 % der neu erstellten Webseiten in ihrer Stichprobe von 900.000 Seiten als Texte, die durch AI erzeugt wurden; es handelt sich dabei um ein Ergebnis eines Herstellerspezifischen Klassifikators und nicht um eine Umfrage des gesamten Internets. Die Abmilderung dieses Problems beginnt mit der Mischung von synthetischen und echten Daten, dem Filtern sowie dem Nachverfolgen der Herkunft, damit rekursiv generiertes Material gemessen werden kann.

Teil VI – Skalierung und Deployment

Das Skalieren von einem GPU auf einen Cluster bedeutet, die Arbeitslast auf mehrere Geräte zu verteilen. In diesem Abschnitt werden Strategien zum Umgang mit Parallelität, Serving Frameworks, die Auswahl von GPU sowie Routing behandelt.

33. Vier Formen des Parallelismus

Tensor Parallelism (TP) verteilt die einzelnen Weight-Matrizen auf mehrere GPUs und kommuniziert in der Regel nach jedem Layer. Schnelle Intra-Node-Verbindungen wie NVLink machen diese Architektur innerhalb eines Nodes besonders praktikabel. Mehr Shards verringern zwar den Speicher- und Rechenaufwand pro Gerät, erhöhen aber die Kommunikationslast; daher sollte das Grad der Verteilung unter Berücksichtigung von Latency und Benchmark gewählt werden.

Pipeline Parallelismus (PP) verteilt die Schichten sequenziell über GPUs und leitet Activations zwischen den verschiedenen Phasen weiter. Das zugehörige Kommunikationsmuster funktioniert zwar auch zwischen Knoten, doch Pipeline-Effekte sowie ungleiche Ausführungszeiten der Phasen verringern die Auslastung. Große Deployments-Systeme kombinieren in der Regel TP innerhalb eines Knotens mit PP über mehrere Knoten hinweg.

Datenparallelität (DP) repliziert die Serving Model, sodass jede Replik unabhängige Anfragen verarbeiten kann, ohne dass für jede Anfrage eine Kommunikation zwischen den Repliken erforderlich ist. Sie ist effizient, wenn die Model ausreicht und der Datenverkehr ausgeglichen werden kann. Beim Training wird DP in der Regel mit ZeRO oder FSDP kombiniert, um den Zustand zu fragmentieren.

Expertenparallelität (EP) verteilt MoE Experten über GPUs unter Verwendung einer All-zu-All-Kommunikation zur Durchführung von Token Routing. Die Leistung hängt von der Token Ausgewogenheit, der Platzierung der Experten sowie der Topologie der Verbindungen ab; der All-zu-All-Datenverkehr kann dabei zum dominierenden Bottleneck werden.

Eine Heuristik für den Start mit Parallelisierung:

• Model passt auf einen GPU: Beginnen Sie mit unabhängigen Kopien und messen Sie die Skalierung des DP-Werts.
• Model passt in einen einzigen Knoten: Testen Sie den TP innerhalb des Knotens und replizieren Sie die Gruppe dann, falls der Datenverkehr dies erfordert.
• Model Spans Knoten: Prüfen Sie eine Kombination aus TP und PP im Zusammenhang mit der Vernetzung sowie dem Latency-Ziel.
• Mischung aus Experten: Fügen Sie EP nur dann hinzu, wenn die Platzierung der Experten dies erforderlich macht.

34. Vergleich von Serving und Frameworks

vLLM Es bietet eine paginierte Zuweisung von Schlüssel-Wert-Paaren, Continuous Batching, einen mit OpenAI kompatiblen API sowie mehrere Parallelisierungsmodi. Seine Model und die unterstützten Hardwarekomponenten ändern sich häufig, weshalb die Zielplattform Model stets anhand der aktuellen Kompatibilitätsmatrix überprüft werden sollte.

SGLang Es kombiniert RadixAttention zur Wiederverwendung von Präfixen, einen benutzerdefinierten Scheduler sowie strukturierte Generierung. Die veröffentlichten Leistungswerte von Throughput hängen vom Arbeitsaufwand und der Konfiguration ab; vergleichen Sie es mit vLLM und TensorRT-LLM unter Verwendung identischer Prompts-Einstellungen, Ausgaben, Hardware sowie SLOs.

TensorRT-LLM zielt auf niedrige Kosten pro einzelner Anfrage ab Latency durch CUDA Graph-Fusion und Kernel Optimierung, wobei die Agenten selbstständig agieren FP8/FP4 Support. Die veröffentlichten Werte beziehen sich auf Hardware- und Model-spezifisch, daher vergleichen Sie es mit den anderen. Frameworks auf einer Seite Harness. Der Kompromiss besteht in einer steileren Lernkurve sowie in Anforderungen, die spezifisch für NVIDIA gelten. Deployment Oberfläche.

TGI Er integriert sich in das Hugging Face-Ökosystem und unterstützt verschiedene Hardware-Backends-Komponenten. Überprüfen Sie vor der Auswahl für einen neuen Deployment den aktuellen Wartungs- sowie Funktionsstatus des Repositoriums.

Ollama Es wird auf eine einfache lokale Model Workflow hingewiesen. Nutzen Sie diese zur Erleichterung der Entwicklung; bei hoher Konkurrenz oder wenn eine präzise Steuerung der SLOs erforderlich ist, kommt ein weiterer Benchmark-Stack mit einer Serving-Architektur zum Einsatz.

llama.cpp Es handelt sich um einen portablen C/C++ Runtime mit Unterstützung für ARM-, x86-, Metal-, CUDA-, ROCm- sowie Vulkan-Beschleuniger. GGUF bietet mehrere Ebenen von Quantization an. Die Leistung hängt stark von der Model-, Quantization-Konfiguration, dem Kontext sowie den Backend ab; daher sollte zur Ausführung auf dem jeweiligen Gerät das dortige Benchmark-Tool verwendet werden.

35. Auswahl von GPU für Inference

Die Tabelle zeigt die Hardware- sowie Cloud-Preise für März 2026 Snapshot an. Die Angaben zu der Präzisionsstufe beziehen sich auf die Möglichkeiten des Herstellers, wobei sich die Preise je nach Anbieter, Region, Vertragslaufzeit und Verfügbarkeit unterscheiden können; überprüfen Sie diese daher vor dem Kauf.

Zunächst wird gemäß dem Speicherverbrauch ausgewählt, anschließend anhand der gemessenen Throughput-Werte am Latency-Ziel. Die 141 GB große Kapazität des H200 kann die Verarbeitung großer Model Deployments-Modelle vereinfachen, während der B200 zusätzlich FP4-Unterstützung, 192 GB HBM3e sowie einer neueren NVLink-Generation bietet. Kleinere, auf GDDR basierende GPUs-Geräte können kostengünstig für quantisierte Models-Anwendungen eingesetzt werden, sofern ihre Speicher- und Interconnect-Beschränkungen zur jeweiligen Arbeitslast passen.

Die Unterstützung für natives Hardware-Quantization hat einen erheblichen Einfluss auf die Leistung. AWQ sowie GPTQ (in Kombination mit INT4 Weights) können durch Dek Quantisierung in FP16-Register effizient auf jeder Architektur ausgeführt werden, doch eine echte native Beschleunigung mittels Tensor Cores hängt von der Generation ab. Die Modelle Hopper (H100/H200) und Ada (L40S/4090) beschleunigen FP8 nativ, während Blackwell (B200) zusätzliche native FP4 Tensor Cores bietet, um große Vorteile bei Throughput zu erzielen. Alle genannten GPUs unterstützen INT8-Matrixoperationen.

LLM Decode sind in der Regel durch die Speicherdurchsatzbeschränkung eingeschränkt, weshalb bei Serving-Arbeitslasten die Kapazität sowie der Durchsatz von HBM oft wichtiger sind als die maximale Anzahl an TFLOPS. Vergleichen Sie dabei GPUs unter Beibehaltung konstanter Werte für Model, Präzision, Verteilung der Datensätze im Batch, Länge des Kontexts sowie das von Latency festgelegte Ziel.

36. Model-Kaskadierung und Routing

Model Routing wählt aus, welcher LLM jede Anfrage aufgrund der vorhergesagten Komplexität oder Kapazitäten verarbeitet. RouteLLM (LMSYS/UC Berkeley, ICLR 2025) berichtet von einer 85-prozentigen Kostensenkung bei der Infrastruktur für MT-Bench, wobei gleichzeitig 95 Prozent der ursprünglichen Qualitätsebene von GPT-4 beibehalten werden konnten. Ob sich Routing rechnet, hängt von den aktuellen Preisen, der Zusammensetzung des Datenverkehrs, den Router-Fehlern sowie dem Mindestqualitätsstandard ab.

Routers reichen von leichten Klassifikatoren bis hin zu Judges, die auf LLM basieren. Die kaskadierte Variante funktioniert sequenziell: Eine Abfrage beginnt mit einem günstigeren Model und wechselt zu einer aufwändigeren Methode, sobald eine Bewertungsfunktion das Ergebnis ablehnt. FrugalGPT Es werden Kosteneinsparungen von bis zu 98 % oder eine höhere Genauigkeit von bis zu 4 % im getesteten Pool von Model festgestellt. Ein produktiver Cascade erfordert kalibrierte Eskalationskriterien sowie eine Überwachung der Anfragen, die der günstige Model fehlerhaft verarbeitet.

Teil VII – Anwendungen

Anwendungsbezogene Muster, die rohe Model-Fähigkeiten in nützliche Systeme umwandeln. Die Leistungsfähigkeit von Embeddings ermöglicht es Retrieval, dass RAG die Antworten auf externen Wissenstexten stützt, Agents übernimmt die Koordination mehrstufiger Workflows-Prozesse, und Prompt sorgt als Engineering-Element für die Gesamtkoordination.

37. Embedding Models im Vergleich zu generativen Models

Embedding Models Texte werden in vektorielle Strukturen fester Dimensionen kodiert, die semantische Bedeutungen erfassen. Im Gegensatz zu generativen Dekodern Models, die Token-Sequenzen erzeugen, liefern sie für den gesamten Eingang einen einzigen dichten Vektor mit 768–4.096 Dimensionen. Die meisten Embedding Models nutzen ausschließlich Encoder-basierte Transformer-Modelle (bidirektionale Attention), anstatt Dekoder. Der Encoder verarbeitet alle Eingabedaten Tokens gleichzeitig und erzeugt eine kontextualisierte Repräsentation für jeden Token. Anschließend kollabiert eine Pooling-Schicht diese pro-Token-Repräsentationen in einen einzigen Vektor – typischerweise mittels Mean-Pooling (Durchschnitt aller Token Embeddings) oder CLS-Pooling (unter Verwendung des Ausgangswerts einer speziellen Klassifizierungs-Token). Der Model wird schließlich mithilfe von kontrastivem Lernen feinjustiert: semantisch ähnliche Texte werden im Vektorraum enger zusammengebracht, während unähnliche Texte voneinander entfernt werden.

Ausgewählte Embedding Models sowie ihre gemeldeten Bewertungswerte (2025–2026):

Die Tabelle kombiniert Berichte von Model mit Versionen von Benchmark, weshalb es sich dabei um eine Auswahlliste und nicht um eine strenge Rangliste handelt. Einige neuere Embedding-Systeme nutzen Decoder-Backbones mit bidirektionaler Attention-Verarbeitung sowie Pooling-Techniken. Andere erzeugen weniger präzise oder multimodale Embeddings-Ausgaben. Bewertet die erforderliche Sprache, Modalitytät, Aufgabe, Dimension sowie den Serving-Kostenfaktor anhand eines Retrieval-Datensatzes.

Matryoshka-basiertes Repräsentationslernen (MRL, Kusupati et al., NeurIPS 2022) macht die Dimensionen von Embedding flexibel. Benannt nach den russischen Matrjoschka-Puppen strukturiert MRL einen Embedding so, dass seine ersten $m$ Dimensionen genauso informativ sind wie ein unabhängig trainierter $m$-dimensionaler Model. Während des Trainings wird anstelle der Berechnung eines einzigen Verlustwerts für die gesamte Embedding in MRL parallel mehrerer Verlustwerte in logarithmisch abgestuften Dimensionen (64, 128, 256, 512, 1024, 2048, 3072) berechnet. Der aggregierte Verlustwert sorgt dafür, dass die vorne liegenden Dimensionen grobe semantische Informationen tragen, während die späteren Dimensionen feinere Details hinzufügen.

Nach dem Training kann ein MRL Embedding auf eine unterstützte Präfixdimension verkürzt werden. Laut OpenAI übertrifft die Version text-Embedding-3-large mit 256 Dimensionen die Version text-Embedding-ada-002 mit 1.536 Dimensionen in dem von ihnen angeführten MTEB-Vergleich. Dadurch entsteht eine Reduzierung der Speicherung der Rohvektoren um das Sechsfache; auch die Kosten für Such-Latency- und Datenbankfunktionen hängen vom Index, den Metadaten, der Filterung sowie der Hardware ab.

Der Embedding Model ist ein wichtiger Bestandteil in einem RAG Pipeline, neben der Parsing-, Chunking-, Such-, Reranking- und Generierungsphase. Wenn relevante Belege nicht abgerufen werden können, ist es für einen leistungsstärkeren Generator nicht möglich, sie zuverlässig wiederherzustellen.

38. RAG-Architektur in der Produktion

Retrieval – Die erweiterte Generierung stellt einem LLM Dokumente zur Verfügung, die zum Zeitpunkt der Abfrage abgerufen werden. Dadurch können aktuelle oder vertrauliche Belege bereitgestellt werden, die in Model Weights fehlen, doch Retrieval garantiert nicht, dass die Antwort diese Belege korrekt verwendet. Ein produktionsreifes RAG-System ist ein mehrstufiger Pipeline, dessen einzelne Stufen einer separaten Bewertung unterzogen werden müssen.

Die Aufnahme von Pipeline erfolgt offline. Rohdokumente (PDFs, HTML, Markdown, Datenbanken) werden zunächst in sauberen Text umgewandelt – was schwieriger ist, als es klingt: Schon allein die Parsing von PDFs kann dazu führen, dass Tabellen, Überschriften und Formatierungen verloren gehen. Anschließend wird der Text in Blöcke aufgeteilt, die unabhängig voneinander eingebettet und indiziert werden.

Chunking beeinflusst sowohl die Retrieval-Rückrufrate als auch den für den Generator verfügbaren Kontext. Geeignete Größen hängen von der Dokumentstruktur, der Granularität der Abfrage, den Grenzen des Embedders sowie den Einschränkungen des Rerankers ab. Häufige Ansätze sind feste Größen mit Überlappung, rekursive Aufteilung entlang der Dokumentgrenzen sowie semantische Chunking-Bewertungen anhand von Embedding-Ähnlichkeiten. Man sollte diese Methoden anhand von Relevanzlabeln auf Seite- oder Abschnittsebene miteinander vergleichen, anstatt universell einen einzigen Token-Bereich zu verwenden.

Jeder Chunk wird anschließend mit einem Model versehen, ähnlich wie die in Abschnitt 37 und in einem Vector Database (Pinecone, Weaviate, Qdrant, pgvector usw.) gespeichert.

Der Retrieval Pipeline wird zur Zeit der Abfrage ausgeführt. Beginnen Sie mit einer messbaren Baseline und fügen Sie anschließend weitere Phasen hinzu, sobald die Fehleranalyse zeigt, dass sie tatsächlich fehlerhafte Fälle behandeln:

• Hybride Suche kombiniert dichte Vektoren Retrieval mit spärlichen Suchmethoden Retrieval wie BM25 und wird in der Regel mithilfe von Reciprocal Rank Fusion (RRF) zusammengeführt. Die dichte Suche bewältigt semantische Paraphrasen, während die spärliche Suche exakte Identifikatoren, Fehlercodes sowie Akronyme erfasst. Herstellerberichte Benchmarks weisen Vorteile gegenüber Baselines, die ausschließlich auf Vektoren beruhen, auf – doch die Größe des Ergebnissatzes hängt vom Korpus sowie den Relevanzlabeln ab.
• Reranking führt die abgerufenen Kandidaten durch einen Model, der sowohl die Anfrage als auch das Dokument bewertet. Dadurch kann eine feinere Relevanzbestimmung erreicht werden, allerdings auf Kosten einer zusätzlichen Aufrufung von Model. Die Anzahl der Kandidaten, die Anzahl der behaltenen Ergebnisse sowie Latency müssen gemeinsam abgestimmt werden. Ich habe den vollständigen mehrstufigen Prozess von Pipeline bereits behandelt. Aufbau eines modernen Such-Ranking-Stacks.
• Abfragedurch Transformation überschreibt die Eingabefrage des Benutzers vor Retrieval, um die Trefferquote zu verbessern. HyDE (Hypothetical Document Embeddings) nutzt die LLM-Funktion, um eine hypothetische Antwort zu erzeugen, die anschließend eingebettet und für Retrieval genutzt wird. Mehrfachabfrageerweiterung erzeugt mehrere Formulierungen derselben Frage. Rückwärts-Aufforderung stellt zunächst eine allgemeinere Frage, um einen breiteren Kontext zu erhalten.

Häufige Ausfallmuster:

• Retrieval-Fehler — Das korrekte Dokument existiert, wird jedoch nicht abgerufen. Prüfen Sie Chunking, die Abfragenumwandlung, die hybride Suche sowie das Metadatenfiltern im Zusammenhang mit diesem Fehlerfall.
• Kontextverfälschung — Irrelevante, abgerufene Textabschnitte führen dazu, dass der LLM in die Irre geführt wird. Überprüfen Sie dabei Reranking, die Kontextfilter sowie kleinere, zu behaltende Datensätze.
• Verlust im Mittelteil — Der LLM ignoriert relevante Kontexte, die sich im mittleren Bereich eines langen Prompt befinden.Liu et al., 2024 Es zeigte sich, dass Models den größten Teil seiner Aufmerksamkeit auf den Anfang und das Ende des Context Window richtete.

GraphRAG (Microsoft, 2024) erweitert den Vektor Retrieval um ein extrahiertes Entity-Relationship-Graph. Dadurch werden Fragen auf Korpus-Ebene sowie solche mit vielen Beziehungen abgedeckt, die eine einfache Aufteilung in Blöcke Retrieval übersehen könnten. Der Nachteil besteht dabei in zusätzlicher Arbeit bei der Extraktion, Indizierung, Speicherung und Bewertung.

Die Leitfäden für Praktiker geben Spektrumwerte für Latency in Bezug auf Embedding, Suchfunktionen, Reranking sowie Generierung an, wobei diese Werte je nach Region, Korpus, Hardware und Model variieren. Es ist erforderlich, jede Phase im Rahmen von Traces zu messen und vor der Übernahme des hinzugefügten Latency eine Bewertung der Qualitätsveränderung durchzuführen.

39. Agent-Architekturen und Toolaufrufe

LLM Agents – man nutzt Models, um Tool Calls im Zusammenhang mit einem sich verändernden Zustand auszuwählen und zu sequenzieren. Drei nützliche Orchestration-Muster sind:

• ReAct — es mischt die Auswahl von Aktionen mit Beobachtungen. Es kann sich nach jeder Tool Result anpassen, doch eine wachsende Historie erhöht die Kosten für Token und Latency. ReWOO — plant Tool Calls mit Platzhaltern, führt unabhängige Aufgaben parallel aus und synthetisiert anschließend die Ergebnisse. Die entsprechende Veröffentlichung weist Token Einsparungen gegenüber ReAct auf, doch ein starres Planungsmodell erfordert einen expliziten Wiederherstellungsmechanismus, falls ein Tool versagt.
• Planner-Executor — trennt Planning von der eigentlichen Ausführung und ermöglicht es, nach einem Fehler eine erneute Planning-Strategie anzuwenden. Dadurch wird eine Model-Spezialisierung möglich, doch es entstehen zusätzliche Orchestration-Zustände sowie eine weitere Entscheidungsgrenze.

Function Calling stellt ein gängiges Mechanismus zur Aufrufung von Tools dar. Durch die APIs werden Tool-Definitionen bereitgestellt und strukturierte Argumente zurückgegeben, wodurch das Parsen von freiformigen Texten überflüssig wird. Dennoch können schema-konforme Argumente weiterhin das falsche Tool auswählen oder ungültige Werte enthalten. Paralleler Function Calling Aufruf kann die Anzahl der Wechselbeziehungen zwischen Client und Server verringern, sofern die jeweiligen Operationen unabhängig voneinander sind.

Structured Output und Constrained Decoding stellen ein Schema durch Einschränkung der bei jedem Generierungsschritt verfügbaren Tokens sicher. Solche Engine wie xGrammar, Wird in vLLM sowie SGLang eingesetzt und kann in unterstützten Konfigurationen mit geringem Overhead zahlreiche Syntax- und Parsing-Fehler beseitigen. Es wird jedoch keine Garantie dafür übernommen, dass die extrahierten Werte oder Entscheidungen korrekt sind. schema-gesteuertes Reasoning (SGR) nutzt die Reihenfolge der Felder sowie die Struktur des Schemas, um den Zwischenzustand vor der endgültigen Entscheidung überprüfbar zu machen. Seine drei Muster sind Cascade (sequentielle Schritte), Routing (Union-Typen als semantische Schalter) sowie Cycle (begrenzte Listen).

Die Qualität der Werkzeugauswahl, die End-to-End-Qualität von Latency sowie die Kosten von Token verschlechtern sich in der Regel mit zunehmender Anzahl an Werkzeugen und größerer Tiefe der Ausführungsschritte. Diese Entwicklungen sollten anhand der tatsächlichen Werkzeudescriptions sowie der Fehlerverteilung gemessen werden. Frameworks wie zum Beispiel LangGraph Man kann den Zustand sowie die Wiederherstellungswege explizit machen, doch dadurch entfällt die Last der Bewertung nicht.

40. Prompt Engineering für die Produktion

Die Erstellung von Prompten für die Produktion stellt ein Bewertungsproblem dar: Man ändert einen Teil von Prompt oder den Kontext und misst anschließend die Qualität der Aufgabe sowie die möglichen Fehlermuster. Die unten aufgeführten Techniken bilden gängige Ausgangspunkte, sind jedoch keine universelle Reihenfolge.

Few-Shot-Beispiele sind in der Regel wirksam, um das Ausgabeformat zu steuern. Beginnen Sie mit 3–5 Beispielen, die leere Eingaben, mehrdeutige Anfragen sowie mehrteilige Antworten abdecken, und bewerten Sie anschließend das Ergebnis anhand eines getrennten Testsets. Die Beispiele sollten Span der tatsächlichen Eingabedistribution entsprechen und nicht nur den einfachsten Fall berücksichtigen. Zu viele Beispiele verbrauchen zusätzlichen Kontext und garantieren keine weiteren Verbesserungen.

Chain-of-Thought (CoT) – Prompting bedeutet, dass ein Model aufgefordert wird, vor der Beantwortung interne Reasoning offenzulegen. Kojima et al. berichteten von Verbesserungen durch den Suffix „Lassen Sie uns schrittweise nachdenken“ bei den getesteten Reasoning-Aufgaben, wobei die Wirkung je nach Model variiert und neuere Reasoning APIs möglicherweise versteckte Traces nicht preisgeben. Für die Produktion sollte man eine überprüfbare Aufgabenteilung oder eine prägnante Begründung bevorzugen, sofern dies für den Evaluator nützlich ist. Selbstkonsistenz (Wang et al., 2023) Es werden mehrere Pfade mit Reasoning ausprobiert und die Ergebnisse zusammengefasst, wobei ein zusätzlicher Aufwand in Form von Inference in Kauf genommen wird, um bei geeigneten Aufgaben eine hohe Zuverlässigkeit zu gewährleisten.

Structured Output unter Verwendung expliziter JSON-SchemataAbschnitt 39) beseitigt zahlreiche Fehler bei der Parsing-Verarbeitung. Constrained Decoding Engines wie xgrammar können während der Generierung die unterstützte Grammatik durchsetzen; eine Überprüfung auf faktische Genauigkeit und semantische Gültigkeit ist dennoch erforderlich, und nicht unterstützte Schema-Eigenschaften müssen möglicherweise weiterhin behandelt werden.

Prompt Chaining unterteilt eine Aufgabe in gezielte Phasen – beispielsweise Absicht klassifizieren → Kontext abrufen → Antwort generieren → Ausgabe validieren. Dadurch lassen sich Fehler lokalisieren, für jede Phase unterschiedliche Models definieren sowie cachierbare Zwischenzustände bereitstellen. Zudem werden Schnittstellen und Latency hinzugefügt; vergleichen Sie dies daher mit einem Szenario, bei dem alle Schritte in einer einzigen Aufrufsequenz ausgeführt werden.

Temperatur beeinflusst die Stichprobenverteilung. Niedrige Werte sind ein sinnvoller Ausgangspunkt für Klassifizierungs- oder Extraktionsaufgaben; höhere Werte können die Vielfalt bei der Ideengenerierung erhöhen. Das genaue Verhalten unterscheidet sich je nach Model APIs und wirkt sich auf top_p, top_ksowie die Standardwerte des Anbieters – daher sollten die unterstützten Einstellungen für die Aufgabe durchgescannt werden, anstatt nur einen bestimmten Bereich zu kopieren.

Trennung von System- und Benutzernachrichten sorgt dafür, dass die dauerhaften Richtlinien vom Inhalt pro Anfrage getrennt bleiben. Chat-Vorlagen sowie Anpassungen der Anweisungen verleihen diesen Rollen unterschiedliche Priorität, doch sie machen eine Systemnachricht nicht automatisch zu einer Grenze für die Durchsetzung von Vorgaben. Legen Sie stabiles Verhalten in die Systemnachricht fest, halten Sie unzuverlässige Daten im Benutzer- oder Tool-Inhalt auf, und setzen Sie strenge Einschränkungen wie den Entfernung von PII außerhalb des Model durch.

Context Engineering erweitert die Arbeit von Prompt um die Aggregation von abgerufenen Dokumenten, Tool Results, Konversationshistorien sowie Beispielen. Liu et al. stellten im langkontextuellen Models, das sie getestet haben, ein „Lost-in-the-Middle“-Phänomen fest; daher sollte die Positionierung Teil der Bewertung sein und nicht als irrelevant angesehen werden. Ich habe das umfassendere Konzept des Workflow behandelt. Context Engineering für AI Agents.

Teil VIII – Produktionsbetrieb

Dieser Abschnitt behandelt Themen wie Rate Limiting, Fehlermodi, Überwachung, Kosteneffizienzsteigerung sowie Kapazitätsplanung Planning unter echtem Traffic.

41. Rate Limiting für Anfragen mit variablen Kosten

Die herkömmliche Rate-Limiting-Methode basierend auf Anfragen pro Sekunde geht davon aus, dass die Kosten pro Anfrage annähernd gleich sind. LLMs Stören Sie diese Annahme. Ein Wert von 10–Token Klassifizierung Prompt und ein 100K-Token Die Dokumentenanalyse stößt auf das gleiche Problem. API Der Endpunkt unterscheidet sich zwar in den Kosten um vier Größenordnungen, doch die durch RPS erfolgende Limitierung lässt entweder teure Anfragen ungeprüft durch oder vernachlässigt unnötigerweise günstigere Anfragen.

Produktionsysteme benötigen eine auf Token basierende Rate-Limiting-Strategie, die mehrere Dimensionen berücksichtigt. OpenAI Dokumentiert die Anfragen sowie die durch die Nutzungsebene festgelegten Token-Limitierungen. Anthropic trennt die Eingangs-Token- und Ausgangs-Token-Grenzen voneinander. Genaue Quoten sowie Algorithmen können sich ändern, weshalb die Dokumentation des Anbieters als verbindliche Quelle angesehen werden sollte; das architektonische Ziel besteht darin, Anfragen sowie Tokens unabhängig voneinander zu planen.

Das praktische Implementierungsmodell besteht aus einer mehrdimensionalen Hierarchie von Beschränkungen (Benutzer → Anwendung → Organisation → global), wobei für Premium-Zugänge unterschiedliche Prioritätsstufen vorgesehen sind. Auf Ebene der Anfragen ist die entscheidende Technik die Budgetreservierung für Token: Es wird eine Gesamtsumme für Tokens geschätzt (Eingaben + max_tokens) Wird zum Zeitpunkt der Aufnahme die entsprechende Menge aus dem Puffer abgezogen und anschließend nach Abschluss der Anfrage entsprechend dem tatsächlichen Verbrauch angepasst. Dadurch wird verhindert, dass eine Welle von Anfragen mit langer Generierungszeit die Kapazität bereits vor dem Erstellen der Ausgabe erschöpft.

Für selbst gehostete Deployments-Lösungen entspricht dies der Bereitstellung von Throughput: Dabei wird eine dedizierte GPU-Kapazität für die gewünschten Token-Tarife reserviert. Bei vLLM Deployments bedeutet das, dass eine Zulassungskontrolle auf der Grundlage aktiver Decode-Slots sowie des KV cache-Drucks konfiguriert wird – anstelle allein der Anzahl der Anfragen. Abschnitt 5 Es wird erläutert, dass sowohl Throughput als auch die Zulassung begrenzt werden müssen, wobei diese Grenzen Token berücksichtigen müssen.

42. Ausfallmuster, gegen die geplant werden muss

LLM Serving fügen Versagenstypen hinzu, die mit variabler Sequenzlänge, KV-Speicher sowie lang andauernden Decode Aufgaben zusammenhängen. Entwerfen und Lasttesten Sie die Schutzmechanismen, bevor der Produktivverkehr auf sie angewiesen ist.

Out-of-Memory (OOM) ist ein häufiges Versagen. Ein 70B FP16 Model benötigt allein für die Weights etwa 140 GB, und KV cache kann unter den angegebenen Annahmen für eine einzige Sequenz mit einem Kontextumfang von 128 K weitere etwa 40 GB verbrauchen. Abschnitt 6. Der Unterschied zwischen „passt in den Speicher“ und „OOM unter Last“ ist geringer, als es scheint, da eine Gruppe von Anfragen mit langem Kontext mehr KV-Speicher verbrauchen kann, als erwartet. Die Prävention erfolgt durch eine gezielte Speicherreservierung in Kombination mit Quantization sowie paginiertem KV-Zuweisungsmechanismus. Bei Workloads mit hohem KV-Druck LMCache Kann Daten des KV-Speichers auf den Speicher oder die Festplatte von CPU abladen; nutzt die dort veröffentlichten Ergebnisse als Ausgangspunkt sowie die lokale Speicherverwaltungshierarchie von Benchmark.

Preemption tritt auf, wenn der Druck durch KV cache den Scheduler zwingt, Arbeitslasten zu entfernen oder neu zu berechnen. Die genaue Strategie hängt von der Version sowie der Konfiguration von Serving ab. Für den Benutzer äußert sich dies in einer höheren Gesamtlatenz von Latency, ohne dass ein offensichtlicher Anwendungsfehler auftritt. Überwachen Sie die Zahlen zur Preemption und ordnen Sie sie dem KV-Auslastung, der Warteschlangentiefe sowie der Länge der Anfragen zu.

Tail Latency kann ansteigen, wenn große Vorausdaten die Ausführung von Decode verzögern. In Blöcke unterteilte Prefill (Abschnitt 7) Zur Minimierung dieser Störungen wird ein auf die Länge ausgerichteter Scheduling-Zielwert eingesetzt. In den Arbeiten zu Learning-to-Rank sowie CascadeInfer werden erhebliche Verbesserungen gegenüber den Baseline-Methoden berichtet, wobei das genaue Ergebnis von der Verteilung der Anfragelängen sowie der Konfiguration des Schedulers abhängt.

Kaskadierte Ausfälle können entstehen, wenn langsame Anfragen die Warteschlange vergrößern, upstream-Kunden den Zeitlimit erreichen und Wiederholungsversuche zusätzliche Last verursachen. Zu den Schutzmaßnahmen gehören Admissionskontrolle, Konkurrenzlimits pro Tenant, Ausgaboberge, Wiederholungsbudgets sowie Circuit Breaker an der Gateway-Ebene. Dezentralisierte Pools für Prefill und Decode können hilfreich sein, wenn Load Tests anhaltende Phaseninterferenzen aufweist.

43. Überwachung von LLM-Systemen

Die Überwachung von LLM unterscheidet sich in einigen grundlegenden Aspekten von der herkömmlichen API-Überwachung. Jeder Anfragen hat einen variablen Kostenfaktor, es gibt zwei unterschiedliche Phasen mit verschiedenen Bottlenecks-Werten, und der Speicherverbrauch hängt sowohl von der Länge der Eingabe als auch von der Länge der erzeugten Ausgabe ab. Standardmetriken wie die Anfragenanzahl Latency sowie die Fehlerquote erfassen den größten Teil der relevanten Informationen nicht.

Goodput gibt die Anzahl der Anfragen pro Sekunde an, die alle definierten SLO-Schwellenwerte erfüllen – wie beispielsweise TTFT, TPOT sowie die Gesamtmenge an Latency. Es handelt sich dabei um einen nützlichen zusammenfassenden Indikator, da die rohen Werte von Throughput zwar gesund erscheinen mögen, während die entsprechenden Latency-SLOs nicht eingehalten werden. Ein System, das 100 Anfragen pro Sekunde verarbeitet, bei denen jedoch 40 Prozent die Schwellenwerte überschreiten, weist einen goodput von 60 auf. Durch die Optimierung nach goodput bleibt die Verteilung der Leistung sichtbar, anstatt lediglich den Durchschnitt angegeben zu werden.

vLLM stellt einen Prometheus-Endpunkt bereit. /metrics Bei laufenden sowie wartenden Anfragen werden KV cache, Verteilungen der Generierungslängen sowie Statistiken des Präfix-Caches genutzt. Die Namen der Metriken können von Version zu Version variieren, weshalb Dashboards an die tatsächlich bereitgestellte Version gebunden werden sollten. Ein typischer Stack setzt dabei Prometheus für die Erfassung von Metriken, Grafana für die Visualisierung sowie OpenTelemetry-kompatible Traces in den Anwendungs- und Serving-Komponenten ein.

Zu den nützlichen Alarmmustern gehören die folgenden. Bestimmen Sie deren Schwellenwerte anhand von Load Tests, anstatt diese Beispiele unverändert zu übernehmen:

• Anstieg der Preemption-Zahlen – Anfragen werden aus dem System entfernt und neu gestartet; die Nutzer erleben eine stillschweigende Verdopplung von Latency.
• Die KV cache-Auslastung nähert sich dem im Test ermittelten Preemption-Bereich – es ist erforderlich, Kapazitäten hinzuzufügen oder Lasten zu reduzieren, bevor es zu Entfernungen von Anfragen kommt Cascade.
• Die Warteschlangentiefe liegt kontinuierlich über dem im Test ermittelten Grenzwert – das Zulassungsmanagement sollte in diesem Fall Anfragen ablehnen oder deren Priorität senken.
• TTFT steigt an, während TPOT konstant bleibt – diese Abweichung deutet zunächst auf Probleme mit der Warteschlange, der Zulassung, dem Netzwerk oder dem Druck durch Prefill hin und weniger auf Probleme im Zusammenhang mit Decode Throughput. Um zwischen diesen Ursachen zu unterscheiden, sollten Traces sowie Warteschlangenmetriken herangezogen werden.

44. Kosteneffizienzoptimierung: Eine kompoundierte Strategie

Da es sich um veraltete Snapshot-Preise vom März 2026 API handelt, lagen die Kosten in den verschiedenen Model-Kategorien in ganz unterschiedlichen Größenordnungen. Da sich die genauen Preise schnell ändern, sollte man zur Entscheidungsfindung stets den aktuellen Kalkulator des Anbieters nutzen. Entscheidend ist dabei, dass bereits die Wahl des Model sowie die Länge der Ausgabe einen erheblichen Einfluss auf die Rechnung ausüben können – und das noch bevor Infrastrukturoptimierungen erfolgen.

Im für diesen Abschnitt verwendeten Snapshot von März 2026 kostete die Ausgabe Tokens mehrere Male so viel wie die Eingabe Tokens für die genannten Model Ebenen. Diese Asymmetrie spiegelt die sequenzielle Decode Verarbeitung wider, wie sie beschrieben wurde. Abschnitt 7. Bei solchen Preismodellen kann die Reduzierung unnötiger Ausgabe einen größeren Effekt erzielen als das Kürzen derselben Menge an Eingabe Tokens.

Mehrere Ansätze können übereinander gestapelt werden, allerdings erst nachdem festgestellt wurde, welche für die jeweilige Arbeitslast geeignet sind:

1. Quantization von FP16 bis INT4 reduziert den Speicherverbrauch von Weight um 75 %. Ob dadurch die Kosten sinken, hängt von der Geschwindigkeit von Kernel, der Größe der Batch-Verarbeitung sowie der Auslastung der Hardware ab.Abschnitt 9).
2. Model Routing leitet den qualifizierten Traffic an günstigere Models weiter. Ein Maxim AI – Fallstudie eines Anbieters Es wurde ein monatlicher Rückgang der Rechnungszahlung von 42.000 US-Dollar auf 29.000 US-Dollar gemeldet; die Qualitätsprüfung muss vor dem Freigeben des Routing-Teils erneut durchgeführt werden.Abschnitt 36).
3. Prompt Caching verringert die Arbeit durch wiederholte Präfixverarbeitung. Da Anbieterrabatte sowie Beschränkungen hinsichtlich der Anfragenhäufigkeit im Laufe der Zeit ändern, sollte die gemessene Aufrufrate mit den aktuellen Bedingungen kombiniert werden.Abschnitt 16).
4. Batch APIs ermöglicht es, nicht-echtzeitbasierte Aufgaben wie Evaluierungen, Erstellung synthetischer Daten sowie Massenklassifizierungen zu bewältigen. Überprüfen Sie die aktuellen Preise sowie die dafür erforderlichen Zeiträume.
5. Self-hosting kann bei einer kontinuierlichen Nutzung vorteilhaft sein, doch es existiert kein universeller Break-Even-Punkt hinsichtlich des Token-Volumens. Neben den Mietkosten für GPU müssen außerdem Kosten für Ingenieurarbeit, Orchestration, Observability, Kapazitätsreserven sowie Notfalldienste berücksichtigt werden.

Durch Multiplikation der exemplarischen Faktoren ergibt sich eine erhebliche theoretische Reduktion, doch die Eingangsgrößen sind nicht unabhängig voneinander: Quantization verändert Throughput, Routing beeinflusst das Qualitätsprofil, und Caching sowie Batching gelten ausschließlich für geeigneten Traffic. Erstellen Sie die Schätzung anhand der gemessenen Trafficanteile und überprüfen Sie sie im Vergleich zur Rechnung.

A Verkäuferbericht 2024 von TrueFoundry die wichtigsten Attribute Deployment der Kostenanteil im jeweiligen Sample ML Ingenieurwesen statt Rechenleistung. Behandeln Sie diese Zahl als Prompt um Arbeitskräfte und Betriebsabläufe einzubeziehen Modelnicht als universelle Verhältniszahl.

45. Kapazität Planning und Automaskalierung

Die Kapazität Planning für LLM Serving muss die variablen Anfragedatenkosten, lang andauernde Decode Aufgaben sowie sequenzabhängige Speicherverbrauche berücksichtigen. Je nach Arbeitslast kann der begrenzende Faktor entweder der KV-Speicher, die Speicherbreite, die Rechenleistung oder die Interkonnektierung sein.

Die harte Obergrenze für parallele Anfragen ist das Speicherkapital von KV cache und nicht die Anzahl der FLOPs:

$\text{maximale Anzahl paralleler Sequenzen} = \frac{\text{GPU Speicher} - \text{Model Weights} - \text{Overhead}}{\text{Größe pro Sequenz KV cache}}$

In einem vereinfachten Beispiel mit Llama 3 70B INT4 benötigt man etwa 35 GB an Weights auf einer 80-GB-H100-Karte, wodurch nach Berücksichtigung weiterer Overhead-Kosten noch rund 40 GB verbleiben. Bei einem Kontextumfang von 4K ergeben sich aufgrund einer geschätzten Größe von 160 MB pro Sequenz theoretisch bis zu 250 Sequenzen; bei 128K sinkt diese Zahl auf etwa fünf. Die tatsächliche Kapazität ist geringer, sobald das Verhalten des Allocators, Runtime-Puffer, Schwankungen in der Anfragenlänge sowie die Latency-SLO berücksichtigt werden. Genau aus diesem Grund GPU-Selektion und KV cache-Optimierung direkt den Kapazitätsplan steuern.

Die Kapazitätsformel zur Bestimmung der Flottengröße:

$\text{ erforderliche GPUs} = \frac{\text{Höchstwert Tokens pro Minute} \times \text{gemessener Sicherheitspuffer}}{\text{pro-GPU Throughput beim Ziel-SLO}}$

Der entscheidende Aspekt ist, dass der Wert „am Zielwert des SLO“ liegt. Spitzenwert Token Throughput und SLO-konform Throughput Die Leistung kann mit zunehmender Parallelisierung stark abweichen. Benchmark mit dem echten Prompt sowie die Verteilung der Ausgabellänge bei den erforderlichen TTFT- und TPOT-Schwellenwerten anstelle eines theoretischen Maxima.

Die GPU-Auslastung ist als einziger Skalierungssignal nicht ausreichend, da sie sowohl bei normaler Verarbeitung als auch bei Überlastung hoch bleiben kann. Kombinieren Sie sie mit der Warteschlangentiefe, der KV cache-Auslastung sowie dem Grad der goodput-Verschlechterung. Passen Sie die Schwellwerte anhand von Load Tests an; Werte wie eine 80%-ige KV-Auslastung dienen lediglich als Ausgangspunkte und nicht als universelle Grenzwerte. Diese Metriken werden in Abschnitt 43.

Durch Skalierung auf Null lassen sich Entwicklungs- und Staging-Umgebungen mit langen Inaktivitätszeiten effektiv abdecken. Serverless Inference-Plattformen sowie auf Kubernetes basierende Autoscaler wie KEDA können inaktive Ressourcen bereinigen, wobei die Einsparungen sowie die Zeit bis zum Erststart von der Größe der Model, der Verwendung von Bildern und dem Caching über Weight sowie der zugrunde liegenden Infrastruktur abhängen. Messen Sie zunächst die Startzeit, bevor Sie dieselbe Strategie für den produktionssensiblen Verkehr mit Latency anwenden.

Das vernetzte System

Diese 45 Konzepte bilden keine willkürliche Ansammlung, sondern ein vernetztes System. Die Größe von KV cache bestimmt die Batch-Größe, die Batch-Größe wiederum beeinflusst die arithmetische Intensität. Diese bestimmt schließlich, ob Decode an Speichermengen gebunden ist – was wiederum den TPOT bestimmt – und der TPOT legt schließlich Throughput fest. Durch GQA verringert sich KV cache, wodurch größere Batches möglich werden. Dadurch steigt die arithmetische Intensität, was wiederum die Auslastung von GPU verbessert. FlashAttention nutzt die Bandbreitenlücke zwischen SRAM und HBM aus. Continuous Batching löst das Problem der Rechenleistungsauslastung, verursacht jedoch Speicherverfrachtung, welche wiederum von PagedAttention behoben wird. Durch chunkbasiertes Vorgehen mit Prefill werden rechenintensive und speicherintensive Aufgaben gemeinsam geplant; die sogenannte „Roofline“-Konzeption von Model erklärt, warum diese Kombination funktioniert.

Auf der Trainingsseite kann die Lebenszykluskostenrechnung es begünstigen, einen kleineren Model auf mehr Tokens zu trainieren, wie Llama 3 8B zeigt. GRPO verringert die Last des Kritiker-Zustands bei PPO. In der getesteten kleinen-Model-Konfiguration von DeepSeek-R1 übertraf die Destillation die direkte RL-Methode. Es handelt sich dabei um Designoptionen, die geprüft werden sollten, und nicht um ein einziges festes Trainingsverfahren.

Das Betriebsmuster ist stabiler als jede Preiskurve: Routing, Caching, Quantization sowie hardwareseitig optimale Ausstattung erzielen ihre Wirkung erst dann, wenn alle Faktoren anhand derselben Qualitätsstandards und des Latency-Ziels bewertet werden.

Schlüsselprinzipien

1. LLM Inference weist zwei unterschiedliche Phasen auf. In herkömmlichen Serving-Umgebungen neigt sich Prefill stärker hin zum Rechenaufwand, während Decode eher dem Speicherbandbreitenbedarf zugutekommt; die Struktur der Arbeitslast kann diese Grenze verschieben.
2. Die KV cache stellt häufig eine zentrale Einschränkung dar. Ihre Größe beeinflusst sowohl die Kapazität für Batch-Aufgaben als auch den Speicherdruck. GQA, paginierte Zuweisungen sowie KV-Quantization-Strukturen adressieren jeweils unterschiedliche Aspekte dieser Einschränkung.
3. Die GPU-Speicherverwaltungskonzepte erklären viele Optimierungen. Durch die Fusion von FlashAttention und Kernel wird teurer Datentransport vermieden, anstatt die Funktionsweise der Model zu ändern.
4. Continuous Batching und PagedAttention arbeiten zusammen. Eine veröffentlichte Vergleichsstudie weist einen Faktor von 23x im Vergleich zur naiven Baseline für Throughput aus; messen Sie den Gewinn in Ihrer eigenen Serving-Architektur.
5. Ein chinchilla-optimales Modell ist nicht zwangsläufig Inference-optimiert. Llama 3 8B wurde beispielsweise mit etwa 1.875 Tokens pro Parameter trainiert, um mehr Rechenleistung für günstigere Inference-Kosten einzusetzen.
6. GRPO sowie Verfahren der Destillation haben das Toolset zur Ausrichtung von Modellen verändert. DeepSeek-R1 zeigte durch Destillation bessere Ergebnisse bei kleinen Model-Modellen im Vergleich zu den direkten RL-Experimenten.
7. Kostenoptimierungen ergeben sich nur dann zusätzlich, wenn sie auf geeigneten Datenverkehrsströmen angewandt werden. Model Quantization, Routing, Caching sowie Batch-Verarbeitung mit APIs erfordern getrennte Messungen hinsichtlich ihrer Effektivität und Qualität, bevor ihre Einsparungen potenziert werden können.
8. Serving-Hardware muss der Bottleneck entsprechen. Decode-intensive Arbeitslasten profitieren in der Regel von ausreichender HBM-Kapazität sowie Bandbreite; Prefill-intensive Arbeitslasten belasten hingegen den Recheneinsatz stärker durch Weight.

Weitere Literatur

Weitere ausführliche Artikel dieses Blogs, nach Themen geordnet:

• Leitfaden für LLM und Fine-Tuning — Wann ist Fine-Tuning gegenüber RAG und Prompt-Engineering vorzuziehen? Open-Source-Varianten und Dateiformate von LLM — Abstimmung der Varianten von Model sowie der quantisierten Formate auf die Hardware LoRAX Serving Leitfaden — Serving Tausende von LoRA-Adaptern in der Produktion
• Skalierung großer Sprachmodelle Models — Mehr-GPU- und Mehrknotenstrategien Lokaler LLMs unter macOS — praktische Einrichtung mit llama.cpp und Ollama AI Agent Reasoning Schleifen im Jahr 2026 — tiefer Einblick in ReAct, ReWOO sowie Planner-Executor-Schleifen
• AI Agent Memory Architektur im Jahr 2026 — Checkpoints, Vector Stores sowie Dokumentenmemorien für Zustandsbasierte Agents

Referenzen

Gestuft nach Themenbereich; Abschnittsnummern in Klammern, sofern zutreffend.

Inference und Attention

• FlashAttention: Schnelle und memorieneffiziente exakte Attention-Lösung mit Berücksichtigung von I/O-Auswirkungen - Dao et al., NeurIPS 2022 FlashAttention-2: Schnellere Attention dank verbessertem Parallelismus und Arbeitsteilung. - Dao, 2023
• FlashAttention-3: Schnell und präzise Attention durch Asynchronität und geringe Präzision - Shah et al., NeurIPS 2024 Flash-Decodierung für lange Kontexte Inference - Dao et al., 2023
• Effizientes Speichermanagement für große Sprachmodelle Model Serving mithilfe von PagedAttention - Kwon et al., SOSP 2023
• Orca: Ein verteiltes Serving-System für transformerbasierte generative Models-Modelle - Yu et al., OSDI 2022
• GQA: Schulung von generalisierten Mehrabfragen mit Attention - Ainslie et al., 2023 Triton: Eine Zwischensprache sowie Compiler für Berechnungen in neuronalen Netzen - Tillet et al., MAPL 2019
• FlashNorm: Schnelle Normalisierung für LLMs - 2024
• Deep Kernel Fusion für Transformer-Modelle - DeepFusionKernel, 2026

Spekulative Dekodierung

• EAGLE-3: Skalierung nach oben Inference Beschleunigung großer Sprachmodelle Models - Li et al., NeurIPS 2025 Medusa: Einfache LLM Inference Beschleunigung Framework mit mehreren Dekodierkopfen - ICML 2024

Quantization

• AWQ: Activation-aware Weight Quantization zur LLM-Kompression und -Beschleunigung - MLSys 2024 Bestes Paper GPTQ: Präzise Post-Training Quantization für generative, vorgetrainierte Transformer-Modelle - Frantar et al., ICLR 2023
• Marlin: Mischgenauigkeit (FP16xINT4) LLM Inference Kernel - Frantar et al., 2024

Training und Fine-Tuning

• LoRA: Niederrangige Anpassung großer Sprachmodelle Models - Hu et al., ICLR 2022 QLoRA: Effizientes Feintunen von quantisierten LLMs - Dettmers et al., NeurIPS 2023
• ZeRO: Speicheroptimierungen für das Trainieren von Modellen mit Billionen an Parametern Models - Rajbhandari et al., SC20 ZeRO-Infinity: Durchbrechung der GPU-Gedächtnisbarriere für tiefes Lernen in extremem Skalenniveau - Rajbhandari et al., 2021 Self-Instruct: Ausrichtung der Sprache Models an selbst generierten Anweisungen - Wang et al., ACL 2023
• WizardLM: Die Fähigkeit großer Sprachmodelle Models zu stärken, um komplexe Anweisungen auszuführen - Xu et al., ICLR 2024 Technischer Bericht Phi-4 - Microsoft, 2024 AI Models kollabiert bei Schulung mit rekursiv erzeugten Daten - Shumailov et al., Nature 2024

Ausrichtung

• Direkte Präferenzoptimierung: Ihre Sprache Model ist im Grunde genommen eine Belohnung Model - Rafailov et al., NeurIPS 2023 DeepSeekMath: Die Grenzen der mathematischen Reasoning in offenen Sprachmodellen Models weiter verschieben - Einführung von GRPO
• DeepSeek-R1: Anreizschaffung für die Reasoning-Fähigkeit in LLMs mittels Verstärkungslernen - DeepSeek, 2025

Skalierung und Architektur

• Die Llama 3 Herde von Models - Meta, 2024 LLaMA: Eine offene und effiziente Grundlagen-Sprachmodell-Plattform Models - Touvron et al. (Meta), 2023
• Llama 2: Offene Foundation-Version sowie feinabgestimmte Chat-Version Models - Touvron et al. (Meta), 2023 Technischer Bericht zu Qwen3 - Qwen Team (Alibaba), 2025 Rechenressourcen-optimiertes Training großer Sprachmodelle Models - Hoffmann et al. (Chinchilla), NeurIPS 2022
• RoFormer: Ein verbessertes Transformer-Modell mit rotierender Positionierung Embedding - Su et al., 2021 YaRN: Eine effiziente Context Window Erweiterung für große Sprachmodelle Models - Peng et al., ICLR 2024 SGLang: Effiziente Ausführung von Programmen in strukturierter Sprache Model - Zheng et al., NeurIPS 2024
• Mixtral of Experts - Jiang et al. (Mistral AI), 2024

Embeddings

• Matryoshka-basiertes Repräsentationslernen - Kusupati et al., NeurIPS 2022 pplx-embed-v1: Diffusionsvorbereitete dichte und kontextuelle Embeddings - Perplexität AI, 2026

Agent-Architekturen

• ReAct: Synergie zwischen Reasoning und Handeln in Sprache Models - Yao et al., ICLR 2023
• ReWOO: Trennung von Reasoning von Beobachtungen zur effizienten Erweiterung sprachbasierter Models Systeme - Xu et al., 2023

Routing

• RouteLLM: Lernen des Routenplanens mit LLMs unter Verwendung von Präferenzdaten - Ong et al., ICLR 2025

Benchmarks

• Ergebnisse von MLPerf Inference v5.0 - MLCommons, April 2025

Serving-Architekturen

• SARATHI: Effiziente LLM Inference durch Nutzung von Dekodierungen im Piggybacking-Verfahren mit in Blöcken vorbereiteten Prefills - Agrawal et al., 2023 (in Blöcken strukturierte Prefill) Splitwise: Effiziente generative LLM Inference durch Phasentrennung - Patel et al., ISCA 2024 (aufgeschlüsselte Serving)
• DistServe: Aufteilung von Prefill sowie Dekodierung für auf Goodput optimierte große Sprachmodelle Model Serving - Zhong et al., OSDI 2024 (Dezontologisierte Serving)

Serving Frameworks

• vLLM - PagedAttention-basierter Serving-Motor SGLang - RadixAttention und strukturierte Generierung
• TensorRT-LLM - Von NVIDIA optimierter Inference
• llama.cpp - Portabler C/C++ Inference
• DeepSpeed - Microsoft-Distributed-Training-Bibliothek
• Ollama - Lokaler LLM-Ausführer

Betrieb

• Effizientes LLM-Scheduling durch Lernen zur Rangbestimmung - Fu et al., NeurIPS 2024 (vLLM-LTR) CascadeInfer: Niedrige Latency-Kosten sowie lastbalancierte LLM-Verarbeitung von Serving durch längenbewusste Scheduling-Strategien - 2024
• Die als Maß für die ML Produktivität verwendete Goodput-Metrik - Google Cloud, 2024 vLLM Optimierung und Abstimmung - vLLM Dokumentation vLLM Metriken - vLLM Dokumentation
• LMCache: Verwaltung von KV Cache für LLM Serving - KV cache Auslastungsreduzierung Rate Limits von OpenAI - OpenAI API-Dokumentation Rate Limits von Anthropic - Anthropic API-Dokumentation