Wann es sich lohnt, ein Modell zu fine-tunen

Fine-Tuning lohnt sich, wenn zwei Prüfungen bestanden sind und ein Grund trägt. Geprüft wird: Ist Ihr Problem Verhalten und nicht fehlendes Wissen, und kann Ihr Basismodell die Aufgabe im Prinzip schon? Fällt eine Prüfung durch, hilft Training nicht. Als Grund genügt einer von dreien: Zuverlässigkeit, Stückpreis bei Volumen, oder Eigentum.

Ein eigenes Modell klingt nach der gründlichen Lösung, und wenn Prüfungen und Grund stimmen, ist es das auch: ein kleines, schnelles Modell, das Ihre Aufgabe zuverlässiger löst als ein Standardmodell. Stimmen sie nicht, zeigt sich das erst nach Monaten, und dann war es teuer. Dieser Beitrag stellt die fünf Punkte zusammen, mit denen sich das vorher klären lässt, und benennt zu jedem, woran Sie die Antwort erkennen.

Die Grundlage sind zwölf veröffentlichte Arbeiten, elf davon begutachtet und zehn bei NeurIPS, ICLR, EMNLP oder TMLR erschienen, dazu die öffentlichen Preislisten der Anbieter. Alle Quellen wurden am 16. September 2026 einzeln abgerufen. Wo die Forschung gegen Fine-Tuning spricht, steht das hier ebenso wie das Gegenteil.

Begriffe: Baseline ist der gemessene Stand vor jeder Änderung. Testset die Menge an Fällen, an der gemessen wird. Teacher ist ein größeres Modell, das einem kleineren Antworten zum Lernen liefert. SFT (Supervised Fine-Tuning) ist Training auf vorgegebenen Musterantworten. LoRA trainiert statt aller Gewichte nur kleine Zusatzmatrizen; wie groß die sind, bestimmt der Rang, und das Ergebnis heißt Adapter. Retrieval meint, dem Modell zur Laufzeit die passenden Dokumente beizulegen, meist als RAG umgesetzt. Distillation ist das Training eines kleinen Modells auf den Antworten eines größeren. Eine Epoche ist ein vollständiger Durchgang durch alle Trainingsbeispiele.

Das Wichtigste in Kürze

• Zwei Prüfungen entscheiden, ob Training wirken kann, drei Gründe, ob es sich lohnt. Bestehen Sie die Prüfungen nicht, hilft Training nicht. Bestehen Sie sie, genügt einer der drei Gründe: Zuverlässigkeit, Stückpreis bei Volumen, oder Eigentum.

• Der stärkste Grund ist meist Zuverlässigkeit, nicht Kosten. Wo ein falsches Ergebnis teuer wird, etwa bei einer Frist oder einer Einstufung mit Haftungsfolge, trägt dieser Grund allein. Ein Volumenargument braucht es dafür nicht.

• Training ändert Verhalten, nicht Wissen. Ovadia et al. haben Fine-Tuning und Retrieval auf denselben Aufgaben verglichen. Retrieval gewann fast durchgehend, die Autoren fassen es als durchgängigen Vorsprung zusammen. Bei Llama2 drückte das Training das Ergebnis von 0,353 auf 0,219, also deutlich unter die Baseline.

• Es gibt eine Diagnose, die vorher sagt, ob Training greift. Die schwersten Fälle hundertmal lösen lassen. Löst das Modell jeden mindestens einmal, aber unzuverlässig, wirkt Training. Löst es ihn nie, wirkt es nicht.

• Prüfen Sie Prompt und Ausgabeformat, bevor Sie die GPU buchen. Bei Tam et al. fiel Claude-3-Haiku auf einer Rechenaufgabe allein durch eine Formatvorgabe von 86,51 auf 23,44 Prozent. Solche Einbrüche sehen in einer Messung wie fehlendes Können aus.

• Reinforcement Learning macht Fähigkeiten zuverlässiger, es erzeugt keine neuen. Yue et al. zeigen in einer bei NeurIPS 2025 als Oral angenommenen Arbeit, gemessen an Mathematik-, Code- und Bildreasoning-Aufgaben: Trainierte Modelle gewinnen beim ersten Versuch, das untrainierte Basismodell erreicht bei vielen Versuchen den höheren Wert. Das Basismodell ist die Obergrenze.

• Sie brauchen weniger Daten als erwartet. Zhou et al. erreichten mit 1.000 kuratierten Beispielen, dass menschliche Bewerter die Antworten in 43 Prozent der Vergleiche gegen GPT-4 als gleichwertig oder besser einstuften. OpenAI empfiehlt 50 als Startpunkt.

• Datenqualität schlägt Datenmenge messbar. Chen et al. filterten 52.000 Trainingsbeispiele auf rund 9.000 herunter und erzielten damit ein besseres Modell als mit dem vollen Satz, bei einer Trainingszeit von 14 statt 80 Minuten für die 7B-Variante.

• Es gibt drei Betriebswege, nicht zwei. Fine-Tuning über die API des Modellanbieters, ein offenes Modell selbst betreiben, oder ein offenes Modell als dedizierten Endpunkt betreiben lassen. Nur beim ersten gehören die Gewichte nicht Ihnen, nur beim zweiten haben Sie den Betrieb an der Backe.

