로컬 LLM을 실행하려면 Mac 메모리가 얼마나 필요할까요?

Apple의 새로운 Mac Studio는 최대 512GB의 통합 메모리를 지원합니다. 언론에서는 이를 두고 프런티어급 모델을 책상 위에 올려놓을 수 있게 됐다고 표현합니다. 대체로 맞는 말이지만, 이는 대부분의 Mac 구매자가 애초에 묻지 않는 질문에 대한 답이기도 합니다.

사람들이 실제로 묻는 질문은 더 좁고 더 실용적입니다. 내가 돌리고 싶은 것을 기준으로, 실제로 얼마나 많은 메모리를 사야 할까? 통합 메모리는 칩 패키지에 납땜되어 있습니다. 이 질문에 답할 기회는 결제 시점 단 한 번뿐이며, 그 답은 기기의 수명 내내 유효합니다.

다행히 이는 의견의 문제가 아니라 계산의 문제입니다. 이 글은 그 계산을 대신 해드립니다.

핵심 요약

• 두 가지 숫자가 모든 것을 결정합니다. 메모리 용량은 모델이 애초에 로드되는지를 결정하고, 메모리 대역폭은 텍스트를 얼마나 빨리 생성하는지를 결정합니다. 이 둘은 서로 독립적이며, 한 기기가 한쪽에서는 강하고 다른 쪽에서는 약할 수 있습니다.
• 가중치는 파라미터 수 × 파라미터당 바이트 수로 추정합니다. 4비트 양자화에서는 파라미터당 약 0.55바이트이므로, 70B 모델은 컨텍스트를 제외하고도 약 38GB가 필요합니다.
• macOS는 GPU가 RAM을 전부 사용하도록 허용하지 않습니다. iogpu.wired_limit_mb로 제어되는, 문서화되지 않은 상한선이 존재합니다. 32GB Mac이라고 해서 모델에 32GB를 다 쓸 수 있는 것은 아닙니다.
• Apple가 내세우는 대표 AI 수치는 텍스트 생성이 아니라 프롬프트 처리를 설명하는 것입니다. 두 작업은 병목 지점이 다릅니다. 표현을 꼼꼼히 읽어야 합니다.
• M5 Ultra의 용량 자체는 새로운 것이 아닙니다. M3 Ultra는 이미 2025년에 512GB를 제공했습니다. 바뀐 것은 대역폭입니다: 819GB/s에서 1.2TB/s로.

두 가지 숫자

AI용 Mac을 잘못 선택하는 경우는 거의 다 이 두 가지를 하나로 뭉뚱그려 생각하는 데서 비롯됩니다.

용량은 벽입니다. 모델과 그 컨텍스트가 메모리에 들어가지 않으면 아예 실행되지 않습니다. 시스템 RAM으로 흘려보낼 수 있는 개별 GPU와 달리, Apple 실리콘에는 우아한 성능 저하라는 것이 없습니다 — Mac에서는 통합 메모리가 곧 시스템 RAM이며, macOS가 GPU에 내주는 양을 넘어서는 순간 로드에 실패하거나 훨씬 느린 방식으로 대체됩니다.

대역폭은 속도 제한입니다. 토큰 하나를 생성하려면 밀집(dense) 모델은 전체 가중치 세트를 메모리에서 읽어야 합니다. 토큰마다 매번입니다. 즉 생성 속도의 이론적 상한선은 메모리 대역폭을 모델 크기로 나눈 값이며, GPU 코어를 아무리 늘려도 이 값은 바뀌지 않습니다.

그래서 200GB짜리 모델을 담을 수 있는 기기라도 실제로는 쓸 수 없게 느껴질 수 있고, 반대로 평범한 기기의 작은 모델이 즉각적으로 느껴질 수 있는 것입니다.

용량: 무엇이 들어가는가

가중치가 가장 큰 비중을 차지하며, 그 크기는 예측 가능합니다:

memory for weights ≈ parameters × bytes per parameter

파라미터당 바이트 수는 양자화 방식에 따라 달라집니다:

정밀도	파라미터당 바이트	일반적인 용도
FP16 / BF16	2.0	학습, 최대 정확도
8-bit (Q8)	~1.0	거의 무손실에 가까운 추론
4-bit (Q4_K_M)	~0.55	실용적인 기본값
3-bit	~0.42	눈에 띄는 품질 저하

4비트 K-quant는 스케일링 메타데이터를 포함하면 평균적으로 4비트를 살짝 웃돌기 때문에, 정확한 수치는 0.50이 아니라 0.55입니다. 이를 적용하면:

모델 크기	4-bit	8-bit	FP16
8B	4.4 GB	8 GB	16 GB
14B	7.7 GB	14 GB	28 GB
32B	17.6 GB	32 GB	64 GB
70B	38.5 GB	70 GB	140 GB
120B	66 GB	120 GB	240 GB
235B	129 GB	235 GB	—
400B	220 GB	400 GB	—
671B	369 GB	671 GB	—

여기에 컨텍스트를 더하기

KV 캐시는 대화 속 모든 토큰에 대한 어텐션 키와 값을 담고 있으며, 컨텍스트 길이에 비례해 선형으로 늘어납니다. 토큰당 크기는 아키텍처에 따라 크게 달라집니다 — 그룹 쿼리 어텐션(grouped-query attention)을 사용하는 모델은 이전 방식보다 훨씬 저렴합니다 — 하지만 실용적인 범위는 토큰당 0.1MB~0.5MB입니다.

32,000토큰 컨텍스트라면 가중치 위에 대략 3GB~16GB가 추가로 필요합니다. 128,000토큰이 되면 모델 자체보다 커질 수도 있습니다.

'들어갈 것 같은데' 실제로는 들어가지 않는 모델의 가장 흔한 원인이 바로 이것입니다. 긴 문서를 입력하거나 긴 대화를 유지할 계획이라면, 가중치 크기만 보고 요행을 바라지 말고 이 부분을 명시적으로 예산에 반영해야 합니다.

실용적인 공식

memory you need ≈ (weights) + (KV cache for your context) + 2–3 GB overhead

그런 다음 이를 macOS가 실제로 내어주는 양과 비교해야 합니다. 이는 상자에 적힌 숫자가 아닙니다.

아무도 말하지 않는 상한선

macOS는 시스템을 위해 통합 메모리 일부를 예약해두고, GPU가 고정(wire)할 수 있는 메모리 양에 상한을 둡니다. 이를 조절하는 것이 sysctl입니다:

$ sysctl iogpu.wired_limit_mb
iogpu.wired_limit_mb: 0

0은 자동을 의미합니다. Apple은 자동 값이 실제로 어떻게 계산되는지 문서화하지 않았고, 저 역시 임의로 공식을 지어내지는 않겠습니다 — 다만 커뮤니티의 측정 결과는 일관되게 전체 메모리의 약 65~75% 선을 가리키며, 기기가 클수록 더 큰 비율이 허용되는 경향이 있습니다.

실제로 구매를 고려할 만한 기기에서의 결과는 다음과 같습니다:

설치된 메모리	GPU가 대략 사용할 수 있는 양
16 GB	~10–12 GB
32 GB	~21–24 GB
64 GB	~42–48 GB
128 GB	~85–96 GB
512 GB	~340–384 GB

이 값을 직접 올릴 수 있습니다. 변경 사항은 즉시 적용되지만 재부팅하면 초기화됩니다:

# Allow the GPU to wire 28GB on a 32GB Mac
sudo sysctl iogpu.wired_limit_mb=28672

# Back to automatic
sudo sysctl iogpu.wired_limit_mb=0

이 값을 조정할 때는 주의해야 합니다. 여기서 가져가는 메모리는 모두 운영체제와 다른 모든 애플리케이션 몫에서 가져오는 것입니다. 전체 용량에 너무 가깝게 밀어붙이면 스와핑, 비치볼(무지개 커서), 메모리 부족으로 인한 강제 종료를 겪게 됩니다 — 그리고 빠른 SSD를 탑재한 Mac이라도, 메모리 압박 상태에서의 스와핑은 지속적인 쓰기 부하이기도 합니다. System has run out of application memory 대화 상자를 본 적이 있다면, 이런 경로로 발생했을 가능성이 있습니다.

합리적인 상한선은 전체 메모리에서 macOS와 다른 앱들을 위한 6~8GB를 뺀 값입니다. 이를 설정하고 모델을 돌리면서 활성 상태 보기(Activity Monitor)에서 메모리 압박 상태를 지켜보십시오. 압박 스파이크가 자주 보인다면, 저희 Mac 메모리 관리 가이드에서 진단 방법을 다루고 있습니다.

대역폭: 응답이 얼마나 빠른가

중요한 것은 이 추정치이며, 정확히 다음과 같습니다:

tokens per second ≈ (memory bandwidth × efficiency) ÷ weight size in bytes

효율(efficiency)은 이론상 최대 대역폭과 실제 추론 엔진이 달성하는 값 사이의 차이를 반영한 것입니다 — 잘 최적화된 런타임을 사용하는 Apple 실리콘에서는 대략 0.6에서 0.8 사이입니다. 아래에서는 0.7을 사용합니다.

이 수치들은 실제로 실행한 벤치마크가 아니라 공개된 대역폭 수치를 바탕으로 계산한 추정치입니다. 정확한 측정값이 아니라 대략적인 규모와 상대적인 순서로 참고하시기 바랍니다. 실제 수치는 런타임, 양자화, 컨텍스트 길이, 발열 상태에 따라 달라집니다.

