1.74GB 모델이 「AIME 94.3, LiveCodeBench 80.2」라고 주장하고 있습니다.

차원이 다른 대형 플래그십 모델들과 경쟁한다는 홍보 문구입니다.

정말일까요?

저는 단순히 숫자를 인용하는 것만으로는 믿을 수 없었습니다.

제 손에 있는 Apple M5로, 암기할 수 없는 문제와 저 자신의 비공개 코드를 먹여서 직접 확인했습니다.

먼저 결론부터 쓰겠습니다.

문제를 풀거나 코드를 읽는 능력은 정말 강력합니다. 하지만 이것은 「정답 엔진(Answer Engine)」이지 「에이전트(Agent)」는 아닙니다. 태스크가 깊고 길어지면 무너집니다.

VibeThinker-3B (WeiboAI)입니다.

만든 곳은 Sina Weibo의 AI 팀입니다. 생소할 수도 있습니다.

목표는 한 점에 집중되어 있습니다. 「작은 모델로 검증 가능한 추론(Verifiable Reasoning)을 어디까지 끌어올릴 수 있는가".

논문 제목이 곧 주장입니다 ―― Exploring the Frontier of Verifiable Reasoning in Small Language Models.

보통 3B 클래스의 소형 모델은 「적당히 무엇이든 해내는 범용 어시스턴트(General Assistant)」를 목표로 합니다.

VibeThinker는 반대였습니다. 수학과 코드라는, 정답 확인이 가능한 영역에 올인하고 있습니다.

그 결과가 서두에 언급한 숫자입니다. 3B임에도 불구하고 차원이 다른 DeepSeek V3.2나 GLM-5, Gemini 3 Pro와 경쟁하는 스코어를 내며, 「3B가 어떻게 그럴 수 있느냐」며 벤치마크 업계에서 논란을 불러일으켰습니다.

그리고 가중치(Weights)와 훈련 코드도 공개되어 있습니다. 그렇기에 이렇게 직접 내려받아 확인할 수 있습니다.

베이스는 Qwen2.5-Coder-3B → Qwen2.5-3B입니다. 즉 코드 계열 베이스의 추론 특화 모델입니다.

4bit 양자화(Quantization) 시 1.74GB입니다. 제 손의 M5에서 약 45~63 tok/s로, 완전히 로컬, 무료, 오프라인으로 동작합니다.

from mlx_lm import load, generate
model, tok = load("mlx-community/VibeThinker-3B-4bit") # 1.74GB

하드웨어에 대해 한마디만 하겠습니다.

M5는 GPU의 각 코어에 Neural Accelerator를 탑재하고 있으며, MLX는 그 **GPU (Metal)**를 사용합니다.

16코어의 Neural Engine (ANE)은 Core ML용이며, Transformer의 LLM 추론에는 사용되지 않습니다.

따라서 「M5에서 빠르다」는 것은 GPU의 힘입니다. 그리고 3-4B/4bit 모델은 애초에 기기를 가리지 않습니다.

오염 방지(Contamination-free)가 된 벤치마크만 보겠습니다.

LiveCodeBench v6: 80.2 (코드. 모델 학습 종료 후에 공개된 신규 문제만을 사용 = 암기 불가능) -
AIME26: 94.3 (수학) 미공개 LeetCode (2026년): 96.1%

3B가 이 숫자를 내는 것은 확실히 눈길을 끕니다.

하지만 이것은 타인이 측정한 숫자입니다. 그래서 저는 다음에 직접 확인했습니다.

여기서 비교도 해두겠습니다.

동일한 ~3-4B 클래스인 Google의 범용 소형 모델 Gemma 4 E4B와 나란히 놓으면 다음과 같습니다.

추론과 코드에 한해서는, 1.74GB의 전문 특화 모델이 Google의 소형 모델을 2배 가까이 앞서고 있습니다.

다만, 이 부분은 솔직하게 선을 긋겠습니다.

제가 비교한 것은 추론과 코드 벤치마크의 숫자뿐입니다.

Gemma의 범용 성능 (이미지, 일본어, 지시 이행)은 저 자신이 아직 측정하지 않았습니다. 따라서 「범용이라면 Gemma가 위다」라고 여기서는 말하지 않겠습니다. 그것은 검증되지 않은 단정이 될 것입니다.

