0.6B 모델의 정답률이 0에서 100으로 — 바꾼 건 모델이 아니라 입력이었다

8년 된 골동품 안드로이드 폰에서 0.6B 모델의 정답률이 0%에서 100%로 뛴 비결이라니… 보고도 눈을 의심했다.

로컬 LLM 실험의 진짜 묘미는 뜬구름 잡는 벤치마크 점수가 아니라, 일상적인 기기에서 일어나는 기적 같은 수치를 목격할 때 나온다. 어제 r/LocalLLM에 올라온 글이 딱 그런 이야기다. 서랍 속에 처박혀 있던 8년 된 구형 스마트폰에서 손톱만 한 0.6B 모델을 돌리던 유저가, 모델 가중치는 단 1도 건드리지 않은 채 질의응답 정답률을 0%에서 100%로 수직 상승시켰다. 도대체 무엇을 바꿨길래? 범인은 모델이 아니라 ‘입력 데이터’였다.

어떤 실험인가

실험 무대부터가 참 눈물겹다. 무려 삼성 갤럭시 노트 8(이게 아직도 액정이 켜진다는 사실부터 놀랍다). 안드로이드 Termux 환경 위에 llama.cpp를 올리고, 3B 이하의 초경량 모델들만 골라서 테스트하는 가혹한 환경이다. 클라우드에서 돌아가는 수백 기가짜리 초거대 모델들과는 비교조차 민망한 장비다. 하지만 그렇기 때문에 더 현실적이고 값지다. 우리 주머니 속에 굴러다니는 현실의 기기들이 딱 이 수준이니까.

과제는 아주 단순했다. 위키피디아 웹페이지 하나를 가공되지 않은 날것의 HTML 그대로 모델에 던져주고, 그 본문 속 내용에 대해 질문을 던져 정답을 맞히게 하는 것. 원본 HTML은 자그마치 46만 자에 달했다. 온갖 div 태그와 복잡한 자바스크립트, 내비게이션 바, 수백 개의 각주 링크가 뒤범벅된 쓰레기통 상태 그대로였다.

Qwen3-0.6B 모델은 세 번 도전해서 세 번 모두 장렬하게 침몰했다(0/3). 그냥 틀린 것도 아니었다. 한 번 답을 내놓겠다고 폰이 뜨끈뜨끈하게 불타오르며 35분에서 44분을 끙끙 앓다가 헛소리를 뱉었다. 고작 질문 하나에 폰이 40분 동안 배터리를 태웠는데 결과가 0점이라는 뜻이다. 보통 사람이라면 “에이, 역시 0.6B 쓰레기 모델이네” 하고 앱을 지웠을 것이다. 하지만 작성자는 포기하는 대신 판을 바꿨다.

입력을 정제하니 결과가 180도 뒤집혔다

모델 아키텍처나 가중치는 단 1바이트도 수정하지 않았다. 오직 모델 입에 들어가는 밥(입력 데이터)만 바꿨다. 똑같은 위키피디아 문서를 E2LLM/SiFR 라이브러리를 통해 핵심 정보만 발라낸 구조화된 스냅샷으로 정제해서 다시 먹였다. 46만 자에 달하던 방대한 HTML 텍스트가 단 200토큰 안팎의 깔끔한 요약본으로 다이어트를 끝냈다.

체감상 이런 극적인 차이다:

[원본 입력 · 46만 자 (노이즈 지옥)]
<!DOCTYPE html><html class="client-nojs">
<head><script>document.documentElement.className="client-js";
window.dataLayer=window.dataLayer||[];...</script>
<style>.mw-parser-output .infobox{border:solid #a2a9b1;...
→ 정답 텍스트가 온갖 태그와 잡다한 스크립트 속에 완전히 파묻혀 있음

[구조화 스냅샷 · 약 200 토큰 (핵심만 압축)]
주제: (문서 제목)
사실:
- 핵심 팩트 1
- 핵심 팩트 2
→ 질문과 직결된 알맹이 정보만 깔끔하게 남김

결과는 소름 돋을 정도로 완벽했다. 열 번 시도해서 열 번 모두 정답을 맞혔다(10/10). 정답을 뱉어내는 데 걸린 시간은 40분이 아니라 채 1분도 걸리지 않았다. 똑같은 폰, 똑같은 0.6B 모델, 똑같은 질문이었는데 말이다.

이 엄청난 격차는 모델이 짊어져야 했던 ‘노이즈 분리’ 부담에서 비롯됐다. 날것의 46만 자 HTML에서는 수만 줄의 쓰레기 태그 사이에서 정답 조각을 찾아내는 탐정 놀이까지 작은 모델의 어깨에 지워져 있었다. 하지만 스냅샷 환경에서는 정제된 사실을 읽고 문맥에 맞게 답하는 순수한 ‘독해’ 작업만 남았다. 값비싼 파인튜닝도, 더 거대한 모델도 필요 없었다. 입력 단계에서 전처리를 똑똑하게 해주니 0.6B짜리 꼬마 모델도 제 몫을 200% 해낸 셈이다.

체급(파라미터)보다 세대(Generation)가 깡패다

이 실험에는 흥미로운 대조군이 하나 더 있었다. 바로 Gemma-3-1B와 Llama-3.2-1B다. 파라미터 체급만 따지면 0.6B보다 거의 두 배 가까이 큰 녀석들이다. 그런데 놀랍게도 이 두 모델은 둘 다 0점을 받았다. 200토큰으로 깔끔하게 구조화된 입력을 떠먹여 줘도 맥락을 소화하지 못하고 헤맸다.

여기서 나온 통찰이 아주 흥미롭다. 모델의 성능 하한선을 결정짓는 건 단순히 뚱뚱한 파라미터 숫자가 아니라 ‘학습된 세대(Architecture Generation)’라는 사실이다. 최신 세대 테크닉으로 학습된 소형 모델은 잘 정제된 문맥을 소화할 줄 아는 반면, 이전 세대 모델은 덩치가 커도 그 독해력을 발휘하지 못한다. “작은 모델이냐 큰 모델이냐”는 단순한 체급 논쟁보다 “얼마나 최신 세대의 모델이냐”가 훨씬 중요해진 셈이다.

레딧 댓글에서도 쏠쏠한 모바일 실전 팁들이 쏟아졌다. 안드로이드 모바일 GPU에서 0.5B급 모델을 돌리면 OpenCL 디스패치 오버헤드 때문에 오히려 느려지니, 이 체급에서는 그냥 CPU 코어로 돌리는 게 훨씬 빠르다는 조언부터, “파라미터 숫자놀음보다 잘 구조화된 컨텍스트가 백배 낫다(raw parameters < structured context)”는 명언에 수많은 추천이 박혔다.

왜 여기에 주목해야 할까

그동안 AI 업계의 화두는 언제나 “더 거대한 모델”이었다. 파라미터를 수천억 개로 늘리고, 학습 데이터를 수십 테라바이트 때려 붓고, 데이터센터에 수천억을 쏟아붓고… 하지만 이 작은 안드로이드 실험이 잡아당긴 레버는 완전히 반대 방향을 가리킨다. 모델은 가볍게 둔 채, 들어가는 데이터의 순도를 극한으로 끌어올리는 접근이다. 효과는 0%에서 100%라는 숫자로 증명됐고, 실행된 기기는 누구나 서랍에 하나쯤 굴러다니는 구형 스마트폰이다.

온디바이스 AI 관점에서도 시사하는 바가 크다. 모든 질의응답이 구형 폰 안에서 완결됐고, 데이터는 와이파이 망을 단 1바이트도 타지 않았다. 개인 건강 기록, 사적인 일정, 민감한 계약서 같은 데이터들을 굳이 불안하게 클라우드로 쏘아 올리지 않아도, 폰 안에서 안전하게 요약하고 검색할 수 있는 길이 열린 것이다. 8년 전 출시된 고물 폰에서도 이 정도가 돌아가는데, 최신 NPU를 탑재한 요즘 폰들이라면 말할 것도 없다.

정리

정답률 0%와 100% 사이를 가른 것은 값비싼 슈퍼컴퓨터가 아니라, 모델의 입맛에 맞게 다듬어진 똑똑한 입력 한 줄이었다.

규모는 작지만 이 실험이 주는 교훈은 묵직하다. 더 비싼 모델, 더 큰 GPU를 결제하기 전에 내가 모델한테 먹이고 있는 프롬프트와 입력 데이터의 순도부터 점검하자. 가장 저렴하면서도 극적인 성능 향상은 언제나 입력 파이프라인에서 나오는 법이니까!