KI & LLM 9 Min Lesezeit

LLM Fine-Tuning für Einsteiger 2026 – LoRA & QLoRA

Was ist LLM Fine-Tuning – und wann lohnt es sich 2026?

Fine-Tuning bedeutet, ein bereits vortrainiertes Basismodell mit eigenen Daten weiterzutrainieren. Das Modell lernt dabei nicht neues Weltwissen, sondern Verhalten: einen bestimmten Tonfall, ein Ausgabeformat, domänenspezifische Terminologie oder die Einhaltung von Compliance-Regeln. Genau hier liegt der entscheidende Punkt – wer Fine-Tuning als Wissensdatenbank missversteht, wird enttäuscht.

Die Faustregel 2026 lautet: Prompt Engineering → RAG → Fine-Tuning, in dieser Reihenfolge. Prompting kostet nichts und löst 60–70 % aller Aufgaben. RAG (Retrieval-Augmented Generation) liefert dem Modell aktuelles Faktenwissen aus einer Vektordatenbank. Fine-Tuning kommt erst dann ins Spiel, wenn du konsistentes Verhalten, strikte JSON-Schemas, spezielle Fachsprache oder deutlich kürzere Prompts brauchst.

Typische Einsatzfälle in der Praxis: Ein Support-Bot, der immer im Markenton antwortet. Ein Code-Assistent, der eure interne API-Struktur kennt. Ein Klassifikator, der deutschsprachige Tickets in 14 Kategorien sortiert. In all diesen Fällen schlägt ein fine-getuntes 7B-Modell ein GPT-4-Prompting-Setup – bei einem Bruchteil der Inferenzkosten.

Der wirtschaftliche Hebel ist enorm: Ein fine-getuntes Qwen2.5-7B auf einer gemieteten GPU kostet dich bei 1 Mio. Tokens pro Tag rund 3–8 € im Monat. Dieselbe Last über eine kommerzielle API liegt schnell bei 400–900 €.

LoRA verstehen: Die Mathematik hinter Low-Rank Adaptation

Full Fine-Tuning eines 7B-Modells bedeutet, 7 Milliarden Parameter zu aktualisieren. Das braucht rund 80–100 GB VRAM nur für Optimizer-States (AdamW speichert zwei Momente pro Parameter in FP32) – plus Modellgewichte und Aktivierungen. Auf einer RTX 4090 mit 24 GB ist das unmöglich.

LoRA (Low-Rank Adaptation) löst das Problem elegant. Statt die Originalgewichte zu verändern, friert LoRA sie ein und fügt parallel kleine Matrizen hinzu. Für eine Gewichtsmatrix W der Dimension 4096×4096 werden zwei Matrizen A (4096×r) und B (r×4096) trainiert, wobei der Rang r typischerweise zwischen 8 und 64 liegt. Die Ausgabe ist W·x + (α/r)·B·A·x.

Der Effekt: Bei r=16 sinkt die Zahl trainierbarer Parameter von 7 Mrd. auf etwa 20–40 Mio. – also 0,3 bis 0,6 %. Der VRAM-Bedarf für Optimizer-States fällt von ~56 GB auf unter 200 MB. Gleichzeitig erreicht LoRA in Benchmarks 95–99 % der Qualität eines Full Fine-Tunings.

Ein zusätzlicher Vorteil: Der LoRA-Adapter ist nur 20–200 MB groß. Du kannst mehrere Adapter für dasselbe Basismodell parallel halten (z. B. einen für Support, einen für Code) und zur Laufzeit umschalten. Das Basismodell liegt einmal im VRAM, die Adapter werden dynamisch geladen.

QLoRA: 4-Bit-Quantisierung macht 70B-Modelle auf einer GPU möglich

