⚡ LLMsID:
test-time-computeTest-Time Compute Scaling
推理时扩展
🎯Core Definition
Test-time compute scaling spends more compute at generation time to buy accuracy, orthogonal to training-time scaling laws. Main forms: ① thinking budgets — o1-style slow thinking that explicitly generates long CoTs; more allowed tokens → higher accuracy (an inference-time scaling law); ② sampling-and-selecting — Best-of-N with a reward model, or majority voting; ③ parallel search — MCTS with process rewards. Budgets are controlled via reasoning effort (low/medium/high) or max_tokens.
💡Use Cases
verifiable or scorable tasks like math and code; latency-tolerant high-stakes settings; API users tuning effort for cost-performance; and distilling searched high-quality trajectories back into small models via self-play.
⚡Key Problems Solved
"answer in one shot" is inaccurate on hard tasks; test-time compute shifts FLOPs from training to inference, boosting hard-task accuracy without retraining, along a compute-time tradeoff curve where error falls by a power law with diminishing returns.
🎯5 High-Frequency Exam Points
1
Main forms of test-time compute scaling, and how it differs from training-time scaling laws?
2
What is a thinking budget, and how does o1 control it via reasoning effort?
3
Best-of-N vs majority voting: differences and the signals each requires?
4
The diminishing-returns curve: where does it flatten, and which tasks benefit most?
5
How is test-time compute distilled back into small models (self-play/distillation)?
📖 In-depth Guide:📄 reasoning-and-cot →
Updated 2026-08-12🎯
🚀 Start Card Practice ➔Test Your Knowledge: Practice Questions for "Test-Time Compute Scaling"
Single choice pitfall questions with instant feedback and mistake tracking.