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

Ein vollständiges Fine-Tuning mit Adam in gemischter Präzision braucht vor den Aktivierungen etwa 16 Byte GPU-Speicher pro Parameter, LoRA auf einer BF16-Basis etwa 2 und QLoRA weniger als 1. Für Llama 3.3 70B sind das 1.129 GB, 144,4 GB und 42,8 GB Modellzustände. Nach unserer Rechnung passt ein 8B-LoRA (16,7 GB) auf eine 32-GB-Karte, ein 70B-QLoRA auf eine Karte mit 72 oder 96 GB oder, mit etwa 5 GB Rest, auf eine 48-GB-Karte, und ein 70B-LoRA auf einer BF16-Basis braucht zwei Karten. Für jeden dieser Läufe nennen wir Ihnen die passende Karte oder legen einen auf Bestellung gebauten Server aus: Schildern Sie kurz Ihren geplanten Lauf, unser Team hilft Ihnen weiter.

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 etwa 12 GB Reserve. Hugging Face dokumentiert eine Möglichkeit, das zu verringern: 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 16 GB frei lässt, oder nach der Zählung von Hugging Face auf 96 GB, was die gesamten angegebenen 96 GB der Karte belegen würde. Die andere Möglichkeit, Sharding, behandeln wir weiter unten.

Aktivierungen und was Gradient Checkpointing eintauscht

Aktivierungen wachsen mit Batchgröße und Sequenzlänge. Im Beispiel der ZeRO-Arbeit benötigt ein GPT-2 mit 1,5 Milliarden Parametern, „trainiert mit einer Sequenzlänge von 1K und einer Batchgröße von 32“, für Aktivierungen „etwa 60 GB Speicher“, 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 Arbeit schreibt: „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. In Hugging Face Transformers müssen NF4 und doppelte Quantisierung beide ausdrücklich angefordert werden (bnb_4bit_quant_type="nf4", bnb_4bit_use_double_quant=True); ohne doppelte Quantisierung kostet ein Gewicht 4,5 Bit, und die Zustände des 70B-Modells kommen auf etwa 46,0 GB. 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 in den Compute-Datentyp dequantisiert, BF16, sobald bnb_4bit_compute_dtype darauf gesetzt ist (Standard ist FP32), 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 GPU zu welchem Fine-Tuning-Lauf passt

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. Alle Karten mit ihrer angegebenen Kapazität von 32, 48, 72, 96 und 141 GB, was die Werte auf der sicheren Seite hält: Der Treiber einer RTX PRO 6000 meldet 95,6 GiB, der einer H200 NVL 140,4 GiB.

Auf der RTX PRO 6000 laufen LoRA bis 32B, wobei mehr als ein Viertel der Karte frei bleibt, und QLoRA bis 70B mit etwa 53 GB Reserve. 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 „auf einer Consumer-GPU mit 32 GB laufen kann“; eines davon ist ein 8B-LoRA mit Batchgröße 4 und Sequenzen von 2.048 Token. Ein 70B-LoRA auf einer BF16-Basis übersteigt mit 144,4 GB selbst die 141 GB einer H200 NVL; wir würden es auf zwei Karten verteilen. Welche Karte zu welcher Methode passt, zeigt unser Leitfaden zur besten GPU für Fine-Tuning.

DGX Spark. Auf NVIDIAs Produktseite heißt es: „KI-Modelle mit bis zu 70 Milliarden Parametern feinabstimmen.“ Das zugehörige PyTorch-Playbook für Fine-Tuning zeigt, Stand September 2026, die Konfigurationen: 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 Spark sowie LoRA auf dem 70B-Modell mit FSDP unter der Überschrift „Run on two Sparks“. Unsere Rechnung stimmt damit überein. Die 144,4 GB eines 70B-LoRA übersteigen den Unified Memory eines DGX Spark mit 128 GB, den 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. DGX-Spark-Systeme mit 64 GB, seit dem 23. Oktober 2026 bei Partnern erhältlich (NVIDIA-Blog vom 21. Oktober 2026), haben halb so viel Speicher: Ein 70B-QLoRA mit 42,8 GB Modellzuständen lässt dort etwa 21 GB für Betriebssystem und Aktivierungen. Unser Artikel zum Speicher des DGX Spark enthält die Einzelheiten.

Für das 70B-LoRA-Setup aus NVIDIAs Playbook bieten wir zwei Spark-Systeme mit je 128 GB an. Nennen Sie uns Modell und Methode, die Sie planen, und wir sagen Ihnen, ob ein Spark, zwei Spark-Systeme oder ein GPU-Server dazu passt.

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 auch mehr als die 141 GB einer H200 NVL; 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.

Auf einem Server mit vier RTX PRO 6000 Server Edition bringt FSDP das vollständige Fine-Tuning von 8B auf 32,1 GB Modellzustände je Karte, das 70B-LoRA auf BF16-Basis auf 36,1 GB und, mit 8-Bit-Adam, ein vollständiges Fine-Tuning von 32B auf etwa 81,9 GB, nach unserer Rechnung. Ein vollständiges Fine-Tuning von 70B passt mit 282 GB je Karte nicht, und derselbe Server kann stattdessen vier QLoRA-Läufe bis 70B nebeneinander ausführen, einen je Karte. Wir liefern nach Auftrag gebaute KI-Server als Multi-GPU-Knoten für Fine-Tuning, mit H200 NVL und NVLink-Bridges oder RTX PRO 6000 Server Edition. Schicken Sie uns Modellgröße und Methode, mit denen Sie trainieren wollen; Konfiguration und Angebot erhalten Sie innerhalb eines Werktages.

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 in Release 2.19 (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

Wir liefern jede Karte aus den Tabellen oben (die RTX PRO 4500 als Workstation-Karte, die RTX PRO 5000 mit 48 und 72 GB, die RTX PRO 6000 in allen drei Editionen einschließlich der Server Edition und die H200 NVL) sowie die DGX Spark Founders Edition mit 128 GB EU-weit mit Herstellergarantie, unter einem EU-Vertrag und auf einer Rechnung. Die Karten liefern wir für sich oder eingebaut in Workstations und nach Auftrag gebauten Servern für Training auf einer oder mehreren GPUs. Wenn Sie auch die Plattform dazu wünschen, gehört MLOps auf Kubernetes (KServe, Kubeflow) zu unserem Service Private AI/ML, den unser Engineering-Partner Vixen.UNO unter demselben Vertrag umsetzt.

FAQ