LLM Fine-Tuning Tutorial: Llama 3 effizient mit eigenen Daten anpassen
LLM Fine-Tuning bedeutet, ein bereits vortrainiertes Sprachmodell gezielt mit eigenen Beispieldaten weiterzutrainieren. Im Unterschied zum Pre-Training lernt das Modell dabei nicht Sprache von Grund auf, sondern passt vorhandenes Wissen, Antwortstil und Aufgabenverhalten an einen konkreten Anwendungsfall an.
Was ist Fine-Tuning?
Beim Pre-Training wird ein großes Sprachmodell mit sehr umfangreichen Textmengen trainiert, damit es Sprache, Faktenmuster, Grammatik und statistische Zusammenhänge lernt. Dieses Training ist sehr rechenintensiv und wird daher in der Regel nur von großen Forschungslaboren oder Unternehmen durchgeführt.
Beim Fine-Tuning verwenden Sie dagegen ein bestehendes vortrainiertes Modell mit verfügbaren Modellgewichten wie Llama, Mistral oder Qwen und trainieren es mit einem kleineren, eigenen Datensatz weiter. Ziel ist nicht, dem Modell komplett neues Weltwissen beizubringen, sondern es auf bestimmte Aufgaben, Formate oder Antwortstile einzustellen. Typische Beispiele für das LLM-Fine-Tuning sind Support-Antworten, strukturierte Extraktion, interne Klassifikation oder domänenspezifische Assistenten. In der Praxis wird dafür häufig SFT, also sogenanntes Supervised Fine-Tuning, genutzt: Das Modell bekommt Eingaben und gewünschte Zielantworten als Trainingsbeispiele.
- Exklusive NVIDIA H200 GPUs für höchste Rechenleistung
- Garantierte Performance durch vollständig dedizierte CPU-Kerne
- 100 % Hosting in Deutschland für maximale Datensicherheit und DSGVO-Konformität
- Einfaches, kalkulierbares Preismodell mit festem Preis pro Stunde
Fine-Tuning vs. RAG: Wann nutzt man was?
Fine-Tuning und Retrieval-Augmented Generation (RAG) verfolgen unterschiedliche Ziele. Beim Fine-Tuning wird ein Sprachmodell mit eigenen Beispieldaten weitertrainiert, damit es ein bestimmtes Verhalten, einen gewünschten Antwortstil oder eine konkrete Aufgabe besser beherrscht. Das gewünschte Modellverhalten wird dauerhaft in den Modellparametern angepasst.
RAG dagegen verändert das Modell selbst nicht. Stattdessen werden während der Anfrage relevante Informationen aus externen Dokumenten, Datenbanken oder Wissensquellen abgerufen und dem Modell als zusätzlicher Kontext bereitgestellt. Dadurch kann das System auch auf aktuelle Informationen zugreifen, ohne dass ein erneutes Training erforderlich ist.
Fine-Tuning eignet sich besonders dann, wenn ein Modell wiederkehrende Aufgaben zuverlässig in einem bestimmten Format lösen soll. Beispiele sind Support-Antworten, Klassifikationen, strukturierte Datenausgaben oder die Anpassung an unternehmensspezifische Sprache und Fachbegriffe. Voraussetzung sind ausreichend hochwertige Trainingsdaten.
RAG ist die bessere Wahl, wenn sich Informationen regelmäßig ändern oder große Dokumentenmengen genutzt werden sollen. Typische Anwendungsfälle sind interne Wissensdatenbanken, Produktdokumentationen, technische Handbücher, Preislisten oder Compliance-Richtlinien. Neue Inhalte können dabei sofort verwendet werden, ohne das Modell erneut trainieren zu müssen.
Kurzvergleich
Fine-Tuning
- Antwortverhalten und Stil anpassen
- Neue Aufgaben trainieren
- Benötigt Trainingsdaten
- Erfordert zusätzlichen Rechenaufwand
- Ideal für stabile, wiederkehrende Anwendungsfälle
RAG
- Aktuelle Dokumente und Wissen nutzen
- Keine Modellanpassung erforderlich
- Benötigt Dokumentenspeicher und Retrieval-System
- Wissen lässt sich jederzeit aktualisieren
- Ideal für Wissensdatenbanken und dynamische Inhalte
Voraussetzungen: Hardware und Python-Libraries
Bevor Sie mit dem Fine-Tuning von LLMs beginnen, sollten Sie die benötigte Hardware und die wichtigsten Software-Komponenten kennen. Im Gegensatz zur normalen KI-Inferenz, bei der ein Modell lediglich Antworten generiert, müssen beim Training zusätzliche Informationen im Speicher gehalten werden. Dazu gehören neben den Modellgewichten auch Gradienten, Optimizer-Zustände und Zwischenergebnisse aus den einzelnen Berechnungsschritten. Dadurch steigt der Speicherbedarf deutlich an.
Aus diesem Grund ist Full Fine-Tuning großer Sprachmodelle in aller Regel nur auf leistungsstarken Rechenzentrums-GPUs wie beispielsweise der NVIDIA H100 möglich. Bei dieser Methode werden sämtliche Modellparameter aktualisiert, was viel VRAM und Rechenleistung erfordert.
In der Praxis kommen deshalb häufig sogenannte Parameter-Efficient Fine-Tuning (PEFT)-Methoden zum Einsatz. Statt das gesamte Modell neu zu trainieren, werden dabei nur kleine zusätzliche Parameter angepasst. Die bekannteste Methode ist LoRA (Low-Rank Adaptation). QLoRA erweitert diesen Ansatz um eine 4-Bit-Quantisierung des Basismodells. Dadurch sinkt der Speicherbedarf erheblich, sodass sich viele 7B- oder 8B-Modelle bereits auf leistungsstarken Consumer-GPUs wie einer RTX 4090 trainieren lassen.
Die folgende Tabelle zeigt typische Größenordnungen für den VRAM-Bedarf verschiedener Modellklassen. Die Werte dienen als Orientierung und können je nach Batch-Größe, Kontextlänge, Precision (FP16 oder BF16), Optimizer und weiteren Trainingseinstellungen abweichen.
| Modellgröße | Full Fine-Tuning, grober VRAM-Bedarf | LoRA, grober VRAM-Bedarf | QLoRA, grober VRAM-Bedarf | Typische Hardware |
|---|---|---|---|---|
| 3B | ca. 16 bis 28 GB | ca. 12 bis 24 GB | ca. 8 bis 16 GB | RTX 4060 Ti 16 GB, RTX 4090, L4 |
| 7B/8B | ca. 60 bis 80 GB | ca. 24 bis 48 GB | ca. 16 bis 24 GB | RTX 4090, L40S, A100 |
| 13B/14B | ca. 160 bis 320 GB | ca. 48 bis 80 GB | ca. 24 bis 48 GB | L40S, A100 80 GB |
| 30B/34B | mehrere A100/H100 | ca. 80 bis 160 GB | ca. 48 bis 80 GB | A100 80 GB, H100 |
| 70B | Multi-GPU-Setup | ca. 160 GB+ | stark optimiert ab 48 GB, realistisch eher 80 bis 160 GB | mehrere A100/H100 |
Für die Umsetzung vom LLM-Fine-Tuning werden außerdem mehrere Open-Source-Bibliotheken benötigt, die unterschiedliche Aufgaben übernehmen:
- PyTorch: Bildet die Grundlage für das Training neuronaler Netze
- Transformers von Hugging Face: Stellt vortrainierte Modelle, Tokenizer und Trainingsschnittstellen bereit
- Datasets: Erleichtert das Laden und Verarbeiten von Trainingsdaten
- PEFT: Implementiert LoRA, QLoRA und weitere parameter-effiziente Fine-Tuning-Methoden
- TRL (Transformers Reinforcement Learning): Enthält mit dem SFTTrainer eine einfache Trainingsoberfläche für Supervised Fine-Tuning
- bitsandbytes: Ermöglicht 4-Bit- und 8-Bit-Quantisierung und ist die Grundlage für QLoRA
- Accelerate: Vereinfacht die Nutzung von GPUs und verteiltem Training
Für die meisten LoRA- und QLoRA-Projekte genügt die Installation der folgenden Pakete in Python:
pip install torch transformers datasets peft trl accelerate bitsandbytesBei größeren Modellen oder Multi-GPU-Setups kann zusätzlich DeepSpeed eingesetzt werden:
pip install deepspeedDeepSpeed erweitert PyTorch um Optimierungen für große Trainingsläufe. Dazu gehören unter anderem Speicheroptimierungen durch ZeRO (Zero Redundancy Optimizer), Gradient Offloading und verteiltes Training über mehrere GPUs. Für ein erstes Fine-Tuning-Projekt ist DeepSpeed jedoch nicht zwingend erforderlich. Anfängerinnen und Anfänger erzielen die besten Ergebnisse, wenn sie zunächst mit einem kleineren Modell, einem überschaubaren Datensatz und einer einzelnen GPU arbeiten.
Wenn Sie auf Consumer-Hardware trainieren wollen und dabei VRAM und Trainingszeit sparen möchten, sollten Sie außerdem einen Blick auf Unsloth werfen. Die Bibliothek ist vollständig kompatibel mit dem Hugging-Face-Ökosystem (TRL, PEFT, Transformers) und ersetzt dort lediglich den Modell-Ladeaufruf, der Rest des Trainings-Codes bleibt identisch. Das Training mit Unsloth ist etwa 2-mal schneller und verbraucht rund 70 Prozent (je nach Modell bis zu 80–90 Prozent) weniger VRAM, ohne Genauigkeitsverluste gegenüber Standard-QLoRA. Für fortgeschrittene Konfigurationen ist zusätzlich Axolotl verbreitet, das ebenfalls auf dem HF-Stack aufbaut und eine YAML-basierte Konfiguration anbietet.
Datenvorbereitung: JSONL-Formatierung und Tokenization
Für Supervised Fine-Tuning benötigen Sie Beispiele aus Eingabe und gewünschter Antwort. Häufig wird dafür JSONL verwendet, also eine Datei, bei der jede Zeile ein eigenes JSON-Objekt enthält. Dieses Format ist praktisch, weil große Datensätze zeilenweise verarbeitet werden können. Für Chat-Modelle sollten die Trainingsdaten möglichst dem späteren Dialogformat ähneln. Ein Beispiel enthält daher oft eine Systemanweisung, eine Nutzereingabe und eine ideale Assistentenantwort. Wichtig ist, dass die Zielantworten sauber, konsistent und fachlich korrekt sind. Schlechte Trainingsdaten führen fast immer zu schlechteren Modellen, auch wenn die technische Konfiguration korrekt ist.
Ein Beispiel für eine JSONL-Datei für einen Support-Assistenten könnte wie folgt aussehen:
{"messages":[{"role":"system","content":"Sie sind ein technischer Support-Assistent."},{"role":"user","content":"Wie setze ich mein Passwort zurück?"},{"role":"assistant","content":"Öffnen Sie die Kontoeinstellungen, wählen Sie 'Passwort ändern' und folgen Sie den Anweisungen. Verwenden Sie anschließend ein starkes, neues Passwort."}]}
{"messages":[{"role":"system","content":"Sie sind ein technischer Support-Assistent."},{"role":"user","content":"Was bedeutet 4-Bit Quantisierung?"},{"role":"assistant","content":"4-Bit Quantisierung reduziert die Speichergröße eines Modells, indem Gewichte mit geringerer numerischer Präzision gespeichert werden. Dadurch sinkt der VRAM-Bedarf, allerdings kann die Genauigkeit leicht beeinflusst werden."}]}Beim Laden der Daten wird der Text anschließend tokenisiert. Tokenization bedeutet, dass Text in numerische Einheiten, sogenannte KI-Tokens, zerlegt wird, die das Modell verarbeiten kann. Hugging Face Transformers stellt dafür passende Tokenizer bereit. Für Chat-Modelle ist wichtig, das Chat-Template des jeweiligen Modells zu verwenden, damit Rollen wie system, user und assistant korrekt formatiert werden. Wenn das Format nicht zum Modell passt, lernt das Modell oft schlechter oder erzeugt unpassende Ausgaben. Für den Anfang sollten Sie mit wenigen hundert bis wenigen tausend hochwertigen Beispielen starten.
Ein einfaches Ladebeispiel sieht so aus:
from datasets import load_dataset
dataset = load_dataset("json", data_files={
"train": "train.jsonl",
"validation": "valid.jsonl"
})
print(dataset["train"][0])Schritt-für-Schritt-Anleitung: Von Data Prep bis Evaluation
Ein Fine-Tuning-Projekt besteht nicht nur aus dem eigentlichen Training. Bevor das Modell lernen kann, müssen die Trainingsdaten vorbereitet, das Basismodell ausgewählt und die Trainingskonfiguration festgelegt werden. Die folgende Schritt-für-Schritt-Anleitung führt Sie durch den gesamten Prozess.
Schritt 1: Daten vorbereiten
Zuerst definieren Sie, welche Aufgabe das Modell lernen soll. Für Anfängerinnen und Anfänger ist eine klar begrenzte Aufgabe besser als ein sehr breiter Assistent. Geeignet sind zum Beispiel Support-Antworten, Produktklassifikation oder strukturierte Antworten in einem festen JSON-Format. Danach sammeln Sie Beispiele aus Eingabe und gewünschter Ausgabe. Jede Antwort sollte so formuliert sein, wie Sie sie später vom Modell erwarten. Entfernen Sie Dubletten, widersprüchliche Beispiele und private Daten. Teilen Sie den Datensatz anschließend in Training und Validation auf, zum Beispiel 90 Prozent Training und 10 Prozent Validation.
Schritt 2: Basismodell auswählen
Wählen Sie ein Modell, das zu Ihrer Hardware und Ihrem Erfahrungsstand passt. Für dieses Tutorial verwenden wir Llama 3.1 8B Instruct, da das Modell weit verbreitet ist, von den wichtigsten Open-Source-Tools unterstützt wird und sich bereits auf leistungsstarken Consumer-GPUs mit LoRA oder QLoRA fine-tunen lässt. Dadurch können die gezeigten Schritte auch ohne Rechenzentrums-Hardware nachvollzogen werden.
Llama 4 ist zwar der aktuelle Nachfolger von Llama 3, nutzt jedoch eine komplexere Mixture-of-Experts-Architektur (MoE) und bietet zusätzlich multimodale Fähigkeiten. Für ein erstes Fine-Tuning-Projekt würde dies unnötige zusätzliche Komplexität einführen, weshalb sich ein breit unterstütztes Modell wie Llama 3.x für dieses Tutorial anbietet. Die grundlegenden Konzepte wie Supervised Fine-Tuning (SFT), PEFT, LoRA und QLoRA funktionieren bei beiden Modellgenerationen nach denselben Prinzipien. Ein Wechsel auf Llama 4 ist daher prinzipiell möglich, setzt aber voraus, dass die verwendete Trainingsumgebung, Bibliotheken und Hardware die jeweilige Modellvariante unterstützen. In vielen Fällen müssen dafür Modell-ID, Tokenizer, Prompt-Format, Speicherbedarf und Fine-Tuning-Konfiguration angepasst und erneut getestet werden.
Wenn Ihnen nur 16 bis 24 GB VRAM zur Verfügung stehen, empfiehlt sich die Nutzung von QLoRA mit 4-Bit-Quantisierung. Verfügen Sie dagegen über eine A100-, H100-, H200-, B200- oder vergleichbare GPU, können Sie größere Batch-Größen, längere Kontextfenster oder größere Modelle ausprobieren. Für reproduzierbare Ergebnisse sollten Sie Modellname, Datensatzversion und Trainingsparameter stets dokumentieren.
Für den Zugriff auf Llama 3.1 über Hugging Face müssen Sie die Lizenzbedingungen von Meta akzeptieren, Zugriff auf das Modell erhalten und sich bei Hugging Face authentifizieren.
Schritt 3: Modell quantisiert laden
Bei QLoRA wird das Basismodell in 4-Bit geladen. Dadurch sinkt der VRAM-Bedarf deutlich. Die eigentlichen Modellgewichte bleiben eingefroren. Trainiert werden nur kleine LoRA-Adapter, die in bestimmte Projektionsschichten des Transformers eingefügt werden. Diese Adapter speichern später die Anpassung an Ihre Aufgabe. Das ist effizienter als Full Fine-Tuning von LLMs, weil deutlich weniger Parameter trainiert werden. Für viele Praxisfälle reicht diese Methode aus.
Das folgende Codebeispiel lädt das vortrainierte Llama-3.1-Modell mithilfe von Hugging Face Transformers in einer 4-Bit-quantisierten Variante:
import torch
from transformers import AutoModelForCausalLM, AutoTokenizer, BitsAndBytesConfig
model_name = "meta-llama/Llama-3.1-8B-Instruct"
quant_config = BitsAndBytesConfig(
load_in_4bit=True,
bnb_4bit_compute_dtype=torch.bfloat16,
bnb_4bit_quant_type="nf4",
bnb_4bit_use_double_quant=True
)
tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModelForCausalLM.from_pretrained(
model_name,
quantization_config=quant_config,
device_map="auto"
)Schritt 4: LoRA-Konfiguration erstellen
LoRA fügt kleine trainierbare Matrizen in bestimmte Schichten des Modells ein. Der Parameter r wird auch Rank genannt. Er bestimmt, wie groß diese zusätzlichen Matrizen sind. Ein typischer Startwert ist r=8 oder r=16. Der Parameter lora_alpha skaliert den Einfluss der LoRA-Gewichte. Mit lora_dropout=0.05 kann man leicht gegen Overfitting stabilisieren. Für viele Llama-ähnliche Modelle werden Zielmodule wie q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj verwendet. Zielmodule sind die Schichten des Sprachmodells, in die LoRA zusätzliche trainierbare Parameter einfügt. Statt alle Milliarden Modellparameter zu aktualisieren, werden nur diese ausgewählten Module angepasst, wodurch das Fine-Tuning deutlich weniger Speicher und Rechenleistung benötigt.
Die Wahl von lora_alpha beeinflusst die Skalierung der LoRA-Adapter. Ein häufig verwendeter Startwert ist lora_alpha = 2×r, beispielsweise lora_alpha=16 bei r=8. Dabei handelt es sich jedoch um eine praktische Heuristik und keine feste Empfehlung. Wenn Sie Rank-Stabilized LoRA (rsLoRA) mit use_rslora=True aktivieren, verwendet PEFT eine angepasste Skalierung von alpha/√r statt alpha/r. Dadurch kann rsLoRA insbesondere bei höheren Ranks stabiler trainieren. Die optimale Kombination aus Rank und lora_alpha sollte weiterhin anhand von Evaluationsergebnissen getestet werden.
Der folgende Code definiert die LoRA-Konfiguration, die während des Fine-Tunings verwendet wird:
from peft import LoraConfig
lora_config = LoraConfig(
r=8,
lora_alpha=16,
lora_dropout=0.05,
target_modules=["q_proj", "k_proj", "v_proj", "o_proj", "gate_proj", "up_proj", "down_proj"],
task_type="CAUSAL_LM"
)Schritt 5: SFTTrainer konfigurieren
Für das eigentliche Training verwenden wir den SFTTrainer aus der Hugging-Face-Bibliothek TRL. SFT steht hier für Supervised Fine-Tuning. Der Trainer verbindet dabei das geladene Basismodell, die Trainingsdaten, die Validierungsdaten und die zuvor definierte LoRA-Konfiguration.
Zusätzlich werden zentrale Trainingsparameter festgelegt. Dazu gehören die Lernrate, die Batch-Größe, die Anzahl der Epochen und die maximale Sequenzlänge. Für ein erstes LoRA-Training ist learning_rate=2e-4 ein üblicher Startwert. Da der VRAM bei Consumer-GPUs oft begrenzt ist, wird hier mit einer kleinen Batch-Größe und gradient_accumulation_steps=8 gearbeitet. Dadurch werden mehrere kleine Trainingsschritte gesammelt, bevor ein Optimierungsschritt ausgeführt wird.
Der folgende Code erstellt die Trainingskonfiguration und übergibt sie zusammen mit Modell, Datensatz und LoRA-Konfiguration an den SFTTrainer:
from trl import SFTTrainer, SFTConfig
training_args = SFTConfig(
output_dir="./llama-lora-output",
learning_rate=2e-4,
per_device_train_batch_size=1,
gradient_accumulation_steps=8,
num_train_epochs=2,
logging_steps=10,
eval_strategy="steps",
eval_steps=50,
save_steps=100,
max_length=1024,
bf16=True
)
trainer = SFTTrainer(
model=model,
args=training_args,
train_dataset=dataset["train"],
eval_dataset=dataset["validation"],
peft_config=lora_config
)Mit dieser Konfiguration trainiert das Modell nicht alle ursprünglichen Gewichte neu, sondern nur die LoRA-Adapter. Die Validierungsdaten werden genutzt, um während des Trainings zu prüfen, ob das Modell auch auf nicht gesehenen Beispielen besser wird.
Schritt 6: Training starten
Nach der Konfiguration starten Sie das Training mit trainer.train(). Während des Trainings protokolliert das Framework typischerweise den Training Loss und den Evaluation Loss. Der Training Loss zeigt, wie gut das Modell auf den Trainingsdaten vorankommt. Der Evaluation Loss zeigt, wie gut das Modell auf nicht gesehenen Validierungsdaten abschneidet. Wenn der Training Loss sinkt, der Evaluation Loss aber steigt, ist das ein Hinweis auf Overfitting. In diesem Fall sollten Sie weniger Epochen, mehr Daten, höheres Dropout oder kleinere LoRA-Ranks testen.
trainer.train()
trainer.save_model("./llama-lora-adapter")Schritt 7: Adapter testen
Nach dem Training speichern Sie nicht das komplette Basismodell, sondern hauptsächlich den LoRA-Adapter. Dieser Adapter kann später zusammen mit dem Basismodell geladen werden. Dadurch bleiben die Dateien deutlich kleiner als bei einem vollständigen Modell-Checkpoint. Für einen ersten Test sollten Sie Beispiele verwenden, die nicht im Trainingsdatensatz enthalten waren. Prüfen Sie nicht nur, ob die Antwort gut klingt, sondern ob sie fachlich korrekt und im gewünschten Format ist. Besonders bei JSON-Ausgaben sollten Sie testen, ob das Modell valide Strukturen erzeugt.
from peft import PeftModel
base_model = AutoModelForCausalLM.from_pretrained(
model_name,
quantization_config=quant_config,
device_map="auto"
)
fine_tuned_model = PeftModel.from_pretrained(
base_model,
"./llama-lora-adapter"
)
Evaluation: Wie bewertet man ein Fine-Tuning?
Nach dem Training stellt sich die Frage, ob das Modell tatsächlich besser geworden ist. Dafür werden verschiedene Metriken verwendet, die während und nach dem Training berechnet werden. Die wichtigsten Kennzahlen sind der Training Loss, der Evaluation Loss und die Perplexity. Zusätzlich sollten die Antworten des Modells immer auch manuell geprüft werden, da einzelne Metriken nicht alle Qualitätsaspekte erfassen können.
Training Loss
Der Training Loss misst, wie stark die Vorhersagen des Modells von den gewünschten Antworten in den Trainingsdaten abweichen. Vereinfacht gesagt zeigt sie, wie gut das Modell die Beispiele gelernt hat, die es während des Trainings gesehen hat.
Während eines erfolgreichen Trainings sollte der Training Loss kontinuierlich sinken. Das bedeutet, dass die Modellvorhersagen immer näher an den gewünschten Zielantworten liegen. Ein niedriger Training Loss allein ist jedoch noch kein Beweis für ein gutes Modell, da das Modell die Trainingsdaten auch auswendig lernen kann.
Evaluation Loss
Der Evaluation Loss wird auf einem separaten Validierungsdatensatz berechnet, den das Modell während des Trainings nicht sieht. Sie zeigt deshalb besser, wie gut das Modell auf neue, unbekannte Eingaben reagieren kann.
Für die Praxis ist der Evaluation Loss meist wichtiger als der Training Loss. Sinken beide Werte gleichzeitig, deutet dies darauf hin, dass das Modell sinnvoll lernt. Sinkt dagegen nur der Training Loss, während der Evaluation Loss wieder ansteigt, spricht dies häufig für Overfitting. Das Modell merkt sich dann die Trainingsdaten zu stark und generalisiert schlechter auf neue Beispiele.
Perplexity
Eine weitere häufig verwendete Metrik ist die Perplexity. Sie beschreibt vereinfacht, wie sicher oder unsicher das Modell bei der Vorhersage des nächsten Tokens ist. Niedrige Werte sind in der Regel besser, da sie auf präzisere Vorhersagen hindeuten. Die Perplexity wird in aller Regel direkt aus dem Cross-Entropy Loss berechnet:
import math
eval_results = trainer.evaluate()
eval_loss = eval_results["eval_loss"]
perplexity = math.exp(eval_loss)
print(f"Evaluation Loss: {eval_loss:.4f}")
print(f"Perplexity: {perplexity:.2f}")Die Perplexity eignet sich gut zum Vergleich verschiedener Modellversionen oder Trainingsläufe. Sie sollte jedoch nicht isoliert betrachtet werden, da ein Modell trotz guter Perplexity fachlich falsche oder unvollständige Antworten erzeugen kann.
Interpretation der Loss-Kurve
Neben den einzelnen Kennzahlen lohnt sich ein Blick auf die gesamte Loss-Kurve während des Trainings. Sie zeigt, wie sich die Modellqualität über die Zeit entwickelt. Eine typische, gesunde Trainingskurve fällt zu Beginn relativ deutlich ab und flacht später langsam ab. Das Modell lernt zunächst schnell und nähert sich anschließend schrittweise einem stabilen Zustand an.
Treten starke Schwankungen auf, kann dies auf eine zu hohe Learning Rate oder einen zu kleinen beziehungsweise uneinheitlichen Datensatz hindeuten. Sinkt der Loss dagegen kaum, kann die Learning Rate zu niedrig sein oder die Trainingsdaten passen nicht gut zur Aufgabe.
Steigt der Evaluation Loss nach einigen Trainingsschritten wieder an, während der Training Loss weiter sinkt, spricht dies häufig für Overfitting. In diesem Fall kann es sinnvoll sein, das Training früher zu beenden oder einen älteren Checkpoint zu verwenden. Aus diesem Grund speichern Trainings-Frameworks regelmäßig Zwischenstände des Modells.
Warum manuelle Tests weiterhin wichtig sind
Metriken liefern wichtige Hinweise auf die Modellqualität, ersetzen aber keine praktische Überprüfung. Nach dem Fine-Tuning sollten Sie das Modell daher mit realistischen Testanfragen evaluieren und die Antworten fachlich bewerten.
In produktiven Projekten werden deshalb meist automatische Kennzahlen wie Loss und Perplexity mit manuellen Tests kombiniert. Erst die Kombination aus beiden Verfahren ermöglicht eine zuverlässige Einschätzung der tatsächlichen Modellqualität.
Fazit
LLM Fine-Tuning ist sinnvoll, wenn ein vortrainiertes Modell mit verfügbaren Modellgewichten ein bestimmtes Aufgabenverhalten oder Antwortformat lernen soll. Für Anfängerinnen und Anfänger ist ein Full Fine-Tuning von LLMs meistens zu teuer und zu speicherintensiv. LoRA und QLoRA sind deshalb die praxisnäheren Methoden, weil sie deutlich weniger VRAM benötigen. Mit 4-Bit-Quantisierung lassen sich 7B- oder 8B-Modelle oft schon auf leistungsstarken Consumer-GPUs trainieren. A100-, H100-, B200- und H200-GPUs bleiben jedoch wichtig, wenn größere Modelle, längere Kontexte oder mehrere Experimente parallel benötigt werden. Entscheidend ist am Ende nicht nur die Trainingskonfiguration, sondern vor allem die Qualität der Daten und eine saubere Evaluation.