LoRA, DPO oder GRPO? Der Fine-Tuning-Entscheidungsbaum 2026 - und was auf eine einzelne GPU passt

Zwei Jahre lang lautete die ehrliche Antwort auf die Frage „Können wir ein eigenes Modell trainieren?" im Mittelstand: technisch ja, wirtschaftlich nein. Supervised Fine-Tuning mit Adaptern war zwar bezahlbar, aber alles, was in Richtung Reinforcement Learning ging, verlangte Multi-GPU-Knoten, ein separates Belohnungsmodell und einen MLOps-Apparat, den kaum ein 200-Personen-Unternehmen vorhält.

2026 stimmt diese Antwort nicht mehr. Reinforcement Learning auf Sprachmodellen ist in die Werkzeugkette der Adapter-Verfahren gewandert: GRPO, der Algorithmus hinter den DeepSeek-R1-Reasoning-Modellen, funktioniert bei Unsloth ausdrücklich auch mit LoRA und QLoRA – zuvor war er nur mit vollem Fine-Tuning nutzbar. Damit verschiebt sich die entscheidende Frage von „Haben wir das Budget?" zu „Welche Karte steht im Rack, und welches Verfahren löst überhaupt unser Problem?" Dieser Artikel beantwortet beides – mit belegten Zahlen statt Faustformeln.

Erst RAG ausreizen, dann Fine-Tuning

Der teuerste Fehler in Fine-Tuning-Projekten passiert vor der ersten Trainingszeile: Ein Unternehmen will „das Firmenwissen ins Modell bekommen" und trainiert Produktdaten, Preislisten oder Prozessbeschreibungen in die Gewichte. Das funktioniert schlecht und altert sofort. Jede Preisänderung, jede neue Maschinenvariante, jede Richtlinienrevision würde einen neuen Trainingslauf erfordern.

Die belastbare Arbeitsteilung sieht anders aus:

• Retrieval liefert Fakten. Alles, was sich ändert, versioniert werden muss oder mit Quellenangabe belegt werden soll, gehört in eine Dokumentenbasis mit semantischer Suche – nicht in die Gewichte.
• Fine-Tuning liefert Form und Verhalten. Antwortstil, Terminologie, Formatvorgaben, Gliederungsmuster, das konsequente Einhalten eines JSON-Schemas, die Art zu argumentieren – das sind Eigenschaften des Modells, keine Fakten in einem Dokument.
• Der Normalfall ist die Kombination. Ein SFT-Adapter, der Ihre Fachsprache und Ihr Antwortformat beherrscht, plus ein RAG-System, das die aktuellen Belege nachliefert.

Praktische Konsequenz: Bevor Sie eine GPU-Stunde investieren, prüfen Sie, ob das Problem ein Retrieval-Problem ist. Falsche Zahlen in der Antwort? Retrieval. Unbelegte Aussagen? Retrieval. Der Assistent klingt wie ein US-Marketingtext, ignoriert Ihre Nomenklatur und liefert Fließtext statt Prüfprotokoll? Das ist Fine-Tuning-Terrain – und dafür lohnt sich der Aufwand tatsächlich.

LoRA und QLoRA: was Adapter tatsächlich verändern

LoRA (Low-Rank Adaptation, Hu et al., arXiv:2106.09685) friert die Gewichte des Basismodells ein und trainiert stattdessen kleine, niedrigrangige Zusatzmatrizen in ausgewählten Schichten. Die harte Zahl aus dem Paper: Gegenüber vollem Adam-Fine-Tuning von GPT-3 175B sinkt die Zahl der trainierbaren Parameter um den Faktor 10.000 und der GPU-Speicherbedarf um den Faktor 3 – bei gleicher oder besserer Modellqualität und ohne zusätzliche Inferenzlatenz, weil sich die Adaptergewichte für die Auslieferung in das Basismodell verrechnen lassen.

In der Praxis heißt das: LoRA trainiert typischerweise deutlich unter einem Prozent der Parameter; die Adapterdatei bleibt bei üblichen Rängen im Bereich weniger Dutzend bis weniger hundert Megabyte. Ein Modell mit acht Milliarden Parametern belegt in 4-bit-Quantisierung mehrere Gigabyte – der zugehörige Adapter passt bequem in ein Git-Repository mit LFS und lässt sich wie eine Softwarekomponente versionieren, reviewen und zurückrollen.

