← Back to concept explainers

Concept Fable

Test-time compute

Conclusion first:Test-time compute, or more plainly inference-time scaling, is spending extra compute while the model is running to improve output quality. Here, "test-time" does not mean the software testing phase, but the phase when the model generates an answer for a new input.

Test-Time Compute / Inference-Time Scaling · Inference

Read the story first. There is no rush to give a definition here; let the question grow on its own first.

Fable

The advisory hall filled the lamp oil for difficult problems separately

The city’s advisory hall answered merchants’ questions every day. The old rule was fair: every question received the same lamp, the same sheet of paper, and the same quarter hour. Simple accounts could be answered, but complex disputes also had to stop when time was up.

The library owner first trained the advisors to write faster. Short Q&A became smoother, but when it came to cross-city contracts, taxes and transport risks, a faster pen only produced incomplete answers faster.

Someone suggested giving three times the lamp oil to every problem. The accountant immediately objected: most problems do not need it, the oil would be burned away on simple problems, and the truly hard problems would still lack a judgment route.

Later the curator graded the problems. Simple questions were answered as usual; medium questions first listed a few lines of thought and then merged them; difficult questions allowed multiple rounds of reasoning, invited verifiers to score, and even had several consultants answer separately before choosing the best.

This new method made the hall seem no longer absolutely fair, because each question consumed a different amount of lamp oil. But the delivery results were fairer: difficult questions received enough thought, and simple questions were not over-processed.

The museum director also set boundaries. Lamp oil was not unlimited; once over budget, it still had to stop. For cases requiring legal responsibility, one could not rely only on more thinking; one also had to find someone who could sign off to review.

After some time, the consultancy no longer understood capability as only the consultant's own intelligence. How much thinking, searching, candidate generation, and verification was allocated on the spot also became part of capability.

The curator finally wrote down the rule: training determines what the consultant knows, and the compute at delivery determines how much care he is willing to put into this particular question. Both must be factored into system design. Later the accounting office also accepted this accounting: not every question burns the same lamp oil, but lamp oil is invested where it can most change the quality of the answer. The extra cost spent on hard questions must buy more reliable judgment. The consultants also learned to explain to merchants: burning more lamp oil is not for show, but because the cost of error on this question is higher, requiring more candidates, verification and trade-offs. The curator also checked the accounts every night, confirming that the extra lamp oil indeed bought fewer misjudgments. The curator also checked the accounts every night, confirming that the extra lamp oil indeed bought fewer misjudgments, rather than just thicker paper.

Reveal

This story is about: test-time compute

Test-time compute, or more plainly inference-time scaling, is spending extra compute while the model is running to improve output quality. Here, "test-time" does not mean the software testing phase, but the phase when the model generates an answer for a new input.

Common approaches include longer reasoning, multiple candidates, self-consistency, verifier-guided search, or tree search. It may improve performance on hard problems, but it increases latency and cost, so decide when it's worth using based on the value of the task.

Metaphor mapping

  • Lamp oil: inference-time compute budget
  • Multi-round deliberation: longer reasoning or deliberation
  • Several consultants answered separately: sampling multiple candidates
  • Verifier scoring: verifier or reward model
  • Problem tiering: routing extra compute by difficulty and value
  • Budget boundaries: latency, cost, and operational constraints

Andy Ren Xu's judgment

The practical value of this concept is that it helps you break "AI features that look smart" into deliverable, verifiable, and governable units of work.

chain-of-thoughtbest-of-Nreasoningscaling
京ICP备2026014272号