SFT, DPO, GRPO: drei Fine-Tuning-Methoden — welche wann einsetzen

Wenn ein Unternehmen beginnt, ein eigenes Sprachmodell zu verfeinern, lautet die erste Frage meistens: „Wie viele Daten brauchen wir?" Die richtigere Frage ist: „Was wollen wir am Modell ändern — und welches Trainingsziel entspricht dem?" SFT, DPO und GRPO sind drei verschiedene Antworten auf drei verschiedene Probleme. Die richtige Methode zu wählen, bevor man Daten sammelt, entscheidet darüber, ob das Projekt nach sechs Monaten funktioniert oder nicht.

Dieser Artikel erklärt nicht, wie man ein Trainings-Framework installiert. Er erklärt, was jede Methode tut, wann sie einzusetzen ist, wie viele Daten tatsächlich benötigt werden — und warum die Reihenfolge SFT → DPO → GRPO kein Zufall ist.

Grundlage: Was ist LoRA, was ist ein Trainingsziel — zwei verschiedene Konzepte

Vor dem eigentlichen Methodenvergleich ist es wichtig, zwei Dinge zu unterscheiden, die in Diskussionen häufig vermischt werden.

LoRA (Low-Rank Adaptation) und QLoRA (die quantisierungskomprimierte Variante) sind *Mechanismen* — eine Möglichkeit, das Modell physisch zu modifizieren, ohne alle Gewichte anzupassen. Stattdessen trainiert man kleine Adaptermatrizen, die auf die bestehenden Modellgewichte aufgesetzt werden. Dadurch kommt man mit deutlich weniger GPU-Speicher aus: Ein typisches 7B-Modell lässt sich mit QLoRA auf einer GPU mit ~9 GB VRAM fine-tunen, während vollständiges Fine-Tuning ~70–120 GB erfordern würde. Einen detaillierteren Vergleich dieser Mechanismen findet sich im Artikel LoRA vs QLoRA vs Full Fine-Tuning.

SFT, DPO und GRPO hingegen sind *Trainingsziele* — sie definieren, was das Modell lernt. Genau wie LoRA ist auch vollständiges Fine-Tuning ein Mechanismus. Man kann SFT mit LoRA, SFT mit vollständigem Fine-Tuning oder DPO mit QLoRA kombinieren — die Kombinationen sind beliebig. In der Praxis wird heute der Großteil domänenspezifischer Projekte aus wirtschaftlichen Gründen mit LoRA oder QLoRA durchgeführt, aber das Trainingsziel bleibt die entscheidende Wahl.

SFT — Supervised Fine-Tuning: dem Modell Format und Verhalten beibringen

SFT (Supervised Fine-Tuning, überwachtes Feintuning) ist die grundlegende Methode. Man gibt dem Modell eine Eingabe und eine gewünschte Ausgabe, und das Modell lernt, diese Paare nachzuahmen. Es ist im Wesentlichen eine Erweiterung des Vortrainings: Das Modell lernt aus Stichproben im Format (Prompt → Antwort).

SFT beantwortet die Frage: *„Wie soll das Modell auf diesen Aufgabentyp reagieren?"*

Wann SFT einsetzen

SFT ist die richtige Wahl, wenn:

• Das Modell das richtige Wissen hat, aber in einem falschen Format antwortet (zu lang, zu kurz, falsche Sprache, falsche Struktur)
• Man dem Modell domänenspezifischen Jargon, Terminologie oder einen bestimmten Kommunikationsstil beibringen möchte
• Eine klar definierte Aufgabe mit konsistenten Mustern vorliegt — etwa Dokumentenklassifikation, Entity-Extraktion, Reportgenerierung nach Vorlage
• Man das Verhalten eines stärkeren Modells destillativ in ein kleineres übertragen möchte (Beispiele erzeugt das teacher-Modell, trainiert wird der student)

SFT dient auch als Fundament für alle weiteren Methoden. Ein Base-Modell ohne SFT lässt sich nicht zuverlässig mit DPO oder GRPO weiter verfeinern — dazu mehr weiter unten.

Wie viele Daten SFT benötigt

Die Forschung hat gezeigt, dass 1.000 hochwertige Beispiele deutlich bessere Ergebnisse liefern können als 100.000 minderwertige Stichproben. Für Produktionssysteme liegt die typische Datensatzgröße jedoch eher bei 10.000–100.000 Paaren, da man den langen Schwanz der Eingabevarianten abdecken möchte, die im realen Betrieb auftreten.

