노트북에서 AI 모델을 직접 돌리는 게 어디까지 되는지 궁금했습니다. 그래서 Gemma 4를 받아 크기별로 재봤어요.

결과보다 먼저 걸린 게 하나 있었습니다. 같은 질문에 같은 답을 받는데 12배 느린 설정으로 돌리고 있었거든요. 기본값이 그렇게 돼 있습니다.

노트북 안에서 모델이 도는 개념 컷 노트북 안에서 모델이 도는 개념 컷 — 출처: 공개 자료 기반 자가 생성

Gemma 4의 다섯 가지 크기

Google 로고 Google 로고 — 출처: Google

Google이 4월에 공개한 오픈웨이트 모델입니다. 가중치를 내려받아 내 기기에서 돌릴 수 있고, 라이선스가 Apache 2.0이라 상업적으로도 쓸 수 있어요. Gemma 계열에서는 처음입니다.

크기 파라미터 컨텍스트
E2B 2.3B 유효 128K
E4B 4.5B 유효 128K
12B 11.95B 256K
26B A4B 25.2B 중 3.8B 활성 256K
31B 30.7B 256K

E 계열은 임베딩을 뺀 유효 파라미터로 표기됩니다. 26B는 MoE(전문가 혼합) 구조라 토큰마다 3.8B만 활성화되고요.

이번에 잰 건 아래 세 크기입니다. 26B와 31B는 측정 시간이 예상보다 길어져 이번 회차에서 뺐습니다.

설치와 모델 내려받기

설치부터 모델 다섯 개 내려받기까지 설치부터 모델 다섯 개 내려받기까지 — 출처: 직접 실행

Homebrew로 Ollama를 깔고 모델을 받으면 끝입니다. 다섯 크기를 전부 받는 데 10분쯤 걸렸어요.

디스크가 만만치 않습니다. 다섯 개 합쳐 58GB를 씁니다. 필요한 크기만 받는 게 낫고, 다 쓴 모델은 지우면 바로 회수됩니다.

크기를 고르는 기준

태그를 붙이지 않고 ollama run gemma4 로 실행하면 기본 태그가 받아집니다. 크기를 지정하려면 gemma4:e2b 처럼 뒤에 붙여요.

내려받은 용량과 실제 메모리 사용량은 다릅니다. 파일은 E4B가 9.6GB, 12B가 7.6GB로 E4B 쪽이 큰데, 메모리에 올라간 크기는 반대로 뒤집힙니다.

안 쓰는 모델은 ollama rm gemma4:31b 로 지우면 디스크가 바로 회수됩니다. ollama ps 로 지금 메모리에 올라간 모델과 GPU 사용 비율을 볼 수 있고요.

측정 조건

MacBook Pro M3 Pro, 통합메모리 36GB, Ollama 0.32.11에서 쟀습니다. 프롬프트는 요약·추론·한국어 설명 세 가지, 옵션은 온도 0에 시드 고정입니다.

수치는 워밍업 한 번을 버리고 다섯 번 재서 중앙값을 썼습니다. 한 번만 재면 값이 튑니다. 실제로 첫 시도에서 적재 메모리를 1.7GB로 잘못 읽었는데, 모델이 다 올라오기 전에 확인해서 생긴 오차였어요.

크기가 두 배면 속도는 절반

Gemma 4 크기별 생성 속도 Gemma 4 크기별 생성 속도 — 출처: 직접 작성 (직접 실측)

E2B가 초당 61.5토큰, E4B가 32.6토큰, 12B가 14.9토큰입니다. 크기가 커질 때마다 속도가 거의 정확히 반씩 떨어졌어요.

크기 속도 적재 메모리
E2B 61.5 tok/s 7.2GB
E4B 32.6 tok/s 9.5GB
12B 14.9 tok/s 8.4GB

측정값의 흔들림은 크지 않았습니다. E2B가 57.0~64.8, E4B가 31.4~34.3, 12B가 11.8~15.2 사이였어요. 같은 프롬프트를 다섯 번 돌린 결과라 이 정도면 안정적인 편입니다.

콜드 로드는 E2B 2.9초, E4B 8.4초, 12B 6.7초였습니다. 모델을 메모리에 올리는 시간이라 한 번 올려두고 계속 쓰면 다시 들지 않습니다. 다만 Ollama는 일정 시간이 지나면 모델을 내리기 때문에, 가끔 쓰는 용도라면 첫 질문마다 이 시간이 붙습니다.

프롬프트 종류는 속도를 거의 안 바꾼다

