한 줄 정의

A4B MoE는 Gemma 4 26B A4B처럼 큰 모델이 매 토큰마다 전부 계산하는 게 아니라, 필요한 Mixture of Experts(전문가 혼합) 블록만 골라 켠다는 뜻을 읽게 해 주는 표기야. 이 항목의 기준선은 Google Gemma 4 model card고, 여기서 A4B는 dense 4B 모델 이름이 아니라 26B급 모델 안에서 실제 Inference (추론) 때 켜지는 계산량을 따로 읽으라는 신호에 가깝다.

어떻게 작동하나

이 표기는 dense 모델처럼 매번 모든 가중치를 다 쓰는 구조가 아니라, 입력마다 필요한 expert만 골라 계산하는 희소 MoE라는 뜻이야. 여기서 expert는 토큰마다 선택해서 쓰는 전문가 블록이고, shared expert는 어떤 토큰이 들어와도 공통으로 붙는 블록이라고 보면 돼. 이름에 붙은 26B는 전체 모델 크기 축이고, A4B 쪽은 매 토큰 Inference (추론)에서 실제로 켜지는 계산량 축이야.

  • 전체 크기: Google Gemma 4 model card 기준으로 26B A4B는 총 25.2B 파라미터를 가진다.
  • 실제 계산량: 토큰마다 실제로 켜지는 활성 파라미터는 3.8B다.
  • 전문가 구성: expert는 전체 128개 중 8개만 토큰마다 선택되고, shared expert 1개는 공통으로 붙는다.
  • 문맥 구조: 모델은 30개 층으로 쌓였고, 최근 구간을 나눠 보는 슬라이딩 윈도우 크기는 1024다.
  • 입력 범위: 최대 Context Window(컨텍스트 윈도우)는 256K고, 텍스트와 이미지를 함께 입력받는다.

이 숫자 묶음은 공식 제품 정의를 읽는 구간이고, 메모리 해석은 따로 봐야 해. 긴 Long Context (긴 문맥)를 쓰면 KV Cache (KV 캐시)가 붙는데, 이건 긴 Context(컨텍스트)를 처리할 때 앞에서 읽은 토큰 상태를 쌓아 두는 Memory(메모리)라고 보면 된다. Kaitchup 분석은 이 모델의 BF16 (브레인 플로팅 포인트 16) KV cache가 최대 컨텍스트에서 약 5.20 GiB까지 갈 수 있다고 계산했는데, 이 숫자는 공식 제품 스펙이 아니라 긴 문맥에서 추가로 붙는 메모리 추정치로 읽는 게 맞다.

왜 중요한가

Local LLM (로컬 LLM)에서 Gemma (젬마) 계열을 볼 때 A4B MoE라는 이름이 따로 거론되는 건, “26B처럼 읽히는 모델인데 실제 토큰 계산은 더 가볍다”는 힌트를 주기 때문이야. 공식 카드만 봐도 26B A4B는 256K 문맥과 이미지 입력까지 함께 보는 큰 모델이라서, 단순한 소형 모델처럼 읽으면 바로 어긋나.

커뮤니티 운용 사례는 따로 봐야 해. LocalLLaMA (로컬라마)의 해당 보고에서는 245,283 / 262,144, 즉 약 94% Context Window(컨텍스트 윈도우)까지 채운 상태에서 특정 사용자의 발화 품질 테스트가 맞았다고 적지만, 이건 공식 capability 보장이 아니라 특정 llama.cpp(로컬 LLM 런타임)와 Unsloth GGUF(GGUF 모델 파일 형식) 조합에서 나온 현장 체감에 가깝다. 제품 사실은 공식 카드로 읽고, 이런 커뮤니티 숫자는 배포 환경 감각을 잡는 보조 사례로만 쓰는 게 맞아.

주의해서 볼 점

A4B MoE를 그냥 “4B 모델”이라고 읽으면 거의 바로 판단이 틀어져. 이 표기는 계산량을 줄이는 희소 구조를 설명할 때는 유용하지만, 실제 배포 판단은 아래처럼 따로 체크해야 해.

Reddit 같은 현장 보고는 그 환경에서 어떤 체감이 나왔는지 보여 줄 뿐이고, A4B MoE 자체의 제품 정의나 공식 capability를 대신해 주지는 않아.