Wie viel GPU-Speicher Fine-Tuning braucht: vollständiges Fine-Tuning, LoRA und QLoRA für Modelle mit 8B, 32B und 70B

Was beim Training den Speicher füllt

Beim Serving braucht ein Modell Speicher für die Gewichte und den KV-Cache, wie unser VRAM-Leitfaden darlegt. Beim Training kommt mehr hinzu. Die Dokumentation von Hugging Face nennt die Gewichte, einen Gradienten für jedes Gewicht, die Optimiererzustände, die Vorwärtsaktivierungen, die „im Vorwärtsdurchlauf berechnet und für den Rückwärtsdurchlauf zwischengespeichert werden“, und temporäre Tensoren. Gewichte, Gradienten und Optimiererzustände sind die Modellzustände: Sie hängen nur von der Parameterzahl und der Methode ab und lassen sich daher im Voraus berechnen. Aktivierungen hängen vom Batch ab.

Die Standardrechnung steht in der ZeRO-Arbeit (arXiv 1910.02054). Training in gemischter Präzision mit Adam, heißt es dort, „benötigt genug Speicher, um eine fp16-Kopie der Parameter und der Gradienten vorzuhalten, mit einem Speicherbedarf von 2Ψ bzw. 2Ψ Byte. Zusätzlich muss es die Optimiererzustände vorhalten: eine fp32-Kopie der Parameter, Momentum und Varianz, mit einem Speicherbedarf von 4Ψ, 4Ψ bzw. 4Ψ Byte.“ Das sind 2 + 2 + 12 Byte, in den Worten der Arbeit „2Ψ + 2Ψ + KΨ = 16Ψ Byte Speicherbedarf“, wobei Ψ die Zahl der Parameter ist. Auch BF16 belegt 2 Byte, die Zählung gilt also ebenso für BF16.

Vollständiges Fine-Tuning: 16 Byte pro Parameter

Ein vollständiges Fine-Tuning trainiert jedes Gewicht, also fallen für jedes Gewicht die vollen 16 Byte an. Mit den Parameterzahlen, die Hugging Face für die drei Checkpoints angibt, 8,03, 32,76 und 70,55 Milliarden, sind das nach unserer Rechnung 128, 524 und 1.129 GB Modellzustände für Llama 3.1 8B, Qwen3-32B und Llama 3.3 70B. Die Dokumentation von Hugging Face rechnet die Gradienten in FP32 und führt 6 Byte für Gewichte, 4 für Gradienten und 8 für Adam-Zustände auf, zusammen 18: 145, 590 und 1.270 GB. Unser Vergleich von Fine-Tuning und RAG nennt beide Zählungen als Spanne.

Mit 32-Bit-Adam passen nur die Zustände des 8B-Modells auf eine einzelne Karte, die wir liefern: die H200 NVL, mit 22 GB Reserve. Hugging Face dokumentiert einen Hebel: Ein quantisierter Adam aus bitsandbytes, im Trainer von Hugging Face optim="adamw_bnb_8bit", speichert die Optimiererzustände mit 2 Byte pro Parameter statt 8, was beim 8B-Modell 48 GB spart. Seine Zustände kommen dann nach der ZeRO-Zählung auf etwa 80 GB, was auf eine RTX PRO 6000 passt und etwa 22 GB frei lässt, oder nach der Zählung von Hugging Face auf 96 GB, was etwa 6 GB frei lässt. Der andere Hebel ist Sharding, dazu unten mehr.

Aktivierungen und was Gradient Checkpointing eintauscht

Aktivierungen wachsen mit Batchgröße und Sequenzlänge. Die ZeRO-Arbeit nennt die Größenordnung: Ein GPT-2 mit 1,5 Milliarden Parametern, „trainiert mit einer Sequenzlänge von 1K und einer Batchgröße von 32, benötigt etwa 60 GB Speicher“ für Aktivierungen, zweieinhalbmal so viel wie die 24 GB seiner Modellzustände.

