결론부터 말한다. Gemma-4-E4B는 RAG 사실 추출용 전용 모델로는 확실히 쓸 만하다. 문제는 오디오 쪽이다 — 멀티모달 오디오 입력 자체는 우리 llama.cpp 서버에서 실제로 작동한다. 다만 기본 설정 그대로 두면, 4초 넘는 클립에서 아무 에러 없이 빈 응답만 돌아온다. 원인을 추적해 보니 모델이 “생각”하느라 토큰 예산을 다 써버렸고, 정답은 생각 속에만 남아 있었다. 이 글은 그 함정을 우리 DGX Spark에서 직접 재현하고 고친 기록과, RAG 추출 성능, 그리고 이 모델이 실제로 어디에 맞는지를 정리한다.

🔍 Gemma-4-E4B는 어떤 모델?

Gemma-4-E4B는 구글 Gemma 4 패밀리(2026년 7월 2일 기술 보고서 공개)의 엣지용 변형이다. 공식 카드 기준 유효 파라미터 약 4.5B(임베딩 포함 8B), 컨텍스트 128K, PLE(레이어별 임베딩)와 로컬/글로벌 하이브리드 어텐션 구조를 쓴다. 텍스트·이미지·비디오·오디오를 모두 네이티브로 받는 멀티모달 모델이라는 게 공식 설명이다.

📊 RAG 사실 추출, 얼마나 빨랐나

우리 메모리 시스템(RAG)은 대화·문서에서 사실을 뽑아 JSON으로 구조화하는 추출 단계를 늘 돌린다. 예전에는 메인 모델 Gemma-4 26B가 이 일을 겸했는데, 추출 자체는 무거운 추론이 필요 없는 작업이다. 그래서 한국어 샘플 5개로 E4B와 26B를 맞붙여 봤다(둘 다 thinking을 끈 동일 조건, 같은 프롬프트).

E4B가 약 1.45배 빨랐고(180~190 tok/s 대 125 tok/s), 10번 모두 유효한 JSON에 환각도 없었다. 다만 이건 우리 자체 비교다. 한 벤치마크는 Qwen3-4B가 RAG 사실 추출에서 95.64% 정확도를 낸다고 보고하지만, Gemma-3 세대 기준이지 E4B와의 직접 비교가 아니다. 같은 벤치마크는 추론 특화 소형 모델이 RAG와 함께 쓰일 때 오히려 정확도가 떨어지는 경우도 보고했다 — “작은 모델 + RAG”가 자동으로 좋아지는 조합은 아니다.

🎙️ 오디오/STT, 정말 되나 직접 돌려봤다

뜻밖의 발견은 오디오였다. E4B는 텍스트만이 아니라 오디오까지 받는 멀티모달 모델이라, 우리 DGX Spark(llama.cpp b9917)에 직접 물어봤다. 짧은 한국어 TTS 클립(“안녕하세요. 오늘 날씨가 정말 좋네요.”, 2.9초)을 보냈더니 글자 하나 틀리지 않고 받아썼다.

문제는 그다음이었다. 조금 더 긴 클립(5.2초, “라즈베리파이 5와 클로디, 미니, 시월이가 멀티모달 모델을 테스트했습니다”)을 보내자 — 아무 에러도 없이 빈 문자열만 돌아왔다.

고치는 법은 간단했다. 요청에 아래 두 필드를 넣어 생각 모드를 꺼버리면 된다.

{
  "chat_template_kwargs": {"enable_thinking": false},
  "reasoning_format": "none"
}

같은 클립을 다시 보내자 0.5초 만에, 토큰 30개만 쓰고 같은 정확도로 답이 나왔다. 생각 모드를 켠 채 토큰 예산만 1000으로 늘려도 정답은 나오지만(2.4초, 312토큰), 끄는 쪽이 5배 빠르고 10분의 1의 비용이었다.

받아쓰기 자체도 흥미로웠다. “시월”이는 “10월”로 잘못 들렸다 — 발음이 겹치는 진짜 동음이의어 혼동이고, 두 번의 테스트에서 똑같이 재현됐다. 숫자도 있는 그대로 읽지 않았다. “십이 퍼센트”, “이백 밀리초”라고 말한 걸 “12%”, “200ms”로 정규화해서 적었다 — 문자 그대로의 받아쓰기라기보다는, 이미 정리된 표기로 바꿔 쓰는 쪽에 가까웠다.

이 결과에는 한계가 있다. 클립 5개, 그것도 macOS TTS로 만든 깨끗한 음성이다. KAIST의 한국어 Whisper 평가(large-v2 기준 CER 14.66%)같은 정식 CER/WER 벤치마크가 아니라, 현장 점검에 가깝다. 그리고 이건 llama.cpp 서버에 직접 물어본 결과다 — Ollama 레이어의 멀티모달 버그는 다른 층의 문제라, 이 테스트로 그 버그가 없다고 말할 수는 없다.

🌱 커뮤니티는 E4B를 어떻게 보나

커뮤니티 반응을 보면 E4B의 자리가 명확해진다. r/LocalLLaMA에서 로컬 만능 모델로 가장 많이 꼽히는 건 E4B가 아니라 Gemma-4 26B A4B(또는 Qwen 3.5/3.6 MoE)다. 한 사용자는 댓글에서 “Gemma 26B A4B는 굉장하다… E4B는 그에 비하면 꽤 실망스러웠다”고 적었다. E4B는 상시 대기하는 엣지·사이드카용 모델로 취급되지, 매일 쓰는 메인 모델 취급을 받지는 않는다.

