AI 활용법

맥에서 로컬 LLM 돌리기|M1~M5 칩별·메모리별 모델 선택 가이드 (2026)

cookiepress · 2026년 6월 2일 · 26분 읽기 · 조회 816
a computer monitor and a keyboard

맥에서 클라우드 없이, API 비용 없이, 데이터를 내 컴퓨터 밖으로 한 번도 내보내지 않고 LLM을 돌린다? 예전부터 가능은 했지만 “쓸 만한가?”는 별개의 문제였습니다. 그런데 2026년 봄, 세 가지 변화가 한꺼번에 일어나면서 애플 실리콘 로컬 AI가 진짜 실전용이 됐습니다. 이 글은 Marco Kotrotsos의 글(원문)과 거기 실린 두 개의 정리표를 바탕으로, 내 맥으로 어떤 모델을 어떻게 돌릴지 한국어로 풀어 쓴 글입니다.

내 맥은 어떤 모델을 돌릴 수 있나 — 30초 진단

칩 이름보다 메모리 용량이 먼저입니다. 같은 M4라도 16GB와 64GB는 돌릴 수 있는 모델이 완전히 다릅니다. 내 맥의 메모리부터 확인하세요.

화면 왼쪽 위 사과 메뉴 → 이 Mac에 관하여를 열면 칩 이름과 메모리가 함께 나옵니다. 터미널을 쓰신다면 이 한 줄로도 됩니다.

system_profiler SPHardwareDataType | grep -E "Chip|Memory"
메모리현실적인 상한추천 시작 모델체감
8GB3BApple Foundation Models (시스템 내장)가벼운 작업만
16GB7~8BQwen 3 8B (Q4)일상 작업 가능
32GB14~30BQwen 3 8B → Phi-4 14B쾌적
64GB35B30B급 상시 구동여유
128GB70B70B급 (Q4)로컬 플래그십

Q4 양자화 기준입니다. 아래에서 계산 방법을 설명합니다.

메모리가 8GB나 16GB라고 실망하실 필요는 없습니다. 대부분의 실제 작업은 8B 모델로 충분합니다. 요약, 분류, 번역, 간단한 코드 작성은 8B에서 이미 쓸 만합니다. 큰 모델이 필요한 건 복잡한 추론이 걸린 작업입니다.


“SuperPower”의 정체 — 무엇이 바뀌었나

원문 제목의 “Superpowers”는 괜히 만들어낸 수식어가 아닙니다. 2026년 1분기~2분기에 실제로 일어난 세 가지 구체적인 사건을 말하는데요. 아래에서 자세히 살펴보도록 하겠습니다.

1. Ollama 0.19 — 추론 엔진을 MLX로 갈아끼우다

가장 큰 변화. 2026년 3월 30일, 가장 널리 쓰이는 로컬 LLM 런타임인 Ollama가 애플 실리콘에서의 추론 엔진을 MLX로 교체했습니다. (리눅스·윈도우는 기존 llama.cpp 유지.)

MLX는 애플이 만든 머신러닝 프레임워크로, 맥의 통합 메모리(unified memory) 구조를 제대로 활용한다고 알려져 있습니다. CPU와 GPU가 같은 메모리 풀을 공유하기 때문에, PC에서 병목이 되는 데이터 복사 과정이 사라집니다.

성능 향상은 “최적화” 수준이 아니라 거의 2배입니다. Ollama 공식 벤치마크(M5 Max + Qwen3.5-35B-A3B 기준):

항목Ollama 0.18 (기존)Ollama 0.19 (MLX)향상
Prefill (프롬프트 처리)1,154 tok/s1,810 tok/s+57%
Decode (응답 생성)58 tok/s112 tok/s+93%

특히 M5 계열 칩은 새로 추가된 GPU Neural Accelerator(행렬 연산 전용 하드웨어) 덕에 효과가 가장 큽니다. M1~M4도 통합 메모리 최적화 혜택은 받지만 Neural Accelerator 가속은 아직 없습니다. 즉, M5Max가 설치된 맥북이 MLX 성능을 가장 많이 뽑아낼 수 있는 기기라고 할 수 있겠습니다.

