Apache 2.0 라이선스
Google DeepMind 공식 발표
Gemma 4, 31B보다 26B가 빠른 이유 있습니다
구글이 2026년 4월 2일 공개한 Gemma 4는 4가지 크기로 출시됐는데, 막상 써보면 31B Dense보다 26B MoE가 훨씬 빠릅니다. 공식 문서에 이유가 딱 나와 있는데 의외로 알려지지 않았습니다. 그리고 로컬에서 돌리려다 VRAM이 날아가는 KV Cache 함정도 있습니다. 이 두 가지를 수치로 정리했습니다.
Gemma 4가 뭔데 이렇게 다들 얘기하나
구글 딥마인드가 2026년 4월 2일 공개한 Gemma 4는 역대 젬마 시리즈 중 가장 큰 규모입니다. 오픈 모델인데도 Gemini 3와 동일한 연구 기술 기반으로 만들어졌고, Apache 2.0 라이선스라서 상업적으로 자유롭게 쓸 수 있습니다. 출시 전까지 젬마 시리즈 누적 다운로드가 4억 회를 넘었고, 커뮤니티가 만든 파생 모델만 10만 개 이상입니다. (출처: Google DeepMind 공식 블로그, 2026.04.02)
모델 크기는 E2B, E4B, 26B A4B MoE, 31B Dense 네 가지입니다. 스마트폰부터 H100 서버까지 다 커버하려는 전략이 눈에 보입니다. 멀티모달도 기본 지원인데, E2B와 E4B는 텍스트·이미지·오디오를 전부 처리하고, 26B와 31B는 텍스트·이미지를 지원합니다.
수학·코딩·추론 벤치마크에서 프런티어급 수치를 찍어서 화제가 됐는데, 막상 로컬에서 돌려보면 생각보다 빡빡합니다. 아래에서 구체적으로 따져봅니다.
26B MoE가 31B보다 빠른 진짜 이유
💡 공식 발표문과 실제 추론 흐름을 같이 보니 “26B인데 4B처럼 빠르다”는 게 단순한 홍보 문구가 아니라 구조 설계에서 나온 결과였습니다.
Gemma 4 26B A4B MoE 모델은 총 파라미터가 25.2B입니다. 그런데 실제 추론 시에는 그 중 3.8B만 활성화됩니다. 나머지 파라미터는 MoE(Mixture-of-Experts) 구조의 전문가(expert) 풀에 들어 있고, 각 토큰 처리마다 관련 있는 전문가만 깨어납니다. (출처: Google DeepMind 공식 모델 카드, 2026.04.02) 결론은 간단합니다. 연산량이 4B짜리 모델과 비슷한데 지식은 26B짜리가 갖고 있는 셈입니다.
반면 31B Dense는 추론할 때마다 30.7B 전부를 씁니다. 정밀도는 조금 더 높을 수 있지만, 속도는 MoE 쪽이 훨씬 유리합니다. H100 80GB 2장에 vLLM으로 31B Dense를 돌린 실측에서는 출력 속도가 평균 297 tok/s였습니다. (출처: mz-moonzoo.tistory.com 실측, 2026.04.02) MoE는 활성 파라미터가 훨씬 적으니 같은 하드웨어에서 더 빠릅니다.
| 구분 | 26B A4B MoE | 31B Dense |
|---|---|---|
| 총 파라미터 | 25.2B | 30.7B |
| 실제 활성 파라미터 | 3.8B | 30.7B (전량) |
| 컨텍스트 윈도우 | 256K | 256K |
| Arena.ai 오픈 모델 순위 | 6위 | 3위 |
| 추론 추천 용도 | 속도 우선 / 에이전트 | 정밀도 우선 / 파인튜닝 |
Arena.ai 텍스트 리더보드에서 31B Dense가 오픈 모델 3위, 26B MoE가 6위인데, 3위와 6위 차이보다 속도 차이가 더 크게 느껴집니다. 에이전트 워크플로우처럼 짧은 응답을 빠르게 반복해야 하는 상황이라면 26B MoE가 현실적인 선택입니다.
벤치마크 수치, 직접 따져봤습니다
💡 수학·코딩 수치는 인상적인데, ‘진짜 어려운 문제’인 HLE 스코어를 같이 보면 다른 그림이 나옵니다.
Gemma 4 공식 모델 카드에 발표된 벤치마크 중 눈에 띄는 수치부터 봅니다. AIME 2026(도구 없이)에서 31B가 89.2%를 기록했습니다. 이전 세대인 Gemma 3 27B가 같은 벤치마크에서 20.8%였으니, 한 세대 만에 4배 이상 뛰었습니다. (출처: Google DeepMind 공식 모델 카드, 2026.04.02) 수학 추론이 이 정도로 올라온 건 프런티어급 폐쇄 모델과 같은 연구 기반을 써서라고 구글은 설명합니다.
코딩 쪽도 비슷합니다. LiveCodeBench v6에서 31B가 80.0%, Codeforces ELO는 2150입니다. Codeforces ELO 2150은 대략 경쟁 프로그래밍 상위 1% 수준인데, 31B 오픈 모델이 이 구간에 들어온 건 처음입니다. 코드 어시스턴트로 쓸 수 있는 실질적인 기준선이 많이 올라왔습니다.
| 벤치마크 | 31B Dense | 26B MoE | Gemma 3 27B |
|---|---|---|---|
| MMLU Pro | 85.2% | 82.6% | 67.6% |
| AIME 2026 (도구 없이) | 89.2% | 88.3% | 20.8% |
| LiveCodeBench v6 | 80.0% | 77.1% | 29.1% |
| GPQA Diamond | 84.3% | 82.3% | 42.4% |
| HLE (도구 없이) | 19.5% | 8.7% | — |
| 긴 문맥 (8-needle 128K) | 66.4% | 44.1% | 13.5% |
여기서 놓치기 쉬운 게 HLE(Humanity’s Last Exam) 스코어입니다. 도구 없이 31B가 19.5%입니다. 검색까지 붙이면 26.5%로 오르긴 하지만, AIME 89%와 비교하면 낙차가 큽니다. HLE는 세계 최고 수준의 전문가들이 출제한 문제 모음이라 현실의 복잡한 판단에 가깝습니다. 수학·코딩 특화 벤치마크가 높다고 모든 작업이 다 잘 되는 건 아닙니다.
로컬 실행 시 KV Cache 함정
💡 “31B라서 H100 한 장에 돌아간다”고 봤을 텐데, KV Cache까지 더하면 계산이 완전히 달라집니다.
Gemma 4 31B Dense는 bfloat16 기준 모델 가중치만 약 62GB입니다. 80GB H100 한 장에 들어가긴 합니다. 그런데 추론 시 KV Cache가 여기에 더해집니다. 공식 모델 카드에 따르면 32K 컨텍스트 기준 KV Cache가 bfloat16에서 40GB에 달합니다. 모델 가중치 62GB에 Cache 40GB를 더하면 단순 합산만 102GB입니다. H100 한 장으로는 안 됩니다. (출처: Google DeepMind 공식 모델 카드, 2026.04.02)
로컬 LLM 커뮤니티에서 실제로 이 문제를 먼저 겪었습니다. 40GB VRAM 환경에서 Q8 양자화 버전을 올려도 2K 컨텍스트밖에 안 들어간다는 보고가 출시 직후 쏟아졌습니다. (출처: Reddit r/LocalLLaMA, 2026.04.03) 다만 이틀 만에 llama.cpp 패치가 나와서 SWA(Sliding Window Attention)를 활성화하면 32K KV Cache가 4GB 수준으로 줄어드는 걸 확인했습니다.
⚠️ 로컬 실행 전 체크리스트
- llama.cpp / LM Studio가 최신 버전인지 확인 (2026.04.04 이후 빌드 권장)
- KV Cache 양자화를 Q8 이상 유지하되 SWA 옵션 활성화
- 31B Dense보다 26B MoE가 Cache 효율이 더 좋음 (활성 파라미터가 3.8B)
- LM Studio 사용자라면 설정에서 런타임 업데이트 후 모델 재다운로드 필요
솔직히 말하면, 일반 소비자용 GPU(24~40GB VRAM)에서 31B를 긴 컨텍스트로 쓰기는 아직 빡빡합니다. 이런 상황이라면 26B MoE가 더 현실적입니다. 26B MoE는 Q4_K_M 양자화 기준 4090(24GB)에서 약 60K 컨텍스트까지 밀어 넣을 수 있다는 보고가 있습니다.
E2B·E4B 온디바이스 모델의 실제 쓰임
💡 “작은 모델이라 성능이 낮겠지”라고 넘겼는데, E4B의 AIME 2026 스코어가 이전 세대 27B를 이미 넘었습니다.
Gemma 4 E2B와 E4B는 이름의 “E”가 Effective Parameter를 뜻합니다. E2B는 실제 추론 파라미터 2.3B인데 총 파라미터는 5.1B, E4B는 실제 4.5B인데 총 8B입니다. 이 차이가 생기는 건 PLE(Per-Layer Embeddings) 구조 때문입니다. 각 레이어마다 독립적인 작은 임베딩 테이블을 두어 파라미터 효율을 극대화했습니다. (출처: Google DeepMind 공식 모델 카드, 2026.04.02)
E4B의 AIME 2026 스코어가 42.5%인데, 이전 세대 Gemma 3 27B의 20.8%를 두 배 이상 뜁니다. 스마트폰에 올라갈 수 있는 크기의 모델이 6배 큰 이전 세대를 수학 추론에서 이겼습니다. E2B와 E4B는 오디오까지 지원하는데, 30초 이내 음성 입력을 직접 처리할 수 있습니다. 구글 픽셀, 퀄컴, 미디어텍과 공동으로 최적화해서 스마트폰에서 인터넷 없이 구동됩니다.
Android 개발자는 AICore Developer Preview를 통해 에이전트 흐름의 프로토타입을 만들 수 있고, 나중에 Gemini Nano 4와의 호환성도 확보됩니다. 앱에 로컬 AI를 붙이고 싶다면 E4B가 현재 가장 현실적인 시작점입니다.
Apache 2.0 라이선스가 실제로 의미하는 것
Gemma 4는 Apache 2.0 라이선스로 배포됩니다. 이전 젬마 시리즈는 구글이 자체 약관을 별도로 적용했고, 상업적 사용에 제약이 있었습니다. Apache 2.0으로 바꾼 건 커뮤니티 요구를 반영한 결정이라고 구글이 직접 밝혔습니다. (출처: Google DeepMind 공식 블로그, 2026.04.02)
Apache 2.0은 사용, 수정, 배포, 상업 판매 모두 가능하고, 파생 모델을 만들어도 됩니다. 저작권 고지만 남기면 됩니다. 허깅 페이스의 Clément Delangue CEO도 “거대한 이정표”라고 평가했습니다. 오픈 웨이트 모델 중 실질적인 프런티어급 성능에 Apache 2.0까지 붙은 케이스가 드물어서, 기업 내부 배포나 파인튜닝 후 API 상용화에 법적 걸림돌이 없습니다.
단, 모델을 실제 프로덕션에 올리려면 안전성 정책을 각자 설정해야 합니다. 구글의 안전 필터는 기본 제공되지 않고, Responsible Generative AI Toolkit을 참고해서 직접 구현해야 합니다.
Q&A
마치며
Gemma 4는 오픈 모델의 기준점을 확실히 올렸습니다. AIME 2026에서 89.2%, LiveCodeBench v6에서 80.0%는 지금까지 31B급 오픈 모델에서 나온 적 없는 수치입니다. Apache 2.0 라이선스까지 얹어서 상업적 활용에도 걸림돌이 없습니다.
다만 몇 가지는 솔직히 짚어야 합니다. HLE 스코어 19.5%는 아직 현실의 복잡한 판단에는 한계가 있다는 신호입니다. 로컬 실행 시 KV Cache 문제도 llama.cpp 패치로 상당 부분 해결됐지만, 32~40GB VRAM 환경에서 긴 컨텍스트를 31B로 돌리는 건 여전히 빡빡합니다. 이런 상황이라면 26B MoE가 더 현실적인 선택입니다. 속도를 잡으면서 벤치마크는 31B와 거의 비슷한 수준이니까요.
결론부터 말하면, 클라우드 API로 쓰거나 Google AI Studio에서 바로 체험할 거라면 31B를 먼저 써보세요. 로컬에 올릴 거라면 본인 VRAM에 맞는 26B MoE나 E4B를 먼저 검토하는 게 시간을 아낍니다.
📌 본 포스팅 참고 자료
※ 본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. Gemma 4 관련 스펙과 벤치마크 수치는 Google DeepMind의 공식 발표 기준이며, 이후 업데이트나 모델 카드 수정에 따라 달라질 수 있습니다. 본 포스팅은 2026.04.06 기준으로 작성되었습니다.
댓글 남기기