추론 시간에 계산을 더 쓰면 LLM이 더 잘 추론하는가: 세 가지 레짐과 운영 함의 (arXiv:2608.04001)

요약

DeepSeek-R1, Claude 3.7 Sonnet, QwQ 같은 추론 특화 모델이 등장하면서 테스트 타임 스케일링(test-time scaling, TTS)이 AI 시스템 엔지니어의 핵심 설계 고려사항이 됐다. 모델을 더 크게 만드는 대신 추론 시점에 계산을 더 쓰는 것만으로도 정확도가 크게 오른다는 발견이 실용화됐다.

그런데 "테스트 타임 스케일링"이라는 단어 아래에는 구조적으로 전혀 다른 알고리즘들이 섞여 있다. 2026년 8월 공개된 arXiv:2608.04001 "Test-Time Scaling in Reasoning LLMs: Inference Regimes, Evaluation, and Reproducibility"는 이 혼용을 해결한다. 논문은 TTS를 자동회귀 모델의 암묵적 전위 트리(prefix tree)에서의 예산 추론(budgeted inference)으로 형식화하고, 세 가지 구조적으로 구별되는 레짐을 정의한다.

이 글은 세 레짐의 차이, 각 레짐의 실제 알고리즘 예시, 재현 가능성 문제, 그리고 서빙 시스템 엔지니어가 설계 시 고려해야 할 함의를 다룬다.

배경: 왜 추론 시간 계산인가

전통적인 LLM 성능 향상 축은 두 가지였다.

파라미터 스케일링: 더 큰 모델 훈련 (GPT-4 → GPT-5 방향)
데이터 스케일링: 더 많고 좋은 훈련 데이터

테스트 타임 스케일링은 세 번째 축이다.

동일한 모델 + 동일한 가중치 → 추론 시점 계산만 증가 → 더 어려운 문제 해결

DeepSeek-R1이 대표 사례다. 모델이 답을 내놓기 전에 수천 토큰 분량의 "생각(thinking)" 과정을 거치면, 수학·코딩·논리 추론 성능이 크게 오른다. 이 생각 과정에 소모되는 추가 계산이 곧 테스트 타임 컴퓨트다.

그러나 "더 많이 생각하면 더 좋다"는 직관이 항상 성립하지는 않는다. 과생각(overthinking) 현상도 관찰된다. 모델이 불필요하게 긴 체인을 생성해 오히려 답이 흐려지는 경우다. TTS 설계는 이 균형을 이해하는 것에서 시작한다.

형식화: 전위 트리에서의 예산 추론

논문의 핵심 통찰은 모든 TTS 알고리즘을 전위 트리(prefix tree) 탐색이라는 단일 프레임워크로 설명할 수 있다는 것이다.

자동회귀 언어 모델은 본질적으로 암묵적 트리를 정의한다. 각 노드는 지금까지 생성한 토큰 시퀀스(전위)이고, 자식 노드는 다음 토큰을 선택해 얻은 새로운 전위다.

루트(프롬프트) → 토큰 A → 토큰 AB → 토큰 ABC (완료된 후보)
              ↘ 토큰 B → 토큰 BA → 토큰 BAB (완료된 후보)
              ↘ 토큰 C → ...

예산 추론(budgeted inference)이란, 이 트리의 어느 노드를 얼마나 탐색할지를 주어진 계산 예산 내에서 결정하는 문제다.

세 레짐은 이 탐색 전략의 차이로 구분된다.

세 가지 추론 레짐

테스트 타임 스케일링의 세 가지 추론 레짐

레짐 1: 단일 궤적 순차적 스케일링

가장 직관적인 방식이다. 하나의 생성 궤적을 길게 늘린다. 모델에게 더 긴 "생각 공간"을 허용하는 것이다.

계산 예산: 토큰 수 한도. Claude의 budget_tokens, QwQ의 thinking_token_limit 등이 이에 해당한다.

장점:

생각 단계들이 이전 단계의 결과를 직접 참조할 수 있어 추론 체인의 일관성이 유지된다.
서빙 인프라가 단순하다. 표준 자동회귀 디코딩 루프 하나면 충분하다.

한계:

과생각(overthinking): 예산을 늘릴수록 성능이 단조적으로 오르지 않는다. 어느 지점을 넘으면 불필요한 자기 의심이나 반복이 답의 품질을 낮춘다.
계산 배분이 단순하다: "생각을 더 길게"밖에 할 수 없어 어떤 부분에 더 집중할지 제어할 방법이 없다.

대표 시스템: Claude 3.7/3.5 Sonnet의 Extended Thinking, o1/o3의 내부 추론 체인, DeepSeek-R1.

레짐 2: 리프 레벨 스케일링과 단말 집약

N개의 완성된 후보를 독립적으로 생성하고, 생성이 완료된 후 집약(aggregation)으로 최선을 고른다.

계산 예산: 샘플 수 N.

Best-of-N 샘플링

N개를 생성하고 결과 보상 모델(ORM) 점수가 가장 높은 것을 반환한다.

# 개념적 예시
candidates = [model.generate(prompt) for _ in range(N)]
scores = [orm.score(c) for c in candidates]
return candidates[argmax(scores)]

자기 일관성 (Self-Consistency)

N개 후보 중 다수결로 답을 고른다. ORM 없이도 적용 가능하다. 수학 문제처럼 정답이 정규화 가능한 경우 효과적이다.

answers = [extract_answer(model.generate(prompt)) for _ in range(N)]
return majority_vote(answers)

장점:

N개 생성이 완전히 독립적이라 배치 처리 친화적이다.
서빙 관점에서 N을 동적으로 늘리거나 줄이는 것이 간단하다.

한계:

N이 늘어날수록 수익이 체감한다. 이미 어려운 문제는 N=1이든 N=32이든 모두 틀린다.
ORM의 정확도에 품질이 종속된다. 보상 해킹(reward hacking) 위험이 있다.

레짐 3: 전위 레벨 스케일링 (검색)

미완성 부분 시퀀스(전위)를 평가해 탐색 방향을 동적으로 결정한다. 이것이 레짐 1·2와 근본적으로 다른 점이다.

핵심 구성 요소:

과정 보상 모델(Process Reward Model, PRM): 중간 추론 단계의 품질을 평가
탐색 알고리즘: 어떤 전위를 확장하고 어떤 것을 가지치기할지 결정

빔 서치 (Beam Search)

상위 K개의 전위를 유지하면서 단계적으로 확장한다.

단계 1: K개의 부분 추론 유지
단계 2: 각 부분에서 M개 확장 → KM개 후보
단계 3: PRM 점수 상위 K개만 남기고 나머지 가지치기
... 완료까지 반복

MCTS (Monte Carlo Tree Search)

UCB(Upper Confidence Bound) 점수로 탐색·활용 균형을 맞추며 트리를 순회한다. AlphaGo 계열에서 검증된 방식이다.

장점: 이론적으로 가장 강력하다. 어려운 다단계 추론 문제에서 Best-of-N을 압도한다.

한계:

PRM 품질에 전적으로 의존: PRM이 부정확하면 검색이 오히려 해롭다.
서빙 복잡도 급증: 부분 시퀀스 관리, 가지치기, 재활용을 위한 특수 인프라가 필요하다.
KV 캐시 관리 어려움: 빔 서치에서 부모 전위 캐시를 자식에 공유해야 하는데, 표준 vLLM/SGLang의 페이지 어텐션은 이를 효율적으로 지원하지 못한다. (SGLang의 RadixAttention이 일부 해결)

혼합 레짐

논문은 실제 많은 시스템이 레짐을 혼합한다고 밝힌다. 가장 흔한 패턴은:

전위 레벨 검색 (레짐 3) → 완성된 후보들 → 단말 집약 (레짐 2)

MCTS로 탐색해 여러 완성 후보를 얻은 뒤, 다수결 투표나 검증기로 최선을 고르는 방식이다.