MacBook Pro on white surface
Photo by Tianyi Ma on Unsplash

⚠️ 단, 이 MLX 경로는 현재 통합 메모리 32GB 이상 맥에서 권장됩니다. 그 미만이면 기존 llama.cpp로 폴백됩니다. 8/16GB 맥 사용자는 당장 큰 체감을 기대하기 어렵습니다. (정식 릴리스는 2026년 2분기 예정.)

2. Apple Foundation Models 프레임워크 — 앱이 믿고 쓸 수 있는 수준으로

2025년 macOS 26 / iOS 26과 함께 나온 Apple Foundation Models 프레임워크가 2026년 들어 성숙기에 접어들었습니다. 핵심은 Swift 개발자가 시스템 내장 LLM을 몇 줄로 호출할 수 있다는 것인데요.

  • @Generable 매크로 — Swift의 struct/enum에 붙이면 컴파일 타임에 스키마가 생성되고, 모델이 타입 안전한 구조화 출력을 그대로 채워줍니다. JSON 문자열을 손으로 파싱하던 시대의 종말입니다. (토큰 단위 제약 디코딩이라 “유효한 JSON이 나오길 기도”할 필요가 없습니다.)
  • 툴 콜링(tool calling) 내장
  • 멀티턴 세션 상태 유지 (LanguageModelSession)
  • 모델은 약 3B 파라미터로 작지만 요약·분류·구조화 추출 같은 “앱이 실제로 하는 일”에 최적화
  • 그리고 호출 비용이 0원. 시스템에 내장돼 무료입니다.

3. macMLX — OpenAI 호환 API로 도입 장벽을 없애다

원문에 따르면 2026년 4월 18일, macMLX가 SwiftUI 네이티브 LLM 런타임으로 출시됐습니다. 화려한 기능보다 중요한 건 OpenAI 호환 API를 제공한다는 점. 이미 OpenAI API로 짜둔 앱이라면 설정만 바꿔서 로컬 모델로 갈아탈 수 있다는 뜻입니다. 채택 장벽이 사라진 것입니다.

정리하면, 빨라졌고(Ollama+MLX), 공짜 구조화 출력이 생겼고(Foundation Models), 기존 코드를 그대로 쓸 길이 열렸습니다(OpenAI 호환). 이 셋이 합쳐져 로컬 AI가 “취미”에서 “실전 스택”으로 넘어왔습니다.


내 칩으로는 뭘 돌릴 수 있나 (M1 → M5 칩별 가이드)

이제부터 핵심입니다. 애플 실리콘은 세대별·등급별로 메모리와 성능 차이가 커서, 칩에 맞는 모델을 골라야 쾌적한데요. 원문의 첫 번째 표를 한국어로 재구성했습니다.

🟢 M1 / M1 Pro — 8~16GB

  • 권장 스택: Apple Foundation Models를 기본으로 (하드웨어에 최적화된 3B 온디바이스 모델). 가끔 더 큰 작업이 필요하면 7~8B 모델(Q4)을 선택적으로 — 단 느리다.
  • 음성 인식(Transcription): WhisperKit (base 또는 small)
  • 현실적 모델 규모: 3B(네이티브) ~ 7–8B(Q4)

🔵 M2 / M2 Pro — 16~32GB

  • 권장 스택: Qwen 3 8B(Q4) — 약 5GB 메모리를 상주시켜 무거운 추론용. 빠르고 구조화된 출력은 Apple Foundation Models로.
  • 음성 인식: WhisperKit large-v3 turbo
  • 현실적 모델 규모: 8B (쾌적)

🟣 M3 Pro / Max — 18~128GB

  • 권장 스택: 일반 작업은 Qwen 3 8B(Q4), 더 날카로운 추론이 필요하면 Phi-4 14B(Q4, 약 9GB 상주). 구조화 출력은 Foundation Models.
  • 음성 인식: WhisperKit large-v3 turbo
  • 현실적 모델 규모: 8B ~ 14B (고품질)

🟠 M4 Pro / Max — 24~128GB

  • 권장 스택: Llama 4 Scout(Q4) — 30B급 만능형. 코드 중심 작업엔 DeepSeek V3-Distill-32B(Q4)가 탁월. 구조화 출력은 Foundation Models.
  • 음성 인식: WhisperKit large-v3 turbo
  • 현실적 모델 규모: 30~32B (부드럽게 구동). 30B 모델 기준 약 60~90 tok/s 디코드.

🟢 M5 Max — 32~128GB

  • 권장 스택: Qwen3.5-35B-A3B(Q4) — 현재 MLX 쇼케이스 모델, 약 112 tok/s 디코드(Ollama 0.19+). 128GB라면 70B급 모델(Q4)도 실용적 — 로컬에서 클라우드급 품질.
  • 음성 인식: WhisperKit large-v3 turbo
  • 현실적 모델 규모: 35B (매우 빠름) ~ 70B (로컬 플래그십). 35B 기준 약 112 tok/s 디코드.

한눈에: M1·M2는 8B가 상한선이자 스위트스폿, M3는 14B까지, M4는 30B급, M5 Max는 35~70B급까지. 메모리가 곧 기준입니다.


용도별 모델 선택 가이드

칩이 정해졌다면, 다음은 “무슨 일에 어떤 모델”이냐 입니다. 원문의 두 번째 표를 한국어로 옮기고 약간의 주석을 더했습니다.

용도추천 모델크기(Q4)이유
구조화 출력·분류·요약Apple Foundation Models시스템 내장무료, 네이티브 Swift, 이 작업들에 최적화
일반 추론 (기본 일꾼)Qwen 3 8B~5GB품질·속도·크기의 최적 균형
작고 빠른 상시 백그라운드Gemma 4 E2B~2GBM5 Max에서 158 tok/s, 최저 지연
8B로 부족한 더 날카로운 추론Phi-4 14B~9GBMS의 추론 특화(reasoning-tuned) 모델
코드 생성Qwen 2.5 Coder 14B 또는 DeepSeek V3-Distill 14B~9–10GB코드 특화 학습, SWE-bench류 강세
다국어 대형 작업Llama 4 Scout~14GB적당한 크기에 강력한 다국어 커버리지
최고 품질 로컬(70B급)Qwen3.5-35B-A3B~22GB현재 MLX 쇼케이스 모델

실전 조합 팁: 대부분의 작업은 “Foundation Models(구조화·요약) + Qwen 3 8B(일반 추론)” 2개 조합으로 충분합니다. 여기에 코드 작업이 많으면 코더 모델을, 백그라운드 상시 작업이 필요하면 Gemma 4 E2B를 얹는 식으로 늘려가면 됩니다.


어떻게 시작하나 (가장 쉬운 경로)

가장 간단한 진입로는 Ollama 입니다.

# 1. 설치 (Homebrew)
brew install ollama

# 2. 서비스 시작
ollama serve

# 3. 모델 받아서 바로 대화
ollama run qwen3:8b

Ollama 0.19+를 쓰면 애플 실리콘에서 자동으로 MLX 경로를 타므로, 32GB 이상 맥이라면 별도 설정 없이 속도 향상을 누릴 수 있습니다. GUI를 선호하면 LM Studio도 좋은 선택이고, 이쪽도 MLX 가속을 지원합니다.

음성 받아쓰기가 필요하면 WhisperKit(애플 실리콘 최적화 Whisper 구현)을 붙이면 됩니다. 위 표대로 M2 이상이면 large-v3 turbo가 쾌적하게 작동합니다.


개발자·자동화 관점에서 진짜 매력

이 글을 읽는 사람이 PHP·자바스크립트로 서비스를 만들고 AI 자동화에 관심이 있다면, 이번 변화의 의미는 분명합니다.

  • 기존 코드를 거의 안 바꿔도 됩니다. Ollama도, macMLX도 OpenAI 호환 엔드포인트를 노출합니다. 코드에서 base_url만 로컬 주소(http://localhost:11434/v1 등)로 바꾸면, OpenAI SDK를 쓰던 자바스크립트/PHP 코드가 그대로 로컬 모델을 호출합니다.
  • 비용이 0이고 데이터가 밖으로 안 나갑니다. 토큰 단가 걱정 없이 마음껏 호출할 수 있어서, “이메일 분류 → 요약 → 알림” 같은 자동화 파이프라인을 24시간 돌려도 추가 비용이 없습니다. 고객 데이터를 외부 API로 보낼 수 없는 상황에도 적합합니다.
  • 구조화 출력이 안정적입니다. 자동화에서 가장 골치 아픈 게 “모델이 깨진 JSON을 뱉는” 문제인데, 로컬에서도 제약 디코딩으로 스키마를 강제할 수 있게 됐습니다. n8n·Node-RED 같은 워크플로 도구에 로컬 LLM을 노드로 끼워 넣기가 훨씬 수월해집니다.

M1 Max 32GB로 실제로 돌려봤습니다

표만 보고 쓰는 글이 되지 않도록, 제 맥북 프로(M1 Max · 통합 메모리 32GB)에서 직접 다섯 개 모델을 돌려 측정했습니다. 아래 숫자는 전부 이 기기에서 나온 값입니다.

생성 속도 — 크기 순서가 아닙니다

모델디스크생성 속도첫 로딩
qwen2.5:7b4.7GB58.7 tok/s3.5초
gemma4:26b17GB56.0 tok/s15.5초
exaone3.5:7.8b4.8GB52.4 tok/s3.7초
qwen3:8b5.2GB44.7 tok/s4.3초
qwen2.5:14b9.0GB26.9 tok/s6.8초

동일한 짧은 프롬프트로 측정. ollama run 모델명 --verbose 의 eval rate 값입니다.

예상과 달랐던 것은 26B 모델이 14B보다 두 배 빨랐다는 점입니다. 파라미터 수만 보고 짐작하면 안 된다는 뜻인데, 이유가 두 가지입니다.

  • MoE 구조 — 전체 파라미터가 26B라도 토큰마다 그중 일부만 활성화되는 모델이 있습니다. 메모리는 26B만큼 쓰지만 연산량은 훨씬 적습니다
  • 추론 모델의 사고 토큰 — qwen3는 답하기 전에 Thinking... 단계를 거칩니다. “대한민국의 수도는?”이라는 질문에도 95개 토큰을 생성했는데, 실제 답은 10개 남짓이고 나머지는 전부 사고 과정입니다. 초당 속도는 빨라도 체감 대기 시간은 깁니다

정확도가 중요한 작업이라면 사고 과정이 도움이 되지만, 단순 분류나 요약을 자동화할 때는 오히려 손해입니다. 용도에 따라 추론 모델을 피해야 할 때가 있습니다.

한국어 모델도 있습니다

표의 exaone3.5는 LG AI연구원이 만든 한국어 특화 모델입니다. 7.8B로 크기가 작은데 52.4 tok/s로 충분히 빠릅니다. 한국어 문서를 다루는 작업이라면 같은 크기의 다국어 모델보다 나은 선택일 수 있습니다.

ollama run exaone3.5:7.8b

로컬 모델이 절대 못 하는 것

속도보다 중요한 한계를 확인한 테스트가 있습니다. 두 모델에 같은 질문을 던져봤습니다.

맥북프로 가장 최근에 출시된 모델 중 사양이 가장 좋은 제품은?

모델답변실제
qwen3:8bM3 Max · 32코어 GPU두 세대 틀림
gemma4:26bM4 Max · 40코어 GPU한 세대 틀림

둘 다 틀렸습니다. 재미있는 것은 두 모델이 자기 사고 과정에 이유를 적어놨다는 점입니다.

  • qwen3:8b — “As of my last update in October 2023…”
  • gemma4:26b — “Most recent lineup (as of late 2024/early 2025 knowledge)…”

모델을 키운다고 해결되지 않습니다. 26B가 8B보다 한 세대 덜 틀렸을 뿐 여전히 틀렸습니다. 학습을 마친 시점 이후의 일은 원리적으로 알 수 없기 때문입니다. 로컬 모델은 인터넷에 접속하지 않으니 확인할 방법도 없습니다.

그래서 최신 정보가 걸린 질문은 로컬 모델에 맡기면 안 됩니다. 제품 사양, 가격, 법 개정, 뉴스 같은 것들입니다. 반대로 요약·번역·분류·문체 교정처럼 주어진 텍스트만 다루는 작업에는 학습 시점이 아무 상관이 없습니다. 로컬 모델을 쓸 자리는 여기입니다.

직접 재보는 방법

같은 방식으로 자기 맥에서 재보실 수 있습니다.

ollama run qwen3:8b --verbose "대한민국의 수도는? 한 문장으로만 답해."

응답이 끝나면 아래에 측정값이 붙습니다.

total duration:       6.494s     ← 전체 소요 시간
load duration:        4.269s     ← 모델을 메모리에 올리는 시간 (처음 한 번만)
eval rate:            44.70 tokens/s    ← 실제 생성 속도

load duration은 모델이 메모리에 올라가 있으면 사라집니다. 두 번째 질문부터는 바로 답이 시작됩니다. 반대로 여러 모델을 번갈아 쓰면 그때마다 다시 로딩되므로, 주력 모델 하나를 정해두고 쓰는 편이 쾌적합니다.


알고 시작해야 할 한계

장밋빛 얘기만 하면 균형이 안 맞으니, 현실도 짚어보겠습니다.

  • 메모리가 기준입니다. Ollama의 MLX 가속은 사실상 32GB 이상을 전제로 합니다. 애플의 최다 판매 모델은 여전히 8/16GB라, 이 혜택을 온전히 누리려면 고용량 맥이 필요합니다.
  • 로컬 모델은 프런티어 모델이 아닙니다. 35B MoE 모델이 로컬에서 잘 돈다고 해도, 최신 클라우드 플래그십(GPT·Claude 등) 수준의 추론을 기대하긴 어렵습니다. “로컬로 충분한 작업”과 “클라우드가 필요한 작업”을 구분하는 안목이 중요합니다.
  • 모델 포맷 차이. Ollama는 GGUF, MLX는 자체 포맷(.safetensors 기반, 보통 Hugging Face의 mlx-community)을 사용합니다. 다행히 인기 모델은 대부분 양쪽 빌드가 다 있습니다.

결국 현명한 전략은 하이브리드입니다. 프라이버시·비용·상시 자동화는 로컬로, 최고 난도 추론은 클라우드로 — 작업 성격에 맞춰 나눠 쓰는 것입니다.

실제로 써 보니 – 맥 스튜디오 M1 Max 32GB 기준

서버를 먼저 실행해줘야 합니다.

ollama serve
ollama run qwen3:8b --verbose "한국의 수도는?"

한국 수도에 대한 자료를 받아 오는데 15초 정도되는 시간이 걸렸습니다. 흠, 아직은 판단이 잘 서지 않네요. 그래서 조금 난이도를 올려 봅니다. 맥북 제품 중 가장 최근에 나왔던 제품 사양과 가장 좋은 제품에 대해서 알려 달라고 해봤습니다.

이건 좀 문제가 있어 보입니다. 최근에 출시된 모델이 M5 칩인데 M3 라고 주장을 하고 있습니다. 이러면 실제 업무에서 쓰기에는 무리가 있어 보입니다. 시간이 24초 정도 걸린것과는 별개로 정확성과 속도 모두 애매한 것 같습니다.

같은 사양의 맥스튜디오에서 클로드코드를 이용해서 같은 질문을 해봤습니다. 답변이 나오는데 1분 9초 정도 걸렸습니다. 시간은 오래 걸렸지만 정확도가 아주 좋습니다. 자신의 자료가 오래된거라고 직접 애플 홈페이지에서 가져왔습니다.

테스트를 하다가 궁금증이 생겨서 요즘 유명한 gemma4:26b 모델을 다운로드 받아서 같은 질문을 해봤습니다. 이 모델은 용량이 17GB나 됐습니다. 그리고 클로드처럼 최신 정보를 요구했더니 웹 검색을 하겠다는 메시지도 나왔습니다. 하지만 결과는 같았습니다.

이번 실험으로 유추해 보건데 로컬 LLM을 돌리면서 최신 자료를 요구하는 것은 위험한 요구사항이라고 보여집니다. 아직 코딩은 테스트해보지 않았지만 하나를 보면 열을 안다고 맥북프로나 맥스튜디오에서는 좋은 성능의 로컬LLM을 기대하기를 힘들어 보입니다.

요즘에 엔비디아에서 나온 젠 스파크라는 일체형 모델에 대해서 많이 얘기하던데 써보고 싶긴한데 어떨지 모르겠습니다. 두 대나 세 대 정도 병렬로 연결해서 사용하면서 테스트해보고 싶은 마음도 있습니다. 한편으로는 그 돈이면 그냥 클로드 쓰자 이런 생각도 있구요.


자주 묻는 질문

Q. 맥북 에어에서도 되나요?

됩니다. 다만 팬이 없어서 긴 작업에서는 발열로 성능이 떨어집니다(스로틀링). 짧은 질의응답은 문제없지만, 긴 문서를 통째로 처리하는 작업이라면 프로 계열이 유리합니다. 메모리 16GB 이상이면 8B 모델은 무난합니다.

Q. 모델 파일은 어디에 저장되나요?

~/.ollama/models
~/.ollama/models/manifests/registry.ollama.ai #맥에서는 이 폴더에 있습니다.

모델 하나가 수 GB이므로 여러 개 받으면 디스크가 금방 찹니다. 목록과 용량은 ollama list로 확인하고, 안 쓰는 것은 ollama rm 모델명으로 지우면 됩니다.

Q. 인터넷 없이도 되나요?

모델을 한 번 받아두면 그 뒤로는 완전히 오프라인입니다. 비행기 안에서도 됩니다. 이게 로컬 LLM의 가장 큰 장점입니다 — 데이터가 내 컴퓨터 밖으로 나가지 않습니다.

Q. 배터리가 많이 닳나요?

추론 중에는 GPU를 계속 쓰기 때문에 소모가 큽니다. 짧게 쓰는 건 괜찮지만, 자동화 스크립트를 오래 돌릴 계획이라면 전원을 연결하는 편이 낫습니다.

Q. 클라우드 API를 완전히 대체할 수 있나요?

작업에 따라 갈립니다. 요약·분류·번역·정형 데이터 추출은 로컬로 충분합니다. 반면 복잡한 코드 리팩터링이나 긴 문맥을 따라가는 추론은 아직 클라우드 플래그십이 앞섭니다. 비용이 걸린 반복 작업은 로컬로, 어려운 한 번은 클라우드로 나누는 편이 현실적입니다.


모델 크기와 필요 메모리 계산법

모델 이름에 붙은 B는 파라미터 개수(Billion)입니다. 8B면 80억 개입니다. 이 숫자로 필요한 메모리를 계산할 수 있습니다.

모델 크기FP16 (원본)Q8Q4 (주로 쓰는 것)
3B6GB3GB약 1.7GB
7B14GB7GB약 3.9GB
8B16GB8GB약 4.4GB
14B28GB14GB약 7.7GB
30B60GB30GB약 16.5GB
35B70GB35GB약 19.2GB
70B140GB70GB약 38.5GB

Q4_K_M 기준 대략값입니다. 모델 구조에 따라 다소 차이가 납니다.

양자화가 무엇인가

양자화(quantization)는 모델의 숫자 정밀도를 낮춰 용량을 줄이는 기술입니다. 사진을 JPEG로 압축하는 것과 비슷합니다. 화질이 조금 떨어지지만 용량은 크게 줄어듭니다.

  • FP16 — 원본. 품질은 최고지만 메모리를 가장 많이 씁니다
  • Q8 — 절반으로 압축. 품질 손실이 거의 없습니다
  • Q4 — 4분의 1 수준. 품질 손실이 약간 있지만 대부분 체감하기 어렵고, 실무에서 가장 널리 쓰입니다

모델 이름 뒤에 q4_K_M 같은 표기가 붙어 있으면 그게 양자화 방식입니다. 잘 모르겠으면 Q4를 고르시면 됩니다.

통합 메모리를 전부 쓸 수 있는 건 아닙니다

맥의 통합 메모리는 CPU와 GPU가 나눠 씁니다. macOS는 기본적으로 전체의 약 75%까지만 GPU에 할당합니다. 나머지는 시스템과 다른 앱 몫입니다.

총 메모리GPU 가용실제로 올릴 수 있는 모델
16GB약 12GB8B (4.4GB) 여유 · 14B (7.7GB) 가능
32GB약 24GB30B (16.5GB) 까지
64GB약 48GB70B (38.5GB) 도 가능
128GB약 96GB70B 여유롭게 · 여러 모델 동시 상주

브라우저에 탭을 수십 개 띄워둔 상태라면 이보다 더 빠듯해집니다. 큰 모델을 돌릴 때는 다른 앱을 정리하는 편이 낫습니다.

모델 파일 크기가 곧 메모리 사용량은 아닙니다

여기까지가 모델 가중치 얘기입니다. 그런데 실제로 돌려보면 이보다 더 씁니다. 대화 내용을 기억하기 위한 KV 캐시가 따로 필요하기 때문입니다.

M1 Max 32GB에서 직접 재봤습니다.

모델디스크 용량실제 메모리 점유차이
qwen3:8b5.2GB10GB+4.8GB
gemma4:26b17GB17GB

컨텍스트 32K 기준. ollama ps 명령으로 확인한 실제 값입니다.

8B 모델이 두 배를 쓰고 있습니다. 컨텍스트를 32,768 토큰으로 잡으면 KV 캐시만 약 4.8GB가 붙기 때문입니다. 컨텍스트를 늘릴수록 이 값도 함께 커집니다.

컨텍스트추가로 필요한 메모리 (8B 기준)
4K약 0.6GB
8K약 1.2GB
16K약 2.4GB
32K약 4.8GB
64K약 9.6GB

실측값에서 환산한 대략치입니다. 모델 구조에 따라 달라집니다.

긴 문서를 통째로 넣는 작업이라면 컨텍스트를 크게 잡아야 하는데, 그만큼 메모리가 더 듭니다. 메모리가 빠듯하다면 컨텍스트를 줄이는 것이 큰 모델을 포기하는 것보다 나은 선택일 때가 많습니다.

ollama ps        # 지금 메모리에 올라간 모델과 실제 점유량 확인


마치며

애플 실리콘 로컬 AI는 오랫동안 “되긴 되는데 느리고 손이 많이 간다”는 평가에 머물렀습니다. 2026년 봄의 세 가지 변화 — Ollama의 MLX 전환, 성숙해진 Foundation Models, OpenAI 호환 런타임 — 이 동시에 도착하면서, 이제는 내 맥 한 대로 진지한 AI 워크로드를 돌리는 게 현실이 됐습니다.

시작은 단순합니다. 내 칩과 메모리를 확인하고, 위 표에서 맞는 모델을 골라 ollama run 한 줄을 치는 것. 거기서부터 나만의 프라이빗 AI 스택이 만들어집니다.


이 글은 Marco Kotrotsos의 “The Local AI Stack for Apple Silicon, Now With Superpowers”(Medium, 2026년 5월)와 해당 글의 정리표를 토대로 작성했습니다. 성능 수치·릴리스 정보는 2026년 6월 기준이며, 빠르게 변하는 분야이므로 도입 전 최신 버전과 벤치마크를 확인하시길 권합니다.

함께 읽으면 좋은 글들

14살 때 100만원으로 시작한 주식투자, 8000% 수익 올린 아이돌

14살 때 100만원으로 시작한 주식투자, 8000% 수익 올린 아이돌

이 블로그의 저자입니다.

← 이전 글
성공한 리더들이 즐겨 인용하는 사자성어 5가지, 그 리더십 의미는?

관련 글