GPU-Speicher
Jedes KI-Modell braucht Platz: für seine gelernten Muster, für Zwischenergebnisse und für die Daten, die gerade verarbeitet werden. Dieser Platz liegt auf der Grafikkarte selbst. Je größer der Speicher dort, desto größere Modelle lassen sich laden und desto mehr Daten können gleichzeitig durchlaufen. In der Fachsprache heißt dieser Speicher VRAM.
Aufbau und Funktion des GPU-Speichers
Eine Grafikkarte besitzt eigenen Arbeitsspeicher, der physisch auf der Platine sitzt. Dieser VRAM (Video Random Access Memory) ist über einen breiten Datenbus direkt mit den Rechenkernen der GPU verbunden. Die Anbindung ist deutlich schneller als der Weg zwischen CPU und System-RAM, weil der Bus mehr Daten pro Takt transportiert.
Beispiel: Eine NVIDIA A100 mit HBM2e-Speicher erreicht eine Speicherbandbreite von rund 2 TB/s. Zum Vergleich: DDR5-Arbeitsspeicher im Desktop kommt auf etwa 50 bis 60 GB/s. Der Faktor liegt bei über 30.
Moderne KI-Karten verwenden gestapelte Speicherchips (HBM, High Bandwidth Memory). Bei HBM liegen mehrere Speicherschichten übereinander und sind über Tausende winziger Verbindungen (Through-Silicon Vias) angebunden. Das erhöht die Bandbreite, ohne die Taktrate steigern zu müssen.
Beispiel: Die NVIDIA H100 verwendet HBM3 mit 80 GB Kapazität und 3,35 TB/s Bandbreite. Die Vorgängerin A100 bot 80 GB bei 2 TB/s. Der Speicher blieb gleich groß, aber die Bandbreite stieg um über 60 Prozent.
Fachliche Einordnung: Die Bandbreite des GPU-Speichers ist in vielen KI-Workloads der eigentliche Flaschenhals. Selbst wenn die Rechenkerne schneller werden, begrenzt die Speicheranbindung, wie viele Daten pro Sekunde tatsächlich verarbeitet werden. In der Literatur wird das als "memory-bound" bezeichnet.
Wofür der Speicher beim Trainieren verbraucht wird
Beim Trainieren eines neuronalen Netzes belegen vier Komponenten den GPU-Speicher:
Modellgewichte: Die gelernten Parameter des Modells. Ein Modell mit 7 Milliarden Parametern belegt in FP16 (16 Bit pro Wert) rund 14 GB. In INT8 halbiert sich das auf 7 GB.
Beispiel: Llama 2 mit 70 Milliarden Parametern benötigt in FP16 etwa 140 GB allein für die Gewichte. Das übersteigt den Speicher einer einzelnen H100 (80 GB). Daher verteilt man das Modell auf mindestens zwei Karten.
Optimizer-States: Der Adam-Optimizer speichert pro Parameter zwei zusätzliche Werte (Momentum und Varianz). Bei FP32 verdreifacht das den Speicherbedarf gegenüber den reinen Gewichten.
Gradienten: Während der Backpropagation berechnet das System für jeden Parameter einen Gradienten. Das entspricht nochmals der Größe der Gewichte.
Aktivierungen: Zwischenergebnisse jeder Schicht, die für die Rückwärtsberechnung aufbewahrt werden. Ihre Größe wächst mit der Batch-Size und der Sequenzlänge.
Beispiel: Für ein 7B-Modell in FP16 ergibt sich überschlagen: 14 GB Gewichte + 28 GB Optimizer (FP32) + 14 GB Gradienten + variable Aktivierungen. Allein die festen Bestandteile summieren sich auf über 56 GB.
Speicherverbrauch bei der Inferenz
Bei der Inferenz (dem Einsatz eines fertig trainierten Modells) fällt ein Großteil des Trainings-Overheads weg. Es gibt keine Optimizer-States, keine Gradienten und keine gespeicherten Aktivierungen für die Rückwärtsberechnung. Der Speicher wird hauptsächlich von den Modellgewichten und dem KV-Cache beansprucht.
Beispiel: Ein 7B-Modell in FP16 belegt bei der Inferenz etwa 14 GB für die Gewichte. Quantisiert auf INT4 sinkt das auf rund 3,5 GB. Damit läuft es auf einer Consumer-Karte mit 8 GB VRAM.
Der KV-Cache speichert bereits berechnete Schlüssel- und Wert-Vektoren der Attention-Schichten. Bei autoregressiver Textgenerierung wächst dieser Cache mit jedem erzeugten Token. Bei langen Kontextfenstern (32.000 Tokens und mehr) kann der KV-Cache mehrere Gigabyte erreichen.
Beispiel: Bei einem 70B-Modell mit 80 Schichten, 64 Attention-Heads und einer Kontextlänge von 4.096 Tokens belegt der KV-Cache in FP16 etwa 5 GB. Verdoppelt sich die Kontextlänge, verdoppelt sich auch der Cache.
Fachliche Einordnung: Die Skalierung des KV-Cache mit der Sequenzlänge ist einer der Gründe, warum Verfahren wie Grouped-Query Attention (GQA) und Multi-Query Attention (MQA) entwickelt wurden. Sie reduzieren die Anzahl gespeicherter Key-Value-Paare und senken den Speicherbedarf bei langen Kontexten erheblich.
Typische Engpässe und ihre Ursachen
Ein voller GPU-Speicher führt zum Abbruch des Prozesses (Out of Memory, OOM). Die häufigsten Ursachen:
Batch-Size zu groß: Jede Erhöhung der Batch-Size vergrößert die Aktivierungen proportional. Eine Verdopplung der Batch-Size verdoppelt den Aktivierungsspeicher.
Beispiel: Ein Transformer-Modell mit Batch-Size 16 läuft stabil auf einer 24-GB-Karte. Mit Batch-Size 32 bricht das Training mit OOM ab, weil die Aktivierungen den verbleibenden Speicher übersteigen.
Sequenzlänge: Der Speicherbedarf der Attention-Berechnung wächst quadratisch mit der Sequenzlänge (bei Standard-Attention). Eine Verdopplung der Sequenz vervierfacht den Attention-Speicher.
Beispiel: Ein Modell verarbeitet Sequenzen mit 2.048 Tokens problemlos. Bei 8.192 Tokens steigt der Attention-Speicher um den Faktor 16. Flash Attention reduziert dieses Problem, indem es die Berechnung blockweise durchführt und nur Teilergebnisse im Speicher hält.
Speicherfragmentierung: Wiederholtes Allokieren und Freigeben unterschiedlich großer Tensoren kann den Speicher fragmentieren. Formal ist noch Platz vorhanden, aber kein zusammenhängender Block reicht für die nächste Allokation.
Beispiel: Ein Trainingslauf zeigt 4 GB freien VRAM an, aber eine 2-GB-Allokation schlägt fehl. Der Grund: Die 4 GB verteilen sich auf viele kleine Lücken. Frameworks wie PyTorch verwenden einen Caching-Allocator, der dieses Problem abmildert, aber nicht vollständig beseitigt.
Strategien zur Speicheroptimierung
Wenn der Speicher nicht reicht, gibt es erprobte Gegenmaßnahmen mit unterschiedlichen Abwägungen:
Quantisierung: Reduziert die Bitbreite der Gewichte. FP16 halbiert den Bedarf gegenüber FP32. INT8 halbiert nochmals. INT4 bringt den Bedarf auf ein Viertel des FP16-Werts. Die Modellqualität sinkt dabei leicht, bei guter Kalibrierung bleibt die Genauigkeit auf Benchmarks häufig innerhalb von 1 bis 2 Prozentpunkten.
Beispiel: Ein 13B-Modell in FP16 belegt 26 GB VRAM. In INT4 (GPTQ-quantisiert) sinkt das auf etwa 6,5 GB. Es läuft damit auf einer Karte mit 8 GB, bei messbarem, aber in vielen Anwendungsfällen akzeptablem Qualitätsverlust.
Gradient Checkpointing: Statt alle Aktivierungen zu speichern, werden nur bestimmte Checkpoint-Schichten aufbewahrt. Die restlichen Aktivierungen werden in der Rückwärtsberechnung erneut berechnet. Das spart Speicher, kostet aber zusätzliche Rechenzeit (typisch: 20 bis 30 Prozent länger).
Beispiel: Ohne Gradient Checkpointing belegt ein Trainingslauf 72 GB VRAM. Mit Checkpointing sinkt der Bedarf auf 45 GB, das Training dauert aber 25 Prozent länger. Das ermöglicht, auf einer einzelnen 80-GB-Karte zu trainieren statt auf zwei Karten.
Mixed Precision Training: Gewichte und Aktivierungen werden in FP16 berechnet, nur die Gewichts-Updates erfolgen in FP32. Das halbiert den Speicherbedarf für Aktivierungen und beschleunigt die Berechnung auf Tensor Cores.
Offloading: Teile des Modells oder der Optimizer-States werden in den System-RAM oder auf die SSD ausgelagert. Das erweitert den verfügbaren Speicher, aber die langsamere Anbindung erhöht die Trainingszeit deutlich.
Beispiel: DeepSpeed ZeRO-Offload lagert Optimizer-States in den System-RAM aus. Bei einem 13B-Modell reduziert das den VRAM-Bedarf von 52 GB auf etwa 20 GB, allerdings bei 30 bis 40 Prozent längerem Training.
Praxiswerte: Welche Karte für welches Modell
Die folgende Übersicht zeigt gängige Konstellationen. Die Angaben sind Richtwerte. Der tatsächliche Bedarf hängt von Framework, Batch-Size, Sequenzlänge und Optimierungen ab.
8 GB VRAM (RTX 4060, RTX 3070): Inferenz von 7B-Modellen in INT4. Fine-Tuning mit LoRA bei sehr kleiner Batch-Size möglich.
Beispiel: Llama 2 7B in 4-Bit-Quantisierung läuft mit llama.cpp auf einer RTX 4060 mit 8 GB. Die Generierungsgeschwindigkeit liegt bei etwa 15 bis 25 Tokens pro Sekunde, abhängig von der Kontextlänge.
24 GB VRAM (RTX 4090, RTX 3090): Inferenz von 13B-Modellen in FP16 oder 70B in INT4. Fine-Tuning von 7B-Modellen mit LoRA in FP16 bei moderater Batch-Size.
Beispiel: Ein 13B-Modell in FP16 belegt 26 GB. Das übersteigt die 24 GB knapp. In INT8 (13 GB) läuft die Inferenz komfortabel mit Platz für den KV-Cache.
48 GB VRAM (NVIDIA A6000, dual RTX 3090): Training von 7B-Modellen in FP16 mit moderater Batch-Size. Inferenz von 70B-Modellen in INT4.
80 GB VRAM (A100, H100): Training von 13B-Modellen in FP16. Inferenz von 70B-Modellen in FP16. Training größerer Modelle erfordert mehrere Karten.
Beispiel: Auf einem Cluster mit 8× H100 (640 GB VRAM gesamt) lässt sich ein 70B-Modell in FP16 vollständig trainieren. Die Karten sind über NVLink verbunden, sodass die Kommunikation zwischen den GPUs die Bandbreite des lokalen Speichers annähernd erreicht.
Grenzen und offene Herausforderungen
Trotz wachsender Speicherkapazitäten bleibt GPU-Speicher ein limitierender Faktor. Die Modellgrößen wachsen schneller als die verfügbare VRAM-Kapazität. GPT-4 wird auf über eine Billion Parameter geschätzt. Selbst auf einem 8×-H100-System wäre das Modell in FP16 nicht vollständig ladbar.
Beispiel: Ein hypothetisches 1T-Modell in FP16 benötigt rund 2 TB allein für die Gewichte. Das erfordert mindestens 25 H100-Karten nur für die Gewichte, ohne Optimizer oder Aktivierungen.
Die Kosten sind ein weiterer Faktor. Eine H100 mit 80 GB kostet im Cloud-Betrieb etwa 2 bis 4 USD pro Stunde. Für Trainingscluster mit Hunderten von Karten summieren sich die Kosten schnell auf Millionenbeträge.
Technologisch zeichnen sich Änderungen ab: HBM4 verspricht höhere Bandbreite und Kapazität. Neue Architekturen wie Mixture-of-Experts (MoE) reduzieren den aktiven Speicherbedarf, weil pro Eingabe nur ein Teil der Parameter berechnet wird. Und Verfahren wie PagedAttention aus vLLM optimieren die KV-Cache-Verwaltung, indem sie den Speicher in festen Blöcken verwalten und Fragmentierung reduzieren.
Fachliche Einordnung: Die Frage, ob Speicher oder Rechenleistung der dominante Engpass ist, hängt vom Workload ab. Beim Training großer Modelle ist der Speicher häufig der begrenzende Faktor ("memory-bound"). Bei der Inferenz kleiner Modelle mit großen Batches kann hingegen die Rechenleistung zum Flaschenhals werden ("compute-bound"). Die Grenze verschiebt sich mit jeder neuen Hardware-Generation.