LLM Fine-Tuning mit LoRA: 12 Schritte [2026]

Wer im Sommer 2026 ein eigenes Sprachmodell auf einen speziellen Ton, eine Fachsprache oder ein festes Antwortformat trimmen will, kommt an einer Frage nicht vorbei: Reicht ein cleverer Prompt, braucht es RAG, oder muss das Modell selbst fine-getuned werden? Seit Google DeepMind am 5. August 2026 Gemma 3 komplett unter Apache 2.0 veröffentlicht hat und Meta am 12. August mit offenen Llama-4-Gewichten nachzog, ist die Antwort für viele Teams klarer geworden: Fine-Tuning auf einer einzelnen Grafikkarte ist praktikabel geworden, nicht nur ein Thema für Konzerne mit eigenem GPU-Cluster.

Dieser Artikel zeigt Schritt für Schritt, wie du ein offenes Basismodell per LoRA beziehungsweise QLoRA fine-tunest, von der Umgebung über den Datensatz bis zum fertigen, quantisierten Modell, das in Ollama oder LM Studio läuft. Der komplette Aufbau der Trainings-Pipeline dauert bei den hier gezeigten Schritten rund 60 Minuten, das eigentliche Training läuft danach je nach Datensatzgröße und Hardware im Hintergrund weiter.

Warum Fine-Tuning im Sommer 2026 wieder Konjunktur hat

Vor zwei Jahren war Fine-Tuning für die meisten Teams zu teuer und zu riskant. Die Modelle waren entweder geschlossen, oder die offenen Varianten hinkten den kommerziellen Angeboten spürbar hinterher. Das hat sich verschoben. Qwen hat am 8. August 2026 mit Qwen3.8-27B erstmals ein Modell der Max-Klasse unter Apache 2.0 offengelegt, mit 262.000 Token Kontext und nativer Bild- und Videoverarbeitung. Zwei Tage zuvor hatte Mistral AI mit Shieldstral-1.0-3B ein kompaktes 3-Milliarden-Parameter-Modell unter derselben Lizenz veröffentlicht, gedacht für Content-Moderation direkt auf dem Endgerät.

Der zweite Treiber ist Hardware. QLoRA lädt das Basismodell in 4-Bit-Quantisierung und trainiert nur kleine Adapter-Matrizen obendrauf. Dadurch passt ein 7- bis 8-Milliarden-Parameter-Modell auf eine einzelne Consumer-GPU mit 16 bis 24 GB VRAM, etwa eine RTX 4090. Für viele Teams in der DACH-Region bedeutet das: Ein firmenspezifisches Modell für Support-Tickets, interne Dokumentation oder Compliance-Texte lässt sich ohne Cloud-Rechnung im fünfstelligen Bereich bauen.

Der dritte Treiber ist eng mit dem zweiten verknüpft: die Reife der Werkzeuge. Hugging Face bündelt Transformers, PEFT und TRL inzwischen so, dass ein Trainingsskript mit wenigen Codezeilen auskommt, während Unsloth als spezialisierte Bibliothek Training und Speicherverbrauch zusätzlich optimiert. Wo vor zwei Jahren noch tiefes Wissen über verteiltes Training nötig war, reicht heute für viele Anwendungsfälle ein einzelnes, gut dokumentiertes Skript, das in diesem Artikel Schritt für Schritt aufgebaut wird.

Fine-Tuning löst dabei nicht jedes Problem. Wer nur aktuelle Fakten in Antworten einbauen will, braucht RAG. Wer nur den Tonfall justieren will, kommt oft mit einem guten System-Prompt aus. Fine-Tuning lohnt sich, wenn ein Modell dauerhaft ein bestimmtes Format, einen festen Stil oder Domänenwissen zeigen soll, das sich nicht zuverlässig über den Kontext einspeisen lässt.

Ein typisches Szenario aus der Praxis: Ein Team will seinen Support-Bot dazu bringen, Tickets nach einem festen internen Schema zu kategorisieren und dabei stets denselben knappen, freundlichen Ton zu treffen. Prompt Engineering allein führt hier oft zu inkonsistenten Ergebnissen, sobald Anfragen leicht vom erwarteten Muster abweichen, weil das Modell die Formatvorgabe aus dem System-Prompt nicht zuverlässig über viele Anfragen hinweg durchhält. Ein LoRA-Adapter, trainiert auf einigen hundert echten, anonymisierten Beispielantworten, festigt genau dieses Verhalten dauerhaft im Modell. Das Basismodell bleibt dabei unverändert im Zugriff, nur der schlanke Adapter kommt hinzu.

Fine-Tuning vs. RAG vs. Prompt Engineering: Was passt wann?

Bevor du GPU-Stunden investierst, lohnt ein nüchterner Vergleich der drei Ansätze. Prompt Engineering ist am schnellsten umgesetzt, stößt aber bei komplexen, wiederkehrenden Formatvorgaben an Grenzen. RAG hält ein Modell aktuell, ändert aber nicht, wie es grundsätzlich schreibt oder strukturiert. Fine-Tuning verändert das Modell selbst, kostet dafür Zeit, Daten und Rechenleistung.

Kriterium	Prompt Engineering	RAG	Fine-Tuning (LoRA)
Einrichtungszeit	Minuten	Stunden bis Tage	Tage bis Wochen
Hardware nötig	Keine eigene	Vektordatenbank	GPU mit 12–48 GB VRAM
Ändert Modellverhalten dauerhaft	Nein	Nein	Ja
Hält Fakten aktuell	Begrenzt	Sehr gut	Schlecht ohne Nachtraining
Passt Ton/Format/Stil an	Begrenzt	Kaum	Sehr gut
Reversibel	Sofort	Sofort	Adapter entfernbar, Basismodell bleibt unverändert
Typischer Einsatz	Prototyping, einfache Aufgaben	Support-Bots mit aktuellem Wissen	Fester Stil, Domänensprache, strukturierte Ausgaben

