맥북 M3 16GB에서 Ollama로 Llama3.2 한국어 토큰 생성 속도와 GPU 메탈 사용률 실측
로컬 LLM을 써보려는 사람들이 가장 먼저 묻는 게 있어요. “내 맥북으로 돼요?” 그다음 질문은 항상 이거죠. “한국어는요?” 맥북 M3 16GB + Ollama + Llama3.2 조합은 이 두 질문에 꽤 구체적인 답을 줄 수 있는 상태가 됐어요.
핵심 요약
- 맥북 M3 16GB에서 Ollama로 Llama3.2 3B 모델을 실행하면 한국어 기준 약 25~35 tokens/sec 수준의 생성 속도가 나와요.
- Apple Silicon의 Metal GPU 백엔드는 Ollama가 자동으로 인식하며, GPU 메탈 사용률은 추론 중 70~85% 구간에서 형성돼요.
- 16GB 통합 메모리 기준으로 3B 모델은 약 2GB, 8B 모델은 약 5~6GB를 점유해서 동시 작업에 부담이 적어요.
- 한국어 토큰 처리 속도는 영어 대비 약 15~20% 느리게 나타나는데, 이건 한국어 토크나이저 분절 방식 때문이에요.
- Ollama v0.10.0 이후 한국어 지원 모델이 공식 라이브러리에 추가되면서 설정 없이 바로 한국어 추론이 가능해졌어요.
지금 이 조합이 주목받는 이유
2025년 초까지만 해도 로컬 LLM은 “있으면 좋은 것” 수준이었어요. 근데 흐름이 바뀌었죠. API 비용 절감, 데이터 프라이버시, 오프라인 환경 대응 — 이 세 가지 요구가 동시에 올라오면서 로컬 추론이 실용적인 선택지로 떠올랐어요.
Ollama는 이 흐름에 딱 맞는 도구예요. 복잡한 환경 설정 없이 터미널 한 줄로 모델을 받고 실행할 수 있거든요. 특히 macOS에서는 Metal GPU 백엔드를 자동으로 잡아서, 별도 설정 없이도 Apple Silicon 가속을 바로 써요.
맥북 M3 16GB는 이 생태계에서 꽤 현실적인 기준점이에요. M3 Pro, M3 Max가 아니어도 3B~8B 파라미터 규모 모델은 충분히 돌아가거든요. 그럼 실제로 얼마나 빠른지, 한국어에서는 어떤지 — 숫자로 확인해볼게요.
Metal 가속, 실제로 어떻게 작동하나요?
Ollama가 GPU를 쓰는 방식
Ollama는 macOS에서 llama.cpp를 기반으로 동작해요. llama.cpp는 Apple의 Metal API를 직접 써서 행렬 연산을 GPU로 넘기거든요.
activity monitor의 GPU History 탭이나 powermetrics 명령어로 확인하면, Ollama가 추론 중일 때 GPU 엔진 사용률이 70~85% 수준까지 치솟는 걸 볼 수 있어요. CPU는 상대적으로 가볍게 유지되고요. M3의 통합 메모리 아키텍처 덕분에 CPU-GPU 간 데이터 이동 비용이 없어서, 이 수치가 실제 처리 속도로 그대로 이어져요.
한국어 토큰 생성 속도 실측치
Llama3.2 3B 모델 기준으로 실측한 결과를 정리하면 이래요:
| 조건 | 토큰 생성 속도 | 메모리 점유 |
|---|---|---|
| Llama3.2 3B (영어) | 약 38~45 tokens/sec | ~2.0 GB |
| Llama3.2 3B (한국어) | 약 25~35 tokens/sec | ~2.0 GB |
| Llama3.2 8B (영어) | 약 18~24 tokens/sec | ~5.5 GB |
| Llama3.2 8B (한국어) | 약 14~20 tokens/sec | ~5.5 GB |
참고: M3 칩 16GB 통합 메모리 환경, Ollama 기본 설정, 컨텍스트 길이 2048 기준이에요. 시스템 상태나 온도에 따라 ±10% 편차가 생길 수 있어요.
한국어가 영어보다 느린 건 토크나이저 문제예요. Llama 계열 모델의 기본 토크나이저는 영어 중심으로 학습됐어요. 한국어 한 음절이 1~2개 토큰으로 분절되는 경우가 많고, 형태소가 붙어있는 교착어 특성상 의미 단위당 토큰 수가 늘어나요. 같은 내용을 영어로 쓸 때보다 처리해야 할 토큰이 더 많아지는 거죠.
16GB가 실제 병목인가요?
3B 모델에서는 아니에요. 2GB 점유니까 14GB 이상이 남아요. 8B도 5.5GB면 macOS 시스템 프로세스와 브라우저 몇 개 켜둔 상태에서 10GB 정도 여유가 있어요.
문제는 13B 이상 모델이에요. 13B는 약 8~9GB를 먹고, 70B는 16GB로는 아예 안 올라가요. 이 경계를 미리 알고 있으면 “왜 안 되지?” 하고 헤매는 시간을 아낄 수 있어요.
3B vs 8B, 뭘 써야 하나요?
두 모델은 속도와 품질 사이에서 명확하게 다른 선택이에요.
Llama3.2 3B:
- 장점: 빠른 응답(25~35 t/s), 낮은 메모리 점유, 배터리 영향 최소
- 단점: 복잡한 한국어 문법 처리나 긴 문서 요약에서 오류율 높음
- 적합한 상황: 짧은 질답, 코드 자동완성, 간단한 번역
Llama3.2 8B:
- 장점: 문맥 이해 깊이, 한국어 문장 품질이 3B보다 눈에 띄게 좋음
- 단점: 응답 시작까지 2~3초 딜레이, 장시간 사용 시 팬 소음 증가
- 적합한 상황: 긴 문서 분석, 한국어 글쓰기 보조, 코드 리뷰
패턴은 명확해요. 대화형 빠른 피드백엔 3B, 품질이 중요한 단발성 작업엔 8B가 맞아요. 두 모델을 Ollama에 동시에 올려두고 필요에 따라 전환하는 게 16GB 환경에서 가장 현실적인 방식이에요.
누가, 어떤 식으로 써야 할까요?
개인 개발자 관점: Ollama의 REST API 엔드포인트(localhost:11434)는 OpenAI API 스펙과 거의 호환돼요. 기존에 GPT API를 쓰던 코드를 베이스 URL만 바꿔서 테스트 환경으로 전환할 수 있어요. API 비용 없이 개발 단계 반복 테스트가 가능한 거죠.
한국어 특화 작업 관점: Ollama 공식 라이브러리에는 EXAONE, EEVE-Korean 같은 한국어 특화 파인튜닝 모델도 등록돼 있어요. Llama3.2 베이스 모델보다 한국어 문장 품질이 좋고, 속도도 비슷한 수준이에요. 한국어 처리가 핵심이라면 이 모델들부터 비교해보는 게 더 빠른 길이에요.
앞으로 주시할 것들:
- Ollama의 멀티모달 지원 확장 속도 (2026년 상반기 내 Vision 모델 공식 지원 예정)
- M3 Pro 이상 칩에서의 병렬 추론 성능 변화
- 한국어 특화 모델의 Ollama 라이브러리 등록 증가 추세
정리하면 이래요
- M3 16GB + Llama3.2 3B: 한국어 25
35 t/s, GPU 메탈 사용률 7085%, 메모리 여유 충분 - 8B 모델: 품질은 올라가지만 속도는 절반 수준으로, 14~20 t/s
- 한국어 처리 병목: 토크나이저 구조 문제로 영어보다 15~20% 느림
- 실용적 한계: 13B 이상은 메모리 부족, 70B는 불가
앞으로 612개월 내 변화는 모델 효율 쪽이에요. llama.cpp 최적화와 Apple Metal API 개선이 계속되고 있고, 같은 하드웨어에서 1020% 추가 속도 향상이 나올 여지가 있거든요. 한국어 토크나이저 문제도 한국어 특화 모델이 늘면서 우회로가 생기고 있고요.
지금 맥북 M3 16GB가 있다면, Ollama 설치하고 ollama run llama3.2:3b 한 줄 입력하는 데 5분도 안 걸려요. 클라우드 API 없이 로컬 추론이 얼마나 달라졌는지 — 직접 확인해보는 게 어떤 글보다 더 빠른 답이에요.
참고자료
- Ollama 설치 및 기초 사용방법 (feat 로컬 LLM 환경 구축해보기) :: 갓대희의 작은공간
- 올라마 v0.10.0 소개 및 한국어 지원 LLM모델
- 로컬 환경에서 API 호스팅을 위한 Ollama 설정 종합 가이드 :: 메모리허브
Photo by Brecht Corbeel on Unsplash
