Google DeepMind가 내놓은 Gemma 4는 오픈소스 AI 모델 중에서도 꽤 독특한 위치에 있어요. 같은 패밀리 안에 31B Dense(전통적 구조)와 26B-A4B MoE(전문가 혼합 구조), 완전히 다른 두 가지 아키텍처가 공존하거든요. 둘 다 Apache 2.0 라이선스라 상업적으로 자유롭게 쓸 수 있고, 텍스트와 이미지를 모두 처리하는 멀티모달 모델입니다. Google 공식 블로그에 따르면 Arena AI 텍스트 리더보드에서 31B가 오픈 모델 3위, 26B MoE가 6위를 기록하고 있어요.
Dense vs MoE, 구조가 어떻게 다른가?
31B Dense는 이름 그대로예요. 30.7B 파라미터가 전부 추론할 때마다 활성화됩니다. 60개 레이어가 전부 동원되는 거죠. 반면 26B-A4B MoE는 총 25.2B 파라미터를 갖고 있지만, 토큰 하나를 처리할 때 실제로 쓰이는 건 3.8B(약 4B)뿐이에요. 모델명에 "A4B"가 붙은 이유가 이거예요 — Active 4B.
MoE의 핵심은 이렇습니다. Dense 모델에서 단일 FFN(Feed-Forward Network)이 있는 자리에 128개의 전문가 FFN과 1개의 공유 전문가를 배치해요. 그리고 라우터가 각 토큰마다 8개의 전문가를 골라서 활성화합니다. 나머지 120개는 그 토큰에 대해서는 쉬고 있는 거죠. 공유 전문가는 모든 토큰에 항상 켜져 있어서 공통 지식을 담당해요.
비유하자면, Dense 모델은 모든 직원이 매번 회의에 참석하는 조직이고, MoE는 안건에 따라 필요한 전문가 8명만 회의실에 불러오는 조직이에요.
어텐션 구조는 뭘 공유하나?
두 모델 모두 로컬 슬라이딩 윈도우 어텐션과 글로벌 풀 어텐션을 5:1 비율로 섞는 하이브리드 어텐션을 씁니다. 31B는 60개 레이어 중 50개가 슬라이딩(1024 토큰), 10개가 글로벌이에요. 26B-A4B는 30개 레이어 중 25개 슬라이딩, 5개 글로벌이고요.
글로벌 어텐션 레이어에는 몇 가지 효율화 기법이 들어가 있어요. 8개의 Query 헤드가 1개의 KV 헤드를 공유하는 GQA, Key와 Value를 동일하게 만드는 K=V 기법, 그리고 RoPE 위치 인코딩을 전체 차원의 25%에만 적용하는 p-RoPE까지. 긴 컨텍스트에서 메모리를 아끼면서 성능을 유지하려는 설계입니다.
스펙 비교표
| 항목 | Gemma 4 31B (Dense) | Gemma 4 26B-A4B (MoE) |
|---|---|---|
| 총 파라미터 | 30.7B | 25.2B |
| 활성 파라미터 | 30.7B (전체) | 3.8B (토큰당) |
| 레이어 수 | 60 | 30 |
| 어텐션 패턴 | 5 로컬 : 1 글로벌 | 5 로컬 : 1 글로벌 |
| 슬라이딩 윈도우 | 1024 토큰 | 1024 토큰 |
| 컨텍스트 길이 | 256K 토큰 | 256K 토큰 |
| 전문가 구성 | 없음 (Dense FFN) | 128개 + 1 공유 / 8개 활성 |
| 비전 인코더 | ~550M | ~550M |
| 라이선스 | Apache 2.0 | Apache 2.0 |
메모리, 실제로 얼마나 차이 나나?
여기서 MoE의 진가가 드러납니다.
BF16(16비트) 기준 모델 가중치만 로드하면, 31B는 약 61GB, 26B-A4B는 약 50GB예요. "MoE가 활성 파라미터 4B인데 왜 50GB나 되지?" 싶을 수 있는데, 128개 전문가의 가중치가 전부 메모리에 올라가야 하거든요. 활성화되는 건 8개뿐이지만, 어떤 토큰에서 어떤 전문가가 호출될지 미리 알 수 없으니까요.
진짜 차이는 KV 캐시에서 나와요. 256K 전체 컨텍스트를 쓸 때 31B의 KV 캐시는 약 21GB인데, 26B-A4B는 약 5GB — 4분의 1 수준이에요. 31B는 글로벌 어텐션 레이어가 10개에 KV 헤드 4개, 26B-A4B는 글로벌 레이어 5개에 KV 헤드 2개라 이런 차이가 생깁니다.
실제 운용하면 GPU는 뭐가 필요한가?
BF16 무양자화로 256K 컨텍스트를 전부 쓴다고 치면, 31B는 가중치(61GB) + KV 캐시(21GB)로 약 82GB 이상이 필요해요. A100 80GB로도 모자라서 96GB급 GPU가 있어야 합니다.
26B-A4B는 가중치(50GB) + KV 캐시(5GB)로 약 55GB예요. 같은 96GB GPU에서 동시 쿼리를 8~9개까지 처리할 수 있는 여유가 생기죠. 서비스 운영자 입장에서는 처리량 차이가 어마어마합니다.
4비트 양자화를 적용하면 더 극적이에요. 31B는 가중치가 17~20GB로 줄지만 KV 캐시 21GB가 그대로라 총 37~40GB가 필요합니다. 26B-A4B는 가중치 약 17GB + KV 캐시 5GB, 합계 약 22GB — 24GB GPU에서도 돌릴 수 있는 수준이에요.
공통 기능은?
두 모델이 공유하는 기능도 짚어둘게요. 시스템 프롬프트에 <|think|> 토큰을 넣으면 답변 전에 단계별 내부 추론을 수행하는 Thinking 모드가 켜집니다. Function Calling도 네이티브로 지원해서 에이전트 워크플로우를 바로 구성할 수 있어요. Gemma 3에서는 안 됐던 system 역할도 이번에 네이티브 지원으로 추가됐고, 이미지 입력도 가변 해상도·종횡비를 지원해서 왜곡 없이 처리합니다.
Dense와 MoE, 구조가 이렇게까지 다른 모델을 같은 패밀리로 묶어서 출시한 건 사용자한테 선택권을 준다는 의미예요. 품질이냐 효율이냐, 다음 글에서 벤치마크를 뜯어보면 답이 보일 겁니다. 더 자세한 내용은 휴미즈에서 확인하세요.
이 글은 기업 데이터 관리 및 컴플라이언스 전문 기업 휴미즈가 작성했습니다.
0 댓글