2026-01-04 · Aktualisiert 2026-07-15

[!NOTE] Automatische Übersetzung Dieser Artikel wurde automatisch aus der englischen Originalversion übersetzt.

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

Die meisten Fine-Tuning-Fehler sind Entscheidungsfehler. Ein Team trainiert zunächst, bevor es nachweist, dass Prompting, Retrieval oder Constrained Decoding das Problem nicht lösen können; es bewertet die Ergebnisse anhand der Trainingsdatenmenge oder stellt nach dem Training fest, dass das erzeugte Modul schwer zu nutzen ist.

Dieser Leitfaden betrachtet die Anpassung als ein Experiment mit einer definierten Abbruchbedingung. Er beginnt mit der Entscheidungsgrenze und verfolgt anschließend einen Ablauf über die Daten, LoRA bzw. QLoRA, die spezifische Bewertung für die jeweilige Aufgabe, die Exportierung sowie Serving.

TL;DR: Führen Sie eine Feinabstimmung durch, sobald eine gemessene Baseline zeigt, dass eine Änderung des Verhaltens von Model einen Aufwand für ein Weight-Update rechtfertigt. Wenden Sie Retrieval bei der Anpassung von Fakten sowie Constrained Decoding bei der Anpassung der Syntax an. Beginnen Sie mit LoRA, wenn die zugrundeliegende Model-Struktur noch ausreichend flexibel ist; nutzen Sie hingegen QLoRA, wenn begrenzte, gefrorene Weight-Speichermengen das Limit darstellen. Bereiten Sie vor dem Training ein Evaluationsset vor, vergleichen Sie es mit der unangepassten Baseline und wählen Sie schließlich das geeignete Deployment-Ergebnis, bevor Sie sich für eine Methode entscheiden.

Sollte man überhaupt feintunen?

Bevor Sie GPU Stunden investieren, entscheiden Sie zunächst, ob Fine-Tuning das geeignete Werkzeug für das vorliegende Problem ist.

Fine-Tuning im Vergleich zu RAG

Fine-Tuning kann die Art und Weise verändern, wie ein Model Sprache aus einem bestimmten Domänenbereich verwendet, stellt jedoch ein unzureichendes Mechanismus dar, um Fakten zu aktualisieren, die sich ändern oder zitiert werden müssen. Retrieval sowie Fine-Tuning adressieren unterschiedliche Aspekte dieses Problems und sollten in der Regel in derselben Systemarchitektur integriert werden.

Ingenieurwesen von Fine-Tuning versus Prompt

Moderne LLMs reagieren gut auf klare Prompts-Anweisungen sowie entsprechende Beispiele. Prüfen Sie diese Optionen sorgfältig, bevor Sie in Fine-Tuning investieren.

[!TIP] Versuchen Sie zunächst das Prompting Beginnen Sie mit einem Prompt sowie repräsentativen Beispielen. Falls nur die Ausgabesyntax unzuverlässig ist, fügen Sie vor der Änderung des Weights einen Constrained Decoding hinzu.

Fine-Tuning im Vergleich zu Constrained Decoding

Bibliotheken wie zum Beispiel xgrammar und outlines Die Generierung wird auf einen JSON schema, eine reguläre Ausdrucksform oder eine Grammatik beschränkt. Je nach Art der Beschränkung sowie dem Backend wird entweder ein Automat oder eine Grammatik erstellt, um ungültige folgende Tokens zu blockieren. Ein Update des Weight ist nicht erforderlich.

Dies garantiert die Verwendung der unterstützten Ausgabssprache – nicht jedoch, dass die Werte wahr, vollständig oder semantisch angemessen sind. Eine syntaktisch korrekte Funktionsaufrufung kann dennoch eine fehlerhafte Kunden-ID enthalten.

Eine praktische Vorgehensweise:

1. Beginnen Sie mit Prompting und Few-Shot-Beispielen für die grundlegende Formatierung.
2. Fügen Sie Constrained Decoding hinzu.xgrammar oder outlines) wenn die Syntax inkonsistent ist.
3. Führen Sie eine Feinabstimmung nur durch, wenn Sie Verhaltensänderungen benötigen, die durch ein Schema nicht vorgeschrieben werden können.

Schnellreferenz: Zuordnung von Problemen zu Lösungen

Den wirtschaftlichen Nutzen messbar machen

Fine-Tuning kann wiederkehrende Prompt Tokens verringern oder es ermöglichen, dass ein kleinerer Model das Ziel erreicht, wobei keiner dieser Einsparungen automatisch erfolgt. Berechnen Sie den Break-Even-Punkt anhand Ihrer eigenen Traffic-Daten und Preise:

[ \text{Gewinnschwelle-Anfragen} = \frac{\text{Kosten für Training + Bewertung + Deployment}} {\text{Basiskosten pro Anfrage} - \text{Anpassungskosten pro Anfrage}} ]

Falls der Nenner klein ist, negativ ist oder auf einer noch nicht bewiesenen Qualitätsannahme beruht, verfügt das Projekt derzeit noch nicht über eine wirtschaftliche Rechtfertigung.

