Reasoning-Modelle werden trainiert, nicht geprompted

Hier ist eine Meinung, die ich beim Team-Lunch letztes Jahr schlecht verteidigt habe und die ich seitdem noch stärker vertrete: Wenn dein mentales Modell eines Reasoning-Modells „ein normales LLM, dem man gesagt hat, Schritt für Schritt zu denken“ ist, verstehst du Reasoning-Modelle überhaupt nicht – und dieses Missverständnis kostet dich in der Produktion still und leise Geld und Genauigkeit. Reasoning-Modelle sind keine Prompting-Technik. Sie sind ein Trainingsergebnis. Das Chain-of-Thought-Verhalten, das sie in Mathe und Code so gut macht, entsteht durch Reinforcement Learning mit überprüfbaren Belohnungen, nicht durch irgendetwas, das du in einen System-Prompt schreibst. Richtig verinnerlicht habe ich das erst, als ich denselben Stoff durchgearbeitet habe, den Sebastian Raschka in seinem neuen 11-stündigen Kurs „Build a Reasoning Model“ behandelt: ein kleines Qwen3-Basismodell laden, einen Verifier bauen, GRPO laufen lassen und zusehen, wie die Reasoning-Traces länger werden und die Genauigkeit steigt. Wenn du das einmal in deiner eigenen Trainingsschleife gesehen hast, kannst du es nicht mehr ungesehen machen.

Lass mich diese Behauptung ordentlich begründen und sie dann dort zurücknehmen, wo das angebracht ist – denn es gibt einen Punkt, an dem Prompting tatsächlich eine Rolle spielt, und das abzustreiten wäre nur Hype in anderer Form.

Warum das „Einfach prompten“-Modell zusammenbricht

Die populäre Geschichte geht so: 2022 fanden Forscher heraus, dass das Anhängen von „Let's think step by step“ an einen Prompt die Genauigkeit bei Arithmetik deutlich verbesserte, und Chain-of-Thought-Prompting war geboren. Soweit stimmt das. Was die Geschichte auslässt, ist, was danach passierte: Die Labs haben dieses Verhalten genommen und mit Reinforcement Learning in die Gewichte eingebrannt. Ein modernes Reasoning-Modell braucht deine Schritt-für-Schritt-Formel nicht mehr. Es erzeugt standardmäßig ausgedehnte Reasoning-Traces, weil es genau dafür trainiert wurde – belohnt für Traces, die in korrekten Antworten enden.

Das kannst du selbst mit einem Experiment prüfen, das einen Nachmittag dauert. Nimm ein Basismodell – Qwen3 0.6B funktioniert gut und läuft auf einer einzelnen Consumer-GPU – und evaluiere es auf MATH-500 mit und ohne Chain-of-Thought-Prompting. Du bekommst einen moderaten Zuwachs. Nimm jetzt die RLVR-trainierte Variante derselben Modellfamilie. Der Abstand zwischen diesen beiden Bedingungen ist kein Zuwachs mehr, sondern eine Klippe. Kein jemals geschriebener System-Prompt schließt sie. Darin liegt der empirische Kern meiner Behauptung: Die Fähigkeit steckt in den Gewichten, und die Gewichte haben diese Form durch Training bekommen, nicht durch clevere Token-Anordnungen zur Inferenzzeit.

Die Verwirrung hält sich, weil beide Varianten von außen identisch aussehen: Das Modell gibt einen langen Strom an Zwischenschritten aus, bevor es antwortet. Doch die oberflächliche Ähnlichkeit verdeckt einen kausalen Unterschied. Ein Basismodell zum Schritt-für-Schritt-Denken zu bringen, ist, als würde man jemanden bitten, seinen Denkprozess laut zu kommentieren, während er im Kopf rechnet – der Kommentar folgt der Fähigkeit. RL-Training verändert die Fähigkeit selbst, weil das Modell end-to-end auf die Korrektheit der Antwort optimiert wird und ausführliches Denken zufällig eine nützliche Strategie ist, um bei schweren Aufgaben richtige Antworten zu bekommen.

Der Verifier ist der ganze Trick

Als ich noch als ML-Engineer gearbeitet habe, war der Teil von RLHF, der sich immer leicht verflucht anfühlte, das Reward-Modell. Man trainiert ein separates neuronales Netz, das menschliche Präferenzen imitiert, optimiert dann die Policy dagegen und verbringt den Rest des Projekts damit, Reward Hacking zu bekämpfen – die Policy findet eine degenerierte Ausgabe, die beim Reward-Modell hoch punktet, für echte Menschen aber nutzlos ist. Das ist eine adversariale Beziehung, die fest in die Architektur eingebaut ist.

Reinforcement Learning mit überprüfbaren Belohnungen – RLVR – umgeht das komplett, und wenn du einen Verifier von Grund auf baust, merkst du, wie elegant dieser Schritt ist. Bei Mathe ist der Verifier ein langweiliges, deterministisches Programm: Es extrahiert die finale Antwort aus der Ausgabe des Modells, normalisiert sie (Brüche, Dezimalzahlen und äquivalente Schreibweisen wie 1/2 vs. 0.5 behandeln) und prüft die mathematische Äquivalenz. Richtige Antwort, Belohnung eins. Falsche Antwort, null. Es gibt kein gelerntes Reward-Modell, das man hacken könnte. Das Belohnungssignal ist Ground Truth.

Deshalb wurden Reasoning-Modelle zuerst in Mathe und Code gut. Beide Domänen haben günstige, verlässliche Verifier – symbolische Äquivalenzprüfer für Mathe, Unit-Tests für Code. Du brauchst keine menschlichen Annotatoren, die Ausgaben ranken; du brauchst eine Python-Funktion, die einen Booleschen Wert zurückgibt. Die praktische Konsequenz für alle, die domänenspezifisches Reasoning bauen, ist eindeutig: Wenn du für deine Domäne einen Verifier schreiben kannst, kannst du wahrscheinlich auch einen Reasoner dafür trainieren. Wenn nicht – wenn Korrektheit in deiner Domäne Geschmackssache ist, wie bei Werbetexten –, bleibt dir nur RLHF mit seinen Reward-Hacking-Kopfschmerzen.

Der Engpass beim Reasoning in einer neuen Domäne ist nicht Rechenleistung oder Daten. Es ist die Frage, ob du aufschreiben kannst, was „korrekt“ als Programm bedeutet.

Ein Detail, das ich am Bauen des Verifiers vor dem Training liebe: Er hat doppelte Funktion. Derselbe Grader, der dein Basismodell auf MATH-500 zur Evaluation bewertet, wird während des RL zur Belohnungsfunktion. Wenn du ihn selbst implementierst, merkst du, wie viel subtile Arbeit er leistet. Die Extraktion der Antwort ist wirklich fummelig, weil Modelle finale Antworten in dutzenden Formaten ausdrücken, und ein wackliger Extraktor verfälscht das Belohnungssignal stillschweigend. Ein Modell, das „also x = 7“ schreibt, wird möglicherweise falsch bewertet, wenn dein Regex nur nach boxed-Antworten sucht. Schlampige Verifier erziehen schlampige Policies. Diese Lektion lernst du beim Lesen von Papers einfach nicht.

Was GRPO tatsächlich mit den Gewichten macht

Die Trainingsschleife selbst ist in ihrer vereinfachten Form aus dem Nichts erstaunlich kompakt. Group Relative Policy Optimization – der Algorithmus, den DeepSeek populär gemacht hat – verzichtet auf das Critic-Netz, das PPO so speicherhungrig macht. Statt eine Value-Funktion zu lernen, erzeugst du eine Gruppe von Antworten auf denselben Prompt, bewertest sie alle mit dem Verifier und berechnest den Advantage jeder Antwort relativ zum Gruppendurchschnitt. Antworten, die besser sind als der Gruppenmittelwert, werden in ihren Token-Wahrscheinlichkeiten nach oben geschoben; schlechtere nach unten.

def grpo_advantages(rewards: torch.Tensor) -> torch.Tensor:
# rewards: [group_size], one per sampled response to the same prompt
mean = rewards.mean()
std = rewards.std().clamp_min(1e-4)
return (rewards - mean) / std  # relative advantage per response
# Training step: maximize advantage-weighted log-probability
def grpo_loss(logprobs: torch.Tensor, advantages: torch.Tensor) -> torch.Tensor:
# logprobs: summed sequence log-prob under the current policy
return -(advantages.detach() * logprobs).mean()

Echte Implementierungen ergänzen einen KL-Penalty, der verhindert, dass die Policy zu weit vom Referenzmodell abdriftet, dazu Clipping aus PPO. Aber das Skelett oben ist ehrlich gesagt der Kern der Idee. Und das Faszinierende am Zuschauen: Du sagst dem Modell nichts über den Denkstil. Du belohnst nur korrekte finale Antworten. Trotzdem werden die Antwortlängen im Lauf des Trainings größer. Das Modell beginnt, sich mitten im Trace selbst zu korrigieren – „Moment, ich prüfe das nochmal“ –, weil Traces mit Verifikationsverhalten häufiger in korrekten Antworten enden, und korrekte Antworten sind das Einzige, was Belohnung bringt. Der Chain-of-Thought-Stil ist eine emergente Lösung des Optimierungsproblems, kein Verhalten, das jemand entworfen hat. Deshalb sage ich: trainiert, nicht geprompted. Die Prompting-Version dieses Verhaltens war, dass Menschen nachahmten, was RL später von selbst entdeckte.

