Wer ein Sprachmodell an eigene Daten anpassen will, landet 2026 fast zwangsläufig bei einem von wenigen Open-Source-Frameworks. Axolotl gehört seit dem Release von Version 0.19.0 am 10. September 2026 zu den aktivsten Projekten in diesem Bereich: neues deklaratives Modell-Support-System, sieben neue Modellfamilien und BitNet-b1.58-QAT-Unterstützung in einem einzigen Update. Für Teams in Deutschland, Österreich und der Schweiz, die LLMs für Kundensupport, interne Dokumente oder Fachsprache trainieren wollen, ist das Framework damit einen genaueren Blick wert, gerade weil sich der komplette Trainingsprozess auf eigener Infrastruktur abspielt und keine Trainingsdaten an einen externen Fine-Tuning-Dienst übermittelt werden müssen. Dieser Artikel zeigt Schritt für Schritt, wie die Installation, Konfiguration und der erste Trainingslauf mit LoRA und QLoRA funktionieren, inklusive Hardware-Planung, Kostenübersicht und den Fehlern, die in der Praxis am häufigsten passieren.
Was ist Axolotl und warum lohnt sich ein Blick darauf?
Axolotl ist ein quelloffenes Fine-Tuning-Framework, das komplexe Trainingsabläufe für große Sprachmodelle auf eine einzige YAML-Konfigurationsdatei reduziert. Statt Trainingscode für jedes Modell neu zu schreiben, definiert man Basismodell, Datensatz, Trainingsmethode und Hardware-Parameter deklarativ, Axolotl übernimmt den Rest: Tokenisierung, Batching, Checkpointing und die Anbindung an Bibliotheken wie Hugging Face Transformers, PEFT, DeepSpeed und Flash Attention. Das Projekt liegt unter der Apache-2.0-Lizenz und wird von der Firma Axolotl AI Cloud gepflegt, die auch gehostete Trainingsinfrastruktur anbietet, das Kernframework bleibt aber vollständig lokal nutzbar und liegt offen auf GitHub.
Der Unterschied zu Tools wie Unsloth liegt im Zuschnitt: Unsloth optimiert vor allem Geschwindigkeit und Speicherverbrauch für einzelne, oft kleinere Modelle auf einer GPU. Axolotl zielt breiter auf Reproduzierbarkeit und Skalierung ab, von einer einzelnen Consumer-GPU bis zu Multi-Node-Clustern mit DeepSpeed ZeRO oder FSDP2. Wer bereits mit Unsloth Studio experimentiert hat, wird die YAML-basierte Konfiguration von Axolotl als logischen nächsten Schritt empfinden, sobald mehrere GPUs oder komplexere Trainingsregime wie DPO ins Spiel kommen.
Mit Release 0.19.0 hat das Projekt außerdem sein Modell-Support-System umgebaut: Statt Patches für jede neue Architektur nachzuziehen, registriert Axolotl Modellfamilien jetzt deklarativ. Das hat direkte Folgen für die Praxis, denn aktuelle Modelle wie Qwen3.8-Flash-Next (inklusive MoE-LoRA-Konfigurationen), Mistral Medium 3.5, Gemma 4 und GPT-OSS sind bereits dokumentiert unterstützt, ohne dass Nutzer auf inoffizielle Patches warten müssen.
Warum lokales Fine-Tuning für Unternehmen in der DACH-Region attraktiv ist
Prompting allein stößt schnell an Grenzen, sobald ein Modell konsistent einen bestimmten Ton treffen, Fachbegriffe aus einer regulierten Branche korrekt verwenden oder ein festes Antwortformat einhalten soll. System-Prompts lassen sich zwar beliebig verlängern, verbrauchen dabei aber Kontextfenster, kosten bei jedem einzelnen API-Aufruf zusätzliche Tokens und liefern trotzdem keine verlässliche Konsistenz über tausende Anfragen hinweg. Fine-Tuning verschiebt dieses Wissen stattdessen direkt in die Modellgewichte, das Ergebnis reagiert danach ohne lange Anweisungen im gewünschten Stil.
Für Unternehmen in Deutschland, Österreich und der Schweiz kommt ein zweiter Punkt hinzu: Kontrolle über die Infrastruktur. Während geschlossene Fine-Tuning-APIs großer Anbieter Trainingsdaten durch fremde Systeme schleusen, läuft Axolotl vollständig auf selbst gewählter Hardware, ob lokal im Rechenzentrum, in einer deutschen Cloud-Region oder auf gemieteten GPUs mit definiertem Serverstandort. Die zugrunde liegende LoRA-Technik ist inzwischen über die PEFT-Bibliothek von Hugging Face breit dokumentiert und in praktisch jedem modernen Fine-Tuning-Framework als Standard verankert, das senkt die Einstiegshürde gegenüber den ersten LoRA-Implementierungen von vor einigen Jahren erheblich.
Voraussetzungen: Diese Versionen brauchen Sie
Bevor es an die Installation geht, sollten die folgenden Voraussetzungen erfüllt sein. Axolotl ist kein Framework, das auf jeder beliebigen Hardware sinnvoll läuft, ein Blick auf die Mindestanforderungen erspart später Fehlermeldungen mitten im Trainingslauf.
| Komponente | Mindestanforderung | Empfehlung |
|---|---|---|
| Python | 3.11 | 3.12 |
| PyTorch | 2.11.0 | 2.12.1 |
| GPU (NVIDIA) | Ampere-Generation | Ampere oder neuer, für bf16 und Flash Attention |
| GPU (AMD) | ROCm-kompatibel | Über separate AMD-HPC-Installationsroute |
| CUDA (Blackwell-GPUs) | 13.0 | 13.0, da CUDA 12.8 nicht für sm_103a/B300 kompiliert |
| Paketmanager | pip | uv (deutlich schnellere Installation) |
| Axolotl-Version | 0.19.0 (Stand 10. September 2026) | jeweils aktuellste Release |
Für den GPU-Speicher gibt die offizielle Dokumentation keinen pauschalen Minimalwert an, weil der tatsächliche Bedarf stark von Modellgröße, Sequenzlänge, Batch-Größe, Quantisierung und Trainingsmethode abhängt. Als grobe Orientierung: Ein 7-bis-8-Milliarden-Parameter-Modell lässt sich mit QLoRA auf einer einzelnen GPU mit 24 GB VRAM trainieren, für volles Fine-Tuning ohne Adapter braucht man je nach Modellgröße ein Vielfaches davon. Die neue NVFP4-MoE-LoRA-Unterstützung aus Version 0.19.0 senkt den Speicherbedarf für MoE-Modelle wie Qwen3.8-Flash-Next zusätzlich, exakte Zahlen dazu veröffentlicht das Projekt aber nicht pauschal, sondern nur pro Modellkonfiguration.
Vor dem ersten Befehl lohnt sich ein kurzer Check, ob GPU-Treiber und CUDA-Toolkit auf dem System überhaupt korrekt erkannt werden. Das erspart Verwirrung, falls die Axolotl-Installation später mit einer unklaren Fehlermeldung abbricht:
nvidia-smi
nvcc --versionZeigt nvidia-smi keine GPU an oder weicht die von nvcc gemeldete CUDA-Version deutlich von der oben genannten Anforderung ab, sollte zuerst der Treiber aktualisiert werden, bevor die eigentliche Axolotl-Installation beginnt. Bei gemieteten Cloud-Instanzen ist das in der Regel bereits vorkonfiguriert, bei eigener Hardware im Rechenzentrum lohnt sich der Check trotzdem, gerade nach einem kürzlichen Treiber- oder Kernel-Update.
Schritt 1: uv installieren und virtuelle Umgebung anlegen
Die aktuelle Axolotl-Dokumentation empfiehlt den Paketmanager uv statt klassischem pip, weil die Installation der schweren Abhängigkeiten (PyTorch, Flash Attention, DeepSpeed) dadurch spürbar schneller läuft. uv wird mit einem einzigen Shell-Befehl installiert:
curl -LsSf https://astral.sh/uv/install.sh | shDanach wird eine virtuelle Umgebung mit Python 3.12 erstellt und aktiviert:
uv venv --python 3.12
source .venv/bin/activateUnter Windows mit WSL2 funktioniert dieser Schritt identisch, da Axolotl auf Linux-Umgebungen ausgelegt ist. Wer nativ unter Windows arbeitet, sollte direkt auf die Docker-Variante ausweichen, die weiter unten beschrieben wird.
Schritt 2: CUDA-Backend setzen und PyTorch installieren
Vor der Installation von Axolotl selbst muss das passende CUDA-Backend für uv gesetzt werden. Für aktuelle Blackwell-GPUs (RTX 50-Serie, B-Serie im Rechenzentrum) ist CUDA 13.0 nötig, ältere Ampere- und Hopper-Karten laufen auch mit früheren Backends, CUDA 13.0 funktioniert aber ebenfalls abwärtskompatibel:
export UV_TORCH_BACKEND=cu130
uv pip install torch==2.12.1 torchvisionWichtig: CUDA 12.8 kompiliert laut Projektdokumentation nicht für die sm_103a-Architektur der B300-GPUs. Wer auf gemieteter Cloud-Hardware mit den neuesten Beschleunigern arbeitet, sollte das Backend also explizit prüfen, bevor der nächste Schritt fehlschlägt.
Schritt 3: Axolotl installieren
Jetzt folgt die eigentliche Installation von Axolotl inklusive DeepSpeed-Unterstützung für spätere Multi-GPU-Läufe:
uv pip install --no-build-isolation axolotl[deepspeed]Für Nutzer, die lieber aus dem Quellcode installieren oder auf einer AMD-GPU arbeiten, dokumentiert das Projekt einen alternativen Weg über git clone:
git clone https://github.com/axolotl-ai-cloud/axolotl
cd axolotl
pip install packaging ninja
pip install --no-build-isolation -e .Für AMD-Systeme mit ROCm-Unterstützung dokumentiert Axolotl zusätzlich eine eigene PyTorch-Installationsroute über den ROCm-Index. Die genaue ROCm-Version hängt vom jeweiligen HPC-System ab und sollte in der offiziellen AMD-HPC-Dokumentation des Projekts geprüft werden, bevor man sie fest in Skripte einbaut.
Schritt 4: Alternative Installation über Docker
Wer Abhängigkeitskonflikte vermeiden will oder auf einem gemieteten GPU-Server ohne persistente Umgebung arbeitet, kann stattdessen das offizielle Docker-Image verwenden. Das ist auch die einfachste Option, um Axolotl auf Plattformen wie RunPod oder Lambda Labs innerhalb weniger Minuten startklar zu haben:
docker run --gpus '"all"' --ipc=host --rm -it axolotlai/axolotl:main-latestDer Container bringt PyTorch, CUDA-Treiber-Bindings und Axolotl bereits vorinstalliert mit, das spart insbesondere bei kurzlebigen Cloud-Instanzen viel Setup-Zeit.
Schritt 5: Beispielkonfigurationen herunterladen
Axolotl liefert über die eigene CLI vorgefertigte Beispiel-Konfigurationen mit, die als Ausgangspunkt für eigene Trainingsläufe dienen. Das erspart es, eine YAML-Datei komplett von Grund auf zu schreiben:
axolotl fetch examples
axolotl fetch deepspeed_configsDer erste Befehl lädt Beispiel-Konfigurationen für gängige Modelle und Trainingsmethoden herunter, der zweite liefert vorgefertigte DeepSpeed-ZeRO-Konfigurationsdateien für Multi-GPU-Training. Beide landen in lokalen Ordnern, die sich direkt als Vorlage kopieren lassen.
Schritt 6: Trainingsdaten vorbereiten
Axolotl unterstützt laut offizieller Dokumentation mehrere Datensatzformate, empfiehlt für eigene Daten aber ausdrücklich JSONL. Das Schema der JSONL-Datei hängt vom gewählten Prompt-Template ab. Zu den unterstützten Formaten zählen unter anderem:
- Alpaca und Alpaca-Varianten (
alpaca,alpaca_chat) - Chat-Templates mit Jinja-Syntax für Rollen- und Turn-Handling (
chat_template) - Input/Output-Paare (
input_output) - Reiner Fließtext für Completion-Training (
completion) - Stufenweise überwachtes Training (
stepwise_supervised) - Präferenzdatensätze für DPO und KTO
- Direkter Import von Hugging-Face-Datasets, sofern die Spalten zum gewählten Format passen
Für ein einfaches Alpaca-Format sieht ein einzelner Eintrag in der JSONL-Datei so aus:
{"instruction": "Fasse den folgenden Text in zwei Saetzen zusammen.", "input": "Der Support-Chat berichtet ueber wiederkehrende Anmeldeprobleme...", "output": "Nutzer melden wiederholt Anmeldefehler nach dem letzten Update. Das Team empfiehlt, den Cache im Browser zu leeren."}Für Kundensupport-Anwendungsfälle im DACH-Raum ist das Chat-Template-Format oft praktischer, weil sich damit direkt mehrere Gesprächsrunden mit System-, Nutzer- und Assistenten-Rollen abbilden lassen, statt jede Anfrage als isoliertes Instruction-Paar zu behandeln.
Schritt 7: Konfigurationsdatei für LoRA erstellen
Der Kern jedes Axolotl-Trainingslaufs ist die YAML-Konfigurationsdatei. Hier ein Minimalbeispiel für LoRA-Fine-Tuning eines mittelgroßen Modells:
base_model: mistralai/Mistral-7B-v0.3
load_in_4bit: false
adapter: lora
lora_r: 16
lora_alpha: 32
lora_dropout: 0.05
lora_target_modules:
- q_proj
- k_proj
- v_proj
- o_proj
datasets:
- path: ./data/support_de.jsonl
type: alpaca
sequence_len: 2048
sample_packing: true
micro_batch_size: 2
gradient_accumulation_steps: 4
num_epochs: 3
learning_rate: 0.0002
bf16: true
flash_attention: true
output_dir: ./outputs/mistral-support-loraDer Parameter lora_r steuert den Rang der Adapter-Matrizen und damit direkt, wie viele zusätzliche Parameter trainiert werden. Ein Wert zwischen 8 und 32 reicht für die meisten Anwendungsfälle mit domänenspezifischen Texten aus, größere Werte erhöhen Speicherbedarf und Trainingszeit, ohne bei kleinen Datensätzen zwangsläufig bessere Ergebnisse zu liefern.
Schritt 8: QLoRA-Variante für begrenzten GPU-Speicher
Wer nur eine einzelne Consumer-GPU zur Verfügung hat, sollte auf QLoRA statt LoRA setzen. Dabei wird das Basismodell in 4-Bit quantisiert geladen, während die LoRA-Adapter weiterhin in höherer Präzision trainiert werden. Die Anpassung der Konfiguration ist minimal:
base_model: mistralai/Mistral-7B-v0.3
load_in_4bit: true
adapter: qlora
lora_r: 16
lora_alpha: 32
lora_dropout: 0.05
lora_target_modules:
- q_proj
- k_proj
- v_proj
- o_proj
bnb_4bit_quant_type: nf4
bnb_4bit_compute_dtype: bfloat16
gradient_checkpointing: true
micro_batch_size: 1
gradient_accumulation_steps: 8Durch die Kombination aus 4-Bit-Quantisierung und Gradient Checkpointing lässt sich ein 7-Milliarden-Parameter-Modell auf einer GPU mit 24 GB VRAM trainieren, etwa einer RTX 4090. Der Kompromiss ist eine längere Trainingszeit gegenüber vollem LoRA auf einer größeren GPU, da kleinere Batch-Größen mehr Gradientenakkumulationsschritte benötigen.
Schritt 9: Training starten
Mit fertiger Konfigurationsdatei wird der Trainingslauf über die Axolotl-CLI gestartet:
axolotl train config.yamlFür Multi-GPU-Setups mit DeepSpeed wird zusätzlich die zuvor heruntergeladene ZeRO-Konfiguration referenziert, etwa über deepspeed: deepspeed_configs/zero2.json innerhalb der YAML-Datei, oder als CLI-Flag beim Start. Axolotl unterstützt dabei DeepSpeed ZeRO Stufe 1, 2 und 3 inklusive CPU-Offloading sowie FSDP2 als Alternative für Sharded-Training über mehrere Knoten hinweg. Welche Variante sinnvoll ist, hängt von der Anzahl verfügbarer GPUs und der Modellgröße ab: FSDP2 eignet sich gut für Modelle, die nicht mehr auf eine einzelne GPU passen, DeepSpeed ZeRO-3 mit CPU-Offload erlaubt zusätzlich das Training größerer Modelle auf Hardware mit wenig GPU-Speicher, allerdings auf Kosten der Geschwindigkeit.
Schritt 10: Training mit Weights & Biases überwachen
Für längere Trainingsläufe lohnt sich die Anbindung an Weights & Biases, um Verlustkurven, Lernrate und GPU-Auslastung live zu verfolgen. Axolotl bringt eine native Integration mit, die lediglich einen API-Schlüssel benötigt:
export WANDB_API_KEY=ihr_api_schluessel
# alternativ:
wandb loginIn der YAML-Konfiguration wird das Projekt zusätzlich benannt, damit Läufe in der Weights-&-Biases-Oberfläche sauber gruppiert erscheinen:
wandb_project: axolotl-support-de
wandb_entity: ihr-teamGerade bei QLoRA-Läufen mit kleinen Batch-Größen lohnt sich der Blick auf die Verlustkurve, weil sich Instabilitäten durch zu hohe Lernraten hier früh zeigen, lange bevor ein vollständiger Trainingslauf durch ist.
Schritt 11: Adapter mit dem Basismodell zusammenführen
Nach Abschluss des Trainings liegt zunächst nur der LoRA-Adapter vor, nicht ein eigenständiges Modell. Für die Auslieferung in Produktion oder den Export in andere Inferenz-Frameworks wird der Adapter mit dem Basismodell zusammengeführt:
axolotl merge-lora config.yaml --lora-model-dir ./outputs/mistral-support-loraDas Ergebnis ist ein vollständiges Modellverzeichnis im Hugging-Face-Format, das sich direkt an Serving-Frameworks wie vLLM übergeben lässt. Wer sein Modell anschließend produktiv bereitstellen will, findet dazu Details im Artikel zum vLLM-Setup.
Für den Einsatz auf schwächerer Hardware oder in lokalen Desktop-Anwendungen lässt sich das zusammengeführte Modell zusätzlich in ein quantisiertes GGUF-Format konvertieren, das von Runtimes wie llama.cpp gelesen wird. Dieser zusätzliche Konvertierungsschritt lohnt sich vor allem dann, wenn das fein-getunte Modell am Ende nicht auf einem GPU-Server, sondern auf Notebooks von Support-Mitarbeitern oder in einer On-Premises-Umgebung ohne dedizierte GPU laufen soll.
Schritt 12: Modell testen und Qualität prüfen
Vor dem produktiven Einsatz sollte das fein-getunte Modell gegen einen Satz repräsentativer Testfragen laufen, idealerweise mit denselben Eingaben, die auch im Trainingsdatensatz nicht enthalten waren. Ein einfacher manueller Test über die Transformers-Pipeline reicht für einen ersten Eindruck:
from transformers import AutoModelForCausalLM, AutoTokenizer
model = AutoModelForCausalLM.from_pretrained("./outputs/mistral-support-lora/merged")
tokenizer = AutoTokenizer.from_pretrained("./outputs/mistral-support-lora/merged")
eingabe = tokenizer("Kunde fragt nach Rueckerstattung bei verspaeteter Lieferung:", return_tensors="pt")
ausgabe = model.generate(**eingabe, max_new_tokens=200)
print(tokenizer.decode(ausgabe[0], skip_special_tokens=True))Für einen systematischeren Qualitätsvergleich zwischen Basismodell und fein-getuntem Modell empfiehlt sich ein eigenes kleines Benchmark-Set aus zehn bis zwanzig Beispielfragen aus dem Zielbereich, die von einer zweiten Person manuell bewertet werden. Automatisierte Benchmarks liefern zwar Zahlen, sagen bei domänenspezifischen Anpassungen aber oft wenig über die tatsächliche Nutzererfahrung aus.
Axolotl, Unsloth und LLaMA-Factory im Kurzvergleich
Axolotl ist nicht das einzige Open-Source-Framework für Fine-Tuning, im selben Umfeld haben sich vor allem Unsloth und LLaMA-Factory als Alternativen etabliert. Alle drei liegen quelloffen auf GitHub, alle drei unterstützen LoRA und QLoRA, unterscheiden sich aber deutlich im Zuschnitt und in der Zielgruppe.
| Kriterium | Axolotl | Unsloth | LLaMA-Factory |
|---|---|---|---|
| Konfiguration | YAML-Datei, deklarativ | Python-Skript oder Notebook | YAML oder Web-Oberfläche |
| Multi-GPU-Training | DeepSpeed ZeRO 1-3, FSDP2 | Eingeschränkt, Fokus auf Einzel-GPU | DeepSpeed unterstützt |
| Zielgruppe | Teams mit skalierenden Trainingspipelines | Einzelne Entwickler, schnelle Experimente | Einsteiger, grafische Bedienung |
| Lizenz | Apache 2.0 | Apache 2.0 | Apache 2.0 |
| Modell-Onboarding | Deklaratives Support-System seit v0.19.0 | Manuelle Patches pro Modell | Community-getriebene Modellliste |
In der Praxis ist die Wahl weniger eine Frage von richtig oder falsch, sondern von Projektgröße. Für ein einzelnes Experiment auf einer gemieteten GPU über ein Wochenende liefert Unsloth oft die schnellste Time-to-Result. Sobald ein Team aber wiederholt trainiert, mehrere Modelle vergleicht oder auf mehreren GPUs gleichzeitig arbeitet, zahlt sich die deklarative, versionierbare YAML-Konfiguration von Axolotl aus, weil sich Trainingsläufe darüber sauber reproduzieren und in Versionskontrolle wie Git ablegen lassen, ganz ohne Python-Skripte, die zwischen Experimenten stillschweigend abweichen.
Wann sich Fine-Tuning nicht lohnt
Nicht jedes Problem, das nach Fine-Tuning aussieht, braucht tatsächlich einen eigenen Trainingslauf. Wer vor allem aktuelle, sich häufig ändernde Fakten in Antworten einbauen will, etwa Produktpreise, Lagerbestände oder interne Richtliniendokumente, fährt mit einer Retrieval-Pipeline meist besser, weil sich die zugrunde liegenden Dokumente dort jederzeit austauschen lassen, ohne das Modell neu zu trainieren. Fine-Tuning eignet sich dagegen für Muster, die über viele Beispiele hinweg stabil bleiben: ein bestimmter Antwortstil, eine feste Ausgabestruktur wie JSON, oder Fachvokabular, das im Basismodell kaum vorkommt.
Ebenfalls zu bedenken: Ein zu kleiner Trainingsdatensatz, etwa deutlich unter tausend Beispielen, führt bei LoRA häufig eher zu auswendig gelernten Einzelfällen als zu generalisierbarem Verhalten. In solchen Fällen liefert präzises Prompt-Engineering, kombiniert mit ein paar Few-Shot-Beispielen direkt im Prompt, oft zuverlässigere Ergebnisse als ein Trainingslauf mit zu wenig Datenbasis. Ein realistischer Richtwert aus der Praxis vieler Fine-Tuning-Projekte liegt bei mehreren hundert bis wenigen tausend qualitativ hochwertigen Beispielen als unterer Grenze, bevor sich der Aufwand eines eigenen Trainingslaufs auszahlt.
Modell versionieren und Trainingsläufe dokumentieren
Ein Punkt, der in vielen Tutorials zu kurz kommt, aber in Produktionssystemen entscheidend ist: die Nachvollziehbarkeit von Trainingsläufen. Wer mehrere Adapter für verschiedene Anwendungsfälle trainiert, verliert ohne klare Namenskonvention schnell den Überblick, welcher Adapter mit welcher Konfigurationsdatei, welchem Datensatzstand und welcher Axolotl-Version entstanden ist. Eine einfache, aber wirkungsvolle Praxis ist, die YAML-Konfigurationsdatei zusammen mit dem trainierten Adapter und einem kurzen Änderungsprotokoll in einem eigenen Git-Repository abzulegen, getrennt vom eigentlichen Trainingscode.
Für Teams, die mehrere Modellversionen parallel betreiben, etwa eine stabile Produktionsversion und eine neuere Testversion, empfiehlt sich zusätzlich ein klares Namensschema für den output_dir, das Modellfamilie, Trainingsmethode und Datum enthält, etwa mistral7b-support-qlora-20260928. Das mag pedantisch wirken, erspart aber genau die Verwirrung, die entsteht, wenn drei Monate später ein Support-Ticket auf ein unerwartetes Modellverhalten hinweist und niemand mehr sicher sagen kann, welcher Adapter tatsächlich in Produktion läuft.
Hardware-Kosten: Was kostet ein Trainingslauf wirklich?
Nicht jedes Team besitzt eigene GPU-Hardware, gerade für gelegentliches Fine-Tuning lohnt sich oft die Miete über einen Cloud-Anbieter. Die folgende Tabelle zeigt aktuelle On-Demand-Preise für gängige Trainings-GPUs bei RunPod, Stand September 2026.
| GPU | VRAM | Preis pro Stunde | Geeignet für |
|---|---|---|---|
| NVIDIA A100 | 80 GB | 1,59 $ | LoRA und QLoRA bis ca. 30B Parameter |
| NVIDIA H100 | 80 GB | 3,49 $ | Größere Modelle, kürzere Trainingszeit durch höhere Rechenleistung |
Bei einem typischen QLoRA-Lauf für ein 7B-Modell mit einigen tausend Beispielen liegen die reinen Rechenkosten damit oft im niedrigen zweistelligen Dollarbereich, sofern der Datensatz überschaubar bleibt und keine mehrfachen Wiederholungsläufe wegen falsch gesetzter Hyperparameter nötig sind. Genau das ist in der Praxis aber der größte Kostentreiber: Nicht die GPU-Miete selbst, sondern wiederholte Fehlversuche durch falsch konfigurierte Lernraten oder zu kleine Kontext-Fenster.
Häufige Fehler beim Fine-Tuning mit Axolotl
Die folgenden Stolperfallen tauchen in der Praxis besonders häufig auf, meist mit vermeidbarem Zeitverlust:
- Falsches CUDA-Backend gesetzt: Wird
UV_TORCH_BACKENDnicht zur GPU-Generation passend gesetzt, schlägt die Installation von PyTorch mit kryptischen Kompilierfehlern fehl, besonders bei neuen Blackwell-Karten mit CUDA 12.8 statt 13.0. - Lernrate zu hoch angesetzt: Werte über 0,0003 führen bei LoRA häufig zu instabilen Verlustkurven, die erst nach mehreren hundert Schritten sichtbar werden, dann ist bereits viel Rechenzeit verloren.
- Sequenzlänge nicht an den Datensatz angepasst: Ist
sequence_lendeutlich größer als die längsten Trainingsbeispiele, wird GPU-Speicher unnötig verschwendet, ohnesample_packingzusätzlich Trainingszeit. - Falsches Datensatzformat gewählt: Wird ein Chat-Datensatz mit dem Alpaca-Typ statt Chat-Template geladen, gehen Rollen- und Turn-Informationen verloren, das Modell lernt dann fehlerhafte Gesprächsstrukturen.
- Kein Validierungssplit angelegt: Ohne separaten Evaluationsdatensatz bleibt Overfitting auf kleine, domänenspezifische Datensätze lange unbemerkt.
- Merge-Schritt vergessen: Wird der LoRA-Adapter direkt an ein Serving-Framework übergeben, das nur vollständige Modelle erwartet, schlägt der Deploy-Versuch fehl, weil Adapter und Basismodell getrennt vorliegen.
- Gradient Checkpointing bei QLoRA deaktiviert: Ohne diese Option reicht der Speicher auf kleineren GPUs oft nicht aus, selbst bei niedriger Batch-Größe.
Fehlerbehebung: Die häufigsten Probleme und ihre Lösung
Auch bei sauberer Konfiguration treten typische Fehlermeldungen auf. Die folgende Übersicht ordnet die häufigsten Probleme konkreten Ursachen zu.
| Problem | Wahrscheinliche Ursache | Lösung |
|---|---|---|
| CUDA out of memory | Batch-Größe oder Sequenzlänge zu hoch für verfügbaren VRAM | micro_batch_size senken, gradient_accumulation_steps erhöhen, gradient_checkpointing: true setzen |
| Installation bricht bei Flash-Attention-Build ab | Fehlende Build-Tools oder falsches CUDA-Backend | packaging und ninja vorher installieren, CUDA-Backend-Variable prüfen |
| Verlust bleibt konstant hoch | Lernrate zu niedrig oder Datensatzformat falsch geparst | Lernrate testweise erhöhen, ein Trainingsbeispiel manuell mit dem Tokenizer prüfen |
| Verlust wird NaN | Lernrate zu hoch, oft in Kombination mit bf16 | Lernrate halbieren, Warmup-Schritte einbauen |
| wandb-Login schlägt fehl | WANDB_API_KEY nicht gesetzt oder abgelaufen | Umgebungsvariable neu setzen oder wandb login erneut ausführen |
| Merge-Befehl findet Adapter nicht | Falscher Pfad zu --lora-model-dir | Pfad zum output_dir aus der Trainingskonfiguration exakt übernehmen |
| DeepSpeed-Prozesse hängen beim Start | Netzwerkkonfiguration zwischen Knoten fehlerhaft | NCCL-Umgebungsvariablen prüfen, Single-Node-Test vor Multi-Node-Lauf durchführen |
| Modell antwortet nach dem Training generisch statt domänenspezifisch | Zu wenige Trainingsbeispiele oder zu niedriger lora_r | Datensatzgröße erhöhen, lora_r schrittweise erhöhen und erneut evaluieren |
LoRA, QLoRA oder volles Fine-Tuning: Was passt zum eigenen Anwendungsfall?
Axolotl unterstützt alle drei Trainingsmethoden, die Wahl hängt vor allem von Hardware-Budget und Zielgenauigkeit ab. Volles Fine-Tuning passt alle Modellgewichte an und liefert bei großen, hochwertigen Datensätzen tendenziell die beste Qualität, verlangt aber ein Vielfaches an GPU-Speicher gegenüber Adapter-Methoden und lässt sich kaum auf einer einzelnen Consumer-GPU durchführen. LoRA trainiert stattdessen kleine, niedrigrangige Zusatzmatrizen, während das Basismodell eingefroren bleibt, das reduziert den Speicherbedarf drastisch bei meist nur geringem Qualitätsverlust gegenüber vollem Fine-Tuning. QLoRA kombiniert LoRA zusätzlich mit 4-Bit-Quantisierung des Basismodells und macht damit auch das Training größerer Modelle auf einer einzelnen 24-GB-GPU praktikabel, auf Kosten etwas längerer Trainingszeiten durch die Quantisierungs- und Dequantisierungsschritte während des Trainings.
Für die meisten Unternehmensanwendungen mit einigen tausend bis niedrigen zehntausend Trainingsbeispielen, etwa Support-Tickets, interne Dokumentation oder Fachsprache aus regulierten Branchen, liefert QLoRA in der Praxis ein gutes Verhältnis aus Qualität, Trainingszeit und Hardware-Kosten. Volles Fine-Tuning lohnt sich vor allem dann, wenn sehr große, saubere Datensätze vorliegen und die letzten Prozentpunkte an Genauigkeit entscheidend sind, etwa bei sicherheitskritischen Klassifikationsaufgaben.
Ein häufig übersehener Zwischenweg ist es, mit einem kleineren lora_r und niedrigerer Lernrate zu starten und die Werte schrittweise zu erhöhen, statt gleich mit aggressiven Einstellungen zu beginnen. Dieses vorsichtige Vorgehen kostet zwar etwas mehr Zeit in der Experimentierphase, senkt aber das Risiko, einen kompletten Trainingslauf wegen instabiler Konfiguration zu verschwenden, gerade bei den ersten Versuchen mit einem neuen Datensatz oder einer bisher ungetesteten Modellfamilie.
Datenschutz und DSGVO beim Fine-Tuning mit Unternehmensdaten
Für Teams in Deutschland, Österreich und der Schweiz ist die Frage, wo Trainingsdaten verarbeitet werden, oft genauso wichtig wie die technische Umsetzung. Da Axolotl vollständig lokal oder auf selbst kontrollierter Cloud-Infrastruktur läuft, bleibt die Kontrolle über Trainingsdaten im Gegensatz zu geschlossenen Fine-Tuning-APIs großer Anbieter vollständig beim Unternehmen selbst. Wer personenbezogene Daten aus Support-Tickets oder internen Dokumenten für das Training nutzt, sollte trotzdem vor dem ersten Lauf prüfen, ob eine Anonymisierung oder Pseudonymisierung der Trainingsdaten nötig ist, insbesondere wenn Modelloutputs später an Kunden ausgespielt werden. Bei der Miete von GPU-Kapazität über internationale Cloud-Anbieter empfiehlt sich zusätzlich ein Blick auf den Serverstandort, um Anforderungen aus Artikel 44 ff. DSGVO zur Datenübermittlung in Drittländer von vornherein zu berücksichtigen.
Ein weiterer praktischer Punkt betrifft die Löschung von Trainingsdaten nach Abschluss eines Laufs. Anders als bei API-basierten Fine-Tuning-Diensten, bei denen unklar bleiben kann, wie lange Anbieter Kopien der übermittelten Daten vorhalten, liegt bei einer selbst betriebenen Axolotl-Umgebung die vollständige Kontrolle darüber beim eigenen Team. Sinnvoll ist ein festes internes Verfahren, das temporäre Trainingsdaten auf gemieteten GPU-Instanzen nach Abschluss des Laufs automatisch löscht, statt sie auf dem nächsten Snapshot der Instanz liegen zu lassen. Das reduziert das Risiko, dass personenbezogene Daten länger als nötig auf fremder Infrastruktur verbleiben, erheblich.
Fortgeschrittene Tipps für stabilere und schnellere Trainingsläufe
Wer über die Basiskonfiguration hinausgehen will, findet in Axolotl mehrere Stellschrauben, die in der Dokumentation oft übersehen werden, in der Praxis aber einen spürbaren Unterschied machen.
- Sample Packing aktivieren: Mit
sample_packing: truewerden mehrere kurze Trainingsbeispiele in eine Sequenz gepackt, statt jedes einzeln mit Padding aufzufüllen. Das reduziert verschwendete Rechenzeit bei Datensätzen mit stark unterschiedlicher Beispiellänge deutlich. - Präferenzoptimierung nach dem Fine-Tuning: Für Anwendungsfälle, bei denen nicht nur Faktenwissen, sondern auch Tonalität und Antwortstil trainiert werden sollen, unterstützt Axolotl DPO- und KTO-Datensätze als zweiten Trainingsschritt nach dem initialen LoRA-Lauf.
- MoE-LoRA für Mixture-of-Experts-Modelle: Für Modelle wie Qwen3.8-Flash-Next mit MoE-Architektur bringt Version 0.19.0 spezielle MoE-LoRA-Konfigurationen mit, die gezielt nur die relevanten Experten-Schichten anpassen, statt die gesamte Architektur einzubeziehen.
- Evaluation während des Trainings: Ein regelmäßiges
eval_steps-Intervall mit separatem Validierungsdatensatz zeigt Overfitting frühzeitig, bevor der komplette Trainingslauf durchgelaufen ist und Rechenzeit verschwendet wurde. - Checkpoints regelmäßig sichern: Bei Multi-Stunden-Läufen auf gemieteten Spot-Instanzen verhindert ein kurzes
save_steps-Intervall, dass ein unerwarteter Instanz-Abbruch den gesamten Fortschritt kostet. - Lernraten-Scheduler nutzen: Ein Cosine- oder linearer Scheduler mit kurzer Warmup-Phase reduziert das Risiko instabiler Verlustkurven gegenüber einer konstanten Lernrate deutlich, besonders bei kleineren Datensätzen.
- Frühzeitig mit kleinem Datensatz-Ausschnitt testen: Ein Testlauf mit nur einigen hundert Beispielen und einer einzigen Epoche deckt Konfigurationsfehler in wenigen Minuten auf, statt sie erst nach einem stundenlangen vollständigen Trainingslauf zu bemerken.
Typische Anwendungsfälle im deutschsprachigen Raum
In der Praxis tauchen bei Unternehmen aus Deutschland, Österreich und der Schweiz immer wieder ähnliche Fine-Tuning-Szenarien auf. Support-Teams trainieren Modelle auf historische Ticket-Antworten, um Erstantworten zu automatisieren, die den firmeneigenen Tonfall treffen, formell oder locker, je nach Marke. Kanzleien und Versicherungen setzen Fine-Tuning ein, um Fachbegriffe aus Verträgen und Gutachten korrekt zu verarbeiten, Begriffe, die in allgemeinen Trainingsdaten kaum vorkommen und von Basismodellen deshalb oft falsch oder unpräzise verwendet werden. Ein drittes wiederkehrendes Szenario ist die Umwandlung unstrukturierter Eingaben in ein festes Ausgabeformat, etwa das Extrahieren von Rechnungsdaten in ein einheitliches JSON-Schema für die Weiterverarbeitung in bestehenden ERP-Systemen.
Gemeinsam ist diesen Fällen, dass die reine Sprachfähigkeit des Basismodells meist schon ausreicht, die Lücke liegt fast immer bei Konsistenz und Fachvokabular, nicht bei grundlegendem Sprachverständnis. Genau für diese Art von Anpassung ist LoRA-Fine-Tuning mit einem überschaubaren, aber sauber kuratierten Datensatz oft treffsicherer als der Versuch, alles über einen immer länger werdenden System-Prompt zu lösen. Wer mit einem ersten kleinen Pilotprojekt startet, etwa 1.000 bis 2.000 Beispiele aus einem einzelnen, klar abgegrenzten Anwendungsfall, bekommt innerhalb weniger Stunden Rechenzeit ein belastbares erstes Ergebnis, ohne gleich ein größeres Datensatz-Projekt aufsetzen zu müssen.
Kontinuierliches Fine-Tuning: Wann ein neuer Trainingslauf nötig wird
Ein einmal trainierter Adapter ist kein statisches Endprodukt. Ändert sich der Produktkatalog, kommen neue Support-Themen hinzu oder wechselt die gewünschte Tonalität, etwa nach einem Relaunch der Marke, sollte das Modell erneut trainiert werden. In der Praxis hat sich ein zweistufiger Ansatz bewährt: Ein initiales Training mit dem vorhandenen historischen Datensatz, gefolgt von regelmäßigen, kleineren Nachtrainings mit frisch gesammelten Beispielen aus dem laufenden Betrieb, etwa vierteljährlich oder sobald sich spürbare Qualitätsprobleme in echten Nutzeranfragen zeigen.
Wichtig dabei: Ein neuer Trainingslauf sollte nicht einfach auf dem vorherigen Adapter aufsetzen, sondern in der Regel erneut vom Basismodell ausgehen, diesmal mit dem erweiterten, aktualisierten Datensatz. Das vermeidet, dass sich Fehler oder veraltete Muster aus früheren Trainingsrunden über mehrere Iterationen hinweg verstärken. Da ein einzelner QLoRA-Lauf für ein 7B-Modell wie oben gezeigt oft unter zwei Stunden Rechenzeit benötigt, ist der Aufwand für ein regelmäßiges Nachtraining überschaubar, gerade im Vergleich zu den Kosten, die durch veraltete oder fehlerhafte automatisierte Antworten im Kundenkontakt entstehen können.
Vollständiges Beispielprojekt: Support-Chatbot auf Deutsch trainieren
Zum Abschluss ein durchgängiges Beispiel, das die einzelnen Schritte zu einem funktionierenden Projekt zusammenführt: ein deutschsprachiges Modell, das auf Support-Anfragen trainiert wird.
# 1. Umgebung vorbereiten
curl -LsSf https://astral.sh/uv/install.sh | sh
export UV_TORCH_BACKEND=cu130
uv venv --python 3.12
source .venv/bin/activate
uv pip install torch==2.12.1 torchvision
uv pip install --no-build-isolation axolotl[deepspeed]
# 2. Beispielkonfigurationen laden
axolotl fetch examples
# 3. Eigene Konfiguration anlegen (config.yaml, siehe Schritt 7/8)
# 4. wandb-Tracking aktivieren
export WANDB_API_KEY=ihr_api_schluessel
# 5. Training starten
axolotl train config.yaml
# 6. Adapter mit Basismodell zusammenführen
axolotl merge-lora config.yaml --lora-model-dir ./outputs/mistral-support-lora
# 7. Modell lokal testen
python test_model.pyEin Trainingslauf mit rund 5.000 Support-Beispielen, QLoRA auf einem 7B-Basismodell und drei Epochen dauert auf einer gemieteten A100 80GB üblicherweise zwischen 45 und 90 Minuten, abhängig von Sequenzlänge und Batch-Größe. Die Beispielausgabe nach erfolgreichem Training in der Kommandozeile sieht typischerweise so aus:
{'loss': 0.842, 'grad_norm': 0.31, 'learning_rate': 0.00018, 'epoch': 1.0}
{'loss': 0.617, 'grad_norm': 0.24, 'learning_rate': 0.00012, 'epoch': 2.0}
{'loss': 0.489, 'grad_norm': 0.19, 'learning_rate': 0.00004, 'epoch': 3.0}
Training completed. Adapter saved to ./outputs/mistral-support-loraEine kontinuierlich fallende Verlustkurve über die Epochen hinweg ist ein gutes Zeichen, ein Anstieg gegen Ende deutet dagegen auf beginnendes Overfitting hin und sollte durch weniger Epochen oder einen größeren Datensatz korrigiert werden. Wer die Ergebnisse anschließend mit anderen Modellen vergleichen will, findet eine strukturierte Herangehensweise dafür im Artikel zum LLM-Benchmark-Setup.
Qualitätssicherung: Fehlverhalten nach dem Training prüfen
Ein fein-getuntes Modell übernimmt nicht nur die gewünschten Muster aus dem Trainingsdatensatz, sondern potenziell auch unerwünschte Nebeneffekte, etwa wenn der Datensatz unausgewogen ist oder bestimmte Formulierungen überproportional häufig vorkommen. Vor dem produktiven Einsatz lohnt sich deshalb ein gezielter Test mit Grenzfällen: mehrdeutige Anfragen, Fragen außerhalb des eigentlichen Themenbereichs und Formulierungen, die im Trainingsdatensatz nicht vorkamen. Reagiert das Modell auf themenfremde Anfragen plötzlich mit erfundenen, zu selbstbewusst formulierten Antworten statt einer ehrlichen Unklarheit, deutet das häufig auf ein zu enges, wenig diverses Trainingsset hin.
Ein einfacher, aber wirkungsvoller Test besteht darin, dieselbe Frage mehrfach mit leicht unterschiedlicher Formulierung zu stellen und zu prüfen, ob die Antworten inhaltlich konsistent bleiben. Große Schwankungen sind ein Hinweis darauf, dass das Modell eher Oberflächenmuster aus dem Trainingsdatensatz auswendig gelernt hat, statt das zugrunde liegende Konzept zu verallgemeinern, ein klassisches Anzeichen für zu wenige oder zu ähnliche Trainingsbeispiele. In solchen Fällen hilft es meist mehr, den Datensatz um zusätzliche Formulierungsvarianten zu erweitern, als einfach die Anzahl der Trainingsepochen zu erhöhen, da Letzteres das Problem oft eher verstärkt als löst. Wer sein Modell zusätzlich systematisch gegen einen festen Prompt-Katalog testen will, findet einen strukturierten Ansatz dafür auch im Artikel zu LLM-Fine-Tuning mit LoRA.
Axolotl im Vergleich zu anderen Fine-Tuning-Wegen
Wer bereits andere Ansätze für Fine-Tuning oder Modellanpassung kennt, sollte Axolotl gezielt dort einsetzen, wo es seine Stärken ausspielt: reproduzierbare, deklarative Konfigurationen und Skalierung über mehrere GPUs hinweg. Für einzelne, schnelle Experimente auf einer GPU ohne Multi-Node-Ambitionen kann ein schlankeres Tool wie Unsloth die einfachere Wahl sein. Wer stattdessen keine eigenen Trainingsdaten sammeln, sondern das Modell zur Laufzeit mit aktuellem Wissen anreichern will, ist mit einer RAG-Pipeline oft besser bedient als mit Fine-Tuning, da sich Wissensquellen dort ohne erneutes Training aktualisieren lassen. Beide Ansätze schließen sich nicht aus: Fine-Tuning für Tonalität, Format und Fachvokabular, RAG für aktuelle, faktenbasierte Inhalte.
In der Praxis kombinieren viele produktive Systeme beide Techniken: Ein fein-getunter Adapter sorgt für den richtigen Ton und die korrekte Struktur der Antwort, während eine angebundene Wissensdatenbank die faktischen Inhalte liefert, die sich ohnehin regelmäßig ändern. Wer eigene Modelle systematisch gegen mehrere Kandidaten testen und die beste Kombination aus Basismodell, Adapter und Retrieval-Strategie ermitteln will, kann dafür eine selbst gehostete Vergleichsumgebung nutzen, wie sie im Artikel zum Aufbau einer eigenen LLM-Arena beschrieben ist.
Häufig gestellte Fragen
Ist Axolotl kostenlos nutzbar?
Ja, das Kernframework steht unter der Apache-2.0-Lizenz und lässt sich kostenlos lokal oder auf eigener Cloud-Infrastruktur betreiben. Kosten entstehen lediglich durch die genutzte GPU-Hardware, egal ob eigene oder gemietete.
Kann ich Axolotl auf einer einzelnen Consumer-GPU nutzen?
Ja, mit QLoRA und aktiviertem Gradient Checkpointing lassen sich 7-bis-8-Milliarden-Parameter-Modelle auf einer GPU mit 24 GB VRAM trainieren, etwa einer RTX 4090. Für größere Modelle wird zusätzlicher Speicher oder eine Multi-GPU-Konfiguration mit DeepSpeed oder FSDP2 nötig.
Welche aktuellen Modelle unterstützt Axolotl?
Mit Version 0.19.0 vom 10. September 2026 dokumentiert das Projekt unter anderem Unterstützung für Qwen3.8-Flash-Next inklusive MoE-LoRA, Mistral Medium 3.5, Gemma 4 und GPT-OSS. Ältere Modellfamilien wie Llama und frühere Qwen-Versionen bleiben ebenfalls unterstützt.
Was ist der Unterschied zwischen LoRA und QLoRA?
LoRA trainiert kleine Zusatzmatrizen, während das Basismodell in voller Präzision eingefroren bleibt. QLoRA lädt das Basismodell zusätzlich in 4-Bit-Quantisierung, was den Speicherbedarf weiter senkt, aber etwas mehr Rechenzeit durch Quantisierungsschritte kostet.
Unterstützt Axolotl Training über mehrere GPUs hinweg?
Ja, das Framework unterstützt sowohl DeepSpeed ZeRO in den Stufen 1 bis 3 mit optionalem CPU-Offloading als auch FSDP2 für Sharded-Training über mehrere Knoten.
Wie lange dauert ein typischer Fine-Tuning-Lauf?
Das hängt stark von Modellgröße, Datensatzgröße und Hardware ab. Ein QLoRA-Lauf mit rund 5.000 Beispielen auf einem 7B-Modell und einer gemieteten A100-GPU dauert häufig zwischen 45 und 90 Minuten für drei Trainingsepochen.
Brauche ich für den DACH-Raum eine spezielle Datenschutzkonfiguration?
Axolotl selbst hat keine eingebaute Datenschutzfunktion, da es lokal oder auf selbst kontrollierter Infrastruktur läuft, liegt die Verantwortung für DSGVO-konforme Datenverarbeitung beim Betreiber. Wichtig ist vor allem die Wahl des Serverstandorts bei gemieteter GPU-Kapazität und eine Prüfung, ob Trainingsdaten personenbezogene Informationen enthalten.
Was mache ich, wenn das trainierte Modell schlechter antwortet als das Basismodell?
Das deutet meist auf zu wenige oder zu einseitige Trainingsbeispiele, eine zu hohe Lernrate oder Overfitting durch zu viele Epochen hin. Ein Blick auf die Verlustkurve in Weights & Biases sowie ein Vergleich mit einem separaten Validierungsdatensatz helfen, die Ursache einzugrenzen, bevor der Datensatz erweitert oder die Konfiguration angepasst wird.
