Fine-Tuning von LLMs: Wann lohnt sich die Anpassung eines Modells?

Fine-Tuning klingt nach Souveränität: ein eigenes Modell, das die eigene Sprache spricht, die eigenen Daten kennt, in der eigenen Infrastruktur läuft. In der Praxis scheitern aber viele Fine-Tuning-Projekte — nicht an der Technik, sondern an falschen Erwartungen, schlechten Daten und fehlender Evaluation. Dieser Beitrag zeigt, wann Fine-Tuning wirklich der richtige Hebel ist und wann andere Methoden günstiger und zuverlässiger zum Ziel führen.

1. Warum Fine-Tuning oft mehr verspricht als hält

Fine-Tuning wird in Vorträgen und Marketing-Decks oft als universelle Lösung präsentiert: „Wir trainieren ein Modell auf Ihre Daten, dann kennt es Ihr Geschäft.” In der Realität bedeutet Fine-Tuning erstmal: viel Arbeit, viel Geld, viel Risiko — und eine Reihe von Voraussetzungen, ohne die das Ergebnis nicht produktiv nutzbar ist.

Die häufigste Fehlerquelle ist die Verwechslung von Wissen und Verhalten. Fine-Tuning ist nicht der richtige Weg, um einem Modell Fakten beizubringen — dafür ist RAG zuständig. Fine-Tuning ist der richtige Weg, um einem Modell Stil, Format und Domänensprache beizubringen. Wer das verwechselt, verbrennt Budget.

2. Was Fine-Tuning wirklich verändert

Fine-Tuning verändert die Gewichtsmatrix eines LLMs — also die internen Parameter, die das Antwortverhalten bestimmen. Diese Veränderung wirkt sich aus auf:

• Stil und Tonalität. Ein auf juristische Texte fine-getunes Modell formuliert juristisch korrekt.
• Format und Struktur. Ein Modell, das konsequent auf JSON-Output trainiert wurde, hält das Format viel zuverlässiger ein.
• Domänenspezifisches Vokabular. Begriffe, die im Pretraining selten vorkamen, werden präziser verwendet.
• Klassifikationsverhalten. Bei Aufgaben mit definierten Kategorien lässt sich die Genauigkeit deutlich steigern.

Was Fine-Tuning nicht zuverlässig verändert:

• Faktenwissen in Bereichen, wo das Modell wenig Pretraining gesehen hat.
• Kontextverständnis über sehr lange Dokumente.
• Wahrheitsgehalt — Halluzinationen verschwinden durch Fine-Tuning nicht.

3. Fünf harte Voraussetzungen

Aus unserer Beratungspraxis: Wenn eine dieser Voraussetzungen fehlt, sollte Fine-Tuning verschoben werden.

1. Klar definierter Use Case. Eine Aufgabe, eine Eingabeart, eine erwartete Ausgabe. „Bessere Antworten” ist kein Use Case.
2. Eigene Daten in ausreichender Menge und Qualität. Mindestens einige hundert hochwertige Beispiele, sauber gelabelt, konsistent formatiert.
3. Eval-Suite vor dem Training. Mindestens 30 reale Testfälle mit Bewertungskriterien. Ohne Eval ist Fine-Tuning Blindflug.
4. Hardware-Plan. GPU-Zugang (lokal oder Cloud), klar definierte Budgets, Datenschutzlage geklärt.
5. Engineering-Disziplin. Reproduzierbare Pipelines, versionierte Datensätze, Logging. Ein Bash-Skript reicht nicht.

4. Was kostet Fine-Tuning realistisch?

Drei Kostentreiber:

• Datenarbeit. Das ist der größte Posten — typischerweise 60–80% des Gesamtaufwands. Sammeln, Bereinigen, Labeln, Validieren von Trainingsdaten.
• GPU-Stunden. Bei LoRA auf 8B-Modellen: 10–100 Euro pro Iteration. Bei Full Fine-Tuning auf 70B-Modellen: 1.000–10.000 Euro pro Iteration. Mehrere Iterationen sind die Regel.
• Eval und Deployment. Eval-Suite bauen, Modell verpacken, Monitoring einrichten, Rollback-Strategie definieren. Zeit, nicht Hardware.

Eine erste produktive LoRA-Iteration ist für 5.000–25.000 Euro Gesamtkosten realistisch. Full Fine-Tuning eines 70B-Modells mit kuratiertem Datensatz und Eval liegt eher bei 80.000–300.000 Euro. Die Rechnung lohnt sich nur, wenn der Mehrwert klar messbar ist.

5. Fine-Tuning gegen RAG abwägen

Eine pragmatische Heuristik:

• Wenn das Problem heißt „Antwortet falsch, weil Wissen fehlt” → RAG.
• Wenn das Problem heißt „Antwortet stilistisch falsch oder formal inkonsistent” → Fine-Tuning.
• Wenn beides zutrifft → erst RAG ausprobieren, dann Fine-Tuning ergänzen, wo nötig.

In den meisten Enterprise-Setups löst RAG 60–80% der ursprünglich als „Fine-Tuning nötig” eingeschätzten Probleme. Erst die verbleibenden 20–40% rechtfertigen den Fine-Tuning-Aufwand. Dazu passt unser Beitrag RAG, Fine-Tuning oder Prompt Engineering.

6. Risiken und Stolpersteine

• Schlechte Datenqualität. Ein Fine-Tuning auf inkonsistente, fehlerhafte oder einseitige Daten produziert ein Modell, das diese Fehler systematisch wiederholt. Mehr dazu in Warum KI-Projekte scheitern.
• Catastrophic Forgetting. Vor allem bei Full Fine-Tuning verliert das Modell allgemeine Fähigkeiten. LoRA mildert dieses Risiko.
• Overfitting. Zu kleine oder zu homogene Datensätze führen dazu, dass das Modell die Trainingsdaten auswendig lernt, aber an neuen Beispielen scheitert.
• Veraltung. Fakten, die heute korrekt sind, sind in einem Jahr veraltet. Fine-Tuning auf solche Inhalte bindet Sie an einen Re-Training-Zyklus.
• Lizenz- und Compliance-Risiken. Open-Weight-Modelle haben unterschiedliche Lizenzen (Llama, Apache, MIT, Restricted). Vor dem Fine-Tuning klären, ob die geplante Nutzung erlaubt ist.

7. Drei harte Entscheidungsregeln

Aus über 50 Beratungsfällen kristallisieren sich drei Regeln heraus:

1. Keine Investition in Fine-Tuning ohne Eval-Suite. Eval ist nicht Kür, sondern Pflicht. Wer ohne Eval startet, kann den Erfolg nicht messen.
2. LoRA vor Full Fine-Tuning. In 90% der Fälle reicht LoRA. Full Fine-Tuning ist die Ausnahme, nicht die Regel. Details in LoRA erklärt.
3. Erst RAG, dann Fine-Tuning. Wenn beides möglich erscheint, RAG zuerst — günstiger, flexibler, wartbarer.

Fine-Tuning ist 2026 keine Geheimwaffe, sondern ein präzises Werkzeug für eine genau umrissene Aufgabe. Wer es als Universallösung einsetzt, verbrennt Budget. Wer es gezielt einsetzt, wo die Voraussetzungen stimmen, baut sich einen echten Wettbewerbsvorteil — ein Modell, das die eigene Sprache spricht, in der eigenen Infrastruktur läuft und sich Iteration für Iteration weiterentwickelt. Der Weg dahin führt über saubere Daten, klare Use Cases und eine reife Eval-Pipeline — nicht über Vendor-Pitches.