150M의 작업을 35M로 해결: Google Gemma 4 12B의 혁신

150M의 작업을 35M로 해결했습니다.
Google에서 새로 출시한 Gemma 4 12B는 멀티모달 (Multimodal)에서 가장 무거운 부품인 비전 인코더 (Vision Encoder)를 150M~550M에서 35M로 직접 압축했습니다.

과거에 멀티모달을 구현하는 방식은 정해져 있었습니다.
이미지를 먼저 전문 비전 인코더 (Vision Encoder)에 던져 모델이 이해할 수 있는 언어로 번역한 뒤, 이를 대규모 언어 모델 (LLM)에 전달하여 이해하게 하는 방식이었죠. 마치 통역사를 붙여주는 것과 같았습니다.

이 통역사 역할을 하는 전통적인 ViT 인코더는 150M에서 550M의 파라미터 (Parameters)가 필요했습니다.

Gemma 4 12B는 이 통역사를 아예 해고해 버렸습니다.
대신 35M 규모의 경량 임베더 (Embedder)만을 남겨두어, 이미지를 48×48 크기의 작은 조각으로 자른 뒤 토큰 (Token)으로서 직접 집어넣습니다.
그리고 Transformer가 스스로 세상을 보는 법을 배우게 만듭니다.

오디오도 마찬가지입니다. 16kHz 원시 파형 (Raw waveform)을 40ms 단위의 프레임으로 잘라 동일한 모델에 직접 입력합니다.

즉, 이미지, 소리, 텍스트가 처음으로 동일한 종류의 것으로 취급되는 것입니다.

왜 이런 방식을 감행할 수 있었을까요?

그것은 한 가지 사실에 도박을 걸었기 때문입니다.
기반 모델 (Base model)이 특정 임계점에 도달할 만큼 커지면, 전문화된 서브 모듈 (Sub-module)들은 더 이상 필수 요소가 아니게 된다는 점입니다.

이런 시나리우스는 이미 본 적이 있을 것입니다.
과거 ViT가 CNN을 대체했을 때도 똑같은 방식이었습니다.
규모가 충분히 커지면, 수많은 전용 구조를 수동으로 설계하는 것보다 하나의 통합된 대규모 모델에게 일을 직접 맡겨 스스로 배우게 하는 것이 더 낫습니다.

현재 이 논리는 비전 단일 모달리티 (Vision single-modality)에서 멀티모달 아키텍처 (Multimodal architecture) 전체로 확산되고 있습니다.

또한 12B라는 사이즈는 아무렇게나 선택된 것이 아닙니다.
인코더 (Encoder)를 버릴 수 있을 만큼 충분히 크면서도, 16GB 노트북에 들어갈 수 있을 만큼 딱 적당한 크기입니다.
aaryan_kakad의 M4 Max 실측 결과에 따르면, 4-bit 양자화 (Quantization) 상태에서 이미지 인식 지연 시간 (Latency)은 1.2초에서 1.5초 사이입니다.
공식적으로는 16GB면 충분하다고 하지만, 커뮤니티의 의견은 더 현실적입니다. 실행은 가능하지만 고해상도 다중 이미지는 한계치에 달할 것이라는 의견입니다.

하지만 이 뉴스가 진정으로 고민해 볼 가치가 있는 지점은, 이것이 당신의 노트북에서 돌아간다는 사실이 아닙니다.
이것이 무엇을 의미하는가 하는 점입니다.

과거에 멀티모달 애플리케이션을 만들려면 Whisper 전사 (Transcription), LLaVa 이미지 인식, 그리고 LLM을 연결하는 등 마치 기계를 조립하듯 각 부품의 인터페이스를 맞추고, 정렬(Alignment)하고, 디버깅해야 했습니다.

만약 인코더 프리 (Encoder-free) 방식이 성공한다면,
미래에는 잘 미세 조정된 (Fine-tuned) 하나의 통합 모델이 이 전체 파이프라인 (Pipeline)을 집어삼킬 수도 있습니다.

그 순간 가치가 떨어지는 것은 특정 도구가 아닙니다.
당신이 과거에 그 기계를 조립하고 파이프라인을 구축하며 쌓아온 모든 기술입니다.

모델은 단순히 부품 하나를 아껴주는 것이 아닙니다.
어떤 기술이 여전히 가치 있는지를 조용히 다시 쓰고 있는 것입니다.