맥북 Air M5에서 로컬 LLM 돌리기

발열이라면 질색이라 시작한 테스트다. 32GB M5 맥북에어(팬리스)에서 로컬 LLM을 발열 없이 적당히 굴릴 수 있는 세팅을 찾으려고 직접 재봤다. 결론부터 적으면, 진짜 벽은 발열이 아니라 메모리였다.

TL;DR

• Apple Silicon에는 GPU 클럭을 직접 제한하는 도구가 없다. macOS가 주는 유일한 "스로틀 스위치"는 저전력 모드뿐이다.
• 저전력 모드를 켜면 생성 속도가 절반 안팎(2.2배)으로 줄지만, 팬리스 에어에서도 발열이 완전히 평탄하게 유지된다. 끄면 속도는 2배 넘게 뛰는 대신, 연속 부하가 쌓이면 실제 스로틀링 곡선(피크 대비 최대 -29%)이 나타난다.
• 큰 모델이 못 쓸 물건이 되는 건 발열이 아니라 메모리 때문이었다. 32GB 에어에서 dense 27B(17GB)는 2.7 tok/s로 추락했는데, 사후 진단해 보니 원인은 스왑이 아니라 메모리 대역폭 한계(모델이 100% GPU에 올라가 있는데도 매 토큰 17GB를 읽어야 함)였고, 스왑은 시스템 자원이 부족해진 증상이었다. 발열은 오히려 전혀 없었다 — GPU가 메모리를 기다리느라 놀아서다.
• 결론 공식: 모델 크기는 램이 정하고(파일 ~14GB 이하 권장), 발열은 저전력 모드로 잡는다. 최적점은 dense 대형이 아니라 중형 MoE. → 실제로 gpt-oss:20b(20B MoE, 13GB)가 29 tok/s로 평탄하게, 발열 없이 돌며 이 가설을 확인했다.
• 다만 그 저전력은 LLM 전용 레버가 아니라 기기 전체 스위치다. 켜면 웹·JS 연산도 1.9배 느려지고 화면 프레임이 60→30fps로 반토막 난다. 대가가 제일 아프게 느껴지는 지점이 이 프레임이라, 아무도 화면을 안 보는 밤에는 그 대가가 0이다(4-6).

먼저, 용어 4개만 (30초)

본론에 들어가기 전에 아래만 알면 된다.

• 파라미터(B) — 모델의 "뇌 크기". 클수록 똑똑해질 여지가 있지만 램·전기를 그만큼 먹는다.
• dense vs MoE — dense는 단어 하나 만들 때 뇌 전체를 쓰고, MoE(전문가 혼합)는 매번 필요한 전문가만 깨운다. 그래서 MoE는 총 크기는 커도 실제 일하는 몫(활성 파라미터)이 작아 빠르고 시원하다.
• 양자화(Q4 등) — 모델을 눌러 담아 용량을 1/3~1/4로 줄이는 압축. 품질은 조금 손해 보지만 노트북에서 돌리는 핵심 비결이다.
• tok/s — 초당 만들어내는 단어조각 수. 사람이 읽는 속도가 대략 5~10 tok/s라, 20 정도면 충분히 실용적이다.

1. 환경

계측 로거는 sudo 없이 얻을 수 있는 지표만으로 구성했다:

• 서멀 상태 — Swift ProcessInfo.thermalState (0 nominal / 1 fair / 2 serious / 3 critical). macOS가 판단하는 공식 발열 압박 단계.
• 배터리 온도 — ioreg AppleSmartBattery의 Temperature.
• 메모리 프레셔 & 스왑 — sysctl 기반.

참고: 이 머신에서는 pmset -g therm이 연속 스로틀 지표(CPU_Speed_Limit)를 반환하지 않았다. GPU 전력(W)까지 보려면 powermetrics(sudo 필요)가 있어야 하는데, 위 지표만으로도 발열 경향은 충분히 잡혔다.

2. 문제

팬리스 맥북에어는 열을 배출할 팬이 없다. 그래서 로컬 LLM처럼 GPU를 오래 붙잡는 워크로드를 돌릴 때 자연스레 세 가지 의문이 생긴다.

1. 발열을 통제할 방법이 있나? — NVIDIA의 nvidia-smi -pl 같은 전력 상한 도구가 macOS엔 없다. 확인해 보니 Apple Silicon에서 사용자가 만질 수 있는 유일한 레버는 저전력 모드(시스템 설정 → 배터리)뿐이었다. SoC 전체의 클럭 상한을 낮추는 방식이라 CPU·GPU가 함께 눌린다.
2. 저전력 모드는 실제로 얼마나 효과가 있나? 속도를 얼마나 내주고 발열을 얼마나 버는가?
3. 32GB 에어의 모델 크기 상한은 어디인가?

이걸 A/B로 실측했다.

3. 테스트 방법

• 모델 3종
• lfm2.5:8b — MoE, 활성 파라미터 ~1.5B (파일 5.2GB)
• qwen3:4b — dense 4B (파일 2.5GB)
• qwen3.6:27b — dense 27B, Q4 양자화 (파일 17GB) ← 메모리 상단 테스트용
• 부하 — 모델당 3분 이상 쉬지 않고 800토큰씩 연속 생성, 라운드마다 생성 속도(tok/s) 기록
• A/B — 저전력 모드 ON / OFF 각각 실행
• 안전장치 — 매 라운드 후 서멀 상태·배터리 온도 점검, critical이거나 배터리 40°C 초과 시 자동 중단 (실제로는 한 번도 발동 안 함)

4. 테스트 결과

4-1. 저전력 모드 ON vs OFF — 속도

저전력 모드는 속도를 딱 절반 남짓으로 눌렀다. 클럭 캡이 걸리니 예상대로다.

4-2. 저전력 모드 ON vs OFF — 발열

저전력 ON에서는 내내 속도가 평평했다. 클럭이 애초에 발열 한계 아래로 눌려 있어 스로틀링이 걸릴 일 자체가 없다. OFF에서는 부하가 쌓이자 서멀 상태가 fair로 올라갔고, 특히 열이 축적된 뒤에 돌아간 2번째 모델(qwen3:4b)은 피크 대비 -29%까지 단조 하락하는 뚜렷한 스로틀링 곡선을 그렸다(테스트 종료 시점에도 하락 중 — 더 오래 돌렸으면 더 떨어졌을 것이다). 그렇게 스로틀이 걸린 바닥(30.0 tok/s)도 저전력 ON의 평균(17.9)보다 1.7배 빠르다. 그리고 critical 근처도 안 갔고 배터리도 31°C에 그쳤다. 손으로 만지면 확실히 따뜻하지만, 하드웨어가 위험한 수준은 전혀 아니다.

왜 손상 걱정을 안 해도 되나: 스로틀링 자체가 보호 장치다. 칩은 위험 온도에 닿기 전에 스스로 클럭을 낮추고, 그래도 안 되면 강제로 슬립한다. 최악이라 봤자 느려질 뿐, 고장 나지 않는다.

4-3. 메모리 상단 테스트 — dense 27B (17GB)

메모리 상단에서는 그림이 완전히 달라졌다.

17GB 모델 + KV 캐시가 32GB를 조이면서 스왑까지 밀렸다. 속도가 2.7 tok/s로 추락한 원인은 발열이 아니라 메모리 병목이었다. 프롬프트 처리 속도도 소형 모델의 약 1/70 수준이었다. GPU가 메모리를 기다리느라 놀아서, 발열은 오히려 전혀 없었다. "느려서 시원한" 상태다.

