LoRA-Feinabstimmung: Ein praktischer Leitfaden

LoRA-Feinabstimmung (Low-Rank Adaptation) ist eine parameter-effiziente Methode, um ein vortrainiertes Sprachmodell an eine spezifische Aufgabe anzupassen. Anstatt jedes Gewicht im Modell zu aktualisieren, friert LoRA die ursprünglichen Gewichte ein und fügt kleine trainierbare Matrizen in die Aufmerksamkeits-Schichten ein. Das Ergebnis ist ein Adapter – eine Datei, die oft unter 100 MB groß ist –, der beim Inferenzbetrieb nahtlos an das Basismodell angehängt wird. So erhalten Sie spezialisiertes Verhalten, ohne Milliarden von Parametern neu zu trainieren.

So funktioniert LoRA

Eine Standard-Transformer-Gewichtsmatrix könnte beispielsweise 4096 × 4096 groß sein. LoRA zerlegt die Aktualisierung dieser Matrix in zwei deutlich kleinere Matrizen: eine mit den Dimensionen 4096 × r und eine mit r × 4096, wobei r der Rang ist (üblicherweise 4–64). Während des Trainings werden ausschließlich diese Low-Rank-Matrizen aktualisiert. Bei der Inferenz wird das Produkt der beiden kleinen Matrizen wieder zur eingefrorenen Originalmatrix addiert – bei den meisten Implementierungen entsteht dadurch keine zusätzliche Latenz, da der Adapter vor der Bereitstellung bereits mit dem Modell verschmolzen wird.

Dies ist für die Hardware entscheidend: Da die Gewichte des Basismodells eingefroren sind, benötigen sie weder Optimierer-Zustände noch Gradienten. Nur die Adapter-Parameter erfordern dies. Deshalb sinken die VRAM-Anforderungen im Vergleich zur vollständigen Feinabstimmung so drastisch.

LoRA vs. QLoRA

QLoRA, eingeführt von Dettmers et al. (2023), lädt das Basismodell in 4-Bit-NormalFloat-(NF4-)Quantisierung und behält den Adapter in voller Präzision bei. Das Training ist langsamer als bei Standard-LoRA aufgrund des Dequantisierungs-Overheads bei jedem Forward-Pass; die VRAM-Einsparungen ermöglichen jedoch das Training von 13B- und 70B-Modellen auf Hardware, die die meisten Nutzer tatsächlich besitzen. Der Qualitätsverlust gegenüber vollständigem LoRA ist bei aufgabenbezogenen Feinabstimmungen meist vernachlässigbar; bei komplexen Schlussfolgerungsaufgaben ist jedoch eine gewisse Verschlechterung möglich.

Bevor Sie sich für eine Hardware entscheiden, führen Sie Ihr Zielmodell durch den VRAM-Rechner — dieser berücksichtigt Batch-Größe und Sequenzlänge, beide Parameter verschieben die Werte erheblich.

Rang und Alpha: Was sie tatsächlich bewirken

Rang (r) steuert die Ausdruckskraft des Adapters. Ein Rang von 4 fügt sehr wenige Parameter hinzu und bewirkt nur subtile Änderungen; ein Rang von 64 verleiht dem Adapter mehr Kapazität, um das Modellverhalten neu zu formen, erhöht aber gleichzeitig den VRAM-Bedarf und das Risiko einer Überanpassung.

Alpha (α) ist ein Skalierungsfaktor, der auf die LoRA-Ausgabe vor ihrer Addition zu den festgehaltenen Gewichten angewendet wird. Die effektive Lernrate des Adapters skaliert mit α/r. Die gängigste Ausgangseinstellung ist α = 2 × r (z. B. r=16, α=32); diese hat sich in der Praxis als robust erwiesen.

Ein höherer Rang bedeutet nicht zwangsläufig bessere Ergebnisse. Für die meisten Anweisungs-basierten Feinabstimmungen ist r=16 ausreichend. Falls sich der Validierungsverlust nicht verbessert, erhöhen Sie entweder den Rang oder fügen mehr Daten hinzu, bevor Sie die Anzahl der Epochen erhöhen.

Realistische VRAM- und Zeitanforderungen

Die folgenden Angaben gehen von QLoRA mit einer Batch-Größe von 1 und einer Sequenzlänge von 2048 aus. Bei Multi-GPU-Setups skaliert der VRAM-Bedarf annähernd linear, allerdings sind Konfigurationen mit FSDP oder DeepSpeed erforderlich.

