Gemma 4 12B: 숨겨진 추론 비용 (Reasoning Tax)

동기 (Motivation)

최근 로컬 LLM 추론을 위해 RTX 5060 Ti 16GB를 구매했으며, 나의 사용 사례인 기술 문서 작성, 코드 생성, 그리고 중국어 분석에 가장 적합한 모델을 찾고 싶었습니다. Google의 Gemma 4 12B는 VRAM에서 여유롭게 실행될 만큼 충분히 작고, 최첨단 아키텍처(state-of-the-art architecture)를 갖추었으며, 강력한 다국어 지원을 제공하기에 완벽한 선택처럼 보였습니다.

하지만 무언가 이상했습니다. 간단한 질문에도 30~60초가 소요되었습니다. 모델이 광고된 사양과 맞지 않을 정도로 느리게 느껴졌습니다.

그래서 벤치마크를 실행했습니다. 그 결과는 나의 모델 선택을 완전히 바꾸어 놓았습니다.

테스트 설정 (Test Setup)

구성 요소	사양
모델	google/gemma-4-12b (lmstudio-community Q4_K_M, 7.56 GB)
...
내가 추적한 핵심 지표는 유효 출력 (effective output) — 사용자에게 보이는 토큰(tokens) 대 총 생성된 토큰의 비율이었습니다.

결정적 증거: reasoning_content

표준 LM Studio 벤치마크는 completion_tokens를 측정하고 그것으로 끝냅니다. 하지만 Gemma 4 12B는 두 번째 필드를 노출합니다: 바로 reasoning_content — 모델이 가시적인 출력을 생성하기 전에 생성하는 내부 사고 사슬(chain-of-thought) 토큰입니다.

나는 두 필드를 모두 추출하여 그 비율을 측정하는 테스트 하네스(test harness)를 구축했습니다.

짧은 프롬프트 테스트 (15 프롬프트 토큰)

"用一句话说明什么是元认知" (메타인지를 한 문장으로 설명하시오)

지표	값
프롬프트 토큰	15
...
모델은 단순한 정의 질문에 대해 컴퓨팅 자원의 96%를 보이지 않는 내부 사고에 소비합니다.

현실적인 Hermes 워크로드 (1060 프롬프트 토큰)

나는 현실적인 에이전트(agent) 워크로드를 시뮬레이션했습니다: 전체 시스템 프롬프트(페르소나/컨텍스트/메모리 약 900 토큰)와 짧은 지시사항을 결합했습니다:

"继续写S1的章节结构" (S1의 장 구조 작성을 계속하시오)

지표	값
프롬프트 토큰	910
...
현실적인 에이전트 워크로드에서도 생성량의 3분의 2는 보이지 않는 추론(reasoning)입니다. 20초가 걸려야 할 응답이 65초가 걸립니다.

전체 테스트 매트릭스 (Full Test Matrix)

시나리오 (Scenario)	컨텍스트 (Context)	가시적 출력 (Visible, 글자 수)	추론 (Reasoning, 글자 수)	낭비 비율 (Waste %)
단순 질의응답 (Simple Q&A, 20자)	15 tok	60	1398	96%
...
최악의 시나리오는 **짧은 프롬프트 (short prompts)**입니다. 모델의 추론 (reasoning)이 전체 토큰 예산을 모두 소비하여, 가시적인 출력 (visible output)을 위한 공간이 거의 남지 않게 됩니다.

비교: Qwen3 30B A3B (추론 낭비 제로)

참고를 위해, 동일한 하드웨어에서 30B 파라미터 MoE 모델(활성 파라미터 3B)인 Qwen3 30B A3B에 대해서도 동일한 테스트를 수행했습니다:

지표 (Metric)	Gemma 4 12B	Qwen3 30B A3B
VRAM	7.56 GB	17.28 GB
...
Qwen3 30B A3B는 reasoning_content가 전혀 없습니다 (zero). 생성되는 모든 토큰이 가시적인 출력입니다. 더 큰 모델임에도 불구하고 실질적인 처리량 (effective throughput)은 3배 더 높습니다.

이것이 중요한 이유

채팅 / 대화형 사용의 경우

Gemma 4 12B를 채팅용으로 사용하는 경우, 사용자의 모든 메시지는 숨겨진 추론 (reasoning) 단계를 트리거합니다. 짧은 답변(한두 문장)의 경우 추론이 전체 토큰 예산을 소비하기 때문에 특히 더 고통스럽습니다.

에이전트 / 도구 사용의 경우

