Test-Time Compute의 핵심은 ‘더 많이’가 아니라 ‘어디에 쓸 것인가’다 — Stanford CS329A Part 2

작성자:

시리즈: 자가 개선 AI 에이전트 — 2/9
이전 편: Part 1 — AI 발전의 중심은 왜 ‘더 큰 모델’에서 확장되고 있는가
강의: Stanford CS329A | Test-Time Compute Scaling

English version

Part 1에서는 AI 성능을 높이는 연산의 투입 지점이 사전학습 밖으로 확장되고 있다는 흐름을 살펴봤다. 모델을 다시 학습하지 않고도, 실제 문제를 푸는 순간 더 많은 연산을 사용해 성능을 높일 수 있다는 것이다.

Part 2는 여기서 한 단계 더 어려운 질문을 던진다.

그렇다면 test-time compute는 정확히 어디에 써야 하는가?

가장 단순한 답은 “같은 문제를 더 많이 풀게 한다”다. 하지만 Stanford CS329A 두 번째 강의는 반복 샘플링에서 시작해 자동 검증, process reward model, 난이도 적응형 연산 배분, 그리고 Archon의 inference-time architecture search까지 나아간다.

따라서 이 강의의 핵심은 “추론을 오래 하면 좋아진다”가 아니다.

추론 연산이 하나의 scaling axis가 되려면, 어디에 연산을 투입하고 어떤 피드백으로 결과를 선택할지까지 설계해야 한다.

1. 반복 샘플링은 모델 안에 숨어 있던 solution coverage를 드러낸다

강의는 Azalia Mirhoseini가 공저한 2024년 Large Language Monkeys 연구를 다시 꺼내면서 시작한다.

방식은 단순하다. 모델 가중치는 그대로 둔다. 같은 문제를 여러 번 독립적으로 풀게 한다. 그리고 적어도 한 번 정답이 생성된 문제의 비율인 coverage를 측정한다.

여러 모델과 과제에서 sample budget을 늘릴수록 coverage는 계속 증가했다. SWE-bench Lite에서는 DeepSeek-Coder-V2-Instruct가 1회 샘플에서 15.9%의 이슈를 해결했지만, 250회 샘플에서는 56%까지 올라갔다.

코드나 formal proof처럼 생성 결과를 자동 검증할 수 있는 영역에서는 이 coverage 증가를 시스템 성능 증가로 직접 전환하기가 쉽다.

여기서 “모델의 능력”이라는 말의 의미도 달라진다.

한 번의 답변은 분포에서 한 번 뽑은 결과다. repeated sampling은 다른 질문을 한다.

이 모델이 정답 경로를 전혀 모르는가, 아니면 알고 있지만 첫 번째 시도에서 꺼내지 못했는가?

2. Coverage가 높다고 실제 시스템 정확도가 높은 것은 아니다

같은 연구는 바로 다음 한계도 보여준다.

1,000개의 답을 만들었는데 정답이 두 개뿐이라고 하자. Coverage 관점에서는 “이 문제를 풀 수 있다”고 할 수 있다. 하지만 실제 시스템은 그 두 개를 998개의 오답과 구분해야 한다.

자동 verifier가 없는 영역에서는 majority voting이나 reward model 기반 선택 성능이 sample 수가 계속 늘어도 일정 수준 이후 정체될 수 있다.

생성 가능한 정답의 범위는 계속 넓어지는데, 선택 능력은 같은 속도로 따라가지 못하는 것이다.

이것이 generator-verifier gap의 실무적 의미다.

모델이 정답을 만들어낼 수 있는 시점과 시스템이 그 정답을 알아볼 수 있는 시점은 다를 수 있다.

3. 왜 전체 benchmark에서는 power law처럼 보이는가

강의에서는 sample 수와 benchmark coverage 사이에 power-law 형태의 scaling curve가 나타난다고 설명한다.

여기서는 원자료의 출처를 정확히 나눌 필요가 있다.

2024년 Large Language Monkeys는 여러 모델과 과제에서 inference compute와 coverage 사이의 empirical scaling pattern을 보여줬다.

하지만 “개별 문제에서는 성공확률이 지수적으로 증가하는데 왜 전체 benchmark에서는 power law가 나오는가?”라는 수학적 설명은 2025년 후속 논문 How Do Large Language Monkeys Get Their Power (Laws)?에서 더 명확하게 다뤄진다.

한 문제의 single-attempt 성공 확률을 p라고 할 때, k번 독립 시도 후 적어도 한 번 성공할 확률은 다음과 같다.

1 − (1 − p)k

