Gemma 4 로컬 AI 스택 완전 정복 — DGX Spark에서 돌려본 솔직한 후기

왜 Gemma 4인가

2026년 4월 2일, Google DeepMind가 Gemma 4를 공개했다. Gemini의 경량 파생 모델로 시작한 Gemma 시리즈가 4세대에 이르러 Apache 2.0 라이선스로 전환하면서, 이름 그대로 "보석"(라틴어 gemma)이 될 조건을 갖추었다.

개인 로컬 AI 서버(DGX Spark)에서 여러 오픈 모델을 돌려보고 있는데, Gemma 4가 나온 김에 환경 전체를 정리해 보려 한다. 어떤 스택으로 돌리고 있고, Gemma 4가 실제로 어떤 모델인지, 그리고 써본 솔직한 느낌까지.

Gemma 시리즈의 진화

Gemma가 어떻게 여기까지 왔는지 간략히 되짚어 보자.

버전	출시일	모델 크기	컨텍스트	핵심 변화
Gemma 1	2024-02	2B, 7B	8K	Gemini 경량 버전, 텍스트 전용
Gemma 2	2024-06	2B, 9B, 27B	8K	GQA, Knowledge Distillation
Gemma 3	2025-03	1B~27B	128K	멀티모달(이미지), 140+언어, Function Calling
Gemma 4	2026-04	E2B~31B	256K	MoE, 오디오/비디오 네이티브, Apache 2.0

Google이 이 시리즈를 만드는 이유는 명확하다. Meta(Llama), Alibaba(Qwen) 등이 오픈 모델 생태계를 주도하는 가운데, Gemini 연구 기반으로 상용적으로 자유로운 모델을 제공하겠다는 전략이다.

그런데 이 대형 업체들이 왜 굳이 모델을 무료로 공개할까? 경제학에 "보완재를 상품화하라(Commoditize the Complement)"라는 전략이 있다. 보완재의 가격이 내려가면 본제품의 수요가 올라간다는 원리다.

Meta를 예로 들면, 본업은 광고 플랫폼(Facebook, Instagram)이고 AI 모델은 그 보완재다. Llama를 무료로 풀어 AI 모델을 쌀이나 전기처럼 누가 만들어도 비슷한 범용재(commodity)로 만들면 두 가지 효과가 생긴다. 첫째, OpenAI 같은 유료 모델 업체의 기술 독점력과 가격 결정력이 무력화된다. 둘째, 광고주들이 AI를 활용해 광고를 더 많이 집행하게 되면서 Meta의 광고 수익은 올라간다.

여기에 더 근본적인 계산도 있다. AI 에이전트가 인간 대신 모든 소비를 결정하는 미래가 오면, 광고를 보고 욕망을 느끼는 "인간 소비자"가 사라지고 Meta의 비즈니스 모델 자체가 위협받는다. AI 기술을 흔하고 값싸게 만들어 특정 AI가 정보의 게이트키퍼가 되는 것을 막고, 사용자의 시선(attention)이 여전히 사람과 콘텐츠가 있는 Meta 플랫폼에 머물게 하려는 것이다. 비싼 AI 기술을 공공재 수준으로 격하시켜 경쟁자의 앞길을 막고, 인간이 광고를 소비하는 기존의 운동장을 지키는 전략이다.

Alibaba는 Qwen으로 알리클라우드 고객을 확보하고, Google은 Gemma로 GCP와 TPU 사용을 유도한다. 이름은 다르지만 논리는 같다. 안드로이드를 무료로 풀어서 모바일 검색 광고 시장을 장악한 Google의 전략과 본질적으로 동일하다.

특히 Gemma 4에서 Apache 2.0으로 라이선스를 전환한 건 이전의 커스텀 라이선스 제약을 완전히 제거한 의미 있는 결정이다.

Gemma 4 모델 라인업

이름 규칙부터 짚고 가자. B는 Billion(10억)이다. 앞 글자가 중요한데, E는 Effective(유효), A는 Active(활성)다. E2B는 "유효 파라미터 20억", 26B A4B는 "총 260억 중 활성 파라미터 40억"이라는 뜻이다.