같은 모델에서 프롬프트를 바꿔도 초당 토큰 수는 비슷했습니다. 12B만 한국어 설명 과제에서 11.8까지 내려갔어요.

크기 요약 추론
E2B 57.0 61.5
E4B 31.6 32.7
12B 15.1 14.2

속도를 바꾸는 건 프롬프트 내용이 아니라 생성하는 토큰 수입니다. 어떤 질문이냐에 따라 답이 길어지고, 그게 곧 대기 시간이 됩니다.

15 tok/s는 어느 정도인가

사람이 소리 내어 읽는 속도보다 조금 빠른 정도입니다. 짧은 답이면 기다린다는 느낌이 없고, A4 한 장 분량을 뽑으려면 1분 넘게 걸립니다.

세 크기 모두 GPU에 100% 올라갔습니다. 통합메모리 36GB에서 가장 큰 12B가 8.4GB를 썼으니 여유가 많이 남았어요. 이 기기에서는 더 큰 모델도 올라갈 수 있다는 뜻입니다.

파라미터 수와 메모리는 따로 논다

여기서 눈에 걸리는 게 있습니다. 12B의 적재 메모리가 E4B보다 작습니다. 파라미터는 세 배 가까이 많은데도요.

E 계열이 임베딩까지 합치면 8B라는 공식 표기와 맞물리는 대목입니다. 내려받은 파일 크기도 순서가 뒤집혀 있어서, E4B가 9.6GB인데 12B는 7.6GB입니다. 이름의 숫자나 파일 크기만 보고 메모리를 가늠하면 어긋납니다.

기본값이 thinking이라는 함정

요약 한 건을 받기까지 걸린 시간 요약 한 건을 받기까지 걸린 시간 — 출처: 직접 작성 (직접 실측)

Gemma 4는 답하기 전에 추론 과정을 먼저 생성합니다. 문제는 그게 기본값이고, 짧은 요약에도 똑같이 붙는다는 점이에요.

문장 하나를 한 줄로 요약해 달라고 시켰을 때입니다.

크기 thinking 켬 thinking 끔
E2B 433토큰 · 8.0초 39토큰 · 1.0초
E4B 789토큰 · 25.5초 52토큰 · 2.1초
12B 622토큰 · 41.7초 40토큰 · 3.4초

E2B가 8배, E4B와 12B는 12배 차이입니다. 답의 내용은 크게 다르지 않은데 앞에 붙은 추론 과정이 600~800토큰이었어요.

끄는 법

Ollama에서는 실행할 때 –think=false를 붙이거나 API 요청에 think: false를 넣으면 됩니다. 기본값이 켜짐이라 아무 설정 없이 쓰면 위 표의 왼쪽 열이 됩니다.

처음에 이걸 모르고 응답 길이를 256토큰으로 제한해 뒀더니 결과가 아예 비어서 돌아왔습니다. 추론 과정을 뱉다가 예산이 끝나 최종 답에 도달하지 못한 것이었어요. 로컬에서 응답 길이를 제한해 쓰는 경우라면 걸리기 쉬운 함정입니다.

켜두면 좋은 자리도 있다

추론이 필요한 문제에서는 이야기가 다릅니다. 사과 12개를 세 사람이 나누되 한 명이 2개씩 더 받는 문제를 시켰더니 결과가 갈렸어요.

E2B는 thinking을 켜든 끄든 1,024토큰 상한을 채우고도 정리된 답에 도달하지 못했습니다. 17초를 쓰고 답이 없는 셈이에요. E4B도 켠 상태에서 상한을 채웠고, 끈 상태에서는 931토큰을 썼습니다.

크기 thinking 켬 thinking 끔
E2B 1,024토큰 · 17.0초 1,024토큰 · 17.7초
E4B 1,024토큰 · 31.8초 931토큰 · 30.2초
12B 1,024토큰 · 72.6초 494토큰 · 33.6초

12B는 끈 상태에서 494토큰으로 풀었습니다. 작은 모델은 켜도 못 푸는 문제가 있고, 큰 모델은 꺼도 풉니다. 켜고 끄는 게 능력을 만들어 주지는 않는다는 뜻입니다.

한국어 설명 과제에서는 반대 현상도 나왔습니다. E2B와 E4B가 464토큰과 691토큰으로 끝낸 프롬프트를 12B는 thinking 모드에서 1,024토큰 상한까지 채웠어요. 87.5초가 걸렸습니다. 모델이 커질수록 더 길게 생각한다는 뜻이라, 속도 차이가 크기 차이보다 더 벌어집니다.

요약·번역은 끄고, 계산이 필요하면 켜는 쪽이 실용적입니다

한국어는 어느 정도인가

정답을 판정할 수 있는 과제 열 개를 만들어 세 크기에 같은 조건으로 물었습니다. 맞춤법·띄어쓰기·높임법·조사·사이시옷·한자어 순화·번역·단위 변환·상식·존댓말입니다.

조사 하나를 고르는 데 쓴 토큰 조사 하나를 고르는 데 쓴 토큰 — 출처: 직접 작성 (직접 실측)

과제 어긋난 곳
띄어쓰기·높임법·번역 세 크기 모두 정상
맞춤법 E4B가 다른 말로 대체
단위 변환 12B 오답, E4B 정답
사이시옷 E2B·E4B 글자 깨짐

흔치 않은 음절에서 글자가 깨진다

가장 눈에 띈 건 등굣길이었습니다. E2B와 E4B가 이 단어를 출력할 때 굣 자리에 바이트 값이 그대로 나왔어요.

💻 [소스코드: gemma4:e4b 실제 출력]

'등교'는 두 단어의 결합이 아니므로
사이시옷 표기가 필요 없고,
'등<0xEA><0xB5><0xA3>길'은 '등교'와
'길'이 결합하여 합성어의 성격을 띠므로
사이시옷 표기가 필요합니다.

12B에서는 글자가 정상이었습니다. 대신 설명이 틀렸어요.

💻 [소스코드: gemma4:12b 실제 출력]

'등굣길'은 '등교'와 '길'이 결합할 때
앞 단어의 끝소리가 'ㄹ'로 끝나고
뒤 단어의 첫소리가 'ㄱ'으로 시작하여
발음이 겹치거나 헷갈릴 수 있기 때문에
사이시옷을 표기합니다.

등교는 ㄹ로 끝나지 않습니다. 글자는 제대로 썼지만 규칙 설명은 지어냈어요. 세 크기 모두 이 문항은 통과하지 못했습니다.

크기가 정확도를 보장하지 않는다

섭씨 250도를 화씨로 바꾸라고 했습니다. 정답은 482도입니다.

💻 [소스코드: 세 크기의 답]

e2b : 계산 도중 토큰이 끝나 답에 미도달
e4b : 482
12b : 410

세 배 큰 모델이 틀렸습니다. E4B는 4토큰으로 정답만 냈고요. 숫자를 다루는 일은 크기와 무관하게 검산이 필요합니다.

시킨 것만 하지 않는다

틀린 곳만 고쳐서 한 문장으로 다시 써 달라고 했습니다. 원문은 ‘회의가 몇일에 있는지 알려주세요’이고, 고칠 곳은 몇일 → 며칠 하나입니다.

💻 [소스코드: 세 크기의 답]

e2b : 회의가 며칠인지 알려주세요.
      또는 회의 날짜를 알려주세요.
e4b : 회의가 언제 있는지 알려주세요.
12b : 회의가 며칠에 있는지 알려주세요.

E4B는 틀린 단어를 고치는 대신 언제로 바꿔 버렸습니다. 문장은 자연스러워졌지만 요청한 교정은 아니에요. 맞춤법 검사 용도로 쓰려면 이런 우회가 문제가 됩니다.

잘한 것도 있다

높임법은 세 크기 모두 맞혔고, 12B는 이유까지 정확히 짚었습니다.

💻 [소스코드: gemma4:12b 실제 출력]

잘못된 부분은 '커피'에 높임의
선어말 어미 '-시-'를 사용한 것입니다.

[수정된 문장]
"주문하신 커피 나왔습니다."

이유: '-시-'는 문장의 주체가
높임의 대상일 때 쓰는 표현입니다.
분석: 이 문장에서 행동의 주체는
'커피'이고, 커피는 사물이므로
높임의 대상이 아닙니다.
오류 원인: 손님을 존중하려는 마음이
'커피'라는 사물까지 높이는 표현으로
잘못 전달된 '사물 존칭'의 오류입니다.

사물 존칭이라는 용어까지 정확합니다. 띄어쓰기 교정도 세 크기 모두 정답이었고, 12B는 다섯 항목으로 근거를 나눠 설명했어요. 밖에가 조사라서 붙여 쓴다는 것까지 짚었습니다.

번역도 무난했습니다. pushed back을 세 크기 모두 연기·미뤄짐으로 옮겼고, 12B는 격식에 따라 세 가지 안을 나눠 제시했습니다.

