Gemma 4 아키텍처 총정리

2026년 3월 31일, Google은 Gemma 4를 공개했습니다. Gemini 3의 연구 성과를 오픈소스로 내린 이 모델 패밀리는 “파라미터당 지능(intelligence-per-parameter)“을 극대화하겠다는 명확한 설계 목표를 가지고 있습니다. 그리고 이번에는 Apache 2.0 라이선스를 채택하면서, 이전 Gemma 시리즈의 커스텀 라이선스가 걸림돌이었던 상업적 활용 문제까지 한 번에 해결했습니다.

그런데 Gemma 4가 흥미로운 건 라이선스 변경 때문만이 아닙니다. 하나의 모델 패밀리 안에 Dense, MoE, 인코더 프리(encoder-free) 아키텍처를 동시에 담으면서, 2B급 엣지 모델부터 31B Dense 모델까지 하나의 설계 철학으로 관통하는 구조를 만들어냈습니다. 이 글에서는 Gemma 4의 5가지 변형이 공유하는 공통 아키텍처와 각 변형만의 차별점을 깊이 있게 살펴보겠습니다.

모델 라인업: 하나의 철학, 다섯 가지 변형

Gemma 4 패밀리는 총 5개의 변형으로 구성됩니다. 초기 출시(3월 31일)에는 4개 변형이 공개되었고, 12B Unified는 6월 3일에 추가되었습니다.

모든 모델이 262K 어휘(vocabulary) 크기를 공유하고, 140개 이상의 언어로 사전학습되었습니다. 35개 이상의 언어를 즉시 지원합니다.

이름에서 “E”는 Effective의 약자입니다. E2B는 총 파라미터가 5.1B이지만 임베딩을 제외한 유효 파라미터가 2.3B라는 의미로, 실제 추론 비용을 더 정확하게 반영합니다. 26B A4B도 같은 맥락입니다. 총 25.2B 파라미터를 가지지만, MoE 라우팅으로 토큰당 3.8B(약 4B)만 활성화됩니다.

하이브리드 어텐션: 로컬과 글로벌의 교차 배치

Gemma 4의 가장 핵심적인 아키텍처 변화는 하이브리드 어텐션 메커니즘(Hybrid Attention)입니다. Gemma 3도 슬라이딩 윈도우 어텐션을 사용했지만, Gemma 4는 로컬 어텐션과 글로벌 어텐션을 레이어 단위로 교차 배치하면서 각각에 서로 다른 헤드 차원을 부여하는 방식으로 한 단계 더 발전시켰습니다.

로컬 레이어와 글로벌 레이어

Layer 0  [Local]   ─── Sliding Window (head_dim=256)
Layer 1  [Global]  ─── Full Attention  (head_dim=512)
Layer 2  [Local]   ─── Sliding Window (head_dim=256)
Layer 3  [Global]  ─── Full Attention  (head_dim=512)
...

로컬 레이어는 슬라이딩 윈도우 어텐션을 사용합니다. 각 토큰이 주변 일정 범위의 토큰만 참조하므로 연산량이 시퀀스 길이에 대해 선형적으로 증가합니다. 헤드 차원은 256입니다.

글로벌 레이어는 풀 어텐션(full attention)을 사용합니다. 시퀀스 전체를 참조하며, 헤드 차원은 512로 로컬의 2배입니다. 글로벌 레이어에서 더 큰 헤드 차원을 쓰는 이유는 먼 거리의 토큰 간 관계를 포착하려면 더 풍부한 표현 공간이 필요하기 때문입니다.

이 설계의 핵심은 효율과 표현력의 균형입니다. 모든 레이어가 풀 어텐션을 사용하면 긴 시퀀스에서 메모리와 연산 비용이 급격히 증가합니다. 반면 모든 레이어가 슬라이딩 윈도우만 사용하면 문서 전반에 걸친 장거리 의존성을 놓치게 됩니다. 로컬과 글로벌을 교차 배치하면 로컬 레이어에서 지역적 패턴(구문, 문법)을 효율적으로 처리하고, 글로벌 레이어에서 문서 수준의 맥락을 잡아냅니다.

Unified Keys and Values

글로벌 레이어에는 하나 더 흥미로운 최적화가 들어갑니다. Unified Keys and Values라 불리는 기법으로, 글로벌 어텐션의 키(Key)와 밸류(Value)를 여러 레이어 간에 공유합니다.

