Unsloth, Axolotl, TRL oder LLaMA-Factory: Fine-Tuning über alle Karten, 4 bis 8 GPUs

Welches Fine-Tuning-Framework alle GPUs des Servers nutzt

Auf einem Server mit vier oder acht GPUs nutzen Axolotl, TRL und LLaMA-Factory jede Karte für einen Lauf, entweder als datenparallele Kopien oder mit einem über FSDP oder DeepSpeed ZeRO auf die Karten verteilten Modell. Unsloth dokumentiert datenparalleles Training auf mehreren Karten und einen Modus, der ein Modell auf mehrere Karten aufteilt; offizielle Multi-GPU-Unterstützung nennt seine Dokumentation weiterhin als kommend. Bei LoRA- und QLoRA-Läufen, die auf eine Karte passen, lasten alle vier Frameworks die Karten aus; für Läufe, die nicht auf eine Karte passen, wählen Sie Axolotl, TRL oder LLaMA-Factory.

Diese Seite vergleicht die Software. Welchen Speicher jeder Lauf braucht und welcher Server ihn aufnimmt, rechnen unsere Leitfäden zum GPU-Speicher für Fine-Tuning und zum Fine-Tuning-Server mit 2, 4 oder 8 GPUs vor. Welche Karte sich eignet, vergleichen H200 NVL oder RTX PRO 6000 für Fine-Tuning und die beste GPU für Fine-Tuning 2026; Läufe auf einem einzelnen Gerät behandelt unsere Seite zum Fine-Tuning auf DGX Spark. Die Angaben unten stammen aus Dokumentation, README und Release Notes des jeweiligen Projekts, gelesen am 24. Oktober 2026. Die Projekte veröffentlichen häufig neue Versionen; prüfen Sie die aktuellen Release Notes, bevor Sie einen Lauf planen.

Projektdokumentation, README-Dateien und GitHub-Release-Seiten, gelesen am 24. Oktober 2026. Die Lizenzaufteilung von Unsloth ist aus seinem README zitiert.

Drei Arten, mehrere Karten zu nutzen

Ein Fine-Tuning-Framework kann die Karten eines Servers auf drei Arten nutzen, und die Unterschiede zwischen den Projekten liegen vor allem darin, welche davon sie unterstützen.

Ein Job je Karte. Vier Karten führen vier unabhängige Jobs aus, jeder mit eigenem CUDA_VISIBLE_DEVICES gestartet. Das kann jedes Framework, weil jeder Job nur eine GPU sieht. Es passt zu einem Team, das viele kleine Experimente fährt, etwa mehrere QLoRA-Läufe mit unterschiedlichen Daten.

Datenparallel (DDP). Jede Karte hält eine vollständige Kopie des Laufs und trainiert auf ihrem Anteil der Batches; nach jedem Schritt addieren die Karten ihre Gradienten. Der DDP-Leitfaden von Unsloth beschreibt das als „one copy of the model on each GPU device, feeding each copy distinct samples“. Der Lauf muss auf eine Karte passen. Bei einem LoRA mit Rang 16 auf Llama 3.3 70B ergeben die Gradienten etwa 0,83 GB je Karte und Schritt, nach der Rechnung auf unserer Seite zum Fine-Tuning-Server rund 13 ms über PCIe Gen5; datenparalleles Training skaliert deshalb auch ohne NVLink gut.

Geshardet (FSDP2 oder DeepSpeed ZeRO-3). Gewichte, Gradienten und Optimiererzustände werden auf die Karten aufgeteilt und eingesammelt, wenn eine Schicht sie braucht. So trainieren Sie einen Lauf, der nicht auf eine Karte passt, etwa ein LoRA auf einer 16-Bit-Basis von 70B mit 144,4 GB Modellzuständen oder ein vollständiges Fine-Tuning. Dabei bewegen sich deutlich mehr Daten: Das 70B-LoRA auf vier Karten empfängt nach unserer Rechnung im selben Leitfaden je Karte etwa 212 GB bei jedem Vorwärts- und Rückwärtsdurchlauf.

Eine vierte Anordnung, die Device Map, legt die Schichten eines Modells auf mehrere Karten, damit es überhaupt passt. Unsloth bietet sie an, wie unten beschrieben. Sie dient dazu, ein Modell überhaupt unterzubringen; wie schnell sie ist, sollten Sie selbst messen.

Wir liefern Server mit zwei, vier oder acht Karten für alle drei Arbeitsweisen; nennen Sie uns, wie viele Läufe Ihr Team gleichzeitig startet und wie groß sie sind, und wir dimensionieren Karten und Hauptspeicher danach.

Unsloth: schnell auf einer Karte, DDP auf mehreren

Die Multi-GPU-Seite von Unsloth schreibt, Unsloth „currently supports multi-GPU setups through libraries like Accelerate and DeepSpeed“, und weiter: „you can already leverage parallelism methods such as FSDP and DDP“. Danach beschreibt die Seite nur das Vorgehen für DDP: ein Trainingsskript schreiben und accelerate launch train.py oder torchrun --nproc_per_node N_GPUS train.py ausführen. Außerdem schreibt sie, das Team arbeite daran, Multi-GPU „much simpler“ zu machen, und werde „official multi-GPU support for Unsloth soon“ ankündigen. Eine Unsloth-Seite, die eine Einrichtung mit FSDP oder ZeRO-3 dokumentiert, haben wir nicht gefunden.

Der DDP-Leitfaden zeigt den gemessenen Fall. Qwen3-8B auf zwei NVIDIA H100 mit 80 GB belegte „~19GB of VRAM per H100 GPU“ bei etwa 1,1 Iterationen pro Sekunde, und Unsloth schreibt, der Durchsatz „increases ~linearly with the number of GPUs“, mit „a small, but increasing penalty for the distributed comms“, wenn Karten hinzukommen. DDP ist „auto-enabled when training with >1 GPU“.

Für Modelle, die größer sind als eine Karte, bietet die Unsloth-Seite device_map = "balanced" an: „we will split the model for you on each GPU“, gezeigt mit Llama 3.3 70B in 4 Bit. Das neueste GitHub-Release am 24. Oktober 2026, v0.1.806-beta vom 2. September, bringt „Improved multi-GPU planning, memory fitting, and split-model training“ und „Train larger models across multiple GPUs with automatic placement“. Keine der beiden Seiten sagt, wie sich die Karten in diesem Modus die Rechenarbeit teilen.

Für Unternehmen ist die Lizenz wichtig. Das README von Unsloth hält fest: „The core Unsloth package remains licensed under Apache 2.0, while certain optional components, such as the Unsloth Studio UI are licensed under the open-source license AGPL-3.0.“ Lassen Sie die AGPL-Bedingungen von Ihrer Rechtsberatung prüfen, bevor Sie die Studio-UI anderen Nutzern über ein Netzwerk bereitstellen.

Setzen Sie Unsloth auf einem Server mit mehreren GPUs ein, wenn jeder Lauf auf eine Karte passt: QLoRA bis 70B und LoRA bis 32B auf einer 96-GB-Karte, ein Job je Karte oder DDP über alle Karten.

Axolotl: FSDP2, DeepSpeed und Context Parallelism

Die Multi-GPU-Dokumentation von Axolotl nennt drei Optionen und merkt an, dass Sie diese Strategien „generally cannot combine“: DeepSpeed, das „supports ZeRO stages 1-3“; FSDP, „PyTorch's native sharding implementation (Recommended)“; und DDP als „Default if neither of the above are selected“. FSDP bedeutet inzwischen FSDP2. Die Release Notes der Version 0.20.0 vom 30. September 2026 halten fest: „FSDP2 is the default and the only supported version“. Für DeepSpeed rät die Seite „Start from Stage 1 -> Stage 2 -> Stage 3“, und die Konfiguration erhält einen Schlüssel wie deepspeed: deepspeed_configs/zero1.json.

Lange Sequenzen werden mit Context Parallelism auf die Karten verteilt, eingestellt mit context_parallel_size; Axolotl bevorzugt Ulysses und weicht auf Ring Attention aus. Version 0.20.0 ergänzt gepackte Sequenzen unter „Ulysses, Ring, or USP context parallelism“ und Expert Parallelism über „a plain all_to_all backend“, und dieselben Notes erlauben LoRA-Training „on a frozen native NVFP4 base under FSDP2, DeepSpeed ZeRO-1/2/3, or tensor parallelism“. Das README nennt N-D-Parallelismus, der Context Parallelism, Tensor Parallelism und FSDP in einem Knoten oder über mehrere Knoten kombiniert, und Training auf mehreren Knoten mit torchrun oder Ray.

Zwei Voraussetzungen aus dem README: Python 3.12 oder neuer und PyTorch 2.13.0 oder neuer. Version 0.18.0 brachte Unterstützung für „consumer Blackwell (RTX 50xx / sm120)“; NVIDIA gibt den RTX-PRO-Blackwell-Karten dieselbe Compute Capability 12.0, die unsere Seite zur Softwareunterstützung für Blackwell RTX behandelt. Axolotl steht unter Apache 2.0.