말할 수 있는 것은 설계상의 위치 선정과, VibeThinker 측에서 실제로 본 것뿐입니다.

• 설계: Gemma 4는 멀티모달 (Multimodal)·다국어 범용 모델(이미지도 입력 가능)입니다. VibeThinker는 추론/코드 특화 모델로, 이미지는 다룰 수 없습니다.
• 관측: VibeThinker의 「특화로 인한 약점」을 저는 직접 목격했습니다. 일본어로 상식을 물으면 다른 문제(미분)를 풀기 시작하고, JSON으로 출력하라고 요청해도 출력하지 않으며, 긴 추적 과정에서는 무너졌습니다.

즉, 「수학·코드를 풀게 하는 것」이라면 VibeThinker는 강력합니다. 반면 범용 용도는 VibeThinker의 약점이며, 그 부분을 Gemma 등의 범용 모델이 담당하는 것이 자연스럽습니다. 다만 「범용 모델로서 Gemma가 얼마나 강력한가」는 제가 별도로 측정해야 할 숙제입니다.

(VibeThinker의 벤치마크는 공식 논문, Gemma의 수치는 이차 정보이며, Google 공식 확인 작업은 계속 진행 중입니다.)

전형적인 LeetCode 문제는 사용하지 않았습니다.

인터넷에 떠도는 문제는 모델이 암기하고 있을 가능성이 있기 때문입니다.

그래서 제가 그 자리에서 만든, 세상에 존재하지 않는 오리지널 문제를 5문제 출제했습니다. 규칙도 독자적입니다.

각 문제에 대해, 저의 참조 구현(Reference Implementation) + 랜덤 경계 사례(Boundary Case)로 생성된 코드를 실제로 실행하여 채점했습니다.

예를 들어, 제가 임의로 정한 이 규칙입니다.

encode(s): 동일한 문자의 연속이 3개 이상이면 「문자+개수」로, 
1~2개라면 그대로. 'aaabbc' -> 'a3bbc'

결과는, 로직 5/5 정답이었습니다.

「최장 양의 정수 교차 부분 수열」과 같이 약간 머리를 써야 하는 문제도 모든 케이스를 통과했습니다.

암기가 아닙니다. 본 적 없는 문제를 정말로 풀고 있습니다.

LiveCodeBench 80.2라는 숫자가 제 손에서 납득되었습니다.

이 부분이 이번에 가장 확인하고 싶었던 것입니다.

저는 yuewei라는 개인 정보 시스템을 운영하고 있습니다.

그 코드는 공개하지 않았습니다. 모델이 학습했을 가능성은 제로입니다.

먼저, assess_article_signal이라는 실제 함수를 하나 전달하고 제어 흐름(Control Flow)을 물었습니다.

「어떤 조건에서 『고시그널 없음』으로 판정하는가」, 「어떤 기사에서는 어떤 kind와 confidence가 되는가」, 「분기 우선순위는 무엇인가」.

3문제 모두 정답이었습니다. 「일단 industry_dynamic으로 떨어진 뒤, karpathy와 anthropic의 조건으로 덮어씌워져 0.96이 된다」는 복잡한 흐름까지 완벽히 추적했습니다.

다음으로 부하를 높입니다.

**모듈 전체(signals.py, 약 4000토큰, 키워드 사전도 전부 포함)**를 전달하고, 구체적인 기사 3건에 대해 출력을 예측하게 했습니다.

정답 확인은 실제로 그 코드를 실행한 결과와 대조했습니다.

3건 모두 완전 정답.

게다가 account_name이 특정 집합에 포함되면 confidence가 0.92가 된다는 사소한 함정까지 맞혔습니다.

집중된 실제 코드라면, 읽고, 추적하고, 구체적인 입력에 올바르게 적용할 수 있다. 이는 지켜보면서 솔직히 대단하다고 생각했습니다.

여기서부터는 솔직한 이야기입니다.

부하를 더 높여, **3개 파일(signals + screener + analyzer, 약 18000토큰)**을 전달하고 파일을 넘나드는 추적을 시켰습니다.

무너졌습니다.

