Durch das Tal der Tränen: Wie LLMs auf Deutsch denken lernen

TL;DR

Reasoning-Modelle denken nach, bevor sie antworten. Selbst wenn man sie auf Deutsch fragt, denken sie meist auf Englisch. Wir wollten ein Modell, das auf Deutsch denkt, fanden aber keine brauchbaren Daten, um es zu trainieren. Deshalb haben wir rund 800.000 deutsche SFT-Trainingsbeispiele (Supervised Fine-Tuning) erzeugt, indem wir dem Reasoning eines Generator-Modells deutsche Satzanfänge vorgegeben haben. Schon mit wenig dieser Daten denkt ein Mixture-of-Experts-Modell mit 3 Milliarden aktiven Parametern auf Deutsch und beantwortet deutsche Matheaufgaben zuverlässig auf Deutsch. Die englische Leistung bleibt dabei unverändert. Die Genauigkeit auf deutschen Benchmarks wird jedoch zuerst schlechter. Insbesondere bei geringem deutschen Anteil gerät das Modell oft in Gedankenschleifen und gibt gar keine Antwort. Dadurch fallen die Werte auf deutschen Benchmarks unter die rein englische Baseline. Auf dem deutschen AIME'26 fällt der Score schon bei wenigen Prozent deutscher Daten von 70,2 auf 48,3. Bei höheren Anteilen wird der Verlust größtenteils wieder aufgeholt, bis auf 67,3 im stärksten Mathe-Upsampling. Was augenscheinlich hilft, sind deutsche Daten aus der Domäne des Benchmarks, nicht deutsche Daten im Allgemeinen. Unsere Methode löst das Sprachkonsistenz-Problem, verhindert aber noch nicht zuverlässig, dass das Reasoning in Endlosschleifen versinkt.

Warum die Sprache des Reasonings zählt

„Reasoning“ oder „Denken“ ist bei Sprachmodellen nichts Mystisches. Bevor sie antworten, schreiben moderne Modelle das Problem auf, probieren Lösungsideen aus oder suchen sich relevanten Kontext. Das nennt man auch „Chain of Thought“. Je mehr Aufwand ein Modell hier investiert, desto besser fällt seine Antwort meist aus. Deshalb hat Reasoning in Feldern wie der Mathematik zu Durchbrüchen geführt. Jetzt, da Sprachmodelle immer komplexere Aufgaben übernehmen, wird ihr Reasoning mehr und mehr Teil des Produkts statt ausschließlich ein Implementierungsdetail. Wenn man ein Modell etwas fragt, will man verstehen, wie es zu seiner Antwort gekommen ist – und das in der eigenen Sprache. Prinzipiell gilt dies zwar für jede Sprache, doch wir konzentrieren uns in dieser Arbeit auf Deutsch, die Erstsprache vieler unserer Nutzer. Die meisten Modelle können solide auf Deutsch antworten. Wir wollen jedoch ein Modell, das auch auf Deutsch denkt, sodass ein deutscher Nutzer dem Gedanken folgen kann.

Die deutsche Lücke

Seit LLMs die Weltbühne betreten haben, ist Englisch die Sprache der KI. Das ist zum Teil unvermeidlich: Englisch ist Weltsprache, und jedes seriöse Modell muss es exzellent beherrschen. Erschwerend kommt hinzu, dass sich der Effekt selbst verstärkt. Das Web ist mehrheitlich englisch, ebenso die am besten kuratierten und frei verfügbaren Datensätze für das Post-Training. Jedes Modell, das auf breiten Webinhalten trainiert wird, lernt deshalb, standardmäßig auf Englisch zu denken. Schlimmer noch: Die Problemlösefähigkeit eines Modells hängt an der Sprache, in der es sie gelernt hat. Modelle, die lange Chains of Thought auf Englisch gelernt haben, verlieren an Genauigkeit, sobald sie in einer anderen Sprache denken (Barua et al., 2025). Viele Nutzer haben sich daran gewöhnt, die Autoren eingeschlossen: Wer das Beste aus einem Modell herausholen will, wechselt ins Englische.