TRL: die Trainer von Hugging Face auf Accelerate

TRL ist die Bibliothek hinter SFTTrainer, DPOTrainer und GRPOTrainer, und mehrere andere Werkzeuge bauen darauf auf; sein README nennt die Integration von Unsloth für „accelerating training using optimized kernels“. Das README hält fest, dass TRL „natively supports distributed training methods like DDP, DeepSpeed ZeRO, and FSDP“. Der Leitfaden für verteiltes Training nutzt accelerate config und accelerate launch train.py, merkt an, dass dies „automatically distributes the workload across all available GPUs“, und nennt die Regel für die Batchgröße: Batchgröße je Gerät × Zahl der Geräte × Schritte der Gradientenakkumulation. Die DeepSpeed-Seite verwendet examples/accelerate_configs/deepspeed_zero2.yaml als Beispiel. Das neueste Release am 24. Oktober 2026 war 1.16.0 vom 15. Oktober. Nicht alle Trainer haben denselben Status: Die Dokumentation von TRL führt den DistillationTrainer bei den regulären Trainern, GKDTrainer, GOLDTrainer und AsyncDistillationTrainer dagegen als experimentell; sie werden aus trl.experimental importiert, wie unsere Seite zur LLM-Distillation on-premise beschreibt.

Der Leitfaden für lange Kontexte ist das ausführlichste Multi-GPU-Dokument der vier Projekte. Er kombiniert Context Parallelism (parallelism_config_cp_size) mit FSDP2 und accelerate 1.11, Ulysses Sequence Parallelism (parallelism_config_sp_size) mit DeepSpeed 0.18.1 und accelerate 1.12; „cp_size requires FSDP2 and sp_size only runs under DeepSpeed“. Sequence Parallelism skaliert „up to the number of KV heads“, acht im Beispiel. Das Beispiel des Leitfadens braucht einen Knoten mit acht H100 und trainiert Qwen3-8B; bei 131k Tokens dauert ein Schritt laut Leitfaden 34,6 s auf zwei GPUs, 17,8 s auf vier und 9,5 s auf acht. Context Parallelism schließt Packing und Modelle mit Sliding-Window-Attention aus; der Leitfaden nennt gpt-oss, Gemma 3 und 4 sowie Qwen3.5 und neuer. Unsere Seite zu GRPO und Reinforcement Learning behandelt den GRPOTrainer von TRL mit vLLM auf denselben Servern.

LLaMA-Factory: eine CLI, mehrere Backends

LLaMA-Factory fasst das Training in einen Befehl, llamafactory-cli train mit einer YAML-Datei, und unterstützt vollständiges, Freeze-, LoRA- und QLoRA-Tuning sowie fortgesetztes Pretraining. Das README der Beispiele startet Läufe auf mehreren GPUs mit FORCE_TORCHRUN=1, enthält ein Beispiel für DeepSpeed ZeRO-3 (qwen3_lora_sft_ds3.yaml), Läufe auf mehreren Knoten mit NNODES und NODE_RANK, elastische Neustarts und ein Ray-Beispiel auf vier GPUs. Das Repository liefert außerdem eine Accelerate-Konfiguration für FSDP, examples/accelerate/fsdp_config.yaml, mit FULL_SHARD. Die News im README nennen „FSDP+QLoRA that fine-tunes a 70B model on 2x24GB GPUs“ (20. März 2024) und ein „Megatron-core training backend with mcore_adapter“ (26. Oktober 2025). Eine Aussage zu FSDP2 haben wir in README und Beispielen nicht gefunden. Die Lizenz ist Apache 2.0.

Die Speichertabelle im README, die ihre Werte als Schätzung kennzeichnet, eignet sich für eine schnelle Prüfung: Sie setzt das 18-Fache der Parameterzahl in GB für vollständiges Training in Mixed Precision an, das 2-Fache für LoRA und das 0,5-Fache für QLoRA mit 4 Bit, und nennt für 70B-Modelle 1.200 GB, 160 GB und 48 GB. Die Modellzustände in unserem Leitfaden für ein 70B-Modell, 1.128,8, 144,4 und 42,8 GB, liegen etwas darunter.

Vier Karten der RTX PRO 6000 Server Edition über PCIe

Keine Edition der NVIDIA RTX PRO 6000 Blackwell hat NVLink; auf einem Server mit vier Karten geht deshalb jedes Byte zwischen den Karten über PCIe Gen5. Die Wahl des Frameworks folgt aus der Größe des Laufs.