왜 "유효"와 "활성"을 구분해야 할까? 파라미터를 줄이는 메커니즘이 근본적으로 다르기 때문이다. E2B의 PLE embedding table은 매 토큰마다 사용은 되지만 연산이 가볍다. 단순 인덱스 조회(lookup)라서 행렬곱이 아니고, CPU 메모리나 flash storage로 오프로드할 수도 있다. 5.1B 파라미터가 전부 동원되지만 실제 연산 부하는 2.3B 수준인 셈이다. 반면 MoE의 26B A4B는 매 토큰마다 router가 3.8B만 골라서 forward pass에 태우고, 나머지 ~22B는 아예 연산에 참여하지 않는다. 둘 다 "Active"라고 부르면 E2B의 embedding table이 비활성이라는 오해를 주고, 둘 다 "Effective"라고 부르면 MoE의 비선택 expert가 효율이 낮을 뿐이라는 오해를 준다. 그래서 별도의 용어가 필요했다.

모델	총 파라미터	유효/활성 파라미터	컨텍스트	멀티모달
E2B	5.1B	유효 ~2.3B	128K	텍스트+이미지+오디오+비디오
E4B	~8B	유효 ~4.5B	128K	텍스트+이미지+오디오+비디오
26B A4B (MoE)	26B	활성 ~3.8B	256K	텍스트+이미지
31B Dense	31B	31B (전부 사용)	256K	텍스트+이미지

각 모델이 해결하려는 핵심 문제가 다르다.

• E2B / E4B — "작은 모델은 왜 멍청한가"를 해결: 표준 Transformer에서 각 토큰은 입력 시점에 단 하나의 embedding 벡터를 받고, 이후 모든 레이어가 이 벡터를 기반으로 작동한다. 큰 모델은 embedding 차원이 넉넉해서(4096차원 이상) 하나의 벡터에 충분한 정보를 담을 수 있지만, 작은 모델은 차원이 좁아서(1536차원) 필요한 정보를 다 우겨넣지 못하는 압축 병목이 생긴다. PLE(Per-Layer Embeddings)는 매 레이어마다 별도의 보조 embedding을 주입해서 이 병목을 해소한다. 시험에 비유하면, 기존에는 첫 페이지에 적힌 요약만 보고 전 과목을 풀어야 했다면, PLE는 매 과목마다 해당 과목 참고자료를 따로 건네주는 것이다. 덕분에 2.3B짜리 E2B가 이전 세대 27B 모델을 능가하는 결과를 낸다.
• 26B MoE — "큰 모델은 왜 느린가"를 해결: 파라미터가 많으면 성능은 좋지만 추론이 느리다. MoE(Mixture of Experts)는 26B개의 파라미터 중 매번 3.8B만 골라서 활성화한다. 100명의 전문가가 있지만 질문마다 가장 적합한 15명만 답변하는 구조다. 전체 지식은 26B만큼 풍부하면서, 실제 연산량은 4B급으로 가볍다.
• 31B Dense — "타협 없는 최대 성능": 모든 파라미터를 매번 다 사용한다. 속도보다 정확도가 중요한 작업에 적합하며, 오픈 모델 Arena 리더보드 세계 3위의 성능을 낸다.

내 로컬 환경 — 세 가지 추론 스택

개인 서버인 NVIDIA DGX Spark(GB10 GPU, 128GB 통합 메모리)에서 Gemma 모델을 세 가지 방식으로 돌리고 있다.

1. Ollama — 일상 추론용

가장 편한 방식이다. ollama run gemma4 한 줄이면 끝. 사이드 프로젝트에서 사진 태깅, 텍스트 생성, RAG 질의 등에 Ollama를 통해 로컬 LLM을 호출한다.

# Gemma 4 실행
ollama run gemma4:26b