Das ist die Abwägung, die wir in diesem Beitrag untersuchen. Rein nach Leistung ist die Sache eindeutig: Reasoning-Modelle schneiden besser ab, wenn sie auf Englisch denken statt in der Sprache des Prompts. Das ist selbst bei ressourcenreichen Sprachen wie Französisch und Chinesisch so (Barua et al., 2025). Lässt man ihnen freie Hand, driftet ihr Reasoning ins Englische oder in Sprachmischungen wie Englisch-Chinesisch ab (Wang et al., 2025). Doch wenn ein Nutzer einen Reasoning-Trace nicht versteht, bringt es wenig, ihn anzuzeigen. DeepSeek hat einen kleinen Genauigkeitsverlust akzeptiert, um Sprachkonsistenz durchzusetzen (DeepSeek-AI, 2025). Wir bei Aleph Alpha wollen ein Modell, das auf Deutsch denkt, wenn es auf Deutsch angesprochen wird. Und wir wollen wissen, was diese Fähigkeit an Modellkompetenz kostet. Dafür braucht es Daten.

Im Pre-Training war die deutsche Lücke eine Frage der Menge. Wir haben sie mit einer deutschen Common-Crawl-Pipeline, offenen Datensätzen und dem Umformulieren bestehender deutscher Texte geschlossen. So kamen mehr als 2 Billionen deutsche Token zusammen, die es frei verfügbar nicht gibt (Hartel & Dürr, 2026). Das hat funktioniert, weil Deutsch auf der Ebene des Rohtexts eine recht ressourcenreiche Sprache ist; Kuration und synthetische Generierung können die Qualität deshalb heben (Burns et al., 2025).

Im Post-Training reicht Nachschärfen nicht. Nativ deutsche Daten für Instruktionsbefolgung und Reasoning sind rar, für Mathematik, Code und agentische Aufgaben gibt es keine. Existierende Daten sind entweder ein Rundungsfehler in mehrheitlich englischen Datensätzen oder ursprünglich englische Daten, die in 200 Sprachen übersetzt wurden. Letzteres gilt als die übliche „Lösung“ für die Sprachlücke. Allerdings führt das Training auf übersetzten Daten unausweichlich zu deutschen Assistenten mit amerikanischem Weltbild und englischen Gesprächsgewohnheiten. Wir haben existierende Datensätze und Ansätze ausprobiert, aber nicht messen können, dass sie die Modellqualität erhöhen. Also haben wir selbst deutsche SFT-Daten mit deutschen Reasoning-Traces gebaut und Modelle darauf trainiert.

Reasoning Cold-Start

Reasoning-Modelle entstehen durch Reinforcement Learning (RL), aber sie beginnen selten damit. Reines RL von einem Basismodell aus erzeugt Reasoning, das oft schwer lesbar ist und mitten im Gedanken die Sprache wechselt (DeepSeek-AI, 2025). DeepSeek-R1 hat dafür vor dem RL eine Cold-Start-Phase eingeführt. Im Cold Start wird das Modell mit einer kleinen, kuratierten Menge langer Reasoning-Traces trainiert. Diese Traces legen das gewünschte Verhalten fest, bevor RL es fixiert: wie eine Chain of Thought aufgebaut ist, wie lange gedacht wird, wie Fehler geprüft werden, wann aufgehört wird, und in welcher Sprache all das passiert. Strukturelle Eigenschaften des Reasonings lassen sich meist nur im Cold Start einführen, nicht später. Wenn wir deutsches Reasoning wollen, müssen wir es also via SFT kaltstarten.

Keine Daten in Sicht

