Lösungen für
Bitte auswählen
Web-App testen
ki-konzepte

Fine-Tuning einfach erklärt — wann, wie, womit

Redaktion ·

Warum dich Fine-Tuning angeht — und warum du es trotzdem oft nicht brauchst

Fine-Tuning klingt nach dem nächsten logischen Schritt, sobald ein vortrainiertes Sprachmodell für deinen Anwendungsfall nicht mehr reicht. Die Praxis ist nüchterner: Die meisten Probleme, die Teams als „das Modell weiß zu wenig” beschreiben, lassen sich sauberer mit Retrieval (RAG) oder besseren Prompts lösen. Fine-Tuning rentiert sich erst, wenn Stil, Format oder Domänen-Vokabular so spezifisch sind, dass Kontext-Engineering an seine Grenzen kommt — oder wenn die Inferenz-Kosten eines großen Modells durch ein kleineres, getuntes ersetzt werden sollen.

Dieser Artikel ordnet das Feld: Welche Verfahren gibt es, wofür sind sie gemacht, was kosten sie an Daten und Hardware, und wo liegen die typischen Stolperfallen. Du sollst danach entscheiden können, ob Fine-Tuning für dein Vorhaben das richtige Werkzeug ist — und wenn ja, welches.

Grundmechanik — was beim Tunen eigentlich passiert

Ein vortrainiertes Modell hat seine Gewichte aus Milliarden Tokens gelernt. Fine-Tuning bedeutet, diese Gewichte mit einem deutlich kleineren, kuratierten Datensatz weiterzutrainieren, bis das Modell ein gewünschtes Verhalten zeigt: Antworten in einem bestimmten Stil, Korrektur von Domänen-Begriffen, oder die Fähigkeit, einem speziellen Antwortformat zu folgen.

Drei Dinge ändern sich gegenüber dem Pretraining: Der Datensatz ist klein (typisch 1.000 bis 100.000 Beispiele statt Milliarden Tokens), die Lernrate ist niedriger, und das Trainingsziel ist enger gefasst. Das Modell verlernt nichts grundsätzlich — aber es kann durchaus Wissen aus dem Pretraining überschreiben, wenn der Tuning-Datensatz schief liegt. Dieses Phänomen heißt Catastrophic Forgetting und ist die häufigste Ursache für „nach dem Tuning kann das Modell plötzlich schlechter Mathematik”.

Zwei Trainingsziele, zwei Familien

Fine-Tuning zerfällt in zwei Großgruppen mit sehr unterschiedlicher Mechanik:

Volumen-Training lehrt das Modell neue Inhalte oder neue Formate. Hier füttert man Eingabe-Ausgabe-Paare ein und lässt das Modell die Ausgabe imitieren. Klassiker: Supervised Fine-Tuning (SFT) mit Instruction-Datensätzen oder Continued Pretraining mit rohen Domänen-Texten.

Präferenz-Alignment lehrt das Modell, welche von zwei plausiblen Antworten besser ist. Es bekommt Paare „bevorzugt vs. abgelehnt” und lernt aus dem Unterschied. Verfahren: RLHF (klassisch, aber aufwändig), DPO (leichter, weil ohne Reward-Modell) und ORPO (kombiniert SFT und Präferenz in einem Schritt).

In der Praxis fährt man die beiden Stufen oft hintereinander: Erst SFT, damit das Modell überhaupt sinnvoll auf das Format reagiert; dann DPO oder ORPO, um den Ton und die Vorlieben zu schärfen.

Wann Fine-Tuning sich lohnt — und wann nicht

Bevor du eine GPU buchst: Drei Werkzeuge konkurrieren um denselben Slot, und sie lösen unterschiedliche Probleme.

| Problem | Richtiges Werkzeug | Warum | |---|---|---| | Modell kennt deine internen Dokumente nicht | RAG | Wissen einspeisen, ohne Modell anzufassen | | Modell formuliert nicht im Hausstil | Prompt-Engineering, dann SFT | Stil per System-Prompt versuchen, erst bei Skalierung tunen | | Modell soll strukturierte Outputs zuverlässig liefern | Constrained Decoding oder SFT | Decoding-Tricks zuerst, Tuning nur bei harten Schemata | | Inferenz-Kosten eines großen Modells zu hoch | SFT auf kleines Modell | Großes Modell als Lehrer, kleines als Schüler (Knowledge Distillation) | | Modell soll Bewertungen / Tonalität verinnerlichen | DPO/ORPO | Präferenz-Daten sind genau dafür gemacht | | Domänen-Vokabular fehlt komplett | Continued Pretraining + SFT | Erst Sprache nachholen, dann Aufgabenformat |

Faustregel: Wenn du das Verhalten mit fünf gut gewählten Beispielen im Prompt erreichst, brauchst du kein Fine-Tuning. Wenn du dasselbe für 50.000 Anfragen pro Tag brauchst und der lange Prompt jedes Mal Token kostet, lohnt sich der Schritt.

