GPU-Performance-Tuning: Maximierung des Durchsatzes für LLM-Training und Inferenz

Aktualisiert am 8. Dezember 2025

Update Dezember 2025: FP8-Training ist jetzt produktionsreif auf H100/H200 und Blackwell und liefert 2x höheren Durchsatz gegenüber FP16 bei gleichwertiger Genauigkeit. Flash Attention 3, optimiert für die Hopper-Architektur, erreicht 1,5-2x Beschleunigung. vLLM 0.6+ und TensorRT-LLM liefern 3-5x Verbesserungen beim Inferenz-Durchsatz durch Continuous Batching und Speculative Decoding. torch.compile mit Triton-Backend ist jetzt Standard für PyTorch 2.4+. NVIDIA NeMo Framework 2.0 bietet End-to-End-optimierte Training-Pipelines.

Ein perfekt konfigurierter 8-GPU-Knoten erreicht 98% der theoretischen FLOPS, während ein schlecht abgestimmtes identisches System bei 43% kämpft und jährlich 380.000 Dollar durch unterausgelastete Hardware verschwendet.¹ MLPerf-Benchmarks zeigen, dass Spitzenreiter 2,3x mehr Durchsatz aus identischen H100-GPUs herausholen als der Median der Einreichungen, wobei der Unterschied ausschließlich auf Software-Optimierung und nicht auf Hardware-Vorteile zurückzuführen ist.² Die Lücke zwischen theoretischer und erreichter Leistung verfolgt jedes KI-Team, wo ein einziger falsch konfigurierter Parameter die Trainingszeit verdoppeln oder die Inferenzkosten verdreifachen kann. Organisationen, die GPU-Performance-Tuning beherrschen, schließen das Modelltraining 60% schneller ab und bedienen Inferenz-Anfragen zu 40% niedrigeren Kosten pro Token als Wettbewerber mit Standardkonfigurationen.

NVIDIAs Optimierungsleitfäden umfassen 1.200 Seiten über verschiedene Frameworks, Kernel und Konfigurationen, doch die meisten Teams implementieren aufgrund von Komplexität und Zeitbeschränkungen weniger als 20% der verfügbaren Optimierungen.³ Ein typischer LLM-Trainingslauf umfasst über 300 einstellbare Parameter, die Speicherzuweisung, Kernel-Scheduling, Kommunikationsmuster und numerische Präzision beeinflussen. Jeder Parameter interagiert mit anderen auf nicht-lineare Weise: Eine Erhöhung der Batch-Größe verbessert die GPU-Auslastung, kann aber Out-of-Memory-Fehler auslösen oder die Konvergenz verschlechtern. Der Optimierungsraum wird so umfangreich, dass eine erschöpfende Suche unmöglich ist und systematische Ansätze erfordert, die Leistungsgewinne gegen Engineering-Aufwand abwägen.

Speicherbandbreiten-Engpässe begrenzen die LLM-Leistung

Moderne LLMs stoßen an Speichergrenzen, lange bevor Rechenleistungslimits erreicht werden. Die 3,35 TB/s Speicherbandbreite des H100 bedient 1.979 TFLOPS Rechenleistung und erzeugt ein Verhältnis von Rechenleistung zu Speicher von 591:1.⁴ LLM-Inferenz liest Modellgewichte wiederholt für jede Token-Generierung, wodurch die Speicherbandbreite zur bindenden Einschränkung wird. Ein 70B-Parameter-Modell bei FP16-Präzision benötigt allein 140 GB für Gewichte und verbraucht den gesamten H100-Speicher mit minimalem Platz für Aktivierungen und KV-Cache.

Speicheroptimierung beginnt mit dem Verständnis von Zugriffsmustern. Sequentielle Lesevorgänge erreichen 95% der theoretischen Bandbreite, während zufälliger Zugriff auf 15% abfällt. LLMs zeigen gemischte Muster: Gewichtslesevorgänge bleiben sequentiell, aber Attention-Mechanismen erzeugen unregelmäßigen Zugriff auf Key-Value-Caches. Die Optimierung des Speicherlayouts verbessert den Durchsatz dramatisch. Row-Major- versus Column-Major-Speicherung ändert die Speicherzugriffseffizienz um das 4-fache für bestimmte Operationen. Das Padding von Tensoren zur Ausrichtung an 128-Byte-Grenzen erhöht die Bandbreitennutzung von 72% auf 91%.⁵

