LocalLLaMA가 해설한 Gemma 4의 Per-Layer Embeddings, 소형 모델이 다른 이유

LocalLLaMA의 기술 설명 글이 Gemma 4 소형 모델의 이름 표기와 추론 특성을 이해하는 데 도움이 되는 관점을 제시했다. 작성자는 gemma-4-E2B와 gemma-4-E4B를 전통적인 dense model이나 전형적인 Mixture-of-Experts로 보지 말아야 한다고 설명하면서, 핵심 차별점으로 Per-Layer Embeddings, 즉 PLE를 짚는다.

게시글에 따르면 gemma-4-26B-A4B 같은 MoE 모델은 전체 파라미터 수는 크지만 token마다 일부 expert만 활성화된다. 다만 어떤 expert가 호출될지 미리 알 수 없기 때문에 전체 가중치를 VRAM이나 빠른 메모리에 올려 둬야 한다. 반면 gemma-4-E2B는 총 5.1B parameters 중 2.8B가 embedding parameters이며, Google은 이를 제외한 2.3B 정도를 “effective” parameter로 본다고 소개된다. 작성자는 이 차이를 이해하려면 embedding을 행렬 곱이 아니라 lookup table 관점에서 봐야 한다고 주장한다.

PLE가 바꾸는 추론 비용의 감각

설명의 요지는 이렇다. 일반적인 입문 자료에서는 embedding matrix를 큰 선형 연산처럼 설명하지만, 실제 inference에서는 필요한 token ID에 해당하는 벡터만 읽어 오면 된다. PLE는 이런 embedding table이 layer별로 추가된 구조이고, 요청마다 vocabulary 전체를 계산하는 것이 아니라 실제로 등장한 token에 해당하는 일부 entry만 접근한다. 그래서 전체 parameter 수는 커 보여도, 계산과 메모리 접근 패턴은 전통적인 dense layer와 다르게 최적화할 수 있다는 것이다.

이 관점이 중요한 이유는 on-device inference 가능성 때문이다. 글은 PLE가 많은 비중의 파라미터를 차지하더라도, 그 데이터가 반드시 GPU VRAM에 상주할 필요는 없으며 경우에 따라 CPU RAM이나 storage에 두는 접근도 가능하다고 정리한다. 정확한 구현 세부는 공식 문서를 더 확인해야 하지만, 최소한 Gemma 4 E 계열이 왜 작은 활성 파라미터 수를 강조하는지 이해하는 데는 꽤 유용한 설명이다.

공식 문서 전 해설로서의 가치

물론 이 글은 커뮤니티 해설이지 Google의 공식 architecture note는 아니다. 따라서 세부 수치나 구현 방식은 원문 모델 카드와 추가 문서를 함께 보는 편이 안전하다. 그럼에도 LocalLLaMA가 이 글에 반응한 이유는 분명하다. PLE를 “왜 빠를 수 있는가”라는 관점에서 풀어 주면서, Gemma 4 소형 모델을 dense vs MoE의 단순 구도로만 읽는 오해를 줄여 주기 때문이다. Gemma 4를 모바일이나 edge device 관점에서 보는 개발자라면 충분히 읽어 둘 만한 요약이다.

특히 제품 기획이나 inference 최적화를 고민하는 팀에는 이런 설명이 실무적인 가치를 가진다. parameter 총량만 보고 하드웨어 비용을 추정하던 방식에서 벗어나, 어떤 종류의 파라미터가 실제 latency와 memory pressure를 만드는지 더 세분화해 볼 수 있기 때문이다.