Scaling

Test-Time Compute: Spending Inference Budget on Search

Test-time compute spends extra inference budget on sampling, verification, and selection; it helps when the generator can produce good candidates and the verifier ranks them reliably.

status: reviewimportance: importantdifficulty 4/5math: undergraduateread: 22mlive demo

Back to Scaling Next: Tree Search Reasoning: Allocating Inference Budget Across Prefixes

Editorial scaling illustration of branching candidate traces scored by verifier gauges and selected through a budgeted funnel.

Concept Structure

Test-Time Compute: Spending Inference Budget on Search

01Intuition

Start with the picture, metaphor, or geometric mechanism.

02Math

Make the objects explicit and connect them with notation.

03Code

Mirror the equations with runnable implementation details.

04Interactive Demo

Manipulate the mechanism and watch the idea respond.

4prerequisites

1next concepts

4related links

Learning map

Test-Time Compute: Spending Inference Budget on Search

BeforeScaling Laws & Emergent AbilitiesNow4/4 sections readyTryManipulate one control and predict the visible change.NextTree Search Reasoning: Allocating Inference Budget Across Prefixes

Object flow

4/4 sections readyAsk about this Research room

ConceptTest-Time Compute: Spending Inference Budget on SearchScaling EquationTest-Time Compute: Spending Inference Budget on Search equation 1Exact equation object CodeTest-Time Compute: Spending Inference Budget on Search code witness 1Exact code witness DemoTest-Time Compute: Spending Inference Budget on Search interactive demoVisualization object ClaimIn the page's finite best-of-N model, extra test-time compute can imp...Exact claim check SourceSelf-Consistency Improves Chain of Thought Reasoning in Language ModelsExact source object

ConceptTest-Time Compute: Spending Inference Budget on SearchScaling

3 sources attachedLocal snapshot ready

concept:scaling/test-time-compute

Codewitness nearby Predictbefore reveal Roomobject handoff

Conceptual Bridge

What should feel connected as you move through this page.

Carry inScaling Laws & Emergent Abilities

Bring the mental model from Scaling Laws & Emergent Abilities; this page will reuse it instead of restarting from zero.

Work hereTest-Time Compute: Spending Inference Budget on Search

Test-time compute spends extra inference budget on sampling, verification, and selection; it helps when the generator can produce good candidates and the verifier ranks them reliably.

Carry outTree Search Reasoning: Allocating Inference Budget Across Prefixes

The next edge should feel earned: use the demo prediction here before following Tree Search Reasoning: Allocating Inference Budget Across Prefixes.

Test the linkManipulate one control and predict the visible change.Then continue to Tree Search Reasoning: Allocating Inference Budget Across Prefixes

01IntuitionStart with the picture, metaphor, or geometric mechanism.02MathMake the objects explicit and connect them with notation.03CodeMirror the equations with runnable implementation details.04Interactive DemoManipulate the mechanism and watch the idea respond.

Intuition

Build the mental picture first so the rest of the page has something to attach to.

Section prompt

Canonical sources: Kaplan et al., "Scaling Laws for Neural Language Models", Hoffmann et al., "Training Compute-Optimal Large Language Models", Cobbe et al., "Training Verifiers to Solve Math Word Problems", Uesato et al., "Solving Math Word Problems With Process- and Outcome-Based Feedback", Lightman et al., "Let's Verify Step by Step", Brown et al., "Large Language Monkeys: Scaling Inference Compute with Repeated Sampling", Wang et al., "Self-Consistency Improves Chain of Thought Reasoning in Language Models", and Snell et al., "Scaling LLM Test-Time Compute Optimally can be More Effective than Scaling Model Parameters".

Training-time scaling spends more compute before deployment: more parameters, more data, longer training.

Test-time scaling spends more compute after the prompt arrives. In this page, that means sampling more complete candidate traces and scoring them with a verifier.

Here "search" means parallel best-of- $N$ over complete traces, not prefix expansion or tree search.

This page focuses on the smallest useful case: best-of- $N$ with a verifier. For one prompt, the model samples $N$ complete candidate traces. A verifier scores each trace. The system returns the highest-scoring sampled trace.

