QLoRA Fine-Tuning mit Unsloth: Eigenes LLM auf einer Consumer-GPU spezialisieren
Wer bereits ein lokales Llama- oder Qwen-Modell per Ollama betreibt, kann es mit QLoRA und Unsloth auf eigene Firmendaten spezialisieren – auf einer RTX 3060 oder RTX 4060 mit 8 GB VRAM, vollständig lokal und ohne Cloud-Abhängigkeit.

Du betreibst bereits ein lokales Sprachmodell per Ollama – und fragst dich, ob du es auf die eigenen Produkte, Prozesse oder FAQ-Inhalte deines Unternehmens zuschneiden kannst. Genau das ermöglicht QLoRA Fine-Tuning mit Unsloth: ein vortrainiertes Open-Source-LLM wie Llama 3.1 8B oder Qwen 2.5 7B bekommt dabei zusätzliche, schlanke Adapter-Gewichte, die auf deinen Firmendaten trainiert wurden – ganz ohne Volltraining, ohne Cloud und auf einer handelsüblichen Gaming-GPU ab 8 GB VRAM. Das Ergebnis ist ein spezialisiertes Modell, das du anschließend als GGUF-Datei direkt in Ollama importierst und genau wie jedes andere Modell nutzt.
Voraussetzungen
- NVIDIA-GPU mit mindestens 8 GB VRAM und CUDA Capability ≥ 7.0 (ab RTX 20er-Serie, z. B. RTX 2080, RTX 3060 8 GB, RTX 4060 8 GB)
- Python 3.11–3.13 (Python 3.14 wird derzeit nicht unterstützt); virtuelle Umgebung per
venvoder Conda empfohlen - Betriebssystem: Windows 10/11 (nativ via PowerShell-Installer oder WSL2), Linux (Ubuntu 22.04/24.04)
- NVIDIA-Treiber mit CUDA 12.4+ (für RTX 50er Blackwell: CUDA 12.8+); bei PowerShell-Installer wird die passende CUDA-Version automatisch gewählt
- Ollama lokal installiert (für den späteren Import des fertig trainierten Modells)
- Firmendaten im JSONL-Format (Alpaca-Format, mindestens 200 Einträge; siehe Schritt 4)
- Mindestens 10 GB freier Festplattenspeicher für Modell-Download (~4–5 GB für ein 8B-Modell), Adapter und Exportdateien
- Internetverbindung für den initialen Modell-Download von HuggingFace
Was ist QLoRA – und warum Unsloth?
Beim klassischen LoRA (Low-Rank Adaptation) werden kleine Adapter-Matrizen an die Gewichtsschichten eines Modells angehängt. Nur diese Adapter werden trainiert – rund 0,1–1 % der Gesamtparameter. Das Basismodell bleibt eingefroren. Das spart Rechenzeit, aber das Modell selbst liegt weiterhin in voller 16-Bit-Präzision im VRAM, was für ein 8B-Modell immer noch ~22 GB bedeutet.
QLoRA geht einen Schritt weiter: Das Basismodell wird zusätzlich in 4-Bit-Quantisierung geladen (via BitsAndBytes), während die Adapter trotzdem in 16-Bit trainiert werden. Damit sinkt der VRAM-Bedarf für ein 8B-Modell auf rund 6 GB – genug für eine RTX 4060 mit 8 GB VRAM.
Unsloth (Apache 2.0 Core, AGPL-3.0 Studio; Version 0.1.462-beta, Stand Juni 2026) optimiert diesen Prozess weiter mit eigenen CUDA-Kerneln: Laut 59 offiziellen Benchmark-Läufen erreicht Unsloth 2× schnelleres Training bei 70 % weniger VRAM im Vergleich zu Standard-HuggingFace+PEFT – ohne messbare Genauigkeitsverluste. Das Framework unterstützt über 500 Modelle, darunter alle gängigen Llama-, Qwen-, Mistral- und Phi-Varianten.
| Modell | Parameter | QLoRA 4-Bit (Min.) | LoRA 16-Bit (Min.) | Empfohlene GPU |
|---|---|---|---|---|
| Llama/Qwen small | 3B | 3,5 GB | 8 GB | RTX 3060 8 GB |
| Llama 3.1 / Mistral | 7–8B | 5–6 GB | 19–22 GB | RTX 3070/4060 8 GB |
| Phi-4 / Qwen 2.5 | 14B | 9 GB | 40 GB | RTX 3090/4080 16 GB+ |
| Llama 3 / Qwen | 70B | 41 GB | 164 GB | 2–4× A100 80 GB |
| Llama 4 Scout (MoE) | 109B ges. / 17B aktiv | ~20 GB | ~50 GB | RTX 4090 24 GB |
Schritt 1: Unsloth installieren
Unsloth bietet einen automatischen Installer, der Python-Umgebung, CUDA-Version und alle Abhängigkeiten erkennt und passend installiert. Unter Windows in einer PowerShell als normaler Benutzer (keine Admin-Rechte erforderlich):
irm https://unsloth.ai/install.ps1 | iexUnter Linux und WSL2:
curl -fsSL https://unsloth.ai/install.sh | shAlternativ kannst du Unsloth manuell in einer bestehenden Python-Umgebung installieren:
# Virtuelle Umgebung anlegen (empfohlen)
python -m venv .venv
source .venv/bin/activate # Linux/WSL
# .venv\Scripts\activate # Windows
# Pakete installieren
pip install unsloth
pip install --no-deps xformers trl peft accelerate bitsandbytesVerifizieren: Nach der Installation sollte python -c "import unsloth; print(unsloth.__version__)" die Versionsnummer (z. B. 0.1.462) ausgeben, ohne Fehlermeldung.
Wichtig für Windows: Der PowerShell-Installer wählt automatisch die passende CUDA-Version. Installiere CUDA nicht manuell zusätzlich – das kann Konflikte erzeugen.
Schritt 2: Modell laden und für QLoRA vorbereiten
Du arbeitest in einem Python-Skript oder Jupyter-Notebook. Für 8 GB VRAM empfehlen sich Llama 3.1 8B Instruct, Qwen 2.5 7B oder Mistral 7B. Unsloth stellt diese Modelle bereits vorquantisiert auf HuggingFace bereit, was den Download beschleunigt:
from unsloth import FastLanguageModel
import torch
model, tokenizer = FastLanguageModel.from_pretrained(
model_name="unsloth/Meta-Llama-3.1-8B-Instruct",
max_seq_length=2048,
dtype=None, # Auto: BF16 auf Ampere+, FP16 sonst
load_in_4bit=True, # QLoRA: 4-Bit-Quantisierung aktivieren
)Der Parameter load_in_4bit=True ist der entscheidende Hebel: Er aktiviert die 4-Bit-Quantisierung via BitsAndBytes und ist Pflicht für 8-GB-GPUs bei 7–8B-Modellen.
Schritt 3: LoRA-Adapter konfigurieren
Im nächsten Schritt richtest du die Adapter-Parameter ein. Der Rank r bestimmt, wie viele Adapter-Parameter trainiert werden – und damit Qualität und VRAM-Bedarf. Starte mit r=16:
model = FastLanguageModel.get_peft_model(
model,
r=16, # Rank: 8 für schmal, 32+ für größere Datasets
target_modules=["q_proj", "k_proj", "v_proj", "o_proj",
"gate_proj", "up_proj", "down_proj"],
lora_alpha=32, # Empfehlung: 2× Rank
lora_dropout=0, # 0 für Effizienz; 0.05–0.1 bei Overfitting
bias="none",
use_gradient_checkpointing="unsloth", # Speicheroptimiertes Backprop
random_state=42,
)Die Faustregel: lora_alpha = 2 × r. Höhere Rank-Werte (r=32, r=64) erhöhen die Anpassungsfähigkeit, aber auch den VRAM-Bedarf. Auf 8 GB VRAM ist r=16 der sichere Ausgangspunkt.
Schritt 4: Firmendaten aufbereiten
Unsloth erwartet deine Trainingsdaten im JSONL-Format. Das verbreitete Alpaca-Format enthält je Zeile ein JSON-Objekt mit drei Feldern:
# Beispiel: firmendaten.jsonl (jede Zeile ein JSON-Objekt)
{"instruction": "Erkläre unsere Rückgaberichtlinie.", "input": "", "output": "Unsere Rückgaberichtlinie gilt 30 Tage ab Kaufdatum ..."}
{"instruction": "Beantworte die Kundenfrage.", "input": "Welche Zahlungsmethoden akzeptieren Sie?", "output": "Wir akzeptieren Kreditkarte, SEPA-Lastschrift und PayPal ..."}Wie viele Beispiele du brauchst, hängt vom Ziel ab:
- 200–500 Einträge: Stil- und Format-Anpassung (Tonalität, Antwortstruktur)
- 1.000–3.000 Einträge: Domänenspezifisches Wissen (Produkt-FAQ, Prozesse)
- 5.000+: Tiefe Wissens-Injektion
Qualität schlägt Quantität: 300 sorgfältig formulierte Beispiele erzielen bessere Ergebnisse als 3.000 inkonsistente Einträge. Tippfehler und widersprüchliche Antworten in den Trainingsdaten wirken sich direkt auf die Ausgabequalität aus.
from datasets import load_dataset
dataset = load_dataset("json", data_files="firmendaten.jsonl", split="train")
def formatting_prompts_func(examples):
texts = []
for instruction, input_text, output in zip(
examples["instruction"], examples["input"], examples["output"]
):
prompt = f"### Instruction:\n{instruction}"
if input_text:
prompt += f"\n### Input:\n{input_text}"
prompt += f"\n### Response:\n{output}"
texts.append(prompt)
return {"text": texts}
dataset = dataset.map(formatting_prompts_func, batched=True)Schritt 5: Training starten
Unsloth nutzt den SFTTrainer aus der TRL-Bibliothek. Die folgenden Parameter sind auf 8 GB VRAM ausgelegt. Bei einem OOM-Fehler ist per_device_train_batch_size=1 der erste Griff:
from trl import SFTTrainer
from transformers import TrainingArguments
trainer = SFTTrainer(
model=model,
tokenizer=tokenizer,
train_dataset=dataset,
dataset_text_field="text",
max_seq_length=2048,
args=TrainingArguments(
per_device_train_batch_size=2, # Bei OOM auf 1 reduzieren
gradient_accumulation_steps=4, # Dann auf 8 erhöhen
warmup_steps=5,
num_train_epochs=1, # 1–3 Epochen empfohlen
learning_rate=2e-4,
fp16=not torch.cuda.is_bf16_supported(),
bf16=torch.cuda.is_bf16_supported(),
logging_steps=1,
optim="adamw_8bit",
output_dir="outputs",
),
)
trainer.train()Verifizieren: Der Trainings-Loss sollte zu Beginn sinken (z. B. von ~2,5 auf ~0,8 über die ersten Schritte). Ein stabiler, fallender Loss-Wert bestätigt, dass das Training korrekt läuft. Ein NaN-Wert deutet auf eine zu hohe Learning Rate hin – dann auf 5e-5 oder 2e-5 reduzieren und warmup_steps auf 10–20 erhöhen.
Auf einer RTX 4060 mit 8 GB VRAM dauert eine Epoche über ~1.000 Beispiele (batch_size=2, gradient_accumulation=4) in der Regel 10–30 Minuten.
Schritt 6: Adapter speichern und Inferenz testen
Nach dem Training speicherst du den Adapter getrennt vom Basismodell. Der Adapter ist typischerweise rund 100 MB groß:
model.save_pretrained("lora_model")
tokenizer.save_pretrained("lora_model")Vor dem Export kannst du die Ausgabequalität direkt testen:
FastLanguageModel.for_inference(model)
inputs = tokenizer(
"### Instruction:\nBeantworte die folgende Kundenfrage.\n### Input:\nWie lautet meine Kundennummer?\n### Response:\n",
return_tensors="pt",
).to("cuda")
outputs = model.generate(**inputs, max_new_tokens=128)
print(tokenizer.decode(outputs[0], skip_special_tokens=True))Schritt 7: Als GGUF exportieren und in Ollama importieren
Für den Einsatz in Ollama exportierst du das Modell ins GGUF-Format. Die Methode q4_k_m ist für Produktion empfohlen – gutes Gleichgewicht aus Qualität und Dateigröße:
# Direkt zu GGUF (benötigt llama.cpp-Build mit CUDA)
model.save_pretrained_gguf("gguf_model", tokenizer, quantization_method="q4_k_m")Schlägt der direkte Export fehl (fehlender llama.cpp-Build), nutze den zweistufigen Weg:
# Erst zu 16-Bit mergen, dann GGUF
model.save_pretrained_merged("merged_model", tokenizer, save_method="merged_16bit")
model.save_pretrained_gguf("gguf_model", tokenizer, quantization_method="q4_k_m")| Methode | Bits | Qualität | Dateigröße (7B) | Verwendung |
|---|---|---|---|---|
| q4_k_m | 4 Bit | sehr gut | ~4,1 GB | Standard-Produktion / Ollama |
| q5_k_m | 5 Bit | ausgezeichnet | ~4,8 GB | Höhere Qualität bei VRAM vorhanden |
| q6_k | 6 Bit | exzellent | ~5,5 GB | Qualitätskritische Anwendungen |
| q8_0 | 8 Bit | fast verlustfrei | ~7,2 GB | Benchmarking / Referenz |
| f16 | 16 Bit | verlustfrei | ~14 GB | Zwischensicherung / Weiterverarbeitung |
Anschließend erstellst du ein Modelfile für Ollama. Unsloth generiert dieses automatisch – du kannst es aber auch manuell anlegen:
# Modelfile (Textdatei im GGUF-Exportverzeichnis)
FROM ./gguf_model/unsloth.Q4_K_M.gguf
PARAMETER temperature 0.7
PARAMETER top_p 0.9
SYSTEM "Du bist ein spezialisierter Unternehmensassistent für [Firmenname]."
# In PowerShell / Terminal: Modell importieren und starten
ollama create mein-firmenmodell -f Modelfile
ollama run mein-firmenmodell "Was sind unsere Servicezeiten?"Verifizieren: ollama list sollte mein-firmenmodell in der Modellliste anzeigen. Ein ollama run mein-firmenmodell "Testfrage" sollte eine kohärente Antwort im trainierten Stil zurückgeben.
Unsloth Studio: Die No-Code-Alternative
Wer kein Python-Skript schreiben möchte, kann das Unsloth Studio nutzen – eine browserbasierte GUI, die den gesamten Fine-Tuning-Workflow abbildet. Starten mit:
unsloth studio -H 0.0.0.0 -p 8888Anschließend im Browser öffnen: http://localhost:8888. Das Studio ist unter der AGPL-3.0-Lizenz verfügbar.
Troubleshooting / Typische Fehler
OOM-Fehler (Out of Memory)
Der häufigste Fehler. Erste Maßnahme: per_device_train_batch_size=1 setzen und gradient_accumulation_steps=8 erhöhen, um die effektive Batch-Größe von 8 (2×4) beizubehalten. Zusätzlich max_seq_length auf 1024 reduzieren, wenn deine Daten es erlauben.
Falsches Chat-Template nach Export
Das häufigste Praxisproblem nach dem Export: Das Chat-Template beim Training (z. B. Alpaca, ChatML) muss im Ollama-Modelfile identisch übernommen werden. Stimmt es nicht überein, liefert das Modell unbrauchbare oder kryptische Ausgaben. Unsloth schreibt das korrekte Template normalerweise automatisch ins Modelfile – prüfe es trotzdem manuell.
EOS-Token fehlt im Modelfile
Ohne den korrekten End-of-Sequence-Token generiert das Modell in Ollama endlose Ausgaben. Den Token kannst du aus dem Tokenizer ableiten (tokenizer.eos_token) und manuell ins Modelfile als PARAMETER stop "<token>" eintragen.
GGUF-Konvertierung schlägt fehl
save_pretrained_gguf benötigt einen funktionierenden llama.cpp-Build mit CUDA. Bei Fehlermeldungen llama.cpp manuell kompilieren: cmake -DGGML_CUDA=ON .. im llama.cpp-Verzeichnis. Alternativ erst als merged_16bit speichern und dann konvertieren.
Overfitting bei kleinem Dataset
Bei mehr als 3 Epochen oder sehr kleinen Datasets (unter 200 Einträge) beginnt das Modell, die Trainingsdaten auswendig zu lernen statt zu generalisieren – erkennbar an merkwürdigen Wiederholungen in der Ausgabe. Epochen auf 1–2 begrenzen und lora_dropout=0.05 setzen.
Learning-Rate-Instabilität (NaN-Loss)
Wenn der Trainings-Loss auf NaN springt, ist die Learning Rate zu hoch. Auf 5e-5 oder 2e-5 reduzieren und warmup_steps auf 10–20 erhöhen.
Falsches Modell für 8 GB VRAM gewählt
Modelle ab 13B passen selbst mit QLoRA nicht in 8 GB VRAM. Immer die VRAM-Tabelle prüfen, bevor ein Modell heruntergeladen wird – 4–5 GB Download für ein unnutzbares Modell kostet unnötig Zeit.
Häufige Fragen
Kann ich auch ohne GPU trainieren?
Nein. Training erfordert zwingend eine NVIDIA-GPU mit CUDA Capability ≥ 7.0 (RTX 20er-Serie oder neuer). CPU-Modus eignet sich nur für Inferenz mit GGUF-Modellen, nicht für Training. Wer keine passende lokale Hardware hat, kann Google Colab mit einer T4 (16 GB VRAM) kostenlos nutzen – Unsloth läuft dort genauso.
Wie viele Beispiele brauche ich mindestens?
200–500 sorgfältig formulierte Einträge reichen für Stil- und Format-Anpassungen (z. B. Tonalität, Antwortstruktur). Für domänenspezifisches Wissen – also wenn das Modell Informationen lernen soll, die im Basismodell nicht vorhanden sind – solltest du 1.000–3.000 Einträge anstreben. Das Wichtigste: Qualität vor Menge. 300 saubere Beispiele schlagen 3.000 verrauschte Einträge.
Was ist der Unterschied zwischen LoRA und QLoRA?
LoRA trainiert kleine Adapter-Matrizen in 16-Bit-Präzision – das Basismodell liegt ebenfalls in 16-Bit im VRAM. QLoRA lädt das Basismodell zusätzlich in 4-Bit-Quantisierung (BitsAndBytes) und trainiert die Adapter trotzdem in 16-Bit. Das spart 60–75 % VRAM bei marginalen Qualitätseinbußen, die in den meisten Praxisszenarien nicht spürbar sind.
Sind meine Firmendaten sicher?
Das komplette Training läuft lokal auf deiner eigenen Hardware. Weder Trainingsdaten noch das resultierende Modell werden automatisch hochgeladen. Daten verlassen den Rechner nur, wenn du explizit push_to_hub() aufrufst – was du für interne Firmenanwendungen schlicht weglässt. Das macht diesen Ansatz besonders interessant für DSGVO-sensible Daten.
Kann ich das Modell in mein bestehendes Ollama integrieren?
Ja, genau das ist der intendierte Workflow. Nach dem GGUF-Export und der Erstellung eines Modelfiles lässt sich das Modell per ollama create importieren und wie jedes andere Ollama-Modell nutzen – in Open WebUI, AnythingLLM oder direkt per API.
Welche Lizenz gilt für das fine-getunete Modell?
Das Fine-Tuning ändert die Lizenz des Basismodells nicht. Qwen- und Mistral-Modelle stehen unter Apache 2.0 und dürfen kommerziell genutzt werden. Llama-Modelle (Meta Llama License) erlauben kommerzielle Nutzung unter bestimmten Bedingungen – bei mehr als 700 Millionen Monatsnutzern ist eine gesonderte Lizenz erforderlich. Immer die Original-Lizenz des Basismodells prüfen.
Fazit
QLoRA Fine-Tuning mit Unsloth ist der praktisch machbare nächste Schritt für alle, die bereits mit Ollama lokale Modelle betreiben und diese auf eigene Inhalte spezialisieren wollen. Die Kombination aus 4-Bit-Quantisierung, optimierten CUDA-Kerneln und der klaren Python-API macht den Prozess auf Consumer-Hardware ab 8 GB VRAM realistisch durchführbar – in rund 90 Minuten vom Install bis zum laufenden Firmenmodell. Der Schlüssel zum Erfolg liegt weniger in der Hardware als in der Qualität der Trainingsdaten: Wer 300 sorgfältig kuratierte JSONL-Einträge investiert, bekommt ein spürbar besser angepasstes Modell als mit 3.000 halbgaren Beispielen. Das trainierte GGUF-Modell lässt sich danach nahtlos in jeden bestehenden Ollama-Stack einfügen – inklusive Open WebUI, AnythingLLM oder direkt über die Ollama-API.
Weiterführende Anleitungen und Quellen
- Ollama-Modelle 2026 richtig auswählen: VRAM, Quantisierung und Modellvergleich für KMU
- Ollama und Open WebUI mit Docker: eigenes lokales KI-Sprachmodell ohne Cloud betreiben
- GGUF, AWQ und GPTQ erklärt: Welches Quantisierungsformat für welchen Zweck
- CUDA-Umgebung korrekt aufsetzen: Treiber, Toolkit, cuDNN und PyTorch auf Ubuntu
- Lokales RAG-System mit Qdrant und Embeddings selbst bauen
- Unsloth Offizielle Dokumentation: Fine-Tuning LLMs Guide
- Unsloth GitHub Repository (README, Benchmarks)