S1: Simple Test-time Scaling

Review

닉네임	한줄평	별점 (0/5)
찰나	LLM이 length를 잘 지킬 수 있을까? 라는 의문이 들긴 함. 다만, 100문장만큼 생각해 ⇒ 깜지 쓰듯이하면 reasoning 단계를 간단하게 확인할 수 있을 것 같긴 함. 다만, 이렇게 하면 오히려 불필요한 reasoning이 생기거나, 그렇게 유도될 것 같기도 함. 성능 개선 측면에선 너무 좋은 방법이라고 생각!	4.3
와사비꽃게랑	방법은 굉장히 단순하고 CoT에 익숙하면 새롭게 느껴지지 않을 수 있긴함. 하지만 test-time에서 얼마나 샘플링하고 언제 끊는지가 성능에 큰 영향을 준다는 부분은 실전에서도 많이 활용할 수 있을것 같음	3.7
메가커피	직관적으로 생각했을 때 성능이 높아지지 않을 것 같은데(시험기간에 공부안했다가 시험칠 때 머리 더 쓴다고 성능이 오를까?) 성능이 오르는게 신기하다.	3.7
요리괴물	학문적인 contribution이 크지는 않지만 실제 적용 단계에서 굉장히 영향력이 클거같다. Wait을 엄청 붙이는데도 정확도가 떨어지지는 않는게 신기하다. 애초에 문제들이 너무 어려워서 그런가? 다들 실험 적용하느라 인용수가 굉장히 높은듯.…	4.0
새우깡	길게 생각하는 것이 혼란을 유발할 수 있지 않을까 싶었는데, 추론능력 어느정도 이상인 언어모델과 어려운 추론 데이터셋 대상으로 해서 그런지 긍정적 영향이 컸나보다. 애매하게 잘하는 언어모델에 대해서는 효과가 어떻게 나올지 궁금하다	4
고구마맛도리	- 향후 0.5~1년 동안은 test time scaling이 많이 나오지 않을까요! 어쨌든 우리는 제한적인 자원안에서 최선의 성능을 끌어올려야 하니까요~ - 그치만 방법이 너무 단순해서 와닿지 않음! 이 논문에서의 findings가 다른 task에서는 유용하지 않을 거 같음	3.5
안성재	scaling에 대한 새로운 접근은 good, but 직관적으로 생각했을 때, LLM training보다 기업에서 inference하는 비용이 훨씬 더 클 것 같음. 그런 면에서 이게 impact가 큰가?는 의문. 보류입니다.	3.3
스타벅스	Inference 단계에서 성능을 높이는 아이디어 자체는 괜찮지만, 이게 논문만큼 얼마나 효과가 있을지는 의문임. 이런 관점에서 봤을 때, 방법론이나 문제 정의가 그렇게 크게 와닿지는 않는 것 같음.	3.8

TL; DR

💡

training 단계에서 말고, inference 단계에서 성능을 높히려면 어떻게 해야 할까?

⇒ 일단 수학/추론 문제는 token 개수 조정해

Summary

연구진

github: https://github.com/simplescaling/s1

인용수: 819

Background & Motivation

Test-time scaling이란?
: 모델의 parameter 수나 training data를 늘리지 않고, 추론 시점(test time)에 사용하는 compute(특히 reasoning token 수)를 조절함으로써 성능을 향상시키는 것
- 참고하면 좋을 링크들!
  https://discuss.pytorch.kr/t/s1-test-time-scaling/6060
  https://duststorage.tistory.com/48

기존 LLM 디벨롭 방식은 Train-time scaling임
- 더 많은 데이터, 더 큰 모델, 더 많은 학습 step, …
- 그러나, 이를 위해서는 너무 많은 GPU/time cost 발생함

⇒ Test-time scaling을 해보자 !

즉, 모델은 고정한 채, inference 과정에서 성능을 올려보자

openAI가 o1 모델을 개발할 때 test-time scaling을 통해 성능 향상을 이끌어냈는데, 방법이 공개되어 있지 않음
- 기존 연구들이 MCTS 등으로 이를 재현해보려 했지만, 실패했음 (high cost & data)

⇒ 가장 단순하고 효율적인 Test-time scaling을 개발해보자 !!!!!!!!!!!!

Contributions (What they’ve revealed)

sample-efficient reasoning data (s1K dataset )생성을 위한 방법 개발 (Section 2)
1. 16가지 시드 데이터셋 중에서, 아래 세가지 기준으로 59,029 questions 선별
  시드 데이터
  NuminaMATH , AIME problems, OmniMath, SAT, LSAT 등 기존 추론 관련 데이터
  자체 생성 데이터
  s1-prob: 스탠포드 대학교 통계학과 박사 자격시험 중 probability section
  s1-teasers: quantitative trading positions에서 흔히 사용되는 두뇌 테스트 문제 중 난이도 Hard
  ⇒ Google Gemini Flash Thinking API를 사용하여 추론 과정과 풀이를 추출
  기준
  Quality: Datasets should be high-quality
  Difficulty: Datasets should be challenging and require significant reasoning effort
  Diversity: Datasets should stem from various fields to cover different reasoning tasks