사후 진단으로 원인을 더 파봤다. 모델을 재로드해 보니 100% GPU에 올라가 있었다. "일부가 CPU로 밀려서" 느린 게 아니라, 대역폭 자체가 병목이었다. 저전력을 끄고 다시 재니 6.6 tok/s로, 저전력 ON(2.7) 대비 딱 2.4배였다. 소형 모델들의 클럭캡 배율(2.2~2.4배)과 똑같다. 스왑이 675MB일 때나 3.1GB일 때나 속도는 이 배율 그대로였다. 27B의 느림은 "매 토큰 17GB 가중치를 읽어야 하는 메모리 대역폭 한계 × 저전력 클럭캡"의 곱이었다. 스왑은 원인이 아니라 증상이었다. 감속을 만들 만한 용의자(서멀·스왑·클럭캡·대역폭) 중 서멀과 스왑은 측정으로 무죄가 나온 셈이다.

진짜 급소는 파일 크기라는 숫자 자체가 아니다. Metal이 GPU에 내주는 램(32GB 중 약 21GB) 안에 모델과 KV 캐시가 다 들어가느냐다. 27B는 여기서 넘쳤고, 넘치는 순간 매 토큰 가중치를 전부 다시 읽어 오느라 메모리 대역폭이 속도를 결정한다.

즉 이 에어에서 dense 27B는 "돌아는 가지만 못 쓰는" 영역이다(저전력을 꺼도 6.6 tok/s). 그리고 이 문제는 저전력 모드나 발열 관리로 해결되지 않는다 — 병목이 클럭이 아니라 메모리 대역폭이기 때문이다.

4-4. 곁다리 발견 — MoE vs dense

lfm2.5:8b(8B 파라미터)가 qwen3:4b(4B 파라미터)보다 파라미터는 2배 많은데 속도는 2.3배 빨랐다. MoE라서 매 토큰 켜지는 활성 파라미터가 ~1.5B뿐이라 연산량이 적기 때문이다. 팬리스 에어에서 "저스펙 고성능"의 전형이고, 발열·속도 양쪽에서 가장 유리한 구조다.

4-5. "쓸만한 상단" 검증 — gpt-oss:20b (MoE, 파일 13GB)

앞의 결과에서 세운 가설("dense 대형이 아니라, 램에 여유 있게 들어가는 중형 MoE가 최적점")을 직접 확인했다. gpt-oss:20b는 20B MoE(활성 파라미터 ~3.6B), 파일 13GB로 32GB 램에 여유 있게 들어간다. (저전력 OFF 조건 — 4-1의 OFF 수치와 직접 비교됨)

가설이 그대로 맞았다. 20B 모델인데도 활성 파라미터가 작아 29 tok/s(사람 읽는 속도의 수 배)가 나왔고, 3분 내내 속도가 평탄했으며 발열도 미미했다. 같은 저전력 OFF 조건에서 dense 27B가 메모리 병목으로 6.6 tok/s였던 것과 극명하게 대비된다. 파라미터 수는 20B로 더 크지만, "실제로 램에 들어가고 활성 파라미터가 작다"는 두 조건 덕분에 같은 조건에서 4.5배 빠르다(29.4 대 6.6).

4-6. 저전력 모드는 LLM 스위치가 아니었다

여기까지는 저전력 모드를 LLM의 속도 조절 장치로만 다뤘다. 그런데 그 스위치는 LLM 옆에 달려 있지 않다. 시스템 설정 → 배터리에 달려 있고, 누르면 SoC 전체가 눌린다(2장). 브라우저도 문서도 화면도 같이 눌린다는 뜻인데, 앞 절들은 그 대가를 재지 않았다. 그래서 다음 날 같은 기기에서 LLM을 빼고 일상 작업만으로 A/B를 다시 돌렸다.

측정 조건 — 2026-07-19 단일 세션 연속 측정. 전 구간 배터리 전원(충전기 미연결)이고, 저전력 ON/OFF는 매 측정마다 pmset으로 실측 확인했다. 브라우저는 Safari.

연산 벤치 2종은 1.9배 느려진다.

성격이 전혀 다른 두 벤치가 1.95와 1.92로 겹쳤다. 문서 작업이 그보다 덜 느려진 건 디스크 읽기나 앱 로딩처럼 CPU 속도와 상관없는 구간이 섞여 있어서다. 문서 작업만 따로 보면 속도는 1.58배만 잃는데 전력 쪽은 뒤에 나올 1.87배 차이라, 같은 일을 끝내는 데 드는 전기는 저전력 쪽이 15%쯤 덜 든다 — 이 구간에 한해서는 남는 장사다.