Effizientes Tunen — die PEFT-Familie

Volles Fine-Tuning, also alle Gewichte eines Modells zu aktualisieren, ist teuer: Ein 70B-Modell braucht im FP16-Training mehrere hundert GB VRAM, weil zusätzlich zum Modell selbst noch Optimizer-States und Gradienten gehalten werden müssen. Kein heimischer Rechner und auch kein einzelner Cloud-Server packt das.

Die PEFT-Familie (Parameter-Efficient Fine-Tuning, siehe PEFT) löst das Problem, indem nur ein Bruchteil der Parameter trainiert wird. Die ursprünglichen Gewichte bleiben eingefroren, dazwischen werden kleine, trainierbare Module gehängt.

LoRA und QLoRA

LoRA injiziert pro Schicht zwei kleine Matrizen, deren Produkt zur ursprünglichen Gewichts-Matrix addiert wird. Trainiert werden nur die kleinen Matrizen — typisch 0,5 bis 5 Prozent der Gesamt-Parameter. Speicherbedarf sinkt drastisch, Trainingsqualität ist für die meisten Anwendungen nahezu identisch zum vollen Tuning.

QLoRA geht einen Schritt weiter: Das Basismodell wird in 4 Bit quantisiert geladen, der LoRA-Adapter selbst läuft in 16 Bit. Damit passt ein 70B-Modell auf eine einzelne 48-GB-GPU. Der Qualitätsverlust durch die 4-Bit-Quantisierung ist messbar, aber für die meisten Tuning-Aufgaben akzeptabel.

Adapter und Prefix-Tuning

Adapter sind eigene kleine Netzwerk-Schichten, die zwischen die bestehenden Schichten geschaltet werden. Sie sind älter als LoRA und werden heute seltener eingesetzt, leben aber in spezialisierten Settings (Multi-Task-Tuning, sehr kleine Modelle) weiter.

Prefix-Tuning hängt trainierbare „virtuelle Tokens” vor den Input und ändert die Modellgewichte gar nicht. Sehr leicht, aber qualitativ meist hinter LoRA — heute eher Forschungs- als Produktiv-Werkzeug.

Hardware: AMD vs. NVIDIA in der Praxis

Wer trainieren will, muss sich der Hardware-Realität stellen.

NVIDIA ist der Pfad des geringsten Widerstands. CUDA, PyTorch und das gesamte Ökosystem (bitsandbytes für Quantisierung, Flash Attention, vLLM für Inferenz) sind dort zu Hause. Ein A100 oder H100 ist die Referenz-Plattform; Consumer-GPUs wie die RTX 4090 (24 GB) reichen für QLoRA bis ~30B-Modelle, eine RTX 6000 Ada (48 GB) bis ~70B.

AMD holt mit ROCm auf, ist aber nicht auf Augenhöhe. PyTorch unterstützt ROCm offiziell, viele Tuning-Bibliotheken laufen nativ — aber: Kernels für Quantisierung sind oft NVIDIA-only oder hinken hinterher, Flash Attention ist auf AMD später und mit Einschränkungen verfügbar, und Speicher-Optimierungen wie bitsandbytes-NF4 funktionieren auf ROCm nicht out-of-the-box. Wer eine MI300X oder eine W7900 hat, kann LoRA und QLoRA fahren, muss aber mit mehr Konfigurations-Aufwand rechnen.

Faustregel: Für ein erstes Tuning-Projekt ist NVIDIA der pragmatische Weg. AMD lohnt sich, wenn die Hardware ohnehin steht oder Datenschutz / Vendor-Diversität strategisch wichtig ist.

Tools im Überblick

| Tool | Stärke | Wofür | |---|---|---| | Hugging Face TRL | Standard-Library für SFT, DPO, ORPO, RLHF | Voller Verfahrens-Stack, gute Doku, NVIDIA + AMD | | Unsloth | 2–5× schnelleres Training, weniger VRAM | LoRA/QLoRA auf einer Consumer-GPU, NVIDIA-fokussiert | | Axolotl | Konfig-driven, viele Modelle out-of-the-box | Reproduzierbare Trainings, Team-Setups | | Together AI / Fireworks | Managed Fine-Tuning per API | Wenn keine eigene GPU verfügbar ist | | OpenAI Fine-Tuning API | Closed-Model-Tuning auf GPT-Familie | Wenn ein OpenAI-Modell die Basis sein muss |

Hugging Face TRL ist der Default für eigenes Tuning, Unsloth der Beschleuniger für kleinere Setups, und Managed-Anbieter sind die Brücke, wenn die GPU-Beschaffung das Bottleneck ist.

Stolperfallen

Drei Probleme tauchen in fast jedem Tuning-Projekt mindestens einmal auf.