Cloud-Kosten variieren. Eine einzelne A100 80 GB bei Lambda Labs kostet Stand Mitte 2026 etwa 1,50–2,00 USD pro Stunde. Ein QLoRA-Feinabstimmungslauf für ein 7B-Modell mit 50.000 Beispielen dauert typischerweise weniger als zwei Stunden – also deutlich unter 5 USD. Für Entscheidungshilfen beim Kauf einer GPU siehe der GPU-Leitfaden für lokale LLMs.

Tools: Wie man eine LoRA-Feinabstimmung tatsächlich durchführt

Die beiden dominierenden Frameworks sind Hugging Face TRL + PEFT und AxolotlBeide unterstützen LoRA und QLoRA. Unsloth ist eine beliebte dritte Option, die mittels benutzerdefinierter CUDA-Kernel eine bis zu zweimal schnellere Trainingsgeschwindigkeit erreicht.

Minimalbeispiel für TRL + PEFT (Python)

from transformers import AutoModelForCausalLM, BitsAndBytesConfig
from peft import LoraConfig, get_peft_model
from trl import SFTTrainer, SFTConfig
import torch

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

model = AutoModelForCausalLM.from_pretrained(
    "meta-llama/Meta-Llama-3-8B-Instruct",
    quantization_config=bnb_config,
    device_map="auto",
)

lora_config = LoraConfig(
    r=16,
    lora_alpha=32,
    target_modules=["q_proj", "v_proj"],
    lora_dropout=0.05,
    task_type="CAUSAL_LM",
)

model = get_peft_model(model, lora_config)

trainer = SFTTrainer(
    model=model,
    train_dataset=your_dataset,  # erwartet Spalte "text"
    args=SFTConfig(output_dir="./output", num_train_epochs=3),
)
trainer.train()
model.save_pretrained("./my-lora-adapter")

Der Adapter, der in ./my-lora-adapter gespeichert wird, umfasst typischerweise 50–300 MB. Führen Sie ihn mit model.merge_and_unload() in das Basismodell ein, um die Inferenzgeschwindigkeit zu erhöhen, bevor Sie speichern.

Axolotl (konfigurationsgesteuert)

Axolotl steuert die gesamte Pipeline über eine YAML-Datei, was die Reproduzierbarkeit von Durchläufen erleichtert. Installieren Sie es mit pip install axolotl, dann:

# config.yml
base_model: meta-llama/Meta-Llama-3-8B-Instruct
load_in_4bit: true
adapter: lora
lora_r: 16
lora_alpha: 32
lora_dropout: 0.05
datasets:
  - path: ./data/train.jsonl
    type: alpaca
output_dir: ./output
num_epochs: 3

accelerate launch -m axolotl.cli.train config.yml

Wann Feinabstimmung das falsche Werkzeug ist

LoRA-Feinabstimmung löst ein spezifisches Problem: die Änderung wie des Verhaltens oder der Reaktion eines Modells. Sie vermittelt jedoch keine sachlichen Kenntnisse zuverlässig. Falls Ihr Anwendungsfall in eine der folgenden Kategorien fällt, führt ein anderer Ansatz mit geringerem Aufwand zu besseren Ergebnissen:

• Dem Modell fehlen aktuelle oder proprietäre Kenntnisse. Verwenden Sie Retrieval-Augmented Generation (RAG). Eine Feinabstimmung auf Fakten erzeugt Modelle, die sich außerhalb des Trainingsdatensatzes selbstsicher „ausdenken“ (halluzinieren).
• Sie benötigen, dass das Modell bestimmte Anweisungen befolgt. Probieren Sie zunächst einen detaillierten System-Prompt aus. Ein sorgfältig entworfener Prompt für ein leistungsfähiges Basismodell übertrifft oft ein feinabgestimmtes kleineres Modell bei derselben Aufgabe.
• Sie verfügen über weniger als etwa 500 hochwertige Beispiele. Das Signal-Rausch-Verhältnis ist zu niedrig; das Modell wird wahrscheinlich überanpassen (overfit). Ergänzen Sie Ihre Daten oder verwenden Sie stattdessen Few-Shot-Prompting.
• Sie befinden sich in der Prototyp-Phase. Die Feinabstimmung fixiert ein Verhalten dauerhaft. Nutzen Sie stattdessen zunächst die API und iterieren Sie anhand von Prompts, bis das gewünschte Verhalten stabil ist; erst danach sollten Sie eine Feinabstimmung in Erwägung ziehen, um bei großem Volumen die Token-Kosten zu senken. Der API-Kostenrechner hilft dabei zu quantifizieren, ab wann die Feinabstimmung eines lokalen Modells kostengünstiger wird als die Bezahlung pro Token.

