Chain of Thought, RLVR und Test-Time Compute: gemessen

Die Versuchung ist groß zu sagen, die zweite Version habe „darüber nachgedacht“. Widersteh dem, denn der Mechanismus ist zugleich einfacher und nützlicher zu kennen.

Ein transformer führt pro generiertem token eine feste Menge an Berechnung aus. Ein forward pass: dieselben Schichten, dieselben Matrizen, dieselbe Anzahl an Operationen, egal ob die Frage was ist 2+2 lautet oder beweise diesen Satz. Es gibt im Modell keinen Regler für „bei dieser Aufgabe mehr anstrengen“.

Wenn ein Modell also sofort nach einer Antwort gefragt wird, besteht die gesamte verfügbare Berechnung aus einem forward pass. Jede Zwischengröße muss in die Aktivierungen dieses einen Durchlaufs passen, und alles, was es dort nicht berechnen kann, kann es nicht berechnen.

Tokens auszugeben ändert das, und zwar auf zwei getrennte Arten, die man auseinanderhalten sollte:

• Mehr Berechnung. Jedes generierte token ist ein weiterer vollständiger forward pass. Hundertfünfundvierzig tokens an Arbeit entsprechen hundertfünfundvierzigmal so viel Arithmetik wie eine direkte Antwort.
• Externalisierter Speicher. Die tokens werden in den context geschrieben, sodass der nächste Durchlauf sie lesen kann. 5 × 13 = 65 wird zu einer Tatsache im Input, nicht zu einem Wert, den das Modell in einer Aktivierung halten und weitertragen muss. Das Modell nutzt seine eigene Ausgabe als Notizblock.

Diesen zweiten Punkt übersehen viele, und er erklärt, warum die Arbeit aufgeschrieben werden muss, damit sie hilft. Ein Modell, das aufgefordert wird, „still darüber nachzudenken und dann zu antworten“, hat keinen Ort, an dem es den Gedanken ablegen kann.

Nichts davon erfordert Mystik, und es liefert eine klare Vorhersage: Chain of Thought sollte am meisten bei Problemen mit serieller Struktur helfen — bei denen Schritt zwei das Ergebnis von Schritt eins braucht — und am wenigsten bei Problemen, die nur ein einzelner Abruf sind. Genau das findet die Literatur, und deshalb bringt „think step by step“ bei was ist die Hauptstadt von Frankreich nichts.

Die Technik kam 2022 in zwei Teilen. Wei et al. zeigten, dass ausgearbeitete Beispiele im prompt — Demonstrationen, bei denen der Antwort eine Begründung vorausgeht — große Gewinne bei arithmetischen und Alltagslogik-Benchmarks brachten.¹ Kojima et al. zeigten dann etwas Merkwürdigeres: Man braucht die Beispiele nicht. Hängt man „Let's think step by step“ an einen Zero-Shot-prompt an, erhält man einen großen Teil desselben Gewinns.²

Das zweite Ergebnis verrät, was passiert. Wenn eine magische Formulierung das Verhalten freischaltet, war das Verhalten bereits im Modell — Pretraining ist voller ausgearbeiteter Lösungen, und die Formulierung ist ein Zeiger auf diese Region der Verteilung. Chain of Thought hat dem Modell nichts beigebracht. Es hat etwas ausgewählt, das das Modell bereits hatte.

Diese Sicht sagt auch die spätere Obsoleszenz der Technik voraus, auf die wir am Ende des Kapitels zurückkommen.

Der naheliegende nächste Schritt: Wenn eine Begründungskette falsch sein kann, sample mehrere und nimm die Mehrheitsantwort. Das ist self-consistency.³ Es ist ein strikt größerer Aufwand — $n$ vollständige Generierungen statt einer — und die Intuition ist, dass falsche Antworten streuen, während richtige übereinstimmen.

Gemessen an 16 derselben Aufgaben, sampling bei temperature 0,8, Mehrheitsentscheid über $n$ Ketten:

Sechzehn Aufgaben sind ein kleiner Nenner, und die Regel aus Kapitel 4 gilt für diese Tabelle genauso wie für jede andere. 13 von 16 sind 81 % mit einem 95-%-Wilson-Intervall von [57, 93]; 16 von 16 sind 100 % mit [81, 100]. Diese überlappen. Lies die Form der Kurve — das ist die Erkenntnis; lies nicht die exakte Stufe, an der sie flach wird, denn sechzehn Aufgaben können sie nicht lokalisieren.

Zwei Dinge in dieser Tabelle, und das zweite ist nicht das, was ich erwartet hatte.