1. 동일한 조건 (Quality, Difficulty, Diversity)를 기준으로 1000개 샘플만 남김
  why? 가장 심플한! 데이터셋을 만들기 위함
  how to sampling? 순서대로 진행
  1)Quality
  API 오류가 발생한 질문을 제거
  low-quality example 제거
  e.g. inconsistent question numbering, non-existent image reference
  ⇒ 51,381개 남음
  2)Difficulty
  각 문제에 대해 Qwen2.5-7B-Instruct와 Qwen2.5-32BInstruct 중 하나라도 답을 맞출 수 있는 문제는 제외 (너무 쉬운 문제 제거)
  ⇒ 24496개 남음
  3)Diversity
  Claude 3.5 Sonnet을 사용하여 American Mathematical Society의 수학 주제로 분류
  (e.g. 기하학, 생물학, 물리학 등 총 50가지 분류)
  각 분류별로 길이가 긴 (=어려운) 데이터 샘플링
  ⇒ 1000개 남음

test-time scaling 방법 개발
- test-time scaling의 두가지 유형 (Sequential & Pararell) 중에서, Sequential scaling을 수행함
  why? 직관적으로 생각했을 때, 중간 결과를 기반으로 최종 계산을 수행할 수 있으니 더 효율적일 거라서!
  pararell의 예시? majority voting!
- maximum/mininum token의 개수에 constraint를 걺으로서, 간단하게 decoding time을 강제함
  예시
  budget forcing 적용
  maximum token 제약
  추론이 너무 길어질 때, end-of-thinking token delimiter 추가하여 reasoning을 조기에 종료
  ⇒ 마지막에 Final Answer: 를 추가하여 현재까지 추론 결과로 답변을 도출하도록
  minimum token 제약
  모델이 너무 짧은 추론 후 답을 생성하려고 할 때 Wait이라는 추가적인 신호를 입력하여, 모델이 지금까지의 출력을 한 번 더 검토할 기회를 제공
  how to apply?
  Token-conditional control : 모델에게 생성할 길이를 알려줌
  Conditional length-control methods: prompt 에서 maximum length를 지정
  Step-conditional control: 각 reasoning staep의 maximum length를 지정
  Class-conditional control: 짧은/중간/긴 시간동안 생각하도록 prompt 생성
  Rejection sampling: 생성 결과가 정해진 budget에 맞을 때까지 sampling

s1-32B 개발
- 세팅
  Qwen2.5-32B-Instruct를, s1K 데이터로 FT ⇒ s1-32B를 얻음
  실험 데이터
  AIME24: 2024년 1월 31일부터 2월 1일까지 개최된 미국 수학 경시대회 문제들
  MATH500: 다양한 난이도의 수학 경시대회 문제들을 모아놓은 벤치마크 데이터
  GPQA Diamond: 생물학, 화학 및 물리학 분야의 박사 수준 과학 문제
  사용한 metric
  다양한 compute budge에서 동일한 데이터를 여러번 평가함
  Control: 전체 실행 중 목표한 최소/최대 compute 범위 안에 들어오는 비율
  Scaling: compute가 증가할 때 accuracy가 얼마나 증가하는지(평균 기울기)
  Performance: 해당 method가 달성한 최대 성능
- 성능
  test-time compute(token개수) 증가에 따른 성능
  ⇒ 더 자세한 결과!
  token 개수와 성능은 비례하지만, 6배 정도에서 saturate됨
  너무 자주 end-of-thinking token delimiter를 사용하면, 모델이 루프에 빠져버림
  pararell scaling(majority voting)과의 비교
  test-time compute를 아무리 확장해도, 제안하는 방법의 성능을 따라올 수 없음
  다른 모델들(e.g. QWEN r1)과의 비교 결과
  제안하는 scaling이 가장 효율적이다 !!
  model output 예시 (이미지가 너무 길어요ㅠ)
  https://aclanthology.org/2025.emnlp-main.1025.pdf#page=6.48
- ablation study 수행
  data ablation : quality, difficulty, diversity를 고려하지 않았을 때에는 어떤가
  1K-random: Gemini로 추론 결과만 도출하고, 데이터 자체는 랜덤 샘플링
  1K-diverse: difficulty 고려하지 않고, 각 카테고리 별로 랜덤 샘플링
  1K-longest: difficulty만 고려
  59k-full: 전체 데이터 다 활용했을 떄
  어떤 test-time compute control 방식이 제일 좋을까? ⇒ budget forcing 하는게 짱이다!
  Rejection sampling: 길이가 길어지니까 오히려 성능이 낮아짐
  즉, 처음부터 길이가 짧은 답변을 생성하는 경우에 더 정확한 답변을 만든다!