QLoRA kombiniert LoRA mit einer 4-Bit-Quantisierung des Basismodells. Die Gewichte werden im NF4-Format (NormalFloat4) gespeichert, einem eigens für normalverteilte neuronale Gewichte optimierten Datentyp. Zusätzlich sorgt Double Quantization dafür, dass auch die Quantisierungs-Konstanten selbst komprimiert werden – das spart weitere ~0,5 GB pro 7B-Modell.

Die Rechnung ist beeindruckend. Ein 7B-Modell in FP16 braucht 14 GB nur für die Gewichte. In 4-Bit-NF4 sind es 3,5–4 GB. Mit Aktivierungen, Gradienten und KV-Cache kommst du bei einer Sequenzlänge von 2048 Tokens auf etwa 8–11 GB Gesamt-VRAM. Damit läuft QLoRA-Training eines 7B-Modells bequem auf einer RTX 3060 mit 12 GB.

Die VRAM-Faustregeln für QLoRA-Training mit batch_size=1 und seq_len=2048:

Modellgröße	VRAM QLoRA	VRAM LoRA (FP16)	Empfohlene GPU
1–3B	4–6 GB	8–12 GB	RTX 3060 12 GB
7–8B	8–11 GB	20–26 GB	RTX 4090 24 GB
13–14B	14–18 GB	34–44 GB	RTX 4090 / A6000
32B	26–32 GB	nicht praktikabel	A100 40 GB
70B	46–52 GB	nicht praktikabel	A100 80 GB / H100

Der Preis für die Effizienz: QLoRA trainiert etwa 20–35 % langsamer als LoRA in BF16, weil jedes Forward-Pass die Gewichte dequantisieren muss. Bei einem 7B-Modell und 2.000 Trainingsbeispielen reden wir über 25 statt 18 Minuten – vernachlässigbar.

Hardware und Kosten: Was brauchst du wirklich?

Für den Einstieg reicht eine gemietete GPU. Die Preise haben sich 2026 stabilisiert; hier realistische Marktwerte pro Stunde (Stand Q1 2026, netto):

Anbieter / GPU	VRAM	Preis/Stunde	Geeignet für
Vast.ai RTX 3090	24 GB	0,18–0,28 €	QLoRA bis 13B
RunPod RTX 4090	24 GB	0,32–0,55 €	QLoRA bis 32B, LoRA 7B
RunPod A100 80 GB	80 GB	1,50–2,30 €	QLoRA 70B
Lambda H100 PCIe	80 GB	2,40–3,80 €	Full FT kleiner Modelle
Hetzner GEX44 (RTX 4000 Ada)	20 GB	184 €/Monat	Dauerbetrieb, Inferenz

Für ein typisches Einsteiger-Projekt – 7B-Modell, 2.000 Beispiele, 3 Epochen – brauchst du auf einer RTX 4090 etwa 45–70 Minuten. Das sind bei RunPod rund 0,30–0,60 €. Selbst wenn du zehn Hyperparameter-Läufe durchprobierst, bleibst du unter 10 €.

Wichtig: Miete niemals eine GPU zum Experimentieren, ohne die Preise zu vergleichen. Vast.ai ist meist 30–50 % günstiger als RunPod, hat aber schwankende Verfügbarkeit und langsamere Netzwerkanbindung. Für reproduzierbare Trainingsläufe sind RunPod und Lambda robuster.

Wenn du regelmäßig trainierst, lohnt ein eigener Server. Eine gebrauchte RTX 3090 kostet 550–750 €, ein passender Ryzen-Build mit 64 GB RAM liegt bei 1.200–1.500 €. Bei 40 Cent/Stunde Miete amortisiert sich das nach rund 3.000 Trainingsstunden – für die meisten Teams unrealistisch. Mieten ist fast immer günstiger.

Setup: Python-Umgebung, CUDA und Bibliotheken installieren

Nutze Python 3.11 oder 3.12 – ältere Versionen machen mit aktuellen PyTorch-Builds Probleme. Auf einem frischen Ubuntu 24.04 LTS mit NVIDIA-Treiber 550 oder neuer:

python3 -m venv ~/ft-env
source ~/ft-env/bin/activate

pip install --upgrade pip
pip install torch==2.5.1 --index-url https://download.pytorch.org/whl/cu124
pip install transformers==4.46.3 \
            peft==0.13.2 \
            bitsandbytes==0.45.0 \
            accelerate==1.1.1 \
            trl==0.12.2 \
            datasets==3.1.0 \
            wandb==0.18.7

Prüfe anschließend, ob CUDA und bitsandbytes korrekt erkannt werden:

python -c "import torch, bitsandbytes as bnb; \
print(torch.cuda.get_device_name(0)); \
print(torch.cuda.get_device_properties(0).total_memory/1e9, 'GB'); \
print('bnb', bnb.__version__)"

Erscheint hier ein Fehler wie CUDA Setup failed despite GPU being available, fehlt meist die passende libcuda.so oder der Treiber ist zu alt. Bei gemieteten Pods ist das selten ein Problem – bei eigenen Servern solltest du nvidia-smi und nvcc --version abgleichen.

Ein Tipp, der dir Stunden spart: Installiere Unsloth, wenn du auf einer einzelnen Consumer-GPU trainierst. Unsloth liefert eigene Triton-Kernels und erreicht laut eigenen Benchmarks 2× höheren Durchsatz bei 60–70 % weniger VRAM als der Standard-PEFT-Stack. Die Installation erfolgt über pip install unsloth und ersetzt transformers-Aufrufe durch FastLanguageModel.

Datensatz erstellen: Format, Menge und Qualität

Die Qualität deiner Daten entscheidet über 80 % des Ergebnisses. Ein häufiger Anfängerfehler ist ein riesiger, verrauschter Datensatz. Für Verhaltens-Fine-Tuning gilt: 500 bis 5.000 exzellente Beispiele schlagen 100.000 mittelmäßige.

Das Standardformat 2026 ist JSONL im Chat-Schema, wie es TRL und Axolotl direkt verarbeiten:

{"messages": [
  {"role": "system", "content": "Du bist Support-Agent der Firma Muster GmbH. Antworte immer auf Deutsch, maximal 80 Wörter, ohne Floskeln."},
  {"role": "user", "content": "Mein Zugang zum Kundenportal funktioniert nicht."},
  {"role": "assistant", "content": "Bitte prüfe zuerst, ob du die Passwort-vergessen-Funktion unter portal.muster.de/reset genutzt hast. Falls die Mail nicht ankommt, kontrolliere den Spam-Ordner. Bleibt das Problem, nenne mir deine Kundennummer – ich setze den Zugang manuell zurück."}
]}

Achte auf drei Dinge: Konsistenz (gleicher Tonfall in allen Beispielen), Vielfalt (variiere Formulierungen, Längen und Randfälle) und Korrektheit (keine einzige falsche Antwort – das Modell lernt Fehler zuverlässig).

Für Klassifikations- oder Extraktionsaufgaben brauchst du weniger Daten: 300–800 saubere Beispiele reichen oft. Für Stil-Transfer oder komplexe Reasoning-Ketten plane 2.000–10.000 ein. Ein brauchbarer Startpunkt ist ein 90/10-Split in Training und Evaluation – ohne Eval-Set fliegst du blind.

Prüfe deinen Datensatz vor dem Training mit einem Token-Längen-Histogramm. Wenn 5 % der Beispiele über 4.096 Token liegen, schneidet max_seq_length sie ab und du verlierst genau die interessanten langen Antworten.

Praxis: LoRA-Training mit Hugging Face PEFT und TRL

Hier ist ein vollständiges, lauffähiges Trainingsskript für ein 7B-Modell mit QLoRA:

import torch
from datasets import load_dataset
from transformers import (AutoModelForCausalLM, AutoTokenizer,
                          BitsAndBytesConfig, TrainingArguments)
from peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training
from trl import SFTTrainer

MODEL_ID = "Qwen/Qwen2.5-7B-Instruct"