4비트 밀집(dense) 모델의 생성 속도:

	M6 (170GB/s)	M5 Pro (307GB/s)	M5 Max (614GB/s)	M5 Ultra (1.2TB/s)
8B (4.4GB)	~27 tok/s	~49 tok/s	~98 tok/s	~190 tok/s
32B (17.6GB)	~7 tok/s	~12 tok/s	~24 tok/s	~48 tok/s
70B (38.5GB)	들어가지 않음	~6 tok/s	~11 tok/s	~22 tok/s
120B (66GB)	들어가지 않음	들어가지 않음	~7 tok/s	~13 tok/s

참고로, 편안하게 읽을 수 있는 속도는 초당 약 10토큰입니다. 초당 5토큰 아래로 내려가면 대부분의 사람은 더 이상 쓰지 않게 됩니다.

32B 행을 보십시오. 동일한 모델 하나가 라인업 전체에 걸쳐 겨우 견딜 만한 수준에서 진짜로 빠른 수준까지 변합니다 — 들어가는지 여부는 전혀 바뀌지 않았는데도 말입니다. 이것이 바로 대역폭이지 용량이 아니며, 기술적으로 모델을 담을 수 있는 가장 저렴한 기기를 사는 사람들이 흔히 잊어버리는 축입니다.

MoE 모델이 답을 바꾸는 이유

MoE(전문가 혼합, Mixture-of-Experts) 모델은 위 규칙을 깨뜨리며, 이것이 바로 512GB 기기가 흥미로운 이유 전부입니다.

MoE 모델은 여러 개의 전문가 서브네트워크를 저장해두지만, 토큰마다 그중 일부만 활성화합니다. 활성 파라미터가 22B인 235B 모델은 235B어치의 가중치를 담고 있어야 하지만, 토큰 하나를 생성할 때는 약 22B어치만 읽습니다.

정리하면:

• 용량은 전체 파라미터 수에 의해 결정됩니다 — 4비트 기준 129GB.
• 속도는 활성 파라미터 수에 의해 결정됩니다 — 마치 22B 밀집 모델처럼 동작하므로, 235B 밀집 모델이었다면 M5 Ultra에서 약 9 tok/s에 그쳤을 것을 대략 40 tok/s로 낼 수 있습니다.

바로 이 비대칭성 때문에 대형 MoE 모델이 소비자용 GPU와 달리 Apple 실리콘에서는 실용적입니다. 필요한 것은 용량인데, Apple은 이 가격대에서 다른 어떤 회사도 하지 않는 방식으로 용량을 팔고 있으며, 그 대가로 훨씬 작은 모델에 비례하는 속도를 얻습니다.

이것이 바로 '512GB면 프런티어급 모델을 돌릴 수 있다'는 말이 사실이면서도 불완전한 이유이기도 합니다. 실제로 실용적인 속도로 돌아가는 것은 희소(sparse) 프런티어 모델입니다. 가상의 400B 밀집 모델을 4비트로 돌린다면 220GB를 차지하고 M5 Ultra에서 초당 약 4토큰을 생성할 것입니다. 들어가기는 합니다. 다만 즐겁게 쓰지는 못할 것입니다.

프롬프트 처리는 전혀 다른 문제입니다

새 Mac mini에 대한 Apple의 주장을 정확히 읽어보십시오:

M4 대비 최대 4.8배 빠른 LLM 프롬프트 처리 M1 대비 최대 13.5배 빠른 LLM 프롬프트 처리

프롬프트 처리 — 프리필(prefill) — 는 모델이 여러분이 입력한 내용을 받아들이는 단계입니다. 입력의 모든 토큰이 병렬로 처리되기 때문에 연산 능력에 좌우되는(compute-bound) 작업이며, GPU 처리량, 각 GPU 코어에 이제 내장된 Neural Accelerator, 그리고 M6에서는 Apple이 처음 출시한 듀얼 Neural Engine에 따라 성능이 달라집니다.

토큰 생성 — 디코드(decode) — 은 한 번에 토큰 하나씩 이루어지며, 매번 가중치 전체를 한 번씩 훑어야 합니다. 이는 대역폭에 좌우되는(bandwidth-bound) 작업이며, 연산 능력을 아무리 높여도 해결되지 않습니다.

Apple은 이 중 연산 능력에 좌우되는 쪽을 홍보에 내세웠습니다. 이것이 오해를 불러일으키려는 것은 아닙니다 — 실제로 이번 세대에서 가장 크게 개선된 부분이 맞습니다. 다만 마케팅 수치가 설명하는 것은 기기가 여러분의 50페이지짜리 문서를 얼마나 빨리 읽는지이지, 요약문을 얼마나 빨리 써내는지가 아니라는 뜻입니다.