• Offene Modelle in Europa sind deutlich billiger als Frontier-APIs. Ein Llama 3.3 mit 70 Milliarden Parametern kostet bei IONOS 0,71 US-Dollar je Million Ausgabe-Tokens, Gemini 3.8 Flash bei Google 3,75. Wer mit dem Preis argumentiert, hat hier seinen Spielraum.

• Sicherheitseigenschaften überstehen ein Training nicht automatisch. Qi et al. maßen nach einer Epoche auf dem harmlosen Alpaca-Datensatz einen Anstieg schädlicher Ausgaben von 5,5 auf 31,8 Prozent. Das gehört nach jedem Lauf neu gemessen.

Inhaltsverzeichnis

1. Zwei Prüfungen und drei Gründe

2. Prüfung 1: Fine-Tuning oder RAG? Verhalten gegen Wissen

3. Prüfung 2: Kann Ihr Basismodell die Aufgabe im Prinzip?

4. Grund 1: Zuverlässigkeit auf Ihrer Aufgabe

5. Grund 2: Volumen und Stückpreis, drei Betriebswege im Vergleich

6. Grund 3: Eigentum und Unabhängigkeit

7. Wie viele Daten Sie brauchen

8. Drei Nebenwirkungen und was man dagegen tut

9. Woran Sie ein belastbares Angebot erkennen

10. Wie wir das mit Ihnen durchgehen

11. Häufige Fragen

12. Quellen

Zwei Prüfungen und drei Gründe

Die verbreitetste Fehlvorstellung über diese Entscheidung ist, dass alles zusammenkommen muss. Das stimmt nicht. Zwei Punkte sind Prüfungen, die Sie bestehen müssen, sonst kann Training gar nicht wirken. Die übrigen drei sind Gründe, und davon muss nur einer stark genug sein.

Der Unterschied ist praktisch. Wer die beiden Prüfungen nicht besteht, sollte kein Trainingsprojekt starten, auch wenn alle drei Gründe für ihn sprechen. Wer sie besteht, braucht dagegen nicht alle drei Gründe, sondern einen, der schwer genug wiegt. Ein Krankenversicherer mit dreihundert Vorgängen am Tag hat kein Volumenargument und trotzdem ein sehr gutes Zuverlässigkeitsargument.

Prüfung 1: Fine-Tuning oder RAG? Verhalten gegen Wissen

Ein Sprachmodell erwirbt sein Wissen im Pre-Training. Was danach kommt, ändert daran wenig, dafür umso mehr daran, wie zuverlässig es das Gewusste abruft und in welcher Form es antwortet. Daraus folgt eine klare Zuordnung.

Für die erste Zeile gibt es die sauberste Messung, die zu diesem Thema vorliegt. Ovadia et al. haben Fine-Tuning und Retrieval auf denselben Aufgaben mit denselben Modellen gegeneinander antreten lassen, auf Fakten, die nach dem Pre-Training entstanden sind.

Retrieval gewinnt in allen drei Fällen deutlich, und über die weiteren Aufgaben der Arbeit hinweg fast durchgehend. Bei Llama2 hat das Training das Modell sogar unter seinen Ausgangspunkt gedrückt. Die Autoren testeten unsupervised Fine-Tuning, also weiteres Training auf Rohtext; ein Teil des Abstands geht auf dieses Verfahren zurück. Fairerweise gehört dazu, dass sie den Einbruch selbst reparieren konnten: Trainiert man auf mehreren Umformulierungen derselben Fakten, liegen alle drei Modelle wieder über ihrer Baseline. An Retrieval kommen sie damit trotzdem nicht heran.

Die Erklärung liefern Gekhman et al. in einer bei EMNLP 2024 angenommenen Arbeit. Sie zeigen zweierlei: Trainingsbeispiele, die neues Wissen einführen, lernt ein Modell deutlich langsamer als solche, die zu seinem vorhandenen Wissen passen. Und sobald es sie gelernt hat, steigt seine Neigung zu erfundenen Antworten linear an. Das Modell lernt nicht nur die Fakten, es lernt auch, selbstbewusst zu antworten, wenn es etwas nicht weiß.

Die Frage „Fine-Tuning oder RAG“ ist deshalb falsch gestellt. Faktenwissen gehört ins Retrieval, weil es sich dort aktualisieren lässt, ohne neu zu trainieren. Regeln, Format und Taxonomie gehören ins Modell, weil sie dort bei jeder Anfrage ohne Kontextkosten zur Verfügung stehen. Ein Projekt, das beides sauber trennt, wird billiger und besser als eines, das alles in einen Topf wirft.

Der Zwischenschritt, den fast alle überspringen

Bevor Sie Zeile drei oder vier für sich beanspruchen, prüfen Sie Zeile zwei zu Ende. Formatprobleme sehen in einer Messung genauso aus wie fehlendes Können, und sie sind um Größenordnungen billiger zu beheben.

Wie groß dieser Effekt wird, haben Tam et al. in einer bei EMNLP 2024 im Industry Track angenommenen Arbeit systematisch vermessen. Dieselben Modelle, dieselben Aufgaben, einmal in freiem Text und einmal mit erzwungenem JSON-Schema:

63 Prozentpunkte Einbruch bei Claude-3-Haiku, ohne dass sich an der Aufgabe irgendetwas geändert hätte. Wer in dieser Lage misst und den Wert für fehlende Fähigkeit hält, beauftragt ein Trainingsprojekt gegen ein Problem, das ein Nachmittag gelöst hätte.

Der Effekt geht auch in die andere Richtung: Bei einer Klassifikationsaufgabe stieg Gemini-1.5-Flash durch dieselbe Formatvorgabe von 41,6 auf 60,3 Prozent, weil sie den Antwortraum einschränkt. Und die Autoren konnten den Mechanismus benennen. Bei GPT-3.5-Turbo platzierten auf einer der Aufgaben im JSON-Modus 100 Prozent der Antworten den Schlüssel answer vor dem Schlüssel reason. Das Modell antwortet dann zuerst und begründet danach, die Begründung kann das Ergebnis nicht mehr beeinflussen.

Die Reihenfolge der Felder in Ihrem Schema ist damit ein Hebel, der nichts kostet. Die Messungen stammen aus 2024, die Anbieter haben ihre Verfahren zur formatgebundenen Ausgabe seither verbessert. Der Mechanismus ist aber struktureller Natur und gilt weiter.

Prüfung 2: Kann Ihr Basismodell die Aufgabe im Prinzip?

Das ist die Frage, bei der die meisten Projekte raten und bei der es nicht nötig ist. Es gibt eine Messung, die sie beantwortet, und sie dauert Stunden.

Das Verfahren heißt pass@k. Das k steht für die Zahl der Versuche, die Sie dem Modell zugestehen.

Für die Diagnose drehen Sie die Temperatur hoch, also den Parameter, der steuert, wie stark das Modell vom wahrscheinlichsten Wort abweichen darf. Dann kommt bei jedem Anlauf eine etwas andere Antwort heraus. Das ist der ganze Trick: Sie wollen nicht wissen, was das Modell diesmal sagt, sondern was es überhaupt sagen kann, wenn es oft genug darf.

Nehmen Sie also Ihre schwersten Fälle, etwa zwanzig Stück, und lassen Sie jeden hundertmal lösen. Das ergibt 2.000 Antworten. Daraus lesen Sie zwei Zahlen ab, und die beiden zählen bewusst Verschiedenes.

pass@1 zählt Antworten. Von allen 2.000 Antworten: Wie viele waren richtig? Das ist die Trefferquote eines einzelnen Anlaufs unter Messbedingungen. Im Betrieb fahren Sie niedrigere Temperatur und liegen dort meist etwas höher; die Messung ist also die vorsichtige Seite.

pass@100 zählt Fälle. Von Ihren zwanzig Fällen: Bei wie vielen war unter den hundert Anläufen mindestens einer richtig? Das ist die Obergrenze dessen, was im Modell steckt.

Ein Rechenbeispiel. Ein Fall wird in 11 von 100 Anläufen richtig gelöst, ein anderer in 83 von 100. Für pass@1 zählen die 11 und die 83 einzeln: 94 richtige Antworten aus 200 Versuchen, also 47 Prozent. Für pass@100 zählt nur, dass bei beiden mindestens ein Treffer dabei war, also zählen beide Fälle voll: 100 Prozent. Der Abstand zwischen 47 und 100 ist genau die Spanne, die Training schließen kann. Deshalb liegt pass@100 nie unter pass@1.

Damit trennen die beiden Zahlen die einzige Frage, auf die es hier ankommt: Kann das Modell es nicht, oder kann es das und trifft nur nicht zuverlässig? Im ersten Fall fehlt Fähigkeit, und die kann Training nicht herstellen. Im zweiten Fall fehlt Konsistenz, und genau die bringt Training.

Dass diese Lesart trägt, ist gut belegt. Yue et al. haben in einer bei NeurIPS 2025 als Oral angenommenen Arbeit gezeigt, dass trainierte Modelle ihr Basismodell bei einem Versuch schlagen, das Basismodell aber bei vielen Versuchen den höheren pass@k-Wert erreicht. Ihre Schlussfolgerung: Die Fähigkeiten stammen aus dem Basismodell und sind durch es begrenzt. Sechs verbreitete Verfahren des Reinforcement Learning verhielten sich darin gleich. Distillation von einem stärkeren Teacher konnte dagegen neue Muster einbringen und die Fähigkeiten tatsächlich erweitern. Wer also an die Decke seines Basismodells stößt, hat damit einen zweiten Hebel und nicht das Ende der Fahnenstange.

Brown et al. zeigen dieselbe Struktur von der anderen Seite, und ihr Ergebnis ist ein Erfolg, kein Warnschild. Ein Modell ohne aufgabenspezifisches Training, DeepSeek-Coder-V2-Instruct, löste auf dem Benchmark SWE-bench Lite bei einem Versuch 15,9 Prozent der Fälle, bei 250 Versuchen 56 Prozent. Damit übertraf es den damaligen Bestwert von 43 Prozent für einen einzelnen Versuch deutlich. Die Fähigkeit war also längst vorhanden, es fehlte nur der Zugriff darauf, und genau diesen Zugriff stellt Training her.