[!TIP] Die hybride Konfiguration Eine gängige Architektur besteht aus einem für die jeweilige Aufgabe angepassten, kleineren Model sowie Retrieval zur Aktualisierung von Fakten. Betrachten Sie den größeren, per Prompt gesteuerten Model als Grundlage und behalten Sie den kleineren Model nur dann bei, wenn er die gleichen, auf die spezifische Aufgabe zugeschnittenen Qualitäts- und Sicherheitsschwellenwerte erfüllt.

Arten von Fine-Tuning

Es gibt drei Hauptformen, die Fine-Tuning annehmen kann. Sie unterscheiden sich dadurch, welche Art von Daten sie benötigen und was sie den Model beibringen.

1. Fortgesetztes Vortrainieren (unüberwacht)

Man trainiert den Basisspeicher. Model bei mehr Rohtext ohne Labels. Es setzt die Verarbeitung fort.Token Die Vorhersage erfolgt genauso wie während des ursprünglichen Vortrainings.

Wann es einzusetzen ist:

• Das Domänenvokabular enthält Begriffe, die der Basis-Model-Modell noch nie begegnet sind (medizinische, rechtliche oder interne Codebasen).
• Sie verfügen über große Mengen an Domänentexten, besitzen jedoch keine gelabelten (Eingangs-, Ausgangs-)Paare.
• Der Basis-Model-Modell fällt es schwer, domänenspezifische Fachbegriffe korrekt zu verstehen.

Beispiel: Training anhand von Millionen von klinischen Notizen, damit der Model medizinische Abkürzungen, Arzneimittelnamen sowie klinische Workflows erkennt.

2. Überwachtes Fine-Tuning (SFT)

SFT wird anhand von beschrifteten (Eingabe-, Ausgabepaarungen) trainiert. Dabei zeigt man dem Model die exakte Ausgabe, die man für jede Eingabe erwartet.

Wann es eingesetzt werden sollte:

• Sie haben eine spezifische Aufgabe mit einem sauberen Eingab-/Ausgabeformat.
• Sie verfügen über qualitativ annotierte Daten – auch in geringen Mengen.
• Sie benötigen ein vorhersagbares Verhalten für Eingaben einer bekannten Struktur.

Beispiel: Training mit Paaren aus (Beschreibung der SQL-Abfrage, SQL-Code) für Text-zu-SQL.

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

3. Anweisungstuning

Instruction Tuning ist ein Spezialfall von SFT, der darauf abzielt, Models dazu zu bringen, einer Vielzahl von Anweisungen in natürlicher Sprache zu folgen. Die Trainingsdaten bestehen aus (Anweisung, Antwort)-Paaren aus verschiedenen Aufgabenbereichen.

Wann es einzusetzen ist:

• Sie möchten einen Allzweck-Assistenten (ähnlich wie ChatGPT oder Claude).
• Der Model muss mit vielfältigen, offenen Anfragen umgehen können.
• Sie entwickeln eine Chat-Schnittstelle.

Beispiel: Training mit Tausenden verschiedener Anweisungen wie „Zusammenfassen Sie diesen Artikel“, „Schreiben Sie ein Gedicht über X“ oder „Erklären Sie Y in einfachen Worten“.

Vergleich

[!NOTE] Was die Praxis tatsächlich vornimmt SFT sowie die Anpassung von Instruktionen nutzen dasselbe nächste Token-Ziel; der Unterschied liegt in der Breite und Struktur des Dataset. Ein weiteres Vortrainieren stellt ein eigenständiges Experiment dar, dem Tests sowohl hinsichtlich fachspezifischer Verbesserungen als auch bezüglich einer Regression der allgemeinen Fähigkeiten folgen sollten.

Der 7-stufige Fine-Tuning Pipeline

Fine-Tuning ist ein Pipeline und keine einzelne Anweisung. Jede Phase weist eigene Fehlermöglichkeiten auf, wobei das Überspringen einer Phase in der Regel später zu einem fehlerhaften Model führt.

Jede Phase baut auf der vorherigen auf:

1. Datenvorbereitung – Definieren Sie die Bewertungseinheit, teilen Sie die Daten auf und reinigen sowie formatieren Sie sie anschließend.
2. Model-Auswahl – Wählen Sie den geeigneten Basis-Model aus und laden Sie den Weights.
3. Trainingskonfiguration – Konfigurieren Sie die Hardware, Hyperparameter sowie die Optimierungsstrategie.
4. Fine-Tuning – Führen Sie SFT, DPO oder ein ORPO-Training durch.
5. Bewertung – Überprüfen Sie die Leistung von Benchmark und validieren Sie die Qualität.
6. Deployment – Exportieren und bereitstellen Sie Ihren Model.
7. Überwachung – Verfolgen Sie die Leistung, warten Sie das System und führen Sie Iterationen durch.

[!WARNUNG] Daten bilden die Grundlage Das Trainieren führt zu systematischen Fehlern in den Beispielen. Überprüfen Sie vor dem Aufwand für Optimierungsversuche die Etiketten, Datenlecks, Abdeckung sowie die Konformität mit den Richtlinien.

Phase 1: Datenvorbereitung

Die meisten Fine-Tuning-Projekte scheitern genau an diesem Punkt und nicht beim Training. Die moderne Datenvorbereitung umfasst weitaus mehr als nur das Durchlaufen von Regulären Ausdrücken auf CSV-Dateien.

Die 5-stufige Datenverarbeitung Pipeline