Flash Attention revolutioniert die Speichereffizienz durch Verschmelzung von Operationen und Reduzierung von HBM-Zugriffen. Standard-Attention-Mechanismen schreiben Zwischenmatrizen in HBM und verbrauchen Bandbreite für temporäre Daten. Flash Attention berechnet Attention in SRAM-Kacheln und reduziert den Speicherverkehr um das 10-20-fache.⁶ Die Optimierung ermöglicht 4x längere Kontextlängen und 2,4x schnelleres Training für Modelle wie GPT-3. Die Implementierung erfordert eine sorgfältige Kachelgrößenauswahl basierend auf der GPU-Architektur: Die optimale Kachelgröße des H100 unterscheidet sich aufgrund der erhöhten SRAM-Kapazität von der des A100.

Batch-Größen-Optimierung balanciert Durchsatz und Konvergenz

Größere Batches verbessern die GPU-Auslastung, beeinflussen aber die Modellkonvergenz unvorhersehbar. Jede GPU arbeitet am effizientesten bei bestimmten Batch-Größen-Vielfachen, die durch Tensor-Core-Dimensionen bestimmt werden. H100 Tensor Cores verarbeiten FP16-Operationen in 16x16-Matrixkacheln, wodurch Batch-Größen, die durch 16 teilbar sind, optimal werden.⁷ Batch-Größe 127 erreicht nur 61% Auslastung, während Batch-Größe 128 94% erreicht. Der dramatische Unterschied resultiert daraus, dass Hardware-Scheduling perfekt mit Zweierpotenzdimensionen übereinstimmt.

Gradient Accumulation ermöglicht große effektive Batch-Größen ohne Speicherbeschränkungen. Training mit Batch-Größe 2048 könnte den Speicher überschreiten, aber das Akkumulieren von Gradienten über 32 Schritte mit Batch-Größe 64 erzielt äquivalente Ergebnisse. Die Technik erhält die mathematische Äquivalenz, während sie innerhalb der Speichergrenzen bleibt. Der Kommunikations-Overhead erhöht sich leicht, da Gradientensynchronisation weniger häufig stattfindet. Intelligente Implementierungen überlappen Gradientenberechnung mit Kommunikation und verbergen die Latenz vollständig.

Dynamische Batch-Größen passen sich an variierende Sequenzlängen im LLM-Training an. Feste Batch-Größen verschwenden Rechenleistung für Padding-Token, wenn Sequenzen in der Länge variieren. Dynamisches Batching packt Sequenzen effizient und verbessert den Durchsatz um 20-35%.⁸ Die Implementierungskomplexität steigt, da die Speicherzuweisung unvorhersehbar wird. Vorab-Allokationsstrategien mit Pooling verhindern Fragmentierung bei gleichzeitiger Aufrechterhaltung der Leistung.

Mixed-Precision-Training beschleunigt ohne Genauigkeitsverlust

Training in FP16 verdoppelt den Durchsatz im Vergleich zu FP32, während die Modellqualität durch sorgfältiges numerisches Management erhalten bleibt. Tensor Cores erreichen 312 TFLOPS in FP32, aber 989 TFLOPS in FP16 auf H100-GPUs.⁹ Der 3,2-fache Rechenvorteil kombiniert sich mit 2-fachen Speichereinsparungen und ermöglicht größere Modelle oder Batch-Größen. Automatic Mixed Precision (AMP) Frameworks handhaben das Präzisionsmanagement transparent, aber das Verständnis der Interna ermöglicht bessere Optimierung.

Loss Scaling verhindert Gradienten-Underflow im FP16-Training. Gradienten fallen oft unter den minimal darstellbaren Wert von FP16 (5,96e-8), erscheinen als Nullen und stoppen das Lernen.¹⁰ Die Multiplikation des Loss mit 2^16 verschiebt Gradienten in den darstellbaren Bereich von FP16. Dynamisches Loss Scaling passt den Multiplikator basierend auf Gradientenstatistiken an und verhindert sowohl Underflow als auch Overflow. Optimale Skalierungsfaktoren variieren je nach Modellarchitektur und Datensatz.

