Vorab: die meisten Fine-Tuning-Anfragen sind RAG-Anfragen
«Wir wollen ein LLM auf unsere Daten trainieren»: Mit diesem Satz beginnen viele Erstgespräche bei uns. Dahinter steckt nach unserer Erfahrung fast immer ein Wissensproblem. Das Modell soll Produktdaten, Verträge oder die interne Dokumentation kennen und daraus korrekt antworten.
Genau dafür ist Fine-Tuning das falsche Werkzeug: Es verändert das Verhalten eines Modells, also Tonfall, Antwortformat und Aufgabenroutine. Wissen dagegen gehört in eine Datenbank, aus der das Modell zur Laufzeit liest — das leistet Retrieval-Augmented Generation, kurz RAG.
Die vollständige Abwägung zwischen beiden Ansätzen findest du im Schwesterartikel RAG vs. Fine-Tuning. Und wo Fine-Tuning in der Gesamthierarchie der Modell-Anpassung steht, zeigt der Entscheidungsbaum in unserem Überblick Eigenes KI-Modell trainieren. Dieser Artikel macht deshalb nur eines: Er geht in die Tiefe der Stufe Fine-Tuning. Du erfährst, was Fine-Tuning 2026 technisch bedeutet, in welchen drei Fällen es sich lohnt, was es wirklich kostet und wann du besser die Finger davon lässt.
Meine These vorweg: Fine-Tuning ist die am meisten überschätzte Stufe der Modell-Anpassung. Die meisten, die es anfragen, brauchen RAG — und wer es wirklich braucht, unterschätzt fast immer die entscheidende Stelle: nicht das Training, sondern die Daten.
Merksatz: Fine-Tuning ändert, wie dein Modell antwortet. RAG ändert, woraus es antwortet.
Fine-Tuning 2026 heißt: Open Weights plus LoRA
Zum Marktumfeld: Wer heute Fine-Tuning plant, plant es nicht mehr bei OpenAI. Die offizielle Deprecation-Übersicht (Abruf 18.08.2026) nennt drei Daten.
Seit dem 7. Mai 2026 können Organisationen, die das Fine-Tuning nie genutzt haben, keine neuen Trainingsjobs mehr starten. Seit dem 2. Juli 2026 gilt das auch für Organisationen ohne Inferenz auf einem fine-getunten Modell in den letzten 60 Tagen. Und ab dem 6. Januar 2027 kann niemand mehr neue Jobs anlegen, auch aktive Bestandskunden nicht. Einen Nachfolger hat OpenAI nicht angekündigt.
Eine Nuance ist wichtig: Bestehende fine-getunte Modelle laufen weiter, bis ihr jeweiliges Basismodell abgeschaltet wird. Neu anfangen kannst du dort aber nicht mehr. Wer seine Automatisierung auf ein fine-getuntes GPT-Modell gebaut hat, sollte die Migration deshalb jetzt planen und nicht erst zur Abschaltung des Basismodells.
LoRA: kleine Adapter statt kompletter Modelle
Die praktische Konsequenz: Fine-Tuning heißt 2026 Open-Weight-Modelle wie Llama, Qwen oder Mistral, trainiert auf eigener oder gemieteter Infrastruktur. Und es heißt fast immer LoRA statt Full Fine-Tuning. LoRA (Low-Rank Adaptation) friert die Originalgewichte ein und trainiert nur kleine Zusatzmatrizen, die sich dem Modell zur Laufzeit überlagern.
Die Zahlen aus dem Originalpaper sind bemerkenswert: Gegenüber Full Fine-Tuning mit Adam reduziert LoRA die trainierbaren Parameter um den Faktor 10.000 und den GPU-Speicherbedarf um den Faktor 3, gemessen an GPT-3 mit 175 Milliarden Parametern (Hu et al., 2021). Die Qualität liegt dabei auf dem Niveau des vollständigen Trainings oder darüber.
Für dich bedeutet das zweierlei: Ein Trainingslauf passt auf eine einzelne gemietete GPU. Und das Ergebnis ist eine kleine Adapter-Datei von wenigen hundert Megabyte, nicht ein komplettes Modell von mehreren hundert Gigabyte.
Die Modellwahl: Größe, Lizenz, Deutschfähigkeit
Welches Modell nimmst du stattdessen? Die kurze Antwort: das kleinste, das deine Aufgabe schafft. Für Extraktion und Klassifikation reichen oft Modelle mit 3 bis 8 Milliarden Parametern; für frei formulierte Texte in Markensprache greifst du eher zur Klasse zwischen 20 und 70 Milliarden.
Zwei Dinge prüfst du vor der Wahl: die Lizenz, denn nicht jedes Open-Weight-Modell erlaubt jede kommerzielle Nutzung ohne Auflagen, und die Deutschfähigkeit, denn sie schwankt zwischen den Modellfamilien deutlich. Beides testest du am besten vor dem Training mit deinen eigenen Beispielen im reinen Prompting-Betrieb: Das kostet einen Nachmittag und erspart dir ein Training auf dem falschen Fundament.
Die drei Fälle, in denen Fine-Tuning sich lohnt
Wann also doch? Nach unserer Projekterfahrung gibt es genau drei Muster, in denen Fine-Tuning einen messbaren Vorsprung gegenüber Prompting und RAG bringt.
Ton und Format. Dein Modell soll in der Markensprache schreiben oder ein striktes Ausgabeformat einhalten: Support-Antworten im Hausstil, Gutachten nach fester Gliederung, JSON ohne einen einzigen Ausreißer. Solches Verhalten lässt sich per Prompt nur mühsam erzwingen, denn jede Formatvorgabe im Prompt kostet Kontextplatz und wird trotzdem gelegentlich ignoriert. Antrainiert sitzt es zuverlässig.
Extraktion und Klassifikation in Serie. Die gleiche eng umrissene Aufgabe, hundert- oder tausendfach pro Tag: Rechnungspositionen auslesen, E-Mails in zwölf Kategorien sortieren, Freitext aus Formularen in Strukturen überführen. Hier schlägt ein fine-getuntes kleines Modell oft ein großes generisches, bei einem Bruchteil der Kosten pro Aufruf. Ein anschaulicher Anker: Wer täglich 5.000 Dokumente durch ein großes API-Modell schickt, zahlt dafür jeden Monat aufs Neue. Ein einmal trainiertes Spezialmodell erledigt dieselbe Serie auf eigener Hardware zum Fixpreis.
Ein kleines Spezialmodell statt eines großen Generalisten. Wenn Latenz oder Stückkosten drücken, lohnt der Tausch: Ein 8B-Modell mit Fine-Tuning erreicht auf einer klar abgegrenzten Aufgabe häufig die Qualität eines deutlich größeren Modells, antwortet schneller und läuft auf günstigerer Hardware. Genau dieses Muster trägt viele unserer Automatisierungsprojekte: ein kleines Modell, eine Aufgabe, hohe Stückzahl.
Bleibt die Frage nach der Datenmenge. Die konkretesten publizierten Schwellwerte stammen aus der OpenAI-Dokumentation zum Supervised Fine-Tuning (Stand 08/2026): Das Minimum sind 10 Beispiele, sichtbare Verbesserungen beginnen bei 50 bis 100, empfohlen ist der Start mit 50 sorgfältig gebauten Demonstrationen. Die Plattform dahinter wird abgewickelt, als Richtschnur für LoRA auf Open-Weight-Modellen taugen die Werte trotzdem. Wichtiger als die Anzahl ist die Qualität: 50 saubere, einheitlich formatierte Beispiele schlagen 500 zusammengekratzte.
Merksatz: Wenn du keine 50 guten Beispiele zusammenbekommst, hast du kein Fine-Tuning-Projekt. Du hast ein Datenproblem.
Was es wirklich kostet: eine ehrliche Rechnung
Jetzt zu den Zahlen, die in kaum einem Artikel zum Thema stehen. Together AI, einer der größten Anbieter für Fine-Tuning auf Open-Weight-Modellen, veröffentlicht eine Preisliste (Abruf 18.08.2026): LoRA-Training kostet 0,48 $ pro Million Trainings-Token für Modelle bis 16 Milliarden Parameter, 1,50 $ für 17 bis 69 Milliarden und 2,90 $ für 70 bis 100 Milliarden. Full Fine-Tuning kostet jeweils das Zweieinhalbfache: 1,20 $, 3,75 $ und 7,25 $.
Die Mindestgebühr pro Trainingsjob liegt bei 4,00 $. Wer lieber dedizierte Rechenleistung bucht: Eine H100-GPU kostet dort 5,49 $ pro GPU und Stunde, ein LoRA-Lauf für ein 8B-Modell ist auf ihr eine Sache von Stunden, nicht Tagen.
Rechnen wir ein typisches Projekt durch. 75 Trainingsbeispiele mit je rund 2.000 Token ergeben 150.000 Token; bei drei Trainingsdurchläufen (Epochen) sind das 450.000 Token, also weniger als eine halbe Million. Der LoRA-Lauf eines 8B-Modells bleibt damit unter der Mindestgebühr: Das Training kostet 4 $. Kein Tippfehler. Der Trainingslauf ist der billigste Posten des gesamten Projekts.
Warum kalkulieren wir solche Projekte trotzdem in Personentagen? Weil der Aufwand woanders steckt: Beispiele auswählen, bereinigen, einheitlich formatieren, eine Testmenge abtrennen und eine Evaluations-Pipeline bauen, die den Erfolg messbar macht.
In der Praxis legen wir vor dem Training einen Teil der Beispiele als Testmenge beiseite und definieren pro Aufgabe eine Metrik: Feldgenauigkeit bei der Extraktion, Trefferquote bei der Klassifikation, eine Bewertungs-Rubrik bei frei formuliertem Text. Nach unserer Projekterfahrung entfällt der weit überwiegende Teil der Stunden auf Datenaufbereitung und Evaluation, nicht auf das Training: Das ist ein Erfahrungswert von uns, keine Publisher-Zahl.
Für die Wirtschaftlichkeit reicht darum eine einfache Formel: Amortisationszeit in Monaten = Einmalkosten für Daten, Training und Evaluation, geteilt durch die monatliche Ersparnis aus eingesparten API-Kosten und eingesparter Handarbeit. Liegt das Ergebnis jenseits deines Planungshorizonts, lass das Projekt liegen. Liegt es unter einem Jahr, rechne genauer nach: Dann ist Fine-Tuning selten die überschätzte Stufe, sondern ein Investment mit klarem Rückfluss.
Wann du es lassen solltest
Radikal ehrlich, auch gegen unseren eigenen Verkauf: In vier Situationen raten wir vom Fine-Tuning ab, selbst wenn die Anfrage danach klingt.
Dein Wissen ändert sich. Preislisten, Lagerbestände, Rechtsstände: Alles, was veraltet, gehört nicht in Modellgewichte. Ein fine-getuntes Modell müsstest du bei jeder Änderung neu trainieren; ein RAG-System liest den aktuellen Stand einfach zur Laufzeit aus deiner Datenbank.
Du hast keine 50 guten Beispiele. Unterhalb der Schwelle lernt das Modell vor allem die Zufälligkeiten deiner kleinen Stichprobe. Das Ergebnis wirkt im Demo-Termin überzeugend und versagt im Betrieb an der ersten Eingabe, die anders aussieht als die Trainingsdaten.
Du kannst den Erfolg nicht messen. Ohne abgetrennte Testmenge und definierte Metrik weißt du nach dem Training nicht, ob es etwas gebracht hat. Fine-Tuning ohne Evaluation ist ein Blindflug mit Budget.
Du brauchst die Allgemeinfähigkeiten des Modells. Training auf eine enge Aufgabe kann andere Fähigkeiten verschlechtern; das Phänomen heißt Catastrophic Forgetting. LoRA mildert das Risiko, weil die Originalgewichte eingefroren bleiben, ausschließen kann es das nicht. Ein Modell, das nebenbei noch frei formulieren, übersetzen und zusammenfassen soll, tunst du besser nicht auf eine Nische.
Die Reihenfolge bleibt darum immer gleich: erst Prompting ausreizen, dann RAG, erst danach Fine-Tuning. Wie du diese Reihenfolge im Unternehmen verankerst, statt sie bei jedem Projekt neu zu diskutieren, beschreibt unser Leitfaden KI im Unternehmen einführen.
Nach dem Training: Betrieb und die Rechtsfrage
Ein fine-getuntes Open-Weight-Modell gehört dir: Du erhältst die LoRA-Gewichte als Datei und entscheidest, wo sie laufen. Zwei Wege sind üblich. Entweder ein Inferenz-Anbieter lädt deinen Adapter und rechnet pro Token ab: wenig Betriebsaufwand, dafür laufende Kosten und ein Drittanbieter in der Kette.
Oder du betreibst das Modell selbst, etwa auf einem dedizierten GPU-Server in Deutschland: Hetzners GEX131 mit 96 GB GPU-Speicher kostet nach der Preisanpassung zum 15.06.2026 1.197,30 € netto pro Monat plus 599 € Setup (Hetzner-Preisliste, Abruf 18.08.2026). Was sich ab welcher Auslastung rechnet, welche Modelle auf welche Karte passen und wo die versteckten Kosten liegen: Das rechnen wir im Schwesterartikel Was kostet es, ein LLM selbst zu hosten? im Detail vor.
Bleibt eine Frage, die uns Geschäftsführer regelmäßig stellen: «Werde ich durch Fine-Tuning rechtlich zum Modell-Anbieter?» Die unverbindlichen GPAI-Leitlinien der EU-Kommission vom 18.07.2025 nennen dazu eine indikative Größe: Wer mehr als ein Drittel des ursprünglichen Trainings-Compute in seine Modifikation steckt, gilt danach als Anbieter eines eigenen GPAI-Modells. Rechtsverbindlich ist das nicht. Technisch lässt sich nur sagen: Ein typischer LoRA-Lauf verbraucht einen winzigen Bruchteil des ursprünglichen Trainings-Compute.
Die rechtliche Einordnung deines konkreten Falls gehört trotzdem nicht in einen Technik-Artikel: Was der AI Act für dich als Auftraggeber bedeutet und welche Fristen gelten, haben wir im Beitrag EU AI Act für Software-Auftraggeber zusammengetragen.
Nächste Schritte
Fine-Tuning ist bei uns nie das erste Angebot: Zuerst prüfen wir, ob dein Problem ein Wissensproblem ist, denn dann genügt ein RAG-System auf EU-Infrastruktur. Steht am Ende doch ein Spezialmodell, bauen wir es mit LoRA auf einem Open-Weight-Modell: Training auf gemieteter GPU, Betrieb auf deinen Servern, Evaluation von Anfang an. Wie solche Modelle anschließend in automatisierte Abläufe eingebettet werden, von der Dokumentenextraktion bis zur Angebotserstellung, zeigt unsere Seite zur Prozessautomatisierung.
Wenn du wissen willst, welche Stufe der Modell-Anpassung dein Anwendungsfall wirklich braucht: Buche ein kostenloses Erstgespräch. Bring dafür zwei Dinge mit: zehn typische Beispiele deiner Aufgabe und eine Zahl, was die manuelle Bearbeitung heute kostet. Mehr braucht es für eine erste Einschätzung nicht.
In einer halben Stunde klären wir gemeinsam, ob deine Aufgabe nach Verhalten oder nach Wissen verlangt, welche Modellklasse dafür in Frage kommt und wie die Amortisationsrechnung für deinen Fall aussieht. Wir rechnen dir das Ergebnis ehrlich vor — auch wenn es lautet: lass es.