Gradient Checkpointing, das die Arbeit Activation Checkpointing nennt, erkauft diesen Speicher mit Rechenaufwand: Es speichert nur einen Teil der Aktivierungen und berechnet den Rest während des Rückwärtsdurchlaufs neu. Nach der Schätzung der ZeRO-Arbeit senkt es die Aktivierungen dieses Beispiels von 60 GB auf etwa 8 GB, „auf Kosten von 33 Prozent Mehraufwand durch Neuberechnung“. Der Trainingsleitfaden von Hugging Face nennt „eine geringere Trainingsgeschwindigkeit (etwa 20 Prozent)“; im zugehörigen Trainer heißt der Schalter gradient_checkpointing=True. Die Modellzustände bleiben gleich.

Bei Adaptern wiegen die Aktivierungen schwerer als der Adapter selbst. Die QLoRA-Arbeit schätzte für ein 7B-Modell bei Batchgröße 1, dass „die LoRA-Eingabegradienten einen Speicherbedarf von 567 MB haben, während die LoRA-Parameter nur 26 MB belegen“, gegenüber 5.048 MB für die 4-Bit-Basis; Gradient Checkpointing senkte diese Gradienten auf etwa 18 MB pro Sequenz. Aktivierungen hängen von Batchgröße und Sequenzlänge ab, deshalb lassen unsere Tabellen sie weg: Was die Modellzustände frei lassen, ist das Budget für Batchgröße mal Sequenzlänge.

LoRA: die Basis einfrieren, einen Adapter trainieren

LoRA (arXiv 2106.09685) „friert die Gewichte des vortrainierten Modells ein und fügt in jede Schicht der Transformer-Architektur trainierbare Rangzerlegungsmatrizen ein“. Die eingefrorenen Gewichte brauchen weder Gradienten noch Optimiererzustände: „Für die meisten Parameter müssen wir weder die Gradienten berechnen noch die Optimiererzustände vorhalten.“

Ein Adapter mit Rang r auf einer Schicht mit m Eingängen und n Ausgängen fügt r × (m + n) Parameter hinzu. Die PEFT-Bibliothek von Hugging Face setzt mit target_modules="all-linear" Adapter auf jede lineare Schicht außer der Ausgabeschicht, und die QLoRA-Arbeit stellte fest, dass „LoRA auf allen linearen Schichten der Transformer-Blöcke nötig ist, um die Leistung eines vollständigen Fine-Tunings zu erreichen“. Bei Rang 16, einem Beispielwert, ergibt unsere Rechnung aus den Schichtdimensionen des jeweiligen Modells 41,9 Millionen trainierbare Parameter für Llama 3.1 8B, 134,2 Millionen für Qwen3-32B und 207,1 Millionen für Llama 3.3 70B: 0,52, 0,41 und 0,29 Prozent der Gewichte. Mit 16 Byte pro Parameter brauchen sie 0,7, 2,1 und 3,3 GB; die eingefrorene BF16-Basis mit 2 Byte pro Parameter macht fast den gesamten Bedarf aus: 16, 66 und 141 GB. Bei Rang 64, der Einstellung, die die QLoRA-Arbeit für ihre Guanaco-Modelle verwendete, vervierfachen sich die Adapterwerte.

QLoRA: eine 4-Bit-Basis

QLoRA (arXiv 2305.14314) behält die Adapter bei und speichert die eingefrorene Basis in 4 Bit. Die Aussage der Arbeit: „Wir stellen QLoRA vor, einen effizienten Fine-Tuning-Ansatz, der den Speicherbedarf so weit senkt, dass sich ein Modell mit 65B Parametern auf einer einzigen GPU mit 48 GB feinabstimmen lässt, bei voller Aufgabenleistung eines 16-Bit-Fine-Tunings.“ Drei Mechanismen sorgen dafür. 4-Bit-NormalFloat (NF4) ist ein Datentyp, der für normalverteilte Gewichte ausgelegt ist. Doppelte Quantisierung speichert die Quantisierungskonstanten in 8 Bit und senkt sie „von 32/64 = 0,5 Bit auf 8/64 + 32/(64 · 256) = 0,127 Bit“ pro Parameter, sodass ein quantisiertes Gewicht etwa 4,13 Bit oder 0,516 Byte kostet. Paged Optimizers nutzen NVIDIAs Unified Memory, um Optimiererzustände in den CPU-Speicher zu verschieben, wenn der GPU der Speicher ausgeht, und sie für den Update-Schritt zurückzuholen; die Arbeit nennt sie „entscheidend, um QLoRA-Tuning von 33B/65B auf einer einzigen GPU mit 24/48 GB durchzuführen“.