이 방식은 KV Cache 메모리를 크게 줄여줍니다. 256K 토큰 컨텍스트에서 각 글로벌 레이어마다 독립적인 KV를 유지하면 메모리 소비가 상당한데, 키/밸류를 공유하면 그만큼의 메모리를 절약하면서도 성능 저하는 최소화할 수 있습니다. Gemma 3에 없었던 새로운 최적화입니다.

Per-Layer Embeddings (PLE): 소형 모델의 표현력 극대화

E2B와 E4B 엣지 모델에는 Per-Layer Embeddings(PLE)라는 독특한 임베딩 기법이 적용됩니다. 일반적인 Transformer에서는 입력 토큰이 하나의 임베딩 테이블을 거친 후, 그 벡터가 모든 레이어를 순차적으로 통과합니다. PLE는 이 구조를 바꿉니다.

기존 방식과의 차이

[기존 Transformer]
토큰 → 공유 임베딩 테이블 → Layer 0 → Layer 1 → ... → Layer N → 출력

[PLE (Per-Layer Embeddings)]
토큰 → Layer 0 전용 임베딩 → Layer 0
      → Layer 1 전용 임베딩 → Layer 1
      → ...
      → Layer N 전용 임베딩 → Layer N → 출력

각 레이어가 자체적인 임베딩 표현을 가지게 되면서, 동일한 파라미터 예산 안에서 더 다양한 표현을 만들어낼 수 있습니다. 이는 특히 파라미터 수가 제한된 소형 모델에서 의미가 큽니다. 2~4B 규모의 모델에서는 레이어 수를 무한정 늘릴 수 없고, 히든 차원도 제한되므로 같은 양의 파라미터를 더 효율적으로 활용하는 전략이 중요합니다.

PLE가 작동하는 원리를 직관적으로 이해하면 이렇습니다. 기존 방식에서는 하위 레이어(구문 분석)와 상위 레이어(의미 해석)가 동일한 초기 임베딩에서 출발합니다. PLE에서는 각 레이어가 자신의 역할에 최적화된 입력을 받을 수 있습니다. E2B의 총 파라미터가 5.1B이지만 유효 파라미터가 2.3B인 이유도 이 추가 임베딩 파라미터 때문입니다. 임베딩이 차지하는 용량은 크지만, 추론 시 각 레이어에서 실제로 활성화되는 연산량은 2.3B 수준입니다.

인코더 프리 아키텍처: 12B Unified의 과감한 설계

Gemma 4의 5개 변형 중 가장 아키텍처적으로 실험적인 모델이 바로 12B Unified입니다. 이 모델은 텍스트, 이미지, 오디오를 하나의 디코더(decoder-only) 모델에서 인코더 없이 처리합니다.

기존 멀티모달 아키텍처와의 비교

대부분의 멀티모달 LLM은 각 모달리티에 전용 인코더를 둡니다. 예를 들어 Gemma 3은 비전에 SigLIP 인코더, 오디오에 USM 스타일 Conformer 인코더를 사용했습니다. 이 방식은 각 모달리티의 전문 인코더가 높은 품질의 특징(feature)을 추출해주기 때문에 안정적이지만, 인코더마다 별도의 파라미터가 필요하고 모달리티 간 통합이 프로젝션 레이어에서 병목이 됩니다.

[기존 멀티모달 (Gemma 3)]
이미지 → SigLIP 인코더 → 프로젝션 → LLM Backbone
오디오 → Conformer 인코더 → 프로젝션 → LLM Backbone
텍스트 → 토큰 임베딩 → LLM Backbone

[인코더 프리 (Gemma 4 12B)]
이미지 → 경량 임베딩 모듈(행렬곱 + 위치 임베딩 + 정규화) → LLM Backbone
오디오 → 원시 파형 직접 투영 → LLM Backbone
텍스트 → 토큰 임베딩 → LLM Backbone

12B Unified는 이 구조를 근본적으로 바꿨습니다.

비전: SigLIP 인코더를 경량 모듈로 대체