In der Praxis kombinieren viele Teams alle drei Ansätze: RAG liefert aktuelle Fakten, ein fine-getunter Adapter sorgt für den passenden Ton und die richtige Struktur, und ein sauberer System-Prompt fasst beides zusammen. Dieser Artikel konzentriert sich auf den dritten Baustein.

Voraussetzungen: Hardware, Software und Basismodelle

Für QLoRA-Fine-Tuning brauchst du keinen Rechenzentrums-Cluster. Eine einzelne GPU mit 16 GB VRAM reicht für kleinere Modelle bereits aus. Für dieses Tutorial gehen wir von folgendem Setup aus: Ubuntu 24.04 oder Windows 11 mit WSL2, Python 3.11, eine NVIDIA-GPU mit aktuellem CUDA-Treiber sowie mindestens 32 GB Arbeitsspeicher. Für die Bibliotheken installierst du jeweils die aktuelle Version, feste Versionsnummern ändern sich hier zu häufig, um sie sinnvoll zu fixieren: Hugging Face Transformers, PEFT, TRL, bitsandbytes, Accelerate und Datasets.

Bei der Wahl des Basismodells hat sich die Lage seit Anfang August 2026 spürbar entspannt. Die folgende Tabelle zeigt offene Modelle, die sich für LoRA- oder QLoRA-Training eignen, mit Parametergröße, Lizenz und ungefährem VRAM-Bedarf für die kleinste praktikable Variante.

Modell	Parameter	Lizenz	Release	Min. VRAM (QLoRA, ca.)
Gemma 3 7B	7B, dicht	Apache 2.0	5. Aug. 2026	16–24 GB
Gemma 3 27B	27B, dicht	Apache 2.0	5. Aug. 2026	24–32 GB
Llama 4 (kleine dichte Variante)	~8B, dicht	Meta-Lizenz, kommerzielles Fine-Tuning erlaubt	12. Aug. 2026	16–24 GB
Llama 4 Maverick	400B gesamt / 17B aktiv (MoE)	Meta-Lizenz	12. Aug. 2026	Nur Multi-GPU
Qwen3.8-27B	27B, dicht	Apache 2.0	8. Aug. 2026	ca. 24 GB (Q4_K_M ~17 GB Gewichte)
Qwen 3.6-35B-A3B	35B gesamt / 3B aktiv (MoE)	Apache 2.0	2026	24–48 GB
Mistral Shieldstral-1.0-3B	3B, dicht	Apache 2.0	4. Aug. 2026	8–12 GB

Für dieses Tutorial nutzen wir Gemma 3 7B als Beispielmodell, weil es unter Apache 2.0 steht, auf einer einzelnen 24-GB-Karte trainierbar ist und laut Benchmarks von Google DeepMind bei MMLU-Pro mit 81,2 Prozent vor Llama 4 8B mit 79,8 Prozent liegt. Bei HumanEval liegt Gemma 3 7B mit 72,5 Prozent ebenfalls vor Llama 4 8B mit 68,3 Prozent, bei MATH mit 58,7 zu 52,1 Prozent. Der beschriebene Ablauf funktioniert mit den anderen Modellen aus der Tabelle nahezu identisch, nur Kontextlänge und Speicherbedarf verschieben sich.

Neben der GPU solltest du genug freien Festplattenspeicher einplanen. Ein 7B-Modell belegt in voller Präzision rund 14 bis 15 GB, dazu kommen die 4-Bit-quantisierte Kopie fürs Training, der gemergte Export und am Ende noch die GGUF-Varianten in unterschiedlichen Quantisierungsstufen. In der Praxis sind 60 bis 80 GB freier Speicher für den gesamten in diesem Artikel beschriebenen Ablauf eine realistische Hausnummer.

Die Schritt-für-Schritt-Anleitung im Überblick

Die folgenden zwölf Schritte führen von der leeren Python-Umgebung zu einem fertigen, quantisierten Adapter, der lokal läuft. Jeder Schritt baut auf dem vorherigen auf, du kannst aber nach Schritt 8 (Evaluation) bereits ein erstes lauffähiges Ergebnis testen, bevor du in Deployment und Quantisierung investierst.

Schritt 1 – Entwicklungsumgebung einrichten

Lege zuerst eine isolierte virtuelle Umgebung an, damit Paketversionen sich nicht mit anderen Projekten in die Quere kommen. Danach installierst du die Kernbibliotheken für Training und Quantisierung.

python3 -m venv lora-finetune
source lora-finetune/bin/activate

pip install --upgrade pip
pip install -U transformers peft trl bitsandbytes accelerate datasets
pip install -U torch --index-url https://download.pytorch.org/whl/cu124

python -c "import torch; print(torch.cuda.is_available(), torch.cuda.get_device_name(0))"

Gibt der letzte Befehl True und den Namen deiner GPU aus, ist die CUDA-Anbindung korrekt. Bricht der Import mit einem Fehler zu fehlenden CUDA-Bibliotheken ab, prüfe zuerst, ob dein installierter NVIDIA-Treiber zur gewählten PyTorch-CUDA-Version passt.

Schritt 2 – Basismodell und Lizenz wählen

Lade zunächst nur die Modellkarte und die Lizenzbedingungen, bevor du Gigabyte an Gewichten herunterlädst. Bei Gemma 3 verlangt Hugging Face eine einmalige Bestätigung der Nutzungsbedingungen im Web-Interface, danach funktioniert der Download über die huggingface-cli ohne weitere Bestätigung. Bei Llama 4 gilt dasselbe Prinzip, die Meta-Lizenz erlaubt laut Ankündigung vom 27. Juli 2026 kommerzielle Nutzung und Fine-Tuning ohne zusätzliche Einschränkungen.

huggingface-cli login

python -c "
from transformers import AutoModelForCausalLM, AutoTokenizer
model_id = 'google/gemma-3-7b'
tok = AutoTokenizer.from_pretrained(model_id)
print(tok.model_max_length, tok.vocab_size)
"

Wenn dieser Aufruf ohne Fehler durchläuft, ist der Zugriff freigeschaltet und der Tokenizer geladen. Notiere dir hier Kontextlänge und Vokabulargröße, du brauchst beide Werte später beim Zuschneiden der Trainingsdaten.

Bei der Modellwahl zählt neben Lizenz und VRAM-Bedarf auch, wie gut das Modell die Zielsprache beherrscht. Für deutschsprachige Anwendungsfälle lohnt sich vor dem Training ein kurzer Test des unveränderten Basismodells mit einigen typischen deutschen Anfragen, um zu prüfen, ob Grammatik und Wortwahl bereits ohne Fine-Tuning überzeugen. Ein Modell, das im Ausgangszustand bei deutschen Fachbegriffen schwächelt, wird durch ein kleines Fine-Tuning selten grundlegend besser, weil LoRA vor allem Stil und Format justiert und weniger sprachliche Grundfähigkeiten nachträgt.

Schritt 3 – Datensatz vorbereiten und formatieren

Die Qualität des Datensatzes entscheidet stärker über das Ergebnis als jeder Hyperparameter. Für ein Fine-Tuning auf Support-Antworten oder internen Stil reichen oft schon 200 bis 2.000 saubere Beispiele, mehr hilft, aber nur wenn die Qualität stimmt. Jedes Beispiel folgt einem festen Chat-Format mit Rollen, damit das Modell lernt, wann es antworten soll und wann nicht.

{"messages": [
  {"role": "system", "content": "Du bist der Support-Assistent von Muster GmbH. Antworte knapp, freundlich und auf Deutsch."},
  {"role": "user", "content": "Mein Login funktioniert seit dem Update nicht mehr."},
  {"role": "assistant", "content": "Das tut mir leid. Bitte lösche zuerst den Browser-Cache und versuche es erneut. Bleibt das Problem bestehen, sende mir deine Kundennummer per privater Nachricht."}
]}

Speichere jede Zeile als eigenes JSON-Objekt in einer .jsonl-Datei, das ist das Standardformat für den SFTTrainer aus der TRL-Bibliothek. Teile den Datensatz danach in Trainings- und Validierungsdaten auf, ein Verhältnis von 90 zu 10 hat sich in der Praxis bewährt.

Als Datenquelle eignen sich historische Support-Tickets, interne Wikis, bereits freigegebene Vorlagenantworten oder von Fachleuten manuell erstellte Beispiele. Wichtig ist, dass die Beispiele die Bandbreite echter Anfragen widerspiegeln, nicht nur die einfachsten Fälle. Enthält der Rohdatensatz personenbezogene Informationen, entferne oder pseudonymisiere Namen, Adressen und Kundennummern, bevor die Daten in den Trainingsprozess gehen, dazu mehr im Abschnitt zu Datenschutz weiter unten.

from datasets import load_dataset

ds = load_dataset("json", data_files="support_daten.jsonl", split="train")
ds = ds.train_test_split(test_size=0.1, seed=42)
print(ds)

LoRA und QLoRA konfigurieren

Schritt 4 – LoRA-Hyperparameter festlegen

LoRA friert die ursprünglichen Gewichte des Modells ein und trainiert stattdessen kleine, niedrigrangige Matrizen, die zusätzlich zu jeder Ziel-Schicht addiert werden. Die Idee stammt aus dem 2021 veröffentlichten Paper von Edward Hu und Kolleg:innen und ist inzwischen der De-facto-Standard für ressourcenschonendes Fine-Tuning. Zwei Werte bestimmen dabei am meisten: der Rang r, der die Größe der Adapter-Matrizen festlegt, und lora_alpha, ein Skalierungsfaktor.

from peft import LoraConfig, TaskType

lora_config = LoraConfig(
    task_type=TaskType.CAUSAL_LM,
    r=16,
    lora_alpha=32,
    lora_dropout=0.05,
    target_modules=["q_proj", "k_proj", "v_proj", "o_proj"],
    bias="none",
)

Ein Rang von 16 mit Alpha 32 ist ein guter Startpunkt für Stil- und Formatanpassungen. Willst du dagegen neues Fachwissen einbringen, etwa juristische oder medizinische Terminologie, erhöhst du den Rang schrittweise auf 32 oder 64 und beobachtest, ob sich Validierungsverlust und Ausgabequalität verbessern.

Die Auswahl der target_modules beeinflusst das Ergebnis mindestens genauso stark wie der Rang. Beschränkst du dich auf die Attention-Projektionen q_proj und v_proj, trainierst du besonders sparsam, was für einfache Stilanpassungen oft ausreicht. Nimmst du zusätzlich die Feed-Forward-Schichten wie gate_proj, up_proj und down_proj hinzu, steigt die Kapazität des Adapters spürbar, was bei komplexeren Aufgaben wie strukturierten JSON-Ausgaben oder mehrstufigen Anweisungen häufig den Ausschlag gibt.

Schritt 5 – Quantisierung mit bitsandbytes

QLoRA lädt das Basismodell in 4-Bit-Präzision und hält nur die trainierbaren LoRA-Matrizen in höherer Präzision. Das senkt den Speicherbedarf für ein 7-Milliarden-Parameter-Modell von etwa 28 GB auf rund 5 bis 6 GB für die reinen Gewichte, Aktivierungen und Optimizer-Zustand kommen noch dazu.

from transformers import BitsAndBytesConfig
import torch

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

model = AutoModelForCausalLM.from_pretrained(
    "google/gemma-3-7b",
    quantization_config=bnb_config,
    device_map="auto",
)

Achte darauf, bfloat16 statt float16 als Rechen-Datentyp zu verwenden, sofern deine GPU das unterstützt. Auf älteren Karten ohne native bfloat16-Unterstützung führt das sonst zu instabilen Trainingsverläufen mit NaN-Werten im Loss.