이 숫자들은 LLM을 잰 게 아니다. 웹 벤치와 문서 작업, 그리고 화면이다. "저전력이 LLM을 1.9배 늦춘다"로 읽으면 안 된다. 말할 수 있는 건 여기까지다. 4-1에서 LLM으로 잰 2.16×·2.17×와, 서로 아무 관계도 없는 워크로드로 잰 1.92~1.95×가 비슷한 자리에 떨어졌다. 같은 원인이라는 증명이 아니라, 두 번 재봤더니 두 번 다 "절반 남짓"이 나왔다는 관찰이다.

진짜 대가는 다른 데서 치른다 — 프레임레이트.

디스플레이 하드웨어는 양쪽 다 60Hz다. 화면 주사율이 내려간 게 아니라 브라우저가 화면을 그릴 기회를 절반만 받는다. 원리가 전혀 다른 두 계측이 같은 답을 냈으니 계측 실수로 보긴 어렵다.

이 기기는 2880×1864 60Hz 고정, ProMotion 없음이다. ProMotion 탑재 맥(120Hz)은 저전력 모드에서 주사율 자체가 60Hz로 내려가는 별도 효과가 있어, 이 30fps 발견을 그대로 옮기면 안 된다.

MotionMark는 프레임레이트 감지 결과만 썼다. 점수는 ON/OFF의 타깃 프레임이 서로 달라 직접 비교가 성립하지 않는다.

왜 연산 1.9배보다 이쪽이 아픈가. 연산이 두 배 느려져도 작업이 짧으면 모른다. PDF 내보내기는 0.93초에서 1.19초가 됐다. 0.26초 차이는 스톱워치를 들지 않고는 알 수 없다. 반면 프레임 반토막은 스크롤 한 번에 나온다. 벤치 점수는 못 느끼고 스크롤은 느낀다. 저전력을 켰을 때 "확 느려졌다"고 하는 그 느낌의 정체는 대개 여기다.

전력은 거의 1:1 맞교환이다.

연산 벤치 1.9배를 전력 1.87배와 바꾼다. 일이 온전히 CPU 속도에 매여 있는 한, 저전력 모드는 같은 일을 더 알뜰하게 해주는 장치가 아니라 초당 하는 일을 줄이는 장치다. 총량은 그대로 두고 그 총량을 더 얇게 펴서 오래 쓴다.

전력은 배터리 잔량(mAh)을 15초 간격으로 기록해 선형회귀로 추정했다. ON 구간 27.4분·OFF 구간 13.3분으로 작업 구성과 길이가 완전히 같지는 않으니(유휴 비율 차이) 방향은 신뢰하되 배율은 근사치로 볼 것.

그리고 발열은 어느 쪽에서도 없었다. 서멀 상태는 저전력 ON 110회·OFF 54회 샘플이 전부 nominal이었고, 배터리 온도 변화는 +0.1°C와 +0.8°C였다. GPU 벤치를 8분 연속 돌린 구간까지 포함해서 그렇다. 4-2에서 LLM을 3분 남짓 돌렸을 때 fair까지 올라갔던 그 기기가, 웹서핑과 문서 편집으로는 데워지지 않는다. 발열이 걱정돼 저전력을 켜는 사람이 있다면 적어도 일상 작업에서는 나지도 않은 불을 끄고 있는 셈이다.

참고로 저전력을 켠 이 기기의 웹 반응성(24.3)은 Speedometer 한 축에서 M2 에어(41.9, magiclasso.co 3회 평균)에는 못 미치고 M1 에어대(26.4~26.7)와 겹친다. 스위치 하나로 네댓 해쯤 뒤로 가는 셈인데, 돌아오는 데는 클릭 한 번이면 된다. 단 M1 수치는 포럼 자기보고라 같은 M1 에어에서도 18.5~26.7로 편차가 크다. "벤치 한 축에서 비슷하다"는 것이지 기기가 M1이 되는 건 아니다 — 메모리 대역폭도 화면도 미디어 엔진도 그대로 최신이다.

