유효 파라미터 2B로 27B를 이기는 방법: Gemma 4(E2B·E4B)의 계층별 임베딩(PLE)과 온디바이스 양자화 해부

모바일 칩셋 위에서 계층별 임베딩(PLE) 평면과 다중 토큰 예측(MTP) 광선, 1GB 미만의 2비트 양자화 코어가 결합되어 동작하는 모습을 표현한 3D 아이소메트릭 개념 일러스트다. 실제 하드웨어 다이(die) 사진이나 프로파일러 화면이 아니다.

Google이 공개한 Android Dev Summit 2026 온디바이스 모델 아키텍처 세션 영상(Inside Gemini Nano and Gemma 4 powering on-device intelligence)과 Gemma 4 공식 기술 문서는 메모리 용량(12~16GB)과 대역폭(50~80GB/s), 배터리 전력이 엄격히 제한된 스마트폰 환경에서 어떻게 이전 세대 27B 서버급 모델보다 높은 추론·코딩·에이전트 성능을 구현했는지를 다룬다. Gemma 모델링 팀의 엔지니어링 리드 Sarah는 Apache 2.0 라이선스로 전환된 Gemma 4 E2B 및 E4B의 세 가지 핵심 설계와 AICore(Gemini Nano 4)·LiteRT 통합 경로를 상세히 소개했다.

결론부터 말하면, 온디바이스 소형 모델(Gemma 4 E2B·E4B)이 Gemma 3 27B를 추월할 수 있었던 비결은 연산에 참여하는 유효 파라미터(2.3B·4.5B)와 룩업 테이블로만 쓰이는 계층별 임베딩(Per-Layer Embeddings, PLE)을 분리해 RAM 대역폭 병목을 피하고, 타깃 모델의 KV 캐시를 공유하는 다중 토큰 예측(MTP) 드래프터와 2비트 QAT 모바일 양자화로 모델 크기를 1GB 미만까지 압축한 데 있다. 다만 이 글은 Google의 공식 발표 영상과 기술 보고서를 교차 검증해 아키텍처 원리를 정리한 것이며, 실제 단말기 기종별 발열이나 토큰 생성 속도(tok/s)를 직접 실측한 벤치마크는 아니다.

왜 ‘E2B·E4B’인가: 총 파라미터와 유효(Effective) 파라미터의 분리

Android Dev Summit 2026 — Inside Gemini Nano and Gemma 4 공식 세션 썸네일 이미지 (원본 JPEG)

Gemma 4 제품군 중 모바일과 엣지 기기를 겨냥한 모델 이름에는 E2B, E4B처럼 알파벳 **‘E(Effective)’**가 붙는다(Gemma 4 기술 보고서). 이는 MoE(Mixture-of-Experts)의 활성 파라미터 개념과는 전혀 다른 계층별 임베딩(Per-Layer Embeddings, PLE) 구조에서 비롯된 표기다.

일반적인 트랜스포머는 입력단에서 토큰 임베딩을 한 번만 조회한 뒤 모든 디코더 층을 통과시킨다. 반면 Gemma 4 E2B(총 5.1B, 35개 층)와 E4B(총 8B, 42개 층)는 262,144개 어휘(vocabulary)에 대해 각 디코더 층마다 별도의 작은 임베딩 테이블을 둔다(Per-Layer Embeddings 구조 해설).

전체 행렬 곱셈 없이 입력 토큰만 선별 조회(Lookup): MoE 모델은 다음 토큰이 어느 전문가(expert)로 라우팅될지 미리 알 수 없어 26B 전체 가중치를 빠른 메모리에 올려두어야 한다. 반면 PLE는 입력 시퀀스의 토큰 ID가 처음부터 정해져 있으므로, 해당 토큰들에 대응하는 임베딩 벡터만 플래시 스토리지나 별도 메모리 영역에서 즉시 조회해 각 층의 은닉 상태(hidden state)에 게이팅(gating) 방식으로 주입한다.

2B급 연산량으로 5B~8B급 지식 용량 확보: 결과적으로 매 토큰 생성 시 행렬 곱셈(compute)과 메모리 대역폭을 소모하는 핵심 트랜스포머 가중치는 E2B가 2.3B, E4B가 4.5B에 불과하다. 이 구조 덕분에 Gemma 4 E2B는 코딩 벤치마크인 LiveCodeBench에서 44점을 기록하며 이전 세대 대형 모델인 Gemma 3 27B(29점)를 크게 앞섰고, E4B는 발표된 모든 추론·코딩·에이전트 벤치마크에서 Gemma 3 27B를 넘어섰다.

모바일 3대 제약(메모리·대역폭·전력)을 돌파하는 3가지 핵심 기법

발표(11:33~18:34)에서는 제한된 모바일 하드웨어 위에서 긴 컨텍스트(최대 128K 토큰)와 멀티모달(비전·오디오)을 돌리기 위해 결합한 세 가지 엔지니어링 기법을 다음과 같이 비교한다.

