Test-Time Compute Scaling

훈련이 아니라 추론 시점에 계산을 더 투입해 성능을 끌어올리는 접근이다.

개념

Test-Time Compute Scaling은 훈련이 아닌 추론 시점에서 더 많은 계산 자원을 사용하여 성능을 향상시키는 접근이다.

패러다임 전환

• 기존 패러다임: 더 큰 모델 + 더 많은 데이터 + 더 많은 훈련 = 더 좋은 성능
• 새로운 패러다임: 같은 모델 + 추론 시간에 더 많이 생각 = 더 좋은 성능

자원 배분 비교

• 기존: 훈련 90%, 추론 10% — 대부분의 자원을 훈련에 투자
• 새로운: 훈련 50%, 추론 50% — 추론 시간에도 동등한 자원 배분

Snell et al. 2024

이 패러다임을 체계화한 정본은 Snell et al.의 "Scaling LLM Test-Time Compute Optimally"(arXiv 2408.03314, 2024)이다. 추론 계산을 두 축으로 늘린다.

1. 검증기 기반 탐색: 과정 보상 모델(Process Reward Model, PRM)로 여러 추론 경로를 채점해 best-of-N·트리 탐색에 활용
2. 응답 분포의 적응적 수정: 프롬프트 난이도에 따라 출력 분포를 갱신

핵심은 최적 계산 배분(compute-optimal)이다. 문제 난이도에 맞춰 추론 계산을 다르게 배분하면, 일부 설정에서 best-of-N 대비 효율이 4배 이상 높아진다. 작은 모델이 어느 정도 성공률을 내는 문제에서는 같은 연산량으로 14배 큰 모델을 앞서기도 한다.

보상 모델: PRM vs ORM

검증 기반 탐색의 품질은 보상 모델이 좌우한다.

• 결과 보상 모델(ORM): 최종 답만 채점한다. 단순하지만 중간 추론의 오류를 놓친다.
• 과정 보상 모델(PRM): 추론 단계마다 채점한다. OpenAI의 "Let's Verify Step by Step"(arXiv 2305.20050)이 80만 단계 라벨(PRM800K)로 PRM을 학습해, 같은 샘플 수에서 ORM(72.4%)보다 높은 78.2%를 기록했다.

s1

2025년 1월 발표된 s1은 적은 데이터로 추론 확장을 구현한 사례다(arXiv 2501.19393).

훈련 방식

1. 데이터 수집: 단 1,000개 어려운 문제
2. 파인튜닝: 이 데이터만으로 훈련
3. Budget Forcing: 'Wait' 삽입과 종료 구분자 제어로 사고 시간 조절

성능

베이스 모델(26.7%)을 1,000개 예제로 파인튜닝한 s1-32B가 AIME 2024에서 o1-preview를 앞선다. 표의 o1-preview(44.6%)·o1(79.8%) 수치는 s1 논문 Table 1을 따른다(arXiv 2501.19393).

Budget Forcing

s1의 핵심 기법은 Budget Forcing이다.

동작 원리

별도의 특수 토큰을 추가하는 방식이 아니다. 더 생각하게 하려면 사고 종료 구분자를 억제하고 평문 "Wait"를 덧붙여 모델이 추론을 이어가게 만든다. 멈추려면 종료 구분자와 "Final Answer:"를 붙여 답을 내게 한다.

• 사고 연장: 종료 구분자 억제 + "Wait" 추가 → 추가 사고 유도
• 사고 종료: 종료 구분자 + "Final Answer:" → 최종 답 출력

동작 예시

일반 생성: "답은 42이다." — 즉시 답변을 출력한다.

Budget Forcing: "음..." → Wait → "이 문제를 풀려면 먼저..." → Wait → Wait → "따라서..." → Final Answer: → "42" — 여러 번의 사고 단계를 거쳐 더 깊이 생각한 뒤 답변한다.

