AutoThink: 적응형 추론으로 로컬 LLM 성능 향상

 (news.ycombinator.com)
2P by GN⁺ | ★ favorite | 댓글 1개
  • 로컬 LLM이 질의 난이도에 맞춰 추론 토큰을 조절해, 같은 자원으로 더 효율적인 답변을 만들도록 돕는 기법임
  • 모든 질의에 같은 “생각 시간”을 주는 대신 HIGH/LOW 복잡도로 나눠, 복잡한 추론에는 70~90%, 단순 질의에는 20~40%의 토큰을 배정함
  • Microsoft Phi-4 논문의 Pivotal Token Search 기반 스티어링 벡터로 수치 정확성, 자기 수정, 철저한 탐색 같은 추론 패턴을 유도함
  • DeepSeek-R1-Distill-Qwen-1.5B에서 GPQA-Diamond는 21.72% 기준선 대비 31.06%로 올라 상대 43% 개선됐고, MMLU-Pro는 25.58%에서 26.38%로 상승함
  • DeepSeek, Qwen, 커스텀 파인튜닝 모델 등 로컬 추론 모델에서 동작하며, API 의존 없이 기준 접근보다 더 적은 토큰을 사용함

질의별 추론 자원 조절

  • AutoThink는 로컬 LLM의 추론 자원을 질의마다 다르게 배분하는 적응형 자원 할당 기법임
  • 먼저 질의를 HIGH 또는 LOW 복잡도로 분류한 뒤, 복잡도에 따라 추론 토큰 비율을 조정함
    • 복잡한 추론: 전체 토큰의 70~90%
    • 단순 질의: 전체 토큰의 20~40%
  • 스티어링 벡터는 Pivotal Token Search에서 파생되며, 생성 중 모델의 추론 방향을 안내함
    • 유도하는 행동에는 수치 정확성, 자기 수정, 철저한 탐색이 포함됨
  • 구현은 두 축으로 구성됨
    • 재학습 없이 새로운 복잡도 카테고리를 학습할 수 있는 적응형 분류 프레임워크
    • Pivotal Token Search의 오픈소스 구현

