Wenn ein Unternehmen über das Fine-tuning eines eigenen LLM nachdenkt, ist die erste Frage meist nicht „wie?" sondern „haben wir dafür die Hardware?". Die Antwort hängt davon ab, welche Methode gewählt wird. Der Unterschied zwischen Full Fine-tuning und QLoRA kann bei einem 7B-Modell mehr als das Zehnfache des benötigten VRAMs ausmachen — und genau das entscheidet, ob das Training auf einer einzelnen RTX 4090 läuft oder einen gemieteten A100-Cluster voraussetzt.
Dieser Artikel behandelt die drei Hauptansätze — LoRA, QLoRA und Full Fine-tuning — aus der Perspektive des praktischen Einsatzes. Es gibt konkrete Zahlen, einen Entscheidungsrahmen und Hinweise auf Situationen, in denen die günstigere Methode nicht ausreicht.
Grundbegriffe für den Einstieg
Bevor wir zu den Zahlen kommen, eine kurze Einordnung:
Full Fine-tuning aktualisiert alle Gewichte des Modells. Bei einem 7B-Modell bedeutet das, 7 Milliarden Parameter zu trainieren — und dabei auch Gradienten sowie Optimizer-States im Speicher zu halten.
LoRA (Low-Rank Adaptation) friert die ursprünglichen Gewichte ein und fügt kleine „Adapter"-Matrizen mit niedrigem Rang (Rank) hinzu. Das Training berührt nur diese Adapter, die um Größenordnungen kleiner sind als das ursprüngliche Modell.
QLoRA (Quantized LoRA) geht einen Schritt weiter: Die eingefrorenen Gewichte des Basismodells werden auf 4-Bit quantisiert, was deren Speicherabdruck drastisch reduziert. Die LoRA-Adapter bleiben dabei in höherer Präzision (BF16). Das Training arbeitet mit dequantisierten Werten — was eine leichte Verlangsamung bringt, dafür aber enorme VRAM-Einsparungen.
Die entscheidenden Zahlen: VRAM nach Methode
Dies sind verifizierte Zahlen für Dense-Modelle (also keine MoE-Architekturen wie Llama 4 oder Qwen3, bei denen der Bedarf durch das Laden aller Experten deutlich höher ist):
Für ein 7B-Modell in FP16/BF16: - Full Fine-tuning: ~67 GB VRAM - LoRA: ~15 GB VRAM - QLoRA 8-Bit: ~9 GB VRAM - QLoRA 4-Bit: ~5 GB VRAM
Für ein 13B-Modell: - Full Fine-tuning: ~125 GB VRAM - LoRA: ~28 GB VRAM - QLoRA 8-Bit: ~17 GB VRAM - QLoRA 4-Bit: ~9 GB VRAM
Für ein 70B-Modell: - Full Fine-tuning: ~672 GB VRAM — praktisch außerhalb der Reichweite für ein Single-Node-Setup - LoRA: ~146 GB VRAM — mindestens 2× A100 80GB - QLoRA 8-Bit: ~88 GB VRAM — ein A100 80GB mit knapper Reserve - QLoRA 4-Bit: ~46 GB VRAM — ein A100 80GB ohne Probleme
Faustregel für Full FT: Rechnen Sie grob mit 10–16 GB VRAM pro Milliarde Parameter — die untere Grenze (~10 GB, entspricht der obigen Tabelle) gilt bei 8-Bit-Optimizer und Gradient-Checkpointing, die obere (~16 GB) beim klassischen 32-Bit-Adam. Die Zahl umfasst Optimizer-States, Gradienten und Aktivierungen.
Ein wichtiges Detail: Fine-tuning benötigt um Größenordnungen mehr Speicher als die Inferenz desselben Modells. Ein 7B-Modell läuft für die Inferenz auf 8 GB, aber LoRA-Training darauf braucht ~15 GB. Das ist die häufigste Überraschung in der Praxis — „das Modell läuft doch bei mir, warum bricht das Training ab?"
Wann welche Methode sinnvoll ist
QLoRA 4-Bit ist der Ausgangspunkt für jeden, der keinen dedizierten Trainingsserver hat. Ein 7B-Modell in QLoRA 4-Bit läuft problemlos auf einer RTX 3090 oder RTX 4090 (24 GB) und mit Gradient-Checkpointing (weitere ~30 % VRAM-Einsparung bei ~2 % langsamerer Trainingsgeschwindigkeit) auch auf einer RTX 3060 12 GB. Für explorative Arbeiten, Proof-of-Concept und Instruction-Tuning auf kleinen Datensätzen (tausende Beispiele) ist QLoRA 4-Bit die vernünftige Wahl.
LoRA in FP16 ist ein Schritt nach oben — sowohl in der Qualität als auch im Anspruch. Für ein 7B-Modell werden ~15 GB benötigt — also eine RTX 4090 oder A100 40GB. Die Qualität liegt orientierungsweise bei 90–95 % des Full Fine-tunings. Für die meisten domänenspezifischen Aufgaben (Klassifikation, Extraktion, Instruction-Tuning auf Firmendokumentation) ist LoRA FP16 der optimale Kompromiss.
Full Fine-tuning empfehlen wir in drei konkreten Fällen: 1. Reasoning, Mathematik und Coding, wo ein Qualitätsunterschied von 5 % signifikant ist 2. Continual Learning — sequenzielle Fine-tunings über mehrere Domänen hinweg (hier hat LoRA systemische Schwächen, siehe unten) 3. Fundamentale Verhaltensänderungen des Modells, die über reines Domänen-Tuning hinausgehen
Für Unternehmenseinsätze in der Kategorie „Chatbot über eigener Dokumentation" oder „Klassifikation von Meldungen" ist Full Fine-tuning üblicherweise unnötig und teuer. Wir haben Dutzende Projekte gesehen, bei denen QLoRA oder LoRA die geforderte Qualität zu einem Bruchteil der Kosten erreicht haben.
Entscheidungsrahmen in der Praxis
Diese Fragen in dieser Reihenfolge verkürzen das Entscheidungsfenster:
1. Welches Modell soll trainiert werden? Dense 7B oder 13B: Sie haben Flexibilität. Dense 70B: QLoRA 4-Bit auf A100 80GB ist das realistische Einstiegstor. MoE-Modelle (z. B. Llama 4, Qwen3): Der VRAM-Bedarf ist deutlich höher als die aktiven Parameter vermuten lassen — überprüfen Sie konkrete Zahlen für jedes Modell vor der HW-Planung.
2. Was ist das Ziel? Instruction-Tuning, Domänen-Anpassung, Tonänderung → LoRA oder QLoRA. Reasoning, Coding, Mathematik → erwägen Sie Full FT oder zumindest höheren LoRA-Rank + DoRA. Sequenzielles Continual Learning → Full FT (LoRA hat hier nachgewiesene Probleme).
3. Sind genügend Daten vorhanden? Für Supervised Fine-tuning (SFT) sind tausende qualitativ hochwertige Beispiele das empfohlene Minimum — soweit die Hauptthemen der Domäne abgedeckt sind. Training auf unzureichenden Daten produziert ein Modell, das mit Zuversicht aus Lücken antwortet. Das ist ein schlechteres Ergebnis als ein Basismodell, das immerhin „ich weiß es nicht" sagen kann. Das Data-Quality-Gate ist vor dem Training wichtiger als die Methodenwahl.
4. Was ist der Deployment-Plan?
QLoRA 4-Bit wird während des Trainings verwendet, nicht in der Produktion. Nach dem Training wird der Adapter in das Basismodell gemergt und in normaler Präzision deployt (BF16/FP16) — oder für das produktive Serving erneut quantisiert (GGUF für llama.cpp, AWQ/GPTQ für vLLM). „QLoRA-Produktionsmodell" ist ein Misnomer, der in Dokumentationen und Projektplänen immer wieder auftaucht.
LoRA-Hyperparameter: Spielraum für Optimierung
Rank (r) ist der wichtigste Hebel. Höherer Rank = mehr trainierbare Parameter = potenziell bessere Qualität, aber auch mehr Speicher und Overfitting-Risiko bei kleinen Datensätzen.
Bewährte Empfehlungen:
- rank=4 bis rank=8: einfache Aufgaben (Klassifikation, Template-Antworten), kleine Datensätze
- rank=16 bis rank=32: komplexeres Instruction-Tuning, Domänenanpassung
- rank=64 und höher: nur bei großen Datenmengen und HW-Reserve; höherer Rank erhöht auch das Risiko von „Intruder Dimensions" (siehe unten)
Alpha (α) wird standardmäßig gleich dem Rank gesetzt oder auf 2× Rank. Für die rsLoRA-Variante ist der theoretisch begründete Wert α/√r.
Target-Module: Wir empfehlen, alle linearen Schichten zu trainieren — q_proj, k_proj, v_proj, o_proj plus gate_proj, up_proj, down_proj. Die Beschränkung auf reine Attention-Schichten ist ein älteres Muster aus 2023, das neuere Frameworks überholt haben.
DoRA und weitere PEFT-Varianten
DoRA (Weight-Decomposed LoRA) zerlegt das Gewichts-Update in Magnitude und Richtung. In der Praxis schließt es etwa die Hälfte der Qualitätslücke zwischen LoRA und Full FT bei einem Overhead von nur +5–10 % VRAM. Verfügbar in der PEFT-Bibliothek, Unsloth und Axolotl. Für Projekte, bei denen LoRA nicht ausreicht, Full FT aber zu teuer ist, ist DoRA der natürliche nächste Schritt.
GaLore optimiert das Training direkt im niedrigrangigen Gradientenraum — ohne explizite Adaptermatrix. Die Ergebnisse sind mit Full FT vergleichbar bei deutlich geringerem Speicherbedarf, aber die Einrichtung ist technisch anspruchsvoller.
Für typische Unternehmensprojekte empfehlen wir: Starten Sie mit LoRA oder QLoRA, wenn das nicht ausreicht, probieren Sie DoRA, bevor Sie auf Full FT wechseln.
Was wir über Qualität wissen: Intruder Dimensions
Die Forschungsarbeit „LoRA vs Full Fine-tuning: An Illusion of Equivalence" (2024) brachte einen wichtigen Hinweis: LoRA und Full FT erzielen oberflächlich ähnliche Ergebnisse, aber durch unterschiedliche Mechanismen.
LoRA erzeugt sogenannte „Intruder Dimensions" — neue hochrangige singuläre Vektoren, die im Basismodell nicht existieren. Diese interferieren mit dem ursprünglichen Repräsentationsraum, was sich beim Continual Learning zeigt — also wenn das Modell sequenziell auf mehreren Domänen trainiert wird. LoRA zeigt in diesem Szenario deutlich stärkeres katastrophisches Vergessen als Full FT.
Für einmaliges Fine-tuning auf einer einzigen Domäne (das sind 90 % der Unternehmensfälle) ist diese Einschränkung praktisch irrelevant. Wenn Sie jedoch planen, das Modell laufend auf neuen Daten oder neuen Domänen nachzuschärfen, ist Full FT oder Continual Learning mit Replay-Buffer der sicherere Ansatz.
Verwandter Artikel: SFT, DPO, GRPO — welche Methode wann
Frameworks im Jahr 2026
Vier Hauptwerkzeuge decken den gesamten Stack ab und konkurrieren in Details miteinander:
`Unsloth` ist das schnellste Single-GPU-Framework — 2–5× schneller als die Standard-HuggingFace-Pipeline bei ~70 % VRAM-Einsparung gegenüber vollem Fine-tuning. Triton-fused Kernels, Gradient-Checkpointing als Standard, Unterstützung für Qwen3, Llama 4 und MoE-Architekturen. Open-Source für Single-GPU; Multi-GPU-Distributed-Training ist hinter einer Unsloth-Pro-Subscription.
`TRL` von HuggingFace ist der Standard für Alignment-Methoden — SFT, DPO, GRPO, ORPO in einer Bibliothek. Gut dokumentiert, in das Transformers-Ökosystem integriert.
`Axolotl` ist eine YAML-gesteuerte Produktions-Pipeline — geeignet beim Skalieren auf mehrere GPUs und bei komplexeren Pipelines (QAT, Sequence Parallelism, Reward Modeling). Für Projekte, bei denen ein wiederholbares, versioniertes Training-Setup benötigt wird.
`LLaMA-Factory` kombiniert GUI und CLI und unterstützt die breiteste Modellpalette — geeignet für Teams, in denen nicht nur ML-Ingenieure das Training starten.
Praktische Wahl: Für einen internen Proof-of-Concept starten Sie mit Unsloth (niedrigste Einstiegshürde, Geschwindigkeit). Für eine Produktions-Pipeline mit Skalierung erwägen Sie Axolotl. Für Alignment-Experimente (DPO/GRPO) greifen Sie zu TRL.
Mehr zur Auswertung von Ergebnissen: Wie man misst, ob Fine-tuning geholfen hat
Was mit dem trainierten Adapter zu tun ist
Ein LoRA-Adapter ist eine kleine Datei (typisch einige bis mehrere Dutzend MB), die unabhängig vom Basismodell geteilt und versioniert werden kann. Für das Deployment gibt es zwei Optionen:
Merge in das Basismodell: peft.merge_and_unload() führt die Adaptermatrizen mit den ursprünglichen Gewichten zusammen. Das Ergebnis ist ein vollwertiges Modell ohne Runtime-Overhead. Für die Produktion empfohlen.
Runtime-Loading: Der Adapter wird dynamisch bei der Inferenz geladen. Flexibel beim Experimentieren (mehrere Adapter für dasselbe Basismodell), fügt aber Latenz hinzu.
Nach dem Merge kann das Modell für effizienteres Serving quantisiert werden — GGUF für llama.cpp und Ollama, AWQ oder GPTQ für vLLM. Das ist der standardmäßige Produktions-Flow: Training in QLoRA 4-Bit → Adapter-Merge → Quantisierung für das Serving.
Verwandte Themen: Quantisierung von LLMs (GGUF, AWQ, GPTQ) und Kleines Fine-tuned vs großes Basismodell
Häufige Fragen
Ist QLoRA nur eine günstigere Version von LoRA? Nicht ganz. QLoRA quantisiert die eingefrorenen Gewichte des Basismodells auf 4-Bit, während die LoRA-Adapter in BF16 bleiben. Der Mechanismus ist ein anderer, und das Training ist ~20–30 % langsamer durch den Dequantisierungs-Overhead. QLoRA ist kein Gratis-Mittagessen — es ist ein Trade-off zwischen VRAM und Geschwindigkeit, kein bloßer Qualitätsrabatt.
Kann ich ein QLoRA-4-Bit-Modell direkt in der Produktion einsetzen? Nicht direkt. Die QLoRA-4-Bit-Bezeichnung bezieht sich auf den Trainingsprozess, nicht auf das Produktionsmodell. Nach dem Training wird der Adapter in das Basismodell gemergt und in Standardpräzision deployt, gegebenenfalls erneut für effizientes Serving quantisiert (GGUF, AWQ). „QLoRA-Produktionsmodell" ist ein Misnomer.
Warum braucht Full Fine-tuning so viel mehr VRAM als die Inferenz? Weil das Training weit mehr als nur Gewichte im Speicher hält: Gradienten (gleiche Größe wie die Gewichte), Optimizer-States (beim Adam 2× die Gewichte zusätzlich) und Aktivierungen für die Backpropagation. Ein 7B-Modell läuft für die Inferenz in 8 GB, LoRA-Training darauf braucht ~15 GB, Full FT ~67 GB.
Wann reicht LoRA nicht und ist Full Fine-tuning notwendig? In drei Fällen: (1) Reasoning, Mathematik, Coding — wo ein Qualitätsunterschied von 5 % signifikant ist, (2) Continual Learning mit sequenziellen Fine-tunings über mehrere Domänen hinweg (LoRA zeigt hier stärkeres katastrophisches Vergessen), (3) fundamentale Verhaltensänderung des Modells über Domänen-Tuning hinaus.
Bedeutet ein höherer LoRA-Rank immer bessere Ergebnisse?
Nicht automatisch. Ein höherer Rank erhöht Speicherbedarf und Trainingszeit, steigert bei kleinen Datensätzen aber eher das Overfitting-Risiko. Höherer Rank produziert auch mehr „Intruder Dimensions", was katastrophisches Vergessen verstärken kann. Für Instruction-Tuning ist rank=16 oder rank=32 in der Regel ausreichend.
Fazit
*Die Wahl zwischen LoRA, QLoRA und Full Fine-tuning ist in erster Linie eine Hardware-Entscheidung — und erst in zweiter eine Qualitätsfrage. Für die überwiegende Mehrheit der Unternehmensfälle (domänenspezifische Chatbots, Klassifikation, Dokumentenextraktion) erreichen LoRA oder QLoRA die geforderte Qualität zu einem Bruchteil der Kosten. Full Fine-tuning sollten Sie für Situationen reservieren, in denen diese fünf Prozent wirklich zählen. Bei MP Industrial Solutions helfen wir Unternehmen, diese Entscheidung auf Basis konkreter Daten zu treffen — von der Datensatz-Analyse über die HW-Auswahl bis zum Deployment. Wenn Sie Ihr erstes Fine-tuning in Betracht ziehen oder prüfen möchten, ob Ihr aktuelles Setup sinnvoll ist, schauen wir uns Ihren Fall gerne an.*