무료로 내 노트북에서 젬마4 12B 로컬 실행하기 (Ollama·LM Studio)

시작하기 전에

결론부터 말하면, 젬마4 12B는 2026년 6월 3일 추가된 모델이고 라이선스가 Apache 2.0이라 개인·상업 용도로 무료로 깔아 돌릴 수 있다(출처: Google Developers Blog). “Gemma 3 12B”가 아니라, 4월에 나온 Gemma 4 라인업(E2B/E4B/26B/31B)에 6월에 합류한 12B “Unified” 모델이다. 텍스트·이미지·오디오를 한 모델이 네이티브로 처리하는 인코더-프리 멀티모달이고, 컨텍스트는 256K까지 지원한다.

이 가이드는 실행 전담 글이다. 모델의 스펙·벤치마크·한국어 품질 전반은 젬마4 모델 리뷰에서 다루니, “이 모델을 써도 되나?”를 먼저 판단하고 싶다면 그쪽을 보고 오면 된다. 여기서는 “내 노트북에서 어떻게 켜나”만 끝까지 책임진다.

필요한 환경

최소 사양은 한 줄로 요약된다. 다운로드한 양자화 모델 크기보다 가용 메모리가 커야 한다. Q4 기준 모델 본체가 6.7–8GB이고 여기에 KV 캐시·런타임 오버헤드가 붙으니, 실전 권장은 16GB다.

공식 문구도 같은 선을 긋는다. “16GB VRAM 또는 통합메모리를 가진 전용 GPU 노트북에서 로컬 실행 가능”이다(출처: ai.google.dev/gemma/docs/core). 여기서 “또는”이 핵심인데, 이 차이가 다음 섹션의 사양 분기 전체를 가른다.

사전 설치 항목

깔 도구는 둘 중 하나면 된다. 둘 다 깔아 비교해도 좋다.

• Ollama — 터미널 기반. ollama run 한 줄로 다운로드부터 실행까지. 자동화·API 연동에 강하다.
• LM Studio — GUI 앱. 명령어 없이 검색·다운로드·대화. 입문자·오프라인 문서 첨부(RAG)에 강하다.

설치 직후 둘 다 정상 동작하는지는 각 도구 섹션에서 결과 확인 명령으로 검증한다. NVIDIA GPU를 쓴다면 시작 전에 그래픽 드라이버를 최신으로 올려두자. 뒤에서 다루지만, 구형 드라이버는 GPU 미인식(CPU만 100%)의 가장 흔한 원인이다.

젬마4 12B, 내 노트북에서 진짜 돌아갈까?

답은 “내 16GB가 RAM이냐 VRAM이냐”에 달렸다. 같은 16GB라도 맥과 윈도우는 동작 방식이 다르고, 윈도우 안에서도 전용 VRAM 16GB와 “VRAM 8GB + RAM 16GB”는 체감이 천지차이다. 이 섹션 하나만 이해하면 “왜 누구는 잘 돌고 나는 버벅이는가”가 풀린다.

메모리는 얼마나 먹나 — 양자화별 실측

먼저 숫자부터 보자. 공식 메모리 표는 20% 오버헤드를 포함한 로드 기준이다(출처: ai.google.dev/gemma/docs/core). Unsloth의 실측값도 함께 둔다(출처: unsloth.ai/docs/models/gemma-4).

Q4_0 본체가 6.7GB라는 건 모델 가중치만의 크기다. 실제로 돌릴 때는 여기에 KV 캐시(대화 맥락을 담는 메모리)와 런타임 버퍼가 더 붙는다. 컨텍스트를 길게 잡으면 KV 캐시가 본체보다 커질 수도 있는데, 이게 뒤 트러블슈팅 섹션의 핵심 원인이다.

RAM이냐 VRAM이냐 — 세 갈래 분기

이제 가장 중요한 분기다. 같은 “16GB”가 어디에 있느냐로 결과가 갈린다.