bnb = BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_quant_type="nf4",
    bnb_4bit_compute_dtype=torch.bfloat16,
    bnb_4bit_use_double_quant=True,
)

tok = AutoTokenizer.from_pretrained(MODEL_ID)
tok.pad_token = tok.eos_token

model = AutoModelForCausalLM.from_pretrained(
    MODEL_ID, quantization_config=bnb, device_map="auto")
model = prepare_model_for_kbit_training(model)
model.config.use_cache = False

lora = LoraConfig(
    r=16, lora_alpha=32, lora_dropout=0.05,
    target_modules=["q_proj","k_proj","v_proj","o_proj",
                    "gate_proj","up_proj","down_proj"],
    bias="none", task_type="CAUSAL_LM")
model = get_peft_model(model, lora)
model.print_trainable_parameters()

ds = load_dataset("json", data_files="train.jsonl", split="train")

args = TrainingArguments(
    output_dir="./lora-out",
    per_device_train_batch_size=2,
    gradient_accumulation_steps=8,
    num_train_epochs=3,
    learning_rate=2e-4,
    lr_scheduler_type="cosine",
    warmup_ratio=0.03,
    bf16=True,
    optim="paged_adamw_8bit",
    logging_steps=10,
    save_strategy="epoch",
    gradient_checkpointing=True,
    report_to="wandb",
)

trainer = SFTTrainer(
    model=model, tokenizer=tok, train_dataset=ds,
    args=args, max_seq_length=2048,
    packing=False,
)
trainer.train()
trainer.model.save_pretrained("./lora-final")

Die effektive Batch-Größe beträgt hier 2 × 8 = 16. Das ist ein guter Wert für Datensätze unter 5.000 Beispielen. Bei kleineren Datensätzen (unter 800 Beispiele) reduziere auf 1 × 4 = 4, sonst siehst du zu wenige Gradient-Updates pro Epoche.

packing=True beschleunigt das Training um 20–40 %, indem mehrere kurze Beispiele in eine Sequenz gepackt werden. Vorsicht: Bei Aufgaben mit strikter Trennung von Frage und Antwort kann Packing die Grenzen verwischen – teste beide Varianten.

Hyperparameter richtig setzen

Die folgende Tabelle fasst bewährte Startwerte zusammen. Sie stammen aus einer Mischung aus Hugging-Face-Empfehlungen, Unsloth-Guides und eigenen Läufen auf RTX 4090 und A100:

Parameter	Empfehlung	Wirkung
LoRA Rank `r`	8–16 (Stil), 32–64 (Fachwissen)	höher = mehr Kapazität, mehr Overfitting
`lora_alpha`	2× r	Skalierung der Adapter-Updates
`lora_dropout`	0,05–0,1	Regularisierung
Learning Rate	1e-4 bis 2e-4	zu hoch = Divergenz, zu niedrig = kein Lernen
Epochen	2–4	mehr als 5 → Overfitting
Warmup	3 % der Steps	stabilisiert den Start
Scheduler	cosine	gleichmäßiger Loss-Verlauf
max_seq_length	1024–4096	höher = mehr VRAM, quadratisch

Die wichtigste Regel: Verändere immer nur einen Parameter pro Lauf. Wer Learning Rate, Rank und Epochen gleichzeitig anpasst, lernt nichts über die Ursache. Logge jeden Lauf in Weights & Biases mit sprechenden Namen wie qwen7b-r16-lr2e4-ep3.

Für target_modules gibt es zwei Philosophien. Nur Attention-Module (q_proj, v_proj) zu trainieren ist der klassische LoRA-Ansatz und braucht am wenigsten VRAM. Alle linearen Layer einzubeziehen (inkl. MLP-Projektionen) kostet ~30 % mehr VRAM, liefert aber bei Domänenanpassungen messbar bessere Ergebnisse. Für Einsteiger: nimm alle sieben Module aus dem Code oben.

