Automatische Übersetzung

Dieser Artikel wurde automatisch aus der englischen Originalversion übersetzt.

Leitfaden zum LLM-Fine-Tuning: LoRA, QLoRA, DoRA, Unsloth, Axolotl und Deployment

Die meisten Fine-Tuning-Projekte, die ich gesehen habe, scheitern nicht beim Training, sondern in den Schritten davor und danach: schlechte Daten, das falsche Basismodell, keine echte Evaluation. Das eigentliche Training ist der einfache Teil. Dieser Leitfaden ist das, was ich gern vor meinem ersten ernsthaften Fine-Tune gehabt hätte — wann man es tun sollte, wann nicht, welche Methoden heute funktionieren (LoRA, QLoRA, DoRA, ORPO) und wie man ein Modell von einem Notebook zu einem Serving-Endpoint bringt.

Solltest du überhaupt fine-tunen?

Bevor du GPU-Stunden investierst, entscheide, ob Fine-Tuning überhaupt das richtige Werkzeug für das vorliegende Problem ist.

Fine-Tuning vs. RAG

Fine-Tune nicht nur, um „Wissen“ hinzuzufügen. Nutze stattdessen diese Aufteilung:

Merkmal	Fine-Tuning	RAG (Retrieval-Augmented Generation)
Kernfunktion	Verändert interne Gewichte, um Fähigkeiten, Stile oder Verhaltensweisen zu vermitteln	Liefert externen, aktuellen Kontext zur Inferenzzeit
Am besten geeignet	• Spezifische Gesprächsstile • Komplexe Befolgung von Instruktionen • Domänenspezifisches Reasoning	• Schnell wechselnde Daten (Nachrichten, Aktienkurse) • Halluzinationen reduzieren (Grounding) • Quellen zitieren
Umgang mit Wissen	Verinnerlicht Muster, keine Fakten	Ruft Fakten aus externer Wissensbasis ab
Update-Frequenz	Erfordert Retraining für Updates	Aktualisiert sich sofort mit neuen Dokumenten

Fine-Tuning vs. Prompt Engineering

Moderne LLMs reagieren bemerkenswert gut auf sauber formulierte Prompts. Reize Prompting aus, bevor du zu Fine-Tuning greifst.

Aspekt	Fine-Tuning	Prompt Engineering
Setup-Kosten	Hoch (Datenkurierung, GPU-Compute, Iteration)	Niedrig (iterative Prompt-Verfeinerung)
Flexibilität	Nach dem Training festgelegt	Jederzeit ohne Retraining änderbar
Format/Stil	Am besten für komplexe, konsistente Ausgabeformate	Gut für einfache Formatierung mit Few-Shot-Beispielen
Latenz	Niedriger (keine langen System-Prompts)	Höher (Kontext-Overhead bei jeder Anfrage)
Am besten geeignet	Komplexe Verhaltensweisen, Distillation, Kosten bei Skalierung	Schnelle Iteration, wechselnde Anforderungen

[!TIP] Probiere zuerst Prompting Starte mit Few-Shot-Beispielen im Prompt. Wenn das Verhalten immer noch inkonsistent ist, versuche SGR, bevor du zu Fine-Tuning greifst.

Fine-Tuning vs. Schema-Guided Reasoning (SGR)

Bibliotheken wie xgrammar und outlines schränken Modellausgaben zur Inferenzzeit mithilfe endlicher Zustandsautomaten ein. Sie funktionieren direkt mit Basismodellen, ganz ohne Training.

Der Wert von SGR liegt nicht nur in strukturierten Ausgaben. Es geht um Konsistenz: dieselbe Eingabeform liefert jedes Mal dieselbe Ausgabeform, ohne irgendetwas neu zu trainieren. Wenn Prompting allein inkonsistente Ergebnisse liefert, fixiert SGR das Ausgabemuster beim Decoding.

Aspekt	SGR (ohne Fine-Tuning)	Fine-Tuning
Setup	Sofort einsatzbereit — Schema definieren, deployen	Erfordert Datenkurierung, GPU-Compute, Iteration
Konsistenz	Garantierte Struktur, verlässliche Muster	Gelerntes Verhalten (kann trotzdem variieren)
Flexibilität	Schema jederzeit ohne Retraining ändern	Nach dem Training festgelegt
Latenz	Leichter Overhead (Modell kann gegen das Schema „anarbeiten“)	Niedriger (Modell gibt das Format natürlich aus)
Am besten geeignet	Strukturierte Ausgaben, konsistentes Verhalten	Komplexes Reasoning, tiefgreifende Verhaltensänderungen

Eine praktische Reihenfolge:

1. Starte mit Prompting und Few-Shot-Beispielen für grundlegende Formatierung.
2. Ergänze SGR (xgrammar oder outlines), wenn das Format inkonsistent ist.
3. Fine-Tune nur dann, wenn du Verhaltensänderungen brauchst, die ein Schema nicht erzwingen kann.