Master-Gewichtskopien in FP32 bewahren die Update-Präzision, während in FP16 gerechnet wird. Kleine Gradienten-Updates für große Gewichte verschwinden in FP16-Arithmetik. Das Beibehalten von Gewichten in FP32 akkumuliert Updates präzise. Der Overhead fügt 50% mehr Speicher für Gewichte hinzu, aber vernachlässigbare Rechenkosten. Fortgeschrittene Implementierungen verwenden stochastische Rundung, um angemessenes Rauschen einzufügen, was in einigen Fällen die Konvergenz verbessert.

Kernel-Fusion eliminiert Speicher-Engpässe

GPU-Kernel, die einzeln gestartet werden, erzeugen Speicherverkehr für Zwischenergebnisse. Eine einfache Layer-Normalisierung umfasst separate Kernel für Mittelwert, Varianz, Subtraktion, Division und Skalierung. Jeder Kernel liest aus HBM und schreibt in HBM, wobei 5x die notwendige Bandbreite verbraucht wird. Fusionierte Kernel berechnen gesamte Operationen in Registern und Shared Memory und berühren HBM nur für Eingabe und Ausgabe.

Benutzerdefinierte Kernel optimieren spezifische Modellarchitekturen. Standard-GEMM-Kernel handhaben allgemeine Matrixmultiplikation, verpassen aber Optimierungsmöglichkeiten in Transformer-Blöcken. Spezialisierte Kernel für Attention, Feedforward-Netzwerke und Layer-Normalisierung verbessern den Durchsatz um 30-50%.¹¹ Die Entwicklung erfordert CUDA-Expertise und architekturspezifisches Tuning. Bibliotheken wie Apex und TransformerEngine bieten optimierte Kernel für gängige Operationen.

Kompilierungs-Frameworks automatisieren die Kernel-Fusion durch Graph-Optimierung. PyTorchs torch.compile analysiert Berechnungsgraphen und generiert automatisch fusionierte Kernel.¹² XLA optimiert ähnlich TensorFlow- und JAX-Modelle. Der Kompilierungs-Overhead amortisiert sich über lange Trainingsläufe. Die initiale Kompilierung dauert Minuten, aber nachfolgende Iterationen laufen 20-40% schneller. Profilgesteuerte Optimierung verbessert die Leistung weiter durch Spezialisierung auf beobachtete Eingabeformen.

Kommunikationsoptimierung für verteiltes Training

Multi-GPU-Training erfordert sorgfältige Optimierung von Kommunikationsmustern. NCCL (NVIDIA Collective Communications Library) bietet optimierte Primitive, erfordert aber eine ordnungsgemäße Konfiguration. Ring-Allreduce erreicht theoretisch bandbreitenoptimale Kommunikation, aber reale Implementierungen leiden unter Synchronisations-Overhead. Baum-Algorithmen reduzieren die Latenz für kleine Nachrichten, während Ring-Algorithmen den Durchsatz für große Transfers maximieren.

Netzwerktopologie-Bewusstsein verbessert die Kommunikationseffizienz dramatisch. GPUs, die über NVLink verbunden sind, erreichen 900 GB/s bidirektionale Bandbreite, während PCIe auf 64 GB/s begrenzt ist.¹³ Platzierungsstrategien, die häufig kommunizierende GPUs auf NVLink-verbundenen Knoten zusammenlegen, reduzieren die Kommunikationszeit um das 5-fache. Hierarchisches Allreduce führt lokale Reduktion über NVLink durch, bevor die Inter-Knoten-Kommunikation über InfiniBand erfolgt.

Gradientenkompression reduziert das Kommunikationsvolumen bei minimalem Genauigkeitsverlust. Die Übertragung nur der Top-k-Gradienten oder die Quantisierung auf INT8 reduziert den Verkehr um das 100-1000-fache.¹⁴ Error-Feedback-Mechanismen akkumulieren abgeschnittene Gradienten für zukünftige Iterationen. Kompressionsraten hängen von der Modell-Sparsity und der Gradientenverteilung ab. Adaptive Schemata passen die Kompression basierend auf der Trainingsphase an und verwenden weniger Kompression während kritischer Konvergenzperioden.