개별 문제에서는 exponential curve다. 그런데 후속 연구는 문제별 성공확률 분포에 극도로 어려운 문제들의 heavy tail이 존재하면, 이들을 합친 전체 benchmark의 실패율이 power-law 형태로 나타날 수 있다고 설명한다.

실무적 의미는 수식보다 단순하다.

benchmark 안의 모든 문제는 같은 속도로 saturate하지 않는다.

쉬운 문제는 적은 compute로 빠르게 해결된다. 추가 연산의 대부분은 아주 어려운 문제들이 흡수한다.

4. 모든 query에 같은 연산 예산을 쓰는 것은 비효율적이다

이 지점에서 Charlie Snell 등의 2024년 논문 Scaling LLM Test-Time Compute Optimally can be More Effective than Scaling Model Parameters로 이어진다.

이 논문의 질문은 자원 배분이다.

고정된 inference budget이 있을 때, 그 연산을 어떻게 나눠 써야 가장 높은 성능을 얻을 수 있는가?

결론은 “모든 문제에 같은 전략을 적용하면 안 된다”는 것이다. 연구진은 test-time technique의 효과가 prompt difficulty에 크게 좌우된다고 보고한다.

문제 난이도에 맞춰 연산을 배분하는 compute-optimal strategy는 best-of-N baseline보다 효율을 4배 이상 높였다. 또 FLOPs를 맞춘 비교에서, 작은 base model이 이미 어느 정도의 non-trivial success rate를 가진 문제에 대해서는 test-time compute를 사용해 14배 큰 모델을 넘어설 수 있었다.

여기에도 중요한 조건이 붙는다.

작은 모델이 처음부터 사실상 풀 수 없는 문제까지 inference compute만으로 해결할 수 있다는 뜻은 아니다. 가장 어려운 문제에서는 더 강한 base model이 여전히 훨씬 유리할 수 있다.

5. 문제 난이도에 따라 탐색 방식 자체가 달라져야 한다

강의는 test-time compute를 쓰는 방법을 크게 두 축으로 설명한다.

  • Parallel exploration: 서로 독립적인 후보를 많이 생성한다.
  • Adaptive improvement: 중간 피드백을 이용해 현재 답변이나 분포를 수정하면서 진행한다.

상대적으로 쉬운 문제에서는 이미 괜찮은 경로를 조금씩 개선하는 방식이 효율적일 수 있다. 반대로 어려운 문제에서는 하나의 경로만 계속 수정하면 나쁜 local region에 갇힐 수 있어 더 넓은 exploration이 필요하다.

여기서 얻을 수 있는 시스템 설계 원칙은 다음과 같다.

연산량은 query마다 고정해서 배분하는 것이 아니라 불확실성과 난이도에 따라 routing해야 한다.

실제 agent가 모든 요청에 동일한 token budget, 동일한 tool call 수, 동일한 verifier pass를 사용한다면 쉬운 문제에는 낭비하고 어려운 문제에는 부족하게 쓸 가능성이 높다.

6. 최종 답만 채점하는 것보다 중간 과정을 검증하면 탐색 비용을 줄일 수 있다

다음 설계 문제는 verifier가 언제 개입하는가다.

Outcome-based evaluator는 완성된 답을 본 뒤 점수를 준다. Process-based evaluator는 중간 reasoning step을 평가한다.

탐색 관점에서는 차이가 크다.

세 번째 단계에서 이미 잘못된 branch를 최종 답까지 생성한 뒤 버리는 것보다, 중간 단계에서 낮은 점수를 주고 바로 가지치기하는 편이 연산 효율이 높다.

Beam search나 tree-style inference에 process verifier를 붙이면:

  • 유망한 branch는 더 확장하고,
  • 약한 branch는 조기에 제거하고,
  • 애매한 문제에만 추가 compute를 집중할 수 있다.

이 부분은 자연스럽게 Part 3으로 이어진다. Search를 verifier가 이끈다면, 결국 verifier가 틀리지 않는 것이 중요해진다.

7. Test-time scaling이 쉬운 분야와 어려운 분야를 가르는 것은 verifier다

강의는 자동 검증이 가능한 영역을 여러 층위로 보여준다.

Formal proof에는 machine-checkable proof system이 있다. 소프트웨어에는 test suite가 있다. GPU kernel generation에서는 생성된 kernel의 출력이 reference implementation과 같은지 비교할 수 있다.

KernelBench가 대표적인 예다. 모델이 reference PyTorch 구현과 기능적으로 같은 GPU kernel을 생성하게 하고, 정확성과 성능을 분리해서 평가할 수 있다.

하지만 “자동 검증”이 “완벽한 검증”과 같은 말은 아니다.

