Test-Time Compute

Test-Time Compute bezeichnet die Rechenzeit, die ein Sprachmodell für eine einzelne Anfrage aufwendet (also beim Beantworten, nicht beim Training), sowie den Hebel, diese Rechenzeit gezielt zu erhöhen, um bessere Antworten zu bekommen. [Snell et al. 2024](https://arxiv.org/abs/2408.03314) zeigten: Ein kleines Modell mit mehr Rechenzeit pro Anfrage kann bei gleicher Genauigkeit insgesamt weniger Rechenleistung verbrauchen als ein deutlich größeres Modell ohne diesen Hebel.

Was ist Test-Time Compute?

Der Begriff hat zwei Bedeutungen, die zusammengehören. Erstens meint Test-Time Compute die Ressource: die Rechenzeit, die das Modell pro Anfrage aufwendet, wenn es antwortet (Inferenz). Gemessen wird sie in Tokens (den Wort-Bausteinen, die das Modell erzeugt), in FLOPs (Fließkomma-Rechenoperationen als Maß für Rechenaufwand) oder schlicht in Sekunden bis zur fertigen Antwort. Zweitens meint der Begriff den Hebel: das Modell rechnet bewusst länger als bei einem einfachen Standardaufruf, um eine bessere Antwort zu liefern. Beide Lesarten treten in der Literatur nebeneinander auf, meist ergibt sich die Bedeutung aus dem Kontext.

Der Hebel lässt sich in mehreren Formen realisieren. Längere Chain-of-Thought-Traces sind die einfachste Variante: Das Modell schreibt mehr Zwischenschritte, bevor es antwortet. Multi-Sample-Voting nach [Wang et al. 2022](https://arxiv.org/abs/2203.11171) zieht n unabhängige Samples mit Temperature größer null und bildet einen Mehrheitsentscheid über die Endantwort (Self-Consistency). Best-of-N mit Reward-Modell zieht ebenfalls n Samples, wählt den besten Kandidaten aber über ein separates Bewertungsmodell aus. Tree-of-Thoughts ([Yao et al. 2023](https://arxiv.org/abs/2305.10601)) erweitert die Suche zu einem Baum verzweigter Reasoning-Pfade mit expliziter Bewertung und Backtracking. Deliberation-Loops in Reasoning Models wie OpenAI o1/o3, DeepSeek R1 und Claude Extended Thinking führen im internen Reasoning-Trace Reflexions- und Verifikations-Schritte aus.

Die empirische Grundlage lieferten Snell et al. 2024. Die Autoren verglichen bei gleicher Aufgabengüte auf dem MATH-Benchmark den Aufwand zweier Wege: mehr Test-Time Compute an einem kleineren Modell versus Training eines größeren Modells. Für einen Teil des Aufgaben-Spektrums verbrauchte der erste Weg weniger Gesamt-Compute. Die o1-Vorstellung von OpenAI im September 2024 machte den Hebel als eigene Skalierungs-Achse öffentlich sichtbar. Der Zugewinn skaliert log-linear und nutzt sich bei einfachen Aufgaben schnell ab; die Wirkung ist bei mathematischen, logischen und codenahen Aufgaben am größten.

Im Betrieb wird der Hebel unterschiedlich gesteuert. Reasoning Models exponieren ihn direkt über API-Parameter: OpenAI o1/o3/o4 kennen reasoning_effort in den Stufen low, medium, high, Anthropic verwendet ein explizites budget_tokens, Google Gemini 2.5 ein Thinking-Budget. Standard-LLMs bekommen den Hebel über Anwendungs-Logik: parallele Aufrufe für Self-Consistency, Best-of-N mit externem Reward-Modell, mehrstufige Prompt-Chains. Kostenseitig werden Reasoning-Tokens abgerechnet, auch wenn sie beim Nutzer nicht ausgeliefert werden. Eine einzelne Anfrage kann zwischen 5.000 und 100.000 Reasoning-Tokens verbrauchen; Latenzen verschieben sich vom Millisekunden- in den Sekunden- bis Minutenbereich.

Abgrenzung zu Training Compute, Reasoning Models, Chain-of-Thought und Model Scaling

Test-Time Compute wird häufig mit angrenzenden Konzepten vermischt. Die relevanten Trennlinien:

Training Compute bezeichnet die Rechenzeit, die einmalig beim Modell-Training aufgewendet wird: Pretraining auf großen Web-Corpora, Supervised Fine-Tuning und Reinforcement Learning im Post-Training. Test-Time Compute ist die Rechenzeit pro Anfrage bei der Inferenz. Beide Achsen ergänzen sich. Snell et al. 2024 vergleichen ihren Ertrag direkt: für einen Teil des Aufgaben-Spektrums lohnt sich zusätzliche Test-Time-Compute-Investition an einem kleinen Modell mehr als das Training eines proportional größeren. Für andere Aufgaben-Klassen (Sprachverständnis, Weltwissen) bleibt Pretraining-Scaling überlegen.

[Reasoning Models](/insights/glossar/reasoning-models/) sind die Modell-Klasse, die den Test-Time-Compute-Hebel systematisch nutzt. Die OpenAI-o-Serie, DeepSeek R1, Anthropic Claude 3.7 Sonnet und Claude 4 Opus mit Extended Thinking sowie Google Gemini 2.5 mit Thinking wurden per Reinforcement Learning auf Reasoning-Traces darauf trainiert, den Hebel zu nutzen. Test-Time Compute selbst ist der Hebel, unabhängig von der Modell-Klasse. Auch ein Standard-LLM wie GPT-4o oder Llama 3 kann den Hebel über Self-Consistency oder Best-of-N nutzen; die Trace-Qualität eines RL-trainierten Reasoning Models erreicht der Standard-Aufruf ohne dieses Training nicht.

[Chain-of-Thought Prompting](/insights/glossar/chain-of-thought/) ist eine konkrete Technik, die den Hebel nutzt. Das Modell formuliert Zwischenschritte aus und verbraucht damit mehr Test-Time Compute als eine direkte Antwort. Test-Time Compute ist der Oberbegriff über alle Verfahren, die die Inferenz-Rechenzeit erhöhen. Chain-of-Thought ist eines davon; daneben stehen [Self-Consistency](/insights/glossar/self-consistency/), Best-of-N-Sampling, Tree-of-Thoughts und interne Deliberation-Loops. Wer den Hebel diskutiert, meint das Konzept; wer Chain-of-Thought diskutiert, meint eine spezifische Umsetzung.

Model Scaling erhöht Parameterzahl (7B → 70B → 400B) oder Trainings-Tokens. Test-Time Compute lässt beide Größen unverändert und erhöht nur den Inferenz-Aufwand. Die zwei Achsen sind orthogonal. Ein 70B-Reasoning-Modell mit hohem Reasoning-Effort kann ein 400B-Standard-Modell bei mathematischen Aufgaben schlagen; ein 400B-Standard-Modell schlägt ein 7B-Modell mit maximalem Test-Time Compute bei allgemeinem Weltwissen. Die richtige Achse hängt von der Aufgaben-Klasse ab.

Latency ist die Wallclock-Zeit zwischen Anfrage und Antwort. Test-Time Compute ist die Rechenmenge dahinter. Ein Voice-Agent kann durch parallele Sample-Aufrufe (Self-Consistency mit n = 5) den Test-Time Compute erhöhen, ohne die Wallclock-Latenz linear zu erhöhen, weil die Samples parallel laufen. Ein langer serieller Reasoning-Trace erhöht beides zugleich. Die Betriebs-Entscheidung trennt die zwei Metriken sauber.

Beispiel: MATH-Benchmark und SQL-Review

Der kanonische Fall aus dem Snell-Paper ist die Skalierung eines kleinen Modells auf dem MATH-Benchmark. Ein Modell der Llama-Größenordnung wird mit deutlich erhöhtem Test-Time Compute betrieben: Multi-Sample-Voting mit n gleich 64, längere Chain-of-Thought-Traces und Best-of-N mit einem Reward-Modell. Bei einem Teil der Aufgaben erreicht das kleine Modell die Genauigkeit eines 14× größeren Basismodells ohne den Hebel. Der Gesamt-Compute-Vergleich fällt für die Autoren zugunsten der Test-Time-Compute-Skalierung aus, weil das Training des großen Modells den Vergleich dominiert.

Im Betrieb zeigt sich der gleiche Mechanismus bei einem SQL-Review-System, das Queries mit potenziell teuren Joins prüft. Ein Aufruf gegen Claude Sonnet ohne Thinking antwortet in etwa zwei Sekunden mit Oberflächen-Feedback. Derselbe Aufruf gegen Claude 3.7 Sonnet mit budget_tokens=16000 oder gegen OpenAI o3 mit reasoning_effort=high braucht 30 bis 90 Sekunden, verbraucht 20.000 bis 60.000 Reasoning-Tokens und findet Fehlerklassen wie fehlende Prädikate, kartesische Produkte und Skew-Muster, die der Standard-Aufruf übersieht. Die Betriebs-Entscheidung wählt den Hebel pro Aufgaben-Klasse: Latenz-kritische Antworten in Voice-Agenten oder IDE-Autocomplete bleiben ohne erhöhten Test-Time Compute, komplexe Analyse-Aufgaben wie Code-Audit, Financial Modeling oder wissenschaftliches Question-Answering nutzen ihn.