어느 쪽이 더 중요한지는 여러분의 작업 방식에 달려 있습니다:

• 긴 입력, 짧은 출력 — 문서 요약, 분류, 코드베이스에서 정보 추출 — 은 프리필이 지배적입니다. Apple의 수치가 적용됩니다.
• 짧은 입력, 긴 출력 — 초안 작성, 채팅, 코드 생성 — 은 디코드가 지배적입니다. 이때 중요한 것은 대역폭입니다.
• 긴 입력과 긴 출력 — 대용량 컨텍스트에서 동작하는 에이전트형 워크플로 — 은 둘 다 필요하며, 여기에 KV 캐시를 위한 용량까지 추가로 필요합니다.

M5 Ultra에서 실제로 달라진 점

일부 출시 보도는 마치 데스크톱에서 프런티어급 모델을 돌릴 수 있게 된 것이 새로운 일인 것처럼 다뤘습니다. 사실은 그렇지 않으며, 이 점을 정확히 짚는 것이 이미 Mac Studio를 보유한 사람의 업그레이드 여부 판단을 바꿔놓습니다.

	M3 Ultra (2025)	M5 Ultra (2026)
최대 통합 메모리	512GB	512GB
메모리 대역폭	819GB/s	1.2TB/s
GPU 코어	최대 80개	최대 80개
CPU 코어	32개	최대 36개

용량은 변하지 않았습니다. GPU 코어 수도 변하지 않았습니다. 대역폭은 약 1.47배 늘었고, CPU는 코어 4개가 추가되었습니다.

이는 Apple이 M3 Ultra와 직접 비교한 수치와도 정확히 맞아떨어집니다 — '최대 1.3배 향상된 멀티스레드 성능'과 '최대 1.8배 빠른 그래픽'은 소박한 수치이며, Apple이 크게 내세우는 '최대 4.3배의 최대 AI 연산 성능'이라는 주장은 코어 수를 늘리거나 코어를 키운 데서 오는 것이 아니라 각 GPU 코어에 새로 내장된 Neural Accelerator에서 비롯된 것입니다.

따라서 로컬 추론에 한정해서 보면:

• 생성 속도는 대략 대역폭에 비례해 향상됩니다 — 동일한 모델 기준으로 약 1.4배 정도입니다.
• 프롬프트 처리는 앞서 말한 4.3배 AI 연산 수치에 걸맞게 훨씬 크게 향상됩니다.
• 로드할 수 있는 모델의 범위는 변하지 않았습니다.

512GB M3 Ultra Mac Studio를 이미 보유하고 있고, 여러분의 제약이 '어떤 모델이 들어가는가'라면 이번 세대는 여러분이 가진 문제를 해결해주지 못합니다. 반면 제약이 '긴 프롬프트 처리를 기다리는 것'이라면 이번 세대가 바로 그 문제를 해결해줍니다. 이전 세대에 대한 자세한 내용은 저희 Mac Studio M4 Max와 M3 Ultra 성능 가이드를 참고하십시오.

주문 전에 알아둘 만한 일정 관련 참고 사항이 하나 더 있습니다: 512GB 구성은 다른 모델들과 함께 9월 22일에 출시되지 않습니다. Apple에 따르면 10월 말에 도착할 예정입니다.

실제 용도별로 살펴보는 기기 선택

16GB — 이 용도에는 부적합

GPU가 사용할 수 있는 메모리는 대략 10~12GB입니다. 이 정도면 4비트 8B 모델을 적당한 컨텍스트로 돌릴 수 있는 정도이고, 그보다 큰 모델은 무리입니다. 자동완성 수준의 모델이나 소형 로컬 어시스턴트에는 괜찮지만, 그 이상은 답답함을 느끼게 될 것입니다. 2026년 기준 16GB는 다른 용도는 잘 소화하면서 LLM은 부수적으로 돌리는 기기입니다.

32GB (M6 Mac mini 풀옵션 — $1,299) — 입문 단계

대략 21~24GB를 사용할 수 있습니다. 8B와 14B 모델은 여유 있게 돌아가고, 4비트 32B 모델도 짧은 컨텍스트라면 초당 약 7토큰으로 돌아갑니다. 마지막 수치가 솔직한 한계입니다 — 들어가긴 하지만 겨우 쓸 만한 수준의 경계선입니다.

적합한 용도: 로컬 코딩 어시스턴트, 개인 문서 작업, 도구 익히기. 로컬 모델 실행이 이 기기를 구매하는 이유 중 하나라면, 16GB에서 $400을 더 주고 업그레이드하는 것은 선택이 아닙니다.

