Zum Inhalt springen

// journal / llm-deep-tech / lora-fine-tuning

Was ist LoRA? Effizientes Fine-Tuning von LLMs einfach erklärt

LoRA — Low-Rank Adaptation — hat das Fine-Tuning von Sprachmodellen demokratisiert. Statt Milliarden Parameter zu trainieren, werden nur kleine Adapter-Matrizen angepasst. Was das technisch bedeutet, warum es funktioniert und wie man es produktiv einsetzt.

Von createIF Labs
Veröffentlicht am
  • LoRA
  • Fine-Tuning
  • PEFT
  • Modellanpassung & Training
  • Adapter
Diagramm: Low-Rank-Adapter zwischen den Attention-Layern eines Transformers
Schematische Architekturdarstellung: Ein vortrainierter Transformer mit eingefrorenen Gewichten, und parallel dazu kleine Low-Rank-Adapter-Matrizen (A und B), die nur einen Bruchteil der Parameter haben und das Modellverhalten gezielt verändern, ohne das Basismodell zu beschädigen. Visualisiert wird der Unterschied zwischen Full Fine-Tuning (gesamter Stack trainierbar) und LoRA (nur Adapter trainierbar).

LoRA — Low-Rank Adaptation — ist eine der wichtigsten Methoden, die das Fine-Tuning großer Sprachmodelle für normale Unternehmen überhaupt möglich gemacht haben. Statt Milliarden Modellgewichte zu verändern, werden nur winzige Adapter-Matrizen trainiert. Das senkt Kosten, Hardware-Bedarf und Trainingszeit um eine bis zwei Größenordnungen — bei oft nahezu identischer Qualität. Dieser Beitrag erklärt, wie es funktioniert und wann es die richtige Wahl ist.

1. Das Problem mit klassischem Fine-Tuning

Ein modernes LLM hat 8 bis 70 Milliarden Parameter, in Forschungsmodellen sogar mehrere hundert Milliarden. Full Fine-Tuning bedeutet, all diese Parameter weiter zu trainieren. Das verursacht drei Probleme:

  • Speicher. Training erfordert mehrfache Modellgrößen im GPU-RAM (Modell, Gradienten, Optimizer-Zustände). Ein 70B-Modell braucht für Full Fine-Tuning hunderte Gigabyte VRAM — also mehrere High-End-GPUs im Cluster.
  • Kosten. GPU-Stunden für Multi-Knoten-Training summieren sich schnell auf fünf- oder sechsstellige Beträge.
  • Catastrophic Forgetting. Wenn man alle Gewichte verändert, kann das Modell allgemeine Fähigkeiten verlieren, die es vor dem Fine-Tuning hatte. Es spezialisiert sich um den Preis seiner Vielseitigkeit.

Für die meisten Unternehmensanwendungen ist das überzogen. Man will keine fundamentale Verhaltensänderung — man will eine Spezialisierung in einer Nische, ohne das Basismodell zu beschädigen.

2. Die LoRA-Idee: Low-Rank-Anpassung

LoRA basiert auf einer mathematischen Beobachtung: Die Veränderungen, die ein Modell durch Fine-Tuning erfährt, leben fast immer in einem niedrigdimensionalen Unterraum. Wenn man also nur eine Low-Rank-Annäherung an die Veränderung lernt, reicht das aus — die hohe Dimensionalität des vollen Modells wird gar nicht gebraucht.

Konkret: Statt eine große Gewichtsmatrix W zu modifizieren, lernt LoRA zwei kleine Matrizen A und B, deren Produkt eine Low-Rank-Approximation der Veränderung darstellt. Die effektive Gewichtsmatrix wird zu W + B·A. Wenn W zum Beispiel 4.096×4.096 Werte hat (rund 17 Millionen Parameter) und der Rank r=16 ist, dann hat A nur 16×4.096 und B nur 4.096×16 Werte — zusammen rund 131.000 Parameter. Das ist eine Reduktion auf weniger als 1%.

In der Praxis werden Adapter typischerweise in den Attention-Layern eingesetzt (Query, Key, Value, Output-Projektionen), manchmal auch in den Feed-Forward-Schichten. Die Wahl betrifft Qualität und Trainingskosten.

3. Warum LoRA funktioniert

Empirisch erreicht LoRA in den meisten Anpassungsaufgaben 90–98% der Qualität eines Full Fine-Tunings. Drei Erklärungen:

  • Low-Rank-Hypothese. Die Veränderungen, die für die meisten Spezialisierungen nötig sind, sind tatsächlich niedrigdimensional. Diese These ist gut belegt durch zahlreiche Studien zur intrinsischen Dimension von LLM-Updates.
  • Pretraining bewahrt allgemeine Fähigkeiten. Da das Basismodell eingefroren bleibt, gehen seine allgemeinen Fähigkeiten nicht verloren — kein Catastrophic Forgetting.
  • Regularisierungseffekt. Die Beschränkung auf einen Low-Rank-Update wirkt als implizite Regularisierung und reduziert Overfitting bei kleinen Datensätzen.

4. LoRA in der Praxis

Ein typisches LoRA-Setup mit Hugging Face PEFT und Transformers sieht so aus:

from peft import LoraConfig, get_peft_model
from transformers import AutoModelForCausalLM

base = AutoModelForCausalLM.from_pretrained("meta-llama/Llama-3.1-8B")

config = LoraConfig(
    r=16,
    lora_alpha=32,
    target_modules=["q_proj", "k_proj", "v_proj", "o_proj"],
    lora_dropout=0.05,
    bias="none",
)

model = get_peft_model(base, config)
model.print_trainable_parameters()
# >>> trainable params: 20M (0.25% of total)

Auf einer einzelnen 24-GB-Consumer-GPU (RTX 4090, RTX 5090) lässt sich damit ein 8B-Modell in wenigen Stunden auf 5.000 Beispielen fine-tunen. Mit QLoRA (siehe nächster Abschnitt) sogar ein 70B-Modell auf einer 48-GB-GPU.

Wichtige Hyperparameter:

  • Rank r: 8 bis 64. Bei 8B-Modellen oft r=16, bei größeren Modellen r=32 oder höher.
  • Alpha: Skalierungsfaktor, üblicherweise das Doppelte des Rank.
  • Dropout: 0,05–0,1 zur Regularisierung.
  • Target Modules: Welche Layer Adapter bekommen. Mehr Layer = mehr Kapazität, aber auch mehr Trainingsaufwand.

5. Varianten: QLoRA, DoRA, Spectrum

QLoRA (Quantized LoRA) kombiniert LoRA mit 4-Bit-Quantisierung des Basismodells. Das ermöglicht Fine-Tuning auf noch kleinerer Hardware — ein 70B-Modell auf einer einzelnen 48-GB-GPU. Details in QLoRA und Quantisierung.

DoRA (Weight-Decomposed Low-Rank Adaptation) zerlegt die Update-Matrix in Magnitude und Direction und trainiert beide getrennt. In vielen Benchmarks etwas besser als reines LoRA, mit geringfügig höherem Aufwand.

Spectrum ist ein neueres Verfahren, das gezielt die Layer mit der höchsten signal-to-noise ratio identifiziert und nur dort trainiert. Effizienter und oft qualitativ besser als blindes LoRA auf alle Attention-Layer.

In der Praxis ist LoRA mit Standard-Hyperparametern für die meisten Aufgaben ausreichend. Die Varianten bringen 1–3% Qualitätsverbesserung, lohnen aber den zusätzlichen Aufwand nur bei reifen Setups.

6. Wann LoRA die richtige Wahl ist

LoRA passt zu Use Cases mit diesen Eigenschaften:

  • Verhaltensanpassung statt Wissensergänzung. Tonalität, Format, domänenspezifische Sprache, strukturierte Outputs.
  • Datensätze von 500–50.000 Beispielen. Genug für eine echte Anpassung, klein genug für effizientes Training.
  • Wunsch nach Modularität. Mehrere Spezialisierungen auf einem Basismodell ohne Mehrfachspeicherung.
  • Begrenzte Hardware. Eine bis vier GPUs, lokal oder gemietet.
  • On-Premise- oder Souveränitätsanforderungen. Open-Weight-Modell plus eigenes LoRA-Training = volle Datenhoheit. Siehe Sichere KI-Integration.