Ein praktisches Minimum für vertrauenswürdige Ergebnisse in einem Domänenprojekt sind rund 5.000 hochwertige Beispiele, die den Großteil der Themenbereiche abdecken, mit denen das Modell konfrontiert wird. Unterhalb dieser Schwelle kann das Modell sein Verhalten zwar auf gesehenen Daten verbessern, scheitert aber an Varianten, die es nicht gesehen hat.

Für regulierte Branchen (Recht, Medizin, Pharma) gilt eine strengere Regel: Der Datensatz muss jede Jurisdiktion und jeden Dokumenttyp abdecken, mit dem das Modell arbeiten soll. Unvollständige Abdeckung erzeugt ein Modell, das auch in Bereichen mit hoher Sicherheit antwortet, für die es nicht ausreichend Trainingsbeispiele gibt — das ist schlimmer, als das Problem überhaupt nicht anzugehen.

Was SFT nicht löst

SFT bringt dem Modell keine *Bewertung* bei — es weiß nicht, dass eine Antwort besser ist als eine andere, es weiß nur, dass eine solche Antwort existiert. Wenn das Modell dazu neigt, rücksichtslos zu antworten, an ungeeigneten Stellen zu knapp zu sein oder bestimmte Fragetypen zu meiden, behebt SFT allein das nicht. Dafür ist DPO zuständig.

DPO — Direct Preference Optimization: dem Modell beibringen, was besser ist

DPO (Direct Preference Optimization) trainiert über Präferenzpaare — zu jedem Prompt gibt es zwei Antworten: winner (bevorzugt) und loser (weniger bevorzugt). Das Modell lernt, seine Antwortverteilung in Richtung des winners und weg vom loser zu verschieben.

DPO ist eine vereinfachte Variante des ursprünglichen RLHF (Reinforcement Learning from Human Feedback) — es erfordert kein separates Reward-Modell, was es deutlich kostengünstiger und stabiler im Training macht.

DPO beantwortet die Frage: *„Wie soll das Modell entscheiden, wenn mehrere mögliche Antworten existieren?"*

Wann DPO einsetzen

DPO ist die richtige Wahl, wenn:

• Definierte Präferenzen vorliegen: welche Antwort besser und welche schlechter ist (durch Menschen verifiziert oder durch einen automatisierten Prozess bestätigt)
• Man die Tendenz des Modells verringern möchte, auf eine bestimmte unerwünschte Art zu antworten — zu passiv, zu lang, mit zu vielen Hedging-Phrasen
• Man den Kommunikationston anpassen möchte, ohne die Trainingsdaten komplett neu zu schreiben
• Man bereits eine SFT-Basis hat und den Alignment des Modells weiter verbessern möchte

Wie viele Daten DPO benötigt

Das empfohlene Minimum sind ~2.000 Präferenzpaare mit menschlich verifizierten winner/loser-Bewertungen. Das ist keine willkürliche Zahl — unterhalb dieser Schwelle lässt sich das Präferenzsignal nicht zuverlässig vom Rauschen der Verteilung trennen, und das Modell kann auf Artefakte einzelner Bewerter übertrainiert werden.

Für gute Generalisierung ist eine breitere Abdeckung anzustreben: 5.000–10.000 Paare, die verschiedene Prompt-Typen und Szenarien abdecken, sind ein typisches Produktionsziel.

Wichtiger als die Zahl ist die Qualität der Bewertung. Wenn winner/loser-Paare inkonsistent oder nach unklaren Kriterien bewertet werden, lernt das Modell eine inkonsistente Richtlinie. Vor der Datenerfassung muss eine klare Rubrik vorliegen — was genau macht eine Antwort besser.

Reihenfolge: SFT vor DPO ist zwingend

DPO wird auf ein Modell angewendet, das SFT durchlaufen hat — nicht direkt auf ein Base-Modell. Der Grund ist praktisch: Ein Base-Modell produziert zu hohe Antwortvariabilität, und das DPO-Signal „löst sich auf" — das Modell hat keine stabile Grundlage, auf der der Präferenzgradient wirken kann.

In der Praxis sieht das so aus:

1. 1.Base-Modell → SFT → Instruction-Tuned-Modell (antwortet konsistent auf gegebene Aufgabentypen)
2. 2.Instruction-Tuned-Modell → DPO → Aligned-Modell (bevorzugt bessere Antworten gegenüber schlechteren)

