Wie man Computing-Budget zwischen Pre-Training, Fine-Tuning und Test-Time Compute aufteilt – und warum dieser Trade-off entscheidend ist
Fig. 1 |Sankey-Diagramm der Compute-Allokation. Die Breite der Flows zeigt den Prozentsatz des Compute-Budgets. Links wählen Sie zwischen 3 Szenarien.
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