• 맥(애플 실리콘) 통합메모리 16GB — CPU와 GPU가 메모리 풀 하나를 공유한다. 16GB면 Q4 12B를 편안하게 돌리고, 8bit(13–14GB)도 빠듯하게 가능하다. 별도 설정 없이 GPU(Metal)가 자동으로 붙는다.
• 윈도우/리눅스 전용 VRAM ≥ 16GB — Q4 본체(6.7–8GB)와 KV 캐시를 GPU 메모리에 모두 올릴 수 있다. NVIDIA RTX 4080/4090, 4060 Ti 16GB 등이 여기 해당한다.
• 저VRAM 윈도우 (예: VRAM 8GB + 시스템 RAM 16GB) — 함정 구간이다. 모델이 VRAM에 다 못 들어가서 일부 레이어가 CPU/시스템 RAM으로 오프로드된다. 동작은 하지만 GPU↔CPU 사이를 데이터가 오가며 속도가 급락한다.

한국어로 쓰면 체감 속도가 절반이라고?

한국 독자라면 반드시 알아야 할 함정이 하나 더 있다. 한국어는 영어 대비 토큰을 약 2.36배(2–3배) 더 소비한다. 즉 같은 t/s(초당 토큰)라도 한국어로 같은 분량을 만들면 영어보다 약 2배의 토큰을 생성해야 하니, 체감 응답 속도는 영어의 절반 수준으로 느껴진다. “영어 벤치에서 30 t/s 나온다더라”를 한국어에 그대로 기대하면 실망한다.

⚠️ 주의: 벤치마크 t/s 수치는 거의 영어 기준이다. 한국어 작업의 체감 속도는 그 절반으로 깎아서 예상하는 편이 현실적이다.

Ollama vs LM Studio, 입문자는 뭘로 시작할까?

둘 다 무료고 둘 다 젬마4 12B를 잘 돌린다. 갈림길은 “터미널이 편한가, GUI가 편한가”와 “무엇에 쓸 것인가”다. 결론부터: 명령어가 낯설면 LM Studio, 자동화·API·스크립트가 목적이면 Ollama.

두 도구 정면 비교

표에서 Ollama를 1열에 둔 건 권위 순서가 아니라 단순 비교 배치다. 실제 선택은 아래 사용 시나리오로 판단하자.

어떤 상황에 뭘 고를까

• 터미널을 거의 안 써봤다 / 일단 대화부터 해보고 싶다 → LM Studio. 검색·다운로드·대화가 전부 클릭이다.
• 셸 스크립트로 자동화하거나 다른 앱에서 API로 부르고 싶다 → Ollama. localhost에 바로 API가 뜬다.
• PDF·메모 같은 내 문서를 붙여 질문하고 싶다(RAG) → LM Studio의 문서 첨부가 손쉽다.
• 맥에서 최대 속도를 뽑고 싶다 → 둘 다 MLX를 지원한다. 더 빠른 MLX 추론 서버 구성이 궁금하면 맥 MLX 로컬 AI 서버 가이드를 참고하자.

⚠️ 주의: 두 도구는 모델 파일을 따로 받는다. Ollama로 받은 모델을 LM Studio가 자동으로 공유하지 않으니, 둘 다 쓰면 디스크에 7–10GB짜리 모델이 중복으로 깔릴 수 있다.

결과 확인

설치가 끝났는지는 버전이 뜨는지로 안다. Ollama는 터미널에서 ollama --version이 버전 문자열을 반환하면 정상이고, LM Studio는 앱을 실행했을 때 좌측에 Discover·Chat 탭이 보이면 정상이다.

Ollama로 젬마4 12B 까는 법

여기서는 Ollama 설치부터 ollama run gemma4:12b로 실제 대화가 뜨는 데까지 끝낸다. 명령어 세 줄이면 끝나지만, 태그가 정확히 무엇을 받는지 알고 가야 나중에 헷갈리지 않는다.

1단계: Ollama 설치

OS별 설치 방법이 다르다. 맥·윈도우는 설치파일을 받아 실행하면 되고, 리눅스·자동화 환경은 명령어 한 줄이 편하다.

리눅스(또는 맥 터미널 설치):

curl -fsSL https://ollama.com/install.sh | sh

윈도우 PowerShell(설치파일 대신 CLI로):

irm https://ollama.com/install.ps1 | iex

