Multi-GPU-Finetuning mit Distributed Data Parallel (DDP)
Lerne, wie du die Unsloth-CLI verwendest, um auf mehreren GPUs mit Distributed Data Parallel (DDP) zu trainieren!
Nehmen wir an, wir haben mehrere GPUs und möchten ein Modell mit allen feinabstimmen! Die direkteste Strategie hierfür ist Distributed Data Parallel (DDP), bei dem auf jeder GPU-Karte eine Kopie des Modells erstellt wird, jede Kopie während des Trainings unterschiedliche Proben aus dem Datensatz erhält und ihre Beiträge zu den Gewichtsupdates pro Optimizer-Schritt zusammengeführt werden.
Warum sollten wir das tun? Wenn wir dem Trainingsprozess mehr GPUs hinzufügen, erhöhen wir die Anzahl der Proben, auf denen unsere Modelle pro Schritt trainieren, machen damit jedes Gradientenupdate stabiler und steigern unseren Trainingsdurchsatz mit jeder hinzugefügten GPU erheblich.
Hier ist eine Schritt-für-Schritt-Anleitung, wie man das mit der Befehlszeilenschnittstelle (CLI) von Unsloth macht!
Hinweis: Unsloth DDP funktioniert mit jedem Ihrer Trainingsskripte, nicht nur über unsere CLI! Weitere Details unten.
Unsloth aus dem Quellcode installieren
Wir klonen Unsloth von GitHub und installieren es. Bitte erwägen Sie die Verwendung einer virtuellen Umgebung; wir verwenden gern uv venv –python 3.12 && source .venv/bin/activate, aber jedes Werkzeug zur Erstellung virtueller Umgebungen ist geeignet.
git clone https://github.com/unslothai/unsloth.git
cd unsloth
pip install .Zielmodell und Datensatz für die Feinabstimmung auswählen
In diesem Demo werden wir feinabstimmen Qwen/Qwen3-8B auf dem yahma/alpaca-cleaned Chat-Datensatz. Dies ist eine Supervised Fine-Tuning (SFT)-Aufgabe, die üblicherweise verwendet wird, um ein Basismodell an einen gewünschten Konversationsstil anzupassen oder die Leistung des Modells für eine nachgelagerte Aufgabe zu verbessern.
Verwenden Sie die Unsloth-CLI!
Zuerst schauen wir uns die Hilfemeldung an, die in die CLI eingebaut ist (wir haben hier an verschiedenen Stellen mit „...“ zur Kürze abgekürzt):
Das sollte Ihnen einen Eindruck davon geben, welche Optionen Sie der CLI für das Training Ihres Modells übergeben können!
Für Multi-GPU-Training (DDP in diesem Fall) verwenden wir den torchrun Launcher, der es ermöglicht, mehrere verteilte Trainingsprozesse in Single-Node- oder Multi-Node-Setups zu starten. In unserem Fall konzentrieren wir uns auf den Single-Node-Fall (d. h. eine Maschine) mit zwei H100-GPUs.
Prüfen wir auch den Status unserer GPUs mit dem nvidia-smi Kommandozeilenwerkzeug:
Großartig! Wir haben wie erwartet zwei H100-GPUs. Beide zeigen 0MiB Speichernutzung, da wir derzeit nichts trainieren oder kein Modell im Speicher geladen ist.
Um Ihren Trainingslauf zu starten, führen Sie einen Befehl wie den folgenden aus:
Wenn Sie mehr GPUs haben, können Sie --nproc_per_node entsprechend setzen, um sie zu nutzen.
Hinweis: Sie können den torchrun Launcher mit jedem Ihrer Unsloth-Trainingsskripte verwenden, einschließlich der Skripte aus unseren kostenlosen Colab-Notebooks konvertierten, und DDP wird automatisch aktiviert, wenn mit mehr als 1 GPU trainiert wird!
Ein weiterer Blick auf nvidia-smi während das Training läuft:
Wir sehen, dass beide GPUs nun etwa 19GB VRAM pro H100-GPU nutzen!
Beim Blick in die Trainingslogs sehen wir, dass wir mit einer Rate von ~1,1 Iterationen/s trainieren können. Diese Trainingsgeschwindigkeit ist annähernd konstant, auch wenn wir mehr GPUs hinzufügen, sodass unser Trainingsdurchsatz ungefähr linear mit der Anzahl der GPUs steigt!
Trainingsmetriken
Wir führten einige kurze Rang-16-LoRA-Feinabstimmungen auf unsloth/Llama-3.2-1B-Instruct auf dem yahma/alpaca-cleaned Datensatz durch, um den verbesserten Trainingsdurchsatz bei DDP-Training mit mehreren GPUs zu demonstrieren.
Die obige Abbildung vergleicht den Trainingsverlust zwischen zwei Llama-3.2-1B-Instruct LoRA-Feinabstimmungen über 500 Trainingsschritte, mit Single-GPU-Training (rosa) vs. Multi-GPU-DDP-Training (blau).
Beachten Sie, dass die Verlustkurven in Skalierung und Trend übereinstimmen, aber ansonsten ein wenig anders sind, da die Multi-GPU-Trainingsprozesse pro Schritt doppelt so viele Trainingsdaten verarbeiten. Dies führt zu einer leicht unterschiedlichen Trainingskurve mit weniger Variabilität auf Schritt-für-Schritt-Basis.
Die obige Abbildung stellt den Trainingsfortschritt für dieselben beiden Feinabstimmungen dar.
Beachten Sie, dass das Multi-GPU-DDP-Training eine Epoche der Trainingsdaten in halb so vielen Schritten durchläuft wie das Single-GPU-Training. Das liegt daran, dass jede GPU pro Schritt ein eigenes Batch (der Größe per_device_train_batch_size) verarbeiten kann. Allerdings ist die Zeit pro Schritt beim DDP-Training aufgrund der verteilten Kommunikation für die Modellgewichtsupdates etwas langsamer. Wenn Sie die Anzahl der GPUs erhöhen, wird der Trainingsdurchsatz weiterhin ungefähr linear zunehmen (jedoch mit einer kleinen, aber wachsenden Strafe für die verteilte Kommunikation).
Diese gleichen Verhaltensweisen bezüglich Verlust und Trainingsepoche gelten auch für QLoRA-Feinabstimmungen, bei denen wir die Basismodelle in 4-Bit-Präzision geladen haben, um zusätzlichen GPU-Speicher zu sparen. Das ist besonders nützlich, um große Modelle mit begrenztem GPU-VRAM zu trainieren:
Vergleich des Trainingsverlusts zwischen zwei Llama-3.2-1B-Instruct QLoRA-Feinabstimmungen über 500 Trainingsschritte, mit Single-GPU-Training (orange) vs. Multi-GPU-DDP-Training (lila).
Vergleich des Trainingsfortschritts für dieselben beiden Feinabstimmungen.
Zuletzt aktualisiert
War das hilfreich?