Fast alle existierenden mehrsprachigen Post-Training-Datensätze sind Übersetzungen von ursprünglich englischen Daten – meist veröffentlicht von amerikanischen KI-Labs. Jedes Modell, das darauf trainiert wird, erbt das enthaltene Weltbild. Wer einen deutschen Assistenten, der auf übersetzten Daten beruht, nach einem Kuchenrezept fragt, bekommt womöglich zwei Tassen Mehl, eine Stange Butter und einen Ofen bei 350 Grad Fahrenheit. Der Text ist deutsch, das Rezept amerikanisch. Dass das ein Problem ist, fiel lange nicht auf, denn übersetzte Trainingsdaten und übersetzte Benchmarks haben denselben Bias. Nur auf nativen oder generativen Benchmarks schneiden Modelle mit übersetzten Trainingsdaten schlechter ab als solche mit nativen (Chen et al., 2024). Inzwischen gehen die großen Labs anders vor. GPT-4 wurde noch auf maschinell übersetztem MMLU evaluiert (OpenAI, 2023), für MMMLU hat OpenAI aber dann professionelle Übersetzer beauftragt (OpenAI, 2024). Meta hat für Llama 3 maschinell übersetzte Daten weitgehend vermieden, um „Translationese“ sowie „name bias, gender bias, or cultural bias“ zu umgehen (Grattafiori et al., 2024).

Wir nutzen übersetzte Benchmarks dort, wo sie das Richtige messen. Übersetzt sind bei uns nur Mathe-Prompts und ein Teil der Tool-Daten. Die Reasoning-Traces erzeugen wir durchweg neu. Es gibt also kein gemeinsames Übersetzungsartefakt, das die Werte aufblähen könnte. Ein übersetzter Mathe-Benchmark soll nicht messen, ob ein Modell Deutschland versteht, sondern ob es ein schweres Problem lösen kann. Für den Teil, den Übersetzung nicht messen kann, haben wir Kulturbank gebaut, einen deutschen Benchmark für kulturelles Wissen. Er besteht aus rund 200 deutschen Fragen, die Nischenwissen über regionale Bräuche, lokale Persönlichkeiten und mehr abfragen.

Auf der Trainingsseite sind die nativ deutschen Datensätze, die es gibt, meist klein und alt. Sie stammen aus der Zeit vor den Reasoning-Modellen. Wir haben das deutsche SFT-Ökosystem durchsucht, nichts Brauchbares gefunden und uns entschieden, die Daten selbst zu erzeugen. Das tun wir per Distillation: Ein stärkeres Modell, der Lehrer, erzeugt die Trainingsbeispiele, und das Zielmodell, der Schüler, lernt, sie zu reproduzieren. Eine gute deutsche Chain of Thought braucht also einen Lehrer, der bereits gut auf Deutsch denkt. Wir nutzen einen Trick, der deutsches Reasoning aus Lehrern herausholt, die sonst auf Englisch denken würden.

Ein Rezept, drei Domänen

Wir erzeugen deutsche Trainingsbeispiele für allgemeinen Chat, Tool Calling, Mathematik, Naturwissenschaften und Code; dieser Beitrag behandelt die ersten drei. Die Pipeline für die Domänen sieht jeweils recht ähnlich aus. Zunächst erzeugen wir einen Prompt aus Seeds. Dann durchdenkt der Lehrer den Prompt, wobei wir einen deutschen Satzanfang vorgeben. Anschließend schreibt er die finale Antwort und wir prüfen das Ergebnis und bereinigen sprachliche Fehler. Bei Bedarf wiederholen wir den Vorgang, um eine Konversation über mehrere Runden aufzubauen. Die Domänen unterscheiden sich vor allem in der Herkunft der Seeds und in der Prüflogik: Eine Mathe-Antwort lässt sich gegen eine Referenz prüfen, eine Chat-Antwort nicht. Als Lehrer nutzen wir mehrere Open-Source-Modelle, die sich im Deutschen als zuverlässig erwiesen haben.

Seed-Prompts

Um ein starkes Modell (Lehrer) in das Zielmodell (Schüler) zu destillieren, stellen wir zuerst eine sinnvolle Liste von Prompts zusammen.