# API로 호출
curl http://localhost:11434/api/generate \
  -d '{"model": "gemma4:26b", "prompt": "..."}'

GPU 스케줄러가 Ollama를 on-demand 작업(우선순위 15)으로 관리하고 있어서, 더 높은 우선순위 작업이 들어오면 자동으로 양보하고, 끝나면 다시 올라온다.

2. llama.cpp — 경량 추론/임베딩용

직접 컴파일한 llama.cpp에는 Gemma 1~3까지의 구현체가 포함되어 있다. GGUF 양자화 모델을 쓰면 메모리를 아끼면서도 준수한 성능을 낼 수 있다.

# Gemma 4 GGUF 서빙
llama-server -hf ggml-org/gemma-4-E4B-it-GGUF:Q8_0

# Gemma 3 멀티모달 (이미지 분석)
llama-mtmd-cli -m gemma3.gguf --mmproj mmproj.gguf \
  --image photo.jpg -p "이 사진을 설명해줘"

3. vLLM Docker — 고성능 서빙용

동시 요청이 많거나 최대 성능이 필요할 때는 vLLM을 쓴다. Gemma 4 전용 Dockerfile을 만들어서 NGC PyTorch 26.03 기반에 FlashInfer v0.6.7(SM121 Blackwell 빌드)을 올렸다.

# Docker 이미지 빌드
docker buildx build -f Dockerfile.gemma4 \
  -t vllm-spark:gemma4 --load .

# Gemma 4 26B MoE 서빙 설정
MODEL_PATH=google/gemma-4-26B-A4B-it
TP_SIZE=1
GPU_MEMORY_UTILIZATION=0.90
MAX_MODEL_LEN=32768
MAX_NUM_SEQS=8

26B MoE 모델은 활성 파라미터가 3.8B뿐이라 DGX Spark 단일 노드(TP=1)에서도 BF16 풀 정밀도로 서빙할 수 있다.

스택 비교 요약

스택	장점	용도
Ollama	설치 간편, API 호환	일상 추론, 사이드 프로젝트 통합
llama.cpp	메모리 효율, 양자화 지원	경량 추론, 엣지 테스트
vLLM	동시 처리, 최대 처리량	배치 추론, 고부하 서빙

벤치마크 — 숫자로 보는 Gemma 4

Google이 공개한 벤치마크와 커뮤니티 비교 결과를 정리했다.

Gemma 4 세대별 비교

벤치마크	Gemma 4 31B	Gemma 4 26B	Gemma 4 E2B	Gemma 3 27B
MMLU 다국어	85.2%	82.6%	60.0%	67.6%
MMMU Pro (비전)	76.9%	73.8%	44.2%	49.7%
AIME 2026 (수학)	89.2%	88.3%	37.5%	20.8%
LiveCodeBench v6	80.0%	77.1%	44.0%	29.1%
GPQA Diamond (과학)	84.3%	82.3%	43.4%	42.4%
TAU2-bench (에이전트)	86.4%	85.5%	29.4%	6.6%

숫자를 보면 세대 간 도약이 극적이다. 특히 에이전트 벤치마크(TAU2)에서 Gemma 3의 6.6%가 Gemma 4 31B에서 86.4%로 뛴 건 아키텍처 수준의 변화가 있었음을 보여준다.

경쟁 모델 비교 (Gemma 4 31B vs Qwen 3.5 27B)

벤치마크	Gemma 4 31B	Qwen 3.5 27B
MMLU-Pro	85.2%	86.1%
Codeforces ELO	2150	1899
MMMLU (다국어)	88.4%	85.9%
TAU2-Bench (에이전트)	76.9%	79.0%

Qwen 3.5와 비교하면 코딩(Codeforces)과 다국어에서 Gemma가 앞서고, 일반 추론(MMLU-Pro)과 에이전트에서는 Qwen이 근소하게 우위다. Arena 리더보드에서는 31B가 오픈 모델 세계 3위, 26B가 6위에 올라 있다.

장단점 — 솔직한 정리

장점