64GB (M5 Pro Mac mini — $1,699부터) — 대부분에게 최적인 지점

약 42~48GB를 사용할 수 있고, 대역폭은 307GB/s입니다. 4비트 70B 모델은 실질적인 컨텍스트 여유를 두고도 들어가며, 초당 약 6토큰으로 생성됩니다 — 배치 작업에는 쓸 만하지만 대화형 채팅에는 느립니다. 32B 모델은 대략 초당 12토큰으로 돌아가며, 이는 쾌적한 수준입니다.

본격적으로 로컬 모델을 쓰려는 대부분의 사람이 결국 도달하는 지점이 여기이며, 저라면 대부분의 사람에게 이 구성을 권하겠습니다. 여기에는 M6 mini에는 없는 Thunderbolt 5도 포함되어 있습니다.

128GB (M5 Max Mac Studio — $2,499부터) — 전문가용 등급

약 85~96GB를 614GB/s로 사용할 수 있습니다. 4비트 70B는 대략 초당 11토큰으로 돌아가 대화형으로도 충분히 쾌적합니다. 120B급 모델도 들어갑니다. 중간 규모의 MoE 모델도 실용적인 수준이 됩니다.

매일 로컬 추론에 업무가 걸려 있는 사람을 위한 구성입니다 — 대역폭이 늘어나면서 동일한 모델의 생성 속도가 M5 Pro의 대략 두 배가 됩니다.

512GB (M5 Ultra Mac Studio — $5,499부터, 풀옵션은 $18,000 이상) — 다른 곳에서는 살 수 없는 용량

약 340~384GB를 1.2TB/s로 사용할 수 있습니다. 이 정도면 4비트 400B급 MoE 모델도 담을 수 있고, 활성 파라미터 수에 해당하는 속도로 생성할 수 있습니다. 이는 이 가격대의 다른 어떤 데스크톱도 하지 못하는 일입니다.

다른 방법으로는 해결되지 않는 용량 제약이 있을 때만 이것을 구매하십시오. 여러분의 모델이 128GB에 들어간다면, Ultra는 더 저렴하게 얻을 수 있는 속도를 위해 돈을 쓰는 셈입니다.

새 Mac을 살 계획이 없다면

메모리가 충분한 기존 M1/M2/M3/M4 Mac이라면 로컬 모델을 무리 없이 돌릴 수 있습니다 — Pro와 Max 등급의 대역폭은 여러 세대에 걸쳐 이미 좋은 수준이었습니다. 본인 기기의 수치를 직접 확인해 보십시오:

# Total memory in GB
echo "$(( $(sysctl -n hw.memsize) / 1073741824 )) GB"

# Chip and current GPU wired limit
sysctl -n machdep.cpu.brand_string
sysctl iogpu.wired_limit_mb

그런 다음 위 표를 적용해 보십시오. 400GB/s의 64GB M1 Max는 지금도 충분히 훌륭한 로컬 추론용 기기이며, 예전부터 늘 그랬습니다.

실제 계산 예시

추상적인 표는 고개를 끄덕이기는 쉬워도 실제로 행동에 옮기기는 어렵습니다. 여기 하나의 구체적인 사례에 이 논리를 적용해 보겠습니다.

요구 사항: 어느 정도 규모가 있는 코드베이스를 읽고, 32,000토큰 컨텍스트를 유지하며, 대화형으로 응답하는 개인용 코딩 어시스턴트. 더 작은 모델은 코드 성능이 눈에 띄게 떨어지므로 32B급 모델을 원한다고 가정합니다.

1단계 — 가중치. 4비트 32B: 32 × 0.55 = 17.6GB.

2단계 — 컨텍스트. 최신 그룹 쿼리 어텐션 모델 기준 토큰당 약 0.2MB로 32,000토큰: 약 6.4GB. 사람들이 흔히 잊어버리는 항목이 바로 이것이며, 여기서는 가중치 크기의 3분의 1을 넘습니다.

3단계 — 오버헤드. 런타임, Metal 버퍼, 토크나이저: 2~3GB.

합계: GPU를 위해 고정(wire)해야 하는 메모리가 대략 26~27GB.

4단계 — 설치 메모리로 환산. 자동 상한이 약 70%라고 하면, 27GB를 고정하려면 설치 메모리가 약 38GB 필요합니다. 32GB Mac은 자동으로 21~24GB를 내주는데, 이는 부족합니다. 32GB 기기에서 iogpu.wired_limit_mb를 27GB까지 직접 올릴 수도 있지만, 그러면 macOS와 나머지 모든 것을 위해 5GB만 남습니다. 이는 다른 아무것도 실행되지 않을 때는 작동하겠지만, 브라우저를 여는 순간 무너질 것입니다.

