Fine-Tuning von LLMs: Was sich 2026 ändert

Das Fine-Tuning von Sprachmodellen ist längst kein Laborritual mehr, sondern ein weiterer Baustein im Produkt-Stack. Was vor zwei Jahren noch dedizierte GPUs und wochenlange Arbeit erforderte, wird heute mit Low-Rank-Techniken, synthetischen Daten und verwalteten APIs gelöst. Doch die Landschaft hat sich so stark verändert, dass viele kursierende Rezepte noch an längst überholten Praktiken festhalten. Dieser Überblick konzentriert sich auf das, was das Feld gerade jetzt bewegt – ohne Wunder zu versprechen.

Was sich im Zyklus des Fine-Tunings verändert hat

Der klassische Ablauf – Instruktions-Antwort-Paare sammeln, alle Gewichte trainieren und nach Augenmaß evaluieren – hat sich aufgefächert. Teams, die mit offenen Modellen arbeiten, haben Varianten übernommen, die Kosten und Risiko senken:

• LoRA und seine Ableitungen (QLoRA, DoRA): Es wird nur ein minimaler Bruchteil der Parameter trainiert, während das Basismodell eingefroren bleibt. Die offizielle Dokumentation der wichtigsten Trainingsbibliotheken präsentiert sie bereits als Standardoption für Anpassungen mit weniger als einer Million Beispielen.
• Präferenzbasierte Ausrichtung: Statt Antworten zu imitieren, wird mit Präferenzpaaren optimiert (DPO und Varianten). Branchenstudien zufolge reduziert dieser Weg die Anzahl benötigter Beispiele im Vergleich zum traditionellen RLHF und vermeidet das Training eines separaten Belohnungsmodells.
• Destillation aus großen Modellen: Daten mit einem größeren Modell zu erzeugen und ein kleineres anzupassen, ist zur gängigen Praxis geworden. Die wichtige Nuance: Die Qualität des Lehrers setzt die Obergrenze des Schülers, und ungefilterte synthetische Daten schleppen Verzerrungen und Halluzinationen mit sich.

Ein realistischer Ablauf, Schritt für Schritt, mit den benannten Fallstricken

1. Das Zielverhalten definieren, bevor Daten angefasst werden

Der am häufigsten wiederholte Fehler, den ich bei Einsteigerteams sehe: das Training zu starten, ohne eine schriftliche Spezifikation dessen, was das Modell tun soll und – vor allem – was es nicht tun darf. Ohne diesen Vertrag ist die spätere Evaluation freie Interpretation. Es empfiehlt sich, 10 bis 20 Anwendungsfälle mit Beispielen für Eingabe und erwartete Ausgabe zu verfassen, einschließlich Grenzfällen (mehrdeutige Anfragen, außerhalb des Domänenbereichs, Manipulationsversuche).

2. Den Datensatz mit mehr Sorgfalt als Begeisterung kuratieren

Die übliche Größenordnung in funktionierenden Projekten liegt bei einigen Hundert bis wenigen Tausend gut annotierten Beispielen. Mehr Volumen mit Rauschen verschlechtert das Ergebnis. Drei Prüfungen, die oft übersprungen werden:

• Semantische Deduplizierung: nahezu identische Antworten mit leichten Variationen blähen den Datensatz auf und verzerren die Anpassung.
• Formatkonsistenz: Wenn 80 % der Antworten einen Stil verwenden und 20 % einen anderen, lernt das Modell beide und schwankt.
• Überprüfung von Annotationsverzerrungen: Wer annotiert, hinterlässt Spuren. Zwei verschiedene Annotatoren erzeugen unterschiedliche Verteilungen, selbst wenn sie derselben Richtlinie folgen.

3. Basis und Methode nach dem tatsächlichen Budget wählen

Nicht alles erfordert ein 70B-Modell. Für Klassifikationsaufgaben, Entitätsextraktion oder Antworten mit festem Format reicht meist ein mit QLoRA angepasstes 7-8B-Modell, das auf einer einzigen GPU bedient werden kann. Für komplexes Reasoning lohnt sich Fine-Tuning gegenüber einem größeren Modell mit gutem Prompting selten; dort übersteigen die Kosten der Modellbereitstellung den Nutzen.

Ein praktisches Detail, das in der Dokumentation mehrerer Plattformen auftaucht: Wenn das Ziel darin besteht, neues Wissen zu vermitteln (interne Richtlinien, Produktkatalog), ist Fine-Tuning ein mittelmäßiges Werkzeug. Dafür funktioniert Retrieval-Augmented Generation besser. Fine-Tuning glänzt, wenn die Art der Antwort geändert werden soll: Ton, Format, Ablehnungspolitik, Ausgabestruktur.