Unsere deutschen Seed-Prompts entstehen auf zwei Wegen, je nachdem, wie kulturspezifisch die Zieldomäne ist. Mathe- und Code-Aufgaben sind meist „kulturfrei“; eine quadratische Gleichung funktioniert überall auf der Welt gleich. Selbst wenn eine Matheaufgabe kulturell eingefärbt ist, etwa „Wie viele Adler passen in den Reflecting Pool in Washington, wenn jeder 6 Quadratfuß braucht?“, ist der kulturelle Teil nebensächlich. Eine Fläche aufzuteilen ist eine Fähigkeit, die über Kulturen hinweg gilt. Solche Aufgaben lassen sich deshalb unbedenklicher übersetzen. Zudem beinhalten die Mathe-Datensätze, die wir nutzen, geprüfte Antworten für viele Prompts. Damit können wir später jeden deutschen Trace auf Korrektheit prüfen und die falschen verwerfen.

Für alltägliche Chat-Prompts (unsere „General“-Pipeline) gehen wir anders vor. Würden wir Prompts aus offenen Chat-Datensätzen übersetzen, kämen deren Themen und Gewohnheiten gleich mit. Also lassen wir die Prompts neu schreiben: Ein starkes Lehrermodell versetzt sich in einen deutschen Nutzer und formuliert eine Anfrage, wie dieser sie tippen würde. Als Ausgangspunkt dienen keine bestehenden Beispiele, sondern kategoriale Seeds, also Kombinationen von Stichworten aus kuratierten Listen, mit mindestens einem Thema und einem Aufgabentyp. Aus {"Schrebergarten", "Plan"} wird so etwa die Bitte um einen einfachen Pflanzplan für den Schrebergarten. Auf diese Weise bleiben die Daten breit gestreut, und wir können gezielt deutsche Themen einbringen.

Reasoning-Prefill-Distillation

Wir wollen sowohl die Antwort als auch das Reasoning des Lehrers auf Deutsch. Eine deutsche Antwort zu bekommen ist nicht besonders schwer. Gute deutsche Reasoning-Traces dagegen schon. Sich selbst überlassen, denkt ein englisch kaltgestartetes Reasoning-Modell über deutsche Prompts auf Englisch nach und zitiert dabei Wendungen aus dem deutschen Prompt (Yong et al., 2025). Übersetzt man einen guten englischen Reasoning-Trace, übernimmt man die Gewohnheiten des Übersetzers, zum Beispiel:

Statt dem Modell dieses umständliche und ineffiziente Reasoning-Verhalten anzutrainieren, greifen wir zu Beginn des Reasoning-Traces ein, denn hier wird die Sprache festgelegt. Wir geben jeweils einen kurzen deutschen Satzanfang vor und lassen das Modell von dort weiterschreiben. Die Satzanfänge passen zur Domäne und orientieren sich daran, wie derselbe Lehrer seine englischen Traces beginnen würde. Ein Mathe-Trace könnte mit „Gegeben ist:“ beginnen, eine allgemeine Aufgabe mit „Der Nutzer möchte“. Die ersten Token legen Sprache und Konsistenz eines Traces weitgehend fest (Bajpai & Chakraborty, 2025). Ein ähnlicher Präfix-Trick wird auch bei On-Policy-Self-Distillation eingesetzt. Dort hält ein Satzanfang in der Zielsprache nach dem <think>-Tag die Ausgaben des Modells davon ab, ins Englische abzudriften (Liu et al., 2026). So beginnt zwar jeder Reasoning-Trace auf Deutsch, aber nichts garantiert, dass er auf Deutsch bleibt. Deshalb prüfen wir jeden Trace mit einem statistischen Sprachidentifikator und einem Test auf deutsche Stoppwörter und verwerfen alle, die unterwegs die Sprache wechseln.

Antworten, Prüfung und Rückfragen

Für jeden Prompt geben wir einen Denkanfang vor und der Lehrer schreibt von dort aus den vollständigen Trace und die Antwort. Was danach passiert, hängt davon ab, ob sich die erwartete Antwort prüfen lässt. Wo das möglich ist, wie bei den meisten Matheproblemen, vergleichen wir die Antwort des Modells mit dem erwarteten Ergebnis. Beispiele mit falscher Antwort werden verworfen. Bei qualitativen Matheaufgaben setzen wir ein Modell zur Prüfung ein. Das folgt der LLM-as-a-Judge-Praxis, die für offene Ausgaben zum Standard geworden ist (Zheng et al., 2023). In unserer General-Pipeline lassen wir den Judge weg, da wir festgestellt haben, dass zusätzliche Rechenzeit hier kaum die Qualität erhöht. Ein starker Lehrer liefert ohnehin fast immer solide Antworten.

Anschließend sortieren wir nicht-deutsche Antworten aus. Ein Judge für Sprachqualität liest dann Trace und Antwort in Abschnitten von etwa 3.000 Zeichen und gibt konkrete Korrekturen zurück, jeweils ein wörtliches Zitat mit einer Änderung. So werden fremdsprachige Einschübe, Grammatikfehler, seltsame Formulierungen und mehr behoben. Das wiederholen wir bis zu dreimal und verwerfen Beispiele, deren Deutsch danach noch Fehler hat.

Einen Teil der Gespräche verlängern wir auf mehrere Runden. Dazu liest ein Nutzer-Simulator den bisherigen Verlauf der Konversation und stellt eine plausible Anschlussfrage auf Deutsch. Der Lehrer beantwortet sie, wieder mit einem vorgegebenen deutschen Reasoning-Opener, und die neue Runde durchläuft dieselben Prüfungen. So sind auch Datensätze wie UltraChat entstanden (Ding et al., 2023).

Tool Calling

Für Tool-Calling-Daten nutzen wir beide Seeding-Ansätze und teilen die Fähigkeit dafür in einen kulturgebundenen und einen kulturfreien Teil. Für Ersteren ziehen wir Entitäten aus den Kategoriebäumen der deutschen Wikipedia und lassen einen Nutzer-Simulator eine neugierige Frage dazu stellen. Beim Formulieren seiner Antwort hat der Lehrer Zugriff auf Wikipedia-Werkzeuge (wikipedia_suche, wikipedia_abschnitt, wikipedia_umgebung, …), mit denen er Live-Daten abrufen kann. Das verankert den generierten Inhalt in echten Fakten. Der Lehrer denkt zwischen den Tool-Aufrufen nach und schreibt die Antwort auf Deutsch.

Die andere Hälfte unseres Tool-Calling-Anteils bauen wir bewusst auf Übersetzung auf. Das geht, weil es hier vor allem um die Mechanik geht: wann ein Tool aufgerufen wird, welche Argumente übergeben werden, wie ein Ergebnis gelesen wird und wie man auf Deutsch darüber nachdenkt. Ausgangspunkt sind englische Tool-Calling-Daten, die bereits in unserer Mischung sind. Wir übersetzen die Nutzeranfrage und die Antworten des Assistenten, lassen aber Tool-Schemata, Aufrufe und Ergebnisse unverändert. Das entspricht dem späteren Einsatz des Modells: Die meisten APIs, die ein deutscher Nutzer über das Modell erreicht, sind ohnehin englisch. Dass die Tool-Seite unverändert bleibt, hat außerdem zwei praktische Vorteile. Erstens können wir jede Konversation prüfen, indem wir die aufgezeichneten Aufrufe erneut abspielen. Zweitens müssen wir keine eigenen Tools bauen und am Laufen halten. Nur die vorhandenen Reasoning-Traces ersetzen wir: Der Lehrer schreibt sie auf Deutsch neu, während die Tool-Aufrufe und ihre Ergebnisse unverändert bleiben.

Daten zählen

Zusammen liefern unsere deutschen Pipelines rund 796.000 deutsche Beispiele, die meisten davon mit deutschen Reasoning-Traces. Einen Teil haben wir absichtlich ohne Reasoning erzeugt, damit das Modell auch mit abgeschaltetem Reasoning robuste Antworten geben kann.

Wie viel Deutsch ist genug?