Training starten und überwachen

Schritt 6 – SFTTrainer konfigurieren und starten

Der SFTTrainer aus der TRL-Bibliothek kombiniert Modell, Datensatz und LoRA-Konfiguration in einer einzigen Trainingsschleife. Für die ersten Testläufe reichen zwei bis drei Epochen, mehr Epochen erhöhen bei kleinen Datensätzen schnell das Risiko von Overfitting.

from trl import SFTTrainer, SFTConfig

config = SFTConfig(
    output_dir="./gemma3-support-adapter",
    per_device_train_batch_size=2,
    gradient_accumulation_steps=8,
    num_train_epochs=3,
    learning_rate=2e-4,
    logging_steps=10,
    save_strategy="epoch",
    bf16=True,
    gradient_checkpointing=True,
)

trainer = SFTTrainer(
    model=model,
    args=config,
    train_dataset=ds["train"],
    eval_dataset=ds["test"],
    peft_config=lora_config,
)

trainer.train()

Die Kombination aus kleiner Batch-Größe und gradient_accumulation_steps=8 simuliert eine größere effektive Batch-Größe von 16, ohne dass der VRAM-Bedarf entsprechend steigt. Das ist der wichtigste Hebel, wenn dir während des Trainings der Speicher ausgeht. Erhöhe zuerst die Accumulation-Schritte, bevor du an der Sequenzlänge oder am LoRA-Rang sparst, denn beide beeinflussen direkt die Qualität des Ergebnisses, während die effektive Batch-Größe vor allem die Trainingsstabilität betrifft.

Schritt 7 – Trainingsverlauf prüfen

Beobachte während des Trainings zwei Kurven: den Trainings-Loss und den Validierungs-Loss. Sinkt der Trainings-Loss stetig, während der Validierungs-Loss nach ein paar hundert Schritten wieder steigt, overfittet das Modell auf die Trainingsdaten. In diesem Fall reduzierst du entweder die Anzahl der Epochen oder erhöhst lora_dropout.

# Beispielhafter Ausgabe-Log während des Trainings
{'loss': 1.842, 'grad_norm': 0.91, 'learning_rate': 0.00018, 'epoch': 0.4}
{'loss': 1.203, 'grad_norm': 0.77, 'learning_rate': 0.00014, 'epoch': 1.2}
{'loss': 0.891, 'grad_norm': 0.65, 'learning_rate': 0.00008, 'epoch': 2.1}
{'eval_loss': 0.94, 'epoch': 3.0}

Ein Trainings-Loss, der von über 1,8 auf unter 1,0 fällt, ist bei den meisten Chat-Formaten ein gutes Zeichen. Liegt der Validierungs-Loss am Ende deutlich über dem Trainings-Loss, etwa mehr als 0,3 Punkte auseinander, ist das ein klares Overfitting-Signal.

Modell evaluieren und testen (Schritt 8)

Automatische Metriken wie Perplexity geben nur einen groben Hinweis darauf, ob das Fine-Tuning funktioniert hat. Entscheidend ist der manuelle Test mit realistischen Eingaben, die im Trainingsdatensatz nicht vorkamen. Lade dazu den Adapter zusätzlich zum Basismodell und vergleiche die Antworten vor und nach dem Training.

from peft import PeftModel

base = AutoModelForCausalLM.from_pretrained("google/gemma-3-7b", quantization_config=bnb_config, device_map="auto")
tuned = PeftModel.from_pretrained(base, "./gemma3-support-adapter")

prompt = "Ich habe meine Rechnung nicht per E-Mail bekommen."
inputs = tokenizer(prompt, return_tensors="pt").to(tuned.device)
out = tuned.generate(**inputs, max_new_tokens=120, temperature=0.3)
print(tokenizer.decode(out[0], skip_special_tokens=True))

Baue dir für konsistente Tests eine feste Liste von 15 bis 20 Beispielanfragen, die den typischen Alltag deines Anwendungsfalls abdecken, und lasse sowohl das Basismodell als auch den fine-getunten Adapter jede davon beantworten. So erkennst du schnell, ob sich Ton, Struktur und Genauigkeit tatsächlich in die gewünschte Richtung verschoben haben, statt dich auf einen einzelnen guten Testlauf zu verlassen.

Automatisierte Evaluierung: Über den manuellen Test hinaus

Manuelle Stichproben reichen für den ersten Eindruck, sind aber schlecht geeignet, um zwei Trainingsläufe objektiv zu vergleichen oder eine Regression frühzeitig zu erkennen, wenn du den Datensatz später erweiterst. Für ein wiederholbares Evaluationsverfahren lohnt sich ein fester Satz von Testfällen, den du bei jedem neuen Adapter automatisch durchlaufen lässt.

Ein einfacher, aber wirkungsvoller Ansatz ist die Kombination aus regelbasierten Prüfungen und einem zweiten, stärkeren Modell als Bewerter. Regelbasierte Prüfungen fangen harte Fehler ab, etwa ob eine erwartete Kategorie im JSON-Feld der Antwort auftaucht oder ob die Antwortlänge eine sinnvolle Obergrenze einhält. Ein zweites Modell, das die Antwort auf einer Skala von eins bis fünf nach Tonfall, Genauigkeit und Format bewertet, deckt danach die weicheren Qualitätsaspekte ab, die sich schlecht in feste Regeln fassen lassen.

import json

def check_format(antwort: str) -> bool:
    pflichtfelder = ["kategorie", "prioritaet"]
    try:
        data = json.loads(antwort)
    except json.JSONDecodeError:
        return False
    return all(feld in data for feld in pflichtfelder)

ergebnisse = [check_format(r) for r in generierte_antworten]
quote = sum(ergebnisse) / len(ergebnisse)
print(f"Formatkonformität: {quote:.1%}")