Introls Performance-Engineering-Teams haben über 10.000 GPU-Deployments in unserem globalen Abdeckungsgebiet optimiert und erreichen konstant 85-95% der theoretischen Leistung für LLM-Workloads.¹⁵ Unsere Optimierungs-Playbooks reduzieren die Time-to-Deployment um 40% und gewährleisten maximale Hardware-Auslastung vom ersten Tag an.

Inferenz-spezifische Optimierungen

Inferenz-Optimierung unterscheidet sich grundlegend von Training-Optimierung. Latenz ist wichtiger als Durchsatz für nutzerorientierte Anwendungen. Speicherbandbreite wird zum Engpass statt Rechenleistung. Serving-Kosten dominieren die Gesamtausgaben, was Effizienz entscheidend macht.

Key-Value-Cache-Management bestimmt die Inferenz-Effizienz. Jede Token-Generierung liest den gesamten KV-Cache und verbraucht Speicherbandbreite proportional zur Sequenzlänge. PagedAttention virtualisiert den KV-Cache-Speicher und reduziert Verschwendung von 60% auf unter 5%.¹⁶ Die Technik ermöglicht 4x höheren Durchsatz für lange Sequenzen. Die Implementierung erfordert sorgfältiges Memory-Pool-Management und Request-Scheduling.

Quantisierung reduziert Modellgröße und Bandbreitenanforderungen. INT8-Quantisierung halbiert die Speichernutzung bei Beibehaltung von 99% der FP16-Genauigkeit für die meisten Modelle.¹⁷ INT4 erreicht 4x Kompression bei 97% Genauigkeitserhaltung. Quantization-Aware Training produziert Modelle, die robust gegenüber reduzierter Präzision sind. Post-Training-Quantisierung funktioniert für viele Modelle, erfordert aber die Auswahl eines Kalibrierungsdatensatzes.

Continuous Batching maximiert den Inferenz-Durchsatz, indem neue Anfragen gestartet werden, sobald Kapazität verfügbar wird. Statisches Batching wartet, bis alle Anfragen abgeschlossen sind, bevor neue gestartet werden, was Ressourcen bei kurzen Sequenzen verschwendet. Continuous Batching verbessert den Durchsatz um das 2,5-fache bei Anfragen mit variabler Länge.¹⁸ Die Implementierungskomplexität steigt aufgrund von dynamischem Speichermanagement und Scheduling-Anforderungen.

Praxisergebnisse der Optimierung

Fallstudie 1: LLM-Training im Finanzdienstleistungsbereich - Modell: 70B-Parameter benutzerdefinierte Architektur - Hardware: 64x H100-GPUs - Baseline: 847 Token/Sekunde/GPU - Optimierungen: Flash Attention, Mixed Precision, Gradient Accumulation - Ergebnis: 1.923 Token/Sekunde/GPU (2,27x Verbesserung) - Trainingszeit reduziert von 18 Tagen auf 8 Tage - Kosteneinsparungen: 240.000 Dollar pro Trainingslauf

Fallstudie 2: Inferenzsystem im Gesundheitswesen - Modell: 13B-Parameter medizinischer Assistent - Hardware: 8x A100-GPUs - Baseline: 142ms Latenz pro Token, 820 Token/Sekunde Durchsatz - Optimierungen: PagedAttention, INT8-Quantisierung, Continuous Batching - Ergebnis: 47ms Latenz, 2.140 Token/Sekunde (2,6x Durchsatz) - Kosten pro Million Token: 0,73 $ → 0,28 $

Fallstudie 3: E-Commerce-Empfehlungsmaschine - Modell: 175B-Parameter MoE-Modell - Hardware: 128x H100-GPUs - Baseline: 43% MFU (Model FLOPS Utilization) - Optimierungen: Expert Parallelism, Kernel-Fusion, topologiebewusste Platzierung - Ergebnis: 71% MFU (1,65x Verbesserung) - In

[Inhalt für Übersetzung gekürzt]