Ihr Vorbehalt ist praktisch wichtig: Das nützt nur, wenn ein automatischer Prüfer die richtige Antwort unter den 250 erkennt. Wenn Sie einen solchen Prüfer bauen können, lösen mehrere Versuche plus Prüfer Ihr Problem unter Umständen billiger als ein trainiertes Modell. Das ist eine Option, die in kaum einem Angebot vorkommt.

Grund 1: Zuverlässigkeit auf Ihrer Aufgabe

Das ist der Grund, der in Kostenvergleichen regelmäßig untergeht, und für viele Anwendungen der einzige, der wirklich zählt. Training macht aus einem Modell, das Ihre Aufgabe manchmal löst, eines, das sie zuverlässig löst.

Wie groß dieser Gewinn bei Ihnen ausfällt, haben Sie in Prüfung 2 bereits gemessen. Dieser Abstand ist die Spanne, um die Training die Zuverlässigkeit heben kann. Ein Modell, das die schwersten Fälle in 47 von 100 Anläufen richtig löst und in 100 von 100 mindestens einmal, kann die Aufgabe vollständig. Es ruft sie nur unzuverlässig ab, und genau daran arbeitet das Training.

Entscheidend ist die Frage, die in keiner Kostenrechnung steht: Was kostet Sie ein falsches Ergebnis? Bei einer internen Suchfunktion ist eine Fehlerquote von zehn Prozent ein Ärgernis. Bei einer Vorgangsklassifizierung, an der eine Frist hängt, ist sie ein Haftungsfall. Wo ein Fehler teuer ist, rechtfertigt der Qualitätsgewinn ein Training auch dann, wenn der Stückpreis über dem einer API liegt. Dieser Grund steht völlig unabhängig vom Volumen.

Zwei Größenordnungen aus der Forschung, was dabei erreichbar ist. Zhou et al. brachten ein Modell mit 1.000 kuratierten Beispielen so weit, dass menschliche Bewerter seine Antworten in 65 Prozent der Vergleiche gegen DaVinci-003 als gleichwertig oder besser einstuften. Chen et al. erreichten mit 9.000 gefilterten Beispielen über 90 Prozent der Leistung ihres Teacher-Modells. Beides sind keine Jahresprojekte.

Die Einschränkung gehört dazu, und sie ist dieselbe wie in Prüfung 2: Über die Decke des Basismodells kommt Training nicht hinaus, es hebt den Boden. Wenn Ihnen der Boden fehlt, ist das der richtige Hebel. Wenn Ihnen die Decke fehlt, brauchen Sie ein stärkeres Basismodell oder Distillation von einem größeren Teacher.

Grund 2: Volumen und Stückpreis, drei Betriebswege im Vergleich

Diese Frage lässt sich am Schreibtisch beantworten und beendet mehr Projekte als jede andere. Es gibt drei Wege, ein fine-getuntes Modell zu betreiben, und sie unterscheiden sich weniger in der Qualität als in der Frage, wer die Arbeit hat und wem am Ende etwas gehört.

Weg 3 wird in Vergleichen regelmäßig vergessen, obwohl er die Nachteile der beiden anderen auflöst. Sie bekommen ein Modell, dessen Gewichte Ihnen gehören, ohne selbst einen Serving-Stack zu betreiben, Karten zu überwachen oder bei Lastspitzen nachts aufzustehen. Bezahlt wird Kapazität, nicht Verbrauch, und genau deshalb verhält sich die Rechnung anders als bei Weg 1.

Jeder der drei Wege hat einen Posten, der in Angeboten selten auftaucht. Der Reihe nach.

Weg eins, Fine-Tuning bei einem API-Anbieter. Dieser Weg verliert gerade an Boden. OpenAI fährt die eigene Fine-Tuning-Plattform herunter: Neue Nutzer bekommen laut Preisseite keinen Zugang mehr, bestehende können noch für einige Monate Trainingsläufe starten, und bereits trainierte Modelle bleiben nur so lange abrufbar, wie ihr Basismodell existiert.

Und OpenAI ist nicht allein. Auch Mistral hat Fine-Tuning abgekündigt: Die Dokumentation trägt den Hinweis „deprecated and no longer actively supported“ und liegt inzwischen im Archivbereich. Technisch laufen die Jobs noch, ein Abschaltdatum ist nicht veröffentlicht.

Bei Google und über AWS Bedrock gibt es den Weg uneingeschränkt weiter, und dort lassen sich Trainingsläufe auch vorab durchrechnen: Beide weisen auf ihren Cloud-Preisseiten Trainingspreise aus, je nach Modell als Preis je tausend Tokens oder je Trainingsstunde. Prüfen Sie das für Ihr Wunschmodell, die Angaben unterscheiden sich innerhalb desselben Anbieters erheblich, und für einen Teil der Modelle fehlen sie.

Was bei allen Anbietern gleich bleibt: Das Ergebnis ist ein Nutzungsrecht auf einer fremden Plattform, und was mit dieser Plattform geschieht, entscheidet ein anderer. Zwei Abkündigungen innerhalb eines Jahres führen genau das vor.