SFT zu überspringen und DPO direkt vom Base-Modell aus anzuwenden, produziert typischerweise instabile Ergebnisse oder ein Modell, das Anweisungen nicht folgt.

GRPO — Group Relative Policy Optimization: dem Modell Schlussfolgern beibringen

GRPO (Group Relative Policy Optimization) ist eine Methode aus der Familie RL-from-Rewards (Reinforcement Learning mit Belohnungen). Anstelle von Präferenzpaaren erhält das Modell eine verifizierbare Aufgabe — eine mathematische Gleichung, ein logisches Problem, eine Coding-Aufgabe — und bekommt eine Belohnung danach, ob seine Ausgabe objektiv korrekt ist.

GRPO erlangte Bekanntheit mit der Veröffentlichung von DeepSeek R1, wo es für reasoning-orientiertes Fine-Tuning eingesetzt wurde. Der entscheidende Vorteil gegenüber dem älteren PPO (Proximal Policy Optimization): GRPO erfordert kein separates Critic-Modell, was den VRAM-Bedarf senkt und die Trainingspipeline vereinfacht.

GRPO beantwortet die Frage: *„Wie bringt man dem Modell bei, bei Aufgaben mit verifizierbarer Antwort besser zu schlussfolgern?"*

Wann GRPO einsetzen

GRPO ist die richtige Wahl, wenn:

• Aufgaben mit verifizierbaren Antworten vorliegen — Mathematik, Code, Logik, SQL-Abfragen, Extraktion strukturierter Daten mit Gold-Annotation
• Man das Reasoning verbessern möchte — die Fähigkeit des Modells, mehrere Schritte durchzuarbeiten, ohne den Kontext zu verlieren
• Man das Modell dazu bringen möchte, Chain-of-Thought (Gedankenketten) bei Aufgaben zu generieren, wo das sinnvoll ist
• Eine Umgebung existiert, in der die Korrektheit der Ausgabe automatisch bewertet werden kann, ohne menschliche Bewerter

GRPO ist typischerweise der dritte Schritt der Pipeline, nicht der erste. Das Modell braucht eine solide SFT-Basis und idealerweise auch DPO-Alignment, bevor RL-Training effektiv wirkt.

Wie viele Daten GRPO benötigt

Das Minimum sind ~1.000 bewertete Trajektorien — Prompts mit verifizierbarer Antwort und einem funktionierenden Reward-Signal. Der Schwerpunkt liegt auf „verifizierbar": Die Belohnung muss konsistent und automatisch berechenbar sein. Wenn die Belohnung von subjektiver Bewertung abhängt, produziert das RL-Training instabile Ergebnisse.

In der Praxis wird GRPO auf kleineren, gezielten Datensätzen durchgeführt (Tausende, nicht Hunderttausende) — weil das Reward-Signal intensiver ist als ein überwachtes Signal. Auf der anderen Seite ist das Sammeln verifizierbarer Belohnungen teuer: Man muss eine Metrik definieren, einen Evaluator schreiben und sicherstellen, dass der Evaluator selbst keine Fehler macht.

Die experimentelle Gegenwart von GRPO

GRPO ist ein aktiver Forschungsbereich. Es gibt mehrere Varianten (DAPO und andere), und die Community erforscht aktiv, wo genau die Grenzen liegen. Für die meisten Domänenprojekte in einem B2B-Umfeld ist GRPO nur relevant, wenn:

• Man an reasoning-intensiven Aufgaben arbeitet (komplexe Analyse, mehrzeiliger Code, technische Diagnose)
• Die Kapazität vorhanden ist, eine Reward-Funktion zu schreiben und zu validieren
• Das Team Erfahrung mit RL-Training hat — das Debugging von RL ist deutlich komplexer als das Debugging von SFT

Für die meisten Domänenadaptionen (Stil, Terminologie, Format) sind SFT + DPO ausreichend und deutlich stabiler.

Drei Methoden im Vergleich — Kurzübersicht

SFT — Supervised Fine-Tuning: - Eingabe: (Prompt, gewünschte Antwort) Paare - Lernt: Format, Stil, Terminologie, Verhalten bei spezifischen Aufgaben - Datenminium: ~5.000 hochwertige Paare für ein domänenspezifisches Produktionssystem - Reihenfolge: immer der erste Schritt

DPO — Direct Preference Optimization: - Eingabe: (Prompt, winner-Antwort, loser-Antwort) Tripel - Lernt: bevorzugte Antwort, Alignment, Verbesserung von Ton und Entscheidungsfindung - Datenminium: ~2.000 menschlich verifizierte Präferenzpaare - Reihenfolge: nach SFT, nicht vom Base-Modell aus