벤치마크 결과와 적용 범위

  • DeepSeek-R1-Distill-Qwen-1.5B에서 다음 결과를 보임
    • GPQA-Diamond: 31.06%, 기준선 21.72% 대비 상대 43% 개선
    • MMLU-Pro: 26.38%, 기준선 25.58% 대비 상승
    • 기준 접근보다 더 적은 토큰을 사용함
  • AutoThink는 로컬 추론 모델 전반에 적용 가능함
    • 예시 모델: DeepSeek, Qwen, 커스텀 파인튜닝 모델
    • API 의존성 없음
  • 관련 자료

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견

  • 저는 AutoThink의 동기 부여가 기존 추론 모델들이 계산 자원을 낭비하는 모습을 보고 시작된 경험임을 밝힘—‘2+2가 뭐야?’ 같은 아주 쉬운 질문에도 복잡한 수학적 증명과 똑같은 만큼의 ‘생각 시간’을 소비하는 비효율성이 명확하게 눈에 들어옴. 놀라운 점은, 별도로 실험하던 적응형 분류(재학습 없이 새 카테고리 학습 가능)와 Microsoft의 Phi-4 논문에서 오픈소스로 공개된 Pivotal Token Search 두 가지를 결합하고 여기에 동적 토큰 예산 할당을 적용하자 예상보다 훨씬 큰 성능 향상이 나온 점임. 실제로 평균적으로 사용된 토큰 수가 줄어들었는데, 간단한 쿼리는 실제로 훨씬 빨리 끝내고 복잡한 쿼리에만 추가 연산을 할당한 효과임. 기술적인 포인트 몇 가지로는 steering vector가 패턴당 1MB 미만으로 작아서 메모리 오버헤드는 거의 없으며, 분류과정이 10ms 정도의 지연만 추가함(무시할 만한 수준임), 그리고 target layer 선택이 중요하다는 점(대부분의 모델에서 중간 레이어 15~20번이 가장 좋은 결과를 보임)임. 피드백을 받고 싶은 부분은— 비슷한 적응형 접근을 해본 경험, 더 유용하게 steer할 reasoning 패턴, 최적의 target layer 자동 탐지에 대한 아이디어임. 구현이나 결과에 대해 궁금한 점은 무엇이든 질문받겠음

    • 이제는 꼭 그렇지도 않음. Gemini 2.5 Pro를 써봤는지 물어봄—간단한 질문엔 거의 ‘생각’하지 않고, 코딩 질문은 긴 논리 기사 같은 답변을 씀. o3도 마찬가지인 것 같음

    • 축하의 말을 전함! LLM 효율화에 관한 모든 시도는 크게 환영함. 지금까지는 Mac Mini M4에서 MLX 모델로 간단한 쿼리만 처리하고, 복잡한 쿼리는 Nvidia 4090으로 보내는 방식으로 게으르게 최적화해옴—M4의 효율성이 Nvidia와 비교해 정말 놀라울 정도임. Apple이 MLX로 가는 길이 옳다고 생각함. AutoThink에 대해 더 읽어보고 개인 워크플로우에도 통합해볼 계획임

    • 필자는 사용자 프롬프트 뒤에 ‘non-reasoning model의 답변’을 삽입하는 방식—예를 들면 “다음은 non-reasoning model이 생각한 내용입니다: ... 이게 사용자가 원하는 결과인가요?”를 시도해볼 가치가 있다고 생각함. 비추론 버전으로 충분할 때는 reasoning model도 답변을 더 빠르게 내릴 수 있는 장점이 있을 수 있음

    • Claude Sonnet 3.5조차(최신 버전인 3.7이나 4도 아닌) 쿼리 복잡도에 따라 처리 시간이 명확히 달라짐—동적으로 처리 시간 조정하는 모습 확인함

  • 질문을 어떻게 ‘복잡한 질문’과 ‘간단한 질문’으로 분류할 수 있는지 궁금함. 겉보기엔 간단한 질문도 실제로 매우 어려울 수 있음. 예를 들어 x³+y³+z³=42 의 정수 해답은 100년 이상의 계산 자원이 소모된 문제임. 또는 x/(y+z)+y/(z+x)+z/(x+y)=4 같은 식도 겉보기에 단순해 보여도 타원곡선 이론이 필요한 억단위(엄청나게 큰 수)의 해가 있음. 솔루션 참조링크

    • 문제의 난이도를 분류하는 건 그 자체로 별개의 기술임—실제 풀이와는 별개로 학습할 수 있는 능력임. 예를 들어 위 식을 봤을 때 바로 세 가지 어려움(정수 범위, 3변수, 3차 방정식)을 눈치채야 함. 이 세 요소가 다 합쳐지면 난이도가 급상승함. 실수나 복소수, 변수 개수가 적거나 차수가 더 낮다면 훨씬 풀기 쉬움. 물론 그렇다고 반드시 어려운 건 아니지만, 미해결 문제일 가능성이 있음. 필자는 실제로 풀 실력은 없지만 어디서 정보 찾을지 감잡는 훈련은 했기에 ‘이거 엄청 어렵다’는 느낌을 바로 파악할 수 있음. LLM도 이런 힌트를 학습해서 문제 난이도를 실제 풀이 없이도 분류하는 능력을 키울 수 있지 않을까 생각함(아니면 이미 배웠을 수도 있음)

    • 이 상황에서의 쿼리 난이도는 정답 데이터셋(GSM8k 등)에서 모델이 올바른 응답을 하기 위해 얼마만큼의 토큰이 소모됐는지에 근거해 정의함. 적응형 분류기는 이 데이터셋에서 학습하고, 이를 추론 단계에서 분류에 활용함

  • Claude 3.7에서 extended thinking 토글이 나왔을 때 저도 비슷한 autothink POC를 만들어봄—심지어 이름도 autothink임
    github.com/NiloCK/autothink
    think-toggles-are-dumb 블로그
    제 버전은 LLM이 쿼리 난이도를 0~100 점수로 채점하는 1차 패스를 거치고, 그 점수에 맞춰 생각 예산을 선형적으로 할당하는 구조임. OP 작업에 비하면 당연히 단순하지만, 정량적인 결과를 보게 되어 정말 기쁨—잘 만든 결과물임!

  • 당연한 최적화라고 생각하고 변화가 벌써 일어나지 않은 게 의아함. 잘 설명하고 직접 구현한 점, 인상 깊음

  • QwQ나 Qwen 3 같은 reasoning 모델에서는 솔직히 결과 개선에 시간 크게 쓰지 않고, 다양한 프롬프트로 reasoning token 출력을 제약하는 시도만 했음. Gemma 3 27B QAT는 reasoning 모델은 아니지만, LLM 체인이나 라우트에서 활용할 때 지시 따르기 성능이 매우 우수해서 사전 분류/언어 최적화에 투입하고 이후 단계에서 실제 reasoning에 활용할 수 있음. 여러 thinking tag 사이에 중간 답변을 교차 출력시키는 것도 가능함. 이런 모델 실험에선 ‘생각 중인 토큰’을 결론과 별개로, 문제 해결 단계별 디딤돌인 모든 토큰으로 정의함. 일부 토큰이나 특정 표현을 우선적으로 사용하도록 지시하면 일반적으로 결과가 개선된 경험이 있고, AutoThink가 데이터셋에서 가장 성능 좋은 토큰을 자동으로 사용하는 방식은 더 일반적이고 효과 좋은 최적화로 활용될 수 있을 법함. 다만 pivot token을 너무 많이 쓰면 벤치마크 질문에만 과적합되는 위험이 있으니 이런 방식이 얼마나 일반화되는지는 좀 더 지켜보고 싶음. 개인적으로는 신중한 워드/토큰 선택이 결과 품질을 크게 향상시키는 저비용 고효율 최적화라 보고 AutoThink의 일반화 능력이 기대됨

  • 소형 모델 덕분에 작은 팀과 개별 연구자도 기존 대형 AI랩 부럽지 않게 혁신적인 접근이나 실험을 쉽게 증명할 수 있게 된 점이 너무 멋짐. SML(Small Language Model) 경쟁력이 올라갈수록 온디바이스에서 구현 가능한 것이 상상 이상으로 확대됨

    • "small language models (SML)"이라는 용어 대신 SLM이 맞는 명칭 같음

  • 다른 사람을 위해 모델을 호스팅한다면 매우 단순한 질문 처리에 컴퓨팅 자원을 아끼는 것도 좋음. 이 경우 모델이 쉽게 판단되는 질문을 소홀히 대하는 단점이 있을 수 있지만 그 비용은 내가 감수하지 않음. 반대로 내 PC에서 직접 모델을 쓰는 경우라면, 이미 GPU에 큰 비용을 투자한 입장에서 최대한 자원 활용하고 싶음—간단한 쿼리까지 연산을 줄이는 건 오히려 원치 않음

  • 좋은 사고거리임! 저희도 AI 크롤러 설계에서 방문하는 사이트별로 더 많은 쿼리를 던질지, 적게 던질지를 유동적으로 인식해야 한다고 내부적으로 논의 예정임. 참고로 저희는 samaritanscout.org로, 다양한 비영리 사이트에 올라온 모든 지역 자원봉사 기회를 한데 모으는 검색 엔진 프로젝트임

  • LLM과 AI 분야에 아주 최근에 입문했지만 이 프로젝트에 깊은 흥미를 느낌. AutoThink가 AI가 문제 난이도에 따라 ‘보다 똑똑하게 생각’하도록 연산 노력을 조절해준다는 점이 직관적으로 매우 인상적임—사람이 2+2 같은 건 바로 풀고, 어려운 문제만 진지하게 고민하는 원리에 비유할 수 있음. 토큰 예산이나 steering vector 등 기술적 요소는 잘 모르지만, 동시에 더 빠르고 똑똑해지는 이런 방식에 매료됨. 계속 지켜볼 계획임

  • LLM에서는 ‘생각’이나 ‘추론’이라는 용어를 쓰지 않는 편이 더 좋다고 생각함—두 단어 모두 특정한 의미와 철학적 배경이 있는데, 실제론 LLM이 그렇게 사고하거나 추론하는 게 아니라 단순히 더 많은 연산(프로세서 시간)을 들여 결과를 생성하는 컴퓨팅 방식에 가까움

    • 이미 그 배는 떠났음. 과거 “컴퓨터”란 단어도 인간 계산자를 뜻했지만 이젠 기계로 의미가 완전히 넘어간 것처럼, 여기서도 용어가 변화한 셈임

    • “ping”에 비유함—IP 주소에 ‘ping’한다고 해서 진짜 금속 선체에 음파를 쏘는 건 아니지만, 실제 동작에 맞춰 비유적으로 쓰임. 유용한 은유라면 현실과 1:1로 일치하지 않아도 일상적으로 사용함

    • 나의 세계관은 원리적으로는 유물론자이며 결정론적임. 그렇지만 일상에선 실존주의와 약간의 영적 감수성까지 더함. 실용적 관점에서 보면 이런 도구에 인격적(anthropomorphic) 속성을 임시로 부여하면, 대화 흐름이 쉬워지고 도구를 직관적으로 파악할 수 있음. 이 방법이 때로는 한계를 보이지만, 그럴 때에는 좀 더 분석적인 틀로 쉽게 전환할 수 있다고 생각함

답변달기