Weg zwei, ein offenes Modell selbst betreiben. Hier fällt der Tokenpreis weg und wird durch einen Stundenpreis ersetzt. Beispiele aus veröffentlichten europäischen Preislisten, abgerufen am 16. September 2026, jeweils netto und in der Währung, in der der Anbieter sie ausweist:

Zur Einordnung noch eine dritte Zahlenreihe, die weder Weg 2 noch Weg 3 ist, aber die Untergrenze Ihrer Rechnung markiert: Was ein offenes Modell ohne eigenes Training bei einem europäischen Anbieter über eine geteilte API kostet. Beim IONOS AI Model Hub sind das für ein 9B-Modell 0,11 US-Dollar je Million Eingabe-Tokens und 0,17 für die Ausgabe. Ein Llama 3.3 mit 70 Milliarden Parametern kostet dort 0,71, und zwar für beide Richtungen gleich.

Die 0,71 lohnen einen Moment. Gemini 3.8 Flash kostet laut Google-Preisliste 3,75 US-Dollar je Million Ausgabe-Tokens, also gut das Fünffache. Das ist ein befristeter Einführungspreis; dieselbe Seite nennt ab dem 1. Januar 2027 den doppelten Wert. Der Abstand liegt dabei auf der Ausgabeseite: Bei den Eingabe-Tokens nehmen sich beide mit 0,75 gegen 0,71 nichts. Der Vergleich ist bewusst schief, denn das Llama ist nicht auf Ihre Aufgabe trainiert und läuft auf geteilter Infrastruktur. Genau deshalb ist er nützlich: Er zeigt, wie viel Spielraum zwischen dem Preisniveau offener Modelle in Europa und einer Frontier-API liegt. Wer mit dem Preis argumentiert, muss diesen Spielraum mit Qualität füllen. Wer mit Zuverlässigkeit oder Eigentum argumentiert, braucht das nicht.

Wenn Sie selbst hosten, entscheidet die Auslastung, und zwar vollständig. Die Rechnung dazu können Sie ohne fremde Hilfe aufstellen: Stundenpreis geteilt durch die Zahl der Dokumente, die Ihre Karte in einer Stunde schafft. Diese zweite Zahl müssen Sie messen, sie hängt an Modellgröße, Antwortlänge und Batchgröße. Was dabei regelmäßig übersehen wird: Ohne Batching, also ohne dass mehrere Anfragen gleichzeitig durch die Karte laufen, liegt der Durchsatz deutlich niedriger. Eine GPU, die auf Anfragen wartet, kostet dasselbe wie eine, die arbeitet.

Daraus folgt die eigentliche Faustregel: Nicht die Modellgröße entscheidet über die Wirtschaftlichkeit, sondern ob Ihre Last planbar genug ist, um die Karte durchgehend zu beschäftigen. Bei ein paar hundert Dokumenten am Tag ist eine geteilte API richtig, bei der Sie nur den Verbrauch zahlen. Bei ein paar hundert in der Minute nicht mehr.

Weg drei, derselbe Stundenpreis ohne den Betrieb. Ein dedizierter Endpunkt folgt derselben Rechnung wie Weg zwei, denn auch dort zahlen Sie Kapazität. Was wegfällt, ist der Posten, den kaum ein Projektplan enthält: Serving-Stack aufsetzen und aktuell halten, Auslastung überwachen, Skalierung, Bereitschaft. Was hinzukommt, ist die Marge des Dienstleisters. Ob sich das lohnt, ist eine Rechnung über Personentage, nicht über Tokens, und sie fällt umso klarer aus, je kleiner Ihr Plattformteam ist. Eine belastbare Schwelle dafür gibt es nicht, das hängt an Ihrer Mannschaft.

Worauf Sie dabei achten sollten: Ein dedizierter Endpunkt ist nur dann Weg drei und nicht verkapptes Weg eins, wenn die Gewichte Ihnen gehören und Sie sie jederzeit exportieren können. Fragen Sie das ausdrücklich ab, bevor Sie unterschreiben.

Grund 3: Eigentum und Unabhängigkeit

Dieser Grund ist keine Messung, sondern eine Entscheidung, und er wird häufig zu spät gestellt. Bei einem Fine-Tuning über eine fremde API entsteht ein Modell, das Sie nutzen, aber nicht herunterladen können. Bei einem offenen Basismodell entsteht eine Datei.

Für regulierte Branchen klärt die dritte Zeile die Entscheidung oft, bevor die Kostenrechnung überhaupt beginnt. Für Berufsgeheimnisträger ist eine dedizierte Inferenz strukturell einfacher zu begründen als eine Kette aus Anbietern, weil es nichts zu verpflichten gibt, wo niemand ist. Wer OpenAI, Claude oder Gemini aus Europa heraus nutzt, findet die Einordnung der Bezugswege in unserem Beitrag zu OpenAI, Claude und Gemini in Europa.

Eine Randnotiz mit Kostenfolge: Mistral weist auf der eigenen Preisseite einen Aufschlag von 10 Prozent für regionale Inferenz aus. Souveränität hat also einen Preis, er ist nur meist kleiner, als er in der Diskussion wirkt.

Ehrlicherweise gehört dazu: Für viele Anwendungen ist die Antwort auf diese Frage nein, und dann ist eine API die richtige Lösung, dauerhaft und nicht übergangsweise.

Wie viele Daten Sie brauchen

Kaum eine Annahme über Fine-Tuning hält sich so hartnäckig wie die, dass es zehntausende Beispiele braucht. Die Forschung sagt das Gegenteil, und zwar mehrfach unabhängig.

Die Arbeit von Chen et al. ist der sauberste Beleg für „Qualität vor Menge“, weil dieselbe Datenquelle einmal mit und einmal ohne Filter verwendet wurde. Geurteilt hat dabei überwiegend ein Sprachmodell, abgesichert durch eine kleine Nutzerstudie und vier Benchmarks. Der Bewertungsprompt weist den Richter ausdrücklich an, die Antwortlänge nicht zu berücksichtigen.

Bemerkenswert ist der Rat, den OpenAI für den Fall gibt, dass 50 Beispiele nichts bewirken: Dann solle man die Aufgabenformulierung oder den Prompt überdenken, statt mehr Daten zu sammeln. Die Empfehlung gilt unabhängig davon, auf welcher Plattform Sie am Ende trainieren. Das ist Prüfung 1 in anderen Worten, formuliert von einem Anbieter, der am Verkauf von Trainingsläufen verdient.

Der eigentliche Aufwand liegt also nicht in der Menge, sondern darin, dass die Zielantworten stimmen. Wer sie nicht selbst schreiben will, kann ein größeres Modell als Teacher einsetzen. Welches Modell dafür vertraglich zulässig ist, ist eine eigene Frage: Anthropic, OpenAI und Google untersagen in ihren Bedingungen das Training konkurrierender Modelle auf den Ausgaben ihrer kommerziellen Modelle. Für Googles offene Gemma-Gewichte gilt das ausdrücklich nicht, Gemma 4 steht unter Apache 2.0. Welche Klausel wo steht, haben wir im Beitrag zu den Distillations-Klauseln der Anbieter zusammengetragen. Wer echte Geschäftsdaten als Trainingsmaterial verwendet, klärt außerdem vorher, warum automatisches Schwärzen personenbezogener Daten allein nicht genügt.

Drei Nebenwirkungen und was man dagegen tut

Ein Training hat Nebenwirkungen. Alle drei sind gut untersucht, alle drei sind behandelbar, und keine davon ist ein Grund, es zu lassen. Sie sind ein Grund, es nicht nebenbei zu machen. Deshalb stehen sie hier mit der jeweiligen Gegenmaßnahme.

Erstens: Sicherheitseigenschaften werden nicht mitvererbt. Wer ein Modell mit Safety-Alignment fine-tunt, bekommt dieses Alignment nicht automatisch mit. Qi et al. haben das in einer bei ICLR 2024 angenommenen Arbeit beziffert, und zwar für gewöhnliche, harmlose Trainingsdatensätze nach einer einzigen Epoche:

Gegenmaßnahme: Die Sicherheitsprüfung gehört in den Eval-Lauf nach dem Training, genauso wie die Fachprüfung. Das ist ein zusätzlicher Prüfschritt, kein Projektrisiko. Zur Einordnung der Zahlen: Sie stammen aus Modellgenerationen von 2023, und bewertet hat ein Modell gegen eine eigene Taxonomie. Die Größenordnung ist trotzdem zu deutlich, um sie mit Messrauschen zu erklären.

Zweitens: Ein Modell kann verlieren, was es vorher konnte. Das ist unter dem Namen Catastrophic Forgetting untersucht. Luo et al. fanden es im Bereich von 1 bis 7 Milliarden Parametern durchgehend, mit dem kontraintuitiven Zusatz, dass es dort mit der Modellgröße zunimmt.

Gegenmaßnahme: die Wahl des Verfahrens. Biderman et al. beziffern in einer bei TMLR erschienenen Arbeit, wie viel das ausmacht: Nach Instruction-Tuning auf Code lagen die allgemeinen Fähigkeiten bei 0,510 mit LoRA gegenüber 0,414 mit vollständigem Fine-Tuning, gemessen bei Rang 64 nach 16 Epochen. Die Werte sind Trefferanteile auf allgemeinen Benchmarks, der Abstand entspricht also rund zehn Prozentpunkten. Wer LoRA nimmt, hat einen guten Teil des Problems bereits gelöst, bevor es auftritt.

Drittens: LoRA hat selbst eine Grenze, und sie liegt bei der Datenmenge. Dieselbe Arbeit zeigt, wo. Bei echtem Domänentraining über 20 Milliarden Tokens lag LoRA auf einer Mathematikaufgabe bei 0,202 gegen 0,293 für vollständiges Fine-Tuning, auf einer Programmieraufgabe bei 0,224 gegen 0,263. Bei Instruction-Tuning auf rund hunderttausend Beispielen schloss LoRA mit hohem Rang (256) dagegen auf, mit niedrigem Rang nicht.