Training überwachen und Fehler erkennen

Der Trainings-Loss ist dein wichtigstes Signal. Ein gesunder Verlauf fällt in den ersten 50 Steps steil von ~2,3 auf ~1,2 und flacht dann ab. Drei Muster solltest du kennen:

Loss bleibt konstant bei ~2,3: Learning Rate zu niedrig oder die labels werden nicht korrekt gesetzt. Prüfe, ob dein Tokenizer den Loss nur auf Assistant-Tokens berechnet.
Loss fällt unter 0,4: Overfitting. Reduziere Epochen oder erhöhe lora_dropout. Ein Trainings-Loss von 0,2 bedeutet meist, dass das Modell deine Beispiele auswendig gelernt hat.
Loss springt auf NaN: Fast immer FP16 statt BF16. Nutze bf16=True auf Ampere oder neuer, fp16=True nur auf älteren Karten mit Loss-Scaling.

Neben dem Loss brauchst du eine qualitative Evaluation. Halte 20–50 Beispiele zurück und generiere nach jeder Epoche Antworten mit temperature=0.2. Vergleiche sie manuell gegen das Basismodell ohne Adapter. In der Praxis zeigt sich der Fortschritt hier deutlicher als in jeder Metrik.

Für automatisierte Checks eignet sich bei Klassifikationsaufgaben ein einfacher Exact-Match-Score, bei generativen Aufgaben ein LLM-as-Judge-Setup mit einem stärkeren Modell als Bewerter. Achte darauf, dass der Judge nicht dasselbe Modell ist, das du trainierst.

Adapter mergen, quantisieren und deployen

Nach dem Training hast du einen Adapter von 20–200 MB. Für den Produktivbetrieb gibt es zwei Wege. Erstens: Adapter separat laden – ideal, wenn du mehrere Varianten parallel betreibst.

from peft import PeftModel
from transformers import AutoModelForCausalLM
import torch

base = AutoModelForCausalLM.from_pretrained(
    "Qwen/Qwen2.5-7B-Instruct", torch_dtype=torch.bfloat16)
model = PeftModel.from_pretrained(base, "./lora-final")
model = model.merge_and_unload()
model.save_pretrained("./merged")

Zweitens: Mergen und als GGUF für llama.cpp oder Ollama konvertieren. Das ist der günstigste Weg für Inferenz auf CPU oder kleiner GPU:

python llama.cpp/convert_hf_to_gguf.py ./merged \
  --outfile model-f16.gguf --outtype f16

./llama-quantize model-f16.gguf model-q4_k_m.gguf Q4_K_M

# Modelfile
echo 'FROM ./model-q4_k_m.gguf
PARAMETER temperature 0.3
PARAMETER num_ctx 4096' > Modelfile

ollama create mein-modell -f Modelfile
ollama run mein-modell

Für hohen Durchsatz nimm vLLM. Der Server startet mit vllm serve ./merged --port 8000 --max-model-len 8192 und liefert auf einer RTX 4090 bei einem 7B-Modell in Q4 rund 1.800–2.400 Tokens pro Sekunde im Batch-Betrieb. Das reicht für 30–50 gleichzeitige Nutzer.

Wichtig beim Mergen: Wenn du in 4-Bit trainiert hast, ist das gemergte Modell in BF16 nicht automatisch besser als der Adapter auf dem quantisierten Basismodell. Vergleiche beide Varianten mit deinem Eval-Set, bevor du dich festlegst.

Fine-Tuning vs. RAG vs. Prompt Engineering – Kostenvergleich

Die Entscheidung ist selten binär. Hier eine realistische Gegenüberstellung für einen Support-Bot mit 50.000 Anfragen pro Monat:

Ansatz	Setup-Aufwand	Monatliche Kosten	Stärke
Prompt Engineering	2–8 Stunden	80–300 € (API)	schnell, flexibel
RAG	2–5 Tage	150–450 € (API + Vektor-DB)	aktuelles Faktenwissen
Fine-Tuning (7B, self-hosted)	3–7 Tage	60–180 € (GPU-Server)	Verhalten, Format, Ton
Fine-Tuning + RAG	1–2 Wochen	90–220 €	volle Kontrolle

Der Break-Even für Fine-Tuning liegt typischerweise bei 200.000–500.000 Tokens Output pro Tag. Darunter ist eine API günstiger, weil du keine GPU 24/7 bezahlen musst. Ein Hetzner GEX44 mit RTX 4000 Ada kostet 184 €/Monat – das sind 6,13 € pro Tag, unabhängig von der Last.

Der eigentliche Gewinn liegt aber nicht im Preis, sondern in der Datenhoheit. Ein self-hosted Modell verarbeitet keine Kundendaten bei Drittanbietern. Für regulierte Branchen (Gesundheit, Finanzen, öffentliche Verwaltung) ist das oft der entscheidende Faktor.

FAQ

Wie viele Trainingsbeispiele brauche ich mindestens für LoRA Fine-Tuning?

Für reine Format- oder Stil-Anpassungen reichen 200–500 hochwertige Beispiele. Für Domänensprache und komplexere Verhaltensweisen plane 1.000–5.000 ein. Unter 100 Beispiele besteht hohes Overfitting-Risiko; über 20.000 Beispiele bringt der zusätzliche Aufwand selten proportionalen Nutzen. Wichtiger als die Menge ist die Konsistenz: Ein Datensatz mit 800 perfekt formulierten Beispielen schlägt 8.000 mittelmäßige.

Reicht eine RTX 4090 für LLM Fine-Tuning aus?

Für QLoRA-Training von Modellen bis 32B ja. Ein 7B-Modell läuft mit 8–11 GB VRAM, ein 13B-Modell mit 14–18 GB, ein 32B-Modell mit 26–32 GB. Die 24 GB der RTX 4090 decken damit den gesamten Einsteiger- und Mittelklasse-Bereich ab. Nur für 70B-Modelle oder Full Fine-Tuning brauchst du eine A100 80 GB oder H100. Die Mietkosten für eine 4090 liegen bei 0,32–0,55 € pro Stunde.

Was ist der Unterschied zwischen LoRA und QLoRA?

LoRA trainiert kleine Adapter-Matrizen auf einem Basismodell, das in BF16 oder FP16 im Speicher liegt. QLoRA quantisiert zusätzlich das Basismodell auf 4 Bit (NF4) und trainiert die Adapter darauf. QLoRA braucht dadurch 60–70 % weniger VRAM, ist aber 20–35 % langsamer. Die Ergebnisqualität ist in den meisten Benchmarks nahezu identisch – QLoRA verliert typischerweise 0,5–1,5 % gegenüber LoRA in BF16.

Kann ich ein fine-getuntes Modell kommerziell nutzen?

Das hängt von der Lizenz des Basismodells ab, nicht von deinem Training. Apache-2.0-Modelle wie Qwen2.5 oder Mistral 7B erlauben kommerzielle Nutzung ohne Einschränkung. Llama-Modelle haben eigene Community-Lizenzen mit Bedingungen (u. a. Namensnennung und eine 700-Mio.-Nutzer-Klausel). Prüfe die Lizenz vor dem Training, nicht danach – ein Modellwechsel nach 40 Trainingsstunden ist teuer.

Wie erkenne ich, ob mein Modell overfittet?

Drei Signale: Der Trainings-Loss fällt unter 0,4, während die Antworten auf zurückgehaltenen Testbeispielen schlechter werden. Das Modell wiederholt Formulierungen aus dem Trainingsdatensatz wörtlich. Und die Antworten werden kürzer und generischer als beim Basismodell. Gegenmaßnahmen: Epochen reduzieren, lora_dropout auf 0,1 erhöhen, Rank senken oder mehr diverse Trainingsdaten ergänzen.