Hier steckt eine pragmatische Ingenieurs-Notiz, die der Hype-Zyklus überspringt: Ein 0.6B-Modell auf einer ordentlichen GPU reicht, um diese Dynamik tatsächlich zu sehen. Du bekommst messbare MATH-500-Verbesserungen durch GRPO auf Hardware, die du für ein paar Dollar pro Stunde mieten kannst. Ein Frontier-Modell wirst du nicht bekommen. Das ist in Ordnung – darum geht es bei der Übung nicht.

Inferenz-Zeit-Skalierung: Wo Rechenleistung das Training (teilweise) ersetzt

Bevor überhaupt RL passiert, gibt es eine Familie von Techniken, die Antworten bei eingefrorenen Gewichten verbessern: mehrere Kandidaten mit Temperature und Top-p samplen und dann kombinieren. Self-Consistency ist das Arbeitspferd – k Antworten erzeugen und per Mehrheitsentscheid über die finalen Antworten abstimmen. Das funktioniert erstaunlich gut, und zwar auch auf Basis-Modellen. Damit ist der erste Riss in meiner Eingangsthese da, den ich zugebe: Rechenaufwand zur Inferenzzeit ist eine echte, eigenständige Achse der Verbesserung.

Aber schau dir an, was diese Techniken eigentlich voraussetzen. Mehrheitsentscheid hilft nur, wenn dein Modell bereits eine nicht-triviale Wahrscheinlichkeit für korrekte Antworten hat – Voting verstärkt vorhandenes Signal, es erzeugt aber kein Signal aus dem Nichts. Scoring-basierte Auswahl (Kandidaten nach Sequenz-Log-Probability ranken) hat dieselbe Eigenschaft. Und Self-Refinement-Schleifen, in denen das Modell die eigene Antwort kritisiert und überarbeitet, erweisen sich bei Basismodellen als enttäuschend schwach, weil ehrliche Selbstkritik selbst eine Fähigkeit ist, die RL installiert. Jeder Inferenz-Trick ergänzt das Training; keiner ersetzt es. Dass Frontier-Systeme RL-trainierte Modelle mit Inferenz-Skalierung kombinieren, liegt daran, dass sich beide multiplizieren statt zu addieren.

Für die Praxis zählt auch die Kostenseite. Self-Consistency mit k=16 kostet das Sechzehnfache an Inferenz. Ob sich das lohnt, hängt ganz von deiner Kurve aus Genauigkeit pro Dollar ab, und die einzig ehrliche Antwort darauf ist, selbst die MATH-500-Genauigkeit gegen die Anzahl der Kandidaten zu plotten. Eine ähnliche Frage zur Platzierung von Rechenaufwand haben wir in unserem Blick auf Flash-Tier-Modelle und Inferenz-Effizienz behandelt. Das wiederkehrende Thema: „mehr Rechenleistung ausgeben“ hat mindestens drei verschiedene Bedeutungen, und die sind nicht austauschbar.

Distillation, und die eine Stelle, an der Prompting überlebt

Die letzte Stufe der Pipeline von Grund auf ist Distillation: Man nimmt die langen Reasoning-Traces eines starken (meist großen) Reasoners und feintunt ein kleineres Modell direkt darauf, mit ganz normalem überwachtem Lernen. Kein RL, kein Verifier in der Schleife. So sind viele der günstigen, kleinen Reasoning-Modelle entstanden, die du tatsächlich einsetzen wirst. Das stützt die These eher, als dass es sie untergräbt: Das Reasoning-Verhalten kommt immer noch von Trainingsdaten, die ein RL-trainiertes Modell erzeugt hat, nur übertragen über Gradient Descent statt über Belohnung. Die Fähigkeit wird nie zur Prompt-Zeit eingespeist; sie wird immer durch Optimierung eingebrannt.

Wo bricht meine Gegenthese also? Ehrlich gesagt: Prompting spielt am Rand weiterhin eine Rolle, und diese Ränder sind nicht null. Reasoning-Effort-Einstellungen – die Low-, Medium- und High-Thinking-Budgets, die aktuelle Modellgenerationen anbieten – sind Inferenz-Stellschrauben, mit denen sich Genauigkeit gegen Latenz und Kosten spürbar tauschen lässt. Strukturierte Ausgabe-Constraints, Verifier-in-the-Loop-Pipelines und Constrained Decoding sind Techniken auf Prompt- und Harness-Ebene mit echtem Nutzen, wie wir in unserem Artikel zu Constrained Decoding dargelegt haben. Und wenn du an einem Basismodell hängst und nichts trainieren kannst, bringt Chain-of-Thought-Prompting bei Evals immer noch echte Punkte. „Trainiert, nicht geprompted“ ist eine Aussage darüber, wo die Fähigkeit entsteht – nicht darüber, dass Entscheidungen zur Inferenzzeit keine Rolle spielen.