Speichere die Ergebnisse jedes Evaluationslaufs zusammen mit der jeweiligen Adapter-Version. So siehst du auf einen Blick, ob ein neuer Datensatz oder eine geänderte Lernrate die Formatkonformität und Bewertungsqualität tatsächlich verbessert hat, statt dich auf dein Bauchgefühl beim Lesen einzelner Antworten zu verlassen.

Adapter zusammenführen und exportieren (Schritt 9)

Für den produktiven Einsatz lohnt es sich oft, den LoRA-Adapter mit dem Basismodell zu einem einzigen Gewichtssatz zu verschmelzen. Das entfernt die kleine Latenz, die durch das getrennte Laden von Basis und Adapter entsteht, und vereinfacht das spätere Deployment.

merged_model = tuned.merge_and_unload()
merged_model.save_pretrained("./gemma3-support-merged")
tokenizer.save_pretrained("./gemma3-support-merged")

Nach dem Merge liegt im Zielordner ein vollständiges Modell, das sich wie jedes andere Hugging-Face-Modell laden lässt, ganz ohne PEFT-Abhängigkeit. Behalte trotzdem den ursprünglichen, nicht verschmolzenen Adapter, falls du später mit einem anderen Basismodell erneut kombinieren willst.

Deployment: Von Hugging Face zu Ollama und LM Studio (Schritt 10–11)

Für den lokalen Alltagseinsatz ist das gemergte Hugging-Face-Format meist zu groß und zu langsam. Ollama und LM Studio erwarten stattdessen das GGUF-Format, das speziell für effiziente CPU- und GPU-Inferenz über llama.cpp entwickelt wurde. Konvertiere dein Modell dafür mit dem Konvertierungsskript aus dem llama.cpp-Repository.

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
pip install -r requirements.txt

python convert_hf_to_gguf.py ../gemma3-support-merged \
  --outfile gemma3-support-f16.gguf \
  --outtype f16

Danach erstellst du in Ollama ein einfaches Modelfile, das auf die GGUF-Datei verweist, und importierst das Modell mit einem einzigen Befehl. Ab diesem Punkt läuft dein fine-getuntes Modell lokal, ohne API-Kosten und ohne dass Trainingsdaten das eigene Netzwerk verlassen müssen.

LM Studio nimmt dieselbe GGUF-Datei entgegen, bietet dafür aber eine grafische Oberfläche samt lokalem API-Server, der sich wie eine OpenAI-kompatible Schnittstelle ansprechen lässt. Das eignet sich gut, wenn Kolleg:innen ohne Kommandozeilen-Erfahrung das Modell testen sollen, oder wenn eine bestehende Anwendung ohnehin schon gegen eine OpenAI-kompatible API spricht und nur die Basis-URL umgestellt werden muss. Für automatisierte Deployments in einer Serverumgebung ist dagegen Ollama meist die schlankere Wahl, weil es sich ohne grafische Oberfläche als Hintergrunddienst betreiben lässt.

Willst du das Modell stattdessen über eine eigene API-Anwendung ansprechen, reicht ein einfacher HTTP-Aufruf gegen den lokalen Ollama-Server, der standardmäßig auf Port 11434 lauscht. Das erlaubt es, den Support-Bot etwa direkt in ein bestehendes Ticket-System einzubinden, ohne dass Anfragen jemals das eigene Netzwerk verlassen.

Quantisierung für den lokalen Einsatz (Schritt 12)

Die F16-GGUF-Datei aus dem letzten Schritt ist noch relativ groß, bei einem 7B-Modell etwa 14 bis 15 GB. Für den Alltag auf einem Notebook oder einer kleineren GPU quantisierst du sie zusätzlich auf 4 oder 5 Bit, was die Dateigröße auf ein Drittel bis die Hälfte senkt und die Antwortgeschwindigkeit spürbar erhöht.

./llama-quantize gemma3-support-f16.gguf gemma3-support-q4_k_m.gguf Q4_K_M

cat > Modelfile << 'EOF'
FROM ./gemma3-support-q4_k_m.gguf
PARAMETER temperature 0.3
SYSTEM "Du bist der Support-Assistent von Muster GmbH."
EOF

ollama create support-bot -f Modelfile
ollama run support-bot

Q4_K_M ist bei den meisten Alltagsaufgaben ein guter Kompromiss zwischen Dateigröße und Antwortqualität. Bei Anwendungen, die auf Zahlen oder Fachbegriffe besonders genau reagieren müssen, lohnt sich ein Test mit Q5_K_M oder Q6_K, auf Kosten von etwas mehr Speicherplatz.

Datenschutz und Lizenzfragen beim Fine-Tuning in der DACH-Region

Sobald echte Kundendaten, Support-Tickets oder interne Dokumente in einen Trainingsdatensatz fließen, ist Fine-Tuning kein rein technisches Thema mehr, sondern ein datenschutzrechtliches. Trainierst du lokal auf eigener Hardware, verlassen die Daten dein Netzwerk nicht, was die DSGVO-Bewertung gegenüber einem Cloud-Training bei einem externen Anbieter deutlich vereinfacht. Trotzdem bleibt die Pflicht bestehen, personenbezogene Daten vor dem Training zu pseudonymisieren oder zu entfernen, insbesondere Namen, E-Mail-Adressen und Kundennummern in Support-Transkripten.

Ein zweiter, oft übersehener Punkt ist die Lizenz des Basismodells selbst. Gemma 3 und die offenen Qwen3.8- und Qwen-3.6-Modelle stehen unter Apache 2.0 und erlauben kommerzielle Nutzung sowie Weiterverbreitung von Fine-Tunes ohne zusätzliche Einschränkungen. Bei Llama 4 gilt laut Metas Ankündigung vom 27. Juli 2026 zwar ebenfalls eine kommerzielle Freigabe, die genaue Formulierung der Lizenzbedingungen solltest du dennoch vor dem produktiven Einsatz selbst prüfen, insbesondere wenn dein Unternehmen den fine-getunten Adapter oder das gemergte Modell an Dritte weitergeben will. Bei Qwen3.8-2.4T-A95B gilt eine eigene, angepasste Lizenz statt Apache 2.0, das solltest du bei der Modellwahl einplanen, falls Weitergabe an Kunden Teil deines Geschäftsmodells ist.