디스크 용량 논쟁도 있다. 공식 태그 gemma4:e4b는 4비트 양자화 기준으로 약 9.6GB다. “4B짜리가 왜 10GB에 가깝냐”는 지적이 커뮤니티에 반복해서 나온다. 유효 파라미터 수와 디스크 용량은 다른 숫자다.

🔧 설정 후기 (a.k.a. 삽질기)

작은 모델 하나 제대로 굴리는 것도 순탄치 않았다.

• flash-attention이 크래시했다. Blackwell GPU에서 FA를 켜니 워밍업 중 fattn.cu:110에서 죽었다. FA 커널이 요구하는 공유 메모리가 이 아키텍처 한계를 넘는, 이미 알려진 패턴이었다. 결국 FA를 끄고 운영한다.
• 128K 천장. 컨텍스트를 크게 잡으려다, 이 모델의 학습 한계가 128K라는 걸 확인했다. 그 이상은 무의미하게 잘린다.
• “생각 모드” 함정, 텍스트 버전. 추출은 결정적이어야 해서 thinking을 서버에서 아예 꺼버렸는데, 그러다 보니 “필요할 때 다시 켜는” 길이 막혔다. 그래서 정책을 뒤집었다 — 서버는 thinking을 기본 ON으로 두고, 결정적 출력이 필요한 호출자만 요청할 때 끈다.
• “생각 모드” 함정, 오디오 버전. 그 정책 뒤집기가 이번엔 부메랑이 됐다. 오디오처럼 새로 붙인 경로는 서버 기본값(thinking ON)을 그대로 물려받는다 — 위 오디오 절이 그 재현 기록이다.
• 포트로 라우팅한다. 이 서버는 “모델 이름”이 아니라 포트로 라우팅한다. 별칭은 표시용일 뿐이다.

🤔 그렇다면 E4B가 항상 옳은 선택인가

정직하게 짚어야 할 반론이 있다.

첫째, 출시 초기 불안정성이 실제로 있었다. goose의 이슈는 구버전 llama.cpp가 Gemma-4의 Jinja 채팅 템플릿을 처리하지 못해 응답이 깨졌다고 보고했다 — llama.cpp를 새 버전으로 올려야 해결됐다. Zed의 열려 있는 이슈는 로컬로 서빙한 Gemma 4가 에이전트 작업에서 파일을 잘못 쓰거나 콘솔에 대신 출력하는 문제를 보고한다. 갓 나온 모델을 로컬에 올릴 땐 스택 전체가 최신이어야 한다는 뜻이다.

둘째, Qwen3-4B와의 직접 비교는 존재하지 않는다. 가장 강력한 소형 모델 RAG 수치(Qwen3-4B 95.64%)는 Gemma-3 세대 기준이고, E4B는 그 무대에 올라본 적이 없다. “E4B가 최고의 소형 추출기”라는 주장은 검증되지 않았다 — “유력한 후보”가 정직한 표현이다.

셋째, 진짜 한국어 STT가 필요하다면 여전히 Whisper 계열이 안전한 선택이다. KAIST 평가에서 파인튜닝한 Whisper-large-v2는 CER 10.48%까지 내려갔다. Gemma의 오디오 경로가 작동하는 건 이제 확인됐지만, 정식 벤치마크로 검증된 정확도가 있는 건 아니다. 짧고 가벼운 음성 맥락은 같은 모델로 처리하되, 본격적인 받아쓰기 작업은 지금도 Whisper를 병행하는 게 현실적이다.

🎯 E4B, 언제 쓰면 될까

RAG 사실 추출처럼 결정적이고 가벼운 작업, 그리고 짧은 음성 메모 처리에는 E4B가 맞는 체급이다. 매일 쓰는 메인 코딩·에이전트 모델을 찾는다면 26B A4B나 Qwen 3.5/3.6 MoE 쪽이 커뮤니티가 실제로 선택하는 답이다. 본격적인 한국어 받아쓰기가 목적이라면 지금도 Whisper 계열이 검증된 선택이다. 그리고 어느 경로로 오디오를 쓰든, 생각 모드부터 확인할 것 — 켜져 있으면 짧은 클립 몇 개만 테스트해보고 “된다”고 판단하기 쉽지만, 조금만 길어져도 조용히 빈 응답을 돌려준다.

📚 참고 자료

• Gemma 4 Technical Report (arXiv:2607.02770, 2026-07-02)
• HuggingFace — google/gemma-4-E4B
• Google AI for Developers — Gemma 3n overview
• Benchmarking SLMs/SRLMs on System Log Severity Classification (arXiv:2601.07790)
• Evaluating ASR Systems for Korean Meteorological Experts, KAIST (arXiv:2410.18444)
• goose — Issue #9110, Gemma-4 Chat Template Support
• Zed — Issue #57416, Local Gemma4 + llama.cpp tools problems
• Ollama Library — gemma4
• r/LocalLLaMA — Gemma 4 26B is the perfect all around local model
• ollama/ollama — Issue #16532

함께 보기 — Mac Mini 원격 개발 서버 구축기