QLoRA (Dettmers et al., arXiv:2305.14314, eingereicht am 23. Mai 2023) setzt eine Stufe darunter an: Das eingefrorene Basismodell wird in 4 bit gehalten – Kern ist der 4-bit-NormalFloat-Datentyp NF4 –, die Adapter selbst bleiben in höherer Präzision. Das Paper zeigt das Fine-Tuning eines 65B-Modells auf einer einzigen 48-GB-GPU bei erhaltener 16-bit-Fine-Tuning-Qualität. Das damit trainierte Guanaco erreichte nach 24 Stunden Training auf einer einzelnen GPU 99,3 Prozent des ChatGPT-Niveaus im Vicuna-Benchmark. Diese beiden Arbeiten sind der Grund, warum PEFT-Verfahren heute der Normalfall sind und volles Fine-Tuning die Ausnahme.

DPO: Präferenzen ohne Reward-Modell

Direct Preference Optimization (Rafailov et al., arXiv:2305.18290, eingereicht am 29. Mai 2023) trägt den sprechenden Untertitel „Your Language Model is Secretly a Reward Model". Die klassische RLHF-Pipeline besteht aus drei Stufen: SFT, Training eines separaten Reward-Modells auf Präferenzdaten, anschließend PPO-Optimierung gegen dieses Reward-Modell. DPO ersetzt diese Kette durch eine Reparametrisierung: Aus der Belohnungsfunktion lässt sich die optimale Policy in geschlossener Form ableiten, sodass sich das Ganze als einfacher Klassifikationsverlust auf Präferenzpaaren trainieren lässt.

Für ein IT-Team bedeutet das konkret: kein separates Reward-Modell, kein RL-Loop, kein Sampling aus dem Sprachmodell während des Trainings. Die Autoren beschreiben das Verfahren als stabil, performant und rechnerisch leichtgewichtig und berichten, dass es PPO-basiertes RLHF bei der Sentiment-Steuerung übertrifft.

Woher die Präferenzpaare kommen

Die eigentliche Arbeit bei DPO liegt in der Datenerhebung. Ein Präferenzpaar besteht aus einem Prompt und zwei Antworten – eine bevorzugte, eine abgelehnte. Drei Quellen haben sich in der Praxis bewährt:

1. Produktivbetrieb mit Daumen-Bewertung. Wenn Ihr interner Assistent bereits läuft, ist jeder Daumen hoch/runter neben zwei alternativen Antworten ein Datenpunkt. 1.000 bis 3.000 saubere Paare aus dem realen Betrieb schlagen 50.000 synthetische.
2. Redaktionelle Korrekturen. Die vom Fachbereich überarbeitete Version einer Modellantwort ist die bevorzugte, das Original die abgelehnte Antwort. Dieser Kanal fällt in vielen Unternehmen ohnehin an – er muss nur protokolliert werden.
3. Regelbasierte Ablehnungen. Antworten, die ein Schema verletzen, eine verbotene Formulierung enthalten oder ohne Quellenangabe auskommen, lassen sich automatisch als „abgelehnt" markieren.

DPO ist damit der natürliche zweite Schritt: erst SFT für die Grundform, dann DPO für die Feinsteuerung des Auswahlverhaltens. Beides als LoRA-Adapter, beides auf einer Karte.

GRPO: Reasoning trainieren ohne Reward-Modell

Group Relative Policy Optimization stammt aus DeepSeekMath (arXiv:2402.03300, eingereicht am 5. Februar 2024) und ist dort als PPO-Variante beschrieben, die den Speicherbedarf von PPO senkt. DeepSeek nutzte das Verfahren später für die R1-Reasoning-Modelle. Die Ergebnisse aus dem Paper: DeepSeekMath-7B erreichte 51,7 Prozent auf MATH ohne externe Tools und ohne Voting, mit Self-Consistency über 64 Samples 60,9 Prozent.

Technisch entfallen gegenüber PPO zwei Komponenten:

• Das Value-Modell entfällt – ersetzt durch Statistik über mehrfaches Sampling pro Prompt. Statt einen separaten Kritiker zu trainieren, zieht GRPO mehrere Antworten zum selben Prompt und vergleicht sie untereinander.
• Das Reward-Modell entfällt – ersetzt durch eigene Reward-Funktionen. Die Vorteile entstehen durch Z-Score-Standardisierung innerhalb der Sampling-Gruppe: Nur die relative Rangfolge in der Gruppe muss stimmen, nicht eine absolute, kalibrierte Bewertungsskala.

