How-To: Fine-Tuning mit LoRA/QLoRA Schritt für Schritt

Warum Fine-Tuning mit LoRA/QLoRA?

Künstliche Intelligenz und Large Language Models (LLMs) sind aus der modernen Softwareentwicklung nicht mehr wegzudenken. Auch für uns als Software-Engineering-Dienstleister ist klar: KI ist längst kein reines Hype-Thema mehr, sondern ein relevantes Werkzeug, mit dem wir uns technisch fundiert auseinandersetzen müssen.

Im Rahmen des Learning Friday-Projekts „Tune das Llama“ haben wir uns daher gezielt mit dem Thema Fine-Tuning von Large Language Models beschäftigt. Ziel war es, unser Know-how über reines KI-Basiswissen hinaus auszubauen und zu verstehen, wie sich bestehende Modelle effizient an konkrete Use Cases anpassen lassen, ohne den hohen Ressourcenaufwand eines vollständigen Modelltrainings in Kauf nehmen zu müssen.

Use Case: Ja/Nein-Entscheidung automatisieren (Human-in-the-Loop)

Im Rahmen von unserem Projekt haben wir einen Use Case betrachtet, bei dem es um eine binäre Ja-/Nein-Entscheidung geht. Für diese Entscheidung existiert bereits ein Regelwerk, das bisher als Unterstützung für menschliche Entscheidungen dient.

Ziel war es, diesen Entscheidungsprozess durch Fine-Tuning eines bestehenden LLM zu automatisieren. Dafür wurde das Modell Qwen3-8B so finegetuned (= mit domänenspezifischen Entscheidungsbeispielen weitertrainiert), dass es das Regelwerk erlernt und auf neue Eingaben konsistent eine Ja- oder Nein-Empfehlung liefert. 

Der Ansatz folgt dabei bewusst einem Human-in-the-Loop-Prinzip: Im Best Case müssen Personen nicht mehr den gesamten Entscheidungsprozess durchführen, sondern lediglich das finale Go geben. Die aufwändige Analyse und Anwendung der Regeln übernimmt das Modell, während die fachliche Verantwortung und die letzte Entscheidung weiterhin beim Menschen bleiben.

Grundlagen, die du fürs Fine-Tuning brauchst: LoRA und QLoRA

LoRA (Low-Rank Adaption)

LoRA erlaubt das Finetunen eines bestehenden Modells, ohne das gesamte Modell bzw. dessen Gewichte (= interne, erlernbare Parameter, die das Verhalten des Modells bestimmen) neu trainieren zu müssen. Die ursprünglichen Gewichte werden dabei  eingefroren, und nur kleine Adapter-Matrizen trainiert, die während der Inferenz (= spätere Nutzung des Modells zur Generierung von Antworten) auf das Basismodell einwirken.

QLoRA (Quantized LoRA)

QLoRA erweitert diesen Ansatz um Quantisierung (= Speicherung der Gewichte in geringerer Auflösung/Bitbreite) des Basismodells (zB. 4-Bit), wodurch der Speicherbedarf weiter reduziert wird, während die Adapter weiterhin in höherer Präzision trainiert werden.

Auf Basis dieser Techniken konnten wir ein geeignetes Setup wählen und das Fine-Tuning praktisch umsetzen – inklusive Datenaufbereitung, Training und Parameterwahl.

How-To: Qwen3-8B mit Unsloth per QLoRA/LoRA fine-tunen

Zur Umsetzung haben wir uns an folgende Schritte gehalten:

1.  Auswahl und Laden des Basismodells

Als Ausgangspunkt wurde ein bereits vortrainiertes und quantisiertes LLM (Qwen 3-8B) und das Open Source Fine-Tuning Framework Unsloth gewählt. Durch die 4-Bit-Quantisierung lässt sich der Speicherbedarf deutlich reduzieren, wodurch das Fine-Tuning auch auf begrenzter Hardware – konkret in einer Google-Colab-Umgebung mit 16 GB VRAM – möglich wurde.

2. Erweiterung des Modells mit LoRA-Adaptern

Das Basismodell wurde anschließend mit LoRA-Adaptern erweitert. Dabei werden die ursprünglichen Modellgewichte eingefroren, während nur eine kleine Anzahl zusätzlicher Parameter trainiert wird. So kann das Modell gezielt an den Use Case angepasst werden, ohne ein vollständiges Re-Training durchzuführen.

3. Aufbereitung der Trainingsdaten

Die Trainingsdaten (1000 Datensätze) wurden in ein – für das Modell passendes – Chat-basiertes Format (d.h. Paare aus Frage und erwarteter Antwort) überführt, das dem späteren Nutzungsszenario entspricht. Dadurch lernt das Modell nicht nur die Entscheidungslogik, sondern auch die gewünschte Struktur der Ein- und Ausgaben.

train_conversations = tokenizer.apply_chat_template(
                train_dataset["messages"],
                tokenize=False)

