한 줄 정의
A4B MoE는 큰 모델이 매번 전부 계산하는 게 아니라, 필요한 전문가 블록 몇 개만 골라 켜는 전문가 혼합 방식이라고 보면 돼. Gemma 4 26B A4B 같은 이름에서 이 표기가 붙는 건 전체 모델 크기와 추론 때 실제로 켜지는 계산량을 따로 읽으라는 뜻이야. Google 공식 모델 카드 기준 이 모델은 전체 파라미터가 25.2B인데, 토큰마다 실제 활성 파라미터는 3.8B만 쓰고, 전문가 구성도 128개 중 8개와 공용으로 늘 같이 붙는 shared expert 1개가 동작하는 식으로 설명돼 있어.
어떻게 작동하나
이 표기는 dense 모델처럼 매번 모든 가중치를 다 쓰는 구조가 아니라, 입력마다 필요한 expert만 골라 계산하는 희소 MoE라는 뜻을 먼저 깔고 봐야 해. 여기서 dense는 “토큰마다 모델 전체 블록을 다 돈다”는 쪽이고, A4B MoE는 그중 일부만 켠다는 차이가 있어. Gemma 4 모델 카드에 따르면 26B A4B는 30 layers, 1024 sliding window, 256K context length를 갖고 text와 image 입력을 받는다. 그래서 이름에 26B가 붙는 이유는 전체 모델 크기 때문이고, A4B 쪽은 매 토큰 계산량이 더 작다는 뜻에 가깝다.
여기서 중요한 건 A4B가 곧장 “VRAM 4B급”을 뜻하지는 않는다는 점이야. 가중치 파일 자체는 25.2B급 모델로 다뤄야 하고, 긴 컨텍스트 윈도우를 쓰면 KV cache도 따로 붙는다. KV cache는 긴 문맥을 처리할 때 앞에서 읽은 토큰의 상태를 쌓아 두는 메모리라고 보면 돼. Kaitchup 분석은 26B A4B의 최대 컨텍스트 BF16, 즉 16비트 부동소수점 기준 KV cache를 약 5.20 GiB로 계산했는데, 이 숫자도 활성 파라미터가 아니라 긴 문맥에서 추가로 먹는 메모리 성격으로 봐야 해.
왜 중요한가
로컬에서 Gemma 계열을 고를 때 A4B MoE라는 이름이 따로 거론되는 건, “26B처럼 읽히는 모델인데 실제 토큰 계산은 더 가볍다”는 힌트를 주기 때문이야. Google 카드만 봐도 26B A4B는 256K 문맥, text/image 입력, 약 550M vision encoder를 같이 들고 있어서 단순한 소형 모델과는 결이 다르다.
- 계산량: dense 26B는 토큰마다 전체 블록을 다 돌리는 쪽으로 읽으면 되고, A4B MoE는 필요한 전문가 일부만 켜서 응답 속도 체감이 달라질 수 있어.
- 메모리: A4B라는 이름만 보고 가볍다고 보면 안 되고, 가중치 파일은 여전히 25.2B급으로 보고 긴 문맥에서는 KV cache까지 따로 더해야 해.
- 배포 방식: 양자화 방식, GGUF 변환본 유무, llama.cpp 같은 런타임에 따라 실제 속도와 VRAM 요구량이 크게 갈려.
커뮤니티가 이 용어를 자주 집는 이유도 여기에 있어. LocalLLaMA의 한 사용 사례에서는 245,283 / 262,144, 즉 약 94% 컨텍스트까지 채운 상태에서도 특정 사용자 발언 회상 테스트가 맞았다고 보고했다. 이건 공식 보장이라기보다, 최신 llama.cpp와 Unsloth GGUF 같은 조합에서 “A4B MoE가 긴 문맥 로컬 운용 후보로 보인다”는 체감 신호에 가깝다.
주의해서 볼 점
A4B MoE를 그냥 “4B 모델”이라고 읽으면 거의 바로 판단이 틀어져. 이 용어는 계산량을 줄이는 희소 라우팅을 설명하는 데는 유용하지만, 실제 배포에서는 모델 파일 크기, VRAM, KV cache, 양자화 방식, 런타임 구현이 같이 움직여. 특히 Reddit 같은 현장 보고는 재현 조건이 강하게 걸려 있으니, 용어 자체는 구조 설명으로 보고 성능 판단은 별도 벤치와 배포 환경으로 다시 확인하는 게 맞아.