결론: 설치 메모리 64GB. 이는 M6가 아니라 M5 Pro Mac mini로 귀결됩니다.

5단계 — 속도 확인. 307GB/s × 0.7 ÷ 17.6GB ≈ 초당 12토큰. 대화형 사용에 쾌적한 수준입니다.

이제 변수 하나만 바꿔봅시다. 나머지는 그대로 두고 128,000토큰 컨텍스트를 요구한다면, KV 캐시는 대략 25GB로 늘어나고, 총 필요량은 약 45GB, 필요한 설치 메모리는 wired limit을 올린다 해도 최소 64GB — 여유 있게 쓰려면 128GB가 됩니다. 설정 하나가 답을 제품 등급 하나만큼 통째로 끌어올린 것입니다.

이것이 방법의 전부입니다. 가중치, 컨텍스트, 오버헤드를 더하고 상한선으로 나눈 뒤, 가중치 크기 대비 대역폭을 확인하는 것입니다.

런타임마다 동작이 다릅니다

위의 계산은 하드웨어를 설명한 것입니다. 실제로 여러분이 관찰하는 결과는 소프트웨어에 달려 있으며, 그 차이는 구매 결정을 바꿀 만큼 큽니다.

MLX는 통합 메모리를 위해 만들어진 Apple 자체의 배열(array) 프레임워크입니다. Apple 실리콘에는 'CPU 메모리'와 'GPU 메모리'의 구분 자체가 없기 때문에 둘 사이를 복사하지 않으며, 대체로 Mac에서 가장 메모리 효율이 좋은 선택지입니다. 로컬 추론을 위해 하드웨어를 구매하는 것이라면, 그 하드웨어를 돋보이게 하는 것은 MLX 기반 도구입니다.

llama.cpp와 그 위에 만들어진 도구들은 이식성이 가장 뛰어난 선택지이며 Metal 지원도 훌륭합니다. 위 표에서 가정한 Q4_K_M 계열 양자화 포맷은 사실상 표준으로 자리 잡았고, 메모리 동작 방식도 예측 가능하고 잘 문서화되어 있습니다.

Ollama는 llama.cpp를 감싸서 모델 관리 기능을 더한 것입니다. 편리하지만, 알아둘 점은 사용이 끝난 뒤에도 설정 가능한 시간 동안 모델을 메모리에 계속 상주시킨다는 것입니다. 상한선에 가까운 상태라면, 한 시간 전에 이미 사용을 마친 모델이 여전히 메모리를 차지하고 있을 수 있습니다. '어제는 됐는데'의 흔한 원인이 바로 이것입니다.

LM Studio는 GUI 기반 선택지로, 메모리에 대해 정직하게 알려줍니다. 로드하기 전에 무엇이 들어가고 무엇이 들어가지 않는지 미리 보여줍니다. 직접 계산하지 않고도 이런 수치에 대한 감을 익히기 좋은 방법입니다.

어떤 것을 쓰든 중요한 동작 두 가지가 있습니다:

1. KV 캐시를 사전 할당하는지 여부. 일부 런타임은 로드 시점에 전체 컨텍스트 윈도우를 미리 확보해두고, 다른 런타임은 대화가 진행됨에 따라 점차 늘려갑니다. 사전 할당 방식에서는 실제로는 돌아갈 수 있는 모델이 로드 자체에 실패할 수 있습니다. 128K에서는 로드가 거부되는데 8K에서는 로드된다면 바로 이 때문이며, 이 경우 해결책은 더 작은 모델이 아니라 설정된 컨텍스트를 낮추는 것입니다.
2. 사용하지 않는 모델을 자동으로 언로드하는지 여부. 기기가 너무 작다고 결론짓기 전에 런타임의 keep-alive 설정부터 확인하십시오.

메모리를 더 사지 않고 여유를 확보하는 법

메모리 등급을 올리는 데 $400을 쓰기 전에, 계산 자체를 바꿔놓는 몇 가지 방법이 있습니다.

양자화를 더 세게 하십시오. 8비트에서 4비트로 내리면 메모리 요구량이 절반이 되는 대신 품질 저하는 크지 않습니다. 대부분의 경우 이는 정밀도를 높이면서 더 작은 모델로 옮겨가는 것보다 더 나은 선택입니다 — 비슷한 메모리 사용량에서 4비트 32B 모델은 대체로 8비트 14B 모델을 능가합니다.

KV 캐시도 양자화하십시오. 대부분의 런타임은 KV 캐시를 8비트 이하로 저장할 수 있습니다. 캐시 크기가 가중치에 맞먹는 긴 컨텍스트에서는 이것이 가장 큰 절약 효과를 내며, 품질 저하는 크지 않습니다.