Gegenmaßnahme: Verfahren und Rang zur Datenmenge passend wählen. Für aufgabenspezifisches Training in üblicher Größenordnung ist LoRA die richtige Wahl; eine ganze Fachdomäne über Milliarden Tokens einzubringen ist etwas anderes und braucht etwas anderes.

Ein Detail für den Fall, dass Sie laufend nachtrainieren wollen: Shuttleworth et al. zeigen, dass LoRA vor allem bei niedrigem Rang Strukturen in den Gewichten erzeugt, die vollständiges Fine-Tuning nicht erzeugt, und dass diese sich über mehrere aufeinander aufbauende Läufe anhäufen. Bei hohem Rang verschwindet der Effekt weitgehend. Weniger Vergessen bei einem einzelnen Lauf, möglicherweise mehr bei wiederholten Zyklen. Das widerspricht Biderman nicht, es ergänzt ihn, und es ist ein Argument dafür, die Eval-Ergebnisse über die Läufe hinweg zu verfolgen statt nur je Lauf.

Zusammengefasst: dreimal eine Entscheidung im Aufbau, nicht dreimal ein Grund zur Vorsicht. Sicherheit nach jedem Lauf mitmessen, LoRA statt vollständigem Fine-Tuning wählen, und Rang und Verfahren zur Datenmenge passen lassen. Das ist Handwerk.

Woran Sie ein belastbares Angebot erkennen

Angenommen, die Prüfungen sind bestanden, ein Grund trägt, und Sie holen Angebote ein. Zahlen zu Modellqualität sind billig, fast jede Vorführung zeigt eine Verbesserung, und viele davon erzeugt das Messverfahren. Diese Prüfliste hilft beim Auseinanderhalten. Halten Sie sie an jeden Anbieter, uns eingeschlossen.

Wie wir das mit Ihnen durchgehen

Die beiden Prüfungen sind so beschrieben, dass Ihr Team sie selbst durchführen kann. Die meisten Teams scheitern auch nicht am Verfahren, sondern daran, ein Testset zu bauen, dem sie hinterher glauben.

Wenn Sie es nicht selbst machen wollen, machen wir genau das: Testset aus Ihren echten Fällen, mit Ihren Fachexperten als Grader, Baseline gegen ein starkes Modell mit fairem Prompt, pass@k auf Ihren härtesten Fällen. Danach wissen Sie, ob sich ein Trainingsprojekt lohnt, und haben ein Testset, das Sie ohnehin brauchen, egal wie die Entscheidung ausfällt.

In der Systematik von Grund 2 sind wir Weg drei: Wir trainieren ein offenes Modell auf Ihre Aufgabe und betreiben es als dedizierten Endpunkt, hinter einer OpenAI-kompatiblen API. Sie bekommen kein Nutzungsrecht, sondern das Modell.

Drei Zusagen, die den Unterschied machen: Trainiert und betrieben wird auf dedizierten GPUs in der EU, ohne US-Hyperscaler in der Kette. Weights, Eval-Set und Dokumentation gehören Ihnen, mit Export jederzeit. Und kein Modell geht ohne Eval-Gate in den Betrieb, jeder Rollout als A/B-Test mit Rollback. Der AVV steht vor dem ersten Datensatz. Alles Weitere, von der OpenAI-kompatiblen API bis zum Audit-Log, können Sie in der Prüfliste oben abfragen.

Der erste Schritt ist ein Gespräch über Ihre Aufgabe: 30 Minuten, Engineering ist dabei, kein Pitch. Wenn dabei herauskommt, dass ein Prompt oder ein Retrieval-System Ihr Problem löst und kein Training, sagen wir das im Gespräch. Termin vereinbaren.

Häufige Fragen

Was ist der Unterschied zwischen Fine-Tuning und RAG?

Fine-Tuning ändert die Gewichte und damit Verhalten, Format und Konsistenz. RAG lässt das Modell unverändert und stellt ihm zur Laufzeit die passenden Dokumente bei. Als Faustregel: Was sich ändern kann, gehört ins Retrieval. Was immer gleich bleiben soll, gehört ins Modell.

Woran erkenne ich, dass Fine-Tuning nicht helfen wird?

An zwei Signalen. Erstens, wenn die fehlende Information nie im Pre-Training war, etwa Ihre Produktdaten oder Vertragsinhalte. Zweitens, wenn das Basismodell die schwersten Fälle auch in hundert Versuchen nie löst. Dann fehlt Fähigkeit. Yue et al. zeigen für Reinforcement Learning, dass es keine neue erzeugt, sondern vorhandene nur zuverlässiger abruft.

Wie schnell weiß ich, ob es bei uns funktioniert?

Die Diagnose aus pass@1 und pass@100 braucht Stunden und kostet wenige Euro an Modellaufrufen. Vorgelagert ist nur der Aufbau eines Testsets aus Ihren echten Fällen, und das brauchen Sie ohnehin, egal wie die Entscheidung ausfällt.

Wie viele Beispiele brauchen wir?

Weniger, als meist angenommen. OpenAI nennt 50 sorgfältig erstellte als Startpunkt, Zhou et al. erreichten mit 1.000 kuratierten Beispielen Ergebnisse, die menschliche Bewerter in 43 Prozent der Vergleiche gegen GPT-4 als gleichwertig oder besser einstuften. Entscheidend ist, dass die Zielantworten stimmen.