4. Von der ersten Minute an mit separater Validierung trainieren

10 % bis 20 % der Daten für die Validierung zurückzuhalten, ist nicht optional. Overfitting bei kleinen Modellen ist schnell und still: Der Trainingsverlust sinkt, während die Antworten starr und repetitiv werden. Das zu erkennen erfordert einen Blick auf Generierungsmetriken, nicht nur auf den Verlust.

5. Mit Bewertungsrubriken evaluieren, nicht mit Eindrücken

Hier scheitern die meisten Projekte. Eine ehrliche Evaluation kombiniert:

• Automatische Tests für Format und Einschränkungen (Wird das JSON-Schema eingehalten? Wird die Quelle zitiert? Wird abgelehnt, was abgelehnt werden muss?).
• Blinde menschliche Bewertung anhand einer kleinen Stichprobe, wobei Basis- und angepasstes Modell mit demselben Prompt verglichen werden.
• Ein Regressionsset, das zwischen Iterationen unverändert bleibt, um Drift zu messen.

Laut der offiziellen Dokumentation mehrerer Evaluierungsanbieter korrelieren automatische Metriken wie BLEU oder ROUGE schlecht mit dem wahrgenommenen Nutzen bei offenen Aufgaben. Sie taugen für das Format, nicht für die Qualität.

Der Fall, den kaum jemand erzählt: die Anpassung, die das Produkt verschlechterte

Ein Team passte ein 8B-Modell an, damit es Support-Anfragen in einem stark kontrollierten Ton beantwortet. Die Ergebnisse im Validierungsset waren hervorragend. In der Produktion begann das Modell, legitime Fragen abzulehnen, die oberflächlich denen ähnelten, die als außerhalb des Zuständigkeitsbereichs markiert worden waren. Das Problem war nicht das Training: Der Datensatz enthielt viele Ablehnungsbeispiele und sehr wenige mehrdeutige Fragen, die durchaus hätten beantwortet werden sollen. Die Lehre: Die Verteilung des Datensatzes definiert das Verhalten ebenso wie der Inhalt. Ein Fine-Tuning vermittelt keine Nuancen, die in den Daten nicht repräsentiert sind.

Tendenzen, die das Feld neu definieren

Spezialisierte kleine Modelle versus Monolithen

Die Kostenkurve der Inferenz drängt zu 3-8B-Modellen, die für eine konkrete Aufgabe angepasst sind. Mehrere Infrastrukturanbieter bieten bereits Low-Rank-Deployments mit wettbewerbsfähiger Latenz an. Die Nuance: Spezialisierung hat eine Obergrenze. Ein für den Kundenservice angepasstes kleines Modell wird nicht zum Generalassistenten, egal wie viel man es trainiert.

Anpassung mit gefilterten synthetischen Daten

Daten mit einem größeren Modell zu erzeugen und vor dem Training nach Qualität zu filtern, ist heute gängige Praxis. Das bekannte Risiko: Modelle, die auf ungeprüften synthetischen Daten trainiert wurden, neigen dazu, Fehler des Generators zu verstärken. Die Empfehlung, die in technischen Foren und Bibliotheksdokumentationen auftaucht, lautet, echte mit synthetischen Daten zu mischen und eine manuelle Prüfung anhand einer Stichprobe beizubehalten.

Evaluierung als Dienstleistung und Nachvollziehbarkeit

Der regulatorische Druck in einigen Branchen hat dazu geführt, den Anpassungsprozess zu dokumentieren: welche Daten, welche Methode, welche Evaluierung, welche bekannten Einschränkungen. Das ist keine Bürokratie: Es ist das, was es ermöglicht zu entscheiden, wann ein angepasstes Modell zurückgezogen werden muss, weil das Verhalten abgedriftet ist.

Was Fine-Tuning nicht löst

Das sollte man ohne Umschweife sagen. Fine-Tuning behebt kein Datenproblem, ersetzt bei einfachen Aufgaben kein gutes Prompt-Engineering und garantiert nicht, dass das Modell aufhört zu halluzinieren. Es ist auch nicht der Weg, um Wissen aktuell zu halten: Jede Änderung interner Richtlinien würde ein Neutraining erfordern, was Retrieval-Augmented Generation vermeidet. Und bei sehr großen Modellen können die Kosten für die Bereitstellung einer eigenen Anpassung die einer verwalteten API mit sorgfältigem Prompting übersteigen.

Die vernünftige Entscheidung hängt von einer vorherigen Frage ab: Muss ich ändern, wie das Modell antwortet, oder muss ich, dass es etwas weiß, was es nicht weiß? Die erste Frage rechtfertigt die Anpassung. Die zweite fast nie.