Tools wie DataTrove und Distilabel können bei großem Umfang unterstützen, doch die Auswahl des Pipeline sollte anhand der Fehlertaxonomie sowie des Datenvertrags erfolgen und nicht von einer bevorzugten Tool-Lösung bestimmt werden.

1. Eingabe und Filterung

• Aktion: Eliminierung von Ablehnungsantworten wie „Ich kann darauf nicht antworten“, fehlerhaften UTF-8-Daten sowie Inhalten in Nicht-Zielsprachen.
• Werkzeuge: Trafilatura zur Extraktion der Daten sowie FastText zur Bestimmung der Sprachidentifikation.

2. Richtlinie zu sensiblen Daten

• Aktion: Bestimmen, welche Informationen der Model erlernen darf, und anschließend nach Bedarf persönliche sowie vertrauliche Felder entfernen, tokenisieren oder ausschließen.
• Werkzeuge: Microsoft Presidio oder scrubadub.
• Grund: Ein Detektor stellt lediglich eine Kontrollmaßnahme dar; weiterhin gelten Anforderungen hinsichtlich Herkunft der Daten, Einwilligung der Nutzer, Aufbewahrungsfristen, Zugriffsrechten sowie Löschvorgängen.

3. Deduplizierung (MinHash LSH)

• Aktion: Nahezu identische Einträge entfernen, damit der Model sie nicht speichert.
• Werkzeuge: DataTrove bewältigt die Verarbeitung von Datenmengen im Terabyte-Bereich sehr gut.

4. Synthetische Erweiterung, falls erforderlich

• Aktion: Verwendung eines leistungsstärkeren Lehrmodells Model (GPT-4o, DeepSeek-V3), um Rohdaten in saubere Instruction-Response-Paare umzuwandeln.
• Werkzeuge: Distilabel.
• Validierung: Auswertung von Beispielausgaben des Lehrmodells unter Anwendung derselben Bewertungskriterien wie bei menschlichen Labels sowie getrennte Bewertung von synthetisch erzeugten und menschlich verfassten Datensätzen.

5. Formatierung

• Aktion: In ein Standardformat umwandeln (Alpaca oder ShareGPT).

Beispiele für Datensatzformate

Alpaca-Format (Anweisungsbefolgung):

{
    "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." }
    ]
}

Was tatsächlich von Bedeutung ist

• Abdeckung vor Menge. Fügen Sie Beispiele hinzu, die unterschiedliche Fehlermuster darstellen, anstatt wiederholt nur die einfachen, häufig vorkommenden Fälle zu verwenden.
• Sauberkeit. Entfernen Sie irrelevante Texte, normalisieren Sie die Leerzeichen und halten Sie die Formatierung konstant.
• Ausgewogenheit. Bewahren Sie wichtige, seltene Fälle bei und berichten Sie über die Leistung pro Segment.
• Trennung. Teilen Sie die Daten nach Quelle, Benutzer, Dokument oder Zeit auf, um zu verhindern, dass zufällige Aufteilungen nahezu identische Einträge durchsickern lassen.
• Herkunft. Erfassen Sie für jede Dataset-Version die Quelle, Lizenz oder Genehmigung, die Veränderungshistorie sowie den Löschweg.

Phase 2: Auswahl von Model und Hardware

Die Auswahl der Basis Model sowie das Verständnis der GPU-Begrenzung bestimmen, was tatsächlich trainiert werden kann.

Beginnen Sie mit der kleinsten Basis Model, die bereits die unverzichtbaren Grundüberprüfungen bestehen lässt. Überprüfen Sie:

• Lizenz- und Verteilungsbedingungen für das geplante Produkt;
• Sprache, Anwendungsbereich, Tool-Nutzung sowie Sicherheitsverhalten vor der Anpassung;
• Kompatibilität von Tokenizer und Chat-Vorlagen mit Dataset;
• maximale Kontextlänge sowie Verhalten bei Trunkierung, wie es in realen Beispielen erforderlich ist;
• Unterstützung sowohl im Trainings-Framework- als auch im Ziel-Serving-Engine.

Fine-Tuning stellt einen Anpassungsschritt dar und keine Reparatur einer ungeeigneten Basis. Sollten die Funktionalitäten des Model die vom Dataset abgedeckten Anforderungen nicht erfüllen, wählen Sie vor dem Sammeln weiterer Epochen eine andere Basis aus.

Größenordnung der Ausführung festlegen – nicht die Marketingstufe

es gibt keinen dauerhaften „Model Größe → GPU” Tabelle. Die Spitzenwerte des Arbeitsspeicherverbrauchs ändern sich mit Weight Präzision, Optimierer, Anzahl der trainierbaren Parameter, Sequenzlänge, Größe des Mikrobatches Activation Checkpointing Attention Implementierung und Framework Overhead. Beginnen Sie mit einer Schätzung des Speicherverbrauchs und führen Sie anschließend einen kurzen Smoke-Test mit maximaler Länge auf dem genauen Stack aus.

Der ursprüngliche Artikel zu QLoRA passte in seiner spezifischen Konfiguration einen 65B großen LLaMA Model auf eine 48 GB große GPU. Dieses Ergebnis stellt eine nützliche Obergrenze dar, nicht jedoch eine Garantie dafür, dass jede aktuelle 70B-Architektur, jede Kontextlänge, Kernel sowie jeder Trainingsalgorithmus auf derselben Hardware untergebracht werden können.