Schnelle Referenz: Probleme den Lösungen zuordnen

Herausforderung	Beste Lösung	Warum?
Fehlendes Wissen	RAG	Modelle halluzinieren Fakten. Retrieval liefert fundierten, aktuellen Kontext
Falsches Format/falscher Ton	Prompt Engineering	Moderne Modelle befolgen Stilvorgaben gut über Few-Shot-Beispiele
Inkonsistente Ausgaben	SGR (xgrammar)	Garantierte Struktur und Zuverlässigkeit ohne Training
Komplexe Verhaltensänderungen	Fine-Tuning (SFT)	Tiefe Persona, Reasoning-Muster oder mehrstufige Workflows
Sicherheit/Präferenz	Alignment (DPO)	Wenn Ausgaben korrekt sind, aber Präferenzen nicht treffen
Latenz/Kosten bei Skalierung	Distillation (SFT)	Kleineres Student-Modell auf Ausgaben eines größeren Teacher-Modells trainieren
Modellgröße reduzieren	Quantisierung	Kein Training — komprimiert Gewichte (FP16→INT4) für schnellere Inferenz

Wann sich die Mathematik tatsächlich lohnt

Fine-Tuning lohnt sich, wenn der Traffic hoch ist und die Anforderungen stabil sind. Ein solides RAG-Setup trägt bei jedem Aufruf oft 2.000 Tokens Kontext mit: System-Prompt, abgerufene Dokumente, Few-Shot-Beispiele. Das ist ein Kontext-Overhead, den du bei jeder Anfrage zahlst.

Ein feinabgestimmtes Modell nimmt den Großteil dieser Instruktionen in seine Gewichte auf, sodass der Prompt von ~2.000 Tokens auf ~50 fällt. Ab genügend Volumen amortisiert das den Trainings-Compute innerhalb weniger Wochen.

[!TIP] Das Hybrid-Setup Das Muster, das ich in Produktion immer wieder sehe: ein feinabgestimmtes 8B-Modell kombiniert mit einem kleinen RAG-Retriever für Fakten. Das schlägt oft ein per Prompt gesteuertes 70B+-Modell sowohl bei Genauigkeit als auch bei Kosten.

---

Arten des Fine-Tunings

Es gibt drei Hauptformen von Fine-Tuning. Sie unterscheiden sich darin, welche Art von Daten sie benötigen und was sie dem Modell beibringen.

1. Continued pre-training (unüberwacht)

Du trainierst das Basismodell auf mehr Rohtext, ohne Labels. Es macht weiterhin Next-Token-Prediction, genau wie beim ursprünglichen Pre-Training.

Wann man es einsetzt:

• Die Domäne hat Vokabular, das das Basismodell nie gesehen hat (medizinisch, juristisch, interne Codebases).
• Du hast große Mengen Domänentext, aber keine gelabelten (Input, Output)-Paare.
• Das Basismodell stolpert über domänenspezifische Terminologie.

Beispiel: Training auf Millionen klinischer Notizen, damit das Modell medizinische Abkürzungen, Medikamentennamen und klinische Workflows aufnimmt.

2. Supervised fine-tuning (SFT)

SFT trainiert auf gelabelten (Input, Output)-Paaren. Du zeigst dem Modell für jede Eingabe genau die Ausgabe, die du haben willst.

Wann man es einsetzt:

• Du hast eine spezifische Aufgabe mit einem sauberen Input/Output-Format.
• Du hast qualitativ gute gelabelte Daten, auch in kleiner Menge.
• Du brauchst vorhersagbares Verhalten auf einer bekannten Eingabeform.

Beispiel: Training auf Paaren aus (Beschreibung einer SQL-Abfrage, SQL-Code) für Text-to-SQL.

{
    "input": "Get all users who signed up last month",
    "output": "SELECT * FROM users WHERE signup_date >= DATE_SUB(NOW(), INTERVAL 1 MONTH)"
}

3. Instruction tuning

Instruction Tuning ist ein Spezialfall von SFT, der Modelle dazu bringen soll, einer großen Vielfalt natürlicher Sprachinstruktionen zu folgen. Die Trainingsdaten sind Paare aus (Instruktion, Antwort) über viele unterschiedliche Aufgaben hinweg.

Wann man es einsetzt:

• Du willst einen General-Purpose-Assistenten bauen (wie ChatGPT oder Claude).
• Das Modell soll mit vielfältigen, offenen Anfragen umgehen.
• Du baust ein Chat-Interface.

Beispiel: Training auf Tausenden unterschiedlicher Instruktionen wie „Fasse diesen Artikel zusammen“, „Schreibe ein Gedicht über X“, „Erkläre Y in einfachen Worten“.

Vergleich