맥·윈도우는 ollama.com에서 GUI 설치파일을 받아 실행해도 동일하다. 설치가 끝나면 백그라운드에 Ollama 서비스가 자동으로 뜬다.

2단계: 젬마4 12B 받고 실행

설치 확인 후 모델을 받는다. 이 한 줄이 다운로드와 실행을 동시에 한다.

ollama run gemma4:12b

gemma4:12b 태그가 받는 건 정확히 이렇다. 7.6GB, Q4_K_M 양자화, 11.9B 파라미터, 256K 컨텍스트, text+image 지원 (출처: ollama.com/library/gemma4). 멀티모달 모델이지만 이 태그는 텍스트와 이미지만 노출하고 오디오는 빠져 있으니, 오디오 입력이 필요하면 뒤 멀티모달 항목을 보자.

다운로드가 끝나면 >>> 프롬프트가 뜨고 바로 대화할 수 있다. 종료는 /bye다.

3단계: 샘플링 파라미터 맞추기

품질을 위해 권장 샘플링값을 맞추면 좋다. Google·Unsloth 권장값은 temperature 1.0, top-p 0.95, top-k 64다(출처: unsloth.ai/docs/models/gemma-4). 대화 세션 안에서 바로 바꿀 수 있다.

>>> /set parameter temperature 1.0
>>> /set parameter top_p 0.95
>>> /set parameter top_k 64

더 높은 품질의 커뮤니티 양자화를 원하면 Unsloth의 동적 양자화 태그를 직접 돌릴 수도 있다.

ollama run hf.co/unsloth/gemma-4-12B-it-GGUF:UD-Q4_K_XL

결과 확인

모델이 GPU에 올라갔는지는 ollama ps로 확인한다. 이게 이 가이드에서 가장 자주 쓸 진단 명령이다.

ollama ps

출력의 Processor 컬럼 값을 본다. 100% GPU면 완전히 GPU에서 도는 정상 상태고, 100% CPU면 GPU를 못 잡은 것, 48%/52% CPU/GPU처럼 분할이면 일부가 CPU로 오프로드된 상태다. 분할이나 CPU 100%가 보이면 다음다음 섹션의 트러블슈팅으로 간다.

성공 기준: 한국어로 짧게 질문했을 때 끊김 없이 토큰이 흘러나오고, ollama ps가 100% GPU를 보이면 정상이다.

LM Studio로 명령어 없이 젬마4 실행하려면?

터미널이 부담스럽다면 LM Studio가 가장 쉬운 길이다. 검색·다운로드·대화가 전부 클릭이고, 내 RAM에 맞는 양자화를 앱이 추천까지 해준다. 흐름은 “설치 → Discover에서 검색 → 다운로드 → Chat에서 로드 → 대화” 다섯 단계다.

1단계: 설치와 모델 검색

lmstudio.ai에서 앱을 받아 설치한 뒤 실행한다. 좌측 Discover 탭 화면에서 “Gemma 4”를 검색하면 여러 양자화 버전이 뜬다.

2단계: 내 사양에 맞는 양자화 고르기

목록에서 RAM에 맞는 GGUF를 고른다. 16GB라면 qat-q4_0 계열이 무난하다. 맥(애플 실리콘) 사용자는 GGUF 대신 MLX 포맷 쪽을 고르면 통상 10–20% 빠르다(커뮤니티 측정). LM Studio는 각 버전 옆에 “이 기기에서 돌아갈지” 여부를 표시해주니 그 가이드를 따르면 된다.

3단계: 로드하고 대화

다운로드가 끝나면 Chat 탭 쪽으로 가서 상단 Model Loader로 받은 모델을 로드한다. 로드 게이지가 끝까지 차면 입력창에 바로 한국어로 질문할 수 있다. 런타임(엔진) 관리 화면은 단축키 Ctrl/Cmd+Shift+R로 연다.

LM Studio의 두 가지 강점도 챙기자. 하나는 OpenAI 호환 API 제공이라 다른 앱에서 localhost로 부를 수 있고, 다른 하나는 오프라인 문서 첨부(RAG) 기능이라 PDF·메모를 붙여 그 내용 기반으로 질문할 수 있다.

