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 probierenDer pragmatische Weg
In der Praxis hat sich eine klare Reihenfolge etabliert:
- Erst LoRA probieren – die Iteration ist so günstig, dass sich das Experiment fast immer lohnt
- Rang erhöhen, wenn die Qualität nicht reicht – mehr Adapter-Kapazität schließt die Lücke oft schon
- 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.