Nun, da wir die Daten generiert haben, möchten wir drei Dinge wissen:

1. ob ein darauf trainiertes Modell auf Deutsch denkt, wenn es auf Deutsch gefragt wird;
2. ob es beim Denken auf Deutsch ähnlich gute Antworten liefert wie beim Denken auf Englisch, und ob das von der Domäne abhängt;
3. wie viele deutsche Daten beides braucht.

Dafür trainieren wir eine Reihe ansonsten identischer Modelle, die sich in genau einer Sache unterscheiden: wie viele deutsche Daten sie im Cold Start sehen.

Versuchsaufbau

Wir entwerfen 13 Datenmischungen und trainieren mit jeder ein Modell. Jedes Training startet vom selben vortrainierten Checkpoint, einem Mixture-of-Experts-Modell mit 3 Milliarden aktiven Parametern, das Deutsch bereits im Pre-Training gelernt hat. Während des Trainings sieht jedes Modell etwa 16 Milliarden SFT-Tokens bei einer Sequenzlänge von 256k (262.144). Jede Datenmischung kombiniert englische Konversationen aus unserem allgemeinen SFT-Datenpool mit deutschen Daten aus den beschriebenen Pipelines. Die Mischungen unterscheiden sich nur darin, wie viel von jedem deutschen Datensatz sie enthalten: Ein Datensatz bekommt ein Gewicht zwischen ×0 (weggelassen) und ×16 (sechzehnmal häufiger als sein natürlicher Anteil). Da das Token-Budget begrenzt ist, bedeutet mehr Deutsch automatisch weniger Englisch. Wir gewichten die Tool-Calling-Daten auf 40 % herunter, damit die absolute Menge an Daten ungefähr mit der in unserem Mathepool vergleichbar ist.

Wir evaluieren auf drei englischen Benchmarks und ihren (übersetzten) deutschen Gegenstücken: AIME 2026 für Mathematik, IFEval für Instruktionsbefolgung und MuSiQue für Multi-Hop-Fragen. AIME hat nur 30 Aufgaben, deshalb berechnen wir den Mittelwert über 16 Versuche pro Aufgabe (avg@16). Das deutsche MuSiQue enthält nur 83 Aufgaben, also bearbeiten wir jede viermal (avg@4). Dazu kommt Kulturbank, unser interner deutscher Benchmark für kulturelles Wissen, der bewusst kein englisches Gegenstück hat. Jede Evaluation läuft mit max_tokens=65,536.

Umweg über Englisch

Auf jedem deutschen Benchmark außer Kulturbank ist de-0 das beste Modell, obwohl es keine deutschen SFT-Daten gesehen hat. de-0 führt auf den deutschen Versionen von AIME (70,2), IFEval (70,0) und MuSiQue (36,5). Das Modell liest hier die deutsche Aufgabe, denkt auf Englisch und gibt offenbar gute Antworten. Genau diesen Umweg über Englisch beschreibt auch die Literatur. Ein wenig Deutsch schadet: de-1 verliert 13 Punkte auf AIME und 8 auf IFEval. Die Einzelgruppen-Sweeps zeigen dasselbe Muster, mit math-0 als schlechtestem Modell auf AIME (48,3). Mit mehr deutschen Daten holt das Modell den Verlust größtenteils wieder auf; math-16 erreicht einen Score von 67,3. Wir gehen den Gründen in den nächsten Abschnitten nach.