Catastrophic Forgetting. Ein zu langer SFT-Lauf auf einem schmalen Datensatz lässt das Modell allgemeines Wissen verlernen. Sichtbar wird das erst beim Eval auf Out-of-Domain-Aufgaben — Mathe, Code, allgemeines Reasoning. Gegenmittel: niedrigere Lernrate, weniger Epochs, Mischung mit allgemeinen Beispielen, oder PEFT statt Full Fine-Tuning.

Schlechte Datenqualität. Tuning ist erbarmungslos darin, Datenfehler zu lernen. Inkonsistente Antworten, falsche Formate, Rechtschreibfehler in „goldenen” Beispielen — alles wird übernommen. Mehr Daten helfen nicht, wenn die Daten falsch sind. Lieber 1.000 saubere Beispiele als 10.000 schmutzige.

Eval-Lücken. Viele Teams tunen, sehen im Spot-Check „klingt gut” und deployen. Drei Wochen später meldet das Produkt-Team Regressionen, die niemand kommen sah. Vor dem Tunen: ein Eval-Set bauen, das den Anwendungsfall abdeckt; vor dem Deployen: gegen das Eval-Set messen und mit dem Basismodell vergleichen. Ohne diesen Schritt ist Tuning ein Blindflug.

Praxis-Rechenbeispiel

Angenommen, du willst ein 8B-Modell auf 10.000 Domänen-Beispiele tunen, drei Epochs.

| Variante | VRAM-Bedarf | Dauer auf RTX 4090 | Cloud-Kosten (A100, 80 GB) | |---|---|---|---| | Volles Fine-Tuning (FP16) | ~120 GB | nicht möglich | ~6 h × 2,50 € ≈ 15 € | | LoRA (FP16-Basis) | ~28 GB | ~4 h | ~3 h × 2,50 € ≈ 8 € | | QLoRA (4-Bit-Basis) | ~10 GB | ~5 h | ~4 h × 2,50 € ≈ 10 € |

Auf der lokalen RTX 4090 (24 GB) läuft volles Tuning nicht, aber QLoRA bequem und LoRA gerade so. Auf einem Cloud-A100 ist volles Tuning machbar, kostet aber das Doppelte von LoRA bei kaum messbarem Qualitätsvorsprung — und der Adapter ist nur ~50 MB groß, statt 16 GB für die volle Gewichts-Datei.

Bei 70B verschiebt sich das Bild: Volles Tuning braucht Multi-GPU-Setups (4–8× A100), QLoRA passt auf eine einzelne 48-GB-Karte. Genau das ist der Grund, warum QLoRA der Default für große Modelle geworden ist.

FAQ

Wie viele Daten brauche ich?
Für SFT mit klarem Format reichen oft 500–2.000 Beispiele, wenn sie sauber sind. Für DPO 1.000–5.000 Präferenz-Paare. Continued Pretraining braucht deutlich mehr — eher 100 MB+ Rohtext.
Kann ich synthetische Daten nutzen?
Ja, das ist der Standardweg, wenn keine echten Daten in ausreichender Menge da sind. Ein größeres Modell generiert Trainings-Beispiele, die du danach manuell oder mit einem Judge-Modell filterst. Risiko: Mode Collapse, wenn der Generator die Schwächen hat, die du eigentlich beheben wolltest.
Soll ich Fine-Tuning auf einem Open-Weight-Modell oder über die OpenAI-API machen?
Open-Weight ist günstiger pro Token, du behältst die Gewichte, aber du betreibst die Inferenz selbst. OpenAI-Tuning ist bequemer, aber teurer pro Token und du kannst das getunte Modell nicht exportieren.
Was ist der Unterschied zwischen Instruction-Tuning und SFT?
Instruction-Tuning ist eine Sonderform von SFT, bei der die Trainings-Beispiele explizit „Instruktion → Antwort"-Paare sind. Begrifflich überlappend, in der Praxis dasselbe Verfahren mit anderem Datensatz-Stil.

Fazit

Fine-Tuning ist ein präzises Werkzeug, kein Universalheilmittel. Bevor du tunest, prüfe, ob RAG (für Wissen) oder Prompt-Engineering (für Stil und Format) das Problem nicht günstiger lösen. Wenn Tuning der richtige Weg ist, fang mit LoRA oder QLoRA an — voller Fine-Tuning lohnt sich erst, wenn die Adapter-Variante an Grenzen stößt, was bei den meisten Anwendungsfällen nicht passiert.

Die Hardware-Wahl ist heute pragmatisch: NVIDIA für den Standardfall, AMD wenn die Karten ohnehin im Haus sind und ein gewisser Konfigurations-Aufwand akzeptabel ist. Tools-seitig sind Hugging Face TRL plus Unsloth der schnellste Einstieg, Managed-Dienste die Brücke ohne eigene GPU.

Was bleibt, ist die unspektakulärste Empfehlung des Artikels: Bau das Eval, bevor du tunest. Alles andere ist Optimierung von Komponenten, die du am Ende nicht messen kannst — und damit kein Fine-Tuning, sondern Hoffnung.

Themenuebersicht

KI-KonzepteTraining & Fine-Tuning