컨텍스트 크기를 실제에 맞게 조정하십시오. 4,000토큰만 쓰면서도 128K 컨텍스트 윈도우를 설정해두면, 사전 할당 방식의 런타임에서는 여전히 그 전체 비용을 치르게 됩니다. 실제로 사용하는 만큼만 컨텍스트를 설정하십시오.

MoE 모델을 우선 고려하십시오. 앞서 다룬 대로, 전문가 혼합 모델은 대형 모델 수준의 품질을 소형 모델 수준의 생성 속도로 제공합니다. 그 대가는 용량인데, 바로 이 용량이야말로 Mac이 다른 대안들보다 훨씬 넉넉하게 가진 부분입니다.

추측 디코딩(speculative decoding)을 활용하십시오. 작은 드래프트 모델이 여러 토큰을 미리 제안하면, 큰 모델이 이를 한 번의 패스로 검증합니다. 검증 과정이 병렬로 이루어지기 때문에 대역폭 병목을 직접 공략할 수 있어 초당 토큰 수를 의미 있게 끌어올릴 수 있습니다 — 대가는 작은 모델 하나를 추가로 메모리에 유지해야 한다는 것입니다. 대역폭이 제한적이지만 용량에는 여유가 있는 기기에서는 좋은 트레이드오프입니다.

쓰지 않는 것을 닫으십시오. 당연한 얘기지만, 놀랍도록 자주 정답이기도 합니다. 탭을 많이 띄운 브라우저, 가상 머신, 영상 편집 프로그램은 모두 같은 메모리 풀을 두고 경쟁합니다. 따로 기댈 수 있는 별도의 VRAM은 없습니다.

흔한 문제 해결하기

모델은 로드되는데 생성 속도가 극도로 느림

문제: macOS가 GPU에 내주는 한도를 넘어서서 작업이 스왑으로 밀려나고 있는 상태입니다. 증상은 첫 토큰이 나오기까지 몇 초씩 걸리고, 생성이 매끄럽게 스트리밍되지 않고 끊기는 것입니다.

해결책: 생성하는 동안 활성 상태 보기(Activity Monitor)에서 메모리 압박 상태를 확인하십시오. 노란색이나 빨간색이라면 더 낮은 양자화를 쓰거나, 컨텍스트 윈도우를 줄이거나, iogpu.wired_limit_mb를 올리십시오 — 시스템을 위해 최소 6~8GB는 남겨두어야 합니다. 압박 상태가 초록색인데도 여전히 느리다면 단순히 대역폭이 부족한 것이며, 해결책은 더 작은 모델입니다.

"System has run out of application memory"

문제: 대개 wired limit을 너무 공격적으로 설정했거나, 긴 세션 동안 컨텍스트가 커진 경우입니다.

해결책: sudo sysctl iogpu.wired_limit_mb=0으로 초기화하고 추론 프로세스를 다시 시작하십시오. 그래도 시스템이 불안정하면 재부팅하십시오 — 이 설정은 지속되지 않으므로 재시작하면 어차피 초기화됩니다. 관련 원인은 저희 메모리 누수 문제 해결 가이드에서 다루고 있습니다.

계산상으로는 들어가는데 로드에 실패함

문제: 가중치 크기만 계산하고 KV 캐시를 빠뜨렸거나, 런타임이 컨텍스트를 점진적으로 늘리지 않고 처음부터 전체를 할당하고 있는 경우입니다.

해결책: 런타임 설정에서 컨텍스트 길이를 낮추고 다시 시도하십시오. 32K 컨텍스트는 로드되는데 128K는 안 된다면 이 진단이 맞다는 뜻이며, 용량 섹션의 계산법을 이용하면 원하는 컨텍스트에 필요한 양을 알 수 있습니다.

긴 세션 동안 Mac이 뜨거워지고 느려짐

문제: 지속적인 추론은 GPU와 메모리 모두에 지속적인 부하를 줍니다. 노트북은 스로틀링이 걸리지만, 데스크톱은 대체로 그렇지 않습니다.

해결책: 이 작업에 있어 MacBook보다 Mac mini나 Mac Studio를 선택할 실질적인 이유 중 하나가 바로 이것입니다 — 지속적인 발열 여유입니다. 노트북을 쓰신다면 저희 MacBook Pro M5 발열 스로틀링 가이드를 참고하십시오.

프롬프트 처리는 빠른데 생성은 느림

문제: 아무 문제도 없습니다. 이는 하드웨어의 예상된 특성입니다.

해결책: 위의 프리필 대 디코드 섹션을 참고하십시오. 생성 속도가 필요한 것이라면, 비용이 적게 드는 순서대로 더 작은 모델, 더 공격적인 양자화, 활성 파라미터 수가 적은 MoE 모델, 또는 더 높은 대역폭이 해결책입니다.