사고 시간 제어

• 쉬운 문제: Wait x 2 — 빠른 답변
• 중간 문제: Wait x 10 — 적당한 사고
• 어려운 문제: Wait x 50 — 깊은 사고

계산량과 성능의 관계

중요한 발견

동적 계산량 조절

문제 난이도에 따른 조절

쉬운 문제: "1 + 1 = ?" → Wait x 1 → "2" — 최소한의 사고로 즉시 답변

어려운 문제: "AIME 문제" → Wait x 50 → 깊은 분석을 거쳐 답변

자신감 기반 조절

s1 자체는 고정 예산(Wait 횟수)으로 제어한다. 아래 자신감 기반 조절은 그보다 일반적인 변형 아이디어로, 초기 사고 후 자신감을 평가해 계산량을 조절한다:

• 자신감 높음: 바로 답변
• 자신감 낮음: Wait 추가 후 더 생각

비용 효율성

비용 비교

• 더 큰 모델 훈련: GPU 수천 대 x 수개월 = $수백만
• 추론 시간 증가: 추가 토큰 비용 x 필요할 때만 = $수천

구현 방식

단순 반복

wait_tokens는 "Wait"를 덧붙여 사고를 연장하는 횟수다. 고정된 예산만큼 반복한 뒤 "Final Answer:"로 답을 강제한다.

def think_longer(model, question, wait_tokens=10):
    prompt = question
    for _ in range(wait_tokens):
        prompt += model.generate(prompt, max_tokens=50)
        prompt += "Wait"
    prompt += "Final Answer:"
    return model.generate(prompt)

적응적 조절

max_waits는 사고 연장의 상한이고, confidence > 0.9는 더 생각할 필요가 없다고 판단하는 임계값이다. 자신감이 임계값을 넘으면 상한에 도달하기 전에 멈춘다.

def adaptive_thinking(model, question, max_waits=50):
    prompt = question
    for i in range(max_waits):
        response = model.generate(prompt, max_tokens=50)
 
        # 자신감 체크
        confidence = model.evaluate_confidence(response)
        if confidence > 0.9:
            break
 
        prompt += response + "Wait"
 
    prompt += "Final Answer:"
    return model.generate(prompt)

Best-of-N Sampling

best-of-N 샘플링은 같은 문제를 N번 풀어 가장 좋은 답을 고르는 기법이다.

같은 문제를 N번 풀어본다:

시도 1: 답 A / 시도 2: 답 B / 시도 3: 답 A / 시도 4: 답 A / 시도 5: 답 C

가장 좋은 것을 선택하거나 다수결을 적용한다 → 답 A

선택 기준

한계

1. 포화점: 무한히 생각한다고 무한히 좋아지지 않음
2. 비용 증가: 추론 비용은 여전히 비용
3. 지연 시간: 사용자 대기 시간 증가
4. 문제 유형: 모든 문제에 효과적이지 않음

적합한 사용 사례

정리

Test-Time Compute Scaling은 추론 시점에 계산을 더 투입해 같은 모델로 성능을 끌어올린다. Snell et al.은 문제 난이도에 맞춘 최적 계산 배분(compute-optimal)으로 best-of-N보다 효율을 높일 수 있음을 보였다. s1의 Budget Forcing은 "Wait" 삽입과 종료 구분자 제어만으로 사고 시간을 조절하고, best-of-N 샘플링은 여러 응답 중 가장 좋은 답을 고른다. 다만 추론량을 늘려도 일정 지점 이후 향상이 포화하고, 추가 토큰 비용과 지연 시간이 따른다. 정확도가 중요한 수학·코딩 문제에 적합하고, 실시간 대화처럼 속도가 중요한 작업에는 맞지 않는다.

관련 개념

• OpenAI o1: 내부 추론 토큰
• DeepSeek-R1: 오픈소스 추론 모델
• Budget Forcing: 사고 시간 제어 기법