비전 처리에서 SigLIP 같은 무거운 인코더를 제거하고, 단일 행렬곱(matrix multiplication) + 위치 임베딩(positional embedding) + 정규화(normalization)로 구성된 경량 임베딩 모듈을 사용합니다. 이미지 패치를 직접 LLM의 토큰 차원 공간에 매핑하는 셈입니다.

이 모델은 이미지당 토큰 수를 동적으로 조절하는 동적 비전 토큰 예산도 도입했습니다. 이미지 복잡도와 해상도에 따라 70, 140, 280, 560, 1120개 토큰 중 적절한 수를 할당합니다. 단순한 아이콘 이미지에 1120개 토큰을 낭비하지 않고, 복잡한 차트에는 충분한 토큰을 배정하는 것입니다.

오디오: 인코더 완전 제거

더 과감한 변화는 오디오 처리입니다. Conformer 인코더를 완전히 제거하고, 원시 16kHz 파형(raw waveform)을 텍스트 토큰 차원 공간에 직접 투영합니다. 음성 인식(ASR)이나 음성 번역 같은 태스크를 위해 별도의 음성 모델을 학습시킬 필요 없이, LLM 자체가 오디오 신호를 이해하도록 만든 것입니다.

현재 오디오 입력은 최대 30초까지 지원됩니다. 비디오는 모든 Gemma 4 모델에서 최대 60초(1fps)로 처리 가능합니다.

왜 인코더 프리인가?

인코더 프리 아키텍처의 장점은 세 가지입니다.

첫째, 파라미터 효율성입니다. 전용 인코더를 제거하면 그만큼의 파라미터를 LLM 본체에 투자할 수 있습니다. 12B라는 제한된 파라미터 예산에서 인코더에 2~3B를 쓰는 대신, 전체를 디코더에 집중시킵니다.

둘째, 모달리티 간 정렬(alignment)입니다. 모든 입력이 하나의 토큰 공간으로 통합되므로, 텍스트·이미지·오디오 간의 교차 참조가 자연스럽습니다. 인코더 + 프로젝션 방식에서는 모달리티 간 정보 손실이 프로젝션 레이어에서 발생할 수 있습니다.

셋째, 서빙 단순화입니다. 인코더별로 다른 연산 그래프를 관리할 필요가 없으니, 추론 파이프라인이 깔끔해집니다.

물론 트레이드오프도 있습니다. 전용 인코더가 수십억 개의 이미지-텍스트 쌍으로 사전학습된 풍부한 시각적 표현을 제공하는 반면, 경량 임베딩 모듈은 LLM 사전학습 과정에서 시각적 이해를 함께 학습해야 합니다. 더 많은 학습 데이터와 더 정교한 학습 전략이 필요한 셈입니다.

MoE 아키텍처: 128개 전문가, 3.8B 활성화

26B A4B는 Gemma 패밀리 최초의 Mixture of Experts(MoE) 모델입니다. 총 25.2B 파라미터를 가지지만, 각 토큰을 처리할 때 128개 전문가 중 8개만 선택하여 3.8B 파라미터만 활성화합니다.

MoE 구성 상세

[26B A4B MoE 레이어 구조]

입력 토큰
    │
    ▼
┌──────────────┐
│ Attention    │  ← 하이브리드 어텐션 (로컬/글로벌 교차)
└──────┬───────┘
       │
       ▼
┌──────────────┐
│ Router       │  ← 게이트 네트워크: top-8 전문가 선택
└──────┬───────┘
       │
       ├──▶ Expert 1 (FFN)
       ├──▶ Expert 7 (FFN)    ← 8개 활성 전문가
       ├──▶ Expert 42 (FFN)
       ├──▶ ...
       │
       ├──▶ Shared Expert (FFN)  ← 항상 활성화되는 공유 전문가
       │
       ▼
┌──────────────┐
│ 가중합        │  ← 라우터 가중치로 전문가 출력 결합
└──────────────┘

핵심 구성 요소를 정리하면 다음과 같습니다.

미세 전문가(Fine-Grained Experts)란?

일반적인 MoE 모델에서는 전문가 수가 8~16개 정도이고, 각 전문가가 큰 FFN 블록을 가집니다. Gemma 4의 26B는 128개의 “미세” 전문가를 사용합니다. 각 전문가의 크기가 작은 대신 수가 훨씬 많습니다.

