2.3B 파라미터 모델이 작년 27B를 수학, 코딩, 긴 문맥 처리에서 전부 이겼다. 장난이 아니라 진짜 벤치마크 결과다. Gemma 4 E2B가 풀린 지 나흘, 커뮤니티에서는 벌써 iPhone 16 Pro 위에서 초당 30토큰을 뽑고 있다. 라이선스 얘기는 지난번에 했으니 오늘은 순수하게 "폰에서 돌리면 어떤가"에 집중한다.

숫자가 이상하다

E2B의 유효 파라미터는 2.3B다. 임베딩까지 합치면 5.1B이지만 추론 시 활성화되는 건 2.3B뿐. 그런데 작년 플래그십이었던 Gemma 3 27B와 나란히 놓으면 결과가 뒤집힌다.

벤치마크 E2B (2.3B) Gemma 3 27B
AIME 2026 37.5% 20.8%
LiveCodeBench v6 44.0% 29.1%
Codeforces ELO 633 110
GPQA Diamond 43.4% 42.4%
MATH-Vision 52.4% 46.0%
Long Context 128k 19.1% 13.5%

수학, 코딩, 긴 문맥에서 12배 작은 모델이 완승이다. MMLU Pro(60% vs 67.6%)와 MMMU Pro(44.2% vs 49.7%)에서는 27B가 앞서는데, 일반 지식을 많이 외워야 하는 영역이라 파라미터 수가 유리한 건 당연하다. 핵심은 추론이 필요한 작업에서 모델 크기가 더 이상 결정적 변수가 아니라는 거다.

PLE가 만든 차이

비밀 병기는 Per-Layer Embeddings다. 보통 트랜스포머는 토큰을 입력층에서 한 번 임베딩하고, 그 벡터 하나를 전체 레이어가 공유한다. 초기 표현에 모든 걸 담아야 하니 작은 모델은 구조적으로 불리했다.

PLE는 매 디코더 레이어마다 별도의 저차원 조건 벡터를 추가로 주입한다. 토큰 ID 기반 임베딩과 학습된 프로젝션을 결합한 신호가 레이어마다 다르게 들어간다. 비유하자면 같은 크기 사무실이지만 각 층에 맞춤형 업무 지시서를 따로 배포하는 것이다. 히든 사이즈보다 훨씬 작은 차원이라 파라미터 비용은 미미하면서 레이어별 특화는 극대화된다.

이게 재밌는 부분인데, 멀티모달 입력에서는 토큰 ID 자체가 없다. 이미지나 오디오는 소프트 토큰으로 변환되면서 원래 ID가 사라지기 때문이다. PLE는 이 경우 pad 토큰 ID로 중립 신호를 보낸다 — 소프트 토큰이 임베딩 시퀀스에 병합되기 전에 미리 계산하는 방식이라 멀티모달에서도 아키텍처가 깨지지 않는다. 깔끔한 설계다.

폰 위의 현실

HN에서 iPhone 16 Pro로 30 tok/s를 찍었다는 보고가 화제였다. 다만 "폰이 상당히 뜨거워진다"는 단서가 붙었다. 지속적 대화보다는 간헐적 쿼리 패턴에 맞다는 뜻이다.

커뮤니티 후기를 종합하면 그림이 좀 더 선명해진다. 역할극, 문서 분석, 간단한 에이전틱 판단에서는 크기 대비 놀라울 정도로 잘 한다. 어떤 개발자는 아이가 저가형 안드로이드 기기로 외국어 읽기·쓰기를 연습하는 데 쓰고 있다고 했다. hCaptcha 스크린샷을 풀었다는 보고도 있다 — 시각 처리 능력이 2B급 치고는 의외의 결과다.

반면 약점도 확실하다. 코딩 보조로는 Qwen 3.5 27B에 한참 못 미치고, E4B 기준으로 세션에서 질문 세 번째부터 응답이 흐트러진다는 보고가 있다. 지식 컷오프가 2023년 10월이라 최근 프레임워크나 API 변경 사항은 아예 모른다. Markdown·LaTeX 렌더링이 안 되고 생성 중 스크롤이 버벅인다는 UX 불만도 나왔다.

구글은 이와 별개로 AICore Developer Preview를 열었다. 안드로이드에서 ML Kit을 통해 Gemma 4를 네이티브로 호출하는 프리뷰인데, 지금 작성하는 코틀린 코드가 나중에 Gemini Nano 4 탑재 양산 기기에서 그대로 돌아간다. 배터리 소비는 이전 세대 대비 60% 줄었고 E2B는 E4B보다 3배 빠르다. 지연시간이 생명이면 E2B, 복잡한 멀티스텝 추론이 필요하면 E4B — 이 기준으로 고르면 된다.

지금 해볼 것

가장 빠른 경로는 llama.cpp다. macOS라면 brew install llama.cppllama-server -hf ggml-org/gemma-4-E2B-it-GGUF 한 줄이면 OpenAI 호환 로컬 서버가 뜬다. Apple Silicon에서는 MLX도 선택지인데, TurboQuant 양자화를 걸면 활성 KV-cache 메모리를 4분의 1로 줄일 수 있다 — 지난번 TurboQuant 글에서 다뤘던 바로 그 기법이다.

안드로이드 앱을 만들고 있다면 AICore Developer Preview 등록이 먼저다. 코틀린에서 GenerativeModel.getClient() 호출 몇 줄이면 온디바이스 추론이 붙고, 올해 하반기 양산 기기에서 하드웨어 가속까지 자동으로 적용된다.

솔직히 E2B는 만능이 아니다. 주력 코딩 에이전트로 쓰기엔 역부족이고 긴 대화에서 불안정하다. 하지만 "주머니 속 오프라인 AI가 작년 서버급 모델을 추론 태스크에서 이긴다"는 문장이 사실이 됐다. 1년 전에는 농담이었다.