Genau diese Gruppen-Normalisierung ist der Grund, warum GRPO für Unternehmen interessant ist: Sie brauchen keinen kalibrierten Bewertungsmaßstab, nur ein Verfahren, das innerhalb einer Handvoll Antworten sagen kann, welche besser ist. Der Preis: Es muss eine verifizierbare Belohnung geben. Bei Mathematik, Code mit Testsuite, Schema-Validierung, SQL-Ergebnisvergleich oder Tool-Aufrufen mit prüfbarem Ergebnis ist das trivial. Bei „schreibt schönere Angebotstexte" nicht – dort ist DPO das richtige Werkzeug.

VRAM- und Kontextbudget je Verfahren

Die relevante Grenze beim RL-Fine-Tuning ist selten das Modell selbst, sondern die Kontextlänge: Bei GRPO werden pro Prompt mehrere Generationen erzeugt und gemeinsam im Speicher gehalten. Die Faustregel von Unsloth für GRPO mit QLoRA in 4 bit: Die Modellparameter entsprechen ungefähr dem VRAM-Bedarf. Als absolutes Minimum nennt die Dokumentation rund 5 GB VRAM für Modelle bis 1,5 Milliarden Parameter und rund 15 GB für Modelle bis etwa 17 Milliarden Parameter.

Die interessanteren Zahlen betreffen die erreichbare Kontextlänge:

Karte / VRAM	Modell	Setup	Kontext (GRPO)
24 GB (z. B. RTX 4090)	gpt-oss	QLoRA	20K
24 GB (z. B. RTX 4090)	Qwen3-VL-8B	QLoRA	32K
80 GB (H100)	gpt-oss	BF16-LoRA	65K
80 GB (H100)	Qwen3-8B	vLLM + QLoRA	110K
192 GB (B200)	gpt-oss	QLoRA	380K

Woher der Sprung bei der Kontextlänge kommt

Unsloth beziffert den Effekt neuer Batching-Algorithmen mit „rund 7-fach längerem RL-Kontext, in Einzelfällen mehr als 12-fach – ohne Einbußen bei Genauigkeit oder Geschwindigkeit gegenüber anderen optimierten Setups". Der Vergleichsmaßstab gehört zwingend in den Satz: Es geht nicht um einen Faktor 7 gegenüber einem naiven Trainingsskript, sondern gegenüber bereits optimierten Referenzimplementierungen.

Technisch liegt der Hebel im Logit-Speicher. Bei einem Setup mit Batch-Größe 4, Kontextlänge 8.192 und einer Vokabulardimension von 128.000 sinkt der Speicherbedarf für die Logits durch dynamisches, geflattetes Sequenz-Chunking von 0,83 GB auf 0,207 GB. Das Prinzip: Der riesige Logit-Tensor wird gar nicht erst materialisiert, und die Log-Softmax-Aktivierungen werden ausgelagert.

Der zweite Hebel ist ein Standby-Modus für die Generierungsphase. Konkreter Benchmark: Qwen2.5-14B-Instruct auf einer H100 mit 80 GB, 32.768 Token Sequenzlänge, 8 Generationen pro Prompt und 4 Gradient-Accumulation-Steps kommt mit Standby-Modus auf 43.042 MiB Peak Memory (rund 43 GB) gegenüber 52.084 MiB (rund 52 GB) ohne – etwa 9 GB Ersparnis auf derselben Karte. Ergänzend beschreibt Unsloth vLLM als Kernbestandteil der meisten RL-Frameworks und beziffert die Beschleunigung der Generierung mit bis zu 11x gegenüber normaler Generierung.

Für die Beschaffung heißt das: Eine 24-GB-Workstation ist der legitime Einstieg für Experimente und kleine Modelle. Sobald Trajektorien länger werden – Agentenläufe, mehrstufige Werkzeugaufrufe, lange Dokumente im Kontext – ist der Sprung auf 80 GB oder mehr kein Luxus, sondern der Unterschied zwischen „Aufgabe passt in den Kontext" und „Aufgabe passt nicht". Welche Karte für welches Vorhaben sinnvoll ist, klären wir bei der Auslegung von On-Premise-KI-Servern konkret am Anwendungsfall.