KernelBench 유지관리 문서 역시 reward hacking과 비현실적으로 좋은 결과를 경계하라고 명시한다. correctness check나 benchmark harness 자체에 빈틈이 있으면 모델은 의도한 문제를 풀기보다 evaluator의 허점을 이용할 수 있다.

따라서 더 근본적인 규칙은 다음과 같다.

test-time scaling의 상한은 feedback channel의 품질이 결정한다.

8. Archon은 inference 자체를 architecture design 문제로 바꾼다

강의 후반부는 repeated sampling보다 훨씬 복합적인 방향으로 간다.

한 모델을 N번 호출하는 대신 inference를 여러 층의 시스템으로 만들 수 있다면 어떨까?

Archon: An Architecture Search Framework for Inference-Time Techniques는 이 아이디어를 체계화한다.

Archon은 generator, critic, ranker, fuser, verifier, unit-test module 같은 inference-time component를 조합한다. 같은 layer 안의 여러 LLM은 병렬로 실행할 수 있고, layer 간에는 순차적으로 정보를 넘길 수 있다.

질문은 이제 “어떤 모델이 제일 좋은가?”가 아니다.

  • 어떤 모델들이 candidate를 생성할 것인가?
  • 각 모델에서 몇 개를 sampling할 것인가?
  • critic을 먼저 넣을 것인가?
  • ranker로 후보를 줄일 것인가?
  • 여러 답을 fusion할 것인가?
  • 몇 개의 layer가 비용 대비 효과적인가?

Archon은 이 조합 자체를 hyperparameter optimization 문제로 다룬다.

9. Fusion은 ‘최고 후보를 고르는 것’과 다르다

Archon에서 특히 흥미로운 요소가 fusion이다.

Ranker는 기존 후보 중 하나를 고른다. Fuser는 여러 후보를 입력받고 그 장점들을 종합해 새로운 답을 생성한다.

Archon 논문은 일부 실험에서 candidate fusion이 개별 후보 중 oracle best를 선택한 것보다 더 높은 결과를 낼 수 있다고 보고한다.

이것은 중요한 차이를 만든다.

추가 inference compute는 이미 생성된 정답을 찾는 데만 쓰이는 것이 아니다. 여러 불완전한 답에 흩어진 올바른 정보를 재조합해 새 답을 만드는 데도 쓰일 수 있다.

즉 inference는 width뿐 아니라 depth를 가질 수 있다.

10. Archon 수치는 원 논문 기준으로 바로잡아야 한다

원 논문을 대조하는 과정에서 강의 관련 source metadata와의 불일치가 확인됐다.

정확한 Archon arXiv ID는 2409.15254다.

또 원 논문 초록은 best Archon architectures가 모든 available LLM을 사용했을 때 비교 대상 frontier single-call model 및 기존 inference architecture 대비 평균 15.1 percentage points의 정확도 향상을 보고한다.

Open-source LLM만 사용한 Archon architecture의 경우 논문은 single-call state-of-the-art LLM 대비 평균 11.2 percentage points의 우위를 보고한다.

따라서 이 글에서는 “open-source만으로 GPT-4o/Claude 3.5보다 평균 14.1% 높았다”는 표현을 그대로 사용하지 않는다.

이런 차이는 작아 보이지만 중요하다. 시스템 성능을 설명할 때는 어떤 모델 pool을 사용했는지, 무엇을 baseline으로 비교했는지, percent인지 percentage point인지가 모두 달라질 수 있기 때문이다.

11. Inference compute는 pretraining과 비용 구조가 다르다

강의 중 학생이 매우 중요한 경제적 반론을 제기한다.

Pretraining은 엄청난 고정비가 들지만 한 번 학습된 모델은 수많은 사용자에게 반복 사용된다. 반면 test-time compute는 query마다 다시 비용을 낸다.

이 차이는 deployment에서 결정적이다.

매 요청마다 수백 개의 sample, 여러 critic, ranker, fuser를 실행해야 한다면 latency와 API/GPU 비용이 급증한다.

따라서 training scale과 inference scale의 비교는 단순 benchmark accuracy 비교로 끝나지 않는다.

  • 고정 학습비,
  • query당 변동비,
  • latency 제한,
  • 과업의 경제적 가치,
  • verifier 신뢰도,
  • 같은 능력이 앞으로 얼마나 반복 사용될지

를 함께 봐야 한다.

Test-time scaling은 특히 모델을 다시 학습할 수 없거나, closed API만 사용할 수 있거나, 소수의 고가치 문제에만 추가 compute를 집중할 수 있는 상황에서 매력적이다.

12. 가장 강한 반론: 결국 더 좋은 모델 하나를 쓰는 게 더 싸고 단순하지 않은가?

