Mid-Training: Was Coding-Modelle lesen, bevor sie zu Agenten werden

Darum geht es

Bisher hieß es oft, ein Sprachmodell entstehe in zwei Schritten. Im Vortraining liest es Billionen Tokens aus dem Netz. Im Post-Training wird es mit Feintuning (SFT, überwachtes Lernen an Beispieldialogen) und Reinforcement Learning (RL, Lernen durch Belohnung) zum Assistenten geformt. Bei Coding-Agenten, also Modellen, die selbstständig Code lesen, Befehle ausführen und Fehler beheben, steckt dazwischen fast immer eine dritte Phase: das Mid-Training. Qwen3-Coder-Next, GLM-5 und Kimi-Dev haben eine solche Phase, und Cursors Composer 2 setzt mit „Continued Pretraining“ etwas Ähnliches ein.

Wie man die Daten dafür zusammenstellt, stand in keinem dieser Berichte. NVIDIAs Nemotron-Team schreibt dazu im neuen Paper „Priming Base Models for Agentic Post-Training“ (arXiv 2610.22019, 15. Oktober 2026):

„Technische Berichte beschreiben diese Phase nur grob, erklären aber selten, wie ihre Daten aufgebaut sind.“

Das Paper legt die Rezeptur bis auf Ablationsebene offen. Ablation heißt: Man lässt gezielt eine Zutat weg und misst, was sich dadurch ändert. Die zentrale These lautet: Ein Modell sollte erst lesen, wie echte Software-Arbeit aussieht, bevor es Agentenverhalten einübt. Japanische Fachblogs wie Zenn fassen das so zusammen: „Erst die Baustelle lesen lassen, dann die Form beibringen.“

Warum es eine dritte Phase braucht

Die Autoren nennen drei Lücken. Erstens läuft das Vortraining meist mit nur 4.000 bis 8.000 Tokens Kontext. Ganze Repositories, Commit-Historien oder lange Werkzeug-Protokolle passen da nicht hinein. Für die kurze Phase, in der der Kontext am Ende des Vortrainings verlängert wird, sind diese Daten wiederum zu umfangreich. Zweitens kennt das Vortraining kein Loss-Masking. Damit ist gemeint, dass man das Modell auf bestimmte Textteile nicht prüft. Es ist deshalb unklar, wie man Werkzeugausgaben in Agenten-Protokollen behandeln soll. Drittens kann sehr langes SFT mit synthetischen Dialogen laut den Autoren das spätere RL ausbremsen. Mid-Training soll deshalb Lernarbeit aus dem Feintuning herausziehen, damit dieses kurz bleiben kann.

Der Begriff selbst ist nicht einheitlich. Bei OLMo 2 hieß die vergleichbare Phase „Late-Stage Curriculum“ während des Annealings, also des Endspurts, in dem die Lernrate gegen null sinkt. Übersichtsarbeiten von 2025 bemängeln diese uneinheitliche Begriffswelt ausdrücklich. Eine CMU-Studie (Liu, Neubig, Xiong) grenzt Mid-Training von reinem Continued Pretraining ab. Beim Mid-Training mischt man Spezialdaten unter allgemeine Daten, statt nur Spezialdaten weiterzutrainieren. In ihren Versuchen mit kleinen Modellen schnitt die Mischung bei Code und Mathematik besser ab und ließ das Modell weniger vergessen.

Die Rezeptur: Was das Modell zu lesen bekommt

NVIDIA hat das Verfahren an Nemotron 3.5 Lightning entwickelt (30 Milliarden Parameter, davon 3 Milliarden pro Token aktiv) und an Nemotron 3.5 Super (120B, 12B aktiv) erprobt. Trainiert wird mit 256.000 Tokens langen, gepackten Sequenzen. Die Mischung des 500-Milliarden-Laufs:

Rechnet man nach, sind rund 65 Prozent natürliche Software-Daten, also von Menschen geschriebener Code samt Änderungen und Logs. Nur ein Zehntel ist im Chat-Format. Laut Zenn liegt der Anteil der Protokolle bewusst bei 10 bis 15 Prozent, damit das Modell sich nicht zu früh auf das starre Dialogformat festlegt. Ein Teil der Protokolle stammt von Perplexity, einem Partner in NVIDIAs „Nemotron Coalition“.

Zwei Details zeigen, wie das gemeint ist. Repositories kommen nur in die Mischung, wenn mindestens 20 Prozent ihrer Code-Dateien andere Dateien des Projekts importieren (bei Ruby 10 Prozent). Die Dateien werden dann so angeordnet, dass eine Datei erst nach den Dateien auftaucht, von denen sie abhängt. So liest das Modell eine Codebasis in der Reihenfolge, in der ihr Aufbau verständlich wird. Die Autoren begründen das vorsichtig: Die Abhängigkeitsreihenfolge trenne starke von schwachen Modellen besser als eine alphabetische Sortierung. Sie lege also Zusammenhänge über Dateigrenzen hinweg offen, die schwächere Modelle noch nicht gelernt haben. Das zweite Detail betrifft die Agenten-Protokolle. Gelernt wird nur an den Zügen des Assistenten. Was Werkzeuge zurückgeben, etwa Terminalausgaben oder Dateiinhalte, sieht das Modell zwar, muss es aber nicht vorhersagen.

Was die Ablationen zeigen

Die wichtigsten Einzelversuche, jeweils mit identischem Feintuning danach:

Ohne Protokolle bringt das Lesen echter Software allein auf SWE-bench Verified also weniger als einen Punkt. Das ist der Test, in dem ein Modell echte GitHub-Fehler beheben muss. Erst zusammen mit den Protokollen entsteht der größere Teil des Gewinns. Reine Protokolle wären laut den Autoren aber im Grunde nur ein langes SFT und würden das spätere RL behindern. Das ist ihre Begründung, ein gemessenes Ergebnis ist es nicht. Werden die oft langen und verrauschten Werkzeugausgaben mitgelernt, kostet das rund zehn Punkte. Laut Zenn ziehen sie offenbar Lernkapazität von den eigentlichen Agentenhandlungen ab.

Die Lernrate zeigt die Kosten des Verfahrens. Sie legt fest, wie stark das Modell pro Schritt umgebaut wird. Höhere Werte bringen mehr Agentenleistung, machen aber Mathematik und Allgemeinwissen kaputt: MATH-500 fällt von 79,7 auf 61,7, MMLU von 79,4 auf 76,8. NVIDIA hat sich bewusst unterschiedlich entschieden: Lightning läuft mit 5e-5, das Agenten-Gewinne vor Allgemeinwissen stellt, Super mit vorsichtigen 1e-5. Mit dieser Einstellung blieben beim Super-Modell nach 65 Milliarden Tokens alle allgemeinen Benchmark-Gruppen innerhalb von 1,2 Punkten des Ausgangswerts.

Was es unterm Strich bringt

Bei Lightning wurde das Mid-Training schrittweise auf 500 Milliarden Tokens ausgedehnt:

Das ergibt +3,8 auf Verified, +7,0 auf Multilingual und +3,5 auf Pro. Der Wert pass@k zählt, wie viele Aufgaben in mehreren Versuchen überhaupt einmal gelöst werden. Er steigt um 2,3 bis 4,7 Punkte, das Modell kann also tatsächlich mehr Aufgaben lösen. Auffällig ist der Kontext: Bei SWE-bench Pro liefen ohne Mid-Training 91 von 2.193 Durchläufen voll ins 256K-Limit, danach nur noch 13. Das ist rund siebenmal weniger. Über alle vier Benchmarks summiert sinkt die Zahl von 164 auf 54, also etwa auf ein Drittel. Die „siebenmal weniger“ gelten nur für SWE-Pro.

Gemessen wurde auch in verschiedenen Harnesses, also den Agenten-Programmen, in denen das Modell arbeitet. Beim Super-Modell nach 65 Milliarden Tokens und kurzem Feintuning lag das Plus auf Verified im Schnitt bei 8,6 Punkten. Bei Lightning wuchs der Wert in Codex um 19,0 und in Claude Code um 14,9 Punkte, in OpenHands nur um 3,8. Ein erster RL-Test mit 20 Schritten zeigt, dass der Vorsprung von etwa zwei Punkten das frühe RL übersteht. Die Formatfehler sanken dabei von 0,34 auf 0,03 Prozent. Die Autoren betonen selbst, dass sie damit nicht belegen, dass Mid-Training die Obergrenze des RL anhebt.

Im produktiven Training von Nemotron 3.5 Super steckt die Phase tatsächlich: 65,4 Milliarden Tokens bei 256K (die Modellkarte nennt 67 Milliarden), mit der Mischung 41/20/10/3/1/20/5 Prozent. Dabei gibt es einen Nebeneffekt. Die Fähigkeit, eine Million Tokens zu verarbeiten, brach auf dem Langtext-Test RULER auf rund 33 Punkte ein. Erst eine kurze Erholungsphase von etwa 9 Milliarden Tokens brachte sie auf 81 zurück.

Was die anderen verraten und was nicht

Kimi-Dev nutzte die Idee schon 2025: Gemergte PR-Diffs und Commit-Folgen dienten als „Skill Prior“, also als Vorwissen über Fehler finden und Code ändern, auf dem der spätere Agent aufbaut. Ein Widerspruch bleibt ungeklärt. Cursor wählte das Basismodell für Composer 2 über interne Messwerte wie die Perplexität auf Codebasen aus. Die Perplexität misst, wie überrascht ein Modell vom Text ist. Laut Cursor sagt der Cross-Entropy-Loss den späteren RL-Erfolg tatsächlich voraus. NVIDIA fand dagegen, dass solche Werte am Basismodell (Bits pro Byte, LoCoDiff) die Ergebnisse nach dem Feintuning nicht verlässlich vorhersagen. Das Team bewertet deshalb jede Datenentscheidung über einen kurzen, festen SFT-Lauf mit 33 Milliarden Tokens.

Unser Fazit

Der Wert des Papers liegt weniger in den Punktgewinnen als in der Offenheit. Zum ersten Mal kann man nachlesen, welche Zutaten ein Coding-Modell zwischen Vortraining und Feintuning bekommt und was jede einzelne bewirkt. Das erklärt zum Teil, warum offene Agenten-Modelle wie Xing4.0 oder Reflection Beam inzwischen hohe SWE-bench-Werte erreichen. Ob deren Hersteller es genauso machen, verraten sie aber nicht.

Unsere Einschätzung: Die Zahlen sind solide, aber bescheiden und nicht unabhängig geprüft. Fast jeder Vergleich beruht auf einem einzigen Trainingslauf. Die Autoren selbst beziffern die Schwankung beim Super-Modell auf etwa einen Punkt bei Verified und zwei bei DeepSWE. Der Verified-Gewinn von +1,4 beim Super-Modell und +1,0 auf Terminal-Bench bei Lightning liegen damit kaum über dem Rauschen. Beim großen Modell fielen Multilingual (−1,1) und Pro (−2,1) nach vollem Feintuning sogar ab. Zwischen 100 und 500 Milliarden Tokens bewegt sich Verified nur innerhalb eines Punktes. Mehr Daten helfen hier also nur noch bei Multilingual sichtbar. Einen Vergleich, bei dem dieselbe Tokenmenge in längeres Vortraining oder Feintuning fließt, gibt es nicht. Getestet wurde zudem nur an Nemotron-Modellen.

Und „offen“ ist bisher nur die Beschreibung. NVIDIAs Dokumentation sagt ausdrücklich, dass die Datenmischungen nicht öffentlich sind und die Phase nicht nachgebaut werden kann. Im Paper heißt es nur, dass Verarbeitungsskripte und Metadaten in einer späteren Version erscheinen sollen, von den Daten selbst ist keine Rede. Auf Hugging Face liegen bisher nur NVIDIAs ältere SFT- und RL-Datensätze für Software-Aufgaben, nicht das Material aus dem Mid-Training. Wer die Rezeptur nachkochen will, muss die Zutaten vorerst selbst beschaffen.