Test-Time Compute
Test-Time Compute (auch Inference-Time Compute genannt) ist die Praxis, ein LLM bei der Inferenz länger "nachdenken" zu lassen, also mehr Reasoning-Tokens zu erzeugen, mehrere Ketten zu durchlaufen oder viele Kandidaten auszuwählen und den besten zu wählen, um die Antwortqualität zu verbessern, ohne das Modell neu zu trainieren. Populär gemacht durch OpenAIs o1 und DeepSeek-R1 in den Jahren 2024 bis 2025, verlagerte es das Reasoning von einem Trainingsproblem zu einem Laufzeitregler.
Test-Time Compute (auch Inference-Time Compute genannt) ist die Praxis, ein LLM bei der Inferenz länger "nachdenken" zu lassen, also mehr Reasoning-Tokens zu erzeugen, mehrere Ketten zu durchlaufen oder viele Kandidaten auszuwählen und den besten zu wählen, um die Antwortqualität zu verbessern, ohne das Modell neu zu trainieren. Populär gemacht durch OpenAIs o1 und DeepSeek-R1 in den Jahren 2024 bis 2025, verlagerte es das Reasoning von einem Trainingsproblem zu einem Laufzeitregler.
Warum es wichtig ist
Während des größten Teils der LLM-Ära bestand die einzige Möglichkeit, ein Modell klüger zu machen, darin, ein größeres mit mehr Daten zu trainieren. Test-Time Compute durchbrach diese Abhängigkeit. OpenAIs o1 zeigte, dass dasselbe Basismodell, dem 10- bis 30-mal mehr Tokens zum Nachdenken vor dem Antworten gegeben wurden, deutlich größere Nicht-Reasoning-Modelle bei Mathematik-, Coding- und Logik-Benchmarks erreicht oder übertrifft. Das stellt Inferenzbudgets neu auf: Statt "nutze das größte Modell, das du dir leisten kannst", fragen Teams nun "wie viel Nachdenken möchte ich bei dieser Anfrage bezahlen?". Die Ökonomie des Reasonings verschob sich, und damit auch das Produktdesign, denn die Reasoning-Qualität ist nun auf Anfrageebene einstellbar.
Wie es funktioniert
Längere Chain-of-Thought: Das Modell gibt vor der sichtbaren Antwort Hunderte oder Tausende interner Reasoning-Tokens aus. Mehr Nachdenken -> bessere Antworten.
Mehrere Stichproben (Self-Consistency): N verschiedene Antworten erzeugen, jene wählen, zu der das Modell am häufigsten gelangt. Einfach und wirksam bei Mathematik.
Tree Search / Beam Search: Mehrere Reasoning-Zweige parallel erkunden, die schlechten beschneiden, die vielversprechenden erweitern.
Process Reward Models: Ein zweites Modell bewertet jeden Reasoning-Schritt und lenkt das Hauptmodell zu besseren Pfaden. Wird in OpenAIs Process Supervision eingesetzt.
Verifizierergeführte Suche: Viele Kandidaten erzeugen, einen externen Verifizierer ausführen (Unit-Tests, Mathematik-Prüfer, LLM-Bewerter), den besten zurückgeben.
Best-of-N + Rerank: Einfachere Variante. 16 bis 64 Kandidaten erzeugen, mit einem Belohnungsmodell neu ranken, den besten zurückgeben.
Der Kompromiss
Jede Test-Time-Compute-Technik erkauft Genauigkeit mit Latenz und Kosten:
Latenz: Eine Antwort, die ohne Reasoning 500 ms dauert, kann mit umfangreichem Test-Time Compute 5 bis 30 Sekunden dauern.
Kosten: Reasoning-Tokens kosten so viel wie alle anderen Ausgabe-Tokens. Eine o1-Antwort mit 10.000 Denk-Tokens kostet etwa das 30- bis 50-Fache einer einfachen GPT-4o-Antwort.
Abnehmende Erträge: Die Kurve aus Genauigkeit und Rechenaufwand flacht ab. Der Schritt von 1.000 auf 10.000 Reasoning-Tokens hilft mehr als der von 10.000 auf 100.000.
Nicht immer hilfreich: Einfache Faktenabfragen und freundlicher Smalltalk profitieren nicht vom Reasoning. o1 auf "wie ist das Wetter" zu zwingen, verschwendet Geld.
Wann man es einsetzt
Mathematik und formale Logik: Test-Time Compute hilft enorm. Reasoning-Modelle schlagen Basismodelle bei GSM8K, MATH, AIME um 20 bis 40 Punkte.
Codegenerierung mit Tests: Erzeugen, Tests ausführen, iterieren. Verifizierergeführte Suche glänzt.
Mehrstufige Planung: Agentenentscheidungen, komplexe Anweisungen, Optimierung unter mehreren Bedingungen.
Einzelanfragen mit hohem Einsatz: Medizin, Recht, Finanzen, wo 5 Sekunden und 0,30 US-Dollar für eine korrekte Antwort günstig sind im Vergleich zu den Kosten einer falschen.
Wann man es nicht einsetzt
Chat-UX unter 1-Sekunden-Budgets: Die Latenz ruiniert die Nutzererfahrung.
Volumen-Workloads: Eine Aufblähung der Tokens um das 20- bis 50-Fache macht jeden Endpunkt mit hohem Volumen unwirtschaftlich.
Einfacher Abruf oder Zusammenfassung: One-Shot-Antworten genügen; längeres Nachdenken hilft nicht.
Offenes kreatives Schreiben: Mehr Abwägen lässt die Ausgaben steif wirken.
Reasoning-Modelle vs reguläre Modelle
| Aspekt | Regulär (GPT-4o, Claude 3.5) | Reasoning (o1, R1, Claude Opus 4.6 thinking) |
|---|---|---|
| Antwortgeschwindigkeit | Schnell | Langsam |
| Token-Kosten | Niedrig | Hoch |
| Mathematik / Logik | Ordentlich | Hervorragend |
| Kreatives Schreiben | Stark | Mitunter steif |
| Chat-UX | Ideal | Überdimensioniert |
| Beste Verwendung | Die meisten Anfragen | Schwierige Anfragen |
Model Routing, also einfache Anfragen an ein schnelles Modell und schwierige Anfragen an ein Reasoning-Modell zu senden, ist das standardmäßige Produktionsmuster.
Häufige Fehler
Reasoning-Modelle überall einsetzen: Bläht Kosten und Latenz rasch auf, ohne die meisten Antworten zu verbessern.
Kein Budgetlimit für Denk-Tokens: Eine unbegrenzte Reasoning-Spur kann bei einer einzigen Anfrage Tausende Dollar verschlingen.
Caching ignorieren: Reasoning-Spuren sind oft repetitiv. Prompt Caching kann die Kosten erheblich senken.
Evaluierung überspringen: Teams nehmen an, Reasoning sei gleichbedeutend mit besser. Für ihre spezifische Domäne mag das nicht zutreffen, benchmarken Sie, bevor Sie sich festlegen.
Denk-Tokens mit der Ausgabe verwechseln: Nutzer sollten die Reasoning-Spur nicht sehen, es sei denn, sie fragen danach. Es ist ein innerer Monolog.
Sources: