LoRA- und QLoRA-Finetuning: die echte Speicher-Mathematik

„Finetune eines 32B-Modells auf einer GPU“-Threads nutzen die Inference-Zahl und ziehen stillschweigend nichts davon ab. Realität: Training hält Gradienten und Optimizer-Status für jeden trainierbaren Parameter vor, und unter gemischter Präzision mit AdamW beträgt dieses Budget 16 Bytes pro Parameter — das Achtfache der 2 Bytes, die ein bf16-Gewicht bei der Inference kostet. Dieser Leitfaden leitet dieses Budget Term für Term her und geht dann die beiden Standard-Fluchtwege (LoRAs Rank-Zerlegung, QLoRAs 4-Bit-Basis) mit durchgerechneten Zahlen für ein reales Modell durch: Qwen3-32B, 32.762.123.264 Parameter (Anzahl verifiziert gegen die Hugging-Face-Safetensors-Metadaten von Qwen/Qwen3-32B; Konfiguration: 64 Schichten, Hidden Size 5.120, 64 Attention-Heads / 8 KV-Heads, Head-Dim 128, FFN 25.600, ungeteilte 151.936-Token-Embeddings) ¹. Bei der Inference braucht dieses Modell allein für die bf16-Gewichte 65,5 GB. Der Leitfaden verzahnt sich mit unserem VRAM-Rechner-Leitfaden und dem Quantisierungs-Leitfaden; das Pendant auf der Serving-Seite ist der KV-Cache-Leitfaden.

Warum Training nicht Inference ist

Die Buchhaltung stammt aus dem ZeRO-Paper (arXiv:1910.02054, Abschn. 3.1) ² — Gemischtes-Präzisions-Training hält eine 2-Byte-fp16/bf16-Parameterkopie und eine 2-Byte-Gradientenkopie, während der Optimizer eine fp32-Kopie der Parameter plus fp32-Momentum und -Varianz vorhält — 4+4+4 Bytes —, insgesamt 2Ψ + 2Ψ + 12Ψ = 16Ψ Bytes für ein Modell mit Ψ Parametern. Diese 14 von 16 Bytes entfallen auf trainierbare Parameter: PyTorches Mixed-Precision-Rezept und die DeepSpeed-Dokumentation halten Gradienten und fp32-Master-/Optimizer-Status ausschließlich für Parameter mit requires_grad=True vor.

Qwen3-32B, volles Finetuning, AdamW gemischt. Modell-Status = 32.762.123.264 × 16 B = 524,2 GB (488,2 GiB) — vor Aktivierungen, Embedding-Gradienten-Buffern oder dem CUDA-Kontext. Dasselbe Modell servt in 65,5 GB. Dieser 8×-Faktor ist die gesamte Geschichte dieses Leitfadens. (ZeRO/FSDP-Sharding und Offloading können die 524 GB über GPUs und Host-RAM verteilen — die Bytes verschwinden nicht, sie wandern.)

LoRA: die 99 % einfrieren, ein niedrigrangiges Delta trainieren

LoRA (arXiv:2106.09685) friert die vortrainierten Gewichte ein und lernt eine Aktualisierung als Produkt zweier kleiner Matrizen — für jede adaptierte Gewichtsmatrix $W$ berechnet der Forward-Pass $W x + \frac{\alpha}{r} B A x$, mit $A \in \mathbb{R}^{r \times d_{\text{in}}}$, $B \in \mathbb{R}^{d_{\text{out}} \times r}$, $B$ mit Null initialisiert. Das trainierbare Delta $\Delta W = BA$ hat exakt:

Parameter pro adaptierter Matrix — Rank 8 fügt einem einzelnen Qwen3-q_proj $8 \cdot (5.120 + 8.192) = 106.496$ Parameter hinzu, gegenüber 41.943.040 eingefrorenen (0,25 %). Auf alle sieben linearen Matrizen pro Schicht angewendet (q, k, v, o, gate, up, down) trägt eine Qwen3-32B-Schicht $r \times 131.072$ Adapter-Parameter:

Voller Finetuning-Modellzustand zur Referenz: 524,2 GB (16 B × 32,76 Mrd. Parameter). Die 16-B/Parameter-Spalte umfasst die bf16-Adaptergewichte selbst, Gradienten sowie fp32 m/v/Master. Sie gilt nur für die trainierbaren 0,2–1,6 %. Andere Optimizer-Implementierungen können die Masterkopie weglassen oder andere Zustandsformate nutzen.

Warum die Zahl sinkt: Gradienten und Adam-Zustände existieren nur für trainierbare Parameter. Die eingefrorene Basis trägt ihre Forward-Gewichte bei; nur die Adapter brauchen Trainingszustand. Das LoRA-Paper berichtet für seine GPT-3-175B-Konfiguration eine dreifache GPU-Speicherreduktion ³. Das ist kein universeller Faktor.