Die Kurve wird bei $n = 3$ flach. Beim dritten Sample ist die Genauigkeit an der Decke, und die übrigen zwei Samples kaufen nichts mehr, kosten aber je 172 tokens, zusammen 345. Das ist die Form jeder self-consistency-Kurve, die in der Literatur berichtet wird, und sie tritt viel früher ein, als das „mehr Samples ist mehr besser“-Framing vermuten lässt.

Und greedy decoding lag bereits bei 100 %. Schau zurück an den Anfang des Kapitels: eine Kette, kein sampling, 145 tokens, 24/24. Sampling bei temperature 0,8 senkte die Genauigkeit auf 81 %, und self-consistency brauchte drei Generierungen, um wieder dorthin zu kommen, wo ein einzelner greedy pass bereits war — bei 3,6-mal so vielen tokens, oder sechsmal so vielen, wenn du den Sweep bis fünf laufen lässt, ohne zu wissen, wo die Kurve flach wird.

Das ist kein Argument gegen self-consistency. Es ist eine präzise Beschreibung dessen, was sie tut: temperature kauft Vielfalt, indem sie Fehler einspeist, und Voting entfernt die Fehler, die sie gerade eingespeist hat. Bei Problemen, bei denen greedy decoding scheitert — bei denen die wahrscheinlichste einzelne Kette irgendwo falsch abbiegt und eine weniger wahrscheinliche richtig ist — lohnt sich dieser Tausch, und deshalb gibt es die Technik. Bei Problemen, bei denen greedy bereits erfolgreich ist, ist sie ein Weg, das Sechsfache des Budgets auszugeben, um am Ende gerade wieder gleichzuziehen.

Den zweiten Fall veröffentlicht niemand, und genau deshalb lohnt es sich, ihn auf deiner eigenen Aufgabe zu messen, bevor du die Technik übernimmst. Das hier sind einfache Zwei-Schritt-Aufgaben für ein kleines Modell; das ist das Regime, in dem die Antwort so ausfällt.

Alles bisher passiert zur prompt-Zeit auf einem Modell, das dafür nie gezielt trainiert wurde. Der Schritt, der die aktuelle Generation von Reasoning-Modellen hervorgebracht hat, bestand darin, es ins Training zu verschieben — und der Schlüssel, der das möglich machte, ist enger, als er klingt.

Das Post-Training aus Kapitel 11 brauchte menschliche Präferenzen, weil es auf „war das eine gute Antwort?“ keine programmatische Antwort gibt. Bei manchen Fragen gibt es sie aber. Eine mathematische Antwort entspricht entweder dem richtigen Wert oder nicht. Code besteht die Tests oder nicht. Ein Beweis checkt oder nicht.

Für diese Domains kannst du das Reward Model durch einen Verifier ersetzen, und alles dahinter wird auf einmal besser: keine Annotatoren, kein Bradley-Terry-Fitting, kein Reward Hacking der Art, wie es in Kapitel 11 gemessen wurde — denn einem Unit Test kann man nicht schmeicheln. Das ist reinforcement learning from verifiable rewards, und es ist das Setting, für das GRPO gebaut wurde: sample eine Gruppe von Lösungsversuchen für dasselbe Problem, prüfe jeden einzelnen und nutze den Mittelwert der Gruppe als Baseline. Kein Critic, kein Annotator, kein Reward Model. Nur ein Programm, das richtig oder falsch sagt.

Das Ergebnis, das das Feld neu gerahmt hat, kam Anfang 2025 von DeepSeek.⁶ Sie nahmen ein Basismodell und wandten reinforcement learning mit verifiable rewards direkt an, ohne vorherige supervised fine-tuning-Phase — die Phase, die Kapitel 11 als Grundlage von allem darstellt. Lange Reasoning-Ketten entstanden trotzdem. Ebenso Verhaltensweisen, für die niemand trainiert hatte: Das Modell begann, seine eigenen Schritte erneut zu prüfen und, in der meistzitierten Passage des Papers, mitten in der Lösung spontan einen Ansatz zu überdenken.

Die ehrliche Lesart ist nicht, dass Reasoning Magie ist. Sie ist: Wenn das Einzige, was belohnt wird, richtig zu sein ist, und bei einem schweren Problem richtig zu sein erfordert, es durchzuarbeiten, dann findet der Optimierer genau dieses Durcharbeiten — einschließlich jener Teile des Durcharbeitens, die auch Menschen tun, weil sie durch das Problem erfordert werden und nicht, weil irgendwer sie beigebracht hat.

Die praktische Konsequenz all dessen ist, dass ein Reasoning-Modell tokens produziert, die du angefordert hast, und tokens, die du nicht angefordert hast — und du bezahlst für beide.

Provider behandeln das unterschiedlich, und der Unterschied ist wichtig:

• Die meisten APIs zählen Reasoning-tokens innerhalb der Output-token-Anzahl. Deine Rechnung und dein max_tokens-Limit enthalten beide das Denken, das du nie siehst.
• Googles Gemini meldet thinking tokens als separates Feld außerhalb der normalen Output-Zählung.

Das ist eine echte Inkompatibilität zwischen zwei Arten, dieselbe Sache zu zählen, und jeder Code, der Kosten berechnet oder ein Budget über Provider hinweg durchsetzt, muss sie normalisieren. Kapitel 16 ist der Punkt, an dem daraus Geld wird, und Kapitel 23 der Punkt, an dem daraus ein Budget wird, das du durchsetzen kannst.

Die andere Konsequenz ist eine Latenz-Konsequenz, die Leute beim ersten Mal überrascht. Die Zeit bis zum ersten sichtbaren token eines Reasoning-Modells enthält all sein Denken. Eine Anfrage, die acht Sekunden lang nichts streamt und dann in einer Sekunde antwortet, ist also keine hängende Verbindung — das Modell arbeitet. Jede Oberfläche, die acht Sekunden lang einen Spinner ohne Erklärung zeigt, hat ein Designproblem, kein Netzwerkproblem.

Eine abschließende Warnung, weil dieses Material am häufigsten genau so falsch angewendet wird.

Alles in der ersten Hälfte ist eine Technik, um ein Modell, das nicht fürs Reasoning trainiert wurde, trotzdem Reasoning produzieren zu lassen. Mit RLVR trainierte Modelle tun das bereits: Sie geben ihre eigene Arbeitskette in ihrer eigenen Länge aus, bevor sie antworten. Ein solches Modell aufzufordern, step by step zu denken, ist bestenfalls redundant und schlimmstenfalls schädlich — es kann eine kurze, prompt-förmige Kette anstelle der längeren erzeugen, die das Modell von selbst generiert hätte, und manche Provider dokumentieren genau das.

Dasselbe gilt für aufwendige Reasoning-Gerüste, die im Anwendungscode gebaut werden. Ein prompt, der ein Modell durch einen Entscheidungsbaum führt, den es intern bereits navigiert, gibt deine tokens dafür aus, ein Verhalten zu beschränken, das antrainiert wurde. Das ist das erste Auftreten eines Themas, das sich durch den Rest des Kurses zieht: Techniken, die 2022 unverzichtbar waren, wurden 2025 zu Aberglauben, und der einzige Weg, für dein Modell heute zu erkennen, was was ist, besteht darin, beides zu messen.

Kapitel 15 ist der Punkt, an dem diese Messung zu einer Disziplin statt zu einer Meinung wird.

Reasoning hat eine unbequeme Eigenschaft: Es ist die eine Fähigkeit, deren Kosten damit skalieren, wie schwer die Frage ist. Ein Modell, das neunhundert tokens lang denkt, macht neunhundert forward passes, hält für alle einen wachsenden Cache im Speicher und belegt für die Dauer eine GPU.

Das macht die Ökonomie des Betriebs eines Reasoning-Modells deutlich schlechter als die eines Chat-Modells, und es macht aus einer Reihe von Implementierungsdetails den Unterschied zwischen einem tragfähigen und einem nicht tragfähigen Produkt: wie der Cache vergangener Keys und Values gespeichert und wiederverwendet wird, wie viele Anfragen sich einen forward pass teilen können und wie viel Präzision die Gewichte tatsächlich brauchen.

Kapitel 13 ist das letzte Kapitel, in dem das Modell ein Objekt in deinem Speicher ist statt ein Service hinter einem Port, und es geht darum, dieses Objekt günstig genug für den Betrieb zu machen. Es löst außerdem ein Versprechen aus diesem Kapitel ein: speculative decoding, das mehrere tokens ungefähr zum Preis eines einzigen produziert, indem ein kleines Modell rät und ein großes prüft — ein Trick, der erst Sinn ergibt, wenn du gesehen hast, wie viel eines forward pass damit verbracht wird, auf Speicher zu warten, statt Arithmetik auszuführen.

Alle Messungen in diesem Kapitel stammen aus Qwen/Qwen2.5-0.5B-Instruct mit 24 generierten Textaufgaben mit zwei Schritten, greedy decoding außer dort, wo sampling angegeben ist, und null abgeschnittenen Generierungen bei den verwendeten token-Caps. Sie sind reproduzierbar, und sie betreffen ein kleines Modell auf einfachen Aufgaben: Lies das self-consistency-Ergebnis als Demonstration des Mechanismus, nicht als Benchmark. Kapitel 18 der CS229 Lecture Notes und Kapitel 12 des Hugging Face LLM Course behandeln dieses Material mit größeren Modellen und richtigen Benchmarks.