GRPO — Group Relative Policy Optimization: - Eingabe: Prompt + automatisches Reward-Signal (verifizierbare Korrektheit) - Lernt: Reasoning, Chain-of-Thought, Genauigkeit bei verifizierbaren Aufgaben - Datenminium: ~1.000 bewertete Trajektorien mit funktionierendem Evaluator - Reihenfolge: nach SFT (und idealerweise DPO) als dritter Schritt

Katastrophales Vergessen — die versteckten Kosten jedes Fine-Tunings

Jede Methode birgt das Risiko von katastrophalem Vergessen (catastrophic forgetting): Ein Modell, das intensiv auf eine enge Domäne trainiert wird, kann in Fähigkeiten degradieren, die nicht in den Trainingsdaten vertreten sind. In der Praxis bedeutet das: Ein Modell, das beim Generieren technischer Reports glänzt, kann in konversationellen Fragen oder beim logischen Schlussfolgern außerhalb der Domäne schlechter werden.

PEFT-Mechanismen wie LoRA mildern diesen Effekt, da sie nur einen kleinen Teil der Gewichte modifizieren — eliminieren ihn aber nicht. Gegenmaßnahmen in der Praxis:

1. 1.Domänenspezifische Daten im Trainingsdatensatz mit generischen Stichproben mischen (5–15 % generischer Mix)
2. 2.Nach jedem Trainingslauf das Modell außerhalb der Domäne evaluieren — nicht nur auf domänenspezifischen Benchmarks
3. 3.Die Modellversion vor dem Fine-Tuning als Fallback aufbewahren

Einen genaueren Blick darauf, wie man misst, ob Fine-Tuning geholfen oder geschadet hat, bietet der Artikel Wie man misst, ob Fine-Tuning geholfen hat.

Pipeline in der Praxis: vom Base-Modell zum Produktions-Deployment

In B2B-Projekten, in denen wir domänenspezifische Modelle eingesetzt haben, sieht der typische Ablauf so aus:

Phase 1 — Basismodell wählen. Man wählt ein geeignetes Open-Weight-Modell (Qwen-, Llama-, Mistral-Familie) entsprechend VRAM-Kapazität und erforderlichem Kontextfenster. Für die meisten Domänenaufgaben ist ein 7B–14B-Modell das optimale Leistungs-/Preisverhältnis. Bei einer GPU mit 24 GB VRAM (z. B. RTX 3090/4090) funktioniert QLoRA auf 7B problemlos; für 13B ist es knapp machbar. Mehr zur Modellwahl und GPU-Dimensionierung im Artikel Welche GPU für LLM-Inferenz.

Phase 2 — SFT-Daten sammeln. Man identifiziert Aufgabentypen, das Format der gewünschten Antworten und die Terminologie. Dann sammelt oder generiert man 5.000–50.000 Paare. Für Domänenprojekte empfiehlt sich folgende Methode: 150–200 hochwertige, menschlich erstellte Seed-Beispiele, die 10–100× durch ein leistungsstarkes Frontier-Modell (Claude, GPT als teacher) erweitert werden. Das Ergebnis wird durch manuelle Annotation einer Stichprobe verifiziert.

Phase 3 — SFT-Lauf. Training mit LoRA oder QLoRA, typischerweise über einige Epochen. Auf einer A100-GPU in Stunden, nicht Tagen. Die groben Cloud-Kosten liegen in einer Größenordnung von einigen zehn Euro pro Lauf bei einem 7B-Modell und 10.000 Beispielen — abhängig vom Anbieter und der verwendeten GPU.

Phase 4 — Evaluation und Entscheidung. Ein Test-Set, das alle Aufgabentypen abdeckt. Wenn die Ergebnisse zufriedenstellend sind, geht das Modell in die Produktion. Wenn nicht — analysiert man, wo es scheitert, anstatt blind mehr Daten hinzuzufügen.

Phase 5 (optional) — DPO. Wenn die Kapazität besteht, Präferenzpaare zu sammeln, und das Modell ein konkretes Verhalten zeigt, das geändert werden soll (nicht nur fehlendes Wissen), ist DPO der richtige nächste Schritt.

Phase 6 (spezialisiert) — GRPO. Nur wenn man an einem reasoning-intensiven Use-Case arbeitet und ein verifizierbares Reward-Signal vorhanden ist.