Speichermathematik

Für einen Model mit (P) Parametern benötigen allein die Weights etwa (2P) Bytes im BF16/FP16 oder (0{,}5P) Bytes bei vier Bit pro Byte, noch bevor Metadaten nach Quantization sowie Puffer nach Runtime hinzukommen. Ein vollständiger Trainingsprozess im Adam-Stil fügt außerdem Gradienten, Optimiererzustände sowie oft Master-Modelle mit höherer Präzision nach Weights hinzu. LoRA vermeidet den größten Teil des Speichers für lernbare Zustände; darüber hinaus verringert QLoRA den Speicherbedarf der eingefrorenen Basis-Weight-Komponenten. Bei sehr langen Sequenzen kann Activations dennoch dominieren.

Verwenden Sie diesen Workflow:

1. Wählen Sie die längste Sequenz sowie den maximalen Mikrobatch aus, den Sie unterstützen müssen.
2. Schätzen Sie Weights sowie den Trainierzustand ab und lassen Sie dabei Puffer für Activations und Kernels frei.
3. Führen Sie einen Vorwärts-/Rückwärts-Schritt bei der maximal möglichen Länge aus.
4. Erfassen Sie den Höchstwert der zugewiesenen sowie reservierten Speichermenge.
5. Erst danach skalieren Sie die Größe des Batches, die Anzahl der Prozessorkerne, die Länge der Sequenz oder die Anzahl von GPU.

Phase 3: Trainingsmethoden (PEFT und LoRA)

Vollständiger Fine-Tuning gegen PEFT

Die vollständige Fine-Tuning (FFT)-Berechnung erfolgt alle Weight, wodurch Gradienten sowie der Zustand des Optimizers mit dem gesamten Model skaliert werden. Der Höchstwert lässt sich nicht allein anhand der Anzahl der Parameter bestimmen, liegt aber deutlich über dem Speicherbedarf, der zur Laden der Weights für Inference erforderlich ist.

Parameter-effizientes Fine-Tuning (PEFT) trainiert lediglich einen kleinen Teil der Parameter und friert den Rest ein. Dadurch wird die mathematische Formulierung erheblich vereinfacht.

LoRA: der Ausgangspunkt

LoRA (Low-Rank Adaptation) führt dazu, dass eine vortrainierte Matrix festgelegt wird und ihre erlernte Aktualisierung durch zwei kleinere Matrizen dargestellt wird. Die ursprüngliche Veröffentlichung begründet dieses Vorgehen mit der Hypothese, dass nützliche Anpassungsaktualisierungen einen niedrigen intrinsischen Rang aufweisen.

Für eine gefrorene Matrix (W0 \in \mathbb{R}^{d{out} \times d_{in}}) lernt LoRA Folgendes:

• (A \in \mathbb{R}^{r \times d_{in}})
• (B \in \mathbb{R}^{d_{out} \times r})

Die angepasste Schicht ist:

[ W’ = W_0 + \frac{\alpha}{r}BA ]

Der Adapter weist (r(d*{in}+d*{out})) trainierbare Parameter auf, anstelle von (d*{in}d*{out}) für diese Matrix. Bei einer quadratischen Matrix mit 4.096 Elementen und Rang 16 bedeutet das eine Reduktion der Dimensionen um den Faktor 128 – und nicht um den Faktor 10.000 wie bei einer beliebigen Model. Der in der LoRA-Veröffentlichung angegebene Faktor von 10.000 bezog sich auf eine spezifische Konfiguration von GPT-3 mit 175 Milliarden Parametern, bei der ausgewählte Matrizen adaptiert wurden.

Vergleich der PEFT-Methoden

Wann welchen wählen

• LoRA: Hier beginnt der Prozess. Schnell, memorieneffizient und gut unterstützt.
• QLoRA: Wenn derselbe LoRA-Versuch aufgrund einer festgelegten Basis Weights nicht anwendbar ist.
• DoRA: Nachdem ein direkter LoRA-Vergleich einen nützlichen Vorteil zeigt.
• Vollständige Fine-Tuning-Auswertung: Erst nachdem PEFT abgeschlossen ist, handelt es sich um eine bewertete Bottleneck-Werte statt um bloße Annahmen.

DoRA: Weight-dekomponierte LoRA

DoRA (Weight – zerlegte Anpassung niedriger Rangordnung) trennt die Länge jedes Weight-Vektors von seiner Richtung. Dabei wird eine LoRA-Aktualisierung auf den Richtungskomponenten angewendet, während die Länge des Vektors separat ermittelt wird.

Wie es funktioniert:

Anstatt Weights als einzige Einheit zu behandeln, zerlegt DoRA die vortrainierten Weights in zwei Komponenten:

1. Größe – ein trainierbarer Wert pro Weight-Vektor.
2. Richtung – ein normalisierter Vektor, der mithilfe von niedrig-rangigen Matrizen aktualisiert wird.

In kompakter spaltenbasierter Notation:

[ W’ = m \frac{V + BA}{\lVert V + BA \rVert_c} ]

wo:

• m = Größe (trainierbar)
• (V) = die gefrorene Richtungsmatrix
• (BA) = die erlernte, niedrig-rangige Richtungsaktualisierung
• (\lVert \cdot \rVert_c) = Spaltenweise Normalisierung