Mit diesem Schritt werden die einzelnen Nachrichten der verschiedenen Rollen (User, System und Assistant) mithilfe des zum Modell passenden Chat-Templates in einen zusammenhängenden Text umgewandelt. Das stellt sicher, dass das Modell während des Trainings genau jenes Eingabeformat sieht, das später auch bei der Inferenz verwendet wird.

Durch tokenize=False wird zunächst nur der formatierte Text erzeugt, die eigentliche Tokenisierung erfolgt erst im Trainingsprozess.

4. Training des Modells

Das Fine-Tuning erfolgt über Supervised Fine-Tuning  (= überwachtes Training, bei dem das Modell anhand vorgegebener Eingabe-Ausgabe-Paare lernt). Ziel war es, das Modell ausreichend an den Use Case anzupassen, ohne es durch zu langes oder zu aggressives Training zum „Auswendiglernen“ zu verleiten (Overfitting). Dabei würde das Modell zwar sehr gute Ergebnisse auf den Trainingsdaten erzielen, aber auf unbekannten Eingaben schlecht abschneiden.

Um dieses Gleichgewicht zwischen Lernfähigkeit und Generalisierung zu erreichen, wurden folgende Hyperparameter (d.h. Parameter die vor Beginn des Trainings konfiguriert werden) gezielt gewählt:

learning_rate = 2e-4
per_device_train_batch_size = 16
gradient_accumulation_steps = 4
num_train_epochs = 5

• Die “learning_rate” steuert dabei, wie stark sich die Gewichte pro Trainingsschritt verändern dürfen. 
• Die “per_device_train_batch_size” bestimmt, wie viele Trainingsbeispiele gleichzeitig verarbeitet werden. 
• Durch “gradient_accumulation_steps” werden die Gewichte nicht nach jedem Batch an Trainingsdaten geupdated, sondern erst nachdem eine festgelegte Anzahl an Trainingsdaten durch das Modell verarbeitet wurde.  Dadurch lässt sich – ohne zusätzlichen Speicherbedarf – eine größere Batch Size realisieren, was bei richtiger Konfiguration zu einem stabileren Training beitragen kann.
• Die “num_train_epochs” wurden bewusst begrenzt, um Overfitting zu vermeiden. Als Epoch wird ein vollständiger Durchlauf der Trainingsdaten bezeichnet. 

Zusätzlich kam Early Stopping zum Einsatz: Sobald sich die Ergebnisse nicht weiter verbessern, wird das Training automatisch beendet. So wird sichergestellt, dass das Modell das Regelwerk verallgemeinert, anstatt es lediglich auswendig zu lernen.

5. LoRA-Adapter speichern und Weiterverwendung

Nach Abschluss des Trainings wurden die trainierten LoRA-Adapter gespeichert. Diese können nun jederzeit mit dem gewählten Basismodell geladen und für die Inferenz verwendet werden.

Ergebnisse: Basismodell vs. fine-getuntes Modell

Evaluations-Setup

Um das Fine-Tuning zu evaluieren, wurden dem Basismodell sowie dem fingetunten Modell 200 Testdatensätze (d.h. Datensätze, die nicht Teil des Trainings waren) übergeben. Zu diesen Daten waren die erwarteten Entscheidungen (d.h. die, die ein Mensch anhand des Entscheidungsprozesses und des Regelwerks treffen würde) bekannt. Diese sog. Ground Truth (GT) wurde mit den Resultaten der beiden Modelle verglichen. Für uns überraschend, lieferte bereits das Basismodell einen F1-Score von ~85%. Dies führen wir auf das klar definierte Regelwerk zurück, das den Personen bei der Entscheidungsfindung zur Verfügung steht und auch dem Modell während des Trainings übergeben wurde. Nichtsdestotrotz ließ sich durch das Fine-Tuning der F1-Score auf ~90% steigern. Dies mag auf den ersten Blick wie eine marginale Verbesserung wirken, jedoch stellen diese 5% ab einer ausreichend großen Menge an Entscheidungsprozessen eine deutliche Performancesteigerung dar.

Noch wichtiger als die reine Genauigkeit des Modells ist dessen Wahrheitsmatrix. Die Wahrheitsmatrix stellt tatsächlich korrekte Ergebnisse – sowohl bei einer positiven (Ja) als auch einer negativen Entscheidung (Nein) – den fälschlicherweise falsch getroffenen Entscheidungen gegenüber.

Die Wahrheitsmatrix besteht aus 4 Werten:

• True Positives (TP): positive Entscheidungen des Modells, die mit positiver Entscheidung einer Person übereinstimmen (beide antworten mit “Ja”).
• True Negatives (TN): negative Entscheidungen des Modells, die sich mit einer negativen Entscheidung einer Person decken (beide antworten mit “Nein”)
• False Positives (FP): positive Entscheidungen des Modells, bei der eine Person jedoch negativ entschieden hätte (Modell: “Ja”, Person “Nein”)
• False Negatives (FN): negative Entscheidungen des Modells, bei der eine Person jedoch positiv entschieden hätte (Modell “Nein”, Person “Ja”)