그래서 삽화 생성 같은 배치 작업을 밤에 저전력으로 돌리면 어떤가.

밤새 돌릴 일이 있으면 저전력을 켜두는 쪽이 알뜰해 보인다. 데이터는 그 직관을 지지하지 않는다. 단 그 데이터는 웹·문서 작업에서 나온 것이다. 연산 벤치 쪽에서는 성능과 전력이 거의 1:1로 붙어 있었고, 이 1:1이 이미지 생성에도 그대로 간다면 작업 100장당 들어가는 전기는 양쪽이 거의 같다. 그러면 저전력 ON은 전기를 아껴주는 게 아니라 시간을 두 배로 쓴다.

조건절을 단 이유를 밝혀야겠다. 이미지 생성은 저전력을 끄고 재본 적이 없다. 켠 채로 장당 66초가 나온 기록이 있을 뿐, 끈 쪽도 그때의 전력도 이 데이터엔 없다. 워크로드가 다르면 배율도 달라진다는 건 방금 위에서 연산 1.9배와 문서 1.58배로 확인한 참이다. 그래놓고 여기서만 슬쩍 넘어갈 수는 없다. 애초에 충전기를 꽂고 자는 사람이라면 배터리를 아낄 이유 자체가 없기도 하다.

그런데 결론은 반쯤 맞다. 이유가 다를 뿐이다. 저전력에서 제일 아픈 대가는 연산이 아니라 프레임 반토막, 눈에 보이는 부드러움이었다. 그리고 밤에는 그 화면을 아무도 안 본다. 대가가 0이다. 밤은 저전력을 켜야 할 시간이 아니라, 켜든 끄든 아무래도 상관없는 유일한 시간대다.

여기에 정직하게 붙일 구멍이 하나 있다. 4-2의 스로틀링 곡선(피크 대비 -29%, 측정 종료 시점에도 하락 중)은 3분 남짓 부하 기준이다. 여덟 시간 연속 부하가 어떤 곡선을 그리는지는 이 데이터에 없다. 저전력을 끄고 밤새 돌린 쪽이 스로틀에 눌려 결국 켠 쪽과 비슷해질 가능성은 열려 있다. 그래서 "야간 배치는 끄는 게 낫다"까지는 못 간다. 재려면 진짜로 밤을 새워야 하는데, 이 테스트는 그 정도로 성실하지 않았다.

"차이가 이렇게 큰데 LLM을 포기해야 하나." 포기 대상이 잘못됐다. 4-3과 4-5의 결론 — 벽은 램이고 최적점은 중형 MoE — 은 저전력과 무관하게 그대로 서 있고, 저전력은 애초에 그 벽을 건드리지도 못한다. 저전력을 켤 합리적인 이유는 하나로 좁혀진다: 지금 남은 배터리로 더 오래 버텨야 할 때.

전체 비교 (저전력 OFF 기준)

5. 정리

이번 실측으로 나온 32GB 팬리스 에어의 로컬 LLM 공식:

모델 크기는 램이 정하고(파일 기준 ~14GB 이하 권장), 발열은 저전력 모드로 잡는다.

여기서 "~14GB"는 편의를 위한 어림선일 뿐, 측정된 임계값은 아직 없다. 진짜 급소는 Metal 워킹셋(32GB 중 약 21GB) 안에 모델과 KV 캐시가 드느냐이고, 컨텍스트 길이나 양자화가 달라지면 그 선도 함께 움직인다.