결과 확인

성공 기준: Chat 탭 상단에 모델명이 “Loaded”로 표시되고, 한국어 질문에 응답이 스트리밍되면 정상이다. 응답이 안 나오거나 앱이 멈추면 양자화를 한 단계 낮춰(예: q4) 다시 로드한다.

맥북(M1·M2·통합메모리)에서 돌리면 뭐가 다를까?

맥 사용자는 윈도우보다 한 수 유리하다. 통합메모리 구조 덕분에 16GB만 있어도 별도 설정 없이 GPU가 붙고, MLX라는 애플 전용 가속 포맷으로 속도를 더 끌어올릴 수 있다. 다만 “맥이 무조건 빠르다”는 아니라서, 한국어 체감 속도와 최신 빌드 요구는 짚고 가야 한다.

통합메모리가 주는 이점

애플 실리콘(M1·M2·M3)은 CPU와 GPU가 메모리 하나를 공유한다. 그래서 16GB 통합메모리로 Q4(7–8GB)는 편안하고, 8bit(13–14GB)도 빠듯하게나마 가능하다. 윈도우에서 “VRAM 8GB라 안 된다”는 상황이 맥에서는 통합메모리 16GB 안에서 자연스럽게 해결된다. Metal 가속은 기본으로 켜져 있어 따로 만질 게 없다.

MLX로 더 빠르게

MLX는 애플이 만든 머신러닝 프레임워크로, 같은 모델이라도 GGUF보다 통상 10–20% 빠르다(커뮤니티 측정). Ollama에서는 전용 태그로 받는다.

ollama run gemma4:12b-mlx

이 MLX 태그는 약 10GB다. LM Studio라면 Discover에서 MLX 포맷 버전을 고르면 된다. ⚠️ 주의: MLX 가속을 제대로 받으려면 최신 Ollama 빌드 쪽이 필요하다. 구버전에서는 MLX 태그가 동작하지 않거나 가속이 안 붙을 수 있으니, 안 되면 Ollama부터 업데이트하자.

MLX 기반으로 추론 서버를 더 빠르게 구성하는 방법은 맥 MLX 로컬 AI 서버 가이드에서 따로 다룬다.

결과 확인

성공 기준: ollama run gemma4:12b-mlx로 대화가 뜨고, 활성 상태 모니터(액티비티 모니터)의 GPU 사용량이 추론 중 올라가면 Metal 가속이 정상이다. 같은 프롬프트로 GGUF 태그와 비교해 토큰 속도가 더 빠르면 MLX 효과를 본 것이다.

⚠️ 주의: 맥에서도 한국어 체감 속도는 토큰 2.36배 규칙을 그대로 받는다. MLX로 영어 기준 속도가 올라도, 한국어 긴 답변은 여전히 영어의 절반쯤으로 느껴진다.

GPU를 안 쓰고 CPU만 100%거나 너무 느릴 때 어떻게 고칠까?

여기가 2차 유입의 핵심이자, 가장 많이 막히는 지점이다. “분명 8GB짜리 Q4를 받았는데 16GB GPU에서 한없이 느리다”거나 “GPU는 100%인데 답이 안 나온다”는 증상의 정체는 대부분 KV 캐시와 컨텍스트 길이 문제다. 원인을 알면 해결은 환경변수 한두 개로 끝난다.

증상부터 정확히 진단하기

가장 흔한 함정 시나리오는 이렇다. 모델 본체는 Q4로 8GB 남짓인데, KV 캐시가 기본 f16(16비트)인 데다 긴 컨텍스트까지 겹치면 16GB GPU에서 22–23GB를 요구하게 된다(출처: github.com/ollama/ollama/issues/9730). 그러면 초과분이 사실상 오프로드되어 “GPU 100%인데 한없이 느린” 상태가 된다. 이때 KV를 q8_0로 낮추면 이번엔 부하가 CPU로 옮겨가 “CPU 100%“가 되기도 한다. 둘 다 같은 뿌리의 증상이다.

먼저 ollama ps로 Processor 컬럼을 확인하고, 더 깊은 로그가 필요하면 디버그 모드로 켠다.

