Gemma 4 thinking 불안정 QAT MTP llama.cpp speculative decoding

🔍 Qwen을 걷어내고 나서 보이기 시작한 그림자

이전 글에서 Qwen을 다 걷어내고 Gemma 하나만 남긴 이야기를 했어요. 빠르고, 충분히 똑똑했고, 실사용 만족도도 좋았으니까요. 결론부터 말하면 그 결정 자체는 지금도 옳았다고 봐요. 그런데 모델 하나만 단독으로 굴리기 시작하니까, 듀얼로 돌릴 때는 안 보이던 표면적이 새로 열렸어요. 이번 글은 그 그림자에 대한 솔직한 회고예요.

증상부터 말할게요. 회사에서 Cline과 opencode로 Gemma를 헤비하게 굴리면, 가끔 응답이 비어서 돌아왔어요. 어떤 때는 tool-call JSON이 깨진 채로 오고, 또 어떤 때는 모델이 끝없이 생각만 하다가 발산했어요. Cline은 이런 에러를 뱉었어요.

Error: empty or unparsable response
       from the model. Retrying may help.

재밌는 건, 재시도하면 대체로 성공했다는 거예요. 단순한 단일 tool 요청은 8번 중 8번 멀쩡했고요. 그러니까 “모델이 완전히 망가졌다”가 아니라 “헤비하게 굴리면 간헐적으로 무너진다”에 가까웠어요. 정확한 발생 빈도는 측정 안 했으니 숫자로 못 박진 않을게요. 다만 패턴은 분명했어요. 증상이 시작된 시점이 2026-06-10, 그러니까 MXFP4에서 QAT로 가중치를 갈아끼우고, draft-MTP를 추가하고, llama.cpp를 v9586으로 올린 직후였거든요.

📋 첫 의심은 틀렸어요 — 양자화 A/B

가장 먼저 떠오른 가설은 누구나 떠올릴 그거였어요. “Q4로 양자화했더니 멍청해진 거 아냐?” 직관적으로 그럴듯하잖아요. 정밀도를 깎았으니 추론이 흔들렸다는 거죠. 그래서 직접 A/B를 돌렸어요. seed=42 고정으로 결정론적으로, MXFP4 가중치와 QAT 가중치를 같은 프롬프트 4개(추론·코드·사실·한국어)에 통과시켰어요.

결과는 제 직관을 정면으로 깼어요. 네 프롬프트 전부 동률이었고, 한국어에선 오히려 QAT가 살짝 나았어요. 고전적인 bat-and-ball 추론 문제도 양쪽 다 $0.05로 맞혔고요. 양자화는 범인이 아니었어요. 이건 외부 근거와도 맞아요. Google이 Gemma 4 QAT를 발표하면서 QAT가 perplexity 저하를 크게 줄인다고 했고(2026-06-05 출시, 현행 세대 맞아요), Unsloth 문서도 reasoning·tool·멀티모달에서 체감 저하가 거의 없다고 정리해요. 학술 쪽도 비슷해요. Quantization Meets Reasoning은 저비트 PTQ가 수학 추론을 떨어뜨리는 경향이 있지만 QAT가 그걸 완화한다고 봐요.

딱 하나 갈린 지점은 최난도 AIME 수학이었어요. Qwen이 738을 맞히고 Gemma가 657로 틀렸죠(대칭 케이스를 빠뜨렸어요). 그런데 이건 단일 샘플이고, 양자화 탓이 아니라 모델 자체의 천장이에요. 실무에서 진짜 어려운 수학은 어차피 프론티어 모델(Claude)이 담당하니까, 운영상 큰 문제는 아니었어요.

🛠️ 진짜 범인 1 — thinking이 기본으로 켜져 있었어요

양자화가 아니면 뭘까. 로그를 토큰 단위로 뜯어봤어요. 그러다 한 방에 잡혔어요. Gemma QAT 템플릿은 thinking(추론 채널)이 기본 ON이에요. 클라이언트가 enable_thinking:false를 명시적으로 안 보내면, 추론 채널이 토큰 예산을 다 먹어버려요. 그러면 정작 사용자에게 보여줄 content가 빈 채로 끝나거나(finish=length), 끝없는 reasoning 루프로 발산해요.