Zwei Einschränkungen. Erstens bleibt die eingefrorene Basis die untere Speichergrenze: LoRA mit r=16 benötigt weiterhin 65,5 GB bf16-Gewichte für Qwen3-32B. Eine 70B-bf16-Basis allein benötigt ungefähr 140 GB und passt nicht auf eine einzelne A100/H100 mit 80 GB. Zweitens setzt das 16-B/Parameter-Budget fp32-Mastergewichte und Adam-Zustände voraus; für 8-Bit-Optimizer ist eine eigene Messung nötig.

QLoRA: 4-Bit-Basis, dieselbe Optimizer-Mathematik

QLoRA (arXiv:2305.14314) entfernt LoRAs Boden — die 2 B/Parameter der eingefrorenen Basis — indem die eingefrorenen Gewichte in 4-Bit NormalFloat (NF4) mit blockweisen Skalen gespeichert werden. Die Bilanz des Papers, Blockgröße 64:

Ohne Double Quantization kosten die blockweisen Skalen 32/64 = 0,5 Bit/Parameter — für ein 65B-Modell sind das ~0,4 GB fp32-Konstanten pro gespeichertem Gewichts-Bit. Double Quantization (die Konstanten erster Stufe selbst mit Blockgröße 256 zu FP8 quantisieren) reduziert das auf 8/64 + 32/16.384 = 0,127 Bit/Parameter — „a reduction of 0.373 bits per parameter" laut der exakten Zahl des Papers, rund 3 GB Ersparnis bei einem 65B-Modell. Paged Optimizer, QLoRAs dritte Komponente, verkleinern den stationären Speicher nicht: Sie nutzen NVIDIA Unified Memory, um Optimizer-Status während der transienten Speicherspitze auf die CPU auszulagern, die Checkpointing bei langen Sequenzen verursacht.

Qwen3-32B in QLoRA (NF4 + DQ, LoRA r=16 all-linear, Batch 4 × 2.048 Tokens, Checkpointing an):

• Basisgewichte: 32.762.123.264 × 4,127 Bit / 8 = 16,9 GB (statt 65,5 GB bf16 — ein 3,9-facher Schnitt bei der eingefrorenen Basis)
• Trainierbarer Adapterzustand: 134.217.728 × 16 B = 2,15 GB (QLoRA quantisiert nur den eingefrorenen Teil)
• Basis plus Adapterzustand: ≈ 19,0 GB, vor Aktivierungen, Dequantisierungs-Buffern, CUDA-Workspace und Allocator-Overhead. Eine 24-GB-Karte ist für den genannten Batch damit nicht als passend belegt; der Trainings-Peak muss gemessen werden.

Paged 8-Bit-AdamW kann den Optimizer-Anteil reduzieren. Der genaue Speicherbedarf hängt von Implementierung, Anzahl und Größe der adaptierten Tensoren ab.

Aktivierungsspeicher und der Checkpointing-Handel

Der Modellzustand ist die Untergrenze; Aktivierungen skalieren mit Tokens. Korthikanti et al. leiten für die von ihnen untersuchte Transformer-Implementierung ungefähr s·b·h·(34 + 5a·s/h) Bytes pro Schicht her ⁴. Fused Attention kann die Speicherung der quadratischen Attention-Matrix vermeiden. Die übrigen 34·s·b·h sind aber eine architekturabhängige Illustration, keine exakte Qwen3-Belegung. Beim Gradient-Checkpointing werden Regionseingaben gespeichert und Zwischenergebnisse im Backward neu berechnet ⁵. Die gespeicherten Grenzen sind nicht der Peak: temporäre Aktivierungen der neu berechneten Region, Gradienten und Workspaces bleiben zusätzlich im Speicher.

Bei 64 Schichten, Hidden Size 5.120 und Batch 4 × 2.048 kosten bereits die gespeicherten bf16-Schichtgrenzen 64 × 8.192 × 5.120 × 2 ≈ 5,37 GB, noch vor dem Backward-Peak. Die bisherige Schätzung 0,67 GB zählte nur acht Grenzen und ließ die Neuberechnung innerhalb eines Acht-Schichten-Segments aus. Sie taugt nicht als GPU-Fit-Zahl. Eine vollständige Neuberechnung kann sich einem weiteren Forward-Pass annähern: ungefähr +33 %, falls Backward doppelt so teuer ist wie Forward. Tatsächlicher Overhead hängt von Checkpoint-Granularität und Kernels ab ⁶.

Illustrative Aktivierungsbilanz für 64 Schichten (h = 5.120, bf16; der Koeffizient 34 stammt aus der untersuchten Transformer-Implementierung, nicht aus einer Qwen3-Messung):

Die rechte Spalte zählt nur Grenz-Tensoren und begrenzt den tatsächlichen Peak mit Checkpointing nicht nach oben. Für eine Fit-Entscheidung müssen der Peak beim Neuberechnen und die gewählte Modell-, Batch-, Optimizer- und Softwarekonfiguration mit torch.cuda.max_memory_allocated() gemessen werden.

Untergrenzen des Modellzustands je Methode

Diese Untergrenzen umfassen Gewichte, Gradienten und Optimizer-Zustand. Aktivierungen und temporäre Buffer fehlen; daraus folgt noch kein Fit auf einer konkreten GPU:

Die Parameterzahl von Llama-3.1-8B stammt aus den Hugging-Face-Metadaten (meta-llama/Llama-3.1-8B: 8.030.261.248). Die 70B-Zeile ist gerundet; tatsächliche Checkpoint-Zahlen und Adapterformen unterscheiden sich. Das QLoRA-Paper demonstrierte ein 65B-Modell auf einer 48-GB-GPU unter seiner Trainingskonfiguration ⁸, nicht einen garantierten Fit für jedes 70B-Modell oder jeden Batch.

Was Finetuning leistet und nicht garantiert

Speicherersparnis belegt noch keine Aufgabenqualität. Testen Sie das angepasste Modell auf die Fakten und Verhaltensweisen, die in der Anwendung zählen:

• Fakten-Updates müssen geprüft werden. Finetuning kann faktische Antworten verändern. Weder LoRAs Niedrigrang-Analyse noch QLoRAs Ergebnisse zu Instruktionsdaten belegen jedoch, dass ein kleiner SFT-Datensatz viele veränderliche Fakten zuverlässig installiert oder erhält ^{9 10}. Retrieval kann aktuelle Quellen bereitstellen; prüfen Sie sowohl den Abruf als auch die generierten Antworten.

• Kapazität bewertet den Durchsatz nicht. Bei Batch 4 × 2.048 Tokens benötigt ein 100-Millionen-Token-Datensatz in einer Epoche mindestens 12.208 Optimizer-Schritte, sofern alle Tokens beitragen und keine Beispiele verworfen werden. Checkpointing und Dequantisierung verursachen Zusatzarbeit. Messen Sie Tokens pro Sekunde auf dem Zielsystem, bevor Sie Laufzeit oder Kosten schätzen.

• Keine ehrlichen Defaults ohne Tuning ¹¹. Die Hyperparameter-Tabelle des QLoRA-Papers selbst nutzt Lernrate 2e-4 für 7B- und 13B-Modelle und 1e-4 ab 33B, Batchgröße 16, konstanter Schedule — rund 10× höher als Lernraten des vollen Finetunings, weil nur die kleine Adapter-Population optimiert wird und die Basis eingefroren ist. LoRAs Paper fegt die Lernrate ebenfalls pro Aufgabe. Jede „nehmen Sie einfach"-Zahl — Rank 8, 3 Epochen, LR 2e-4 — ist ein Startgritter, kein Ergebnis; der ehrliche Weg ist ein kleiner Sweep über Lernrate und Rank, bevor man einer Loss-Kurve glaubt.

• Quantisierungsfehler hängen von der Aufgabe ab ¹⁰. QLoRA berichtet starke NF4-Ergebnisse auf seinen Tests; daraus folgt keine allgemeine Qualitätsgrenze für jedes Modell, jede Aufgabe und Kontextlänge. Vergleichen Sie mit der vorgesehenen Referenz in voller Präzision.

Was Sie mitnehmen sollten

• Trainings-Budget pro trainierbarem Parameter: 16 Bytes unter gemischter AdamW-Präzision (2 bf16-Gewicht + 2 bf16-Gradient + 4 fp32-Master + 4 m + 4 v), laut ZeRO-Paper — das 8-Fache der Inference-Gewichte. Qwen3-32B volles Finetuning: 524,2 GB vor Aktivierungen.
• Eingefrorene Parameter behalten ihre Forward-Gewichte; das 16-Byte-Adam-Budget gilt für trainierbare Parameter. Qwen3-32B mit all-linear LoRA r=16 hat ungefähr 134 Mio. trainierbare Parameter und eine Modellzustands-Untergrenze von 67,7 GB.
• Die LoRA-Adaptergröße beträgt r(d_in+d_out) pro Matrix; die sieben Linearen pro Schicht ergeben 67 Mio. trainierbare Parameter bei r=8 und 537 Mio. bei r=64.
• QLoRAs eingefrorene NF4-Basis kostet ungefähr 4,127 Bit/Parameter unter den Double-Quantization-Annahmen des Papers. Bei Qwen3-32B sind das 16,9 GB Basis plus 2,15 GB Adapterzustand bei r=16, vor Aktivierungen und Workspaces.
• Checkpoint-Grenzen sind nicht der Aktivierungs-Peak. Bei Batch 4 × 2.048 benötigt bereits ein bf16-Grenz-Tensor pro Qwen3-32B-Schicht etwa 5,37 GB. Messen Sie den Backward-Peak vor jeder GPU-Fit-Aussage.
• Faktische Qualität muss nach dem Finetuning getestet werden; nutzen Sie aktuelle Retrieval-Quellen, wo eine Anwendung aktuelle oder nachvollziehbare Fakten benötigt.

Für die Speicher-Mathematik auf der Serving-Seite siehe den KV-Cache-Leitfaden; für Gewichtsformate und 4-Bit-Blockquantisierung den Quantisierungs-Leitfaden; für die Rechenschaft über die Kosten des Betriebs des Trainierten den VRAM-Rechner-Leitfaden und das Inference-Ökonomie-Tool.