Gemma 3를 로컬에서 고를 때는 가벼운 텍스트 작업이면 1B, 이미지 입력이나 128K context가 필요하면 4B 이상을 먼저 검토하고, 12B, 27B는 실제 메모리 여유를 확인한 뒤 시도하는 것이 안전합니다. 큰 모델이 항상 내 장비와 업무에서 더 나은 선택은 아닙니다.
Gemma 3 로컬 실행, 1B와 4B 중 무엇을 고를까? 이미지, Context, VRAM 기준
1B와 4B 사이에서 기능이 갈린다
Gemma 3 제품군은 1B, 4B, 12B, 27B 규모와 32, 16, 8, 4bit 정밀도 선택지를 제공합니다. 1B는 텍스트 전용이며 context가 32K입니다. 4B, 12B, 27B는 이미지와 텍스트를 함께 다루고 context가 128K입니다. 따라서 모델 크기를 비교하기 전에 입력 형식을 먼저 정해야 합니다.
이미지 모델은 SigLIP을 사용하고 이미지를 896×896로 정규화하며, pan-and-scan으로 큰 이미지의 세부 영역을 다룹니다. 문서 화면이나 작은 객체를 읽어야 한다면 “멀티모달 지원” 표시만 보지 말고 실제 이미지의 글자 크기와 배치로 시험해야 합니다. 140개가 넘는 언어로 사전 학습됐고 35개 언어가 즉시 사용 가능한 범위로 소개됐으며 tokenizer vocabulary는 262K입니다. 다국어 수치는 모든 언어에서 같은 품질을 뜻하지 않습니다.
기능 선택은 다음처럼 단순화할 수 있습니다.
- 짧은 요약, 분류, 개인 실험: 1B부터 시작
- 이미지 질문이나 긴 문맥: 4B부터 비교
- 더 높은 품질이 필요하고 GPU 여유가 있음: 12B 검토
- 27B: 정밀도까지 포함해 장비 적합성을 먼저 측정
Function calling도 지원하지만, 모델이 만든 인자를 검증하고 실제 도구 권한을 제한하는 애플리케이션 계층은 별도로 필요합니다.
Ollama에서는 작은 모델부터 메모리를 확인한다
가장 간단한 진입점은 Ollama 다운로드 뒤 ollama run gemma3:1b 또는 ollama run gemma3:4b를 실행하는 것입니다. 원문의 2025년 로컬 관찰에서는 12B가 약 11.6GB VRAM을 사용하고 응답에 10~15초가 걸렸습니다. 이는 한 장비에서 얻은 관찰값이지 보편적인 최소 사양이나 속도 보장이 아닙니다.
실행 순서는 1B 또는 4B로 prompt와 메모리 사용량을 확인하고, 같은 prompt를 더 큰 모델에 넣어 개선 폭을 비교하는 편이 좋습니다. 모델을 올렸는데 응답 지연만 늘고 정확도 차이가 작다면 작은 모델이 실제 서비스에는 더 적합합니다. 27B 명령인 ollama run gemma3:27b를 먼저 실행해 장비 한계를 찾는 방식은 다운로드와 메모리 비용만 키울 수 있습니다.
Transformers 예제는 버전과 모델 ID를 함께 확인한다
원문의 Python 예제는 Transformers 4.50.0 이상을 전제로 하고 gemma-3-4b-it 모델 ID와 로컬 이미지 경로를 사용합니다. 당시 관찰에서는 4B 예제가 약 14GB를 쓰고 약 20초가 걸렸습니다. 모델 ID 접근 권한, 라이브러리 버전, 이미지 파일, device와 dtype이 모두 맞아야 하므로 이 조각을 환경 독립적인 완전 실행법으로 보면 안 됩니다.
공개 모델 모음은 Gemma 3 release collection에서 확인할 수 있습니다. Apple Silicon용으로 원문에 소개된 mlx-vlm 저장소 주소는 Blaizzy/mlx-vlm입니다. 어느 경로를 택하든 같은 질문 세트와 이미지 세트를 고정해야 모델, runtime 차이를 비교할 수 있습니다.
긴 Context와 Benchmark 숫자를 그대로 믿지 않는다
128K context는 긴 입력을 받을 수 있다는 뜻이지, 마지막까지 모든 정보를 같은 정확도로 회수한다는 보장은 아닙니다. 긴 문서를 앞, 중간, 뒤로 나눠 답을 찾게 하고, 근거 문장을 실제로 되짚는지 확인해야 합니다. 이미지도 전체 장면, 표, 작은 글자처럼 난도를 나눠 테스트하는 편이 좋습니다.
Gemma 3의 benchmark와 단일 GPU 구동 주장은 모델, 정밀도, 장비 조건을 함께 읽어야 합니다. 환각, 편향, 모호한 질문의 취약성도 남습니다. 로컬 도입 결론은 모델 이름이 아니라 내 입력에서의 정답률, 최대 메모리, 첫 응답 시간, 지속 처리량 네 값을 기록한 뒤 내려야 합니다.
모델 크기는 기능 조건을 통과한 후보끼리 비교한다
모델 선택을 “가장 큰 것을 올릴 수 있는가”로 시작하면 다운로드와 memory 실험이 길어집니다. 먼저 텍스트만 처리하는지, 이미지가 들어오는지, 실제 입력이 얼마나 긴지 적습니다. 이미지가 필요하면 1B는 후보에서 빠지고, 짧은 텍스트 분류라면 4B 이상의 멀티모달 기능은 사용하지 않는 비용이 될 수 있습니다. 기능 조건을 통과한 두 모델만 같은 입력으로 비교하는 편이 효율적입니다.
| 작업 | 첫 비교 후보 | 반드시 확인할 값 |
|---|---|---|
| 짧은 요약, 분류 | 1B와 4B | 정답률, 첫 응답 시간 |
| 이미지 질의 | 4B와 12B | 작은 글자 정답률, peak memory |
| 긴 문서 질의 | 4B와 12B | 위치별 근거 회수율, token 처리 시간 |
| 품질 우선 생성 | 12B와 27B | 개선 폭, 지속 처리량, 메모리 여유 |
모델을 키운 뒤 좋아졌다는 판단도 작업별 정답으로 내려야 합니다. 긴 답이 더 자세해 보여도 사실 오류가 늘 수 있고, 이미지 설명이 풍부해져도 표의 숫자를 틀릴 수 있습니다. 출력 길이와 문체를 가능한 한 맞춘 뒤 핵심 질문의 정답과 근거를 비교해야 합니다.
로컬 Benchmark는 내 입력과 내 Runtime으로 만든다
테스트 세트는 실제 사용을 닮은 소규모 묶음이면 충분합니다. 텍스트 작업은 명확한 질문, 모호한 질문, 답할 근거가 없는 질문을 나눕니다. 이미지 작업은 큰 객체, 작은 글자, 표, 복잡한 배치를 나눕니다. 긴 문서는 답의 근거를 앞, 중간, 뒤에 배치해 특정 위치만 잘 읽는지 확인합니다.
각 요청에서 첫 token 시간, 완료 시간, peak memory, 결과의 근거 문장, 실패 유형을 기록합니다. 한 번의 실행은 model load와 cache 영향을 크게 받으므로 cold start와 이미 로드된 상태를 구분합니다. context를 늘릴 때 memory와 시간이 어떻게 변하는지도 별도 열로 둡니다. Ollama와 Transformers를 비교한다면 model variant, 정밀도, prompt를 맞추지 않은 속도 숫자는 의미가 없습니다.
큰 Context는 입력 설계를 없애지 않는다
긴 문서를 통째로 넣을 수 있어도 질문과 무관한 부분이 많으면 처리 비용이 늘고 핵심 근거를 놓칠 수 있습니다. 먼저 문서 구조와 질문 범위를 분명히 하고, 답과 함께 근거 위치를 요구해 실제 회수 여부를 검증합니다. 근거가 없을 때 추측하지 않는지도 중요한 실패 조건입니다.
메모리 부족만 실패가 아닙니다. swap이나 CPU offload로 실행은 되지만 응답 시간이 업무 한도를 넘을 수 있고, 여러 요청이 겹칠 때 처리량이 급격히 떨어질 수 있습니다. 선택 결과는 “구동 성공” 대신 허용 시간 안에서 필요한 입력을 처리하고, 근거가 있는 답을 안정적으로 반복하는 가장 작은 모델로 기록하는 편이 재현 가능합니다.
정밀도를 바꾸면 같은 모델로 취급하지 않는다
같은 4B 이름이라도 32, 16, 8, 4bit 설정은 memory와 속도뿐 아니라 출력 품질에 영향을 줄 수 있습니다. 모델 크기 비교와 정밀도 비교를 한 번에 하면 차이의 원인을 알 수 없습니다. 먼저 같은 정밀도에서 1B와 4B처럼 규모를 비교하고, 선택한 규모 안에서 정밀도를 낮춰 허용 가능한 품질 저하인지 확인하는 순서가 명확합니다.
특히 작은 숫자, 고유명사, 표의 값, 이미지 속 글자는 양자화 뒤의 오류를 별도로 모읍니다. 전체 문장이 자연스러워도 이런 항목 하나가 틀리면 실제 작업은 실패할 수 있습니다. 정답률만 보지 말고 어떤 유형의 답이 바뀌었는지 기록하고, 반복 실행에서 결과가 불안정해지는지도 확인합니다.
동시 요청이 들어오면 단일 실행 결과가 달라진다
로컬 대화 한 번이 빠르다고 여러 사용자의 요청을 감당한다는 뜻은 아닙니다. 모델이 차지하는 고정 memory와 요청별 context memory를 구분하고, 두 요청 이상이 겹칠 때 대기 시간과 실패율을 측정합니다. 긴 문서와 이미지 요청이 동시에 들어오는 상황도 실제 사용에 있다면 테스트에 포함합니다.
서비스 후보를 고를 때는 첫 응답의 평균뿐 아니라 가장 느린 구간, memory 부족으로 중단된 비율, 일정 시간 동안 완료한 요청 수를 봅니다. 큰 모델이 한 요청에서는 더 정확해도 queue가 길어지면 사용자는 답을 받지 못할 수 있습니다. 이 경우 작은 모델을 기본으로 쓰고 어려운 입력만 큰 모델로 보내는 정책도 비교할 수 있지만, route 오류와 두 모델의 답변 차이는 새 실패 조건으로 관리해야 합니다.
함께 읽으면 이해가 이어지는 글
- Liquid AI, 스마트폰과 CPU에서 작동하는 로컬 에이전트 모델 LFM2.5-2.6B 공개 — Liquid AI가 스마트폰 및 소비자용 CPU에서 로컬로 구동되는 26억 매개변수 온디바이스 에이전트 모델 LFM2.5-2.6B를 공개했습니다. 2.5GB 미만의 RAM 메모리로 128K 컨텍스트와 네이티브 툴 콜링을 지원하며…
- 긴 대화 RAG에서 관련 문서를 다시 골라야 할까? QRRanker의 4B 해법 — QRRanker가 4B 모델의 query-focused attention head로 후보 문서를 함께 재정렬하고 대화, 서사 메모리를 활용하는 방법과 적용 한계를 정리합니다.
- BitNet b1.58은 GPU 없이도 빠를까? 3값 가중치와 전용 커널의 조건 — 가중치를 -1, 0, 1로 제한하는 BitNet b1.58이 메모리와 행렬 연산을 줄이는 원리, 학습 방식과 실제 가속에 필요한 커널 조건을 정리합니다.
자주 묻는 질문
Gemma 3에서 이미지 입력이 필요하면 1B를 써도 되나요?
1B는 텍스트 전용이므로 이미지 입력이나 128K context가 필요하면 4B 이상을 검토해야 합니다.
12B의 VRAM 관찰값을 최소 사양으로 봐도 되나요?
아닙니다. 정밀도, runtime, context 길이, 장비에 따라 달라지는 한 환경의 관찰값이므로 같은 설정에서 직접 peak memory를 측정해야 합니다.
128K context면 긴 문서를 정확히 다 읽나요?
긴 입력을 받을 수 있다는 뜻일 뿐 모든 위치의 정보를 같은 정확도로 회수한다는 보장은 없습니다. 문서 앞, 중간, 뒤의 근거를 찾는 테스트가 필요합니다.
표지 1 —
←→ 키와 좌우 스와이프를 지원합니다. 읽던 페이지는 이 기기에 저장됩니다.
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.