충분히 가능한 반론이다.

작은 모델이 1,000번 시도하고 process verifier와 critic과 fusion layer까지 거쳐야 큰 모델의 1회 답변과 비슷해진다면, 그냥 더 강한 모델을 쓰는 것이 더 나을 수 있다.

실제로 test-time scaling에는 구조적 한계가 있다.

  • base model 분포 안에 좋은 해답이 거의 없으면 sampling으로 해결하기 어렵다.
  • 복잡한 inference pipeline은 latency와 운영 복잡성을 늘린다.
  • verifier가 틀릴 수 있다.
  • 생성된 unit test가 불완전할 수 있다.
  • fusion이 공통된 오류를 상쇄하는 대신 증폭할 수도 있다.

그래서 test-time compute를 지지하는 가장 강한 결론도 조건부다.

base model이 이미 유의미한 확률로 좋은 구성요소를 만들 수 있고, feedback이 충분히 신뢰할 수 있을 때, 추가 inference compute는 일부 model scale을 매우 효율적으로 대체할 수 있다.

이는 inference scaling이 pretraining을 대체한다는 주장과 전혀 다르다.

13. 이 글이 주장하지 않는 것

  • Pretraining이 이제 필요 없다고 주장하지 않았다.
  • Majority voting이 모든 문제에서 무의미하다고 주장하지 않았다. 특히 정답이 희귀한 고난도 문제에서 한계가 크다는 것이다.
  • sample 수를 늘리기만 하면 deployed accuracy가 자동으로 오른다고 주장하지 않았다.
  • 하나의 inference architecture가 모든 domain과 budget에서 최적이라고 주장하지 않았다.
  • latency와 query당 비용 문제를 제거하지 않았다.
  • Archon의 architecture search가 인간 설계를 완전히 대체한다고 주장하지 않았다. 실제 framework도 design-space constraint를 사용한다.

14. Part 2의 실제 결론

강의는 “더 많이 생성하라”에서 시작하지만 마지막에는 훨씬 복합적인 inference engineering에 도착한다.

추론 시점의 추가 연산은 다음에 쓸 수 있다.

  1. 더 많은 candidate 생성,
  2. 유망한 trajectory 수정,
  3. 중간 step 검증,
  4. 약한 branch pruning,
  5. candidate ranking,
  6. 불완전한 해답 fusion,
  7. inference architecture 자체의 search.

이제 핵심 질문은 “더 많은 compute가 도움이 되는가?”가 아니다. 도움이 될 수 있다는 증거는 충분하다.

더 어려운 질문은 이것이다.

다음 한 단위의 compute를 어디에 써야 하는가?

이 관점에서 test-time scaling은 단순히 “AI에게 더 오래 생각할 시간을 주는 것”이 아니다. 지능을 위한 compute scheduler를 설계하는 문제에 가깝다.

Part 3에서는 이 구조의 필수 전제를 파고든다. search를 verifier가 이끈다면, verifier 자체는 어떻게 robust하게 만들 수 있는가?

Claim map

  • Speaker / Course Claim: test-time compute는 중요한 scaling axis이며, 문제 난이도에 따라 compute allocation이 달라져야 한다. generator-verifier gap은 repeated sampling의 핵심 병목이고, multi-layer inference architecture는 single-call system을 넘어설 수 있다.
  • Verified Fact: repeated sampling은 coverage를 높인다. cited SWE-bench Lite 실험에서 DeepSeek-Coder-V2-Instruct는 15.9%에서 56%로 증가했다. Snell et al.은 compute-optimal strategy가 best-of-N보다 4배 이상 효율적이고 조건부 FLOPs-matched 비교에서 14배 큰 모델을 넘어섰다고 보고했다. Archon은 generation, ranking, fusion, critique, verification, unit test 등을 결합하며, 원 논문은 all available LLM 조건에서 +15.1 percentage points, open-source-only 조건에서 +11.2 percentage points를 보고한다.
  • Editorial Interpretation: “test-time scaling은 compute-allocation 문제다”라는 문장은 강의와 논문을 종합한 이 글의 중심 해석이다.

강의 지도

  • 00:00–00:05 — inference를 세 번째 scaling 단계로 보기, repeated sampling 복습
  • 00:05–00:12 — inference scaling curve와 hard-problem tail
  • 00:12–00:19 — automated verification과 generator-verifier gap
  • 00:19–00:27 — verifier 설계 및 failure mode 토론
  • 00:27–00:41 — compute-optimal test-time scaling과 process-based verification
  • 00:41–00:46 — parallel search와 tree-style search
  • 00:46–01:03 — Archon, fusion, deep inference layer, architecture search

주요 1차 출처