Aspekt	Continued Pre-Training	SFT	Instruction Tuning
Daten	Rohtext	(Input, Output)-Paare	(Instruktion, Antwort)-Paare
Labels	Keine (unüberwacht)	Aufgabenspezifisch	Vielfältige Aufgaben
Ziel	Domänenwissen	Verhalten für spezifische Aufgabe	Beliebigen Instruktionen folgen
Datenvolumen	Groß (Millionen Tokens)	Klein-Mittel (500-10k Beispiele)	Mittel-Groß (10k-100k Beispiele)

[!NOTE] Was Leute in der Praxis tatsächlich tun Die meisten Praktiker nutzen SFT für spezifische Aufgaben und Instruction Tuning für Chat-Assistenten. Continued Pre-Training ist seltener, weil es riesige Mengen an Domänentext und viel Compute braucht.

---

Die 7-stufige Fine-Tuning-Pipeline

Fine-Tuning ist eine Pipeline, kein einzelner Befehl. Jede Stufe hat ihre eigenen Fehlerbilder, und wenn man eine überspringt, zeigt sich das meist später in einem schlechten Modell.

Jede Stufe baut auf der vorherigen auf:

1. Datenvorbereitung — Daten bereinigen, deduplizieren und formatieren (Schritt mit dem größten Hebel)
2. Modellauswahl — Das richtige Basismodell wählen und Gewichte laden
3. Trainings-Setup — Hardware, Hyperparameter und Optimierungsstrategie konfigurieren
4. Fine-Tuning — SFT-, DPO- oder ORPO-Training ausführen
5. Evaluation — Performance benchmarken und Qualität validieren
6. Deployment — Modell exportieren und bereitstellen
7. Monitoring — Performance verfolgen, warten und iterieren

[!WARNING] Daten sind das Fundament Stufe 1 (Datenvorbereitung) ist der Schritt mit dem größten Hebel. Algorithmen können keine Fehler ausbügeln, auf denen du trainiert hast. 500–1.000 sorgfältig kuratierte Beispiele schlagen in der Regel 50.000 verrauschte.

---

Stufe 1: Datenvorbereitung

Die meisten Fine-Tuning-Projekte scheitern hier, nicht beim Training. Moderne Datenvorbereitung ist mehr als ein regex über CSVs laufen zu lassen.

Die 5-stufige Datenpipeline

Teams, die das ernsthaft betreiben, setzen auf Tools wie DataTrove (Hugging Face) und Distilabel (Argilla) statt auf maßgeschneiderte Skripte.

1. Ingestion und Filterung

• Aktion: Ablehnungen („I cannot answer that“), kaputtes UTF-8 und Nicht-Zielsprachen entfernen.
• Tools: Trafilatura für Extraktion, FastText für Language ID.

2. PII-Bereinigung (Pflicht im Enterprise-Umfeld)

• Aktion: E-Mails, IP-Adressen und Telefonnummern vor dem Training erkennen und schwärzen.
• Tools: Microsoft Presidio oder scrubadub.
• Warum: auf Kunden-PII zu trainieren ist ein Sicherheitsvorfall mit Ansage.

3. Deduplizierung (MinHash LSH)

• Aktion: Near-Duplicates entfernen, damit das Modell sie nicht auswendig lernt.
• Tools: DataTrove verarbeitet Terabyte-Scale gut.

4. Synthetische Augmentierung

• Aktion: ein stärkeres Teacher-Modell (GPT-4o, DeepSeek-V3) verwenden, um Rohdaten in saubere Instruktions-Antwort-Paare umzuschreiben.
• Tools: Distilabel.
• Warum das wichtig ist: hier kommt in der Regel der größte Qualitätsschub her.

5. Formatierung

• Aktion: in ein Standardformat konvertieren (Alpaca oder ShareGPT).

Beispiele für Datenformate

Alpaca-Format (Instruction-Following):

{
    "instruction": "Summarize the following text.",
    "input": "The text to be summarized...",
    "output": "This is the summary."
}

ShareGPT/ChatML-Format (konversationell):

{
    "conversations": [
        { "from": "user", "value": "Hello, who are you?" },
        { "from": "assistant", "value": "I am a helpful AI assistant." }
    ]
}

Worauf es wirklich ankommt

• Qualität vor Quantität. 500–1.000 sorgfältig kuratierte Beispiele schlagen 50.000 verrauschte.
• Sauberkeit. Irrelevanten Text entfernen, Whitespace normalisieren, Formatierung konsistent halten.
• Balance. Die Abdeckung über Themen verteilen, damit das Modell nicht auf den dominanten Teil überfitten.
• PII-Bereinigung ist für jedes Produktionssystem nicht verhandelbar.

---

Stufe 2: Modellauswahl und Hardware

Die Wahl des Basismodells und das Verständnis der GPU-Untergrenze entscheiden darüber, was du realistisch trainieren kannst.

Hardware nach Modellgröße

Speicher ist die harte Untergrenze. Die folgenden Zahlen beziehen sich auf Training, nicht auf Inferenz.