OLLAMA_DEBUG=1 ollama serve

해결책 1: 컨텍스트부터 줄여라(가장 직접적)

256K 컨텍스트가 KV 캐시 폭증의 주범이다. 일상 대화에 256K가 필요한 경우는 거의 없으니, 컨텍스트를 4K–8K로 낮추는 게 가장 효과가 크고 직접적이다. 기본값은 4096인데, 도구가 더 크게 잡아두는 경우가 있다.

세션 안에서 바로 줄이기:

>>> /set parameter num_ctx 4096

서버 전체 기본값으로 고정하기:

OLLAMA_CONTEXT_LENGTH=8192 ollama serve

해결책 2: Flash Attention과 KV 캐시 양자화

컨텍스트를 줄여도 빠듯하면, KV 캐시 자체를 가볍게 만든다. Flash Attention을 켜면 KV 캐시의 VRAM 사용을 30–50% 줄이면서 품질 손실이 0이다(출처: docs.ollama.com/faq). 여기에 KV 캐시 타입을 q8_0(또는 q4_0)로 낮추면 추가로 줄어든다.

OLLAMA_FLASH_ATTENTION=1 OLLAMA_KV_CACHE_TYPE=q8_0 ollama serve

세 가지(컨텍스트 축소 + Flash Attention + KV 양자화)를 함께 적용하면 16GB에서도 안정적으로 GPU에 다 올라간다.

해결책 3: GPU 자체를 못 잡을 때

ollama ps가 계속 100% CPU라면 GPU 인식 문제다. 점검 순서는 이렇다.

• compute capability 확인 — NVIDIA는 compute capability 5.0 이상이어야 한다. 너무 오래된 GPU는 지원되지 않는다.
• 드라이버·Ollama 최신화 — 최신 GPU(예: RTX 5090)에서 윈도우가 “0 B VRAM”으로 오인식하거나, 드라이버 업데이트 직후 인식이 깨지는 사례가 보고됐다. 드라이버와 Ollama를 모두 최신으로 올리는 게 첫 처방이다.
• 로그 확인 — OLLAMA_DEBUG=1 ollama serve로 GPU 탐지 로그를 본다.

해결책 4: 저VRAM이라 어쩔 수 없이 분할일 때

VRAM이 작아서 전체를 못 올린다면, GPU에 올릴 레이어 수를 직접 제한해 분할을 통제한다. 전체 레이어의 70–80% 정도만 GPU에 얹는 식이다. Ollama에서는 num_gpu 파라미터로 조절한다.

>>> /set parameter num_gpu 28

(레이어 총수는 모델·빌드마다 다르니, 전체의 70–80%에 해당하는 값으로 조정한다.)

결과 확인

성공 기준: 위 설정 적용 후 ollama ps가 100% GPU를 보이고, 같은 프롬프트의 응답 속도가 체감으로 빨라지면 해결이다. 여전히 분할이면 num_ctx를 더 낮추거나 양자화를 한 단계 더 내린다.

양자화(Q4·Q8)와 256K 컨텍스트, 16GB에 맞추려면?

앞에서 명령어로 해결했다면, 이번엔 “왜 그렇게 하는가”를 이해할 차례다. 핵심 변수는 양자화 수준과 컨텍스트 길이 둘이고, 16GB라는 예산 안에서 이 둘을 어떻게 배분하느냐가 품질과 속도를 동시에 결정한다.

양자화 — 어디까지 낮춰도 되나

양자화는 모델 가중치의 정밀도를 낮춰 메모리를 줄이는 기법이다. 낮출수록 가벼워지지만 품질이 떨어지는 트레이드오프가 있다. 16GB 환경의 실전 선택지는 이렇다.

Q4_K_M이 16GB 실전 기본인 이유는 품질을 약 97% 유지하면서 메모리는 본체 6.7–8GB로 끊기 때문이다(출처: unsloth.ai/docs/models/gemma-4). Q8은 거의 원본 품질이지만 13.4GB라 16GB VRAM에서는 KV 캐시 여유가 거의 없어 빠듯하다. QAT 포맷(qat-q4_0)은 메모리를 약 3배 아끼면서 품질을 거의 유지하니, 메모리가 민감한 환경에서 특히 유리하다.