공통 문제는 장황함

괄호에 조사 하나를 넣으라는 과제입니다. 답은 는 한 글자면 끝나요.

💻 [소스코드: 응답 길이 비교]

e2b (11토큰)
'나(는) 학교에 간다.'

e4b (255토큰)
괄호에 알맞은 조사는 는 또는 에 입니다.
문맥에 따라 의미가 달라질 수 있습니다.
1. "나(는) 학교에 간다."
의미: 주어 '나'를 강조하며 …

12b (156토큰)
문맥에 따라 여러 가지 조사가
들어갈 수 있습니다.
1. 나(는) 학교에 간다.
2. 나(도) 학교에 간다. …

가장 작은 모델이 가장 정확하게 답했습니다. 큰 모델들은 묻지 않은 대안까지 늘어놓느라 스무 배 넘는 토큰을 썼어요.

존댓말 과제에서는 세 크기 모두 300토큰 상한을 채웠습니다. 밥 먹었어를 존댓말로 바꿔 달라는 요청에 상황별 분류와 이모지까지 붙여 답을 늘렸습니다. 로컬에서는 이 장황함이 그대로 대기 시간이 됩니다.

그래서 어디에 쓸 만한가

번역과 띄어쓰기, 높임법 교정은 세 크기 모두 무난했습니다. 김치찌개 재료처럼 간단한 상식도 셋 다 맞혔고요.

반대로 맞춤법 교정과 숫자 계산은 크기와 상관없이 틀린 답이 섞여 나왔습니다. 사이시옷처럼 규칙 설명이 필요한 문항은 세 크기 모두 실패했어요.

문장을 다듬는 용도라면 로컬로 충분하고, 정확한 값이나 어문 규범이 필요한 자리에는 검산을 붙이는 편이 맞습니다.

26B와 31B는 왜 뺐나

다섯 크기를 다 받아 놓고 세 개만 쟀습니다. 측정에 걸리는 시간이 크기에 비례해 늘어나서예요.

12B 한 모델을 재는 데 프롬프트 3종 × 모드 2종 × 6회로 20분이 걸렸습니다. 앞의 속도 흐름대로면 26B는 7 tok/s, 31B는 그 아래로 떨어질 가능성이 큽니다. 같은 항목을 재려면 각각 40~60분이 더 필요했어요.

받아 놓은 파일 크기로 짐작할 수 있는 건 있습니다. 26B가 17GB, 31B가 19GB라 36GB 통합메모리에는 올라갑니다. 다만 12B가 8.4GB를 쓴 걸 감안하면 실제 적재량은 파일 크기와 또 다를 겁니다.

26B는 MoE 구조라 토큰마다 3.8B만 활성화됩니다. 파라미터가 25.2B인데도 속도는 덴스 12B와 비슷하거나 빠를 수 있다는 뜻이고, 이 라인업에서 가장 궁금한 자리예요. 다음에 따로 재서 붙일 부분입니다.

데이터가 기기 밖으로 나가지 않는다

로컬 실행의 실질적인 이점은 속도가 아니라 데이터가 기기 밖으로 안 나간다는 점입니다.

측정하는 동안 네트워크는 모델을 내려받을 때만 쓰였고, 질문과 답은 전부 기기 안에서 처리됐습니다. 사내 문서나 계약서처럼 외부 API에 올리기 곤란한 자료를 다룰 때 이 차이가 큽니다.

Apache 2.0 라이선스라 상업적 이용에도 제약이 없습니다. 다만 Google이 별도로 두는 금지 사용 정책이 있으니 실무 도입 전에는 원문을 확인하는 게 맞습니다.

정리하면

36GB 맥북에서 12B까지는 무리 없이 돌아갑니다. 속도는 크기가 커질 때마다 반씩 줄어 12B에서 15 tok/s 정도고, 메모리는 8.4GB만 썼습니다.

그보다 먼저 확인할 건 설정입니다. thinking이 켜져 있으면 짧은 요약 하나에 41.7초를 기다리게 되는데, 끄기만 해도 3.4초로 줄어듭니다. 로컬 LLM이 느리다고 느꼈다면 모델 크기가 아니라 이 설정 때문일 수 있어요.

한국어는 문장을 다듬는 쪽이 강하고 규칙을 설명하는 쪽이 약했습니다. 크기를 키운다고 나아지지 않는 항목이 있다는 게 이번 측정에서 가장 분명하게 나온 부분입니다.

참고 출처