에이전트 프레임워크 (Hermes Agent, Claude Code 등)는 도구 정의 (tool definitions)가 포함된 대규모 시스템 프롬프트 (system prompts)를 전송합니다. 우리의 테스트 결과에 따르면, 약 1000 토큰의 컨텍스트 (context) 환경에서 Gemma는 여전히 생성 과정의 **67%**를 생각하는 데 낭비합니다. 즉, 당신의 에이전트는 단순 토큰/초 (tok/s) 수치가 시사하는 것보다 3배 더 느립니다.

배치 처리 (Batch Processing)의 경우

긴 형식의 생성 (long-form generation, 수천 개의 출력 토큰)만 수행한다면, 추론 오버헤드 (reasoning overhead)가 차지하는 비율은 작아집니다. 4000 토큰 응답의 경우 낭비 비율이 20-30%에 불과할 수 있습니다. 하지만 대화형 사용에서는 이를 감당하기 어렵습니다.

추론을 비활성화할 수 있나요?

아니요 — 모델 아키텍처 (architecture)에 내장되어 있습니다. reasoning_content 동작은 Gemma 4 학습의 일부입니다. 설정 가능한 추론 모델 (GPT-4o, Claude 등)과 달리, 이를 거부할 수 없습니다:

• "생각하지 마라"는 시스템 프롬프트 지시는 효과가 미미합니다.
• LM Studio 설정에는 추론 토글 (reasoning toggle)이 노출되어 있지 않습니다.
• 모델은 단순히 순전파 (forward pass) 과정의 일부로서 추론을 생성합니다.

일부 GGUF 양자화 (quantizations) 버전은 추론 템플릿 (reasoning template)을 제거하려고 시도하지만, lmstudio-community 변체들을 대상으로 한 테스트에서도 여전히 해당 동작이 관찰됩니다.

언제 Gemma 4 12B를 사용해야 할까요?

이러한 문제에도 불구하고, Gemma 4 12B는 진정한 강점을 가지고 있습니다:

1. VRAM 효율성: 7.56 GB를 사용하여 임베딩 모델 (embedding models), 두 번째 모델, 또는 더 큰 배치 크기 (batch sizes)를 위한 여유 공간을 확보할 수 있습니다.
2. 순수 추론 속도가 빠름: 추론 과정을 지나치고 나면 출력 속도는 약 8.7 tok/s입니다.
3. 배치 / 오프라인 작업: 매우 긴 문서를 생성하며 추론 오버헤드 (reasoning overhead)가 허용 가능한 수준인 경우 적합합니다.

하지만 **대화형 사용 (interactive use), 단문 응답, 그리고 에이전트 워크로드 (agent workloads)**를 위해서는 다음과 같은 대안을 강력히 추천합니다:

• Qwen3 30B A3B: 3배의 유효 속도, 추론 낭비 제로, 17.28 GB VRAM
• Qwen 3.6 35B A3B MTP: 유사한 성능, 약간 더 큰 크기
• Gemma 4 E4B (7.5B): 더 가볍지만, 여전히 추론 문제가 있을 수 있음

방법론 (Methodology)

모든 테스트는 stream: false 설정과 함께 LM Studio API (/v1/chat/completions)를 사용했습니다. 응답에서 content와 reasoning_content를 모두 추출했습니다. "낭비 (waste)" 지표는 다음과 같이 정의됩니다:

waste = reasoning_chars / (reasoning_chars + content_chars)

테스트는 Linux 호스트에서 LM Studio 서버 (RTX 5060 Ti 16GB, 프록시 없음)로 SSH를 통해 curl과 Python을 사용하여 수행되었습니다.

결론

Gemma 4 12B는 유능한 모델이지만 중요한 주의 사항이 있습니다: 무엇을 벤치마킹하고 있는지 스스로에게 물어보십시오. 만약 completion_tokens만 측정한다면, 전체 이야기의 2/3를 놓치고 있는 것입니다. 숨겨진 추론 세금 (reasoning tax)으로 인해 이 모델은 대화형 사용 시 겉으로 보이는 것보다 3배 더 느립니다.

기술 문서 작성, 코드 생성, 그리고 중국어 분석이라는 저의 사용 사례를 위해, 저는 Qwen3 30B A3B로 전환했습니다. 더 큰 VRAM 점유율은 3배의 처리량 (throughput) 이득을 얻을 만큼 가치가 있습니다.

교훈: 현대적인 LLM을 벤치마킹할 때는 항상 reasoning_content를 확인하십시오. 보이지 않는 것이 당신의 속도를 늦출 것입니다.