목차
- Gemma 4 12B 모델 스펙과 로컬 실행 방법 기본 요건
- 메모리 요구사항과 양자화 옵션 비교
- LiteRT-LM으로 Gemma 4 12B 로컬 서버 구동하기
- Gemma 4 12B 지원 로컬 프레임워크 비교
- Gemma 4 12B 멀티모달 아키텍처의 로컬 실행 특성
- Gemma 4 12B 로컬 실행 시 알아둘 제약사항
- Gemma 4 릴리스 타임라인과 모델 선택
- Gemma 4 12B 로컬 실행 이후의 확장 방향
litert-lm import --from-huggingface-repo=litert-community/gemma-4-12B-it-litert-lm gemma-4-12B-it.litertlm gemma4-12b
litert-lm serve이 두 줄이면 Gemma 4 12B가 로컬에서 OpenAI 호환 API 서버로 동작한다. Gemma 4 12B 로컬 실행 방법을 찾는 개발자라면, 클라우드 API 비용 없이 256K 컨텍스트 윈도우를 갖춘 멀티모달 모델을 자기 노트북에서 실행할 수 있다. 2026년 6월 3일 공식 릴리스된 이 모델은 텍스트·이미지·오디오 입력을 단일 아키텍처에서 처리하면서도, Q4_0 양자화 기준 6.7GB 메모리만 요구하는 것이 특징이다.
이 글에서는 모델 스펙 확인부터 양자화 옵션 선택, LiteRT-LM 서버 구동, 프레임워크별 차이점까지 로컬 실행에 필요한 전 과정을 정리한다.
Gemma 4 12B 모델 스펙과 로컬 실행 방법 기본 요건
Gemma 4 12B의 정확한 파라미터 수는 11.95B이다. "12B"는 반올림 표기이므로 메모리 계산 시 11.95B 기준으로 잡는 것이 정확하다. 모델 아키텍처의 핵심 수치는 다음과 같다.
| 항목 | 값 |
|---|---|
| 파라미터 수 | 11.95B |
| 레이어 수 | 48 |
| 슬라이딩 윈도우 어텐션 | 1024 토큰 |
| 어휘 크기 | 262K |
| 컨텍스트 윈도우 | 256K |
| 라이선스 | Apache 2.0 |
슬라이딩 윈도우 어텐션 크기가 1024 토큰이라는 점은 로컬 실행 시 메모리 효율에 직접 영향을 주는 설계다. 전체 256K 컨텍스트를 풀 어텐션으로 처리하면 메모리가 기하급수적으로 증가하지만, 1024 토큰 윈도우로 제한함으로써 로컬 환경에서도 긴 문서 처리가 가능해지는 셈이다.
슬라이딩 윈도우 어텐션(SWA)은 전통적인 풀 셀프 어텐션과 달리 각 토큰이 주변 1024개 토큰만 참조하는 방식이다. 모든 48개 레이어가 SWA만 사용하는 것은 아니며, 일부 레이어에서는 글로벌 어텐션을 함께 사용해 장거리 의존성을 포착한다. 이 혼합 방식 덕분에 256K 전체 컨텍스트를 처리하면서도 KV 캐시 메모리 증가를 선형 수준으로 제어하는 것이 가능하다.
Gemma 4 모델 카드 상세 스펙에서 전체 벤치마크 결과를 확인할 수 있다. 주요 벤치마크 성능은 MMLU Pro 77.2%, AIME 2026 77.5%, LiveCodeBench v6 72.0%, GPQA Diamond 78.8%로, 12B 규모 모델 중 상위권에 해당한다.
MMLU Pro 77.2%는 57개 학문 분야의 지식 수준을 측정하는 지표이고, LiveCodeBench v6 72.0%는 경쟁 프로그래밍 문제 풀이 능력을 평가한다. GPQA Diamond 78.8%는 박사급 과학 질문에 대한 정확도다. 이 수치들을 조합해서 읽으면, 코딩·수학·과학 세 영역에서 모두 70% 이상을 기록한다는 것이다. 로컬에서 실행 가능한 범용 어시스턴트로 활용하기에 충분한 성능 지표다.
Gemma 4 12B는 Apache 2.0으로 배포된다. 상업적 사용, 수정, 재배포가 모두 허용되므로 사내 서비스에 통합하거나 파인튜닝 후 배포하는 데 라이선스 제약이 없다.
메모리 요구사항과 양자화 옵션 비교
Gemma 4 12B 로컬 실행 방법을 결정할 때 가장 먼저 확인해야 할 것은 가용 메모리다. 정밀도 수준에 따라 필요한 메모리가 4배까지 차이 나기도 한다.
| 정밀도 | 메모리 요구량 | 대상 환경 |
|---|---|---|
| BF16 (풀 정밀도) | 26.7GB | 32GB 이상 GPU / 통합 메모리 |
| SFP8 | 13.4GB | 16GB VRAM GPU |
| Q4_0 (4비트 양자화) | 6.7GB | 8GB 이상 일반 노트북 |
BF16은 풀 정밀도로 모델 품질 손실이 없지만 26.7GB를 요구한다. 대부분의 소비자용 GPU에서는 현실적이지 않은 수치이다. 반면 Q4_0 양자화는 6.7GB로 줄어들어 8GB RAM 노트북에서도 이론적으로 구동 가능하다. 다만 OS와 다른 프로세스가 차지하는 메모리를 고려하면, 안정적 실행을 위해서는 16GB RAM 이상을 권장하는 편이다.
양자화 포맷 간 선택도 미리 정해두어야 한다. GGUF는 llama.cpp 계열 도구(LM Studio, Jan, Ollama 등)에서 사용하고, Compressed Tensors는 vLLM·SGLang 전용 포맷이다. 두 포맷 간의 직접 변환은 지원하지 않으므로, 사용할 프레임워크를 먼저 결정한 뒤 그에 맞는 포맷을 다운로드해야 한다. 나중에 프레임워크를 전환하려면 모델을 다시 다운로드해야 하는 번거로움이 생긴다.
공식 QAT 양자화 모델 포맷
Google은 Gemma 4 12B에 대해 공식 QAT(Quantization-Aware Training) 양자화 모델을 두 가지 포맷으로 제공한다.
첫 번째는 GGUF 포맷(-qat-q4_0-gguf)이다. llama.cpp와 LM Studio에서 사용하는 표준 포맷으로, 로컬 실행 도구 생태계에서 가장 범용적으로 호환된다.
두 번째는 Compressed Tensors 포맷(-qat-w4a16-ct)으로, vLLM과 SGLang 같은 서빙 프레임워크에 최적화되어 있다. 프로덕션 추론 서버를 구축한다면 이 포맷이 적합하다.
QAT는 학습 단계에서 양자화를 반영하여 모델을 훈련한 것이다. 사후 양자화(PTQ)보다 동일 비트 수에서 품질 손실이 적다. Gemma 4 12B의 공식 Q4_0 모델이 QAT 기반이므로, 커뮤니티 PTQ 양자화보다 품질 면에서 유리할 수 있다.
LiteRT-LM으로 Gemma 4 12B 로컬 서버 구동하기
Google AI Edge 팀이 제공하는 LiteRT-LM CLI는 Gemma 4 12B를 로컬 OpenAI 호환 API 서버로 실행하는 가장 간단한 경로다. 16GB RAM의 일반 노트북에서 구동 가능하다고 공식 문서에 명시되어 있다.
모델 가져오기
Hugging Face에서 모델을 로컬로 가져오는 명령은 다음과 같다.
litert-lm import --from-huggingface-repo=litert-community/gemma-4-12B-it-litert-lm gemma-4-12B-it.litertlm gemma4-12b--from-huggingface-repo 플래그로 Hugging Face 리포지토리를 지정하고, 마지막 인자 gemma4-12b는 로컬에서 사용할 모델 별칭이다. 다운로드 크기는 양자화 수준에 따라 다르며, Q4_0 기준으로 대략 6~7GB 수준이 된다.
서버 시작
litert-lm serve이 한 줄로 localhost:9379에서 API 서버가 시작된다. 별도의 포트 설정이나 구성 파일 없이 기본값으로 동작하는 방식이다.
API 호출 테스트
서버가 구동되면 표준 OpenAI API 형식으로 요청을 보낼 수 있다.
curl http://localhost:9379/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{"model": "gemma4-12b,gpu", "messages": [{"role": "user", "content": "Hello!"}]}'"model": "gemma4-12b,gpu" 부분에서 ,gpu는 GPU 가속을 사용하겠다는 의미다. OpenAI SDK를 사용하는 기존 코드가 있다면 base URL만 http://localhost:9379/v1로 변경하면 그대로 호환되는 것이 장점이다. Python에서는 다음처럼 연결한다.
from openai import OpenAI
client = OpenAI(
base_url="http://localhost:9379/v1",
api_key="local",
)
response = client.chat.completions.create(
model="gemma4-12b,gpu",
messages=[
{"role": "user", "content": "Python async/await 개념을 설명해줘"}
],
max_tokens=512,
)
print(response.choices[0].message.content)api_key 값은 로컬 서버가 검증하지 않으므로 임의 문자열을 넣어도 무방하다. 기존 OpenAI SDK 코드에서 OpenAI() 생성자의 base_url 파라미터만 교체하면 되므로, 프로토타이핑 단계에서 API 공급자를 전환하는 비용이 거의 없다.
LiteRT-LM serve는 stateless prefix caching을 내장하고 있다. 동일한 시스템 프롬프트로 반복 요청을 보내는 경우, 프리픽스 부분의 연산을 캐싱하여 응답 속도가 개선된다. 별도 설정 없이 자동 적용되는 기능이다.
Gemma 4 12B 지원 로컬 프레임워크 비교
LiteRT-LM 외에도 Gemma 4 12B는 다양한 로컬 실행 프레임워크를 지원한다. Gemma 4 12B 개발자 가이드에 명시된 공식 지원 프레임워크는 6종이다.
| 프레임워크 | 주요 용도 | 양자화 포맷 |
|---|---|---|
| Hugging Face Transformers | 연구·프로토타이핑 | 모든 포맷 |
| llama.cpp | CLI 기반 경량 추론 | GGUF |
| MLX | Apple Silicon 최적화 | MLX 전용 |
| SGLang | 고성능 서빙 | Compressed Tensors |
| vLLM | 프로덕션 추론 서버 | Compressed Tensors |
| Unsloth | 파인튜닝 특화 | 자체 포맷 |
프레임워크 선택 기준
프레임워크 선택은 목적에 따라 달라진다. 빠른 프로토타이핑이 목적이라면 Hugging Face Transformers가 가장 접근성이 높다. 모델 로딩부터 추론까지 Python 코드 몇 줄로 완료되기 때문이다.
프로덕션 서빙이 목적이라면 vLLM이나 SGLang이 적합하다. 두 프레임워크 모두 Compressed Tensors 포맷(-qat-w4a16-ct)을 사용하며, 배치 추론과 동시 요청 처리에 최적화되어 있다. 반면 개인 노트북에서 가볍게 돌리는 것이 목적이면 llama.cpp + GGUF 포맷 조합이 메모리 효율 면에서 가장 유리한 경우가 많다.
Apple Silicon Mac 사용자라면 MLX를 고려할 수 있지만, 공식 문서에 MLX 프레임워크 실행 방법이 상세히 다뤄지지 않은 상태다. 커뮤니티 가이드를 참조해야 할 수 있다.
각 프레임워크가 Gemma 4 12B를 지원하려면 특정 버전 이상이 필요한 경우가 많다. 새 모델이 출시된 직후에는 프레임워크를 최신 버전으로 업데이트해야 로딩 오류가 없는 경우가 흔하다. 설치 전 각 프레임워크의 공식 변경 이력(changelog)에서 Gemma 4 관련 항목을 확인하는 것이 중요하다. 버전 불일치는 로컬 실행 초기에 가장 많이 마주치는 장애물 중 하나다.
Ollama를 통한 Gemma 4 12B 설치·실행 커맨드(`ollama pull/run gemma4:12b` 등)는 Google 공식 문서에 포함되어 있지 않다. Ollama 자체 사이트에서만 가이드가 제공된다. 마찬가지로 llama.cpp 빌드 및 GGUF 모델 로딩의 단계별 가이드도 공식 문서에 부재하므로, 각 도구의 자체 문서를 참조해야 하는 상황이다.
Gemma 4 12B가 다른 12B급 모델과 구분되는 핵심은 encoder-free 통합 멀티모달 아키텍처에 있다. 텍스트·이미지·오디오 입력을 별도 인코더 없이 단일 LLM 백본에서 직접 처리한다.
flowchart LR
A[텍스트 토큰] --> D[LLM 백본\n48레이어]
B[이미지\n48×48px 패치] --> E[비전 임베더\n35M params] --> D
C[오디오\n16kHz / 40ms] --> F[웨이브 프로젝터] --> D
D --> G[출력 토큰]비전 임베더와 웨이브 프로젝터가 각각 이미지·오디오를 LLM 백본이 처리할 수 있는 토큰 공간으로 변환한다. 별도의 CLIP이나 SigLIP 같은 외부 비전 인코더 모델이 없으므로, 로컬 실행 시 추가 모델 파일을 따로 받을 필요가 없다.
비전 처리 방식
비전 임베더는 35M 파라미터 규모로, 이미지를 48×48 픽셀 패치 단위로 분할한 뒤 LLM 백본에 직접 투영(projection)한다. 별도의 CLIP이나 SigLIP 같은 외부 비전 인코더를 사용하지 않기 때문에, 로컬 실행 시 추가 모델을 로딩할 필요가 없다. 이 점이 메모리 절약에 기여하는 구조적 이점이 된다.
오디오 처리 방식
오디오 입력은 16kHz 샘플링, 40ms 프레임 단위의 웨이브 프로젝션으로 처리된다. 음성 데이터를 별도 ASR(Automatic Speech Recognition) 파이프라인 없이 모델에 직접 입력할 수 있는 구조인 것이다. LiteRT-LM과 함께 제공되는 Eloquent 음성 받아쓰기 앱이 이 기능을 활용한 사례에 해당한다.
encoder-free 설계의 실질적 의미는 배포 복잡도 감소다. 전통적인 멀티모달 모델은 비전 인코더 + 언어 모델을 각각 로딩해야 하므로 메모리 오버헤드와 의존성이 늘어난다. Gemma 4 12B는 단일 모델 파일 하나만 로딩하면 텍스트·이미지·오디오를 모두 처리 가능하므로, 로컬 환경에서의 셋업이 단순해지는 편이다.
단, encoder-free 접근의 트레이드오프도 있다. 전용 비전 인코더 없이 범용 LLM 백본이 이미지를 처리하므로, 순수 이미지 이해 전담 작업에서는 비전 특화 모델보다 성능이 낮을 수 있다. Gemma 4 12B의 멀티모달 기능은 텍스트 위주 작업에서 이미지·오디오를 보조적으로 활용하는 시나리오에 적합하며, 이미지 분석만을 전담하는 전문 파이프라인을 완전히 대체하기는 어렵다.
Gemma 4 12B 로컬 실행 시 알아둘 제약사항
공식 문서에 명시되지 않은 영역과 실행 환경별 제약을 정리한다. Gemma 4 12B 로컬 실행 방법을 검토할 때 이 부분을 미리 파악해두면 불필요한 시행착오를 줄일 수 있다.
Windows 환경 지원
Windows 환경 전용 로컬 실행 가이드는 공식 문서에 존재하지 않는다. 공식 자료가 macOS와 Linux 중심으로 작성되어 있으므로, Windows에서 실행하려면 WSL2를 통한 Linux 환경 구성이 현실적인 우회 방법이 될 수 있다. 다만 이 경로 역시 공식적으로 검증된 가이드는 아니다.
WSL2에서 Ubuntu 22.04 배포판을 사용하는 것이 현재로서 가장 일반적인 접근이다. WSL2는 NVIDIA GPU 패스스루(CUDA via WSLg)를 지원하므로, NVIDIA GPU가 있는 Windows 노트북이라면 WSL2 내부에서도 GPU 가속 추론이 가능하다. 다만 WSL2와 Windows 호스트 간의 메모리 공유 방식 때문에 실제 가용 메모리는 물리 RAM보다 적을 수 있으므로, WSL2 메모리 상한 설정(.wslconfig의 memory 항목)을 확인하는 것이 중요하다.
한국어 공식 문서 부재
모든 공식 자료가 영문으로만 제공된다. Gemma 4 12B의 모델 카드, 개발자 가이드, 릴리스 노트 등 어떤 문서도 한국어 버전이 없는 상태다. 영문 문서 독해가 어렵다면 번역 도구를 활용하되, 기술 용어의 오역에 주의해야 한다.
Apple Silicon MLX 실행
MLX는 공식 지원 프레임워크 목록에 포함되어 있으나, Apple Silicon에서의 구체적 실행 방법이 공식 문서에 상세히 다뤄지지 않은 상태이다. Apple Silicon의 유니파이드 메모리 구조는 16GB 모델에서도 GPU VRAM 제약 없이 실행 가능하다는 이론적 장점이 있지만, 실제 성능과 호환성은 커뮤니티 자료에 의존해야 하는 상황이다.
메모리 관리 실무 팁
16GB VRAM 또는 유니파이드 메모리가 있는 GPU 노트북에서 로컬 실행이 가능하다고 공식 문서에 명시되어 있다. 그러나 16GB는 SFP8(13.4GB) 기준으로도 여유가 3GB 이하다. 다른 애플리케이션을 함께 실행하면 OOM(Out of Memory)이 발생할 수 있으므로, Q4_0(6.7GB) 양자화를 사용하거나 불필요한 프로세스를 종료한 상태에서 실행하는 것이 안정적이다.
모델 로딩 전에 브라우저 탭 정리, Docker 컨테이너 중지, IDE의 메모리 사용량 확인 등을 수행하면 안정성이 높아진다. 특히 Electron 기반 앱(VS Code, Slack 등)은 개별적으로 1~2GB를 차지하는 경우가 있다.
Gemma 4 12B Unified는 2026년 6월 3일에 공식 릴리스되었다. 이전 Gemma 4 시리즈인 E2B, E4B, 31B, 26B A4B는 2026년 3월 31일에 선행 릴리스된 바 있다. Gemma 공식 릴리스 노트에서 전체 릴리스 이력을 확인할 수 있다.
Gemma 4 시리즈 전체의 변형 모델을 로컬 실행 관점에서 비교하면 다음과 같다.
| 모델명 | 릴리스 | 규모 특성 | 로컬 실행 현실성 |
|---|---|---|---|
| Gemma 4 E2B | 2026.03.31 | 초경량, 온디바이스 최적화 | 스마트폰·엣지 디바이스 |
| Gemma 4 E4B | 2026.03.31 | 경량, 온디바이스 최적화 | 저사양 노트북·엣지 |
| Gemma 4 12B Unified | 2026.06.03 | 멀티모달, 균형 설계 | 노트북 16GB 이상 |
| Gemma 4 26B A4B | 2026.03.31 | MoE 구조, 효율 추론 | 고성능 GPU 권장 |
| Gemma 4 31B | 2026.03.31 | 최대 성능 | 서버급 메모리 필요 |
E2B와 E4B는 모바일·온디바이스 시나리오를 위한 경량 모델이고, 26B A4B는 Mixture of Experts(MoE) 구조로 활성 파라미터 대비 추론 효율이 높은 편이다. 31B는 성능이 가장 높지만 일반 노트북에서의 로컬 실행은 현실적으로 어렵다.
12B를 선택하는 판단 기준은 명확하다. 31B는 로컬 실행에 필요한 메모리가 훨씬 크고, E2B나 E4B는 규모가 작아 복잡한 작업에서 성능 한계가 있다. 12B는 로컬 실행 가능성과 모델 성능 사이의 균형점에 해당하며, 특히 Q4_0 양자화 시 6.7GB라는 메모리 요구량은 대부분의 개발 노트북에서 감당 가능한 수준이다.
256K 컨텍스트 윈도우 지원도 로컬 활용 시 중요한 요소다. 긴 코드베이스를 통째로 넣고 분석을 요청하거나, 대량의 문서를 한 번에 처리하는 작업이 로컬에서 가능해지기 때문이다. 다만 256K 전체를 활용하려면 그만큼 KV 캐시 메모리가 추가로 필요하므로, 실제 사용 가능한 컨텍스트 길이는 가용 메모리에 의존하게 된다.
Gemma 4 12B 로컬 실행 이후의 확장 방향
Gemma 4 12B를 로컬에서 성공적으로 구동했다면, 다음 단계로 고려할 영역이 몇 가지 있다. 먼저 Unsloth을 활용한 파인튜닝이다. Apache 2.0 라이선스이므로 도메인 특화 데이터로 모델을 추가 학습시킨 뒤 사내 서비스에 배포하는 것이 라이선스상 가능하다.
프로덕션 서빙으로 전환한다면 vLLM이나 SGLang + Compressed Tensors 포맷 조합을 검토할 필요가 있다. 로컬 테스트 단계에서는 LiteRT-LM의 단순함이 유리하지만, 동시 요청 처리와 배치 추론이 필요한 환경에서는 전용 서빙 프레임워크가 적합하다.
멀티모달 기능의 활용도 확장 포인트 중 하나다. encoder-free 아키텍처 덕분에 이미지 분석과 오디오 처리를 별도 파이프라인 없이 단일 API 호출로 처리할 수 있으므로, 문서 OCR, 음성 명령 처리, 이미지 기반 코드 리뷰 같은 워크플로에 통합하는 방향을 고려해볼 만하다. Gemma 4 12B 양자화 Q4 모델로 로컬 프로토타이핑을 먼저 진행하고, 검증이 끝나면 클라우드 서빙으로 스케일업하는 것이 Gemma 4 12B 로컬 실행 방법의 가장 실용적인 활용 경로다. 로컬 실행 기반이 잡히면 RAG 파이프라인 구성이나 MCP 서버 연동을 통한 에이전틱 워크플로 확장도 자연스럽게 이어지는 다음 단계가 된다.