256K 컨텍스트는 16GB에서 풀로 못 켠다

젬마4는 256K 컨텍스트를 지원하지만, 16GB에서 256K를 풀로 켜는 건 사실상 불가능하다. 컨텍스트가 길어질수록 KV 캐시가 선형으로 커지는데, 256K에서는 KV 캐시가 모델 본체보다 커질 수 있기 때문이다. 그래서 16GB에서 긴 컨텍스트를 쓰려면 두 가지가 필수다.

• num_ctx를 현실적으로 낮추기 — 일상은 4K–8K, 문서 한 편 통째로 넣어야 할 때만 16K–32K로 올린다.
• KV 캐시 양자화 — 앞서 본 OLLAMA_KV_CACHE_TYPE=q8_0로 KV 캐시 메모리를 추가로 줄인다.

멀티모달 입력의 제약

젬마4 본체는 text·image·audio·video를 네이티브로 다루지만, Ollama의 gemma4:12b 태그는 text와 image만 노출한다. 오디오 입력은 llama.cpp나 LM Studio 등 별도 경로가 필요하다. 이미지·오디오를 넣을 때는 텍스트 앞에 배치하고, 오디오는 최대 30초까지만 지원한다.

⚠️ 주의: “젬마4가 오디오를 듣는다”는 모델 차원의 사실이지만, 그게 곧 “Ollama 기본 태그로 오디오가 된다”는 뜻은 아니다. 도구별로 노출 범위가 다르다.

16GB로 부족하면 대안은?

16GB로 Q4 12B는 되지만, 더 가볍게 가고 싶거나 반대로 더 무거운 작업이 필요할 수 있다. 젬마4 라인업 안의 경량 모델, 경쟁 오픈웨이트, 그리고 클라우드/저가 API까지 선택지가 넓다. 시드 모델(젬마4)만 답은 아니다.

더 가벼운 젬마4 — E4B·E2B

16GB도 빠듯하거나 구형 노트북이라면 젬마4의 경량 변형으로 내려가자.

E4B는 4bit로 4.5–6GB라 VRAM 8GB급에서도 돌고, E2B는 2.9–4GB(텍스트만 모바일에서 1GB 미만)로 더 가볍다(출처: unsloth.ai/docs/models/gemma-4).

경쟁 오픈웨이트와 한국어 특화

젬마4가 유일한 선택지는 아니다. 비슷한 체급의 대안과 한국어 강점 모델도 함께 저울질하자.

• Qwen 14B 계열 — 동급 경쟁 모델. VRAM 24GB 이상이거나 코딩 에이전트가 목적이라면 Qwen 3.6 리뷰를 참고하자.
• Gemma 3 12B QAT — int4로 6.6GB. 전 세대지만 16GB에서 안정적인 대안이다.
• 한국어 특화 로컬 모델 — 젬마4의 한국어가 아쉽다면 EXAONE 4.5 한국어 로컬 LLM이 한국어 작업에서 더 나을 수 있다.

⚠️ 주의: 젬마4의 한국어 성능은 상업적 로컬 모델 중 우수한 편이지만, 여전히 클라우드 서비스보다는 떨어질 수 있다는 점은 균형 있게 봐야 한다. 한국어 정확도가 중요한 업무라면 클라우드와 병행하는 게 현실적이다.

더 무거운 작업은 클라우드·저가 API

16GB로 무리인 대형 작업(긴 문서 분석, 대형 모델 품질)은 클라우드로 넘기는 게 합리적이다. Google은 gemma4:31b-cloud 같은 클라우드 실행과 Vertex AI를 제공한다. 16GB로 감당이 안 되는 대형 오픈웨이트 작업이라면 저가 오픈웨이트 API도 선택지다. 예컨대 Kimi K2.6 심층 분석이나 GLM 5.1 리뷰에서 다루는 대형 모델은 로컬 16GB로는 무리이니, 저가 API로 접근하는 편이 낫다.

결론: 여기까지 완성한 것