Tier	Hardware-Konfiguration	Fähigkeit	Anwendungsfall
Enterprise-Standard	8x NVIDIA H100 (80GB)	Volles Fine-Tuning	Training von 70B-Modellen mit langem Kontext (32k+) bei maximaler Geschwindigkeit
Minimum Viable (Pro)	4x NVIDIA A100 (80GB)	QLoRA / LoRA	Fine-Tuning von Qwen 72B oder Llama 70B in 4-Bit
Lokale R&D	4x RTX 6000 Ada (48GB)	QLoRA	On-Prem-Workstation für Datenschutzanforderungen
Hobbyist/Indie	1-2x RTX 3090/4090 (24GB)	QLoRA	7B–32B-Modelle mit parameter-effizienten Methoden fine-tunen

[!TIP] Consumer-GPUs reichen weiter, als man denkt Mit QLoRA und Unsloth kann eine einzelne RTX 4090 (24GB) Modelle bis 32B Parameter fine-tunen. Die 3090 ist für 7B–13B-Training immer noch solide. Die 24GB-VRAM-Klasse reicht für die meisten ernsthaften Arbeiten außerhalb des Long-Context-Bereichs.

[!NOTE] Warum H100s Der Hauptgrund ist nicht VRAM, sondern FP8-Präzision. H100s unterstützen natives FP8-Training, was effektiven Speicher und Durchsatz gegenüber A100s ungefähr verdoppelt. Für 128k-Token-Kontexte ist FP8 auf H100s oft die einzige Möglichkeit, eine vernünftige Batch-Größe unterzubringen.

Speicher-Mathematik

Um ein 72B-Modell fine-zutunen, muss die GPU Folgendes halten:

• Modellgewichte in 16-Bit-Präzision: ~144 GB.
• Gradienten und Optimizer-State: je nach Optimizer etwa 2–3× die Modellgröße (AdamW liegt eher am oberen Ende).
• Aktivierungen: wachsen mit der Kontextlänge, z. B. 32k Tokens.

Deshalb ist QLoRA (4-Bit-Basis + LoRA-Adapter) für die meisten Teams die praktische Standardeinstellung.

---

Stufe 3: Trainingsmethoden (PEFT und LoRA)

Volles Fine-Tuning vs. PEFT

Volles Fine-Tuning (FFT) aktualisiert jedes Gewicht. Ein 7B-Modell in 16-Bit-Präzision braucht allein zum Trainieren rund 112GB VRAM. Das ist für die meisten Teams außer Reichweite.

Parameter-Efficient Fine-Tuning (PEFT) trainiert nur eine kleine Teilmenge der Parameter und friert den Rest ein. Dadurch wird die Mathematik deutlich freundlicher.

LoRA: der Standard

LoRA (Low-Rank Adaptation) ist die PEFT-Technik, die man zuerst lernen sollte. Die Grundidee: Die Gewichtsanpassungen, die man beim Fine-Tuning tatsächlich braucht, haben einen niedrigen „intrinsic rank“, daher braucht man keine Full-Rank-Updates.

Statt eine vollständige Gewichtsmatrix W (d × d) zu aktualisieren, lernt LoRA zwei kleinere Matrizen:

• A (d × r) — Down-Projection
• B (r × d) — Up-Projection

Das Update ist ΔW = B × A.

Bei Rank r=16 reduziert das die trainierbaren Parameter um ungefähr 10.000× und senkt den VRAM-Bedarf von 120GB auf 16GB.

PEFT-Methoden im Vergleich

Methode	Wie sie funktioniert	Speicherersparnis	Am besten geeignet für
LoRA	Low-Rank-Matrizen werden in eingefrorene Gewichte injiziert	~10x	Allgemeines Fine-Tuning
QLoRA	LoRA + 4-Bit-Quantisierung des Basismodells	~20x	Consumer-GPUs (16–24GB)
DoRA	LoRA mit Magnitude-/Direction-Dekomposition	~10x	Wenn LoRA an seine Performance-Grenze stößt
HFT	Friert pro Trainingsrunde die Hälfte der Parameter ein	~2x	Balance zwischen FFT und PEFT

Wann man was wählen sollte

• LoRA: hier anfangen. Schnell, speichereffizient, gut unterstützt.
• QLoRA: wenn du ein 70B-Modell auf Consumer-GPUs fine-tunen willst.
• DoRA: wenn die Qualitätsgrenze von LoRA sichtbar wird, besonders bei anspruchsvolleren Reasoning-Aufgaben.
• HFT: wenn LoRA nicht reicht, aber volles Fine-Tuning zu teuer ist.

DoRA: gewichtsdekomponiertes LoRA

DoRA (Weight-Decomposed Low-Rank Adaptation) zerlegt jedes vortrainierte Gewicht in Magnitude und Direction und trainiert sie getrennt. Damit schließt es in der Regel den Großteil der Lücke zwischen LoRA und vollem Fine-Tuning.

