인코더를 없앴더니 성능은 올라가고 메모리는 절반이 됐다 — Gemma 4 12B 아키텍처의 진짜 의미

이미지·오디오를 직접 처리하는 방식이 왜 기존 구조보다 훨씬 나은가

---

문제 제기: 멀티모달 모델이 무거운 근본 원인은 아키텍처에 있었다

"왜 멀티모달 모델은 이렇게 무거운가?" 이 질문의 답은 아키텍처에 있다.

 

기존 멀티모달 AI 모델의 구조를 따라가 보자.

이미지 입력
  → 비전 인코더 (CLIP, ViT 등 — 별도 모델)
  → 프로젝션 레이어 (인코더 출력을 LLM 차원으로 변환)
  → LLM 백본
  → 텍스트 출력

오디오 입력
  → 오디오 인코더 (Whisper 등 — 또 다른 별도 모델)
  → 프로젝션 레이어
  → LLM 백본
  → 텍스트 출력

 

이 구조에서 메모리는 세 층에서 동시에 잡는다.

• 비전 인코더 파라미터,
• 오디오 인코더 파라미터,
• LLM 백본 파라미터.
  그리고 각 단계를 거칠 때마다 지연시간이 누적된다.

12B 언어 모델 위에 비전 인코더를 올리면
실질적으로는 18~20B급 메모리가 필요한 경우가 많았다.
로컬 실행이 어려운 이유이다.

---

공감: LLaVA 쓰다 포기한 경험이 있다면

LLaVA(Large Language and Vision Assistant)
텍스트만 이해하던 기존의 대규모 언어 모델(LLM)에
시각적 이해 능력을 결합한 오픈소스 멀티모달 AI 모델

 

Ollama로 LLaVA를 써본 개발자들이 겪는 패턴이 있다.

# 시도 1: LLaVA 7B - 속도는 되는데 이미지 이해가 너무 기본적
# 시도 2: LLaVA 13B - 메모리 부족 또는 너무 느림
# 시도 3: BakLLaVA - 지원 중단
# 결론: 그냥 Claude API 쓰자

 

이 흐름이 반복되는 건 결국 아키텍처의 문제였다.

 

비전 인코더를 별도로 올리는 구조에서는
12~13B 모델이라도 실용적인 성능을 내면서 16GB 안에서 돌리기 어려웠다.

Gemma 4 12B는 이 구조를 처음부터 다시 설계하였다.

---

해결: 인코더를 없애면 무슨 일이 일어나는가

비전 처리: 인코더 → 경량 임베딩 모듈

Gemma 4 12B의 비전 처리 변화이다.

 

기존 방식:

이미지 → ViT/CLIP 인코더(수백M~수십억 파라미터) → 프로젝션 → LLM

 

Gemma 4 12B 방식:

이미지 → 경량 임베딩 모듈
        (단일 행렬 곱셈 + 위치 임베딩 + 정규화)
      → LLM 백본이 직접 시각 처리

 

인코더가 담당하던 시각적 특징 추출을 LLM 백본 자체가 담당하도록 훈련하였다.
별도 모델 가중치가 사라지고, 경량 임베딩 모듈만 남았다.

오디오 처리: 인코더 완전 제거

기존 방식:

오디오 → Whisper 등 오디오 인코더 → 프로젝션 → LLM

 

Gemma 4 12B 방식:

원시 오디오 신호
  → 텍스트 토큰과 동일한 차원 공간으로 직접 투영
  → LLM 백본이 직접 처리

 

오디오 인코더를 완전히 없앴다.
원시 신호를 텍스트 토큰과 같은 공간으로 매핑하는 투영 연산만 남는다.

---

이 방식이 가능한 이유: LLM 백본이 충분히 강해졌다

이 설계가 가능한 전제가 있다.
LLM 백본이 충분히 강력해야 인코더 없이도 시각·청각 정보를 직접 이해할 수 있다는 것이다.

 

구글은 Gemma 4 12B의 LLM 백본이 이 역할을 감당할 수 있도록 학습하였다.
멀티모달 인코더가 해주던 특징 추출과 표현 학습을
LLM이 직접 하도록 사전학습과 파인튜닝을 설계한 것이다.

 

결과는 수치를 통해 검증되었다.
26B MoE 모델 대비 메모리는 절반 미만, 표준 벤치마크 성능은 근접.

---

Multi-Token Prediction — 속도까지 챙긴 방법

아키텍처 최적화만으로는 부족하다.
16GB 노트북에서 실용적인 속도로 돌리려면 추론 속도도 중요하다.

 

Gemma 4 12B는 Multi-Token Prediction(MTP) drafters를 채택하였다.
기존 LLM은 한 번에 토큰 하나를 예측한다.
MTP는 여러 토큰을 동시에 예측하는 보조 헤드를 추가해 추론 속도를 높인다.

기존: 토큰 1 → 토큰 2 → 토큰 3 → ... (순차)
MTP: 토큰 1·2·3 동시 예측 초안 → 검증 → 확정 (병렬)

 

지연시간이 줄어들어 로컬 실행 경험이 더 자연스러워진다.

기술적 시나리오:
의료 문서와 X선 이미지를 함께 분석하는 내부 도구를 개발하는 경우,
기존에는 이미지를 Claude API로, 텍스트를 별도 로컬 모델로 분리 처리해야 했다.
Gemma 4 12B를 도입하면 단일 로컬 모델에서 이미지와 텍스트를 함께 처리할 수 있다.
"인터넷 없는 내부망에서 돌릴 수 있게 됐다"는 것이 가장 큰 변화다.

---

마치며

인코더를 없앤다는 것은 단순한 경량화가 아니다.
LLM 백본이 멀티모달 처리를 직접 내재화할 만큼 강력해졌다는 신호이다.

이 방향이 계속된다면 멀티모달 AI의 로컬 실행 장벽은 더 낮아질 것이다.
Gemma 4 12B는 그 방향의 현재 가장 실용적인 구현체이다.

---

📎 참고 출처

• Google 공식 블로그: https://blog.google/innovation-and-ai/technology/developers-tools/introducing-gemma-4-12b/
• Google Developers Guide: https://developers.googleblog.com/gemma-4-12b-the-developer-guide/