Gemma 4 12B를 MacBook Air에서 로컬로 돌리기
TL;DR — 같은 Gemma 4 12B 로컬 서빙을 기존 맥 스튜디오 글에선 Mac Studio M4 Max / 64GB로 끝냈다. 이 후속편은 그 구성을 반으로 깎아 다시 돌린 기록이다 — 메모리 절반(32GB), GPU 1/4(10코어), 게다가 냉각 팬도 없는 MacBook Air M4. 결론부터: 버틴다. 8-bit가 32GB에 스왑 0으로 들어간다(품질 우선 양자화 안 깎아도 됨). 대신 데스크톱엔 없던 노트북만의 제약 두 가지가 따라온다 — ① 속도는 GPU 코어 수에 비례해 깎여 ~7.7 tok/s(기존 글의 1/4), ② 팬이 없어 지속 고부하에선 ~30% 스로틀(7.6→5.4 tok/s). 데스크톱 Mac과 본질적으로 갈리는 건 ②뿐이다.
1. 무엇이 같고, 무엇이 달라졌나
목표는 기존 글과 동일하다: Gemma 4 12B를 항상 떠 있는 OpenAI 호환 로컬 서버로(재부팅·크래시에도 알아서 살아나게) 운용한다. 런타임도 같은 MLX, 모델도 같은 mlx-community/gemma-4-12B-it-8bit, 스택 버전(mlx 0.31.2 · mlx-vlm 0.6.1)까지 사실상 동일하다. 바뀐 건 장비 하나뿐이고, 그 차이가 이 글의 전부다.
| 항목 | 이 글: MacBook Air | 기존 글: Mac Studio |
|---|---|---|
| 모델명 | MacBook Air (Mac16,12) | Mac Studio (Mac16,9) |
| 칩 | Apple M4 (CPU 10코어) | M4 Max (16코어) |
| GPU | 10코어, Metal 4 | 40코어 |
| 메모리 | 32 GB 통합메모리 | 64 GB |
| 냉각 | 없음 (팬리스, 패시브) | 능동 냉각(팬) |
| OS | macOS 26.5 (25F71) | macOS 26.5 |
런타임·모델·버전이 같으니 하드웨어를 뺀 변수는 0이다. 그래서 세 가지를 미리 의심하고 들어갔다.
- 32GB로 12B 8-bit가 스왑 없이 들어갈까 — 모델만 ~13GB.
- GPU 1/4(10 vs 40)가 속도를 얼마나 깎을까.
- 팬이 없는데 지속 부하를 버틸까.
통합메모리라 별도 VRAM 없이 32GB 전체를 모델에 쓸 수 있다는 구조는 기존 글과 동일하다. 아래에서 이 셋을 하나씩 실측으로 답한다.
2. 설치 — 다른 점만
설치 절차 자체는 기존 글과 같다(uv로 Python 3.12 격리 환경 → mlx mlx-lm mlx-vlm 설치 → hf download mlx-community/gemma-4-12B-it-8bit). 이 머신에서만 달랐던 두 가지만 적는다.
- 시스템 Python이 3.13이라(기존은 3.14) 그대로 둬도 무방했지만, 휠 호환을 위해 동일하게 3.12 격리 환경을 만들었다.
- 8-bit를 고집한 이유가 다르다. 64GB에선 8-bit가 당연한 선택이었지만, 32GB에선 4-bit(~7GB)로 안전하게 도망갈 수도 있었다. 그런데도 8-bit(~13GB)를 택한 건 “절반 사양에서도 품질 우선 양자화가 스왑 없이 들어가나” 가 이 글의 질문이기 때문이다. 결론을 당겨 말하면 — 들어간다.
설치된 스택(실측): mlx 0.31.2 · mlx-lm 0.31.3 · mlx-vlm 0.6.1 · transformers 5.10.2 · huggingface-hub 1.18.0. 버전까지 기존 글과 같아 비교의 공정성이 보장된다.
3. 속도 — GPU 코어 수에 비례해 깎인다
텍스트·이미지·오디오 3종이 다 도는지는 기존 글에서 확인했고, 모델·런타임이 같으니 이 머신에서도 당연히 다 동작한다(직접 재확인했고 결과도 같았다). 다만 한 가지: 오디오에 "in English"를 줘도 출력은 여전히 한글 음차로 떨어졌다 — 기존 글이 “영어로 지정하면 로마자”라 적은 것과 갈리는 지점인데, 머신과 무관한 그리디 디코딩의 특성이다. 즉 세 종류 모두 기존과 동일하게 동작하고, 새로 볼 건 속도 한 가지다.
| 항목 | 이 글: MacBook Air | 기존 글: Mac Studio |
|---|---|---|
| 텍스트 | 7.68 tok/s | 32.3 tok/s |
| 이미지 | 7.64 tok/s | 32.9 tok/s |
| 오디오 | 7.29 tok/s | 33.5 tok/s |
| prefill | 69–75 tok/s | 276–442 tok/s |
생성 속도는 세 종류 모두 ~7.3–7.7 tok/s로 일관됐다. 기존 글의 32–33 tok/s 대비 정확히 약 1/4 — GPU 코어 수 차이(10 vs 40)가 속도에 거의 그대로 반영됐다. (peak 메모리는 ~13GB로 기존과 동일.)
4. 32GB에서 얼마나 쓰고, 얼마나 남나
기존 64GB 글의 결론은 “12B는 가벼운 짐, 한두 개 더 띄울 여유”였다. 절반인 32GB에선 그 여유가 어떻게 바뀌는지가 관건이다.
| 자원 | Idle (상주만) | 추론 중 (실측) |
|---|---|---|
| 메모리 풋프린트 | ~13 GB | ~13.1 GB (peak) |
| GPU | ~0% | 100% (10코어 풀가동) |
| CPU | 0.3% | ~29% (MLX는 GPU 바운드) |
| 스왑 | 0 B | 0 B |
| 속도 | — | 7.3–7.7 tok/s |
idle엔 GPU·CPU 거의 0, 요청 순간만 GPU 100%로 당겨 쓰고 끝나면 돌아가는 패턴은 기존 글과 똑같다. 시스템 메모리는 idle ~70% free, 추론 중에도 51% free, 스왑은 내내 0이었다.
함정 하나:
ps의 프로세스 RSS는 6.5GB로 작게 잡힌다. MLX가 가중치를 Metal/wired 버퍼로 올려 RSS에 다 안 잡히기 때문 — 실제 풋프린트는 mlx가 보고하는 Peak ~13GB가 정확하고, 시스템 차원에서도 스왑은 0이었다.
정리하면 (여기서 64GB와 갈린다): 12B 8-bit는 32GB의 ~41%(13GB) 를 쓴다(64GB에선 ~22%였다). 스왑 0으로 한 개는 쾌적하지만, 두 번째 12B를 더 띄우는 건 무리(26GB+OS → 스왑 위험). 멀티 인스턴스나 26B MoE 업그레이드는 64GB 머신의 몫이고, 절반 사양 노트북의 현실적 상한은 “12B 한 개를 쾌적하게” 다.
5. 24/7 상주 — 노트북이라 새로 생기는 숙제
mlx_vlm.server + launchd LaunchAgent로 부팅 자동시작·크래시 자동복구를 거는 방법(plist, launchctl 명령)은 기존 글의 것을 그대로 쓰면 된다 — 경로만 ~/gemma4-mlx/.venv로 바뀐다.
실제로 kill -9로 죽여보니 launchd가 2초 만에 새 PID로 재기동했다. 부팅 자동시작 + 크래시 복구는 데스크톱과 동일하게 동작한다.
다른 건 노트북이라 새로 생기는 변수다. Mac Studio엔 없던 클램쉘(덮개 닫기)·잠자기가 상시 서버의 적이다. 24/7로 굴리려면 전원을 연결하고 pmset으로 잠들지 않게 잡거나, 클램쉘 상시 가동을 따로 설정해야 한다. 데스크톱 Mac에는 없는, 노트북 특유의 숙제다.
6. 노트북이 데스크톱과 진짜로 갈리는 지점 — 스로틀링
여기가 이 글의 핵심이고, 기존 글에는 아예 없던 이야기다. Mac Studio는 능동 냉각이라 “18초 풀로드에도 스로틀 0”이었다. 그럼 팬이 없는 MacBook Air는?
모델을 한 번 로드하고 백투백으로 7.5분간 쉬지 않고 추론을 돌리며 라운드별 생성 속도를 기록했다.
| 누적 시간 | 생성 속도 |
|---|---|
| 40초 | 7.60 tok/s (시원할 때) |
| 168초 | 3.78 tok/s (최저, 피크의 절반↓) |
| 452초 | 5.37 tok/s (열포화 후 정착) |
처음 시원할 땐 7.6 tok/s가 나오지만, 1~3분 사이 칩이 달궈지며 3.8 tok/s까지 급락했다가 ~5.4 tok/s로 정착했다. 피크 대비 약 30% 하락. 단발·간헐 사용이면 7.6 tok/s를 누리지만, 쉴 새 없이 때리는 24/7 고부하라면 5.4 tok/s가 현실적인 지속 속도다. 능동 냉각 데스크톱에는 없는, 팬리스 노트북이 치러야 하는 대가다.
7. 그렇다면 — 노트북엔 “상시”보다 “필요할 때만”
여기서 한 발 물러서면 질문이 하나 생긴다. 노트북에 24/7 상시 서버가 정말 맞는 그림인가?
데스크톱 Mac Studio는 능동 냉각 + 상시 전원 + 잠들지 않는 기기라 “띄워놓고 잊기”가 자연스럽다. 하지만 MacBook Air는 위에서 본 대로 ① 클램쉘·잠자기를 억지로 막아야 하고, ② 팬이 없어 상시 부하엔 스로틀이 걸리며, ③ 들고 다니는 기기라 배터리·발열도 무시 못 한다. 상시 서버와는 결이 잘 안 맞는 제약들이다.
그래서 노트북에선 KeepAlive로 영구 상주시키기보다 필요할 때만 켜고, 안 쓰면 내리는 on-demand 운용이 더 어울린다고 본다.
- 쓸 때만 띄우기: 평소엔 내려두고 작업을 시작할 때 깨운다. 첫 요청에 서버를 띄우고 일정 시간 idle이면 스스로 내려가는 얇은 래퍼를 앞에 두면, 안 쓸 때 전력·발열이 사실상 0이 된다.
- 다 쓰면 내리기:
launchctl bootout한 줄, 또는 idle 타임아웃으로 자동 종료.
게다가 스로틀링은 결국 “쉴 새 없이 때릴 때” 만 걸리는 것이라, 단발·간헐 사용에 맞춰 필요할 때만 띄우면 노트북은 시원할 때의 7.6 tok/s를 그대로 누리면서 발열·배터리 부담은 피한다.
한 줄로: “24/7 상시”는 늘 깨어 있는 데스크톱의 미덕이고, 노트북에는 “필요할 때 즉시”가 더 맞는 미덕일 수 있다.
8. 마치며
이틀 전 나온 12B 멀티모달 모델이, 데스크톱도 아닌 얇은 팬리스 노트북에서 · 완전 로컬로 돌아간다. 기존 맥 스튜디오 글을 절반 사양에서 재현하며 새로 확인한 것만 추리면:
- 메모리: 32GB에 12B 8-bit가 스왑 0으로 상주(~13GB, 41%). 품질 우선 양자화를 굳이 포기할 필요 없었다. 단, 두 번째 인스턴스는 무리다.
- 속도: GPU 코어 1/4 → 속도도 ~1/4(7.7 vs 32 tok/s).
- 냉각: 팬리스라 지속 부하 시 ~30% 스로틀(7.6→5.4). 데스크톱 Mac과 본질적으로 갈리는 유일한 지점.
- 운영: 부팅 자동시작·크래시 복구(2초)는 동일. 단 노트북은 클램쉘·잠자기를 따로 잡아야 하고, 애초에 24/7 상시보다 필요할 때만 띄우는 on-demand가 더 맞을 수 있다.
한 줄로: “노트북에서 멀티모달”은 마케팅이 아니라 사실이다. 다만 팬 없는 노트북이라면 — 24/7로 줄곧 굴려 발열에 깎이느니, 필요할 때만 띄워 시원한 7.6 tok/s를 누리는 쪽이 더 좋은 방향이다.
Fri, 05 Jun 2026 10:00:00 +0900환경: MacBook Air M4 · 32GB · 10코어 GPU · macOS 26.5 / Gemma 4 12B (mlx-community 8-bit) · mlx-vlm 0.6.1 · 측정일 2026-06-05