So funktioniert es:

Statt Gewichte als eine einzige Einheit zu behandeln, zerlegt DoRA vortrainierte Gewichte in zwei Komponenten:

1. Magnitude — ein trainierbarer Skalar pro Spalte, der die „Stärke“ steuert.
2. Direction — wird mit LoRA-Matrizen aktualisiert und steuert das „Was“.

Das Update ist W' = m × (V + B × A), wobei:

• m = Magnitude (trainierbar)
• V = Direction (W / ||W||)
• B × A = LoRA-Update zur Direction

Was du für diese zusätzliche Struktur bekommst:

• Ausdrucksstärkere Parameter-Updates ohne Effizienzverlust.
• Qualität näher am vollen Fine-Tuning.
• Die gleichen ~10× Speicherersparnis wie bei LoRA.
• Besonders sichtbar bei schwierigeren Reasoning-Aufgaben.

Half fine-tuning (HFT)

HFT liegt zwischen vollem Fine-Tuning und PEFT-Methoden:

• Methode: In jeder Runde wird die Hälfte der Modellparameter eingefroren, die andere Hälfte wird aktualisiert.
• Strategie: Welche Hälfte eingefroren wird, rotiert von Runde zu Runde.
• Warum es funktioniert: Die eingefrorene Hälfte bewahrt Vorwissen, während die aktive Hälfte neues Verhalten lernt.
• Wann man dazu greift: LoRA bringt dich nicht ans Ziel, aber volles Fine-Tuning ist zu teuer.

Adapter-Merging für Multi-Task-Learning

Statt ein monolithisches Modell für mehrere Aufgaben fine-zutunen, trainierst du pro Aufgabe einen eigenen kleinen Adapter und hältst das Basismodell eingefroren. Die Adapter kannst du dann zur Serving-Zeit zusammenführen.

Gängige Merging-Methoden:

1. Concatenation — Adapter-Parameter kombinieren und den effektiven Rank erhöhen. Schnell und einfach.
2. Linearkombination — gewichtete Summe von Adaptern. Gibt dir Stellschrauben.
3. SVD — Matrixzerlegung für das Merging. Flexibler, aber langsamer.

Beispiel: ein Adapter für Zusammenfassungen, ein anderer für Übersetzung, zusammengeführt zu einem einzigen Multi-Task-Modell.

---

Stufe 4: Fine-Tuning und Preference Alignment

Manchmal liefert SFT die richtige Antwort, aber im falschen Stil: zu ausführlich, im falschen Ton, gelegentlich unsicher. Preference Alignment behebt genau das.

RLHF mit PPO (der ältere Ansatz)

Das ursprüngliche Rezept war eine dreistufige Pipeline:

1. SFT — die Aufgabe lernen.
2. Reward-Modell — auf menschlichen Präferenzen trainieren (chosen vs rejected).
3. PPO (Proximal Policy Optimization) — Reinforcement Learning zur Optimierung der Policy.

Die Schmerzpunkte:

• Kompliziert in Implementierung und Wartung.
• Teuer — du trainierst mehrere Modelle.
• Empfindlich gegenüber Hyperparametern und anfällig für instabiles Training.

DPO (der einfachere Nachfolger)

DPO (Direct Preference Optimization) verzichtet auf ein explizites Reward-Modell und die RL-Schleife. Es optimiert weiterhin das RLHF-Ziel (Reward-Maximierung mit einer KL-Divergenz-Beschränkung), tut das aber als reparametrisiertes Supervised-Learning-Problem statt mit Reinforcement Learning:

{
    "prompt": "Explain quantum computing",
    "chosen": "Quantum computing uses qubits...",   # Preferred response
    "rejected": "Well, it's complicated..."        # Non-preferred response
}

Was du bekommst:

• Einfacherer Codepfad (kein separates Reward-Modell, keine RL-Schleife).
• Stabileres Training, weil es schlicht Supervised Learning ist.
• Geringere Compute-Kosten.

DPO hat den Großteil des praktischen Wettkampfs gewonnen, aber PPO ist nicht komplett abgelöst:

• DPO kann in manchen Setups verzerrte Lösungen erzeugen.
• Ein gut abgestimmtes PPO liefert bei schwierigeren Aufgaben wie Code-Generierung weiterhin State-of-the-Art-Ergebnisse.
• Das explizite Reward-Signal von PPO gibt feinere Steuerung für spezialisierte Aufgaben.

Wenn du heute frisch startest, würdest du zuerst zu DPO (oder ORPO unten) greifen und nur dann auf PPO zurückfallen, wenn es einen echten Grund dafür gibt.

ORPO (einstufig)

ORPO (Odds-Ratio Preference Optimization) fasst SFT und Preference Alignment in einem einzigen Trainingslauf zusammen. Für die meisten Teams ist das eine große Vereinfachung.

