Fine-Tuning – Was du jetzt wissen musst

Fine-Tuning lohnt sich, wenn dein Modell konsistent deinen Stil, dein Format und deine Fachterminologie beherrschen soll. Dank LoRA und QLoRA läuft das heute auf einer einzigen Consumer-GPU statt auf einem GPU-Cluster.

Wer glaubt, Fine-Tuning sei nur etwas für ML-Forschungsteams mit GPU-Cluster, verschenkt einen erheblichen Wettbewerbsvorteil. Die Methode ist längst keine Nischenübung mehr. Dank Parameter-effizienter Verfahren wie LoRA und QLoRA trainierst du grosse Sprachmodelle auf einer einzigen Consumer-GPU, mit einem Bruchteil des VRAM-Bedarfs, der vor zwei Jahren noch nötig war. Das ändert die Kalkulation für IT-Teams und Business-Analysten grundlegend: Was früher ein Forschungsprojekt war, ist heute eine machbare Engineering-Aufgabe.

Dieser Artikel erklärt dir, was Fine-Tuning technisch bedeutet, wann es gegenüber Prompt Engineering und RAG die bessere Wahl ist und wie du einen produktionsnahen Einstieg hinbekommst, ohne in klassische Fallen zu tappen.

Stand: Juni 2026. Die genannten VRAM-Werte, Modell-Beispiele und Plattform-Angebote entwickeln sich schnell weiter, prüfe vor einem Projekt die aktuellen Angaben der jeweiligen Anbieter.

Was bedeutet Fine-Tuning eigentlich?

Ein vortrainiertes Modell wie GPT-4o oder Llama 3 hat auf Billionen von Token gelernt, wie Sprache funktioniert. Fine-Tuning bedeutet: Du nimmst dieses Modell und trainierst es auf deinen spezifischen Daten weiter, damit es deine Terminologie kennt, dein Ausgabeformat einhält und in deiner Domäne konsistent performt.

Der entscheidende Unterschied zum Prompt Engineering: Du veränderst die Modellgewichte selbst. Das hat Konsequenzen. Das Verhalten wird stabiler, weil du es nicht bei jedem API-Call neu instruieren musst. Gleichzeitig kannst du mehr Wissen einbetten, als in ein Kontextfenster passt, und du sparst Token, weil lange System-Prompts wegfallen. Microsoft beschreibt den Effekt in der Azure-Foundry-Dokumentation qualitativ: Fine-Tuning liefert in passenden Fällen bessere Resultate als Prompt Engineering allein, reduziert die Latenz und senkt die Token-Kosten pro Request, weil weniger Anweisungen mitgeschickt werden müssen.

Warum machen LoRA und QLoRA den Unterschied?

Full Fine-Tuning, also das Anpassen aller Modellgewichte, ist für die meisten Teams nach wie vor unrealistisch. Ein Modell mit 70 Milliarden Parametern in voller Präzision zu trainieren, braucht dutzende High-End-GPUs. Hier kommen Parameter-effiziente Methoden (PEFT) ins Spiel, allen voran LoRA (Low-Rank Adaptation). Die Hugging-Face-PEFT-Dokumentation bündelt diese Verfahren als Open-Source-Standard.

Wie LoRA funktioniert

LoRA friert die originalen Modellgewichte ein und fügt kleine, trainierbare Adapterschichten hinzu. Statt alle Parameter zu verändern, trainierst du nur diese Adapter, laut der ursprünglichen LoRA-Arbeit ein winziger Bruchteil der Parameter gegenüber Full Fine-Tuning. Die Qualität bleibt dabei weitgehend erhalten, und du kannst mehrere Adapter für unterschiedliche Aufgaben getrennt vom Basismodell speichern.

QLoRA: wenn VRAM der Engpass ist

QLoRA geht einen Schritt weiter: Das Basismodell wird in 4-Bit-Quantisierung geladen, was den VRAM-Bedarf drastisch senkt. Die QLoRA-Arbeit zeigte, dass sich damit selbst sehr grosse Modelle auf einer einzigen GPU feinjustieren lassen, ohne nennenswerten Qualitätsverlust gegenüber voller Präzision. Konkrete Werte aus der QLoRA-Arbeit:

• Ein 65-Milliarden-Parameter-Modell auf einer einzigen 48-GB-GPU statt auf einem Cluster aus High-End-Karten
• Volle Task-Performance auf dem Niveau eines in 16-Bit voll feinjustierten Modells
• Rund 24 Stunden Trainingszeit auf einer einzelnen GPU für das dort vorgestellte 65B-Modell

Das bedeutet in der Praxis: Ein 13B-Modell lässt sich mit QLoRA auf einer NVIDIA RTX 4090 mit 24 GB VRAM trainieren. Ein 70B-Modell passt mit QLoRA knapp auf eine einzelne 48-GB-Karte wie die A6000, komfortabel wird es mit einer A100 oder H100 mit 80 GB. Das ist keine Forschungsinfrastruktur mehr, das ist kalkulierbar.

Fine-Tuning oder RAG: was wann?

Die häufigste Fehlannahme: Fine-Tuning und RAG (Retrieval-Augmented Generation) seien konkurrierende Ansätze. Sie sind es nicht, sie lösen unterschiedliche Probleme.

Fine-Tuning eignet sich für:

• Stabile, sich selten ändernde Eigenschaften: Stil, Tonalität, Ausgabeformat
• Fachterminologie, die das Basismodell nicht kennt (juristische Klauseln, steuerliche Fachbegriffe, interne Produktbezeichnungen)
• Aufgaben, bei denen konsistentes Verhalten wichtiger ist als aktuelle Fakten

RAG eignet sich für:

• Dynamisches, sich häufig änderndes Wissen (Preislisten, aktuelle Rechtslage, interne Dokumentation)
• Situationen, in denen Nachvollziehbarkeit und Quellenangaben erforderlich sind
• Anwendungsfälle, bei denen du den Ursprung einer Aussage auditieren musst

Die Kombination ist oft der pragmatischste Weg. Du nutzt Fine-Tuning, damit das Modell deinen Stil und deine Terminologie beherrscht, und RAG, damit es auf aktuelle Fakten zugreifen kann. Ein konkretes Beispiel: Ein Steuerberatungsunternehmen feinjustiert ein Modell auf interne Formulierungsstandards und schweizerisches Steuerrecht und koppelt es via RAG an eine laufend aktualisierte Rechtsdatenbank.

Wie strukturierst du ein Fine-Tuning-Projekt?

Schritt 1: Datenvorbereitung ist 80 % der Arbeit

Qualität schlägt Quantität. Für viele domänenspezifische Aufgaben reichen 500 bis 2’000 hochwertige Trainingsbeispiele. Die Daten müssen im Instruction-Tuning-Format vorliegen (Prompt/Response-Paare) und dürfen keine widersprüchlichen oder fehlerhaften Beispiele enthalten. Ein schlechtes Dataset erzeugt ein schlecht trainiertes Modell. Das klingt trivial, wird aber regelmässig unterschätzt.

Schritt 2: Epochen bewusst wählen

Eine verbreitete Fehlannahme ist, dass mehr Trainingsepochen zwingend besser sind. In der Praxis genügen für gut vortrainierte Basismodelle häufig 1 bis 3 Epochen. Mehr Epochen erhöhen das Risiko des Overfittings: Das Modell memoriert die Trainingsbeispiele, verliert aber Generalisierungsfähigkeit. Beobachte den Validierungsverlust und stoppe früh, wenn er stagniert.

Schritt 3: Evaluation nicht vernachlässigen

Definiere vor dem Training, was du misst. Mögliche Metriken je nach Anwendungsfall:

• Format-Compliance: Hält das Modell das gewünschte Ausgabeformat ein?
• Terminologie-Treffer: Verwendet es die korrekten internen Begriffe?
• Halluzinationsrate auf einem Holdout-Testset
• Task-spezifische Benchmarks (F1, BLEU, menschliche Evaluation)

Ohne definierte Evaluation weisst du nach dem Training nicht, ob du etwas verbessert oder verschlechtert hast.

Welche Tools und Plattformen sind relevant?

Für Teams ohne eigene ML-Infrastruktur gibt es heute mehrere produktionsreife Optionen:

• Microsoft Azure AI Foundry bietet Fine-Tuning mit LoRA direkt über die Plattform an, inklusive Monitoring und Deployment. Relevant, wenn dein Unternehmen ohnehin in der Azure-Welt ist.
• OpenAI Fine-Tuning: Die hauseigene Self-Serve-Plattform wickelt OpenAI ab und ist für Neueinsteiger bereits geschlossen: Organisationen ohne bisherige Fine-Tuning-Nutzung können dort keine Trainings-Jobs mehr anlegen, ab dem 2. Juli 2026 gilt das auch für Organisationen ohne aktive Nutzung und ab dem 6. Januar 2027 selbst für aktive Bestandskunden. Bereits feinjustierte Modelle bleiben nutzbar, bis ihr Basismodell abgeschaltet wird. Wer OpenAI-Modelle anpassen will, geht deshalb über Azure AI Foundry (siehe oben), sonst über den Open-Weights-Weg.
• Hugging Face mit PEFT-Library ist der Open-Source-Standard. Mit transformers, peft und trl hast du volle Kontrolle über Methode, Hyperparameter und Datenpipeline. Kombiniert mit bitsandbytes für die Quantisierung läuft QLoRA auf lokaler Hardware.
• Unsloth hat in der Community zuletzt Aufmerksamkeit gewonnen: Die Library verspricht laut eigenen Angaben deutlich schnelleres Training mit LoRA und QLoRA auf Consumer-GPUs, bei reduziertem Speicherbedarf und minimalem Code-Overhead.

Worauf musst du beim Datenschutz achten?

Das wird in vielen Praxisartikeln weggelassen, ist aber zentral: Wenn du Fine-Tuning mit internen Unternehmensdaten durchführst, gelten dieselben Compliance-Anforderungen wie bei jedem anderen Datenverarbeitungsvorgang. Das bedeutet konkret:

• Trainierst du über eine Cloud-API (etwa OpenAI oder Azure), prüfe in den Vertragsbedingungen, ob deine Trainingsdaten für das weitere Training fremder Modelle verwendet werden dürfen. Geschäftskunden-Tarife schliessen das in der Regel aus, aber lass dir das schriftlich geben.
• Kläre, in welcher Region die Daten verarbeitet und gespeichert werden. Für DACH-Unternehmen mit Personendaten ist die physische Verarbeitung in der EU oder der Schweiz oft eine Pflicht, kein Nice-to-have.
• Anonymisiere oder pseudonymisiere Trainingsbeispiele, wo immer das möglich ist. Ein feinjustiertes Modell kann Trainingsdaten teilweise rekonstruieren, deshalb gehören echte Personendaten, Geheimnisse und Zugangsdaten nicht ins Dataset.
• Dokumentiere die Datenherkunft und die Rechtsgrundlage. Wenn du das Modell später auditieren oder löschen musst, brauchst du diese Nachweise ohnehin.
• Bei besonders sensiblen Daten ist lokales Fine-Tuning per QLoRA auf eigener Hardware der sicherste Weg: Die Daten verlassen dein Haus nie.

Einordnung für die DACH-Region

Wer produktive Unternehmensdaten fürs Fine-Tuning nutzt, bewegt sich je nach Standort in unterschiedlichen Datenschutzregimes: in der Schweiz gilt das revidierte Datenschutzgesetz (revDSG), in Deutschland und der EU die DSGVO ergänzt um das BDSG, in Österreich die DSGVO in Verbindung mit dem nationalen DSG. Die Grundlinie ist überall ähnlich, die Details unterscheiden sich. Das ist keine Rechtsberatung, sondern eine erste Orientierung, kläre den konkreten Fall mit einer fachkundigen Stelle.

Fazit: wann sich Fine-Tuning lohnt

Fine-Tuning ist heute eine kalkulierbare Engineering-Aufgabe, kein Forschungsprojekt. Setz es ein, wenn dein Modell stabil deinen Stil, dein Format und deine Fachterminologie beherrschen soll und Prompt Engineering an seine Grenzen stösst. Für aktuelles, sich häufig änderndes Wissen bleibt RAG die bessere Wahl, oft ist die Kombination aus beidem der pragmatischste Weg. Starte klein: 500 bis 2’000 saubere Beispiele, 1 bis 3 Epochen, QLoRA auf einer einzelnen GPU und eine klar definierte Evaluation, bevor du trainierst. Und kläre den Datenschutz, bevor die ersten internen Daten ins Dataset wandern, nicht danach.

Mehr Orientierung im Themenfeld findest du in unseren KI-Grundlagen, dem strukturierten Einstieg in die wichtigsten KI-Konzepte für die Praxis.