Unsloth vs. Axolotl vs. TRL vs. LLaMA-Factory: LLM-Fine-Tuning-Frameworks im Vergleich bei Geschwindigkeit, VRAM und Multi-GPU
Wichtige Erkenntnisse
- •Unsloth liefert durch handgeschriebene Triton-Kernel bis zu 2x Trainingsgeschwindigkeit auf einzelnen GPUs; bei Mixture-of-Experts-Modellen wie gpt-oss-20b wächst der Vorteil, wo es bei 8K Kontext eine 7.3x Beschleunigung gegenüber Transformers v5 erreichte.
- •Axolotl bietet die umfassendste Multi-GPU-Parallelismus-Unterstützung und kombiniert Daten-, Tensor-, Kontext- und Expertenparallelismus über PyTorch DeviceMesh, während Unsloths Multi-GPU-Fähigkeiten begrenzt bleiben und manuelle Einrichtung erfordern.
- •LLaMA-Factory schreibt keine eigenen Kernel, sondern delegiert über Konfigurationsflags an andere Frameworks; sein FSDP+QLoRA-Pfad ermöglicht Fine-Tuning von 70B-Modellen auf zwei 24 GB GPUs — der günstigste dokumentierte Weg im Vergleich.
- •TRL fungiert als grundlegende Trainer-API-Schicht, die Axolotl und LLaMA-Factory intern nutzen; es liefert korrekte Primitive statt abgestimmter Defaults und verlangt von Nutzern eigene Konfigurationen für Parallelismus und Speicheroptimierung.
- •Die vier Frameworks nähern sich sichtbar den Stärken der jeweils anderen an: Unsloth ergänzt Multi-GPU-Support, LLaMA-Factory integriert ein Megatron-core-Backend, und Axolotl übernimmt von Unsloth inspirierte Kernel-Optimierungen.
Vier Open-Source-Projekte dominieren heute das Fine-Tuning großer Sprachmodelle: Unsloth, Axolotl, TRL und LLaMA-Factory. Alle vier kapseln denselben zugrunde liegenden Stack aus PyTorch und Hugging Face, unterscheiden sich aber darin, worauf sie ihre Engineering-Ressourcen konzentrieren. Unsloth schreibt Kernel für maximale Geschwindigkeit neu. Axolotl konzentriert sich auf kombinierbare Parallelisierungsstrategien. TRL definiert die Trainer-APIs, auf denen die anderen aufbauen. LLaMA-Factory priorisiert eine breite Modellabdeckung und Zero-Code-Bedienung.
Da Open-Weight-Modelle von Meta, Alibaba, Google und anderen den Qualitätsabstand zu proprietären APIs verringern, führen Unternehmen Fine-Tuning zunehmend lokal durch, statt pro Token Aufpreise zu zahlen — dadurch wird die Framework-Schicht zu einem direkten Kostenhebel, da GPU-Stunden in jeder Anpassungspipeline der dominierende Kostenfaktor bleiben.
Dieser Vergleich bewertet drei Dimensionen, mit denen Praktiker regelmäßig konfrontiert sind: Trainingsdurchsatz, maximale VRAM-Nutzung und Multi-GPU-Skalierung.
Framework-Überblick
TRL dient als Referenz-Implementierungsschicht. Es liefert SFTTrainer, DPOTrainer, GRPOTrainer, KTOTrainer, RewardTrainer und RLOOTrainer. Sowohl Axolotl als auch LLaMA-Factory greifen intern darauf zurück. Die aktuelle stabile Release-Linie ist v1.8.0.
Unsloth ersetzt Teile des Modellierungscodes durch handgeschriebene Triton-Kernel. Backpropagation-Schritte werden manuell hergeleitet statt per Autograd generiert. Hugging Face weist in einem eigenen Beitrag darauf hin, dass die Genauigkeitsverschlechterung gegenüber Standard-QLoRA bei 0% liegt, da keine Approximationen eingeführt werden.
Axolotl ist ein YAML-gesteuerter Wrapper über Transformers, PEFT, TRL, Accelerate und DeepSpeed. Sein wichtigstes Unterscheidungsmerkmal ist die Kombinierbarkeit von Parallelisierungsstrategien, nicht die Optimierung auf Kernel-Ebene.
LLaMA-Factory ist in einem ACL 2024 System Demonstration Paper dokumentiert und enthält eine Gradio-Weboberfläche namens LlamaBoard. Das Repository deckt mehr als 100 LLMs und VLMs ab.
Geschwindigkeit
Unsloth: Kernel-basierte Gewinne auf einer einzelnen GPU
Die veröffentlichten Benchmarks von Unsloth zeigen eine 2x Trainingsgeschwindigkeit für Llama 3.1 8B und Llama 3.3 70B. Der Testaufbau nutzte den Alpaca-Datensatz, Batch-Größe 2 und Gradient Accumulation 4. QLoRA lief mit Rang 32 über alle linearen Schichten.
Die Ergebnisse für Mixture-of-Experts-Modelle (MoE) fallen deutlicher aus. Unsloth führte Fine-Tuning von unsloth/gpt-oss-20b-BF16 auf einer NVIDIA B200 durch und meldete 712.33 ms pro Schritt bei 8K Kontext gegenüber 5,226.86 ms für Transformers v5 — ein Abstand von 7.3x. Bei 4K Kontext verringert sich die Lücke auf 4.82x, bei 1K beträgt sie nur 1.37x.
Die Richtung des Trends hängt vom Modell ab. Die MoE-Dokumentation von Unsloth grenzt diese konkrete Aussage auf gpt-oss ein, wo die Beschleunigung mit der Sequenzlänge zunimmt, was Flex Attention und den MoE-Kernels zugeschrieben wird.
Qwen3-30B-A3B auf B200 zeigt das entgegengesetzte Muster. Die gemeldete Beschleunigung sinkt von 1.7x bei 1K Kontext auf 1.1x bei 16K. Die Speichereinsparungen bewegen sich in die umgekehrte Richtung und steigen von etwa 2% auf 15%.
Qwen3-30B-A3B auf H100 erreicht bis zu 1.77x. GLM-4.7-Flash auf RTX PRO 6000 erreicht 2.1x. Eine Zusammenarbeit mit AMD maß Llama-3.1-8B LoRA SFT mit 2.07 s/Schritt, während TRL plus FlashAttention-2 2.87 s/Schritt benötigte — ein Abstand von 1.39x bei übereinstimmenden Loss-Kurven.
Axolotl: Übernommene Kernel, nativer Parallelismus
Axolotl fügte im Februar 2025 eigene Triton-Kernel und Autograd-Funktionen für LoRA hinzu und nannte ausdrücklich Unsloth als Inspiration. Sie sind optional über lora_mlp_kernel, lora_qkv_kernel und lora_o_kernel aktivierbar.
Aktuelle Release Notes ergänzen Unterstützung für SonicMoE LoRA, mit bis zu 1.45x Beschleunigung und 30% Speicherreduktion gegenüber einer grouped_mm-Baseline für Qwen3.5-35B-A3B 8-bit LoRA auf einer einzelnen H100 SXM.
Axolotl liefert außerdem FlashAttention 2/3/4, xFormers, Flex Attention, SageAttention, Liger Kernel, Cut Cross Entropy und ScatterMoE mit.
TRL: Die Baseline, an der alle messen
TRL dient typischerweise als Referenzpunkt und ist nicht der Gewinner beim rohen Durchsatz auf einer einzelnen GPU. Es kompensiert dies durch eine breite Palette an Speicher- und Geschwindigkeitshebeln, die in Reducing Memory Usage und Speeding Up Training dokumentiert sind. Dazu gehören Packing, Padding-freie Batches, Truncation, Liger Kernel und der vLLM-Sleep-Modus für GRPO. TRL bietet außerdem eine First-Party-Integration von Unsloth, sodass sich beide nicht gegenseitig ausschließen.
LLaMA-Factory: Geschwindigkeit durch Delegation
LLaMA-Factory schreibt keine eigenen Kernel. Stattdessen macht es Optimierungen anderer Frameworks über Konfigurationsflags zugänglich. Das Setzen von use_unsloth: true aktiviert den Unsloth-Patch; laut Changelog des Projekts liefert dieser Pfad 170% relative Geschwindigkeit. Unsloths Long-Sequence-Training wird mit 117% Geschwindigkeit und 50% Speicher angegeben. LLaMA-Factory unterstützt außerdem enable_liger_kernel: true sowie FlashAttention-2 über flash_attn: fa2.
VRAM
Gemeldete Speicheruntergrenzen
Unsloth veröffentlicht eine nach Parameterzahl sortierte Tabelle mit VRAM-Anforderungen. Sie nennt 6 GB für ein 8B-Modell in 4-bit QLoRA und 41 GB für 70B. LoRA mit 16-bit kostet für dieselben Modelle 22 GB beziehungsweise 164 GB.
Die Hardware-Tabelle im README von LLaMA-Factory deckt denselben 4-bit-QLoRA-Bereich ab und nennt 6 GB bei 7B, 24 GB bei 30B und 48 GB bei 70B. Vollständiges bf16-Fine-Tuning von 70B wird mit 600 GB angegeben.
Beide Tabellen beschreiben Mindestwerte. Batch-Größe, Sequenzlänge und Optimizer-Wahl beeinflussen den tatsächlichen Verbrauch.
Kontextlänge als schärferes Unterscheidungsmerkmal
Spitzen-VRAM bei fixer Kontextlänge ist weniger aussagekräftig als der maximale Kontext, den ein gegebenes VRAM-Budget ermöglicht. Die Kontextlängen-Benchmarks von Unsloth für Llama 3.1 8B QLoRA mit Rang 32 und Batch-Größe 1 fallen deutlich aus. Unsloth führt dies auf seinen Gradient-Checkpointing-Algorithmus in Kombination mit Apples Cut Cross Entropy zurück. Für Llama 3.3 70B auf einer 80 GB A100 meldet es 89,389 Token — verglichen mit 6,916 für die FA2-Baseline.
Die MoE-Speicherfrage
MoE-Training ist der Bereich, in dem sich das Speicherverhalten 2026 am stärksten verändert hat. Unsloth meldet Fine-Tuning von gpt-oss-20b innerhalb von 12.8 GB, während Qwen3-30B-A3B mit 16-bit LoRA 63 GB benötigt.
Bei seinem B200-gpt-oss-Lauf nutzte Unsloth 47.43 GB bei 8K Kontext, während Transformers v5 73.80 GB verwendete. Bei 16K ging Transformers v5 der Speicher aus, während Unsloth 55.13 GB nutzte.
Der Mechanismus ist eine Split-LoRA-Formulierung. PEFT materialisiert das LoRA-Delta über alle Experten hinweg vor der MoE-Matmul-Operation. Unsloth ordnet die Operationen stattdessen um; dies ist mathematisch identisch, vermeidet aber den Materialisierungsschritt.
Axolotl adressiert dasselbe Problem über MoE-Expertenquantisierung, indem Expertengewichte beim Laden des Modells quantisiert und der ursprüngliche bf16-Tensor sofort freigegeben wird. Dies wurde nach einer Änderung in Transformers v5 notwendig, bei der Expertenschichten von nn.Linear zu fusionierten nn.Parameter-3D-Tensoren wechselten, wodurch bitsandbytes sie beim Laden nicht mehr quantisieren konnte. Die Axolotl-Dokumentation berichtet, dass GLM-4.7-Flash QLoRA mit quantize_moe_experts: true von etwa 127 GiB auf etwa 23 GiB reservierten Speicher fällt.
Multi-GPU
Multi-GPU ist der Bereich, in dem sich die Single-GPU-Rangfolge umkehrt. Unsloths Vorsprung auf einer einzelnen GPU überträgt sich nicht.
Axolotl: Die tiefste Parallelismus-Matrix
Der Multi-GPU-Leitfaden von Axolotl bietet drei sich gegenseitig ausschließende Sharding-Strategien: DeepSpeed ZeRO Stages 1 bis 3, FSDP und DDP. FSDP2 ist der empfohlene Pfad, FSDP1 ist veraltet.
Darüber hinaus kombiniert der N-D Parallelism Guide Daten-, Tensor-, Kontext- und Expertenparallelismus über PyTorchs DeviceMesh. Die dokumentierte Support-Matrix bestätigt FSDP+TP, HSDP+TP, FSDP+CP, FSDP+TP+CP und FSDP+EP. Zwei Kombinationen werden ausdrücklich nicht unterstützt: Expertenparallelismus kann in v1 nicht mit TP oder CP kombiniert werden, und reines DDP kann ebenfalls nicht mit ihnen kombiniert werden.
Axolotls Sequenzparallelismus nutzt die ring-flash-attention-Bibliothek. Der veröffentlichte H100-Benchmark für Llama 3.1 8B QLoRA verdeutlicht den Kompromiss: Der Kontext skaliert nahezu linear, aber die Durchsatzeffizienz bricht ein. Auf 4090s bei SP-Grad 8 verzeichnet derselbe Benchmark eine Beschleunigung von 0.88x — das Training wurde tatsächlich langsamer, während der Kontext 32,768 Token erreichte.
Axolotl unterstützt außerdem Multi-Node-Training über torchrun und Ray.
TRL: Zwei Backends zur Sequenzaufteilung
Der Leitfaden für verteiltes Training von TRL unterscheidet klar zwischen zwei Ansätzen. Context Parallelism verwendet Ring Attention auf FSDP2, erfordert Accelerate 1.11.0+, nutzt cp_size mit cp_backend="torch" und unterstützt derzeit nur SDPA — FlashAttention wird auf diesem Pfad nicht unterstützt. Sequenzen müssen durch cp_size * 2 teilbar sein.
Sequence Parallelism nutzt ALST/Ulysses auf DeepSpeed, erfordert DeepSpeed 0.18.1+ und Accelerate 1.12.0+. Es verwendet sp_size mit sp_backend="deepspeed" und funktioniert mit FlashAttention-2, ist jedoch durch die Anzahl der Attention Heads begrenzt und erfordert num_heads >= sp_size.
Die Empfehlungen von TRL sind konkret: Ring Attention eignet sich für Sequenzen mit 1M+ Token und begrenzte Netzwerktopologie, während Ulysses für NVLink- oder InfiniBand-Verbindungen und Sequenzen bis etwa 500k Token geeignet ist. TRLs eigener Ring-Attention-Benchmark fine-tunte Qwen3-8B über 1, 2, 4 und 8 H100-GPUs; bei 8 GPUs wurden Kontextlängen über 300k Token trainierbar.
LLaMA-Factory: Standard-Engines mit Megatron
Die Dokumentation zu verteiltem Training von LLaMA-Factory behandelt DDP, DeepSpeed und FSDP, einschließlich FSDP2 und Ray für Single-Node- und Multi-Node-Läufe. Die Dokumentation beschreibt außerdem DeepSpeed AutoTP, das Tensorparallelismus mit ZeRO kombiniert.
Die folgenreichste Ergänzung im Jahr 2025 war ein Megatron-core-Trainingsbackend über mcore_adapter, das einen echten Pfad für großskaliges Pretraining eröffnet. Der FSDP+QLoRA-Pfad ermöglicht das Fine-Tuning eines 70B-Modells auf zwei 24 GB GPUs — der günstigste dokumentierte Weg zu 70B in diesem Vergleich.
Der Reibungspunkt ist die Oberfläche selbst. Verteilte Konfigurationen liegen in YAML und CLI, nicht in LlamaBoard. Teams, die LLaMA-Factory wegen der Zero-Code-Benutzeroberfläche eingeführt haben, verlieren diese Eigenschaft, sobald sie über eine GPU hinaus skalieren.
Unsloth: Die offene Lücke
Die Multi-GPU-Dokumentation von Unsloth besagt, dass Multi-GPU über Accelerate und DeepSpeed funktioniert und Zugang zu FSDP und DDP bietet. Sie weist jedoch auch darauf hin, dass der Prozess komplex ist und manuelle Einrichtung erfordert, während offizieller Support noch angekündigt wird. Der praktische Weg ist accelerate launch train.py oder torchrun --nproc_per_node N_GPUS train.py. Für Modelle, die zu groß für eine einzelne GPU sind, verteilt device_map = "balanced" das Modell auf mehrere Geräte.
Der PyPI-Eintrag von Unsloth kennzeichnet Multi-GPU als verfügbar, mit größeren Verbesserungen in Arbeit. Das Studio-Changelog beschreibt seit März 2026 eine vorläufige automatische Multi-GPU-Zuweisung für Inferenz und Training.
Zusammengenommen ist die Position klar: Unsloth unterstützt Multi-GPU, bietet aber noch nicht die kombinierbare Parallelismus-Matrix, die Axolotl und TRL dokumentieren.
Grenzen der einzelnen Frameworks
Unsloth stößt an Grenzen, wenn Tensor-, Kontext- oder Expertenparallelismus als erstklassige Konfigurationsoption benötigt wird. Es stößt auch an Grenzen, wenn ein Modell nicht auf der unterstützten Liste steht, da die Gewinne aus architekturspezifischen Kerneln stammen.
Axolotl scheitert eher an der Lernkurve. Nutzer müssen FSDP2 versus DeepSpeed, SP-Grad und Teilbarkeitsanforderungen konfigurieren, die GPU-Anzahl, Sequenzlänge und Attention Heads betreffen.
TRL stößt bei den Defaults an Grenzen. Es liefert korrekte Primitive statt abgestimmter Voreinstellungen — Nutzer müssen Accelerate-Konfiguration, Speicheroptimierungen und Parallelisierungsplan selbst bereitstellen.
LLaMA-Factory stößt an der UI-Grenze an Grenzen. Seine Abstraktion ist bis zu einem Node effektiv, darüber hinaus aber dünn.
Praktische Einordnung
Für eine einzelne Consumer-GPU mit unterstützter Architektur und LoRA oder QLoRA ist Unsloth die stärkste Wahl — allein der Spielraum bei der Kontextlänge rechtfertigt dies.
Für zwei bis acht GPUs mit langem Kontext und vollständigem Fine-Tuning oder RLHF-Pipelines wird Axolotl empfohlen. FSDP2 plus Sequenzparallelismus ist der am besten dokumentierte Pfad.
Für eigene Trainingsschleifen, neue Post-Training-Algorithmen oder enge Hugging-Face-Kopplung ist TRL die Grundlage, auf der man aufbauen sollte, da es die Schicht ist, die die anderen kapseln.
Für die breiteste Modellabdeckung, nicht-technische Bediener und die schnellsten ersten Läufe ist LLaMA-Factory optimal — mit einem Wechsel zur CLI bei Skalierung.
Diese Optionen schließen sich nicht gegenseitig aus. LLaMA-Factory kann Unsloth als Backend ausführen. TRL liefert eine Unsloth-Integration. Axolotl ruft intern TRL-Trainer auf. Die Frameworks nähern sich sichtbar den Stärken der jeweils anderen an — Unsloth ergänzt Multi-GPU, LLaMA-Factory integriert Megatron, Axolotl übernimmt Kernel-basierte Tricks — was darauf hindeutet, dass sich die Differenzierung im nächsten Zyklus von reiner Performance hin zu Entwicklerfreundlichkeit und Integrationsbreite verlagern könnte.