Für Teams, die im Auftrag Dritter mit sensiblen Daten arbeiten, etwa im Finanz- oder Gesundheitssektor, lohnt sich zusätzlich eine kurze Auftragsverarbeitungs-Prüfung, auch wenn das Training komplett lokal läuft. Das Basismodell selbst verarbeitet beim Training keine Daten an Dritte weiter, aber Tools wie Weights & Biases zur Verlaufsverfolgung senden Metriken standardmäßig an externe Server. Wer das vermeiden will, schaltet das entsprechende Logging auf lokalen Modus oder deaktiviert es vollständig.

Dokumentiere zusätzlich, welche Datenquelle, welche Bereinigungsschritte und welche Modellversion in jeden Trainingslauf eingeflossen sind. Diese Dokumentation kostet beim ersten Adapter nur wenige Minuten, erspart aber bei einer späteren Anfrage nach Rechenschaftspflicht oder bei einem internen Audit die aufwendige Rekonstruktion im Nachhinein.

Kosten im Vergleich: Eigene GPU vs. Cloud-Training

Ob sich eigene Hardware oder ein Cloud-GPU-Mietmodell lohnt, hängt vor allem davon ab, wie oft du trainierst. Für ein einmaliges Projekt ist eine gemietete GPU-Stunde meist günstiger als der Kauf einer eigenen Karte. Trainierst du dagegen regelmäßig neue Adapter-Versionen, etwa monatlich mit aktualisierten Support-Daten, amortisiert sich eigene Hardware schneller.

Ansatz	Vorlaufkosten	Laufende Kosten	Am besten geeignet für
Eigene RTX-4090-Workstation	Hoch (Hardware-Kauf)	Strom, keine Miete	Regelmäßiges Training, sensible Daten, feste Teams
Gemietete Cloud-GPU (nach Bedarf)	Keine	Pro GPU-Stunde	Einzelprojekte, Experimente, unklarer Bedarf
Managed Fine-Tuning-Service	Keine	Pro Trainingslauf oder Abo	Teams ohne eigene ML-Infrastruktur

Für die meisten der in diesem Artikel gezeigten Trainingsläufe mit 7- bis 8-Milliarden-Parameter-Modellen und einigen hundert bis wenigen tausend Beispielen reicht eine einzelne gemietete GPU mit 24 GB VRAM für wenige Stunden aus. Erst bei größeren Modellen wie Qwen 3.6-35B-A3B oder bei sehr großen, mehrfach wiederholten Trainingsläufen wird eine dedizierte Multi-GPU-Umgebung wirtschaftlich interessant.

Ein oft unterschätzter Kostenfaktor ist die Iterationszahl. Selten trifft der erste Trainingslauf schon die gewünschte Balance aus Ton, Format und Genauigkeit. Rechne von Beginn an mit drei bis fünf Durchläufen, bis Datensatz und Hyperparameter zusammenpassen. Bei einer gemieteten GPU multipliziert sich der Stundenpreis entsprechend, bei eigener Hardware fällt nur der Stromverbrauch zusätzlich an. Das spricht dafür, die ersten Experimente bewusst mit einem kleineren, günstigeren Modell wie Mistral Shieldstral-1.0-3B zu fahren und erst für den finalen Lauf auf ein größeres Basismodell zu wechseln, sobald Datensatz und Konfiguration stabil sind.

Fünf häufige Fehler beim LLM Fine-Tuning

Die meisten gescheiterten Fine-Tuning-Versuche haben weniger mit exotischen Bugs zu tun als mit denselben fünf wiederkehrenden Fallen. Wer diese vor dem ersten produktiven Trainingslauf kennt, spart sich mehrere Iterationen und damit auch GPU-Stunden.

Zu wenig, zu einseitige Trainingsdaten. 50 Beispiele aus einer einzigen Support-Kategorie erzeugen ein Modell, das außerhalb dieser Kategorie unbrauchbar antwortet. Streue die Beispiele über die tatsächliche Verteilung deiner echten Anfragen.
Falsches Chat-Template. Jedes Modell erwartet ein bestimmtes Format für System-, User- und Assistant-Rollen. Nutzt du das Template eines anderen Modells, lernt das Modell inkonsistente Muster, die sich erst in der Produktion zeigen.
Zu viele Epochen auf zu kleinem Datensatz. Fünf oder mehr Epochen auf 200 Beispielen führen fast immer zu Overfitting. Das Modell wiederholt dann Trainingssätze fast wörtlich, statt zu generalisieren.
Lernrate zu hoch gewählt. Werte über 5e-4 bringen den Trainingsverlauf bei LoRA schnell zum Kippen, erkennbar an sprunghaften Loss-Werten oder NaN-Ausgaben.
Kein Vergleich gegen das unveränderte Basismodell. Ohne Baseline lässt sich nicht sagen, ob das Fine-Tuning tatsächlich etwas verbessert hat oder nur zufällig anders klingt.

Troubleshooting: Acht Probleme und ihre Lösungen

Diese Übersicht deckt die Probleme ab, auf die Teams beim ersten eigenen Fine-Tuning-Lauf am häufigsten stoßen. Die meisten davon lassen sich in wenigen Minuten beheben, sobald die Ursache klar ist, kosten ohne diese Übersicht aber oft einen kompletten Nachmittag Fehlersuche.