최적화 기법	핵심 동작 원리	모바일 하드웨어에서 얻는 정량적 이점
계층별 임베딩 (Per-Layer Embeddings, PLE)	전체 파라미터 중 절반 이상(`E2B` 기준 5.1B 중 2.8B)을 층별 토큰 룩업 테이블로 분리하여 입력에 쓰인 토큰의 임베딩만 런타임에 로드	연산 및 메모리 대역폭은 2.3B / 4.5B 유효 파라미터 수준으로 유지하면서 대형 모델 수준의 어휘·지식 표현력 확보
KV 캐시 공유 다중 토큰 예측 (MTP Drafter)	4개 층(약 76M 파라미터) 규모의 초소형 드래프터가 한 번에 3~4개 토큰을 예측(Speculative Decoding)하되, 독자적인 프리필(prefill) 없이 베이스 모델의 KV 캐시를 교차 어텐션으로 그대로 공유	1,000토큰 프롬프트 기준 프리필 시간 약 130ms 절약(타 드래프터 대비 30~40배 빠른 구동), 토큰 수락률 40~60% 향상, 디코드 지연 시간 40% 단축 및 배터리 소모 30~40% 절감
2비트 QAT 모바일 양자화 (Mobile Quant)	양자화 인지 학습(QAT)을 통해 핵심 가중치를 2비트(2-bit)까지 압축하고, 채널 단위(channel-wise) 양자화·정적 활성화 범위(static activation range)·임베딩 및 KV 캐시 양자화를 결합	런타임 동적 범위 계산 오버헤드를 제거하고 `E2B` 모델 전체 크기를 1GB 미만으로 축소하여 장시간 대화 시 메모리 고갈 방지

또한 멀티모달 처리에서도 이미지를 정사각형으로 억지로 찌그러뜨리지 않고 원본 비율을 유지하는 **가변 종횡비(Variable Aspect Ratio, 150M ViT 인코더)**를 도입해 표·스프레드시트·차트 OCR과 객체 좌표 지시(pointing) 정확도를 높였으며, 개발자가 **시각 토큰 예산(Visual Token Budget, 최대 70~1,120토큰)**을 직접 조절해 해상도와 전력 소모 사이의 균형을 맞출 수 있게 했다. 오디오 역시 305M Conformer 기반 인코더를 내장해 35개 이상 언어의 음성 인식·번역을 즉시 지원한다.

AICore(Gemini Nano 4)와 LiteRT(번들링) 경로의 선택 기준

Android 앱에서 이 모델들을 호출하는 방법은 운영체제 공유 런타임을 쓰는 경로와 앱 내부에 모델을 직접 묶는 경로의 두 가지로 나뉜다.

비교 항목	시스템 공유 경로 (`AICore` • `ML Kit GenAI`)	앱 자체 번들링 경로 (`LiteRT` • `Gemma 4`)
실행 모델 및 배포 방식	기기 OS에 내장되어 여러 앱이 공유하는 `Gemini Nano 4` 사용 (앱 APK 용량 증가 없음)	개발자가 선택한 `Gemma 4` 체크포인트(`Q4_0` 또는 커스텀 파인튜닝 모델)를 앱에 포함해 배포
하드웨어 최적화 지원	2비트 `Mobile Quant`, RAM 외부 `PLE` 로딩, `MTP` 스페큘레이티브 디코딩, 입출력 2중 안전(Safety) 필터가 기본 내장	범용 `Q4_0` 양자화 및 커스텀 가중치 제어 가능. 단, 메모리 점유율과 배터리 소모를 개발자가 직접 관리해야 함
권장 사용처	별도 파인튜닝 없이 요약·재작성·함수 호출(Agentic API)·멀티모달 이해를 빠르게 도입하려는 일반 Android 앱	140개 프리트레이닝 언어 중 비주류 언어 파인튜닝이 필요하거나 iOS·데스크톱·웹까지 동일한 커스텀 가중치를 배포해야 하는 경우

온디바이스 AI 기능을 설계할 때 확인할 점

모바일 앱에 Gemma 4나 Gemini Nano 4를 실제로 통합할 때는 발표에서 언급된 다음 세 가지 제약을 먼저 확인해야 한다.

모델 아키텍처 한도(128K)와 ML Kit 런타임 컨텍스트 예산의 구분: Gemma 4 E2B·E4B 모델 자체는 최대 128K 컨텍스트를 지원하지만, 공유 서비스인 ML Kit은 단말기 메모리 보호를 위해 입력 컨텍스트 길이에 별도의 상한(cap)을 둔다. 장문 문서나 고해상도 이미지를 넣기 전에 타깃 API의 실제 토큰 한도를 먼저 확인하고 필요시 시각 토큰 예산을 줄여야 한다.

직접 추론(LiteRT 등) 시 챗 템플릿(Chat Template) 엄격 준수: ML Kit을 쓰면 프롬프트 포맷팅이 자동으로 처리되지만, LiteRT나 오픈소스 런타임에서 직접 에이전트 루프와 도구 호출(tool calling)을 구현할 때는 Gemma 4 전용 시스템 프롬프트 및 챗 템플릿 토큰이 조금만 어긋나도 JSON 출력이나 다단계 추론 품질이 급격히 떨어지므로 공식 토크나이저 템플릿을 그대로 사용해야 한다.

오프라인 환경 및 폴백(Fallback) 시나리오 검증: 비행기 모드나 등산·현장 작업처럼 네트워크가 완전히 끊긴 상태에서도 함수 호출과 카메라 화면 인식이 정상 동작하는지 확인하고, 구형 기기에서 AICore가 지원되지 않을 때의 서버 API 폴백 또는 기능 비활성화 처리를 함께 설계하는 편이 안전하다.

결국 온디바이스 AI의 핵심은 서버 모델을 단순히 잘라내는 것이 아니라, 플래시 스토리지와 RAM 대역폭의 물리적 특성을 고려해 파라미터 조회(PLE)와 연산을 분리하는 아키텍처 수준에서 결정된다.