KAPITEL 3.4 · TEST-TIME COMPUTE

Compute-Allokation Strategien

Wie man Computing-Budget zwischen Pre-Training, Fine-Tuning und Test-Time Compute aufteilt – und warum dieser Trade-off entscheidend ist

Compute-Allokation: Wie verteilt man ein festes Compute-Budget optimal? Pre-Training, Fine-Tuning und Inference konkurrieren um Ressourcen. Die optimale Balance verschiebt sich zugunsten von Test-Time Compute.

📖 Lern-Kontext ▼
🎯

Lernziele

  • Compute-Budget-Aufteilung verstehen
  • Trade-offs zwischen Phasen kennen
  • Moderne Allokations-Trends erkennen
🗺️

Kontext: Wo sind wir?

Schritt 3/5 Reasoning & Test-Time Compute

Die ökonomische Perspektive auf Test-Time Scaling.

💡

Warum wichtig

2022: 90% Pre-Training, 10% Rest. 2025: 60% Pre-Training, 20% Fine-Tuning, 20% Inference. Der Trend geht zu mehr Inference-Compute — das verändert die ML-Ökonomie.

📌

Key Takeaways

  • Shift: Mehr Budget für Inference statt Training
  • Chinchilla: Ursprüngliche Regel galt nur für Pre-Training
  • Flexibilität: Inference-Compute kann pro Query skaliert werden
Fig. 1 | Sankey-Diagramm der Compute-Allokation. Die Breite der Flows zeigt den Prozentsatz des Compute-Budgets. Links kannst du zwischen 3 Szenarien wählen.

Drei Allokations-Strategien

Schlüssel-Erkenntnisse

1
Die Chinchilla Frage: Historisch war die Weisheit "Skaliere Parameter und Daten gleich". Aber Snell et al. (2024) zeigen: Mit Test-Time Compute kann man von dieser Regel abweichen.
2
Pre-Training ist die Basis: Ohne gutes Pre-Training hilft Test-Time Compute nicht. Man braucht ein grundsätzlich kompetentes Modell. Minimum ~70% des Budgets sollten in Pre-Training gehen.
3
Fine-Tuning ist optional: Moderne Forschung zeigt: In-Context Learning (Few-Shot) ist oft besser als Fine-Tuning. Man kann Fine-Tuning ganz weglassen und stattdessen Pre-Training oder Test-Time verstärken.
4
Test-Time Leverage: Mit 20% des Budgets auf Test-Time (Best-of-N, Reasoning, Verification) kann man Performance eines 14× größeren Modells erreichen. Dies ist die neueste Entdeckung aus o1/o3 Forschung.
5
Aufgabenabhängig: Der optimale Split hängt ab vom Aufgabentyp. Für Factual QA: Pre-Training Heavy. Für Reasoning: Test-Time Heavy. Für Language Generation: Balanced.
6
Praktische Implikation: Bei großen Unternehmen werden Modelle oft Pre-Trained in Batches, dann SFT/RLHF einmal, dann für verschiedene Tasks mit unterschiedlichen Test-Time Budgets deployed. Dies erlaubt Flexibilität ohne Retraining.

Mathematischer Hintergrund

Total Compute Budget = C

Allocation:
C_pre = α × C (Pre-Training)
C_ft = β × C (Fine-Tuning)
C_test = (1-α-β) × C (Test-Time)

Snell et al. Finding:
Optimal Performance ∝ C_pre^0.5 × C_test^0.5

Not: C_pre^1 (which was previously assumed)