Wenn die Aufgabe eher Wissens-orientiert ist (Fakten aus Dokumenten beantworten), ist RAG die bessere Wahl. Vergleich in RAG, Fine-Tuning oder Prompt Engineering.

7. Grenzen und Trade-offs

LoRA ist nicht für alles geeignet:

  • Tiefgreifende Verhaltensänderungen. Wenn das Modell etwas fundamental Neues lernen soll (eine neue Sprache, eine völlig neue Modalität), reicht LoRA oft nicht.
  • Latenz bei nicht-gemergeten Adaptern. Adapter zur Laufzeit hinzuzuschalten kostet einige Prozent Latenz — bei hochfrequenter Inferenz relevant.
  • Wahl der Target Modules. Falsche Hyperparameterwahl kann zu schlechteren Ergebnissen als ein generisches Modell führen.
  • Eval bleibt zwingend. Auch ein LoRA-Adapter kann Halluzinationen produzieren, Biases verstärken oder Edge Cases übersehen. Ohne strukturierte Eval bleibt der Effekt nicht messbar — Details in Guardrails, Evals und Prompt Injection.

LoRA ist 2026 das Standardwerkzeug für die meisten Spezialisierungsaufgaben in Unternehmen. Wer es ignoriert und entweder bei reinem Prompt Engineering bleibt oder direkt zu Full Fine-Tuning greift, lässt erhebliches Effizienzpotenzial liegen. Mit etwas Disziplin in Datensatzkuratierung und Evaluation entsteht aus einem Open-Weight-Basismodell und einem trainierten Adapter ein produktives, domänenspezifisches System — souverän, kontrollierbar und ohne Vendor-Lock-in.

// FAQ

Häufige Fragen.

  1. / 01Wie viele Parameter trainiert LoRA tatsächlich?

    Typischerweise 0,1–1% der Gesamtparameter eines Modells. Für ein 7B-Modell heißt das 7–70 Millionen Parameter statt sieben Milliarden. Das senkt den GPU-Speicherbedarf dramatisch und macht Training auf einer einzelnen Consumer-Grafikkarte möglich.

  2. / 02Was ist der Rank in LoRA?

    Der Rank (r) bestimmt die Größe der Adapter-Matrizen. Übliche Werte sind 8, 16, 32 oder 64. Höherer Rank bedeutet mehr trainierbare Parameter und potentiell mehr Anpassungskapazität — aber auch mehr Speicherbedarf und Overfitting-Risiko. Für viele Use Cases ist r=16 ein guter Ausgangspunkt.

  3. / 03Verändert LoRA das Basismodell?

    Nein, das ist der Kernvorteil. Die Originalgewichte bleiben eingefroren. Adapter werden separat gespeichert und können zur Laufzeit hinzu- oder weggeschaltet werden. Das ermöglicht mehrere Spezialisierungen auf einem Basismodell ohne Mehrfachspeicherung des großen Modells.

  4. / 04Lassen sich mehrere LoRA-Adapter kombinieren?

    Ja, das ist eine der Stärken. Multi-Adapter-Setups erlauben, ein Basismodell mit verschiedenen Spezialisierungen zu betreiben — beispielsweise ein medizinischer Adapter und ein juristischer Adapter auf demselben Modell. Frameworks wie LoRAX oder S-LoRA spezialisieren sich auf solche Setups.

  5. / 05Kann ich LoRA-Adapter mit dem Basismodell verschmelzen?

    Ja, das nennt sich Adapter-Merge. Die Adapter-Gewichte werden mathematisch in das Basismodell eingerechnet, was die Inferenz beschleunigt — keine zusätzliche Matrix-Operation mehr nötig. Der Nachteil: Nach dem Merge ist der Adapter nicht mehr separat austauschbar.

  6. / 06Wie sieht der Datenbedarf für LoRA aus?

    Deutlich geringer als bei Full Fine-Tuning. Für klar definierte Aufgaben reichen oft 500–5.000 hochwertige Beispiele. Die Qualität der Daten ist wichtiger als die Menge. Mit synthetischen Daten lässt sich der Bedarf weiter senken — Details in Synthetic Data.

// Weiterlesen

Weiterlesen