So funktioniert es: ORPO nutzt einen kombinierten Loss, der zwei Dinge gleichzeitig tut:

1. Maximiert die Likelihood der gewählten Antwort (die Aufgabe lernen).
2. Bestraft die abgelehnte Antwort mit einem Odds-Ratio-Term (Präferenzen lernen).

Wichtige Hyperparameter:

from trl import ORPOConfig

config = ORPOConfig(
    learning_rate=8e-6,  # Very low, as recommended by the ORPO paper
    beta=0.1,            # Controls strength of preference penalty
    # ... other params
)

• Learning Rate: sehr niedrig bleiben (8e-6 im ORPO-Paper).
• Beta: steuert, wie stark die Präferenzstrafe wirkt (0.1 ist ein typischer Wert).

Was du mit ORPO bekommst:

• Eine Trainingsstufe statt zwei.
• Kein Reward-Modell.
• Weniger Hyperparameter als bei DPO.
• Der kürzeste Weg vom Rohmodell zum ausgerichteten Modell.

Wann man was wählen sollte:

• ORPO: der Standard für die meisten Anwendungsfälle.
• DPO: wenn du mehr Kontrolle über Alignment willst.
• PPO: wenn du ein explizites Reward-Signal brauchst, etwa für Code-Generierung.

---

Fine-Tuning-Frameworks

Das Ökosystem hat sich auf vier Hauptwerkzeuge eingependelt.

Unsloth — Geschwindigkeit und Speichereffizienz

Unsloth umhüllt HuggingFaces trl und transformers und legt eine zusätzliche Optimierungsschicht darüber:

• Eigene Triton-GPU-Kernels für Attention, RoPE und Cross-Entropy, die PyTorch-Overhead umgehen.
• Speichereffiziente Backpropagation, die Aktivierungen im Backward-Pass neu berechnet, statt sie im Speicher zu halten.
• Fused Operations, die mehrere Schritte (Layer Norm + Linear und ähnliche) in einzelne GPU-Calls zusammenfassen.
• 4-Bit-Quantisierung direkt in den QLoRA-Pfad integriert, mit optimierter Dequantisierung.

[!IMPORTANT] Die Import-Reihenfolge ist wichtig Unsloth patched HuggingFace-Pakete zur Importzeit. Importiere und initialisiere FastLanguageModel aus unsloth bevor du etwas aus trl oder transformers importierst, sonst greifen die Patches nicht.

# ✅ Correct order
from unsloth import FastLanguageModel  # Must be first!
from trl import SFTTrainer
from transformers import TrainingArguments

# ❌ Wrong order - will fail
from trl import SFTTrainer
from unsloth import FastLanguageModel  # Too late!

Am besten geeignet für: Single-GPU-Training, Prototyping, Colab-Notebooks, alle, die auf die GPU-Kosten achten.

Der größte Gewinn: Diese benutzerdefinierten Triton-Kernels machen es 2–5× schneller als den Standardpfad von HuggingFace.

Axolotl — konfigurationsgetriebene Produktion

# config.yaml - no code required
base_model: meta-llama/Meta-Llama-3-8B
adapter: qlora
lora_r: 32
lora_alpha: 16
datasets:
    - path: data/my_data.jsonl
      type: alpaca
sample_packing: true

Ausführen mit: accelerate launch -m axolotl.cli.train config.yaml

Am besten geeignet für: Produktionspipelines, Multi-GPU-Cluster, reproduzierbare Experimente.

Der größte Gewinn: Konfigurationen sind YAML-Dateien, also gut versionierbar und leicht teilbar.

Framework-Vergleich

Merkmal	Unsloth	Axolotl	TRL	Torchtune
Stärke	Geschwindigkeit & Effizienz	Multi-GPU-Skalierung	Ökosystem	PyTorch-nativ
Geschwindigkeit	Am schnellsten (2-5x)	Hoch	Mittel	Hoch
Multi-GPU	Wachsend	Exzellent	Gut	Exzellent
Konfiguration	Python	YAML	Python	Python
Am besten geeignet für	Lokal/Colab	Cluster	Research	PyTorch-Puristen

---

Praktische Demo: Fine-Tuning mit Unsloth

Hier ist ein vollständiges Beispiel aus meinem Repository unsloth-finetune-demo. Die Demo fine-tunt Nemotron-Nano für Function Calling.

Schnellstart

# Clone and setup
git clone https://github.com/slavadubrov/unsloth-finetune-demo.git
cd unsloth-finetune-demo

# Install with uv (recommended)
uv sync

# Run fine-tuning (quick test)
uv run finetune --max-samples 1000

Konfiguration

Die interessanten Teile liegen in config.py:

# Model & Dataset
MODEL_NAME = "nvidia/Llama-3.1-Nemotron-Nano-4B-v1.1"  # 4B params, 128K context
DATASET_NAME = "glaiveai/glaive-function-calling-v2"   # 113K examples

