Türkei (Türkisch)
Germany (German)
Worldwide (English)
Die Lösung hängt von der Phase ab: OOM beim Laden ist nicht dasselbe wie OOM im Backward.
Halkali Merkez Viertel Fatih Str. Ozgur Apt. No. 46, Kucukcekmece, Istanbul, 34303, TR
CUDA-OOM beim Laden, Forward, Backward oder Optimizer Step mit Batch/Context, Checkpointing, QLoRA, Fragmentierung, Offload und Profiling beheben.
Die Lösung hängt von der Phase ab: OOM beim Laden ist nicht dasselbe wie OOM im Backward.
Gradient Checkpointing senkt Activation Memory; kleinere Batches/Contexts reduzieren ihn direkt.
Hoher reserved-but-unallocated Speicher kann Fragmentierung anzeigen; Allocator-Variablen ersetzen aber keine Ursachenanalyse.
OOM bei `from_pretrained()` deutet auf Weights/Quantisierung/Device Map. Forward-OOM auf Activations/Batch/Context, Backward zusätzlich Gradients, Optimizer-Step auf Optimizer State.
Gesamt-VRAM, andere Prozesse, allocated/reserved und Batch/Context protokollieren. Vor/nach erstem Step `nvidia-smi` und `torch.cuda.memory_summary()` erfassen.
nvidia-smipython - <<'PY'
import torch
print(torch.cuda.memory_summary())
PYps aux --sort=-rss | head -20Batch auf 1 setzen, Context sabit lassen. Falls OOM bleibt, Context schrittweise reduzieren. Beide gleichzeitig zu ändern versteckt die Ursache.
Gradient Accumulation simuliert große effektive Batches mit kleinen Micro-Batches. Es hilft bei Activations, aber nicht wenn die Weights allein schon nicht passen.
Wenn Activations dominieren, hilft Checkpointing stark. Activations werden verworfen und im Backward neu berechnet; das spart Speicher, kostet Rechenzeit.
Wenn Base-Weights das Problem sind, ist 4-Bit-QLoRA sehr wirksam. bitsandbytes reduziert Weights, 8-Bit-Optimizer die Optimizer States; PEFT empfiehlt `prepare_model_for_kbit_training()`.
Ist reserved-but-unallocated klein, ist die GPU wirklich voll. Ist es groß, Fragmentierung prüfen. Fremdprozesse schließen und Validation-Peaks messen, bevor Allocator-Settings geändert werden.
Wenn Training stabil ist, aber Eval OOM erzeugt, Eval-Batch, Generation Length, `predict_with_generate` und Validation-Pipeline separat prüfen.
Wenn Single-GPU-Optimierungen nicht reichen, sharden ZeRO-3/FSDP Parameter über GPUs. CPU/NVMe-Offload spart VRAM, kann Training aber deutlich verlangsamen.
| Phase | Erster Verdacht | Erste Maßnahme |
|---|---|---|
| Model Load | Weights / dtype | 4-Bit / Device Map |
| Forward | Batch / Context / Activations | Batch=1, Context reduzieren |
| Backward | Activations + Gradients | Checkpointing |
| Optimizer Step | Optimizer State | 8-Bit-Optimizer / Sharding |
| Eval | Generation/Logits Peak | Eval-Batch/Generation reduzieren |
In einer funktionierenden Trainingsumgebung Pakete nicht blind aktualisieren. GPU, Treiber, CUDA/PyTorch-Runtime, Transformers, Accelerate, PEFT, TRL, bitsandbytes/Diffusers, Modellrevision und Dataset-Fingerprint pro Run protokollieren.
Meist nicht die Ursache. Es gibt ungenutzte Cache-Blöcke frei, hilft aber nicht bei echtem Peak über der Kapazität.
Weights, langer Context, Validation-Peaks oder Optimizer State können VRAM trotzdem überschreiten.
Modellgröße, Precision, Context, Batch, LoRA/QLoRA oder Full Fine-Tuning und Multi-GPU gemeinsam bewerten.