「그 부분을 찾으려고... 그 부분에는... 하지만 읽지 않으면...」이라는 반복 루프(Loop)에 빠져, 9000토큰을 다 쓰고도 답을 내놓지 못했습니다.

공식 권장 사항인 temp=0.6에서도 마찬가지였습니다.

원인을 분류해 보았습니다.

즉, 범인은 컨텍스트의 「양」이 아닙니다.

18K를 넣어도 질문이 간단하면 괜찮았습니다.

6.8K라도 추론 체인(Reasoning Chain)이 길고 복잡하면 무너졌습니다.

범인은 「추론의 길이와 복잡성」입니다. 창(Window)이 128K라 해도, 안정적으로 사용할 수 있는 작업 기억(Working Memory)은 훨씬 작습니다.

또 하나, 에이전트로서 치명적인 약점이 있습니다.

JSON으로 출력하라고 요청해도 끝없이 추론만 하고 내놓지 않습니다.

함수명을 score로 지정했는데, calculate_score라고 이름을 붙입니다.

지시나 포맷을 순순히 따르지 않는다.

(보충: Greedy 디코딩 (Greedy decoding)은 가짜 붕괴, 즉 반복 읽기를 유발했습니다. 권장되는 temp=0.6 설정에서는 대부분 해결되지만, 가장 부하가 큰 상황에서는 여전히 붕괴됩니다. 평가 설정에 따라 결론이 달라질 수 있다는 교훈을 얻었습니다.)

적성과 부적성이 명확합니다.

적합한 것:

• 자기 완결적인 문제를 푸는 로컬 엔진 (알고리즘, 수학, 코드).
• 집중된 코드 조각의 설명·리뷰·트레이스 (함수 1개, 모듈 1개라면 정확함).
• 파이프라인의 "답변 부품". 외부에서 작고 명확한 부분 문제를 전달하고, 출력을 검증하는 방식의 사용법.

오프라인, 무료, 보안이 필요한 상황에서 특히 효과적입니다.

적합하지 않은 것:

• 자율 에이전트 (Autonomous Agent) / 도구 호출 (Tool calling)의 사령탑 (포맷을 지키지 않고, 탈선하며, 장기적인 작업에서 붕괴됨).
• 리포지토리 전체 / 대규모 파일 횡단 수정.
• 일상적인 범용 채팅 (이것은 답변용 뇌이지, 어시스턴트가 아닙니다).

이는 로컬 AI 코딩을 실측한 Vicki Boykis의 견해—로컬은 "부품"이며, 오케스트레이션(Orchestration)이나 도구는 외부라는 관점—와 그대로 맞닿아 있습니다.

한마디로 요약하자면 다음과 같습니다.

VibeThinker-3B는 강력한 로컬 "답변 뇌"입니다. 잘게 나누어 정확하게 전달하면 강력합니다. 대국적인 흐름이나 점점 불어나는 컨텍스트를 통째로 맡기면 붕괴됩니다.

• 직접 만든 문제 몇 가지를 바탕으로 한 저의 실측 결과입니다. 공개 벤치마크를 대신할 수는 없습니다. 능력의 "수치"는 LiveCodeBench / AIME를 확인해야 합니다.
• 4bit 양자화 (Quantization) 버전에서의 결과입니다.
• 붕괴에는 temp=0.6 단발 관측도 포함됩니다. 샘플링에는 변동성이 있습니다.
• Gemma의 비교치는 이차 정보이며, 공식적인 확인 작업은 계속 진행 중입니다.

그럼에도 불구하고 방향은 확실해졌습니다.

"똑똑한 것"과 "에이전트가 될 수 있는 것"은 별개의 문제입니다. 1.74GB인 이 모델은 전자(똑똑함)에 있어서는 진짜였습니다. 후자(에이전트)는 아직 다른 도구의 영역입니다.

검증 환경: Apple M5 / MLX / mlx-community VibeThinker-3B-4bit. 코드 채점은 생성된 코드를 실행하여 저의 참조 구현과 대조함. 코드 이해는 저의 비공개 리포지토리 yuewei의 실제 코드를 사용함.

원문 기사 및 관련 기사는 AI Watch 본 사이트에서 읽으실 수 있습니다.

👉 https://aiwatch-jp.pages.dev/vibethinker-3b-local

―― AI 미래 편집실 「AI Watch」