Wenn Sie langfristig ein lokal feinabgestimmtes Modell einem gehosteten API gegenüberstellen, liefert Ihnen der Selbsthosting- versus-API-Kosten-Grenzwert-Rechner den Break-even-Punkt basierend auf Ihrem Datenvolumen und Ihren GPU-Kosten.

Häufig gestellte Fragen

Wie viel Daten benötige ich für eine LoRA-Feinabstimmung?

Für die Anpassung an Anweisungen oder Stiländerungen reichen oft 500–2000 hochwertige, vielfältige Beispiele aus. Für komplexe Domänenanpassungen führen 5000–20000 Beispiele zu robusteren Ergebnissen. Die Qualität zählt weitaus mehr als die Menge – 200 sorgfältig kuratierte Beispiele schlagen 2000 verrauschte deutlich.

Kann ich LoRA-Inferenz auf Consumer-Hardware durchführen?

Ja. Ein zusammengeführter Adapter verursacht keinen zusätzlichen Inferenz-Overhead gegenüber dem Basismodell. Ein nicht zusammengeführter Adapter fügt pro Vorwärtsdurchlauf nur geringfügig zusätzliche Berechnung hinzu. Sowohl llama.cpp als auch Ollama unterstützen das direkte Laden von GGUF-konvertierten LoRA-Adaptoren. Weitere Informationen zu Speicheranforderungen bei Inferenz-only-Szenarien finden Sie im Leitfaden zu VRAM-Anforderungen für Inferenz-only-Speicherbedarf.

Was ist der Unterschied zwischen LoRA und vollständiger Feinabstimmung?

Bei einer vollständigen Feinabstimmung werden sämtliche Gewichte des Modells aktualisiert; dazu müssen Optimierer-Zustände für alle Parameter gespeichert werden – bei gemischter Genauigkeit mit Adam etwa 16–20 Byte pro Parameter. LoRA aktualisiert lediglich die Low-Rank-Adapter-Matrizen und reduziert so die Anzahl trainierbarer Parameter um den Faktor 10–1000. Der Trade-off liegt in der Kapazität: Eine vollständige Feinabstimmung kann das Modell umfassender umgestalten, doch für die meisten praktischen Aufgaben erreicht LoRA vergleichbare Leistung.

Welche Schichten sollte ich mit LoRA ansprechen?

Die Attention-Projektionsschichten (q_proj und v_proj) sind die am häufigsten genutzten Zielbereiche und eignen sich für die meisten Aufgaben gut. Das Hinzufügen von k_proj, o_proj, sowie der MLP-Schichten (gate_proj, up_proj, down_proj) erhöht die Kapazität, verbraucht aber mehr VRAM und verlängert das Training leicht. Falls VRAM knapp ist, beginnen Sie zunächst ausschließlich mit den q- und v-Projektionen.

Erzeugt QLoRA ein schlechteres Modell als Full LoRA?

Bei den meisten aufgabenbezogenen Feinabstimmungen ist der Unterschied vernachlässigbar. Veröffentlichte Benchmarks zeigen QLoRA innerhalb von 1–2 Prozentpunkten gegenüber Full LoRA bei Standard-Evaluierungen. Die Lücke kann sich bei komplexen Denkaufgaben mit sehr kleinen Datensätzen vergrößern, da Quantisierungsrauschen sich bei begrenztem Signal verstärkt. Falls Genauigkeit oberste Priorität hat und ausreichend VRAM zur Verfügung steht, verwenden Sie LoRA auf einer bf16-basierten Modellbasis.

Wie bewerte ich, ob meine Feinabstimmung tatsächlich einen Fortschritt gebracht hat?

Halten Sie 10–20 % Ihrer Daten als Validierungsset zurück und verfolgen Sie den Validierungsverlust während des Trainings. Brechen Sie ab, sobald sich der Validierungsverlust nicht mehr verbessert (Early Stopping). Führen Sie anschließend aufgabenbezogene Evaluierungen durch: Bei Klassifikationsaufgaben messen Sie die Genauigkeit an den zurückgehaltenen Beispielen; bei Generierungsaufgaben nutzen Sie entweder menschliche Bewertung oder ein LLM-as-Judge-Setup an 50–100 Beispielen. Ein Rückgang des Validierungsverlusts, der sich nicht in eine bessere Aufgabenausführung übersetzt, deutet auf eine Verteilungsmismatch zwischen Ihren Trainingsdaten und den realen Eingaben hin.