재현 가능성 문제

논문의 또 다른 중요한 기여는 TTS 평가의 재현 가능성 위기를 명시한다는 점이다.

주요 재현 가능성 장벽

항목	문제
계산 예산 정의	"동일한 추론 시간"을 FLOPs, 토큰 수, 시간(초) 중 무엇으로 맞출지 논문마다 다름
기준 모델 불일치	API 기반 평가는 내부 모델 버전 변화에 취약
샘플링 온도	레짐 2에서 온도 설정이 성능에 크게 영향, 논문 간 통일 없음
PRM 비공개	레짐 3 결과는 비공개 PRM을 쓴 경우 재현 불가
벤치마크 오염	추론 모델 훈련 데이터에 평가 문제가 포함됐을 가능성

이 때문에 서로 다른 논문의 TTS 성능 수치를 직접 비교하는 것은 위험하다.

서빙 엔지니어를 위한 설계 함의

레짐 선택 기준

문제 유형이 다단계 추론인가?  ──→ 예 → 레짐 3 검색 고려
                                     PRM 품질 확인 필수
                            ──→ 아니오
응답 일관성이 중요한가?  ──→ 예 → 레짐 1 (단일 궤적)
                         ──→ 아니오 → 레짐 2 (Best-of-N)
                                     가장 단순하고 확장 용이

레짐별 서빙 인프라 요구

레짐	KV 캐시 복잡도	병렬화	추가 인프라
단일 궤적	표준	요청 레벨	없음
Best-of-N	표준	요청 레벨 내 병렬	ORM 서버
검색 기반	고복잡도 (트리 공유)	부분 트리 레벨	PRM 서버, 트리 관리

비용 추정

Best-of-N에서 N=8은 단순 생성 대비 이론적으로 8× 비용이지만, 배치 처리로 실제 지연 증가를 억제할 수 있다. 반면 레짐 3 검색은 PRM 추론 비용이 추가로 발생하고 KV 캐시 효율이 낮아 실제 비용이 더 빠르게 올라간다.

운영 체크리스트

[ ] 사용 중인 TTS 방법이 세 레짐 중 어디에 해당하는지 파악했는가
[ ] 레짐 2를 쓴다면 ORM/검증기 지연이 전체 응답 지연의 병목인지 측정했는가
[ ] 레짐 3을 쓴다면 PRM 정확도를 독립적으로 검증했는가 (PRM 오류 → 검색 품질 하락)
[ ] 단일 궤적에서 budget_tokens 증가가 실제로 정확도를 개선하는지 확인했는가 (과생각 지점 탐색)
[ ] TTS 성능을 벤치마크할 때 계산 예산 기준(토큰 수 vs FLOPs)을 명확히 정의했는가
[ ] Best-of-N의 병렬 생성이 GPU 배치 효율을 높이도록 요청을 묶어 처리하고 있는가
[ ] 레짐 3의 빔 서치를 쓴다면 KV 캐시 전위 공유를 지원하는 서빙 엔진(SGLang RadixAttention)을 사용하는가

References

arXiv:2608.04001 — Test-Time Scaling in Reasoning LLMs: Inference Regimes, Evaluation, and Reproducibility: https://arxiv.org/abs/2608.04001
Sebastian Raschka — The State of LLM Reasoning Model Inference (2026): https://magazine.sebastianraschka.com/p/state-of-llm-reasoning-and-inference-scaling
arXiv:2604.10739 — When More Thinking Hurts: Overthinking in LLM Test-Time Compute Scaling: https://arxiv.org/abs/2604.10739
arXiv:2501.10069 — A Survey on LLM Test-Time Compute via Search: Tasks, LLM Profiling, Search Algorithms, and Relevant Frameworks: https://arxiv.org/abs/2501.10069
arXiv:2606.17930 — How Inference Compute Shapes Frontier LLM Evaluation: https://arxiv.org/abs/2606.17930
vLLM Prefix Caching and RadixAttention 문서: https://docs.vllm.ai/en/stable/design/prefix_caching/