AI 모델은 보통 같은 구조를 크게 혹은 작게 만드는 방식으로 가족을 구성합니다. 그런데 Google이 Gemma 4에서 한 일은 달랐습니다. 엣지 모델(E2B·E4B)과 서버 모델(26B·31B)은 이름만 같은 가족일 뿐, 내부 설계 자체가 다릅니다. 단순히 크기를 줄인 게 아니라, 아키텍처 DNA를 처음부터 다르게 짰습니다.

Google DeepMind가 공개한 Gemma 4의 아키텍처를 분석한 결과, 엣지와 서버 모델이 공유하는 설계 원칙이 거의 없다는 사실이 드러났습니다. 스마트폰과 데이터센터 서버가 처한 하드웨어 제약이 물리적으로 정반대이기 때문입니다. 이 선택이 AI 모델 설계의 방향이 어디로 가고 있는지를 보여줍니다.

출처: Gemma 4 — Google DeepMind – Google DeepMind

폰과 서버의 제약은 정반대다

스마트폰에는 플래시 저장소가 넉넉합니다. 128GB는 기본입니다. 대신 DRAM은 8GB 안팎이고, 모델 가중치·KV 캐시·활성화값이 전부 그 안에서 경쟁해야 합니다. 반대로 H100 서버는 80GB HBM 메모리를 가지고 있고, 비용이 드는 건 메모리가 아니라 연산(FLOP)입니다.

메모리가 부족하면 연산을 더 써서 보완하고, 연산이 비싸면 메모리를 더 써서 아낍니다. 제약의 방향이 정반대이면 최적 설계도 정반대가 됩니다. 이게 Gemma 4 엣지와 서버 모델이 다른 이유의 전부입니다.

그리고 이 논리는 Gemma 4만의 이야기가 아닙니다.

Gemma 4가 보여준 선택들

엣지 모델이 채택한 가장 극단적인 설계가 레이어별 임베딩(Per-Layer Embeddings, PLE)입니다. 일반적인 트랜스포머는 토큰을 하나의 임베딩 벡터로 변환한 뒤 그것을 모든 레이어가 공유합니다. E2B는 hidden size가 1,536으로 좁은데, 이 좁은 공간 안에 “bank(은행)”와 “bank(강둑)”의 의미가 충돌합니다. 좁을수록 구별이 어렵습니다.

Google의 해법은 각 레이어에 독립된 임베딩 테이블을 두는 것이었습니다. 35개 레이어가 각자 토큰을 새로 조회합니다. 문제는 이 테이블이 파라미터 예산의 46%를 씁니다. 5.1B 모델에서 2.35B가 임베딩 테이블입니다. 여기서 폰의 플래시 저장소가 결정적입니다. 이 테이블은 DRAM이 아닌 플래시에 저장하면 됩니다. 한 번 읽으면 끝이니 레이턴시가 문제가 되지 않고, 폰에 128GB가 있으니 공간도 충분합니다. 서버 모델(26B·31B)은 이 기법을 쓰지 않습니다. H100에는 플래시 비대칭이 없고, hidden size도 충분히 넓어서 충돌 자체가 없기 때문입니다.

KV 캐시 처리도 마찬가지입니다. 128K 컨텍스트를 표준 7B 모델로 처리하면 KV 캐시만 12.8GB가 필요합니다. 폰의 전체 DRAM과 맞먹습니다. E2B는 여기에 두 가지를 적용했습니다. 먼저 크로스레이어 KV 공유로 35개 레이어 중 20개가 K/V를 직접 계산하지 않고 앞 레이어의 것을 재사용합니다. 다음으로 GQA(Grouped-Query Attention)로 KV 헤드를 8:1로 압축합니다. 두 기법을 합치면 KV 캐시가 수십 GB에서 수백 MB로 줄어듭니다. 이게 128K 컨텍스트가 8GB 폰에서 작동하는 이유입니다.

서버 모델의 핵심은 Hybrid MoE입니다. 26B는 128개 전문가(expert) 중 8개만 활성화하는 극단적인 희소 구조인데, 라우팅이 틀렸을 때의 품질 붕괴를 막기 위해 항상 켜진 Dense FFN을 함께 붙였습니다. 전문가가 틀려도 Dense 경로가 최소한의 출력 품질을 보장합니다. 결과적으로 25.2B 파라미터를 가지지만 추론 시 3.8B만 활성화합니다. 메모리는 25B급, 연산은 4B급입니다.

같은 압력이 다른 곳에서도 작동하고 있다

KV 캐시 문제를 Gemma 4만 풀려는 게 아닙니다. DeepSeek의 MLA(Multi-Head Latent Attention)는 K/V를 작은 잠재 벡터로 압축해 캐시 크기를 93% 줄였습니다. Mamba는 아예 어텐션을 쓰지 않고 선택적 상태 업데이트로 시퀀스를 처리합니다. 접근 방식은 각자 다르지만 목표는 같습니다. O(n²)로 폭발하는 어텐션 비용을 어떻게든 억제하는 것.

칩 설계도 비슷한 방향으로 움직입니다. 훈련과 추론의 요구사항이 달라서 하드웨어 설계가 분기하고 있고, 텍스트·이미지·비디오에 맞는 토크나이저와 처리 방식이 각각 달라지고 있습니다. 어느 레이어를 보더라도 “하나로 전부”라는 답이 점점 설득력을 잃고 있습니다.

Gemma 4의 아키텍처 분리는 이 흐름의 한 사례입니다. 폰과 서버라는 물리적으로 정반대의 제약 앞에서, 이름만 같고 설계는 다른 모델 패밀리가 등장했습니다. 균일한 스케일링이 당연하게 받아들여지던 시절은 끝나가고 있고, 하드웨어의 물리적 특성을 설계에 직접 반영하는 방향으로 무게중심이 이동하고 있습니다.

Gemma 4의 각 설계 결정이 어떻게 맞물리는지, 그리고 현재 H100 같은 서버 하드웨어에서 실제로 겪는 성능 문제는 원문에서 더 깊이 다룹니다.

참고자료:

• Google’s Gemma 4 will Change How AI Models are Built – Artificial Intelligence Made Simple