Modellzustände aus unserem Leitfaden zum Fine-Tuning-Speicher (Adapter mit Rang 16, 16 Byte je Parameter mit 32-Bit-Adam, etwa 10 mit 8-Bit-Adam); freier Speicher gegenüber den angegebenen 96 GB je Karte. Spalte Frameworks nach der Dokumentation oben.

Datenparallele Läufe passen am besten zu diesem Server, weil nur Gradienten über die Verbindung gehen. Geshardete Läufe funktionieren, bewegen aber bei jedem Durchlauf die eingefrorene Basis über PCIe: beim 70B-LoRA etwa 212 GB je Karte, nach unserer Rechnung mindestens 3,3 Sekunden je Durchlauf bei 64 GB/s, von denen FSDP einen Teil mit der Berechnung überlappt. Prüfen Sie vor geshardeten Läufen die Peer-to-Peer-Übertragung: NVIDIAs NCCL-Dokumentation hält fest, dass „CUDA and the NVIDIA driver stack do not support IOMMU-enabled PCIe peer-to-peer memory transfer“, und unser Leitfaden zu P2P auf der RTX PRO 6000 zeigt die Prüfungen. Unsere Seite zum Server mit vier Karten der Server Edition behandelt den übrigen Server.

Acht H200 NVL mit zwei NVLink-Domänen

Eine NVLink-Brücke verbindet höchstens vier H200 NVL; ein Server mit acht Karten hat daher zwei Domänen aus je vier verbrückten Karten mit PCIe dazwischen. Auf diesem Server vermeiden zwei geshardete Jobs, die jeweils in einer Domäne bleiben, PCIe für ihren größten Verkehr: ein 70B-LoRA mit 36,1 GB je Karte auf den Karten 0 bis 3, ein zweiter Lauf auf den Karten 4 bis 7. Prüfen Sie mit nvidia-smi topo -m, welche Karten eine Brücke teilen, bevor Sie CUDA_VISIBLE_DEVICES setzen, wie unser Leitfaden zur NVLink-Brücke der H200 NVL zeigt.

Läufe, die alle acht Karten brauchen, sind vollständige Fine-Tunings: ein 32B-Modell mit 65,5 GB je Karte bei 32-Bit-Adam, ein 70B-Modell mit 88,2 GB je Karte bei 8-Bit-Adam, nach den Zahlen auf unserer Seite zum Fine-Tuning-Server. In Axolotl, TRL und LLaMA-Factory laufen sie mit FSDP2 oder ZeRO-3 über beide Domänen. Für zwei oder mehr solcher Server dokumentiert Axolotl Training über mehrere Knoten mit torchrun oder Ray, TRL mit Accelerate und Slurm und LLaMA-Factory mit NNODES und seinem Megatron-core-Backend. Unsere Seite zum Server mit acht H200 NVL beschreibt die Hardware.

Welches Framework für welches Team

Ein Lauf je Karte, viele Experimente. Unsloth oder eines der anderen, ein Job je Karte. Die Kernels von Unsloth beschleunigen jeden Lauf auf einer Karte, und vier oder acht Karten führen vier oder acht Jobs aus.

LoRA und QLoRA, die auf eine Karte passen, ein Lauf so schnell wie möglich. DDP in jedem der vier. Das DDP von Unsloth ist dokumentiert und gemessen; in Axolotl ist es die Voreinstellung.

Läufe, die nicht auf eine Karte passen. Axolotl oder TRL mit FSDP2, alternativ DeepSpeed ZeRO-3 in jedem der drei. Axolotl bietet die meisten Einstellungen in einer YAML-Datei, TRL die meiste Kontrolle in Python, LLaMA-Factory eine CLI für viele Modellfamilien.

Lange Sequenzen. TRL oder Axolotl mit Context Parallelism, auf FSDP2 oder DeepSpeed, wie es das jeweilige Projekt verlangt.

Das Framework läuft auf Betriebssystem, Treibern und CUDA des Servers. Die Trainingsplattform darum, mit Warteschlangen, Datenzugriff und MLOps auf Kubernetes, gehört zu unserem Service Private AI/ML, den unser Engineering-Partner Vixen.UNO umsetzt. Wir liefern die Server mit Karten der RTX PRO 6000 Server Edition oder H200 NVL, vor der Lieferung montiert und getestet, mit einem EU-Vertrag und einer Rechnung; Mengen und Lieferzeit bestätigen wir schriftlich mit dem Angebot. Beschreiben Sie Ihre Läufe und das Framework Ihres Teams, und wir antworten innerhalb eines Werktages.

FAQ