Die englische Leistung leidet nicht. Über alle dreizehn Läufe bleibt der gemittelte Wert praktisch gleich: 60,3 ohne deutsche Daten, 60,1 bei de-16 und 60,5 im besten Lauf (general-16). Die Ausnahme ist das englische AIME. Es schwankt zwischen 64,0 und 83,8 und folgt keinem Gruppenanteil. Wir glauben nicht, dass die deutschen Daten dafür verantwortlich sind. AIME hat nur 30 Aufgaben, und bei so kleinen Mathe-Benchmarks schwankt schon ein einzelner Evaluierungslauf allein durch das Sampling um 5 bis 15 Punkte (Hochlehnert et al., 2025). Wir mitteln über 16 Versuche pro Aufgabe (avg@16) und gleichen einen großen Teil davon aus. Was bleibt, sind Unterschiede zwischen den Checkpoints selbst. Die Ausgaben zeigen, dass sich die Checkpoints vor allem darin unterscheiden, wie lange sie nachdenken: Manche denken systematisch länger und laufen öfter in das Kontextlimit hinein. Das trifft AIME besonders hart, weil eine einzige Aufgabe Zehntausende Reasoning-Tokens benötigen kann. Resultate auf der deutschen AIME-Version sind zwar auch hiervon betroffen, aber dort überwiegen andere Effekte, wie die nächsten Abschnitte erklären.

Sprachkonsistenz der Antwort

Unsere deutschen Daten verbessern die Sprachkonsistenz nicht nur im Reasoning, sondern auch in der finalen Antwort, besonders im Bereich der Mathematik. de-0 beantwortet nur rund 55 % der deutschen AIME-Fragen auf Deutsch. Müsste eine Antwort richtig und deutsch sein, um zu zählen, fiele der Score von de-0 von 70,2 auf 42,3. Jede noch so kleine Dosis deutscher Reasoning-Daten bringt die Sprachkonsistenz gleich auf 100 %.

Auf IFEval bleibt eine Lücke von zehn Punkten in der Sprachkonsistenz, die keine Menge deutscher Daten schließt. Diese Beobachtung lässt sich anhand der Benchmark-Implementierung erklären. Manche IFEval-Prompts verlangen eine Antwort auf Swahili oder im JSON-Format. Eine nicht-deutsche Antwort wäre in diesem Fall regelkonform, eine deutsche nicht. Andere Prompts verlangen Text komplett in Klein- oder Großbuchstaben, und der Prüfer des Benchmarks kontrolliert das mit langdetect(value) == "en" – das ist im Prinzip ein Bug. Eine korrekte deutsche Antwort fällt also durch, eine englische besteht. Beim kreativen Schreiben ist das Modell dagegen unsicher. Gefragt nach „zwei Witze[n] über Raketen“ produziert de-4 zwei Raketenwitze auf Englisch und keinen auf Deutsch. Es scheint, dass unsere Daten sehr wenige deutsche Witze enthalten. Wir halten das für kulturell authentisch.

Das Tal

Auf der deutschen AIME-Version denkt de-0 fast ausschließlich auf Englisch und erreicht 70,2. Sobald deutsche Reasoning-Daten in die Trainingsmischung kommen, wechselt das Modell zu ausschließlich deutschem Denken. Es beginnt aber auch, im Reasoning zu „loopen“ – ein bekanntes Fehlermuster von Reasoning-Modellen. Das Modell wiederholt sich, bis es die Kontextgrenze erreicht, und gibt keine Antwort. Ein Viertel der deutschen Reasoning-Traces von math-0 loopt, und die Benchmark-Performance fällt auf 48,3. Von dort verbessern mehr deutsche Daten das Bild langsam. Bei math-16 sinkt der Looping-Anteil auf etwa 15 %, und der Score erholt sich auf 67,3. Barua et al. beobachten denselben Fehler, „unstable generation (e.g., endless repetition)“, allerdings bei mittel- und ressourcenarmen Sprachen. Dort bringen schon tausend Traces in der Zielsprache so viel wie die zwanzigfache Menge englischer Traces (Barua et al., 2025). Bei uns erholt sich vor allem der Score, das Verhalten dagegen kaum. Bei jedem deutschen Anteil gerät das Modell deutlich häufiger in Endlosschleifen als die Baseline ohne Deutsch. Das ist das Tal der Tränen: Die Umstellung auf deutsches Reasoning kostet zunächst Leistung. Um diese zurückzugewinnen, braucht es viele deutsche Daten, und selbst beim höchsten Anteil, den wir getestet haben, ist sie noch nicht ganz zurück.