미세 전문가의 장점은 라우팅 정밀도입니다. 128개 중 8개를 고르면 약 2조(trillion) 가지의 전문가 조합이 가능합니다. 이는 8개 중 2개를 고르는 28가지 조합과는 비교할 수 없는 수준의 다양성입니다. 각 토큰이 자신에게 가장 적합한 전문가 조합을 세밀하게 선택할 수 있습니다.

공유 전문가(Shared Expert)

128개의 라우팅 전문가 외에 1개의 공유 전문가(shared expert)가 있습니다. 이 전문가는 라우팅과 무관하게 모든 토큰에 항상 적용됩니다. 공유 전문가는 언어의 기본적인 문법, 상식 같은 범용 지식을 담당하고, 라우팅 전문가들은 특정 도메인이나 태스크에 특화된 지식을 처리합니다.

추론 효율성과 트레이드오프

MoE의 핵심 가치는 추론 효율성입니다. 31B Dense 모델은 모든 토큰에 30.7B 파라미터를 전부 사용하지만, 26B MoE는 3.8B만 활성화합니다. 토큰당 연산량(FLOPs)이 약 8배 적습니다. 고처리량 서빙 환경에서 같은 GPU로 훨씬 많은 요청을 동시 처리할 수 있습니다.

다만 주의할 점이 있습니다. MoE 모델은 활성 파라미터가 3.8B이지만, 전체 25.2B 파라미터를 메모리에 로드해야 합니다. 어떤 전문가가 선택될지 미리 알 수 없기 때문입니다. 메모리 사용량은 Dense 모델에 근접하면서 연산량만 줄이는 구조이므로, 메모리가 아닌 연산(compute)이 병목인 환경에서 장점이 극대화됩니다.

Proportional RoPE (p-RoPE): 장문맥의 열쇠

Gemma 4는 E2B/E4B에서 128K, 12B/26B/31B에서 256K 토큰의 컨텍스트 윈도우를 지원합니다. 이 장문맥(long context)을 가능하게 하는 핵심 기술이 Proportional RoPE(p-RoPE)입니다.

RoPE와 p-RoPE의 차이

RoPE(Rotary Position Embedding)는 토큰의 위치 정보를 임베딩 벡터에 회전(rotation)으로 인코딩하는 방식입니다. 표준 RoPE는 학습 시 본 최대 길이를 넘어가면 성능이 급격히 저하되는 문제가 있습니다.

p-RoPE는 이 문제를 해결하기 위해 회전 주파수를 시퀀스 길이에 비례(proportional)하여 조정합니다. 핵심 아이디어는 단순합니다. 시퀀스가 길어지면 회전 속도를 그에 비례하여 늦춰서, 학습 시 본 상대적 위치 관계를 긴 시퀀스에서도 유지하는 것입니다.

기존에도 YaRN, NTK-aware RoPE 같은 장문맥 확장 기법이 있었지만, p-RoPE는 Gemma 4의 하이브리드 어텐션과 결합되어 특히 효과적으로 작동합니다. 로컬 레이어는 슬라이딩 윈도우 내에서만 어텐션을 수행하므로 위치 인코딩의 외삽(extrapolation) 문제가 없고, 글로벌 레이어에서만 p-RoPE가 장거리 위치를 처리하면 됩니다. 하이브리드 구조 자체가 장문맥에 유리한 셈입니다.

기능적 아키텍처: 함수 호출, Thinking, 드래프트 모델

아키텍처 혁신 외에도 Gemma 4는 모델의 기능적 측면에서 중요한 변화를 도입했습니다.

네이티브 함수 호출(Function Calling)

Gemma 3에서는 함수 호출을 위해 프롬프트 엔지니어링에 의존했습니다. Gemma 4는 6개의 전용 제어 토큰을 학습 데이터에 포함시켜, 함수 호출을 모델의 네이티브 기능으로 만들었습니다.

<|tool|>        / <tool|>         — 도구 정의 영역
<|tool_call|>   / <tool_call|>    — 함수 호출 영역
<|tool_response|> / <tool_response|>  — 함수 응답 영역

이 토큰들이 어휘에 포함되어 있으므로, 모델이 “도구를 호출해야 할 타이밍”과 “호출 결과를 해석하는 방법”을 사전학습 단계에서 학습합니다. tau2-bench(에이전트 도구 사용 벤치마크)에서 86.4%를 기록한 것은 이 네이티브 지원의 직접적인 결과입니다. 같은 벤치마크에서 Gemma 3은 6.6%에 불과했습니다.