Was Sie für diese zusätzliche Struktur erhalten:

• Mehr Freiheitsgrade im Vergleich zu herkömmlichen LoRA, da die Größe unabhängig verändert werden kann.
• Bessere Ergebnisse als bei LoRA in mehreren von dem Verfassungspaper beschriebenen Konfigurationen.
• Es sind zusätzliche Parameter sowie Rechenaufwand erforderlich, weshalb der Gewinn für Ihre spezifische Aufgabe sowie den entsprechenden Serving-Weg überprüft werden sollte.

Zusammenführung von Adaptern für das Multi-Task-Lernen

Durch getrennte Adapter kann eine festgefrorene Basis mehrere Aufgaben unterstützen. Es ist möglich, Anfragen an einen bestimmten Adapter zu leiten, bei Unterstützung mehrere Adapter über denselben Engine zu betreiben, oder ein offline zusammengeführtes Ergebnis zu erzeugen. Durch das Zusammenführen können Störungen entstehen; daher sollte das resultierende Artefakt gründlich geprüft werden, anstatt davon auszugehen, dass die ursprünglichen Adapter sauber zusammenarbeiten.

Gängige Fusionsmethoden:

1. Kombination – Durch Vereinigung der Adapterparameter wird die effektive Ranggröße erhöht. Schnell und einfach.
2. Lineare Kombination – Gewichtete Summe der Adapter. Bietet Anpassungsmöglichkeiten.
3. SVD – Matrixzerlegung zur Verschmelzung. Flexibler, aber langsamer.

Beispiel: Ein Adapter für die Zusammenfassung, ein weiterer für die Übersetzung – beides wird zu einem einzigen Mehrzweck-Model@ zusammengeführt.

Phase 4: Fine-Tuning sowie Abstimmung der Präferenzen

SFT lernt anhand von Demonstrationen. Die Methode der Präferenzoptimierung hingegen nutzt Vergleiche wie „die ausgewählte Antwort A ist besser als die abgelehnte Antwort B“. Wenden Sie sie nur dann an, wenn eine paareweise Präferenz die geeignete Beschreibung für den Fehler darstellt; bei faktischer Korrektheit und Einhaltung von Richtlinien sind oft stärkere Evaluators erforderlich als eine allgemeine Präferenz.

PPO-basierte RLHF

Das ursprüngliche Verfahren bestand aus drei Phasen Pipeline:

1. SFT – Das Aufgabenschema wird erlernt.
2. Belohnung Model – Der Trainingsschritt basiert auf menschlichen Präferenzen (ausgewählt vs. abgelehnt).
3. PPO (Proximal Policy Optimization) – Ein Verstärkungslernalgorithmus zur Optimierung der Strategie.

Die Betriebskosten entstehen durch die beweglichen Komponenten:

• Die Implementierung und Wartung sind komplex.
• Teuer – es müssen mehrere Models trainiert werden.
• Für On-Policy-Sampling sowie die Optimierung der Belohnungen sind sorgfältige Überprüfungen hinsichtlich Stabilität und möglicher Reward-Hacking-Techniken erforderlich.

DPO

DPO (Direkte Präferenzoptimierung) verzichtet auf die explizite Model sowie auf den RL-Zyklus. Sie optimiert weiterhin das RLHF-Ziel (Maximierung der Belohnung unter Berücksichtigung einer KL-Divergenz-Beschränkung), doch dies geschieht als umparameterisiertes überwachtes Lernalgorithmus-Problem anstelle mittels Verstärkungslernung:

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

Was sich in der Betriebspraxis ändert:

• Einfachere Code-Struktur (keine separate Belohnung Model, kein RL-Zyklus).
• Ein Offline-Ziel, das auf Paaren von Präferenzen beruht, anstelle eines On-Policy-Reinforcement-Learnings.
• Eine Referenzpolitik oder äquivalente Referenzlogwahrscheinlichkeiten in der Standardformulierung.

DPO lässt sich leichter prototypisieren als ein vollständiger PPO Pipeline, stellt jedoch keine automatische Verbesserung der Qualität dar. Die Ergebnisse hängen von der Ausgangspolicy, der Qualität des Paars, den Verlusteinstellungen, den Längeneffekten sowie dem Bewertungsprotokoll ab. Vergleichen Sie es mit einem SFT Checkpoint unter Verwendung derselben ausgeschlossenen Präferenz- und Aufgabensätze.

ORPO

ORPO (Odds-Ratio Preference Optimization) kombiniert den Verlust aus der negativen Log-Likelihood-Funktion von SFT mit einer Strafe aufgrund des Odds-Ratios für abgelehnte Antworten. Dadurch entfällt die notwendige separate Referenz Model, und es ist möglich, Task-Lernen sowie Präferenzoptimierung in einem einzigen Durchlauf miteinander zu verknüpfen.

Wie es funktioniert: ORPO verwendet einen kombinierten Verlustfunktion, der gleichzeitig zwei Aufgaben erledigt:

1. Maximiert die Wahrscheinlichkeit der gewählten Antwort (Lernen der Aufgabe).
2. Straft die abgelehnte Antwort mit einem Odds-Ratio-Faktor (Lernen von Präferenzen).

Wichtige Hyperparameter, die man kennen sollte:

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
)