# LoRA Configuration
LORA_R = 16        # Rank - higher = smarter but more VRAM
LORA_ALPHA = 32    # Scaling factor - usually 2x LORA_R
MAX_SEQ_LENGTH = 4096

# Target all linear layers for best quality
LORA_TARGET_MODULES = [
    "q_proj", "k_proj", "v_proj", "o_proj",
    "gate_proj", "up_proj", "down_proj",
]

[!NOTE] Das Alpha-zu-Rank-Verhältnis Eine gängige Faustregel: setze alpha = 2 × rank (z. B. rank=16, alpha=32). Das gibt stärkere Weight-Updates, ohne das Training zu destabilisieren.

Zentraler Trainingscode

from unsloth import FastLanguageModel
from trl import SFTTrainer
from transformers import TrainingArguments

# Load model with 4-bit quantization
model, tokenizer = FastLanguageModel.from_pretrained(
    model_name="nvidia/Llama-3.1-Nemotron-Nano-4B-v1.1",
    max_seq_length=4096,
    load_in_4bit=True,
)

# Add LoRA adapters
model = FastLanguageModel.get_peft_model(
    model,
    r=16,
    lora_alpha=32,
    target_modules=["q_proj", "k_proj", "v_proj", "o_proj",
                    "gate_proj", "up_proj", "down_proj"],
    use_gradient_checkpointing="unsloth",  # Big memory savings
)

# Train with SFTTrainer
trainer = SFTTrainer(
    model=model,
    tokenizer=tokenizer,
    train_dataset=dataset,
    max_seq_length=4096,
    packing=True,  # Key for efficiency!
    args=TrainingArguments(
        per_device_train_batch_size=2,
        gradient_accumulation_steps=4,
        learning_rate=2e-4,
        num_train_epochs=3,
        bf16=True,
    ),
)
trainer.train()

---

Fine-Tuning mit Axolotl

[!NOTE] Demo folgt Ich arbeite an einer praktischen Axolotl-Demo. Bis dahin ist der Accelerate n-D Parallelism Guide von Hugging Face eine gute Referenz für Multi-GPU-Trainingsstrategien.

Für Produktions- und Multi-GPU-Setups macht Axolotls config-first-Ansatz den Workflow reproduzierbar:

# axolotl_config.yaml
base_model: meta-llama/Meta-Llama-3-8B
model_type: LlamaForCausalLM

# QLoRA configuration
load_in_4bit: true
adapter: qlora
lora_r: 32
lora_alpha: 16
lora_dropout: 0.05
lora_target_modules:
    - q_proj
    - k_proj
    - v_proj
    - o_proj
    - gate_proj
    - up_proj
    - down_proj

# Dataset
datasets:
    - path: data/training_data.jsonl
      type: alpaca

# Training settings
sequence_len: 4096
sample_packing: true # Critical for speed!
micro_batch_size: 2
gradient_accumulation_steps: 4
learning_rate: 0.0002
num_epochs: 3

# Hardware
bf16: true
flash_attention: true

Training ausführen:

accelerate launch -m axolotl.cli.train axolotl_config.yaml

---

Stufe 5: Evaluation

Training ist der einfache Teil. Herauszufinden, ob das Modell tatsächlich besser geworden ist, ist schwieriger — und du brauchst Antworten, bevor du auslieferst.

Automatisierte Benchmarks

Verwende lm-evaluation-harness für standardisierte Tests:

lm_eval --model hf \
    --model_args pretrained=./outputs/merged-model \
    --tasks hellaswag,arc_easy,mmlu \
    --batch_size 8

LLM-as-judge

Für subjektive Qualität lässt du ein größeres Modell die Ausgaben bewerten:

judge_prompt = """
Rate this response from 1-5 on:
- Relevance
- Accuracy
- Formatting

Response: {model_output}
Expected: {ground_truth}
"""

Domänenspezifische Evaluation

Halte ein Testset mit echten Beispielen aus deinem tatsächlichen Anwendungsfall zurück. Das ist die Evaluation, die zählt. Generische Benchmarks sagen dir nicht, ob dein Function-Calling-Modell funktioniert.

---

Stufe 6: Deployment und Ausgabeformate

Nach dem Training hast du drei Möglichkeiten, das Modell zu exportieren:

1. LoRA-Adapter (Standard)

uv run finetune  # Saves ~100-500MB adapter

• Größe: ~100–500 MB.
• Am besten geeignet für: Entwicklung, Tests, mehrere Adapter auf einem Basismodell.
• Bonus: Du kannst Adapter austauschen, ohne das Basismodell erneut herunterzuladen.

2. Gemergtes Modell

uv run finetune --merge  # Creates standalone ~8-16GB model

• Größe: ~8–16 GB (volle 16-Bit-Gewichte).
• Am besten geeignet für: Teilen auf HuggingFace, vLLM-Serving, einfaches Deployment.
• Trade-off: größeres Artefakt, aber keine separate Basismodell-Abhängigkeit.