Welche deutschen Daten helfen aus dem Tal heraus? Der deutsche Gesamtanteil sagt keinen der deutschen Werte voraus (alle |ρ| ≤ 0,34). Es zählt, woher die deutschen Daten kommen. Jede Gruppe hilft dem Benchmark, der ihrer Domäne am nächsten liegt, und meist über denselben Hebel: Das Modell bringt sein deutsches Reasoning häufiger zu Ende.

Mathe-Daten helfen dem deutschen AIME. Ihr Anteil korreliert positiv mit dem Score (ρ = +0,86) und negativ mit unbeantworteten Rollouts (−0,87) und Endlosschleifen (−0,66). Anderswo helfen die deutschen Mathedaten nicht. Englisches AIME und MuSiQue neigen sogar in die andere Richtung (−0,54 und −0,53), ohne jedoch die Signifikanzschwelle zu erreichen.

General-Daten verbessern die Performance auf der deutschen IFEval-Version (ρ = +0,66) und sonst kaum. Trotzdem setzt sich deutsches Reasoning auf IFEval nie ganz durch. Der Anteil wächst von etwa der Hälfte der Beispiele bei de-0 auf etwa drei Viertel bei de-16.

Unsere deutschen Tool-Daten haben zwei Effekte. Erstens verbessern sie Kulturbank (ρ = +0,66), das auf keine andere Gruppe reagiert. Die wahrscheinliche Quelle ist die Wikipedia-Pipeline, die das deutsche Wissen des Modells auffrischt. Zweitens gibt es mit mehr Tool-Daten weniger unbeantwortete Rollouts auf dem deutschen MuSiQue (ρ = −0,68), der Score ändert sich aber nicht (ρ = −0,11). Auf dem englischen MuSiQue steigt der Wert hingegen (ρ = +0,40). Ein Teil der Tool-Fähigkeit überträgt sich augenscheinlich über die Sprachgrenze hinaus.

Fazit

Reasoning-Prefill-Distillation erweist sich als verlässliche Methode, um deutsche Reasoning-Traces in großer Zahl zu erzeugen. In unserem Cold-Start-Experiment reicht schon ein kleiner Anteil dieser Daten, damit das Modell auf Deutsch denkt und antwortet. Die englische Leistung bleibt dabei unberührt. Bei der Genauigkeit sieht es anders aus, und das bestätigt, was die Literatur im Großen und Ganzen sagt: Reasoning auf Englisch bleibt überlegen, selbst bei deutschen Aufgaben. In kleinen Mengen schaden deutsche Reasoning-Daten: Die Scores sinken auf fast allen Benchmarks. Auf drei der vier deutschen Benchmarks entsteht der direkte Verlust vor allem durch Traces, die nicht zu Ende kommen, nicht durch fertige Traces mit schlechteren Ergebnissen. Die Ausnahme ist Multi-Hop-Retrieval. Dort kommen deutsche Traces zwar meist zu Ende, liefern aber oft falsche Antworten. Aus diesem Tal herauszukommen, braucht mehr Daten, als wir erwartet hatten. Dieser Post gibt einen ersten Anhaltspunkt, wie viele. Er zeigt, wie man einem Modell beibringt, auf Deutsch zu denken, aber noch nicht, wie es damit auch wieder aufhört. Wie bei allem, was SFT offenlässt, vertrauen wir darauf, dass RL es richtet.

Danksagungen

Diese Arbeit baut auf dem großartigen Einsatz des SFT-Teams bei Aleph Alpha auf. Unser Dank gilt Dylan Rodriguez, Garwin Lechner, Irina Vidal und Leonard Salewski. Wir danken außerdem Yasser Jadidi, Martin Feltes, Niko Dürr, Pablo Schumacher und Helena Treeck für ihre Reviews dieses Posts, Noé Beckerle Vallejo für die Grafiken, Paige Reddington für die Unterstützung bei Social Media, Svenja Fahlisch für die Organisation und Alexander Wortmeier für die Veröffentlichung auf der Website.