• Apache 2.0 라이선스: Llama는 월간 활성 사용자 7억 명 이상이면 별도 허가가 필요한 커스텀 라이선스다. Gemma 4는 Apache 2.0이라 상용 배포, 수정, 재배포에 아무 제약이 없다. 스타트업이든 대기업이든, 그냥 쓰면 된다.
• 파라미터 대비 압도적 성능: E2B(2.3B)가 이전 세대 27B 모델을 대부분의 벤치마크에서 능가한다. 20배 작은 모델이 더 똑똑하다는 건, 같은 하드웨어로 더 많은 동시 요청을 처리하거나 모바일에서도 쓸 수 있다는 의미다.
• 다국어 최강: 140개 이상 언어를 지원하며, 다국어 벤치마크(MMMLU)에서 Qwen 3.5를 능가한다. 한국어로 질문하고 한국어로 답받는 로컬 AI를 원한다면 현재 최선의 선택지다.

단점

• 추론 속도가 느리다: 26B MoE가 동일 하드웨어에서 Qwen 3.5 대비 현저히 느리다는 커뮤니티 보고가 있다(5060 Ti 16GB 기준 11 tok/s vs 60+ tok/s). MoE 구조의 라우팅 오버헤드가 원인으로 보이며, 실시간 채팅처럼 응답 속도가 중요한 작업에서는 체감된다.
• 메모리를 많이 먹는다: 같은 GPU에서 Gemma는 20K 토큰 컨텍스트밖에 못 쓰는데, Qwen은 190K를 쓸 수 있다는 비교가 있다. 긴 문서를 통째로 넣고 분석하는 작업에서는 불리하다.
• 파인튜닝 생태계가 아직 덜 됐다: HuggingFace Transformers, PEFT 등에서 Gemma 4 아키텍처를 아직 완전히 지원하지 않는다. 출시 3일째라 시간이 해결해줄 문제이긴 하지만, 당장 커스텀 모델을 만들려면 삽질이 필요하다.

실사용 느낌

DGX Spark의 128GB 통합 메모리 환경에서는 31B dense도 무리 없이 올라간다. 하지만 실제로 가장 많이 쓰는 건 26B MoE다. 활성 파라미터가 3.8B뿐이라 메모리도 적게 먹고, 다른 작업과 병행하기 좋다.

사이드 프로젝트에서 사진 분석이나 텍스트 생성에 로컬 LLM을 붙여 쓰고 있는데, Gemma 4의 멀티모달 능력은 확실히 Gemma 3 대비 안정적이다. 특히 한국어 처리에서 체감되는 개선이 크다.

GPU 스케줄러로 자원을 관리하면서 Ollama(일상), vLLM(고부하)을 전환하는 구조가 잘 맞는다. GPU가 하나뿐이니 우선순위 기반 선점이 중요한데, Gemma 4 MoE는 메모리 풋프린트가 작아서 다른 작업에 양보한 뒤 재시작 시간도 짧다.

마무리

Gemma 4는 Google이 오픈 모델 경쟁에서 의미 있는 도약을 한 모델이다. Apache 2.0 전환이 가장 큰 전략적 변화이고, 파라미터 효율성(특히 E2B의 소형 모델 혁신)과 다국어·코딩 성능에서 확실한 강점을 보인다.

다만 추론 속도와 VRAM 효율에서 Qwen 3.5에 밀리는 건 아쉽다. 파인튜닝 생태계가 성숙하면 활용도가 더 넓어질 것이다. 출시 3일 만에 벌써 커뮤니티의 GGUF 양자화, 벤치마크 비교, 버그 리포트가 쏟아지고 있으니, 한 달 뒤의 Gemma 4 생태계가 기대된다.

로컬 AI 서버를 운영하면서 Ollama + llama.cpp + vLLM 세 스택을 상황에 맞게 전환하는 구조가 잡히니, 새 모델이 나올 때마다 빠르게 테스트하고 적용할 수 있다. Gemma 4도 그 흐름에 자연스럽게 합류했다.

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.