Reicht LoRA oder brauchen wir vollständiges Fine-Tuning?

Für aufgabenspezifisches Training spricht viel für LoRA, vor allem der geringere Verlust an allgemeinen Fähigkeiten. Eine Einschränkung: Biderman et al. haben kleine Datensätze nicht gemessen, ihr kleinster Fall sind rund hunderttausend Beispiele, und dort zog LoRA nur bei hohem Rang gleich.

Was bringt Fine-Tuning im besten Fall?

Ein kleines, spezialisiertes Modell, das Ihre Aufgabe so zuverlässig löst wie ein deutlich größeres und dabei Ihnen gehört. Zhou et al. erreichten mit 1.000 kuratierten Beispielen, dass menschliche Bewerter die Antworten in 65 Prozent der Vergleiche gegen DaVinci-003 als gleichwertig oder besser einstuften. Chen et al. kamen mit 9.000 gefilterten Beispielen auf über 90 Prozent der Leistung des Teacher-Modells.

Ab welchem Volumen rechnet sich eigene Hardware?

Das hängt an der Auslastung, nicht am Modell. Ein Stundenpreis läuft weiter, ob die Karte arbeitet oder wartet. Rechnen Sie Stundenpreis geteilt durch Dokumente je Stunde und vergleichen Sie mit dem Tokenpreis Ihres Anbieters. Ohne Batching liegt der Durchsatz deutlich niedriger, messen Sie ihn deshalb im gebatchten Betrieb.

Können wir das Modell hinterher selbst betreiben?

Bei offenen Basismodellen mit geeigneter Lizenz ja. Das Ergebnis eines LoRA-Laufs ist ein Adapter, der um Größenordnungen kleiner ist als das Basismodell, plus Protokoll, Eval-Ergebnissen und Modellkarte. Bei einem Fine-Tuning über eine fremde API bekommen Sie stattdessen ein Nutzungsrecht auf deren Plattform.

Quellen

• Ovadia et al., „Fine-Tuning or Retrieval? Comparing Knowledge Injection in LLMs“ (EMNLP 2024): kontrollierter Vergleich bei Faktenwissen

• Gekhman et al., „Does Fine-Tuning LLMs on New Knowledge Encourage Hallucinations?“ (EMNLP 2024): warum Faktenwissen ins Retrieval gehört

• Tam et al., „Let Me Speak Freely? A Study on the Impact of Format Restrictions“ (EMNLP 2024 Industry Track): Formatvorgaben und Feldreihenfolge

• Yue et al., „Does Reinforcement Learning Really Incentivize Reasoning Capacity in LLMs Beyond the Base Model?“ (NeurIPS 2025, Oral): pass@k und die Obergrenze des Basismodells

• Brown et al., „Large Language Monkeys: Scaling Inference Compute with Repeated Sampling“ (arXiv:2407.21787): latente Fähigkeit gegen Zuverlässigkeit

• Zhou et al., „LIMA: Less Is More for Alignment“ (NeurIPS 2023): 1.000 kuratierte Beispiele als Referenzpunkt

• Chen et al., „AlpaGasus: Training A Better Alpaca with Fewer Data“ (ICLR 2024): Datenqualität gegen Datenmenge

• Qi et al., „Fine-tuning Aligned Language Models Compromises Safety, Even When Users Do Not Intend To!“ (ICLR 2024, Oral): Safety-Degradation durch harmloses Training

• Hu et al., „LoRA: Low-Rank Adaptation of Large Language Models“ (ICLR 2022): das Verfahren hinter dem Adapter

• Biderman et al., „LoRA Learns Less and Forgets Less“ (TMLR): LoRA gegen vollständiges Fine-Tuning

• Shuttleworth et al., „LoRA vs Full Fine-tuning: An Illusion of Equivalence“ (NeurIPS 2025): Gegenbefund zum Vergessen bei wiederholtem Training

• Luo et al., „An Empirical Study of Catastrophic Forgetting in Large Language Models During Continual Fine-tuning“ (IEEE/ACM TASLP 33, 2025): Vergessen im Bereich 1 bis 7 Milliarden Parameter

• OpenAI, Supervised Fine-Tuning Guide und API Pricing: Mindestbeispielzahlen und der Hinweis zur Abkündigung der Fine-Tuning-Plattform

• Scaleway GPU-Preise, OVHcloud Public-Cloud-Preise, IONOS Cloud-Preise und Mistral API-Preise und Mistral Fine-Tuning-Dokumentation (dort der Abkündigungshinweis), Gemini API-Preise, Google Cloud, Preise für Model Tuning und AWS Bedrock-Preise: Vergleichswerte und Trainingspreise

• The Evals Guide: Aufbau von Testsets, Scorer und statistischer Auswertung

Stand: 16. September 2026 · kontinent.ai. Alle Prozentwerte stammen aus den genannten Veröffentlichungen und gelten für die dort getesteten Modelle und Aufgaben, überwiegend aus den Jahren 2023 bis 2025. Preisangaben wurden am 16. September 2026 auf den Seiten der Anbieter abgerufen und ändern sich. Kein Rechtsrat.