Belohnungsfunktion ohne Handarbeit

Der praktische Flaschenhals bei GRPO ist nicht die Hardware, sondern die Reward-Funktion. Für Mathematik oder Unit-Tests ist sie in einer halben Stunde geschrieben. Für einen Agenten, der ein CRM bedient, drei Werkzeuge aufruft und am Ende eine Zusammenfassung liefert, wird das Schreiben und Abstimmen der Belohnungslogik schnell zum Hauptaufwand des Projekts.

Hier setzt RULER an – „Relative Universal LLM-Elicited Rewards", von OpenPipe und Teil des Open-Source-Frameworks ART (Agent Reinforcement Trainer). Das Verfahren nutzt genau die Eigenschaft von GRPO, die oben beschrieben wurde: Weil innerhalb der Sampling-Gruppe normalisiert wird, müssen die Scores nur gruppenintern vergleichbar sein. Ein LLM-Judge bewertet daher mehrere Agent-Trajektorien relativ zueinander und vergibt Scores zwischen 0 und 1 – ohne dass jemand eine absolute Bewertungsskala kalibrieren müsste.

Die von OpenPipe berichteten Ergebnisse sind für Unternehmen interessanter als die reine Technik: In 3 von 4 Aufgaben schneiden mit RULER trainierte Modelle leicht besser ab als solche mit handgeschriebenen Reward-Funktionen – bei 2- bis 3-fach kürzerer Implementierungszeit und ohne gelabelte Daten oder menschliches Feedback. RULER ist inzwischen auch über W&B Training Serverless RL verfügbar.

Warum Fine-Tuning ins eigene Haus gehört

Bei Inferenz über eine fremde API verlässt eine einzelne Anfrage das Haus. Beim Fine-Tuning verlässt etwas anderes das Haus: der kuratierte Trainingsdatensatz. Und der ist qualitativ etwas völlig anderes.

Ein Fine-Tuning-Datensatz ist destilliertes Firmenwissen. Er enthält typischerweise die besten Antworten Ihrer erfahrensten Mitarbeiter, die Struktur Ihrer internen Prozesse, Ihre Nomenklatur, Ihre Entscheidungsregeln – ausgerechnet in der aufbereiteten, maschinenlesbaren Form, die intern über Jahre nie zustande gekommen wäre. Wer diesen Datensatz hochlädt, gibt nicht eine Anfrage heraus, sondern das Konzentrat der eigenen Arbeitsweise.

Dazu kommt die datenschutzrechtliche Seite. Enthält der Trainingsdatensatz personenbezogene Daten – Kundenkorrespondenz, Servicefälle, Bewerbungsunterlagen, Personalvorgänge –, ist das Training ein eigenständiger Verarbeitungsvorgang mit allem, was dazugehört: Rechtsgrundlage, Zweckbindung, Verzeichnis von Verarbeitungstätigkeiten, gegebenenfalls Auftragsverarbeitung. Anders als bei einer flüchtigen Inferenzanfrage entsteht hier ein dauerhaftes Artefakt, aus dem sich Trainingsinhalte unter Umständen wieder herauslocken lassen. Was das für Ihre Konstellation konkret bedeutet, klären wir im Rahmen von Datenschutz und KI.

Der dritte Punkt ist der pragmatischste: Trainieren Sie im eigenen Haus, bleibt der Adapter Ihr Eigentum und portabel. Er liegt als Datei auf Ihrem Storage, lässt sich auf ein anderes Basismodell übertragen, weitergeben, archivieren oder löschen. Das ist der Unterschied zwischen einem Vermögenswert und einem Mietverhältnis. Wenn Ihnen dafür Betriebspersonal fehlt, ist das lösbar – genau dafür gibt es KI-Full-Stack-Providing, bei dem Hardware, Modelle und Betrieb aus einer Hand kommen, die Daten aber im eigenen Rack bleiben.

Empfohlener Pfad in vier Schritten

Aus den bisherigen Abschnitten ergibt sich eine Reihenfolge, die Aufwand und Risiko in der richtigen Reihenfolge verteilt:

1. Retrieval zuerst ausreizen. Bauen Sie das RAG-System, messen Sie die verbleibenden Fehler und sortieren Sie sie: Faktenfehler bleiben Retrieval-Aufgaben, Form- und Verhaltensfehler wandern auf die Fine-Tuning-Liste. Ohne diese Sortierung trainieren Sie das falsche Problem.
2. QLoRA-SFT auf einer einzelnen Karte. 500 bis 2.000 sorgfältig kuratierte Beispiele im gewünschten Zielformat schlagen 50.000 automatisch generierte. Trainieren Sie auf einer 24-GB-Karte, evaluieren Sie gegen ein festes Testset, das der Fachbereich definiert hat – und behalten Sie den Datensatz versioniert. Er ist wertvoller als der Adapter.
3. DPO ergänzen, sobald Präferenzpaare vorliegen. Sammeln Sie ab dem ersten Produktivtag Bewertungen und redaktionelle Korrekturen. Sobald ein paar tausend saubere Paare zusammengekommen sind, ist DPO der günstigste verfügbare Qualitätssprung – ohne Reward-Modell, ohne RL-Infrastruktur.
4. GRPO erst bei verifizierbarer Belohnung. Wenn und nur wenn sich für Ihre Aufgabe automatisch entscheiden lässt, ob ein Ergebnis richtig ist – Testsuite, Schema-Validierung, numerischer Vergleich – oder wenn ein validierter LLM-Judge vergleichend ranken kann. Dann liefert GRPO das, was SFT und DPO nicht können: verbessertes Reasoning statt verbesserter Nachahmung.

Realistischer Zeitrahmen für Schritt 1 bis 3 in einem mittelständischen Unternehmen: sechs bis zehn Wochen, davon der überwiegende Teil Datenarbeit, nicht Training. Die eigentlichen Trainingsläufe dauern bei Adapter-Verfahren auf einer einzelnen Karte Stunden, nicht Tage – das ist inzwischen der kleinste Posten in der Rechnung. Wenn Sie prüfen wollen, welcher Schritt bei Ihnen ansteht, lässt sich das in einem kurzen Gespräch klären: Fine-Tuning-Projekt besprechen.

Quellen & Primärbelege

Alle Zahlen, Fristen und Produktangaben in diesem Beitrag wurden vor der Veröffentlichung gegen die folgenden Primärquellen geprüft.

1. Unsloth Docs GRPO Long Context – VRAM- und Kontexttabellen, 24-GB-Klasse
2. Unsloth Docs Reinforcement Learning Guide – GRPO mit LoRA/QLoRA, vLLM-Beschleunigung
3. Unsloth Docs Memory-Efficient RL – Logit-Chunking, Standby-Modus, Qwen2.5-14B-Benchmark
4. OpenPipe RULER – Ergebnisse gegenüber handgeschriebenen Reward-Funktionen
5. ART Docs RULER-Grundlagen, Scores 0–1, relatives Ranking
6. arXiv:2106.09685 Hu et al., LoRA – 10.000x weniger trainierbare Parameter, 3x weniger GPU-Speicher
7. arXiv:2305.14314 Dettmers et al., QLoRA – 65B auf einer 48-GB-GPU, NF4, Guanaco
8. arXiv:2305.18290 Rafailov et al., Direct Preference Optimization
9. arXiv:2402.03300 DeepSeekMath – GRPO, 51,7 % auf MATH

Häufig gestellte Fragen zu Fine-Tuning auf einer GPU

Reicht eine einzelne GPU fuer Reinforcement Fine-Tuning?

Ja. GRPO laeuft inzwischen mit LoRA und QLoRA auf einer 24-GB-Karte; fuer lange RL-Kontexte ist eine 80-GB- oder 96-GB-Karte deutlich komfortabler.

Wann DPO und wann GRPO?

DPO, wenn Sie Praeferenzpaare haben und Stil oder Auswahlverhalten steuern wollen. GRPO, wenn es eine verifizierbare Belohnung gibt und Reasoning verbessert werden soll.

Ersetzt Fine-Tuning ein RAG-System?

Nein. Aktuelles und haeufig wechselndes Wissen gehoert ins Retrieval. Fine-Tuning veraendert Ton, Format, Fachsprache und Reasoning-Muster.

Wie gross sind die trainierten Adapter?

LoRA-Adapter sind typischerweise 50 bis 500 MB gross, trainieren nur 0,1 bis 1 Prozent der Parameter und lassen sich getrennt vom Basismodell versionieren.