측정값이 깔끔하게 말해줘요. “120자 문단 하나 써줘” 같은 평범한 요청을 던졌더니 이렇게 나왔어요.

# 기본 요청: "120자 문단 하나 써줘"
reasoning_len = 2797    # 추론에 다 써버림
content_len   = 0       # 정작 답은 텅 빔
finish_reason = "length"  # 토큰 예산 소진

같은 프롬프트에 enable_thinking:false와 /no_think를 붙였더니, 즉시 정상으로 돌아왔어요.

# enable_thinking:false + /no_think
content_len   = 687
finish_reason = "stop"    # 정상 종료

요청은 이런 식이에요. 800토큰짜리 예산으로도 추론 채널이 켜져 있으면 답이 안 나오던 게, 채널을 끄니까 687자가 멀쩡히 나왔어요.

curl http://{LLAMA_HOST}:8080/v1/chat/completions \
  -d '{
    "messages": [
      {"role": "user",
       "content": "120자 문단 써줘 /no_think"}
    ],
    "chat_template_kwargs": {
      "enable_thinking": false
    }
  }'

이게 Cline의 “empty response”와 opencode의 “발산”을 그대로 설명해줘요. 외부에서도 같은 증상이 보고돼요. Gemma 4를 llama.cpp로 굴릴 때 tool-call 데이터가 reasoning 필드로 새고 content가 비는 사례, 그리고 opencode + Gemma 4에서 tool calling을 고치는 기록이 있어요. Gemma 고유의 빈-content tool-call 버그는 llama-server 쪽 PEG 파서(PR #21326)와 후속 수정(#21343)으로 잡히고, --jinja 옵션이 사실상 필수예요.

# Gemma 4 tool-call 파싱: --jinja 필수
llama-server -m gemma-4-qat-q4.gguf --jinja

한 가지 솔직하게 분리해 둘게요. “6-10 QAT 교체 때 thinking 기본값이 ON으로 바뀌었다”는 건 추정이에요. 시점이 겹친다는 정황만 있고, 이전 MXFP4 모델의 동작을 따로 검증하진 않았거든요. 인과로 단정하지는 않을게요. 참고로 같은 변수가 Vision/OCR에서도 똑같이 작동했어요. thinking이 켜져 있으면 어려운 이미지에서 추론으로 토큰을 다 써버려 content가 비고, 그걸 보고 “모델이 OCR을 못한다”고 오판하기 쉬웠어요. thinking을 끄면 밀집 문서 OCR이 1.4초에 정확히 나왔고요.

🛠️ 진짜 범인 2 — +35% 속도의 대가, MTP

두 번째 요인은 속도 최적화였어요. draft-MTP(multi-token prediction) speculative decoding을 붙여서 디코드 속도를 80.8에서 109.3 tok/s로, 그러니까 +35% 끌어올렸어요. draft acceptance도 ~82%로 꽤 높았고요(n=2 기준). 숫자만 보면 공짜 점심처럼 보였어요. 그런데 여기에 미묘한 함정이 있었어요.

이론적으로 speculative decoding은 lossless여야 해요. 그런데 이 “lossless”가 정확히 뭘 보장하는지가 핵심이에요. 외부 자료를 직접 확인하면서 제 안에 있던 모순이 풀렸어요.

이 구분이 왜 중요하냐면, 우리 내부에서도 두 문서가 충돌하고 있었거든요. 벤치 문서는 “lossless — target 모델이 모든 토큰을 검증한다”고 적었고, 진단 문서는 “sample-match라 lossless가 보장되지 않는다”고 적었어요. 같은 날짜에 쓴 두 글이 서로 다른 말을 한 거죠. 그런데 위 정의를 적용하면 둘 다 맞아요. 분포는 보존되지만(벤치 문서가 본 것), 커밋된 토큰은 갈릴 수 있어요(진단 문서가 본 것). 모순이 아니라 같은 현상의 두 측면이었어요.

외부 증거도 진단 쪽을 받쳐줘요. llama.cpp의 draft-mtp는 고정 seed와 temp 0에서도 non-spec 베이스라인과 다른 토큰 스트림을 냅니다(--spec-draft-n-max 3에서 재현). 토큰이 갈리면 tool-call JSON이 깨질 수 있고, 그러면 unparsable이 되어 재시도가 필요해져요. 제가 본 증상과 결이 맞죠.

참고로 MTP의 미성숙함은 다른 데서도 드러나요. Apple Silicon(Metal)에선 모든 config에서 throughput 순손실이 보고됐어요(100% acceptance에서도 -11%, 심한 경우 -28%). 우리는 Blackwell GB10이라 직접 해당되진 않지만, 2026년 중반 시점에 MTP self-speculative가 아직 무르익지 않았다는 방증이에요. 수정 비용도 명확해요. MTP를 끄면 tool-call 손상은 사라지지만 -35% 속도를 반납해야 해요. 그게 트레이드오프예요.

📊 네 가지 후보 원인, 한눈에

지금까지의 진단을 표로 정리하면 이래요. 확정과 추정, 기각을 명확히 구분하는 게 이 회고의 핵심이에요.

그리고 이 실패 클래스(“reasoning이 토큰 예산을 먹고 content가 빈다”)는 사실 우리 스택에서 처음이 아니었어요. 다만 전적은 전부 Qwen 모델에서 나왔어요. Echo 응답 지연 때도, 한 내부 도구의 완주 실패 때도 같은 패턴이었죠. reasoning budget이 예산을 잡아먹어 content가 비고, 재시도 spiral에 빠지는 거요. 그래서 이걸 Gemma 사실로 둔갑시키진 않을게요. “같은 스택, 다른 모델, 동일 실패 패밀리”로만 읽어주세요. 공통 교훈은 분명해요. reasoning 모드는 켜고 끄긴 쉬워도, 상한을 두는 게 백엔드·빌드별로 잘 깨져요.

📌 솔직한 결말 — 다 진단해놓고 PARKED

여기서 정직해야 할 부분이 있어요. 이 글은 “완벽하게 고친 회고”가 아니에요. 원인을 다 진단해놓고, 2026-06-10에 PARKED로 결정했어요. 보류했다는 뜻이에요.

이유는 단순해요. Gemma는 우리한테 비핵심이에요. 회사의 진짜 코딩 워크로드는 Claude와 브릿지가 담당하고, Gemma는 보조 역할이거든요. 1순위 수정안(서버 thinking 기본 off, 속도 무손실)조차 “쓰다가 정 안 되면 적용하자”로 미뤄뒀어요. 그래서 분명히 적어둘게요. thinking-default off가 모든 발산을 해결한다는 건 아직 검증된 결론이 아니라 유력한 1순위 후보예요. 미적용 상태고요.

📚 References

• Google: Gemma 4 with Quantization-Aware Training (2026-06-05)
• Unsloth: Gemma 4 QAT
• EmergentMind: Lossless Speculative Decoding
• llama.cpp #23335 — draft-mtp deterministic output divergence (Qwen)
• llama.cpp #23302 — draft-mtp with –spec-draft-n-max 3 (Qwen)
• llama.cpp #23752 — Metal MTP throughput net loss
• llama-cpp-python #2227 — Gemma 4 tool calls in content
• arXiv 2505.11574 — Quantization Meets Reasoning
• 관련 글: Qwen을 걷어내고 Gemma 하나만 남긴 이유 (이 글의 전편)

✅ 정리하며

네 가지 교훈으로 마칠게요. 첫째, 작은 모델로 가는 결정이 옳았어도 단독 운용은 새로운 표면적을 열어요. 둘째, 불안정의 첫 의심(양자화)은 보통 틀려요. 직관을 측정으로 먼저 깨보세요. 셋째, reasoning 모드는 “끄기”는 쉬워도 “길들이기”가 어려워요. 넷째, +35% 속도는 절대 공짜가 아니에요. 어딘가에서 미묘한 불안정으로 값을 치르게 돼요.

이 글은 깔끔한 해피엔딩이 아니에요. 범인을 다 찾아놓고도 우선순위 때문에 보류한, 트레이드오프를 아는 회고예요. 그게 매일 모델을 직접 굴리는 사람의 진짜 운영 일지에 더 가깝다고 생각해요. 다음에 thinking 서버 기본값을 실제로 꺼보고 나면, 그 결과도 정직하게 측정해서 공유할게요. (측정 기준 시점: 2026년 6월)