For this finite best-of- $N$ verifier setup, extra inference compute is useful only when two conditions are both true:

the generator sometimes samples a good trace,
the verifier tends to rank good traces above bad ones.

If the good trace is almost never sampled, extra compute may not be enough. If the verifier has a false-positive trap, more samples can make the system worse by making that trap more likely to appear. The honest question is not "does thinking longer help?" It is: for this prompt, generator, verifier, and cost model, is another sample worth buying?

Math

Translate the story into symbols, assumptions, and a derivation you can inspect.

Section prompt

Equation 1p_i=\pi_{\mathrm{base}}(\tau_i\mid x), \qquad \sum_i p_i=1, \qquad u_i\in\{0,1\}, \qquad s_i=...Equation 2\tau^\star = \arg\max_{\tau\in\{\tau^{(1)},\dots,\tau^{(N)}\}} s_\phi(\tau); F_k = \sum_{i=1}...

For one prompt $x$ , let the base model define a finite distribution over complete candidate traces. Each trace has hidden task correctness and a verifier score:

p_i=\pi_{\mathrm{base}}(\tau_i\mid x), \qquad \sum_i p_i=1, \qquad u_i\in\{0,1\}, \qquad s_i=s_\phi(\tau_i).

Best-of- $N$ draws $N$ independent traces from $p$ and returns the sampled trace with the highest verifier score. Assume verifier scores are distinct and sort traces from lowest to highest verifier score, so $s_1 < \cdots < s_K$ :

\begin{aligned} \tau^\star &= \arg\max_{\tau\in\{\tau^{(1)},\dots,\tau^{(N)}\}} s_\phi(\tau),\\ F_k &= \sum_{i=1}^k p_i,\qquad F_0=0,\\ P_N(k\ \mathrm{selected}) &= F_k^N-F_{k-1}^N,\\ A(N) &= \sum_k u_k \left(F_k^N-F_{k-1}^N\right),\\ \mathrm{coverage}_N &= 1-\left(1-\sum_i p_i u_i\right)^N. \end{aligned}

To connect back to process reward models, a trace score might be an additive step score:

s_\phi(\tau_i) = \sum_{t=1}^{T_i} r_\phi(h_{i,t-1},a_{i,t}).

Treat this as a ranking score, not a calibrated probability of correctness. Sum-vs-mean aggregation, length normalization, and distribution shift can all change which traces receive high verifier score.

The expected selected verifier score is

S(N) = \sum_k s_k \left(F_k^N-F_{k-1}^N\right).

Selected correctness and sampled-correct coverage can be very different. Sampling a correct trace is coverage. Returning it is selection. More samples can make $S(N)$ rise while $A(N)$ falls if the highest-scoring trace is a verifier error.

A simple cost model is

C(N)=N(c_{\mathrm{gen}}+c_{\mathrm{score}}).

Here $N$ is only a teaching proxy for inference budget. Real serving cost also depends on generation length, verifier cost, batching, latency, and traffic volume.

Code

Keep the implementation aligned with the notation so the algorithm is legible.

Section prompt