Quantisiert werden nur lineare Schichten, und für kausale Sprachmodelle merkt Hugging Face an, dass „der letzte lm_head in seinem ursprünglichen dtype belassen wird“; auch das Eingabe-Embedding ist keine lineare Schicht, sodass in diesen drei Modellen 1,05, 1,56 und 2,10 Milliarden Parameter in BF16 bleiben. Die 4-Bit-Gewichte werden für jede Matrixmultiplikation nach BF16 dequantisiert, und Gradienten fließen durch sie hindurch, werden aber nur für die Adapter gespeichert. Der bitsandbytes-Leitfaden von Hugging Face stellt ausdrücklich fest, dass „8- und 4-Bit-Training nur für das Training zusätzlicher Parameter unterstützt wird“: Ein 4-Bit-Modell ist kein Weg zu einem vollständigen Fine-Tuning.

Nur Modellzustände, keine Aktivierungen. Unsere Rechnung, GB = 10⁹ Byte: 16 Byte pro Parameter für vollständiges Fine-Tuning (ZeRO-Arbeit); eine eingefrorene Basis mit 2 Byte (BF16) oder, bei QLoRA, lineare Schichten mit 0,516 Byte (NF4 mit doppelter Quantisierung, QLoRA-Arbeit), wobei Embeddings, Ausgabeschicht und Normalisierungsschichten 2 Byte belegen; dazu ein Adapter mit Rang 16 auf allen linearen Schichten mit 16 Byte pro trainierbarem Parameter. Parameterzahlen von Hugging Face. Der tatsächliche Bedarf liegt höher: Für ihre 4-Bit-Basis mit 7B nennt die QLoRA-Arbeit 5.048 MB, wo diese Rechnung etwa 3,9 GB ergibt.

Welche Karte für welchen Lauf reicht

Was jeder Karte nach den Modellzuständen bleibt, ist das Budget für Aktivierungen, den CUDA-Kontext und temporäre Puffer.

Speicher, der nach den Modellzuständen aus der Tabelle oben frei bleibt, nach unserer Rechnung. RTX PRO 6000 und H200 NVL mit den 95,6 und 140,4 GiB, die der Treiber anzeigt, also 102,6 und 150,8 GB; RTX PRO 4500 und 5000 mit ihrer Nennkapazität.

Auf der RTX PRO 6000 laufen LoRA bis 32B, wobei ein Drittel der Karte frei bleibt, und QLoRA bis 70B. Die RTX PRO 5000 mit 72 GB fasst ein 70B-QLoRA mit reichlich Reserve, ein 32B-LoRA auf einer BF16-Basis lässt ihr aber nur 4 GB. Die 48-GB-Karte lässt neben einem 70B-QLoRA etwa 5 GB frei, noch vor CUDA-Kontext und Aktivierungen; das 65B-Modell der QLoRA-Arbeit selbst brauchte auf 48 GB Paged Optimizers. Auf der RTX PRO 4500 mit 32 GB rückt mit QLoRA das 32B-Modell in Reichweite, mit 11 GB Reserve, und ein 8B-LoRA lässt 15 GB frei, wobei die Batchgröße entscheidet: NVIDIA erklärt, dass keines seiner Fine-Tuning-Beispiele für DGX Spark, darunter ein 8B-LoRA mit Batchgröße 4 und Sequenzen von 2.048 Token, „auf einer Consumer-GPU mit 32 GB laufen kann“. Ein 70B-LoRA auf einer BF16-Basis lässt selbst auf der H200 NVL etwa 6 GB frei; wir würden es auf zwei Karten verteilen.

DGX Spark. NVIDIAs Produktseite verspricht: „KI-Modelle mit bis zu 70 Milliarden Parametern feinabstimmen.“ Das zugehörige PyTorch-Playbook für Fine-Tuning zeigt, Stand September 2026, wie: ein vollständiges Fine-Tuning von Llama 3.2 3B, LoRA auf Llama 3.1 8B und QLoRA auf Llama 3.1 70B auf einem Gerät sowie LoRA auf dem 70B-Modell mit FSDP unter der Überschrift „Run on two Sparks“. Die Rechnung bestätigt das: Die 144,4 GB eines 70B-LoRA übersteigen die 128 GB Unified Memory des Geräts, die auch das Betriebssystem nutzt, und allein die Modellzustände eines vollständigen Fine-Tunings von 8B mit 32-Bit-Adam belegen etwa den gesamten Speicher. Unser Artikel zum Speicher des DGX Spark enthält die Einzelheiten.

Mehr als eine Karte: FSDP und ZeRO-3

Passen die Zustände nicht auf eine Karte, verteilen Sie sie per Sharding. FSDP von PyTorch „verringert den GPU-Speicherbedarf durch Sharding von Modellparametern, Gradienten und Optimiererzuständen“; ZeRO von DeepSpeed partitioniert in Stufe 1 die Optimiererzustände, in Stufe 2 zusätzlich die Gradienten und in Stufe 3 die 16-Bit-Parameter, wo, in den Worten der ZeRO-Arbeit, „die Speicherreduktion linear mit dem DP-Grad verläuft“. Nach unserer Rechnung braucht das vollständige Fine-Tuning von 8B dann auf zwei Karten 64,2 GB Modellzustände pro Karte, das von 32B auf acht Karten 65,5 GB pro Karte und das 70B-LoRA auf einer BF16-Basis auf zwei Karten 72,2 GB pro Karte, jeweils zuzüglich der Aktivierungen und der gerade zusammengeführten Parameter. Ein vollständiges Fine-Tuning von 70B braucht auch verteilt auf acht Karten noch 141 GB pro Karte, mehr als eine RTX PRO 6000 bietet, und lässt auf einer H200 NVL weniger als 10 GB frei; es verlangt also mehr Karten oder Offloading: ZeRO-Offload verlagert Optimierer- und Gradientenzustände in den CPU-Speicher, ZeRO-Infinity zusätzlich auf NVMe.

Sharding kostet Datenverkehr. FSDP führt die verteilten Parameter vor dem Vorwärts- und vor dem Rückwärtsdurchlauf per All-Gather zusammen, und für ein vollständiges Fine-Tuning setzt die ZeRO-Arbeit den gesamten Verkehr mit dem 1,5-Fachen des Verkehrs bei reinem Datenparallelismus an. Ob dieser Verkehr über NVLink oder PCIe läuft, ist Thema unseres Vergleichs von H200 NVL und RTX PRO 6000.

FP8 und die GPU-Generation

NVIDIAs Transformer Engine, mit der FP8-Training läuft, nennt in ihrer README vom September 2026 „Unterstützung für FP8 auf NVIDIA-GPUs der Generationen Hopper, Ada und Blackwell“ und stellt fest, dass „FP8-Funktionen Compute Capability 8.9+ erfordern“, was jede Karte hier abdeckt: die H200 NVL mit 9.0, die RTX-PRO-Blackwell-Karten mit 12.0 und DGX Spark mit 12.1. MXFP8 und NVFP4 sind nur für Blackwell aufgeführt, doch die eigene Support-Prüfung der Transformer Engine lehnt MXFP8, Stand September 2026, auf Compute Capability 12.0 und höher ab, „not supported on 12.0+ architectures yet“: Die RTX-PRO-Blackwell-Karten und DGX Spark bekommen NVFP4, nicht MXFP8. NVIDIAs Einführung in FP8 stellt FP8 als Weg zu „höherem Durchsatz bei Matrixmultiplikationen“ dar; unsere Tabellen rechnen keine Ersparnis durch FP8 ein.

Was wir liefern

Eurokommerz liefert DGX Spark sowie die RTX PRO 6000, RTX PRO 5000, RTX PRO 4500 und H200 NVL EU-weit mit Herstellergarantie, die Karten einzeln oder in Workstations und Servern, die für Training auf einer oder mehreren GPUs konfiguriert sind. Unser GPU-Sortiment ist der Ausgangspunkt; schicken Sie uns das Modell und die Methode, und wir stimmen die Karte auf den Lauf ab.

FAQ