• Lernrate: In den Experimenten des Artikels wurden niedrige Werte verwendet; passen Sie die Rate an Ihre Model-, Batch- und Datensätze an, anstatt pauschal einen festen Wert zu übernehmen.
• Beta: Steuert den Gewichtungsfaktor im Verhältnis zum SFT-Term.

Der Kompromiss:

• Eine Trainingsphase anstelle von zwei.
• Keine Belohnung Model.
• Kein Referenz-Model-Vorwärtslauf.
• Ein gekoppelter Ablauf: Falls das Lernen der Aufgabe oder das Präferenzverhalten zurückgeht, existiert kein intermediärer SFT Checkpoint aus demselben Pipeline, den man überprüfen könnte.

Wählen Sie aus den Daten sowie dem Evaluationsdesign aus:

• Verwenden Sie DPO, wenn Sie bereits einen zufriedenstellenden SFT Checkpoint besitzen und ein einfacheres Offline-Präferenzexperiment durchführen möchten.
• Testen Sie ORPO, wenn ein referenzloser, eintaktiger Optimierungsansatz zu Ihren Daten sowie betrieblichen Einschränkungen passt.
• Nutzen Sie PPO-basierte RLHF, wenn das Online-Sampling unter Verwendung einer explizit gelernten Belohnung zu den Anforderungen gehört und Sie die Ausbeutung dieser Belohnung überwachen können.

Im Standardfall gilt für alle Aufgaben „Keines“. Es sollte eine Baseline ausschließlich für SFT aufrechterhalten werden, wobei sowohl Metriken zu den Aufgabenergebnissen als auch zu den Nutzerpräferenzen berichtet werden müssen.

Fine-Tuning Frameworks

Frameworks überschneiden sich und ändern sich schnell. Wählen Sie entsprechend dem Ausführungspfad, den Sie unterstützen müssen, feste Versionen festlegen und stellen Sie sicher, dass die Trainingskonfiguration ausreichend portabel ist, um sie außerhalb eines Notebooks nachzubilden.

Unsloth – Geschwindigkeit und Speichereffizienz

Unsloth integriert sich mit Hugging Face. trl und transformers und stellt optimierte Kernels-, Checkpointing- sowie quantisierte Fine-Tuning-Pfade für unterstützte Models bereit.

• Custom Triton GPU Kernels für Attention, RoPE sowie Cross-Entropy, die die damit verbundenen PyTorch-Kosten vermeiden.
• Speichereffizientes Backpropagation, das Activations während des Rückwärtspasses erneut berechnet, anstatt sie im Speicher zu speichern.
• Verschmolzene Operationen, die mehrere Schritte (Layer Norm + Linear usw.) in einzelne GPU-Aufrufe zusammenfassen.
• 4-Bit Quantization, das direkt in den QLoRA-Pfad integriert ist und über eine optimierte Dekodierung verfügt.

[!WICHTIG] Die Importreihenfolge ist entscheidend Befolgen Sie die im Unsloth-Beispiel für die von Ihnen festgelegte Version angegebene Importreihenfolge. Unsloth wendet während des Imports Patches an, weshalb es zuerst importiert werden muss. trl und transformers vermeidet fehlende Optimierungen oder auf bestimmte Versionen bezogene Fehler.

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

# Avoid this order with Unsloth's patched path
from trl import SFTTrainer
from unsloth import FastLanguageModel

Am besten geeignet für: Einzel-GPU-Training, Prototypenentwicklung, Colab-Notebooks – sowie für alle, die die Kosten von GPU im Auge behalten müssen.

Die angegebenen Werte für Geschwindigkeit und Speicherverbrauch unterscheiden sich je nach Model, Länge der Sequenz, Batch-Größe, Genauigkeitsstufe sowie verwendeter Hardware. Messen Sie daher den Durchsatz in Benchmark Tokens pro Sekunde sowie den maximalen Speicherverbrauch bei Ihrem eigenen Testlauf, anstatt einen in Schlagzeilen genannten Quotienten als feststehende Framework Eigenschaft zu betrachten.

Axolotl – konfigurationsgesteuertes Training

# 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: deklarative, reproduzierbare Ausführungen sowie integrierte Startoptionen für verteiltes Training.

Der wesentliche Vorteil besteht in der deklarativen Konfiguration, die überprüft, versioniert und bei lokalen sowie verteilten Ausführungen wiederverwendet werden kann.

Framework-Vergleich

Praktische Demonstration: Fine-Tuning mit Unsloth

Hier ist ein vollständiges Beispiel aus meinem unsloth-Finetuning-Demo Repository. Die Demo führt eine Feinabstimmung von Nemotron-Nano für Function Calling durch.

Schneller Einstieg

# 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

Der interessante Teil befindet sich 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        # Adapter capacity; tune against held-out results
LORA_ALPHA = 32    # Update scaling; alpha/r is the classic LoRA scale
MAX_SEQ_LENGTH = 4096

# Candidate modules for this Llama-family model
LORA_TARGET_MODULES = [
    "q_proj", "k_proj", "v_proj", "o_proj",
    "gate_proj", "up_proj", "down_proj",
]