시스템 역할(System Role) 네이티브 지원

Gemma 3에는 시스템 프롬프트가 공식적으로 지원되지 않았습니다. Gemma 4는 시스템 역할을 토크나이저 수준에서 지원합니다. 에이전트 프레임워크에서 시스템 프롬프트로 행동 지침을 설정하는 것이 표준 패턴인데, 이 지원이 없으면 user 메시지에 시스템 지침을 끼워넣는 우회가 필요했습니다.

구성 가능한 Thinking 모드

<|think|> 토큰을 통해 Chain-of-Thought 추론을 명시적으로 트리거할 수 있습니다. Thinking 모드에서는 4,000개 이상의 추론 토큰을 생성하면서 복잡한 문제를 단계별로 풀어갑니다. 31B Thinking 모드의 벤치마크 성능은 다음과 같습니다.

다만 이 비교에는 유의할 점이 있습니다. Gemma 4 31B Thinking은 수천 토큰의 CoT 추론을 수행하는 반면, Gemma 3 27B는 non-thinking 모드의 결과입니다. 동등한 조건의 비교라기보다는, Thinking 모드가 얼마나 강력한지를 보여주는 수치로 해석하는 것이 적절합니다.

전용 드래프트 모델과 투기적 디코딩

Gemma 4의 모든 변형에는 전용 드래프트 모델(draft model)이 함께 제공됩니다. 투기적 디코딩(speculative decoding)은 작은 드래프트 모델이 여러 토큰을 먼저 생성하고, 큰 타겟 모델이 이를 한꺼번에 검증하는 방식입니다. 출력 품질은 타겟 모델과 동일하면서 추론 속도만 빨라집니다.

이전에는 드래프트 모델을 따로 찾거나 학습해야 했는데, Gemma 4는 각 변형에 최적화된 드래프트 모델을 공식적으로 제공합니다. 프로덕션 서빙에서 바로 활용할 수 있습니다.

DiffusionGemma: 자기회귀를 넘어서

Gemma 4 패밀리에는 흥미로운 실험적 변형도 있습니다. DiffusionGemma는 26B A4B 아키텍처를 기반으로 하되, 자기회귀(autoregressive) 디코딩 대신 블록 디퓨전(block diffusion)을 사용합니다.

자기회귀 모델은 토큰을 하나씩 순차적으로 생성합니다. DiffusionGemma는 256개 토큰으로 구성된 블록을 동시에 생성합니다. 이미지 생성에서 디퓨전 모델이 한 번에 전체 이미지를 만들어내듯, 텍스트에서도 비슷한 접근을 시도하는 것입니다.

아직 실험적 단계이므로 프로덕션 배포에는 적합하지 않지만, 자기회귀의 근본적인 속도 제약(토큰당 한 번의 포워드 패스)을 벗어나려는 시도로서 주목할 만합니다.

마치며

Gemma 4는 단순한 모델 크기 업그레이드가 아닙니다. 하이브리드 어텐션으로 효율과 표현력의 균형을 잡고, PLE로 소형 모델의 한계를 밀어붙이고, 인코더 프리 아키텍처로 멀티모달 통합의 새로운 방향을 제시하고, 128개 미세 전문가 MoE로 추론 효율성을 극대화했습니다. 거기에 Apache 2.0 라이선스까지, 오픈소스 LLM 생태계에서 Gemma 4의 포지션은 상당히 매력적입니다.

실무에서 어떤 변형을 선택할지는 결국 배포 환경에 달려 있습니다. 모바일이면 E2B/E4B, 오디오까지 처리해야 하면 12B, 처리량이 중요하면 26B MoE, 품질이 최우선이면 31B. 하나의 설계 철학에서 갈라진 다섯 갈래 길 중 자신의 상황에 맞는 모델을 고르면 됩니다.

참고자료

• Gemma 4 Model Card - Google AI for Developers
• Gemma 4 - Google DeepMind
• Introducing Gemma 4 - Google Blog
• Introducing Gemma 4 12B - Google Blog
• A Visual Guide to Gemma 4 - Maarten Grootendorst