Warum selbst bauen mehr bringt als lesen

Ein berechtigter Einwand kam an den üblichen Stellen auf: Ist ein Tutorial zum Bauen eines eigenen Reasoning-Modells nicht wie eine Anleitung zum Bau eines eigenen CPUs – charmant, aber nutzlos, weil echte Trainingsläufe Cluster und proprietäre Daten brauchen? Ich finde, das verfehlt, wozu die Übung dient, und dasselbe gilt für das klassische Build-a-Shell-Tutorial, das wir in What Building a Shell Teaches You About Unix aus genau diesem Grund gelobt haben. Niemand schreibt eine Shell, um Bash zu ersetzen. Man schreibt eine, damit fork, exec, Pipes und Signalbehandlung aufhören, auswendig gelernte Abstraktionen zu sein, und zu Mechanik werden, die man selbst in der Hand hatte.

Genauso hier. Das, was meine Arbeit mit Reasoning-Modellen dauerhaft verändert hat, kam aus Implementierungsdetails, nicht aus Papers:

• Den Verifier zu schreiben hat mir gezeigt, dass Belohnungsqualität ein Software-Engineering-Problem ist – Edge Cases bei der Normalisierung verzerren das Training stillschweigend, und „die Belohnung ist Ground Truth“ ist nur so wahr wie dein Antwort-Extraktor.
• Die Sequenz-Log-Probability-Bewertung zu implementieren (mit der nötigen numerischen Stabilitäts-Akrobatik) hat die Hälfte der Loss-Funktionen in der Post-Training-Literatur entmystifiziert. Sie laufen alle darauf hinaus, zu vergleichen, wie wahrscheinlich Antworten unter verschiedenen Policies sind.
• Zuzusehen, wie die Antwortlänge bei GRPO ungefragt wächst, hat meine letzte Restüberzeugung getötet, Denkstil sei ein oberflächliches Verhalten. Es ist das, was Optimierung findet, wenn Korrektheit das einzige Ziel ist.
• Die Genauigkeit gegen die Anzahl der Kandidaten für Self-Consistency zu plotten, hat mir ein echtes Gefühl für den Trade-off aus Genauigkeit pro Dollar gegeben, das keine Benchmark-Tabelle je vermittelt hat.

Die Rechenangst ist für den Lernzweck außerdem übertrieben. Die frühen Teile – ein Basismodell laden, Streaming-Generierung mit KV-Caching, den Verifier bauen, MATH-500 laufen lassen – sind Laptop-Territorium oder nah dran. GRPO-Training braucht eine GPU, aber nur eine einzige, und stundenweise gemietet ist sie günstiger als die meisten Lehrbücher. Was du zu Hause nicht nachbauen kannst, ist Skala, und Skala ist wirklich eine eigene Disziplin. Das gehört zu den Mythen über DeepSeeks Inferenz-Engine, die wir überprüft haben: Der Serving-Stack eines Frontier-Labs löst Probleme, die auf Tutorial-Niveau schlicht nicht existieren, und umgekehrt.

Die praktische Schlussfolgerung

Wenn du nur eines mitnimmst, dann die verifier-zentrierte Sicht. Der moderne Reasoning-Stack besteht aus: einem Basismodell, einem Programm, das festlegt, was „korrekt“ bedeutet, einem RL-Algorithmus, der dagegen optimiert, und Inferenz-Techniken, die das Ergebnis multiplizieren. Prompting sitzt ganz am Rand dieses Systems und steuert eine Fähigkeit, die das Training geschaffen hat. Teams, die das verstehen, stecken ihren Aufwand dorthin, wo er sich aufzinst: in bessere Verifier, besseres Reward-Design und bessere Evaluationsschleifen, wie die, die unserer Meinung nach in den meisten KI-Benchmarks, die echte Arbeit verfehlen, fehlen. Teams, die das nicht verstehen, feilen weiter an System-Prompts und wundern sich, warum die Genauigkeit stagniert.

Meine Lunch-Table-These überlebt mit einer Einschränkung: Reasoning-Modelle werden trainiert, nicht geprompted – aber das Harness, das du um sie baust, Prompts eingeschlossen, bestimmt, wie viel von dieser trainierten Fähigkeit du tatsächlich ausschöpfst. Bau mal die kleine Version selbst. Elf Stunden Mitprogrammieren sind ein günstiger Preis dafür, nie wieder über diesen Punkt im Unklaren zu sein.