# 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](https://www.ionos.at/digitalguide/server/knowhow/large-language-model/) 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](https://www.ionos.at/digitalguide/server/knowhow/llama-3/), 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. ## Fine-Tuning vs. RAG: Wann nutzt man was? Fine-Tuning und [Retrieval-Augmented Generation (RAG)](https://www.ionos.at/digitalguide/server/knowhow/retrieval-augmented-generation/) 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](https://www.ionos.at/digitalguide/hosting/hosting-technik/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](https://www.ionos.at/digitalguide/server/knowhow/ai-inference/), 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](https://www.ionos.at/digitalguide/server/knowhow/nvidia-h100/) möglich. Bei dieser Methode werden sämtliche Modellparameter aktualisiert, was viel [VRAM](https://www.ionos.at/digitalguide/server/knowhow/gpu-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: ```bash pip install torch transformers datasets peft trl accelerate bitsandbytes ``` Bei größeren Modellen oder Multi-GPU-Setups kann zusätzlich DeepSpeed eingesetzt werden: ```bash pip install deepspeed ``` DeepSpeed erweitert [PyTorch](https://www.ionos.at/digitalguide/server/knowhow/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](https://www.ionos.at/digitalguide/server/knowhow/was-ist-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: ```json {"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](https://www.ionos.at/digitalguide/websites/web-entwicklung/ai-token/), 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: ```python 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. Hinweis 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: ```python 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. Hinweis 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: ```python 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`: ```python 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. ```python 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. ```python 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: ```python 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. This is a markdown version of: [https://www.ionos.at/digitalguide/server/konfiguration/fine-tuning-llm-guide/](https://www.ionos.at/digitalguide/server/konfiguration/fine-tuning-llm-guide/) for AI/LLM consumption.