[!NOTE] Das Alpha-zu-Rank-Verhältnis alpha/r skaliert den klassischen LoRA-Update-Prozess. alpha = 2r Es handelt sich dabei um eine gängige Einstiegshilfe in der Dokumentation einiger Tools – sie stellt jedoch keine Garantie für Stabilität dar. Ordnen Sie die Anpassung von Rang, Alpha-Wert, Lernrate sowie Zielmodulen erst dann an, nachdem Daten und Baseline festgelegt wurden.

Kern-Trainingscode

from unsloth import FastLanguageModel
from trl import SFTConfig, SFTTrainer

# 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",  # Lower activation memory; extra compute
)

# The data step creates versioned train_dataset and eval_dataset objects.
# Each row has the chat messages and tool schemas expected by current TRL.

# Train with the current TRL configuration surface.
trainer = SFTTrainer(
    model=model,
    processing_class=tokenizer,
    train_dataset=train_dataset,
    eval_dataset=eval_dataset,
    args=SFTConfig(
        output_dir="outputs/nemotron-function-calling",
        max_length=4096,
        packing=True,
        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 in Vorbereitung Ich arbeite an einer praktischen Demo zu Axolotl. Bis dahin, die Leitfaden zur Beschleunigung von n-D-Parallelität Die Quelle Hugging Face stellt eine gute Referenz für mehrere Strategien des GPU-Trainings dar.

In Konfigurations-geführten sowie verteilten Architekturen sorgt Axolotl dafür, dass die Workflow reproduzierbar bleibt:

# 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 # Benchmark with your length distribution
micro_batch_size: 2
gradient_accumulation_steps: 4
learning_rate: 0.0002
num_epochs: 3

# Precision and attention path; verify support on the pinned stack
bf16: true
flash_attention: true

Training ausführen:

axolotl train axolotl_config.yaml

Phase 5: Bewertung

Einfrieren Sie den Evaluationsvertrag vor dem ersten Ausführungsvorgang. Vergleichen Sie zumindest den optimierten Checkpoint mit der exakt unoptimierten Basiskonfiguration unter denselben Prompt-, Dekodierungs-Einstellungen sowie Tool-Umgebung. Berichten Sie erst über die Gesamtbewertung, nachdem Sie die Fehlerfälle überprüft haben, die eigentlich verbessert werden sollten.

Verfolgen Sie vier Gruppen:

1. Zielaufgabe: exakte Übereinstimmung, erfolgreiche Ausführung, menschliche Bewertungskriterien oder ein anderes Ergebnis, das mit dem jeweiligen Anwendungsfall verbunden ist.
2. Regression: allgemeine Fähigkeiten sowie zuvor unterstützte Aufgabenteile, die durch Anpassungen beeinträchtigt werden könnten.
3. Sicherheit und Richtlinien: Ablehnungen, Datenlecks, Prompt Injection oder domänenspezifische Einschränkungen.
4. Betrieb: Latency, Throughput, Speicherverbrauch, Größe der Erzeugnisse sowie Kosten bei der vorgesehenen Serving Konfiguration.

Automatisierte Benchmarks

Verwenden lm-evaluation-harness für relevante standardisierte Aufgaben – und nicht als Ersatz für die Produktbewertung:

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

LLM als Judge

Bei der Bewertung der subjektiven Qualität kann ein größeres Model bei der Erstellung von Scores helfen, wobei es jedoch anhand von von Menschen überprüften Beispielen kalibriert werden muss und die Identität des Kandidaten dabei geheim gehalten werden sollte:

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

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

Domänenbezogene Bewertung

Stellen Sie echte Beispiele nach Quelle, Benutzer, Dokument oder Zeitpunkt bereit, damit nahezu identische Fälle nicht über die Aufteilung hinweg durchsickern. Für Function Calling müssen Sie den gesamten Ablauf überprüfen: Auswahl der Werkzeuge, übergebene Argumente, Ausführungsergebnis, Wiederherstellungsmaßnahmen sowie die endgültige Antwort. Bei kleinen Stichproben sollten Sie Konfidenzintervalle oder Paarzahlen aus Siegen und Niederlagen angeben, und in kritischen Bereichen müssen alle Abweichungen genauestens untersucht werden.

Phase 6: Deployment sowie Ausgabeformate

Wählen Sie das Artefakt anhand des Serving-Engines sowie des Rollback-Plans aus – und nicht ausschließlich aufgrund der Dateigröße:

1. LoRA-Adapter

uv run finetune  # Saves ~100-500MB adapter

• Größe: ist proportional zu den Zielmodulen, der Rangstufe, den Schichten sowie dem Datentyp; meist deutlich kleiner als die Basisversion.
• Am besten geeignet für: die Entwicklung, versionierte Aufgabenanpasser sowie Engines, die LoRA direkt unterstützen.
• Zusatzvorteil: Sie können Anpasser austauschen, ohne die Basis Model erneut herunterladen zu müssen.

2. Verschmolzene Model

uv run finetune --merge  # Creates a standalone full model

• Größe: ungefähr die volle Basisgröße von Checkpoint bei der gewählten Ausgabepräzision.
• Am besten geeignet für: Engine oder Verteilungspfade, die den Adapter nicht separat unterstützen.
• Kompromiss: größeres Ergebnisdokument und langsamere Implementierung; einfacheres Einzel-Model Laden.

3. Format von GGUF

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

• Größe: abhängig von Model; etwa vier Bit für Weights plus Metadaten für die Q4-Varianten.
• Am besten geeignet für: CPU Inference, Ollama, llama.cpp sowie Edge-Deployment-Umgebungen.
• Optionen: q4_k_m (kleiner) q5_k_m (mehr Weight-Genauigkeit). q8_0 (mehr Größe und höhere Genauigkeit). Messen Sie den Einfluss der Aufgabe nach der Konvertierung.

Phase 7: Serving sowie Überwachung

Mit vLLM

# Serve the base and expose a PEFT adapter as a model name.
vllm serve nvidia/Llama-3.1-Nemotron-Nano-4B-v1.1 \
    --enable-lora \
    --lora-modules function-calling=./outputs/adapter \
    --host 0.0.0.0 \
    --port 8000 \
    --max-model-len 4096

Abfrage über den mit OpenAI kompatiblen API:

from openai import OpenAI

client = OpenAI(base_url="http://localhost:8000/v1", api_key="dummy")
response = client.chat.completions.create(
    model="function-calling",
    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)

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

Überwachen des veröffentlichten Model

Der Lebenszyklus endet nicht bereits bei einem akzeptablen Trainingsverlust. Die Basis-Model-Revision, der Tokenizer sowie das Chat-Template, der Adapter-Hash, die Dataset-Version, die Trainingskonfiguration und der Bewertungsbericht werden als eine einzige Release-Einheit aufgezeichnet. In der Produktion werden mithilfe derselben Datenschnitte, die auch im Offline-Betrieb verwendet werden, der Erfolg der Aufgaben, ungültige Ausgaben, Policy-Fehler, Latency sowie Input-Drift überwacht. Stellen Sie sicher, dass die vorherigen Artefakte weiterhin ladbar sind, und definieren Sie vor dem Start einen Rollback-Threshold.

Wichtige Erkenntnisse

1. Führen Sie die Feinabstimmung erst durch, nachdem eine unangepasste Baseline sowie eine Taxonomie von Fehlern gezeigt haben, dass die Anpassung mittels Weight das Problem löst.
2. Retrieval kümmert sich um sich ändernde Belege, während Constrained Decoding für die Syntax zuständig ist; keines dieser Konzepte wird durch SFT ersetzt.
3. LoRA verringert die Anzahl der trainierbaren Zustände. Zusätzlich komprimiert QLoRA die festgefrorene Basis Weights. Weisen Sie den Speicherverbrauch von QLoRA nicht LoRA zu.
4. Datenumfassung, Integrität der Aufteilung, Herkunft der Daten sowie das Maskieren von Verlusten sind wichtiger als das Kopieren einer modischen Optimiererkonfiguration.
5. DPO, ORPO sowie auf PPO basierende RLHF stellen unterschiedliche experimentelle Ansätze dar und bilden keine Hierarchie mit einem universellen Standard.
6. Bewerten Sie das Zielverhalten, Regressionen, Sicherheit sowie die Betriebsfähigkeit anhand derselben Basis Model.
7. Wählen Sie vor dem Training entweder einen Adapter, ein zusammengeführtes Ergebnis oder ein GGUF-Ergebnis gemäß den Anforderungen an Serving und Rollbacks aus.

Referenzen

Arbeiten und Forschung

• LoRA: Niederrangige Anpassung großer Sprachmodelle Models
• QLoRA: Effizientes Feintunen von Quantisierten LLMs
• DoRA: Weight-dekomponierte niedrig-rangige Anpassung
• DPO: Optimierung der direkten Präferenz
• ORPO: Optimierung der Präferenzverhältnisse durch Odds-Ratio-Analyse
• PPO: Algorithmen zur proximalen Optimierung von Policies — OpenAI, 2017

Datenverarbeitungstools

• DataTrove — Hugging Face Skalierter Datenauswertung Distilabel — Erzeugung synthetischer Daten (Argilla)
• Verarbeitung — Extraktion von Webtexten und Crawling FastText — Facebook AI-Spracherkennung (unterstützt 217 Sprachen) Microsoft Presidio — Erkennung und Anonymisierung personenbezogener Daten
• scrubadub — Python-Bibliothek zur Entfernung von PII

Constrained Decoding

• xGrammar — Constrained Decoding zusammen mit FSMs Überblickskonzepte — Strukturierte Generierung für LLMs

Schulung Frameworks

• Trägheit — Optimierte Fine-Tuning Framework
• Axolotl — Konfigurationsgesteuertes Training sowie verteilte Launcher
• TRL — Hugging Face SFT sowie Bibliothek für Präferenztrainierung Leuchtton — PyTorch-native Fine-Tuning-Bibliothek

Inference und Deployment

• vLLM LoRA Adapter — Einen oder mehrere Adapter zusammen mit der Basis Model bereitstellen. Ollama — Lokaler LLM-Ausführer für Mac/Windows/Linux
• llama.cpp — CPU/GPU Inference im GGUF-Format

Bewertung

• lm-Bewertung-Harness — EleutherAI hat die Standardisierung der LLM-Benchmarks vorgenommen.

Leitfäden und Ressourcen

• Demo-Repositorium — Praktisches Fine-Tuning Beispiel
• LLM Fine-Tuning. Theoretische Intuition und praktische Umsetzung — Forschungs-Notebook von NotebookLM
• Leitfaden zur Beschleunigung von n-D-Parallelität — Hugging Face mehrfache GPU Trainingsstrategien