LoRA vs. Full Fine-Tuning

Die Kernfrage

Du willst ein vortrainiertes Modell auf deine Domäne, deinen Stil oder deine Aufgabe anpassen. Beim Wie stehen sich zwei Ansätze gegenüber:

• Full Fine-Tuning: Alle Gewichte des Modells werden weitertrainiert
• LoRA (Low-Rank Adaptation): Die Basisgewichte bleiben eingefroren; trainiert werden nur kleine zusätzliche Adapter-Matrizen

Die Frage ist selten, ob LoRA funktioniert – sondern ob dein Use Case zu den Fällen gehört, in denen sich der massive Mehraufwand von Full Fine-Tuning noch lohnt.

Wie Full Fine-Tuning funktioniert

Beim klassischen Fine-Tuning wird das gesamte Modell auf neuen Daten weitertrainiert – jeder einzelne Parameter kann sich ändern.

Stärken:

• Maximale Anpassungstiefe: Das Modell kann sein Verhalten grundlegend umformen
• Beste Wahl bei starken Domänen-Shifts – etwa hochspezialisierte Fachsprache, neue Sprachen oder Aufgabentypen fernab des Vortrainings
• Keine architektonischen Zusätze: Das Ergebnis ist ein ganz normales Modell

Schwächen:

• Teuer: Alle Gewichte plus Optimizer-Zustände müssen in den GPU-Speicher – bei größeren Modellen heißt das Multi-GPU-Cluster
• Catastrophic Forgetting: Beim aggressiven Anpassen kann das Modell Fähigkeiten aus dem Vortraining verlieren – es wird besser in der Nische und schlechter in allem anderen
• Unflexibel: Jede Variante (pro Kunde, pro Aufgabe, pro Experiment) ist eine vollständige Modellkopie mit eigenem Hosting

Wie LoRA funktioniert

LoRA friert die Basisgewichte ein und legt an ausgewählte Schichten kleine Low-Rank-Matrizen – die Adapter. Die Idee dahinter: Die für eine Anpassung nötige Gewichtsänderung hat meist eine niedrige effektive Dimension und lässt sich als Produkt zweier schmaler Matrizen darstellen. Trainiert wird nur dieser Bruchteil – häufig unter einem Prozent der Gesamtparameter.

Stärken:

• Wenig VRAM: Training oft auf einer einzelnen GPU möglich; mit QLoRA (quantisiertes Basismodell) sinkt der Bedarf weiter
• Schnell und günstig: kleinere Trainingsläufe, schnellere Iteration
• Mehrere Adapter pro Basismodell: Ein gehostetes Modell bedient viele Spezialisierungen – Adapter sind nur Megabyte groß und lassen sich zur Laufzeit wechseln
• Geringes Forgetting-Risiko: Die Basisgewichte bleiben unangetastet; ein Adapter lässt sich jederzeit rückstandslos entfernen

Schwächen:

• Begrenzte Kapazität: Bei starken Domänen-Shifts kann die Qualität minimal hinter Full Fine-Tuning zurückbleiben
• Zusätzliche Hyperparameter (Rang, Alpha, Ziel-Schichten) wollen gewählt werden
• Ohne Merging ein kleiner Inferenz-Overhead durch den Adapter-Pfad

Wann was?

LoRA wählen, wenn:

• Du Stil, Ton oder Format anpassen willst (Marken-Tonalität, Antwortstruktur)
• Dein Use Case Domänen-Feinschliff ist, kein Komplettumbau
• Budget oder Hardware begrenzt sind
• Du viele Varianten brauchst – pro Kunde, Sprache oder Aufgabe je ein Adapter
• Du schnell experimentieren willst: Adapter trainieren, testen, verwerfen

Full Fine-Tuning wählen, wenn:

• Das Modell einen starken Domänen-Shift bewältigen muss (z. B. hochspezialisierte Fachdomäne, deutlich anderes Aufgabenformat)
• Das letzte Quäntchen Qualität geschäftskritisch ist und den Aufwand rechtfertigt
• Du ohnehin die Infrastruktur und das Team für große Trainingsläufe hast
• Ein einzelnes, dediziertes Spezialmodell entstehen soll – keine Adapter-Flotte

Praxis-Szenarien

LoRA in Aktion: Eine Agentur betreibt Text-Assistenten für zwölf Kunden, jeder mit eigener Marken-Tonalität. Statt zwölf komplette Modelle zu hosten, läuft ein einziges Basismodell – pro Kunde wird nur der passende Adapter geladen. Neue Kunden bedeuten einen kurzen Trainingslauf auf einer einzelnen GPU und wenige Megabyte zusätzlichen Speicher.

Full Fine-Tuning in Aktion: Ein Unternehmen baut ein Modell für hochspezialisierte juristische Gutachten in einer Nischen-Rechtsdomäne, deren Sprache und Argumentationsmuster im Vortraining kaum vorkommen. Nach systematischen Vergleichstests bleibt LoRA auch mit hohem Rang messbar hinter den Anforderungen zurück – hier rechtfertigt der Qualitätsabstand den vollen Trainingsaufwand samt sorgfältiger Evaluation gegen Catastrophic Forgetting.

Der häufigste Fehler in der Praxis ist übrigens keiner der beiden Wege, sondern die Reihenfolge: Teams starten mit dem teuren Full Fine-Tuning, ohne vorher geprüft zu haben, ob ein LoRA-Adapter – oder sogar nur besseres Prompting – das Problem längst gelöst hätte.

Entscheidungsbaum

Reicht Prompting oder RAG für dein Ziel?
├── Ja → Kein Training nötig
└── Nein
    └── Ist die Anpassung Stil/Feinschliff innerhalb der Domäne des Modells?
        ├── Ja → LoRA (ggf. QLoRA bei knapper Hardware)
        └── Nein (starker Domänen-Shift)
            └── Rechtfertigt der Qualitätsgewinn Kosten und Forgetting-Risiko?
                ├── Ja → Full Fine-Tuning
                └── Nein → LoRA mit höherem Rang probieren

Der pragmatische Weg

In der Praxis hat sich eine klare Reihenfolge etabliert:

1. Erst LoRA probieren – die Iteration ist so günstig, dass sich das Experiment fast immer lohnt
2. Rang erhöhen, wenn die Qualität nicht reicht – mehr Adapter-Kapazität schließt die Lücke oft schon
3. Full Fine-Tuning erst, wenn LoRA nachweislich an seine Grenze stößt

Faustregel: LoRA ist der Standard, Full Fine-Tuning die begründungspflichtige Ausnahme. Wer die Qualitätslücke nicht gemessen hat, sollte sie nicht mit dem Zehnfachen an Trainingskosten bezahlen.