3. GGUF-Format

uv run finetune --gguf q4_k_m  # Creates ~2-4GB quantized model

• Größe: ~2–4 GB (Q4_K_M-Quantisierung).
• Am besten geeignet für: CPU-Inferenz, Ollama, llama.cpp, Edge-Deployment.
• Optionen: q4_k_m (ausgewogen), q5_k_m (höhere Qualität), q8_0 (nahezu verlustfrei).

---

Stufe 7: Serving und Monitoring

Mit vLLM (Produktion)

# Requires merged model format
vllm serve ./outputs/unsloth-nemotron-function-calling-merged \
    --host 0.0.0.0 \
    --port 8000 \
    --max-model-len 4096

Abfrage über die OpenAI-kompatible API:

from openai import OpenAI

client = OpenAI(base_url="http://localhost:8000/v1", api_key="dummy")
response = client.chat.completions.create(
    model="unsloth-nemotron-function-calling-merged",
    messages=[{"role": "user", "content": "Book a flight to Tokyo"}]
)

Mit Ollama (lokal)

# Create Modelfile
echo 'FROM ./outputs/unsloth-nemotron-function-calling-gguf/model-q4_k_m.gguf' > Modelfile

# Import to Ollama
ollama create my-function-model -f Modelfile

# Run
ollama run my-function-model

Mit llama.cpp (CPU)

./main -m ./outputs/model-q4_k_m.gguf \
    -p "What's the weather in Tokyo?" \
    --ctx-size 4096

---

Zentrale Erkenntnisse

1. Gehe die Pipeline vollständig durch. Der Hebel liegt in der Datenvorbereitung, nicht im Training.
2. Greife nicht standardmäßig zu Fine-Tuning. Probiere Prompting, dann SGR, dann RAG. Fine-Tune nur, wenn dich das nicht ans Ziel bringt.
3. Nimm Datenvorbereitung ernst. Nutze moderne Pipelines (DataTrove, Distilabel) und bereinige PII vor jedem Enterprise-Rollout.
4. Setze standardmäßig auf QLoRA, außer du hast 8× H100s herumstehen. So fine-tunt man 70B-Modelle auf Consumer- oder A100-Hardware.
5. Nutze ORPO für Alignment. Einstufiges Training ist einfacher und meist schnell genug.
6. Greife zu DoRA, wenn LoRA bei schwierigeren Reasoning-Aufgaben an seine Qualitätsgrenze stößt.
7. Aktiviere Sample Packing. Das ist der größte Gewinn bei der Trainingszeit.
8. Unsloth für Prototyping, Axolotl für Produktion.
9. Exportiere nach GGUF, wenn das Deployment-Ziel lokal oder am Edge ist.

---

Referenzen

Papers & Forschung

• LoRA: Low-Rank Adaptation of Large Language Models
• QLoRA: Efficient Finetuning of Quantized LLMs
• DoRA: Weight-Decomposed Low-Rank Adaptation
• DPO: Direct Preference Optimization
• ORPO: Odds Ratio Preference Optimization
• PPO: Proximal Policy Optimization Algorithms — OpenAI, 2017
• HFT: Half Fine-Tuning for Large Language Models — Abschwächung von catastrophic forgetting

Tools zur Datenverarbeitung

• DataTrove — Hugging Face Datenverarbeitung im großen Maßstab
• Distilabel — Synthetische Datengenerierung (Argilla)
• Trafilatura — Webtext-Extraktion und Crawling
• FastText — Facebook AI Sprachidentifikation (unterstützt 217 Sprachen)
• Microsoft Presidio — PII-Erkennung und Anonymisierung
• scrubadub — Python-Bibliothek zur PII-Entfernung

Schema-Guided Reasoning (SGR)

• xgrammar — Constrained Decoding mit FSMs
• outlines — Strukturierte Generierung für LLMs

Trainings-Frameworks

• Unsloth — Champion für Geschwindigkeit & Effizienz (2-5x schneller)
• Axolotl — Konfigurationsgetriebenes Multi-GPU-Training
• TRL (Transformer Reinforcement Learning) — Hugging Face RL-Training
• Torchtune — PyTorch-native Fine-Tuning-Bibliothek

Inferenz & Deployment

• vLLM — LLM-Serving-Engine mit hohem Durchsatz
• Ollama — Lokaler LLM-Runner für Mac/Windows/Linux
• llama.cpp — CPU/GPU-Inferenz mit GGUF-Format

Evaluation

• lm-evaluation-harness — Standardisiertes LLM-Benchmarking von EleutherAI

Leitfäden & Ressourcen

• Demo Repository — Praktisches Fine-Tuning-Beispiel
• LLM Fine-Tuning. Theoretical Intuition and Practical Implementation — NotebookLM-Forschungsnotebook
• Accelerate n-D Parallelism Guide — Hugging Face Strategien für Multi-GPU-Training