• 저전력 모드는 발열/속도 레버다. 소형·MoE 모델이면 저전력 ON으로도 40 tok/s가 나와 "발열 없이 쓸만"이 성립한다.
• 다만 그 레버는 LLM에만 걸리지 않는다. 켜는 순간 기기 전체가 같이 눌려 웹 연산이 1.9배 느려지고, 무엇보다 화면 프레임이 60fps에서 30fps로 반토막 난다(4-6). 대가는 LLM 바깥에서 치러진다.
• 하지만 저전력 모드는 메모리 병목엔 무력하다. 큰 모델을 쓸만하게 만드는 건 저전력이 아니라 "램에 여유 있게 들어가는 크기"를 고르는 것이다.
• 따라서 실용 상한은 dense 대형이 아니라 중형 MoE(활성 파라미터가 작은 모델)다.

온디바이스 AI가 추론 비용을 클라우드 사용료에서 내 손안의 실리콘 구매비로 옮기는 흐름이라면(온디바이스 AI: 칩이 아니라 비용과 사법권이 경계를 긋는다), 이 글은 그 실리콘이 실제로 감당하는 벽을 한 대에서 재본 기록인 셈이다.

실용 권장

이 머신(M5/32GB 팬리스 에어)에서 로컬 LLM을 쓴다면:

• 일상용 최적점 — gpt-oss:20b 같은 중형 MoE. 29 tok/s로 충분히 빠르고 발열·메모리 모두 여유. 품질과 속도의 균형점.
• 최고 속도 — lfm2.5:8b 같은 소형 MoE. 90 tok/s. 가볍고 빠르다.
• 피해야 할 것 — dense 20B+ (27B 등). 램을 넘겨 Metal 워킹셋 밖으로 밀리면 답이 안 나온다.
• LLM을 오래 돌릴 때 발열이 신경 쓰이면 — 저전력 모드 ON. 속도는 절반이지만 위 모델들 모두 여전히 읽기 속도 이상(소형 MoE는 40 tok/s대)을 유지하고, 발열은 완전히 평탄해진다. 단 이 처방은 LLM 연속 부하 한정이다. 웹서핑·문서 편집 정도로는 저전력을 꺼도 애초에 열이 안 난다(4-6). 그리고 켤 때는 대가를 함께 치른다 — LLM만 얌전해지는 게 아니라 기기 전체가 같이 얌전해지고, 화면 프레임이 30fps로 떨어진다.
• 밤에 배치로 돌릴 때 — 켜도 되고 꺼도 된다. 아무도 화면을 안 보는 시간대라 저전력의 제일 큰 대가가 사라진다. 전기 쪽은 연산 벤치에서 성능:전력이 1:1로 나왔으니, 그게 이미지 생성에도 이어진다면 아껴지는 것 없이 시간만 두 배가 된다 — 다만 이미지 생성은 저전력을 끄고 재본 적이 없다. 굳이 고르라면 충전기를 꽂고 끄는 쪽 — 밤샘 연속 부하도 안 재봤다(아래 한계).

이 실측의 한계

이 결과를 과신하진 말자. 대부분 한 번씩만 돌린 측정(n=1)이고(27B는 1라운드뿐), GPU 전력(W)은 sudo가 필요한 도구라 이번엔 못 쟀다. 게다가 모델을 순서대로 돌려서 뒤 모델은 앞 모델이 데워 놓은 섀시에서 시작했다(순서 교란). 그래서 "A가 B보다 스로틀에 약하다"는 모델 간 비교는 이 데이터로 낼 수 없다. gpt-oss는 28분 쉰 식은 상태에서 시작했고, "평탄"은 3.5분 부하 기준이라 더 오래 돌리면 곡선이 나올 수도 있다. 스왑도 한 번 생기면 남아서, 뒤 테스트엔 증가분만 잡힌다. "3분대 부하 · 이 모델군 · 이 머신"까지가 이 글이 보증하는 범위다.

뒤에 덧붙인 저전력 측정(4-6)에는 한계가 하나 더 있다. 그건 LLM이 아니라 웹·문서·화면을 잰 것이고, 제일 긴 구간도 30분이 안 된다. 여덟 시간 연속 부하에서 저전력 ON과 OFF가 어떻게 갈리는지 — 야간 배치의 진짜 답 — 는 이 데이터에 없다. 재려면 밤을 새워야 하는데, 그러지 않았다.