자주 묻는 질문

70B 모델을 돌리려면 RAM이 얼마나 필요한가요?

4비트 양자화 기준 가중치는 약 38.5GB입니다. 여기에 컨텍스트와 오버헤드를 더하면 현실적인 최소치로 설치 메모리 64GB가 필요합니다. macOS가 그중 대략 42~48GB만 GPU에 내주기 때문입니다. 의미 있는 수준의 컨텍스트를 포함하면 설치 메모리 48GB는 너무 빠듯합니다.

2026년에 로컬 AI를 쓰기에 16GB로 충분한가요?

짧은 컨텍스트의 4비트 8B 모델이라면 충분합니다. 그보다 큰 모델이라면 부족합니다. 로컬 모델 실행이 기기 구매 이유 중 하나라면, 32GB를 최소선으로, 64GB를 목표로 삼으십시오.

Neural Engine이 로컬 LLM 속도를 높여주나요?

프롬프트 처리에는 기여하며, 바로 여기서 Apple의 '4.8배 빠른 LLM 프롬프트 처리'라는 수치가 나옵니다. M6의 듀얼 16코어 Neural Engine은 실질적인 진전입니다. 하지만 토큰 생성의 대역폭 한계는 바꾸지 못합니다. Mac에서 널리 쓰이는 로컬 추론 런타임 대부분은 주로 Metal을 통한 GPU에 의존합니다.

512GB Mac Studio를 사야 할까요?

용량 제약이 있는 경우에만 그렇습니다. 실제로 돌리는 모델이 128GB에 들어간다면, M5 Max Mac Studio가 3분의 1 가격으로 같은 일을 해냅니다. 또한 512GB 옵션은 10월 말이 되어야 출시되며, 풀옵션 구성은 $18,299에 달한다는 점도 참고하십시오.

나중에 메모리를 추가할 수 있나요?

아니요. 통합 메모리는 모든 Apple 실리콘 Mac에서 칩 패키지의 일부입니다. 이는 넉넉하게 구매할 가치가 가장 큰 사양인데, 나중에 절대 다시 손댈 수 없는 유일한 사양이기 때문입니다.

이 용도에는 개별 GPU를 탑재한 PC보다 Mac이 더 나은가요?

트레이드오프가 서로 다릅니다. 개별 GPU는 메모리 대역폭이 훨씬 높지만 메모리 용량은 훨씬 적습니다 — 소비자용 카드는 Mac Studio가 제공하는 수준에 한참 못 미칩니다. Mac은 달러당 용량과 전력 소비에서 압도적으로 우위지만, VRAM에 들어갈 만큼 작은 모델의 순수 처리량에서는 밀립니다. 모델이 크다면 Mac이 사실상 유일한 단일 기기 옵션인 경우가 많습니다. 모델이 작다면 GPU가 더 빠릅니다.

양자화가 품질을 해치나요?

8비트는 대부분의 용도에서 거의 무손실에 가깝습니다. 4비트 K-quant는 실용적인 기본값이며, 대부분의 작업에서 품질 저하는 완만합니다. 4비트 아래로 내려가면 품질이 눈에 띄게 떨어집니다. 위 메모리 표를 보면, 8비트에서 4비트로 내리는 것은 메모리 요구량을 대략 절반으로 줄이며 — 대개 더 작은 모델로 옮겨가는 것보다 더 나은 선택입니다.

결론

512GB라는 헤드라인은 실제이며, 소수의 사람에게는 결정적인 요소입니다. 나머지 대부분에게 이 글에서 쓸모 있는 부분은 세 줄의 계산입니다: 가중치는 파라미터 수 곱하기 파라미터당 바이트 수이고, 컨텍스트는 여기에 토큰당 0.10.5MB를 더하며, macOS는 여러분이 구매한 것의 약 6575%만 GPU에 내줍니다.

실제로 사용하려는 모델을 기준으로 이 숫자들을 계산해보면 답은 대개 64GB로 귀결됩니다. 그다음에는 두 번째 숫자인 대역폭을 확인해야 합니다 — 이것이 들어가는 모델을 계속 쓰게 될 모델로 만들어줄지를 결정하기 때문입니다. 초당 7토큰인 32B 모델과 초당 24토큰인 같은 모델 사이의 격차는 데모와 도구 사이의 격차이며, 용량을 아무리 늘려도 이 격차는 메워지지 않습니다.

무엇을 고르든, 신중하게 고르십시오. 이것은 납땜되어 있습니다.

관련 글: Mac mini M6와 Mac Studio M5 Ultra: 실제로 달라진 점, Mac의 로컬 AI 앱과 여러분의 데이터 처리 방식, 2026년 Mac RAM 가격 상승.