Wann Fine-Tuning nicht die Antwort ist

Fine-Tuning ist nicht die Antwort auf jedes Problem. Wir haben Projekte erlebt, in denen ein Unternehmen Wochen in SFT investiert hat und das Ergebnis schlechter war als eine einfache RAG-Pipeline mit einem guten Prompt. Vor dem Fine-Tuning sollte man sich fragen:

• Liegt das Problem darin, was das Modell nicht weiß (Fakten, Dokumente) — dann ist RAG effizienter und günstiger. Fine-Tuning bringt einem Modell keine neuen Fakten zuverlässig bei, es verändert nur das Verhalten.
• Liegt das Problem darin, dass das Modell schlecht im Format oder Stil antwortet — dann kann ein besserer System-Prompt ausreichen, bevor man in einen Datensatz investiert.
• Hat man ausreichend hochwertige Daten für die Domänenabdeckung — wenn nicht, produziert Fine-Tuning ein Modell, das auch dort mit Sicherheit antwortet, wo es keine Grundlage hat.

Den Entscheidungsrahmen RAG vs. Fine-Tuning behandelt ausführlicher der eigenständige Artikel RAG vs. Fine-Tuning — wann was.

Häufige Fragen

Kann ich DPO direkt vom Base-Modell aus ohne SFT durchführen?

Technisch ja, das Ergebnis ist in der Regel instabil. Ein Base-Modell produziert zu variable Ausgaben — der DPO-Gradient kann nicht effektiv wirken, weil das Modell keine konsistente Verhaltensbasis hat. In der Praxis braucht man fast immer mindestens einen minimalen SFT-Durchlauf vor DPO.

Ist GRPO für Unternehmensprojekte außerhalb der Technologie geeignet?

GRPO ist stark dort, wo verifizierbare Antworten vorliegen — Mathematik, Code, strukturierte Extraktionen mit Gold-Annotation. Für die meisten B2B-Use-Cases (Kundensupport, Dokumentationsassistent, Reporting) sind SFT + DPO ausreichend und deutlich einfacher zu implementieren und zu debuggen. GRPO empfehlen wir nur, wenn das Team Erfahrung mit RL-Training hat.

Was kostet Fine-Tuning in der Cloud für ein 7B-Modell?

Grobe Schätzung: Ein SFT-Lauf auf 10.000 Beispielen dauert auf einer A100-GPU in der Größenordnung von Stunden, die Kosten liegen bei einigen zehn Euro (bei günstigeren Anbietern) bis zu niedrigen dreistelligen Eurobeträgen (Hyperscaler). Der tatsächliche Projektpreis hängt von der Anzahl der Iterationen, der Datensatzgröße und davon ab, wie oft das Training nach Datenanpassungen wiederholt wird. Der größere Kostenfaktor ist in der Regel das Sammeln und Annotieren von Daten, nicht das Training selbst.

Was ist katastrophales Vergessen und wie lässt es sich vermeiden?

Katastrophales Vergessen tritt auf, wenn Fine-Tuning auf einer engen Domäne die allgemeinen Fähigkeiten des Modells degradiert — etwa logisches Schlussfolgern oder konversationelle Fähigkeiten außerhalb der Domäne. Es lässt sich mildern, indem man Domänendaten mit generischen Stichproben mischt (5–15 % generischer Mix im Datensatz), den LoRA/QLoRA-Mechanismus verwendet (weniger aggressive Gewichtsmodifikation) und das Modell nach jedem Trainingslauf regelmäßig außerhalb der Domäne evaluiert.

Welches Open-Weight-Modell empfehlen Sie als Basis für domänenspezifisches SFT?

Für die meisten Domänenprojekte im Jahr 2026 sind Modelle aus den Familien Qwen, Llama oder Mistral im Bereich 7B–14B eine gute Grundlage. Die Wahl hängt von der Kontextlänge, der Lizenz und der Kompatibilität des Base-Modells mit dem Trainings-Framework ab. Für spezifische Empfehlungen mit konkreten Zahlen siehe Wie man ein LLM-Modell auswählt.

*Wenn Sie erwägen, ein eigenes Modell zu verfeinern, und nicht sicher sind, wo Sie anfangen sollen — SFT, DPO oder eine andere Methode — gehen wir gerne mit Ihnen einen konkreten Use-Case durch und erarbeiten einen realistischen Plan. Kontaktieren Sie uns auf mp-is.eu oder vereinbaren Sie direkt eine Beratung.*