Code witness 1def selected_distribution(candidates, n): ranked = sorted(candidates, key=lambda item: item["...python

This witness uses the same finite best-of- $N$ object as the demo. With a clean verifier, more samples improve selected correctness. With a noisy verifier, selected verifier score improves while true correctness eventually falls.

def selected_distribution(candidates, n):
    ranked = sorted(candidates, key=lambda item: item["score"])
    cumulative = 0.0
    selected = {}
    for item in ranked:
        p = item["prior"]
        next_cumulative = cumulative + p
        selected[item["id"]] = next_cumulative ** n - cumulative ** n
        cumulative = next_cumulative
    return selected

def expected(candidates, selected, key):
    return sum(selected[item["id"]] * item[key] for item in candidates)

def scored(candidates, mode):
    return [{**item, "score": item[f"{mode}_score"]} for item in candidates]

def expected_accuracy(candidates, n, mode):
    rows = scored(candidates, mode)
    return expected(rows, selected_distribution(rows, n), "correct")

def expected_score(candidates, n, mode):
    rows = scored(candidates, mode)
    return expected(rows, selected_distribution(rows, n), "score")

candidates = [
    {"id": "common_wrong", "prior": 0.50, "correct": 0, "clean_score": -2.0, "noisy_score": -2.0},
    {"id": "plausible_slip", "prior": 0.25, "correct": 0, "clean_score": -0.3, "noisy_score": -0.3},
    {"id": "clean_correct", "prior": 0.18, "correct": 1, "clean_score": 1.8, "noisy_score": 1.8},
    {"id": "rare_exploit", "prior": 0.07, "correct": 0, "clean_score": 0.2, "noisy_score": 2.6},
]

clean_1 = expected_accuracy(candidates, 1, "clean")
clean_32 = expected_accuracy(candidates, 32, "clean")
noisy_1 = expected_accuracy(candidates, 1, "noisy")
noisy_64 = expected_accuracy(candidates, 64, "noisy")

assert clean_32 > clean_1
assert noisy_64 < noisy_1
assert expected_score(candidates, 64, "noisy") > expected_score(candidates, 1, "noisy")
print(round(clean_32, 3), round(noisy_64, 3))

Interactive Demo

Use direct manipulation to connect the explanation to a moving system.

Section prompt

Use the demo to compare a clean verifier against a noisy verifier on the same four traces. Increase $N$ to spend more inference compute. Watch the gap between "sampled at least one correct trace" and "selected a correct trace"; that gap is where verifier quality matters.

Live Concept Demo

Explore Test-Time Compute: Spending Inference Budget on Search

The stage is code-native and interactive. Use it to test the explanation against the mechanism.

difficulty 4/5undergraduatecode-aligned

Demo Prediction Checkpoint

Manipulate one control and predict the visible change.

Commit to what Test-Time Compute: Spending Inference Budget on Search should make visible before reading the result.

After The First Pass

Turn the concept into an inspected object.

Once the invariant is visible in the intuition, math, code, and demo, use these panels to inspect the mechanism visually, check source support, practice the idea, and attach a grounded research question.

Mechanism Storyboard

See the idea move before the page explains it

Test-time compute spends extra inference budget on sampling, verification, and selection; it helps when the generator can produce good candidates and the verifier ranks them reliably.

Prediction open01 / Intuition

Prediction lens

Start with the picture, metaphor, or geometric mechanism.

Commit first

Before reading further, choose the kind of change Test-Time Compute: Spending Inference Budget on Search should make visible.

Visual Inquiry

Make the image answer a mathematical question

Test-time compute spends extra inference budget on sampling, verification, and selection; it helps when the generator can produce good candidates and the verifier ranks them reliably.

4/4 stages readyLive demo connected

Visual cueWhich visible object should carry the first intuition?

Inspection depth2/4

Prediction

Which visible object should carry the first intuition?

Commit first

Pick the cue that should make Test-Time Compute: Spending Inference Budget on Search easier to reason about before the page gives the answer.

Source Grounding

Canonical references for the mechanism on this page.

paper · 2022Self-Consistency Improves Chain of Thought Reasoning in Language ModelsWang et al.

Grounds repeated sampling and answer aggregation as a simple way to spend more inference compute.

Open source

paper · 2023Let's Verify Step by StepLightman et al.

Grounds process-supervised reward models as learned verifiers evaluated by best-of-N selection over sampled reasoning solutions.

Open source

paper · 2024Scaling LLM Test-Time Compute Optimally can be More Effective than Scaling Model ParametersSnell et al.

Grounds the scaling question of when extra inference budget beats larger base models.

Open source

Claim Review

Test-time compute spends extra inference budget on sampling, verification, and selection; it helps when the generator can produce good candidates and the verifier ranks them reliably.

StatusSubstantive claim review pending

Source IDs and witness objects are attached for review; they are not proof by themselves.

Sources3 references

wang-2022-self-consistency, lightman-2023-verify-step-by-step, snell-2024-test-time-compute

Witnesses4 local objects

Use equation, code, and demo objects to check whether the source support is operational.

Source-linked; substantive support review pendingIn the page's finite best-of-N model, extra test-time compute can improve selected correctness when more samples cover good traces and the verifier ranks them highly; as N grows, clean ranking can help, while a rare high-scoring verifier error can be selected more often.Claim metadata: source checked

Wang et al. ground drawing multiple reasoning paths and aggregating answers. Lightman et al. evaluate reward models by best-of-N search: select the sampled solution ranked highest by the reward model. Snell et al. analyze test-time compute via best-of-N and verifier/PRM search. The local math/code/demo show coverage vs verifier selection and noisy-verifier failure.

Sources: Self-Consistency Improves Chain of Thought Reasoning in Language Models, Let's Verify Step by Step, Scaling LLM Test-Time Compute Optimally can be More Effective than Scaling Model ParametersThis checks a finite, fixed-distribution best-of-N verifier model, not tree search, adaptive reasoning policies, universal scaling laws, exact serving costs, calibrated verifier probabilities, or guaranteed gains from more inference compute.Attached source IDs and witness refs are review targets, not proof.

source-span-wang-2022-self-consistency source-span-lightman-2023-verify-step-by-step source-span-snell-2024-test-time-compute math-object-1 math-object-2 code-witness-1 interactive-demo

Source support candidates

paper 2022Self-Consistency Improves Chain of Thought Reasoning in Language Models

Grounds repeated sampling and answer aggregation as a simple way to spend more inference compute.

paper 2023Let's Verify Step by Step

Grounds process-supervised reward models as learned verifiers evaluated by best-of-N selection over sampled reasoning solutions.

paper 2024Scaling LLM Test-Time Compute Optimally can be More Effective than Scaling Model Parameters

Grounds the scaling question of when extra inference budget beats larger base models.

Mechanism witnesses

Equation 1

p_i=\pi_{\mathrm{base}}(\tau_i\mid x), \qquad \sum_i p_i=1, \qquad u_i\in\{0,1\}, \qquad s_i=s_\phi(\tau_i).

Equation 2

\begin{aligned} \tau^\star &= \arg\max_{\tau\in\{\tau^{(1)},\dots,\tau^{(N)}\}} s_\phi(\tau),\\ F_k &= \sum_{i=1}^k p_i,\qquad F_0=0,\\ P_N(k\ \mathrm{selected}) &= F_k^N-F_{k-1}^N,\\ A(N) &= \sum_k u_k \left(F_k^N-F_{k-1}^N\right),\\ \mathrm{coverage}_N &= 1-\left(1-\sum_i p_i u_i\right)^N. \end{aligned}

Code witness 1def selected_distribution(candidates, n): ranked = sorted(candidates, key=lambda item: item["...Demo stateLive mechanism probe

Practice Loop

Try the idea before it explains itself

Test-time compute spends extra inference budget on sampling, verification, and selection; it helps when the generator can produce good candidates and the verifier ranks them reliably.

Readiness0/3 checks ready

Predict

Before touching the demo, predict one visible change that should happen in Test-Time Compute: Spending Inference Budget on Search.

Hint 1

Reveal when your model needs a nudge.

Hint 2

Reveal when your model needs a nudge.

Hint 3

Reveal when your model needs a nudge.

Your answer canvas

Local checks

Claim

A concrete answer is on the canvas.

Mechanism

The answer names why the claim should hold.

Bridge

It touches the page context or a neighboring idea.

Misconception check

Object research drawerClose

ConceptTest-Time Compute: Spending Inference Budget on SearchScaling

Code witness comparisonTest-Time Compute: Spending Inference Budget on Search code witness 1def selected_distribution(candidates, n): ranked = sorted(candidates, key=lambda item: item["...Prediction before revealTest-Time Compute: Spending Inference Budget on Search interactive demoManipulate one control and predict the visible change.

Grounded room questionWhat is the smallest example that makes Test-Time Compute: Spending Inference Budget on Search click without losing the math?Local snapshot ready

Research Room

Attach the question to an exact object

Pick the concept, equation, source, code witness, claim, misconception, or demo state before asking for help. The handoff stays grounded to that object.

Next local actionNo local draft saved yet

Open the draft below to save one note and next action in this browser.

conceptScaling

Test-Time Compute: Spending Inference Budget on Search

Anchored question

What is the smallest example that makes Test-Time Compute: Spending Inference Budget on Search click without losing the math?

Local action draftNo local draft saved yetExpand only when ready to capture one local next action

Local action draft

This draft stays locally in this browser for concept:scaling/test-time-compute.

Draft noteNext action

No local draft saved.

Evidence to inspect

Source ids to inspect: wang-2022-self-consistency, lightman-2023-verify-step-by-step, snell-2024-test-time-compute
Definition, prerequisite, and contrast concept links
The equation or code witness that makes the concept operational
One demo state that shows the invariant instead of a slogan

What would resolve this

The learner can state the mechanism in their own words
The learner can name the prerequisite that would repair confusion
The learner can predict how the mechanism changes under one perturbation

Grounded AI handoff

I am working in Continuous Function's research reading room. Object: concept - Test-Time Compute: Spending Inference Budget on Search Object key: concept:scaling/test-time-compute Context: Scaling Anchor id: concept/concept-notebook/scaling/test-time-compute Open question: What is the smallest example that makes Test-Time Compute: Spending Inference Budget on Search click without losing the math? Evidence to inspect: - Source ids to inspect: wang-2022-self-consistency, lightman-2023-verify-step-by-step, snell-2024-test-time-compute - Definition, prerequisite, and contrast concept links - The equation or code witness that makes the concept operational - One demo state that shows the invariant instead of a slogan What would resolve this: - The learner can state the mechanism in their own words - The learner can name the prerequisite that would repair confusion - The learner can predict how the mechanism changes under one perturbation Answer as a careful research tutor: stay source-grounded, separate verified evidence from assumptions, name the relevant math objects, and end with one next action.

Open source object

concept/concept-notebook/scaling/test-time-compute
concept:scaling/test-time-compute

Learning Map

Before / Now / Try / Next

BeforeScaling Laws & Emergent Abilities

NowIntuition → Math → Code → Demo

TryManipulate one control and predict the visible change.

NextTree Search Reasoning: Allocating Inference Budget Across Prefixes

Intuitionready
Mathready
Codeready
Interactive Demoready

Object Companion

Ask beside the selected object

Test-time compute spends extra inference budget on sampling, verification, and selection; it helps when the generator can produce good candidates and the verifier ranks them reliably.

Your question

GoalComfortStyleStuck on

Context prompt

You are my AI learning companion for Continuous Function. Current context: Scaling concept. Learning surface: Test-Time Compute: Spending Inference Budget on Search. What this page says: Test-time compute spends extra inference budget on sampling, verification, and selection; it helps when the generator can produce good candidates and the verifier ranks them reliably. Current section: Intuition, math, code, and interactive demo. Suggested next step: Manipulate one control and predict the visible change.. Learner goal: Understand the idea. Learner comfort level: New to this. Preferred explanation style: Visual first. Task: Explain the central idea in plain language, then restate it with the exact math objects from the page. Answer in a way that helps me learn: ask one clarifying question only if needed, use intuition before notation, and end with one thing I should try on the page.

Domain

Scaling

scalinginferencetest-time-computeverifiersreasoning

Prerequisites

Scaling Laws & Emergent Abilities Process Reward Models: Step-Level Verifiers for Reasoning Reward Hacking: Overoptimizing Preference Proxies Decoding & Sampling: Temperature, Top-p & Inference-Time Control

Leads To

Tree Search Reasoning: Allocating Inference Budget Across Prefixes

RLHF: Reward Modeling + KL-Regularized Policy Optimization LLM Serving at Scale: Prefill, Decode & Continuous Batching Speculative Decoding: Lossless Multi-Token Generation Overparameterization & Generalization (Double Descent)

Within this domain