Problem	Wahrscheinliche Ursache	Lösung
CUDA Out of Memory	Batch-Größe oder Sequenzlänge zu hoch	Gradient Checkpointing aktivieren, Batch-Größe senken, Gradient Accumulation erhöhen
Loss wird NaN oder Inf	Lernrate zu hoch oder fp16 auf inkompatibler GPU	Lernrate halbieren, auf bfloat16 wechseln, Gradient Clipping aktivieren
Modell verliert Basisfähigkeiten	LoRA-Rang zu hoch, zu viele Epochen	Rang und Epochenzahl reduzieren, Dropout erhöhen
Adapter lädt nicht nach dem Training	Adapter wurde auf anderem Basismodell trainiert als beim Laden verwendet	Exakt dieselbe Basismodell-ID beim Laden angeben
Loss sinkt, Antworten bleiben schlecht	Datensatz zu klein oder falsches Prompt-Format	Mehr Beispiele sammeln, Chat-Template gegen Modellkarte prüfen
GGUF-Konvertierung schlägt fehl	Architektur wird vom Konvertierungsskript noch nicht unterstützt	llama.cpp auf aktuellen Stand bringen, Architektur-Support in den Release Notes prüfen
Training extrem langsam trotz GPU	bitsandbytes-CUDA-Kernel nicht korrekt installiert	bitsandbytes neu installieren, CUDA-Version mit PyTorch abgleichen
Multi-GPU-Training bricht mit NCCL-Fehler ab	Fehlende oder falsche Accelerate-Konfiguration	`accelerate config` erneut ausführen, NCCL-Version mit Treiber abgleichen

Tritt ein Problem auf, das hier nicht auftaucht, hilft meist ein Blick in die Trainings-Logs direkt vor dem Absturz. Die überwiegende Mehrheit der Fehler in QLoRA-Setups lässt sich auf eine von drei Ursachen zurückführen: zu wenig VRAM, eine falsch konfigurierte Quantisierung oder eine Versionsinkompatibilität zwischen Transformers, PEFT, TRL und bitsandbytes. Ein frisches virtuelles Environment mit den jeweils aktuellen Versionen aller vier Bibliotheken löst überraschend viele dieser Fälle bereits von allein.

Fortgeschrittene Tipps: Spectrum, DoRA und Multi-GPU-Training

Sobald der Standardablauf zuverlässig läuft, lohnen sich vier Techniken für bessere Ergebnisse oder mehr Kontrolle. Keine davon ist für den Einstieg notwendig, sie werden aber relevant, sobald du über den ersten erfolgreichen Adapter hinaus systematisch bessere Ergebnisse oder größere Modelle angehst.

Die erste ist DoRA (Weight-Decomposed Low-Rank Adaptation), eine 2024 vorgestellte Weiterentwicklung von LoRA, die Gewichte in Richtung und Magnitude zerlegt und dadurch in mehreren Benchmarks eine höhere Genauigkeit bei gleicher Parameterzahl erreicht. In PEFT aktivierst du DoRA mit einem einzigen zusätzlichen Flag in der LoraConfig.

Die zweite Technik ist selektives Layer-Training, bei dem nicht alle, sondern nur bestimmte Schichten des Modells für das Training freigegeben werden. Das reduziert den Speicherbedarf zusätzlich und eignet sich besonders, wenn nur ein enger Aspekt des Modellverhaltens angepasst werden soll, etwa Ausgabeformat statt Weltwissen.

Die dritte Technik betrifft die Skalierung: Reicht eine GPU nicht mehr aus, etwa für Qwen 3.6-35B-A3B oder größere Datensätze, verteilst du das Training mit Accelerate und DeepSpeed ZeRO über mehrere Karten. Starte dafür mit ZeRO Stage 2, das Optimizer-Zustände über die GPUs verteilt, ohne die Kommunikationslast von Stage 3 zu erzeugen.

Eine vierte, weniger bekannte Stellschraube ist Sequence Packing: Statt jede Trainingsprobe einzeln mit Padding auf die maximale Länge aufzufüllen, werden mehrere kurze Beispiele in eine Sequenz gepackt. Das reduziert verschwendete Rechenzeit auf Padding-Tokens spürbar und beschleunigt gerade bei kurzen Chat-Beispielen den Trainingsdurchlauf, ohne dass sich an Modell oder Datensatz etwas ändert.

accelerate config
# Interaktiv: Multi-GPU, DeepSpeed ZeRO Stage 2, bf16 auswählen

accelerate launch train_lora.py --config gemma3_lora.yaml

Vollständiges Projektbeispiel: Support-Bot in unter 150 Zeilen Code

Die folgende Zusammenfassung bündelt alle vorherigen Schritte zu einem lauffähigen Skript. Es liest einen JSONL-Datensatz ein, trainiert einen LoRA-Adapter auf Gemma 3 7B und speichert das Ergebnis für den anschließenden Export.

import torch
from datasets import load_dataset
from transformers import AutoModelForCausalLM, AutoTokenizer, BitsAndBytesConfig
from peft import LoraConfig, TaskType
from trl import SFTTrainer, SFTConfig

MODEL_ID = "google/gemma-3-7b"
DATA_FILE = "support_daten.jsonl"
OUTPUT_DIR = "./gemma3-support-adapter"

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

tokenizer = AutoTokenizer.from_pretrained(MODEL_ID)
model = AutoModelForCausalLM.from_pretrained(
    MODEL_ID, quantization_config=bnb_config, device_map="auto"
)

ds = load_dataset("json", data_files=DATA_FILE, split="train")
ds = ds.train_test_split(test_size=0.1, seed=42)

lora_config = LoraConfig(
    task_type=TaskType.CAUSAL_LM,
    r=16,
    lora_alpha=32,
    lora_dropout=0.05,
    target_modules=["q_proj", "k_proj", "v_proj", "o_proj"],
    bias="none",
)

sft_config = SFTConfig(
    output_dir=OUTPUT_DIR,
    per_device_train_batch_size=2,
    gradient_accumulation_steps=8,
    num_train_epochs=3,
    learning_rate=2e-4,
    logging_steps=10,
    save_strategy="epoch",
    bf16=True,
    gradient_checkpointing=True,
)

trainer = SFTTrainer(
    model=model,
    args=sft_config,
    train_dataset=ds["train"],
    eval_dataset=ds["test"],
    peft_config=lora_config,
)

if __name__ == "__main__":
    trainer.train()
    trainer.save_model(OUTPUT_DIR)
    tokenizer.save_pretrained(OUTPUT_DIR)
    print("Training abgeschlossen. Adapter liegt in", OUTPUT_DIR)

Führe das Skript mit python train_lora.py aus. Auf einer RTX 4090 mit 24 GB VRAM dauert ein Durchlauf mit 500 Trainingsbeispielen über drei Epochen typischerweise 20 bis 40 Minuten, abhängig von der Sequenzlänge deiner Beispiele. Kombiniere das Skript mit den Export- und Quantisierungsschritten von weiter oben, um vom Training direkt zu einem lauffähigen Ollama-Modell zu kommen.

Häufig gestellte Fragen

Wie viele Trainingsbeispiele braucht man für ein gutes Fine-Tuning-Ergebnis?
Für Stil- und Format-Anpassungen reichen oft 200 bis 500 saubere Beispiele. Für neues Fachwissen oder komplexe Aufgaben sind 1.000 bis 5.000 Beispiele realistischer. Qualität und Vielfalt der Daten wiegen dabei mehr als die reine Menge.

Reicht eine Consumer-GPU wie eine RTX 4090 für Fine-Tuning aus?
Für QLoRA-Training an 7- bis 8-Milliarden-Parameter-Modellen wie Gemma 3 7B oder die kleine Llama-4-Variante reicht eine 24-GB-Karte in der Regel aus. Größere Modelle wie Qwen 3.6-35B-A3B benötigen entweder mehr VRAM oder mehrere GPUs.

Was ist der Unterschied zwischen LoRA und vollständigem Fine-Tuning?
Vollständiges Fine-Tuning passt alle Parameter des Modells an und benötigt entsprechend viel Speicher und Rechenzeit. LoRA friert die Originalgewichte ein und trainiert nur kleine, zusätzliche Matrizen, was Speicherbedarf und Trainingszeit drastisch senkt, bei meist vergleichbarer Qualität für spezialisierte Aufgaben.

Kann man mehrere LoRA-Adapter auf demselben Basismodell kombinieren?
Ja. PEFT unterstützt das Laden mehrerer Adapter gleichzeitig und das Umschalten zwischen ihnen zur Laufzeit, ohne das Basismodell neu zu laden. Das eignet sich etwa, um für verschiedene Kunden oder Sprachen jeweils eigene Adapter bereitzuhalten.

Welches offene Modell eignet sich 2026 am besten für den Einstieg?
Gemma 3 7B und die kleine Llama-4-Variante sind für den Einstieg gut geeignet, weil beide auf einer einzelnen 24-GB-GPU trainierbar sind und unter permissiven Lizenzen stehen. Wer besonders knappe Hardware hat, startet mit Mistral Shieldstral-1.0-3B.

Wie lange dauert ein typisches Fine-Tuning-Projekt insgesamt?
Der technische Trainingslauf selbst dauert je nach Datensatzgröße oft nur 20 bis 90 Minuten. Die Datensammlung, das Formatieren der Beispiele und die anschließende Evaluation nehmen in der Praxis deutlich mehr Zeit in Anspruch, häufig mehrere Tage.

Muss man den fine-getunten Adapter zwingend mit dem Basismodell zusammenführen?
Nein. Für Experimente und schnelle Iteration lässt sich der Adapter separat laden. Für den produktiven Einsatz und die GGUF-Konvertierung ist ein Merge aber sinnvoll, weil dadurch Ladezeit und Komplexität sinken.

Was, wenn nach dem Fine-Tuning Datenschutzanforderungen nachträglich ein Trainingsbeispiel betreffen?
Ein LoRA-Adapter lässt sich nicht gezielt um einzelne Trainingsbeispiele bereinigen, das Wissen steckt verteilt in den Gewichten. In diesem Fall bleibt nur, den Datensatz zu korrigieren und den Adapter komplett neu zu trainieren. Das ist ein weiterer Grund, den Trainingsdatensatz schon vor dem ersten Lauf sorgfältig auf personenbezogene Daten zu prüfen.

Fazit: Fine-Tuning ist 2026 kein Konzern-Privileg mehr

Mit offenen Modellen wie Gemma 3, Llama 4 und Qwen3.8-27B sowie einer einzelnen Consumer-GPU lässt sich ein spezialisiertes Sprachmodell heute in wenigen Tagen bauen statt in Wochen. Der größte Hebel bleibt dabei nicht die Wahl der Hyperparameter, sondern ein sauberer, repräsentativer Datensatz. Wer klein anfängt, das Ergebnis konsequent gegen das unveränderte Basismodell testet und Schritt für Schritt nachjustiert, kommt mit den hier gezeigten zwölf Schritten zu einem Modell, das lokal läuft und keine laufenden API-Kosten verursacht.

Der nächste sinnvolle Schritt nach dem ersten erfolgreichen Adapter ist selten ein größeres Modell, sondern ein größerer, saubererer Datensatz und ein festes Evaluationsverfahren. Beides zahlt sich stärker aus als jede zusätzliche Trainingsstunde auf denselben wenigen hundert Beispielen. Wer diesen Kreislauf aus Training, Evaluation und Datensatz-Verbesserung einmal etabliert hat, kann ihn bei jedem neuen offenen Modell, das in den kommenden Monaten erscheint, ohne große Umstellung wiederverwenden.

Quellen zu den in diesem Artikel genutzten Techniken: das Original-Paper zu LoRA, das Paper zu DoRA, die offizielle PEFT-Dokumentation, die TRL-Dokumentation sowie die Ankündigung von Qwen3.8 durch Alibaba.

LLM Fine-Tuning mit LoRA: 12 Schritte, 60 Min [2026]